From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 1 05:14:11 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4901216C30B for ; Mon, 1 Jan 2007 05:13:23 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.freebsd.org (Postfix) with ESMTP id D05D713C46B for ; Mon, 1 Jan 2007 05:13:22 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id l015DM4W066477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 31 Dec 2006 21:13:22 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id l015DMga066476 for freebsd-hackers@freebsd.org; Sun, 31 Dec 2006 21:13:22 -0800 (PST) Received: from fbsd61 ([192.168.200.61]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA28477; Sun, 31 Dec 06 21:04:32 PST Date: Sun, 31 Dec 2006 21:07:27 -0800 From: perryh@pluto.rain.com To: freebsd-hackers@freebsd.org Message-Id: <4598970f.9ep0rKpupZVZv2B8%perryh@pluto.rain.com> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: how to stop the "automatic reboot" 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: Mon, 01 Jan 2007 05:14:12 -0000 Pressing a key after the "Automatic reboot in 15 seconds - press a key on the console to abort" message does not seem to prevent the reboot. What is the correct way of stopping it long enough to copy the other messages? From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 1 17:29:11 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B7AB16A412 for ; Mon, 1 Jan 2007 17:29:11 +0000 (UTC) (envelope-from huyslogic@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.225]) by mx1.freebsd.org (Postfix) with ESMTP id 4F0DA13C428 for ; Mon, 1 Jan 2007 17:29:11 +0000 (UTC) (envelope-from huyslogic@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so2423332nzh for ; Mon, 01 Jan 2007 09:29:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=gc3hohSpP4DdRgN94437ihyALHLvpuuKDOIpqYV0RWMcJSBGLA8jCzGt2YWO6YmNou2PUE7Jjazu1kmwgmEHPowJ1eTCggfSq9fI4BvdaODsu3qztHtVw2GWid7sPGS8EuOL5hcyShDruxvxhiQAgfviOsQHOa0eokqxaZv0Ffw= Received: by 10.65.236.14 with SMTP id n14mr16524839qbr.1167670997191; Mon, 01 Jan 2007 09:03:17 -0800 (PST) Received: by 10.65.176.17 with HTTP; Mon, 1 Jan 2007 09:03:17 -0800 (PST) Message-ID: <1cac28080701010903v3a793452ldce6906464febf64@mail.gmail.com> Date: Mon, 1 Jan 2007 12:03:17 -0500 From: "Huy Ton That" To: "perryh@pluto.rain.com" In-Reply-To: <4598970f.9ep0rKpupZVZv2B8%perryh@pluto.rain.com> MIME-Version: 1.0 References: <4598970f.9ep0rKpupZVZv2B8%perryh@pluto.rain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: how to stop the "automatic reboot" 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: Mon, 01 Jan 2007 17:29:11 -0000 I'm not certain, but maybe pressing the pause-break key on your keyboard will work. This has saved me in the past. On 1/1/07, perryh@pluto.rain.com wrote: > > Pressing a key after the "Automatic reboot in 15 seconds - press a > key on the console to abort" message does not seem to prevent the > reboot. What is the correct way of stopping it long enough to copy > the other messages? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 1 21:09:41 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E4BA16A415 for ; Mon, 1 Jan 2007 21:09:41 +0000 (UTC) (envelope-from bsd.devil@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.237]) by mx1.freebsd.org (Postfix) with ESMTP id 53DA213C4A5 for ; Mon, 1 Jan 2007 21:09:41 +0000 (UTC) (envelope-from bsd.devil@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so2444045nzh for ; Mon, 01 Jan 2007 13:09:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=JRCGJUhlb3E/opeBu9W2ea1666V4JHK91mjn7HccDCcCUCZ4jRZof7b3semighkRGebSt97nz//kt57ckofX1dFXGP52lb4T/r5Don7nZsf0ei0VX/mRWq/fbApDQWofHdmu+trCKERkm9ETebmaxUe01s1VqdAG8tgEZ6vGiDY= Received: by 10.65.177.6 with SMTP id e6mr25543179qbp.1167684109865; Mon, 01 Jan 2007 12:41:49 -0800 (PST) Received: by 10.65.249.17 with HTTP; Mon, 1 Jan 2007 12:41:49 -0800 (PST) Message-ID: Date: Mon, 1 Jan 2007 15:41:49 -0500 From: "Vishal Patil" To: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org. MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: vpnc problem 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: Mon, 01 Jan 2007 21:09:41 -0000 I am trying to use vpnc 0.3.3 on FreeBSD 6.1 but I get the following errors route: bad address: delete net default Also this completely screws up the network on my machine :( Has anyone being successfully in using vpnc 0.3.3 on FreeBSD 6.1? Thanks. - Vishal From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 1 21:54:06 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2DB3816A407 for ; Mon, 1 Jan 2007 21:54:06 +0000 (UTC) (envelope-from steve@Watt.COM) Received: from wattres.watt.com (wattres.watt.com [66.93.133.130]) by mx1.freebsd.org (Postfix) with ESMTP id EE4FF13C468 for ; Mon, 1 Jan 2007 21:54:05 +0000 (UTC) (envelope-from steve@Watt.COM) Received: from wattres.watt.com (localhost.watt.com [127.0.0.1]) by wattres.watt.com (8.13.8/8.13.8) with ESMTP id l01LawHF017697 for ; Mon, 1 Jan 2007 13:36:58 -0800 (PST) (envelope-from steve@wattres.watt.com) Received: (from steve@localhost) by wattres.watt.com (8.13.8/8.13.8/Submit) id l01Lawp7017696 for hackers@freebsd.org; Mon, 1 Jan 2007 13:36:58 -0800 (PST) (envelope-from steve) Message-Id: <200701012136.l01Lawp7017696@wattres.watt.com> From: steve@Watt.COM (Steve Watt) Date: Mon, 1 Jan 2007 13:36:58 -0800 X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: hackers@freebsd.org X-Archived: 1167687418.194853807@wattres.Watt.COM Cc: Subject: Interesting TCP issue 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: Mon, 01 Jan 2007 21:54:06 -0000 One of my users is having trouble receiving mail from Skype. So, after some sniffing, I discovered this: # tcpdump -vv -s 1500 -i dc0 -X net 213.244.128.0/18 tcpdump: lestening on dc0, link-type EN10MB (Ethernet), capture size 1500 bytes 13:18:13.607493 IP (tos 0x20, ttl 58, id 12896, offset 0, flags [DF], proto: TCP (6), length: 74) share.skype.net.50406 > wattres.watt.com.smtp: P, cksum 0x9297 (correct), 4072464914:4072464936(22) ack 1248591103 win 46 0x0000: 4520 004a 3260 4000 3a06 c609 d5f4 aa50 E..J2`@.:......P 0x0010: 425d 8582 c4e6 0019 f2bc e212 4a6b fcff B]..........Jk.. 0x0020: 8018 002e 9297 0000 0101 080a 95b8 5568 ..............Uh 0x0030: 1eff 784a 4548 4c4f 2073 6861 7265 2e73 ..xJEHLO.share.s 0x0040: 6b79 7065 2e6e 6574 0d0a kype.net.. 0x0000: 4520 004a 3261 4000 3a06 c608 d5f4 aa50 E..J2a@.:......P 0x0010: 425d 8582 c4e6 0019 f2bc e212 4a6b fcff B]..........Jk.. 0x0020: 8018 002e 1d67 0000 0101 080a 95b8 ca98 .....g.......... 0x0030: 1eff 784a 4548 4c4f 2073 6861 7265 2e73 ..xJEHLO.share.s 0x0040: 6b79 7065 2e6e 6574 0d0a kype.net.. And no responses from my system. Interesting. I presume it has something to do with the idiotically small window the remote server is advertising. So I set net.inet.tcp.minmss down to 46, and that resulted in a RST being spit back to skype's server when its retransmit happened. 13:20:13.610975 IP (tos 0x20, ttl 58, id 12897, offset 0, flags [DF], proto: TCP (6), length: 74) share.skype.net.50406 > wattres.watt.com.smtp: P, cksum 0x1d67 (correct), 0:22(22) ack 1 win 46 13:20:13.611036 IP (tos 0x20, ttl 64, id 39789, offset 0, flags [DF], proto: TCP (6), length: 40) wattres.watt.com.smtp > share.skype.net.50406: R, cksum 0x5b51 (correct), 1248591103:1248591103(0) win 0 0x0000: 4520 0028 9b6d 4000 4006 571e 425d 8582 E..(.m@.@.W.B].. 0x0010: d5f4 aa50 0019 c4e6 4a6b fcff 0000 0000 ...P....Jk...... 0x0020: 5004 0000 5b51 0000 P...[Q.. The packets shown here are the complete capture. I can hand-type stuff to the skype server and it appears to get through just fine, but when it connects to my box, no segments make their way back to skype. I can see them sitting in the Send-Q: # netstat -f inet Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (state) [ ... ] tcp4 0 213 wattres.smtp share.skype.net.50406 ESTABLISHED [ ... ] Very strange. Any opinions on possible workarounds, since I'm not expecting Skype to fix their (broken) system? -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3" Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices... From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 2 01:33:37 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4584116A407 for ; Tue, 2 Jan 2007 01:33:37 +0000 (UTC) (envelope-from david@madole.net) Received: from d.omd3.com (mx1.omd3.com [69.90.174.41]) by mx1.freebsd.org (Postfix) with ESMTP id 26CA513C44B for ; Tue, 2 Jan 2007 01:33:36 +0000 (UTC) (envelope-from david@madole.net) Received: from [66.212.193.19] (helo=david) by d.omd3.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.54) id 1H1YNY-0005NS-Fp; Mon, 01 Jan 2007 20:23:48 -0500 Date: Mon, 01 Jan 2007 20:21:00 -0500 From: "David S. Madole" To: 'Steve Watt' , "'hackers@freebsd.org'" X-Priority: 3 Organization: Optimized Micro Devices X-Mailer: Bynari Insight Connector 3.1.1-1128233 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <20070102013337.26CA513C44B@mx1.freebsd.org> Cc: Subject: RE: Interesting TCP issue 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, 02 Jan 2007 01:33:37 -0000 > From Steve Watt on Monday, January 01, 2007 4:37 PM >=20 > # tcpdump -vv -s 1500 -i dc0 -X net 213.244.128.0/18 > tcpdump: lestening on dc0, link-type EN10MB (Ethernet), capture size 1500 > bytes > 13:18:13.607493 IP (tos 0x20, ttl 58, id 12896, offset 0, flags [DF], > proto: TCP (6), length: 74) share.skype.net.50406 > wattres.watt.com.smtp= : > P, cksum 0x9297 (correct), 4072464914:4072464936(22) ack 1248591103 win 4= 6 > > 0x0000: 4520 004a 3260 4000 3a06 c609 d5f4 aa50 E..J2`@.:......= P > 0x0010: 425d 8582 c4e6 0019 f2bc e212 4a6b fcff B]..........Jk.= . > 0x0020: 8018 002e 9297 0000 0101 080a 95b8 5568 ..............U= h > 0x0030: 1eff 784a 4548 4c4f 2073 6861 7265 2e73 ..xJEHLO.share.= s > 0x0040: 6b79 7065 2e6e 6574 0d0a kype.net.. >=20 > Interesting. I presume it has something to do with the > idiotically small window the remote server is advertising. So I > set net.inet.tcp.minmss down to 46, and that resulted in a RST > being spit back to skype's server when its retransmit happened. Are you sure the window is really that small and that window scaling was no= t negotiated at the start of the connection? The initial packets are not ca= ptured here so I can't tell. Is it possible to get a really complete capture of a session including the = initial handshake? David From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 2 02:46:50 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 872BA16A412 for ; Tue, 2 Jan 2007 02:46:50 +0000 (UTC) (envelope-from iedowse@iedowse.com) Received: from nowhere.iedowse.com (nowhere.iedowse.com [82.195.144.75]) by mx1.freebsd.org (Postfix) with SMTP id E09FB13C441 for ; Tue, 2 Jan 2007 02:46:49 +0000 (UTC) (envelope-from iedowse@iedowse.com) Received: from localhost ([127.0.0.1] helo=iedowse.com) by nowhere.iedowse.com via local-iedowse id ; 2 Jan 2007 00:46:39 +0000 (GMT) To: Matthew Dillon In-Reply-To: Your message of "Sun, 31 Dec 2006 12:43:44 PST." <200612312043.kBVKhi7t095666@apollo.backplane.com> Date: Tue, 02 Jan 2007 00:46:38 +0000 From: Ian Dowse Message-ID: <200701020046.aa80712@nowhere.iedowse.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Confusion in acpi_sleep_machdep(). 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, 02 Jan 2007 02:46:50 -0000 In message <200612312043.kBVKhi7t095666@apollo.backplane.com>, Matthew Dillon w rites: > I'm trying to figure out how the acpi_sleep_machdep() code works and > there are a couple of lines I just don't understand: > > pm = vmspace_pmap(p->p_vmspace); > cr3 = rcr3(); >#ifdef PAE > load_cr3(vtophys(pm->pm_pdpt)); >#else > load_cr3(vtophys(pm->pm_pdir)); >#endif > > page = PHYS_TO_VM_PAGE(sc->acpi_wakephys); > pmap_enter(pm, sc->acpi_wakephys, page, > VM_PROT_READ | VM_PROT_WRITE | VM_PROT_EXECUTE, 1); > > First, why isn't it just using kernel_pmap ? What's all the load_cr3() > stuff for ? > > Second, why is it entering the physical address sc->acpi_wakephys > as the virtual address in the pmap ? Shouldn't it be using > sc->acpi_wakeaddr there? > > Anybody know ? I don't know the details, but acpi_sleep_machdep() sets up an identity mapping in the current process's vmspace (hence using virtual = physical). Lazy switching of address spaces means that cr3 may not currently refer to the same vmspace, which would break the identity mapping, so that's the reason for the load_cr3() calls. See revision 1.22 for a bit more information. Ian From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 2 05:50:59 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F5BB16A407 for ; Tue, 2 Jan 2007 05:50:59 +0000 (UTC) (envelope-from SRS0=5nRf5r=GL=vvelox.net=v.velox@yourhostingaccount.com) Received: from mailout03.yourhostingaccount.com (mailout03.yourhostingaccount.com [65.254.254.78]) by mx1.freebsd.org (Postfix) with ESMTP id 3681613C467 for ; Tue, 2 Jan 2007 05:50:59 +0000 (UTC) (envelope-from SRS0=5nRf5r=GL=vvelox.net=v.velox@yourhostingaccount.com) Received: from scan04.yourhostingaccount.com ([10.1.1.234] helo=scan04.yourhostingaccount.com) by mailout03.yourhostingaccount.com with esmtp (Exim) id 1H1cI5-00076w-CA for freebsd-hackers@freebsd.org; Tue, 02 Jan 2007 00:34:25 -0500 Received: from authsmtp11.yourhostingaccount.com ([10.1.18.11] ident=exim) by scan04.yourhostingaccount.com with spamscanlookuphost (Exim) id 1H1cI5-0006Cz-8X for freebsd-hackers@freebsd.org; Tue, 02 Jan 2007 00:34:25 -0500 Received: from authsmtp11.yourhostingaccount.com ([10.1.18.11] helo=authsmtp11.yourhostingaccount.com) by scan04.yourhostingaccount.com with esmtp (Exim) id 1H1cI4-0006Cu-T5 for freebsd-hackers@freebsd.org; Tue, 02 Jan 2007 00:34:24 -0500 Received: from [69.92.217.33] (helo=vixen42) by authsmtp11.yourhostingaccount.com with esmtpa (Exim) id 1H1cI4-0004nY-7B for freebsd-hackers@freebsd.org; Tue, 02 Jan 2007 00:34:24 -0500 Date: Mon, 1 Jan 2007 23:35:25 -0600 From: Vulpes Velox To: freebsd-hackers@freebsd.org Message-ID: <20070101233525.0b10a1e2@vixen42> X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.10.6; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EN-UserInfo: 0d1ca1697cdb7a831d4877828571b7ab:1570f0de6936c69fef9e164fffc541bc X-EN-AuthUser: vvelox2 Sender: Vulpes Velox Subject: getgroups and getgrouplist functions 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, 02 Jan 2007 05:50:59 -0000 Just working on fixing the problem with DBus for when a user is a member of more than 16 groups. I have NGROUPS_MAX set to 64 on this system. So far I have one person on the DBus mailing list telling me that the FreeBSD getgrouplist is broken. I just want to verify if how I am reading the docs is correctly. I am reading it as int *ngroups is not set to the number of groups in the list if the number of groups is larger than the number specified. They are saying it does not make a difference because getgroupslist will do it regardless. Based on testing and reading the man, I am convinced this is a load of bull. And the proper way to get the number of groups some one is in is to call getgroups(0). Any one have any opinions or would like to hear more? From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 2 07:50:00 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A78D16A403 for ; Tue, 2 Jan 2007 07:50:00 +0000 (UTC) (envelope-from steve@Watt.COM) Received: from wattres.watt.com (wattres.watt.com [66.93.133.130]) by mx1.freebsd.org (Postfix) with ESMTP id 3B77313C471 for ; Tue, 2 Jan 2007 07:50:00 +0000 (UTC) (envelope-from steve@Watt.COM) Received: from wattres.watt.com (localhost.watt.com [127.0.0.1]) by wattres.watt.com (8.13.8/8.13.8) with ESMTP id l027nwlb033589 for ; Mon, 1 Jan 2007 23:49:58 -0800 (PST) (envelope-from steve@wattres.watt.com) Received: (from steve@localhost) by wattres.watt.com (8.13.8/8.13.8/Submit) id l027nw80033588 for hackers@freebsd.org; Mon, 1 Jan 2007 23:49:58 -0800 (PST) (envelope-from steve) Message-Id: <200701020749.l027nw80033588@wattres.watt.com> X-Newsgroups: local.freebsd-hackers In-Reply-To: <20070102013337.26CA513C44B@mx1.freebsd.org> From: steve@Watt.COM (Steve Watt) Organization: Watt Consultants, San Jose, CA, USA Date: Mon, 1 Jan 2007 23:07:23 -0800 X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: david@madole.net Status: RO X-Archived: 1167724198.398154640@wattres.Watt.COM Cc: hackers@freebsd.org Subject: Re: Interesting TCP issue 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, 02 Jan 2007 07:50:00 -0000 In <20070102013337.26CA513C44B@mx1.freebsd.org>, david@madole.net wrote: >> From Steve Watt on Monday, January 01, 2007 4:37 PM >> >> # tcpdump -vv -s 1500 -i dc0 -X net 213.244.128.0/18 [ snip ] >> Interesting. I presume it has something to do with the >> idiotically small window the remote server is advertising. So I >> set net.inet.tcp.minmss down to 46, and that resulted in a RST >> being spit back to skype's server when its retransmit happened. > >Are you sure the window is really that small and that window scaling was not >negotiated at the start of the connection? The initial packets are not captured >here so I can't tell. > >Is it possible to get a really complete capture of a session including the initial >handshake? Good point. Here's the full capture from a different session. Same tcpdump flags. My FreeBSD box (a.k.a. wattres.watt.com) said wscale 1, so that's (if I remember my TCP correctly) what gets used. Note after the ACK from share.skype.net, my machine doesn't ACK the segment with the EHLO in it, so we get retransmits. At the application level, I can see that sendmail got the EHLO, because the milter cb_helo callback happened. I wasn't at the box when this particular connection attempt happened, so I couldn't see the Send Q in netstat, but this is exactly the same appearance as the snippet I showed earlier, so I'm presuming a similar failure occurred. Very strange behavior. 22:44:17.578821 IP (tos 0x20, ttl 58, id 56305, offset 0, flags [DF], proto: TCP (6), length: 60) share.skype.net.59816 > wattres.watt.com.smtp: S, cksum 0xf0c3 (correct), 1414414327:1414414327(0) win 5840 0x0000: 4520 003c dbf1 4000 3a06 1c86 d5f4 aa50 E..<..@.:......P 0x0010: 425d 8582 e9a8 0019 544e 3ff7 0000 0000 B]......TN?..... 0x0020: a002 16d0 f0c3 0000 0204 05b4 0402 080a ................ 0x0030: 9639 e406 0000 0000 0103 0307 .9.......... 22:44:17.578958 IP (tos 0x0, ttl 64, id 30930, offset 0, flags [DF], proto: TCP (6), length: 64) wattres.watt.com.smtp > share.skype.net.59816: S, cksum 0xb1c9 (correct), 1236670735:1236670735(0) ack 1414414328 win 65535 0x0000: 4500 0040 78d2 4000 4006 79c1 425d 8582 E..@x.@.@.y.B].. 0x0010: d5f4 aa50 0019 e9a8 49b6 190f 544e 3ff8 ...P....I...TN?. 0x0020: b012 ffff b1c9 0000 0204 05b4 0103 0301 ................ 0x0030: 0101 080a 2107 c0ed 9639 e406 0402 0000 ....!....9...... 22:44:17.742243 IP (tos 0x20, ttl 58, id 56306, offset 0, flags [DF], proto: TCP (6), length: 52) share.skype.net.59816 > wattres.watt.com.smtp: ., cksum 0xf13d (correct), 1:1(0) ack 1 win 46 0x0000: 4520 0034 dbf2 4000 3a06 1c8d d5f4 aa50 E..4..@.:......P 0x0010: 425d 8582 e9a8 0019 544e 3ff8 49b6 1910 B]......TN?.I... 0x0020: 8010 002e f13d 0000 0101 080a 9639 e42f .....=.......9./ 0x0030: 2107 c0ed !... 22:44:17.785110 IP (tos 0x0, ttl 64, id 30938, offset 0, flags [DF], proto: TCP (6), length: 64) wattres.watt.com.57166 > share.skype.net.auth: S, cksum 0x6899 (correct), 2124104998:2124104998(0) win 65535 0x0000: 4500 0040 78da 4000 4006 79b9 425d 8582 E..@x.@.@.y.B].. 0x0010: d5f4 aa50 df4e 0071 7e9b 4526 0000 0000 ...P.N.q~.E&.... 0x0020: b002 ffff 6899 0000 0204 05b4 0103 0301 ....h........... 0x0030: 0101 080a 2107 c1ba 0000 0000 0402 0000 ....!........... 22:44:17.947113 IP (tos 0x20, ttl 58, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) share.skype.net.auth > wattres.watt.com.57166: R, cksum 0xc429 (correct), 0:0(0) ack 2124104999 win 0 0x0000: 4520 0028 0000 4000 3a06 f88b d5f4 aa50 E..(..@.:......P 0x0010: 425d 8582 0071 df4e 0000 0000 7e9b 4527 B]...q.N....~.E' 0x0020: 5014 0000 c429 0000 0000 0000 0000 P....)........ 22:44:17.952929 IP (tos 0x0, ttl 64, id 30939, offset 0, flags [DF], proto: TCP (6), length: 98) wattres.watt.com.smtp > share.skype.net.59816: ., cksum 0x3baf (correct), 1:47(46) ack 1 win 33304 0x0000: 4500 0062 78db 4000 4006 7996 425d 8582 E..bx.@.@.y.B].. 0x0010: d5f4 aa50 0019 e9a8 49b6 1910 544e 3ff8 ...P....I...TN?. 0x0020: 8010 8218 3baf 0000 0101 080a 2107 c262 ....;.......!..b 0x0030: 9639 e42f 3232 3020 7761 7474 7265 732e .9./220.wattres. 0x0040: 7761 7474 2e63 6f6d 2045 534d 5450 2053 watt.com.ESMTP.S 0x0050: 656e 646d 6169 6c20 382e 3133 2e38 2f38 endmail.8.13.8/8 0x0060: 2e31 .1 22:44:18.115814 IP (tos 0x20, ttl 58, id 56307, offset 0, flags [DF], proto: TCP (6), length: 52) share.skype.net.59816 > wattres.watt.com.smtp: ., cksum 0xef3d (correct), 1:1(0) ack 47 win 46 0x0000: 4520 0034 dbf3 4000 3a06 1c8c d5f4 aa50 E..4..@.:......P 0x0010: 425d 8582 e9a8 0019 544e 3ff8 49b6 193e B]......TN?.I..> 0x0020: 8010 002e ef3d 0000 0101 080a 9639 e48c .....=.......9.. 0x0030: 2107 c262 !..b 22:44:18.115887 IP (tos 0x0, ttl 64, id 30940, offset 0, flags [DF], proto: TCP (6), length: 95) wattres.watt.com.smtp > share.skype.net.59816: P, cksum 0xbd09 (correct), 47:90(43) ack 1 win 33304 0x0000: 4500 005f 78dc 4000 4006 7998 425d 8582 E.._x.@.@.y.B].. 0x0010: d5f4 aa50 0019 e9a8 49b6 193e 544e 3ff8 ...P....I..>TN?. 0x0020: 8018 8218 bd09 0000 0101 080a 2107 c306 ............!... 0x0030: 9639 e48c 332e 383b 204d 6f6e 2c20 3120 .9..3.8;.Mon,.1. 0x0040: 4a61 6e20 3230 3037 2032 323a 3434 3a31 Jan.2007.22:44:1 0x0050: 3720 2d30 3830 3020 2850 5354 290d 0a 7.-0800.(PST).. 22:44:18.279234 IP (tos 0x20, ttl 58, id 56308, offset 0, flags [DF], proto: TCP (6), length: 52) share.skype.net.59816 > wattres.watt.com.smtp: ., cksum 0xee45 (correct), 1:1(0) ack 90 win 46 0x0000: 4520 0034 dbf4 4000 3a06 1c8b d5f4 aa50 E..4..@.:......P 0x0010: 425d 8582 e9a8 0019 544e 3ff8 49b6 1969 B]......TN?.I..i 0x0020: 8010 002e ee45 0000 0101 080a 9639 e4b5 .....E.......9.. 0x0030: 2107 c306 !... 22:44:18.280331 IP (tos 0x20, ttl 58, id 56309, offset 0, flags [DF], proto: TCP (6), length: 74) share.skype.net.59816 > wattres.watt.com.smtp: P, cksum 0xb617 (correct), 1:23(22) ack 90 win 46 0x0000: 4520 004a dbf5 4000 3a06 1c74 d5f4 aa50 E..J..@.:..t...P 0x0010: 425d 8582 e9a8 0019 544e 3ff8 49b6 1969 B]......TN?.I..i 0x0020: 8018 002e b617 0000 0101 080a 9639 e4b5 .............9.. 0x0030: 2107 c306 4548 4c4f 2073 6861 7265 2e73 !...EHLO.share.s 0x0040: 6b79 7065 2e6e 6574 0d0a kype.net.. 22:44:18.768992 IP (tos 0x20, ttl 58, id 56310, offset 0, flags [DF], proto: TCP (6), length: 74) share.skype.net.59816 > wattres.watt.com.smtp: P, cksum 0xb59c (correct), 1:23(22) ack 90 win 46 0x0000: 4520 004a dbf6 4000 3a06 1c73 d5f4 aa50 E..J..@.:..s...P 0x0010: 425d 8582 e9a8 0019 544e 3ff8 49b6 1969 B]......TN?.I..i 0x0020: 8018 002e b59c 0000 0101 080a 9639 e530 .............9.0 0x0030: 2107 c306 4548 4c4f 2073 6861 7265 2e73 !...EHLO.share.s 0x0040: 6b79 7065 2e6e 6574 0d0a kype.net.. 22:44:19.754563 IP (tos 0x20, ttl 58, id 56311, offset 0, flags [DF], proto: TCP (6), length: 74) share.skype.net.59816 > wattres.watt.com.smtp: P, cksum 0xb4a6 (correct), 1:23(22) ack 90 win 46 0x0000: 4520 004a dbf7 4000 3a06 1c72 d5f4 aa50 E..J..@.:..r...P 0x0010: 425d 8582 e9a8 0019 544e 3ff8 49b6 1969 B]......TN?.I..i 0x0020: 8018 002e b4a6 0000 0101 080a 9639 e626 .............9.& 0x0030: 2107 c306 4548 4c4f 2073 6861 7265 2e73 !...EHLO.share.s 0x0040: 6b79 7065 2e6e 6574 0d0a kype.net.. 22:44:21.722186 IP (tos 0x20, ttl 58, id 56312, offset 0, flags [DF], proto: TCP (6), length: 74) share.skype.net.59816 > wattres.watt.com.smtp: P, cksum 0xb2ba (correct), 1:23(22) ack 90 win 46 0x0000: 4520 004a dbf8 4000 3a06 1c71 d5f4 aa50 E..J..@.:..q...P 0x0010: 425d 8582 e9a8 0019 544e 3ff8 49b6 1969 B]......TN?.I..i 0x0020: 8018 002e b2ba 0000 0101 080a 9639 e812 .............9.. 0x0030: 2107 c306 4548 4c4f 2073 6861 7265 2e73 !...EHLO.share.s 0x0040: 6b79 7065 2e6e 6574 0d0a kype.net.. 22:44:25.659767 IP (tos 0x20, ttl 58, id 56313, offset 0, flags [DF], proto: TCP (6), length: 74) share.skype.net.59816 > wattres.watt.com.smtp: P, cksum 0xaee2 (correct), 1:23(22) ack 90 win 46 0x0000: 4520 004a dbf9 4000 3a06 1c70 d5f4 aa50 E..J..@.:..p...P 0x0010: 425d 8582 e9a8 0019 544e 3ff8 49b6 1969 B]......TN?.I..i 0x0020: 8018 002e aee2 0000 0101 080a 9639 ebea .............9.. 0x0030: 2107 c306 4548 4c4f 2073 6861 7265 2e73 !...EHLO.share.s 0x0040: 6b79 7065 2e6e 6574 0d0a kype.net.. 22:44:33.529821 IP (tos 0x20, ttl 58, id 56314, offset 0, flags [DF], proto: TCP (6), length: 74) share.skype.net.59816 > wattres.watt.com.smtp: P, cksum 0xa732 (correct), 1:23(22) ack 90 win 46 0x0000: 4520 004a dbfa 4000 3a06 1c6f d5f4 aa50 E..J..@.:..o...P 0x0010: 425d 8582 e9a8 0019 544e 3ff8 49b6 1969 B]......TN?.I..i 0x0020: 8018 002e a732 0000 0101 080a 9639 f39a .....2.......9.. 0x0030: 2107 c306 4548 4c4f 2073 6861 7265 2e73 !...EHLO.share.s 0x0040: 6b79 7065 2e6e 6574 0d0a kype.net.. 22:44:49.276106 IP (tos 0x20, ttl 58, id 56315, offset 0, flags [DF], proto: TCP (6), length: 74) share.skype.net.59816 > wattres.watt.com.smtp: P, cksum 0x97d2 (correct), 1:23(22) ack 90 win 46 0x0000: 4520 004a dbfb 4000 3a06 1c6e d5f4 aa50 E..J..@.:..n...P 0x0010: 425d 8582 e9a8 0019 544e 3ff8 49b6 1969 B]......TN?.I..i 0x0020: 8018 002e 97d2 0000 0101 080a 963a 02fa .............:.. 0x0030: 2107 c306 4548 4c4f 2073 6861 7265 2e73 !...EHLO.share.s 0x0040: 6b79 7065 2e6e 6574 0d0a kype.net.. 22:45:20.765784 IP (tos 0x20, ttl 58, id 56316, offset 0, flags [DF], proto: TCP (6), length: 74) share.skype.net.59816 > wattres.watt.com.smtp: P, cksum 0x7912 (correct), 1:23(22) ack 90 win 46 0x0000: 4520 004a dbfc 4000 3a06 1c6d d5f4 aa50 E..J..@.:..m...P 0x0010: 425d 8582 e9a8 0019 544e 3ff8 49b6 1969 B]......TN?.I..i 0x0020: 8018 002e 7912 0000 0101 080a 963a 21ba ....y........:!. 0x0030: 2107 c306 4548 4c4f 2073 6861 7265 2e73 !...EHLO.share.s 0x0040: 6b79 7065 2e6e 6574 0d0a kype.net.. 22:46:23.742617 IP (tos 0x20, ttl 58, id 56317, offset 0, flags [DF], proto: TCP (6), length: 74) share.skype.net.59816 > wattres.watt.com.smtp: P, cksum 0x3b92 (correct), 1:23(22) ack 90 win 46 0x0000: 4520 004a dbfd 4000 3a06 1c6c d5f4 aa50 E..J..@.:..l...P 0x0010: 425d 8582 e9a8 0019 544e 3ff8 49b6 1969 B]......TN?.I..i 0x0020: 8018 002e 3b92 0000 0101 080a 963a 5f3a ....;........:_: 0x0030: 2107 c306 4548 4c4f 2073 6861 7265 2e73 !...EHLO.share.s 0x0040: 6b79 7065 2e6e 6574 0d0a kype.net.. 22:48:23.747790 IP (tos 0x20, ttl 58, id 56318, offset 0, flags [DF], proto: TCP (6), length: 74) share.skype.net.59816 > wattres.watt.com.smtp: P, cksum 0xc661 (correct), 1:23(22) ack 90 win 46 0x0000: 4520 004a dbfe 4000 3a06 1c6b d5f4 aa50 E..J..@.:..k...P 0x0010: 425d 8582 e9a8 0019 544e 3ff8 49b6 1969 B]......TN?.I..i 0x0020: 8018 002e c661 0000 0101 080a 963a d46a .....a.......:.j 0x0030: 2107 c306 4548 4c4f 2073 6861 7265 2e73 !...EHLO.share.s 0x0040: 6b79 7065 2e6e 6574 0d0a kype.net.. 22:49:18.322070 IP (tos 0x20, ttl 58, id 56319, offset 0, flags [DF], proto: TCP (6), length: 52) share.skype.net.59816 > wattres.watt.com.smtp: F, cksum 0xc92d (correct), 23:23(0) ack 90 win 46 0x0000: 4520 0034 dbff 4000 3a06 1c80 d5f4 aa50 E..4..@.:......P 0x0010: 425d 8582 e9a8 0019 544e 400e 49b6 1969 B]......TN@.I..i 0x0020: 8011 002e c92d 0000 0101 080a 963b 09b5 .....-.......;.. 0x0030: 2107 c306 !... -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3" Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices... From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 2 08:06:47 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A0EF16A403 for ; Tue, 2 Jan 2007 08:06:47 +0000 (UTC) (envelope-from steve@Watt.COM) Received: from wattres.watt.com (wattres.watt.com [66.93.133.130]) by mx1.freebsd.org (Postfix) with ESMTP id 6F74313C448 for ; Tue, 2 Jan 2007 08:06:47 +0000 (UTC) (envelope-from steve@Watt.COM) Received: from wattres.watt.com (localhost.watt.com [127.0.0.1]) by wattres.watt.com (8.13.8/8.13.8) with ESMTP id l0286jWc034038; Tue, 2 Jan 2007 00:06:45 -0800 (PST) (envelope-from steve@wattres.watt.com) Received: (from steve@localhost) by wattres.watt.com (8.13.8/8.13.8/Submit) id l0286jjg034037; Tue, 2 Jan 2007 00:06:45 -0800 (PST) (envelope-from steve) Message-Id: <200701020806.l0286jjg034037@wattres.watt.com> From: steve@Watt.COM (Steve Watt) Date: Tue, 2 Jan 2007 00:06:45 -0800 In-Reply-To: Julian Elischer "Re: Interesting TCP issue" (Jan 1, 23:56) X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Julian Elischer X-Archived: 1167725205.585563546@wattres.Watt.COM Cc: hackers@freebsd.org Subject: Re: Interesting TCP issue 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, 02 Jan 2007 08:06:47 -0000 On Jan 1, 23:56, Julian Elischer wrote: } Subject: Re: Interesting TCP issue } Steve Watt wrote: } > One of my users is having trouble receiving mail from Skype. So, } > after some sniffing, I discovered this: } > } > # tcpdump -vv -s 1500 -i dc0 -X net 213.244.128.0/18 } > tcpdump: lestening on dc0, link-type EN10MB (Ethernet), capture size 1500 bytes } > 13:18:13.607493 IP (tos 0x20, ttl 58, id 12896, offset 0, flags [DF], proto: TCP (6), length: 74) share.skype.net.50406 > wattres.watt.com.smtp: P, cksum 0x9297 (correct), 4072464914:4072464936(22) ack 1248591103 win 46 [ sneck ] } > } > And no responses from my system. } > } > Interesting. I presume it has something to do with the } > idiotically small window the remote server is advertising. So I } > set net.inet.tcp.minmss down to 46, and that resulted in a RST } > being spit back to skype's server when its retransmit happened. } > [...] } } turn off window scaling (I forget the sysctl) and see if that helps } It's broken in some versions of freeBSD at least. Duh, should've mentioned the version: FreeBSD wattres.Watt.COM 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #6: Tue Dec 26 11:46:36 PST 2006 root@wattres.Watt.COM:/usr/obj/usr/src/sys/WATTRES i386 I did the cvsup just before the build time above. I just turned off net.inet.tcp.rfc1323; we'll see if that helps on the next polling attempt by skype's server. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3" Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices... From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 2 08:07:17 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0DEF916A492 for ; Tue, 2 Jan 2007 08:07:17 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outV.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id E0B8713C458 for ; Tue, 2 Jan 2007 08:07:16 +0000 (UTC) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Mon, 01 Jan 2007 23:39:25 -0800 Received: from [192.168.2.4] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id l027uw5p054803; Mon, 1 Jan 2007 23:56:59 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <459A104A.2000106@elischer.org> Date: Mon, 01 Jan 2007 23:56:58 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Steve Watt References: <200701012136.l01Lawp7017696@wattres.watt.com> In-Reply-To: <200701012136.l01Lawp7017696@wattres.watt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: Interesting TCP issue 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, 02 Jan 2007 08:07:17 -0000 Steve Watt wrote: > One of my users is having trouble receiving mail from Skype. So, > after some sniffing, I discovered this: > > # tcpdump -vv -s 1500 -i dc0 -X net 213.244.128.0/18 > tcpdump: lestening on dc0, link-type EN10MB (Ethernet), capture size 1500 bytes > 13:18:13.607493 IP (tos 0x20, ttl 58, id 12896, offset 0, flags [DF], proto: TCP (6), length: 74) share.skype.net.50406 > wattres.watt.com.smtp: P, cksum 0x9297 (correct), 4072464914:4072464936(22) ack 1248591103 win 46 > 0x0000: 4520 004a 3260 4000 3a06 c609 d5f4 aa50 E..J2`@.:......P > 0x0010: 425d 8582 c4e6 0019 f2bc e212 4a6b fcff B]..........Jk.. > 0x0020: 8018 002e 9297 0000 0101 080a 95b8 5568 ..............Uh > 0x0030: 1eff 784a 4548 4c4f 2073 6861 7265 2e73 ..xJEHLO.share.s > 0x0040: 6b79 7065 2e6e 6574 0d0a kype.net.. > 0x0000: 4520 004a 3261 4000 3a06 c608 d5f4 aa50 E..J2a@.:......P > 0x0010: 425d 8582 c4e6 0019 f2bc e212 4a6b fcff B]..........Jk.. > 0x0020: 8018 002e 1d67 0000 0101 080a 95b8 ca98 .....g.......... > 0x0030: 1eff 784a 4548 4c4f 2073 6861 7265 2e73 ..xJEHLO.share.s > 0x0040: 6b79 7065 2e6e 6574 0d0a kype.net.. > > And no responses from my system. > > Interesting. I presume it has something to do with the > idiotically small window the remote server is advertising. So I > set net.inet.tcp.minmss down to 46, and that resulted in a RST > being spit back to skype's server when its retransmit happened. > [...] turn off window scaling (I forget the sysctl) and see if that helps It's broken in some versions of freeBSD at least. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 2 08:25:27 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B897216A47B for ; Tue, 2 Jan 2007 08:25:27 +0000 (UTC) (envelope-from steve@Watt.COM) Received: from wattres.watt.com (wattres.watt.com [66.93.133.130]) by mx1.freebsd.org (Postfix) with ESMTP id 95F3313C45A for ; Tue, 2 Jan 2007 08:25:24 +0000 (UTC) (envelope-from steve@Watt.COM) Received: from wattres.watt.com (localhost.watt.com [127.0.0.1]) by wattres.watt.com (8.13.8/8.13.8) with ESMTP id l028PMh6034572; Tue, 2 Jan 2007 00:25:22 -0800 (PST) (envelope-from steve@wattres.watt.com) Received: (from steve@localhost) by wattres.watt.com (8.13.8/8.13.8/Submit) id l028PMBK034571; Tue, 2 Jan 2007 00:25:22 -0800 (PST) (envelope-from steve) Message-Id: <200701020825.l028PMBK034571@wattres.watt.com> From: steve@Watt.COM (Steve Watt) Date: Tue, 2 Jan 2007 00:25:22 -0800 In-Reply-To: steve@wattres.Watt.COM (Steve Watt) "Re: Interesting TCP issue" (Jan 2, 0:06) X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Julian Elischer X-Archived: 1167726322.557620151@wattres.Watt.COM Cc: hackers@freebsd.org Subject: Re: Interesting TCP issue 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, 02 Jan 2007 08:25:27 -0000 On Jan 2, 0:06, Steve Watt wrote: } Subject: Re: Interesting TCP issue } On Jan 1, 23:56, Julian Elischer wrote: } } Subject: Re: Interesting TCP issue } } Steve Watt wrote: } } > One of my users is having trouble receiving mail from Skype. So, } } > after some sniffing, I discovered this: } } > } } > # tcpdump -vv -s 1500 -i dc0 -X net 213.244.128.0/18 } } > tcpdump: lestening on dc0, link-type EN10MB (Ethernet), capture size 1500 bytes } } > 13:18:13.607493 IP (tos 0x20, ttl 58, id 12896, offset 0, flags [DF], proto: TCP (6), length: 74) share.skype.net.50406 > wattres.watt.com.smtp: P, cksum 0x9297 (correct), 4072464914:4072464936(22) ack 1248591103 win 46 } [ sneck ] } } > } } > And no responses from my system. } } > } } > Interesting. I presume it has something to do with the } } > idiotically small window the remote server is advertising. So I } } > set net.inet.tcp.minmss down to 46, and that resulted in a RST } } > being spit back to skype's server when its retransmit happened. } } > [...] } } } } turn off window scaling (I forget the sysctl) and see if that helps } } It's broken in some versions of freeBSD at least. } } Duh, should've mentioned the version: } } FreeBSD wattres.Watt.COM 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #6: Tue Dec 26 11:46:36 PST 2006 root@wattres.Watt.COM:/usr/obj/usr/src/sys/WATTRES i386 } } I did the cvsup just before the build time above. } } I just turned off net.inet.tcp.rfc1323; we'll see if that helps on the } next polling attempt by skype's server. We have a winner -- setting net.inet.tcp.rfc1323=0 let the mail message come in on the next try. p0f's guess at the remote machine is that it's a newer Linux 2.6 box; that doesn't seem like an interoperability problem that should've slipped through -BETA, given how common those are... The exchange with rfc1323 looks completely normal, with the remote end giving windows of 5840. But it ended the conversation in a very Windows way by sending a couple of RSTs after the FIN exchange. Or has that brokenness now extended itself to Linux as well? -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3" Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices... From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 2 10:26:34 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 15A6116A40F for ; Tue, 2 Jan 2007 10:26:34 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c58-107-94-118.belrs4.nsw.optusnet.com.au [58.107.94.118]) by mx1.freebsd.org (Postfix) with ESMTP id 945DD13C44B for ; Tue, 2 Jan 2007 10:26:33 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id l029kcri001658; Tue, 2 Jan 2007 20:46:38 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id l029kcY2001657; Tue, 2 Jan 2007 20:46:38 +1100 (EST) (envelope-from peter) Date: Tue, 2 Jan 2007 20:46:38 +1100 From: Peter Jeremy To: Vulpes Velox Message-ID: <20070102094637.GA836@turion.vk2pj.dyndns.org> References: <20070101233525.0b10a1e2@vixen42> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: <20070101233525.0b10a1e2@vixen42> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-hackers@freebsd.org Subject: Re: getgroups and getgrouplist functions 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, 02 Jan 2007 10:26:34 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 2007-Jan-01 23:35:25 -0600, Vulpes Velox wrote: >I am reading it as int *ngroups is not set to the number of groups in >the list if the number of groups is larger than the number specified. I read getgrouplist(3) as stating that it will always return the actual number of groups via ngroups. The code in RELENG_6 actually returns the number of groups that are returned via groups - which is never be greater than was passed in. I believe that the manpage does not match the implementation but I am not certain which is correct. >convinced this is a load of bull. And the proper way to get the >number of groups some one is in is to call getgroups(0). At least in RELENG_6, getgroups(2) states that passing the first argument as 0 will return the number of groups: getgroups(0, NULL); This matches the code in the kernel. --=20 Peter Jeremy --DocE+STaALJfprDB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFmin9/opHv/APuIcRAkRWAKCn/UggfIdmlArDxGjI1Rw1/XlppACgr1zg Tejf79n+FZspPg5Xb7gqeLs= =zyOa -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 2 11:08:42 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CB1F16A40F for ; Tue, 2 Jan 2007 11:08:42 +0000 (UTC) (envelope-from anandhkrishnan@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.224]) by mx1.freebsd.org (Postfix) with ESMTP id C891013C45A for ; Tue, 2 Jan 2007 11:08:41 +0000 (UTC) (envelope-from anandhkrishnan@gmail.com) Received: by wr-out-0506.google.com with SMTP id 55so1805193wri for ; Tue, 02 Jan 2007 03:08:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=IvS5LbFGsSjyVTKznjkrHxiVRmK2N3LAmNBKImBONp54CMrPpYrfV5wF5r2E/XgVZowjTZuE6dbamDtZwZDWdQfh4RmIRs6IhvNZaiINvTy8ileNvyhv/HerOELCDxqelR/+tmVwGzyhc44TgoGGcreOgCWVf6mDqibwXaYo/hM= Received: by 10.90.113.18 with SMTP id l18mr14244941agc.1167734554715; Tue, 02 Jan 2007 02:42:34 -0800 (PST) Received: by 10.90.74.4 with HTTP; Tue, 2 Jan 2007 02:42:34 -0800 (PST) Message-ID: <9bf098930701020242t232a1131r355c693618169441@mail.gmail.com> Date: Tue, 2 Jan 2007 16:12:34 +0530 From: "Anand H. Krishnan" To: hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Doubts with scheduler code 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, 02 Jan 2007 11:08:42 -0000 Hi, I had a couple of doubts when I was going through 6.1 freebsd code. * First one is in the wakeup() code. After a series of calls wakeup() lands in maybe_preempt() and if preemption is enabled maybe_preempt() switches to a new thread (if a high priority thread has been made runnable). That means that an interrupt handler which calls wakeup() will not return immediately. (I'm looking @ ULE scheduler). So is there a problem when wakeup() is called from high priority (fast interr upt) handlers ? * Second one is in spinlock code. Can anyone say why critical_enter is called from spinlock_enter() ? The only thing that critical_enter seems to be doing is to increment td_critnest which probably helps in finding out whether a thread can be pre-empted or not. But spinlock_enter() disables interrupts and I fail to understand how can any thread become runnable and get scheduled in between. I've one more.. * msleep() allows a thread to change it's priority when it gets woken up and in many places they gets woken up with very high priority indeed. Is there any convincing reason as to why it should be ? Thanks, Anand From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 2 12:31:20 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 70CB516A403 for ; Tue, 2 Jan 2007 12:31:20 +0000 (UTC) (envelope-from sharadc@niksun.com) Received: from in.niksun.com (210.18.76.166.sify.net [210.18.76.166]) by mx1.freebsd.org (Postfix) with ESMTP id 121A013C448 for ; Tue, 2 Jan 2007 12:31:20 +0000 (UTC) (envelope-from sharadc@niksun.com) Received: from sharadc.niksun.com (unknown [10.60.5.27]) by in.niksun.com (Postfix) with ESMTP id B03EB5C85 for ; Tue, 2 Jan 2007 17:43:47 +0530 (IST) From: Sharad Chandra Organization: Niksun India To: freebsd-hackers@freebsd.org Date: Tue, 2 Jan 2007 17:40:31 +0530 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701021740.32110.sharadc@niksun.com> Subject: Get IP from ttyname(3) 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, 02 Jan 2007 12:31:20 -0000 Hi all, I was reading man page of ttyname(3). I thought if i have ttyname then using that can i have IP address of connected host?. like in sshd logs on log file like. ... sshd[]: Accepted keyboard-interactive/pam for from port ssh2 This IP here is connected hosts ip.. is there any api..? Thanks Sharad From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 2 14:32:56 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8EEFA16A412 for ; Tue, 2 Jan 2007 14:32:56 +0000 (UTC) (envelope-from thinker@branda.to) Received: from msr26.hinet.net (msr26.hinet.net [168.95.4.126]) by mx1.freebsd.org (Postfix) with ESMTP id 40FAE13C45A for ; Tue, 2 Jan 2007 14:32:55 +0000 (UTC) (envelope-from thinker@branda.to) Received: from [192.168.1.39] (220-139-94-134.dynamic.hinet.net [220.139.94.134]) by msr26.hinet.net (8.9.3/8.9.3) with ESMTP id WAA09578; Tue, 2 Jan 2007 22:21:57 +0800 (CST) Message-ID: <459A6A23.1040800@branda.to> Date: Tue, 02 Jan 2007 22:20:19 +0800 From: Thinker User-Agent: Thunderbird 1.5.0.8 (X11/20061228) MIME-Version: 1.0 To: Sharad Chandra References: <200701021740.32110.sharadc@niksun.com> In-Reply-To: <200701021740.32110.sharadc@niksun.com> X-Enigmail-Version: 0.94.1.0 OpenPGP: url=http://heaven.branda.to/~thinker/GinGin_CGI.py/get_afile/1/thinker-pgp.asc Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Get IP from ttyname(3) 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, 02 Jan 2007 14:32:56 -0000 Sharad Chandra wrote: > Hi all, I was reading man page of ttyname(3). I thought if i have > ttyname then using that can i have IP address of connected host?. > like in sshd logs on log file like. You can read login informations from utmp(8). /var/run/utmp is a array of utmp(8). please check man page for more information. -- Thinker Li - thinker@branda.to thinker.li@gmail.com http://heaven.branda.to/~thinker/GinGin_CGI.py From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 2 20:39:53 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6EC6E16A403 for ; Tue, 2 Jan 2007 20:39:53 +0000 (UTC) (envelope-from zombyfork@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.236]) by mx1.freebsd.org (Postfix) with ESMTP id 3173513C43E for ; Tue, 2 Jan 2007 20:39:53 +0000 (UTC) (envelope-from zombyfork@gmail.com) Received: by wr-out-0506.google.com with SMTP id 55so1918774wri for ; Tue, 02 Jan 2007 12:39:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=N3AsilENK8lxYGQ7Ef0XzAhNhcB4oi3+amB1vbHkM7cXiahOIUxmSV1+UbK2eIe/9TkbF9KbH6vvX2hf1G5HOYFEbI1bh/5J0ijFnudsXqAKn3/aouaJGcf8ZHBXH5jOPBwCBiaUlOgZCV84530DTa7ic7M8cqwm9JXHM0+Ox7U= Received: by 10.90.94.2 with SMTP id r2mr5535481agb.1167768915911; Tue, 02 Jan 2007 12:15:15 -0800 (PST) Received: by 10.90.101.15 with HTTP; Tue, 2 Jan 2007 12:15:15 -0800 (PST) Message-ID: <346a80220701021215h91ea76dr5a32b6ebe5bb1362@mail.gmail.com> Date: Tue, 2 Jan 2007 13:15:15 -0700 From: "Coleman Kane" To: "Anand H. Krishnan" In-Reply-To: <9bf098930701020242t232a1131r355c693618169441@mail.gmail.com> MIME-Version: 1.0 References: <9bf098930701020242t232a1131r355c693618169441@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: hackers@freebsd.org Subject: Re: Doubts with scheduler code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cokane@cokane.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2007 20:39:53 -0000 On 1/2/07, Anand H. Krishnan wrote: > > Hi, > > I had a couple of doubts when I was going through 6.1 freebsd code. > > * First one is in the wakeup() code. After a series of calls wakeup() > lands in maybe_preempt() and if preemption is enabled maybe_preempt() > switches to a new thread (if a high priority thread has been made > runnable). > That means that an interrupt handler which calls wakeup() will not return > immediately. (I'm looking @ ULE scheduler). > > So is there a problem when wakeup() is called from high priority (fast > interr > upt) handlers ? > > * Second one is in spinlock code. Can anyone say why critical_enter is > called from spinlock_enter() ? The only thing that critical_enter seems to > be doing is to increment td_critnest which probably helps in finding out > whether a thread can be pre-empted or not. But spinlock_enter() disables > interrupts and I fail to understand how can any thread become runnable > and get scheduled in between. > > I've one more.. > > * msleep() allows a thread to change it's priority when it gets woken up > and > in many places they gets woken up with very high priority indeed. Is there > any convincing reason as to why it should be ? > > Thanks, > Anand Anand, If I remember correctly a significant amount of the ULE scheduler code from 6.1 (and 7-CUR at that time) has been overhauled. In fact, the scheduler was taken off the list of "working" due to a bunch of problems. You may want to review the versions of the scheduler code from the latest -CURRENT or 6.2-RELEASE and then re-ask... -- Coleman Kane From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 2 20:52:33 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9116E16A416 for ; Tue, 2 Jan 2007 20:52:33 +0000 (UTC) (envelope-from SRS0=5nRf5r=GL=vvelox.net=v.velox@yourhostingaccount.com) Received: from mailout20.yourhostingaccount.com (mailout20.yourhostingaccount.com [65.254.253.166]) by mx1.freebsd.org (Postfix) with ESMTP id 5226913C457 for ; Tue, 2 Jan 2007 20:52:33 +0000 (UTC) (envelope-from SRS0=5nRf5r=GL=vvelox.net=v.velox@yourhostingaccount.com) Received: from scan04.yourhostingaccount.com ([10.1.1.234] helo=scan04.yourhostingaccount.com) by mailout20.yourhostingaccount.com with esmtp (Exim) id 1H1qca-0008Rz-8G for freebsd-hackers@freebsd.org; Tue, 02 Jan 2007 15:52:32 -0500 Received: from authsmtp10.yourhostingaccount.com ([10.1.18.10] ident=exim) by scan04.yourhostingaccount.com with spamscanlookuphost (Exim) id 1H1qca-00089M-2p for freebsd-hackers@freebsd.org; Tue, 02 Jan 2007 15:52:32 -0500 Received: from authsmtp10.yourhostingaccount.com ([10.1.18.10] helo=authsmtp10.yourhostingaccount.com) by scan04.yourhostingaccount.com with esmtp (Exim) id 1H1qcZ-00089G-Ng for freebsd-hackers@freebsd.org; Tue, 02 Jan 2007 15:52:31 -0500 Received: from [69.92.217.33] (helo=vixen42) by authsmtp10.yourhostingaccount.com with esmtpa (Exim) id 1H1qcZ-0006Lx-7O; Tue, 02 Jan 2007 15:52:31 -0500 Date: Tue, 2 Jan 2007 14:53:36 -0600 From: Vulpes Velox To: Peter Jeremy Message-ID: <20070102145336.462e5700@vixen42> In-Reply-To: <20070102094637.GA836@turion.vk2pj.dyndns.org> References: <20070101233525.0b10a1e2@vixen42> <20070102094637.GA836@turion.vk2pj.dyndns.org> X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.10.6; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EN-UserInfo: 0d1ca1697cdb7a831d4877828571b7ab:1570f0de6936c69fef9e164fffc541bc X-EN-AuthUser: vvelox2 Sender: Vulpes Velox Cc: freebsd-hackers@freebsd.org Subject: Re: getgroups and getgrouplist functions 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, 02 Jan 2007 20:52:33 -0000 On Tue, 2 Jan 2007 20:46:38 +1100 Peter Jeremy wrote: > On Mon, 2007-Jan-01 23:35:25 -0600, Vulpes Velox wrote: > >I am reading it as int *ngroups is not set to the number of groups > >in the list if the number of groups is larger than the number > >specified. > > I read getgrouplist(3) as stating that it will always return the > actual number of groups via ngroups. The code in RELENG_6 actually > returns the number of groups that are returned via groups - which is > never be greater than was passed in. I believe that the manpage > does not match the implementation but I am not certain which is > correct. I am not reading at always in this case. The man pages for other systems do specify always, but a bit iffy here. From testing it appears it is not set and ngroups is left alone if it is to small. I found it is set to the number if that number is less than the initial ngroups value. So far I know NetBSD, glibc, and what ever Mac uses makes the change. I am lost on if this is a bug or if FreeBSD is not following some standard in regards to this. > >convinced this is a load of bull. And the proper way to get the > >number of groups some one is in is to call getgroups(0). > > At least in RELENG_6, getgroups(2) states that passing the first > argument as 0 will return the number of groups: getgroups(0, NULL); > This matches the code in the kernel. Yeah. The patch I made for DBus last uses this upon failing the first time. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 2 21:40:31 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F5C516A40F for ; Tue, 2 Jan 2007 21:40:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outR.internet-mail-service.net (outR.internet-mail-service.net [216.240.47.241]) by mx1.freebsd.org (Postfix) with ESMTP id F1FAA13C455 for ; Tue, 2 Jan 2007 21:40:30 +0000 (UTC) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 02 Jan 2007 13:22:50 -0800 Received: from [10.251.18.229] (nat.ironport.com [63.251.108.100]) by idiom.com (8.12.11/8.12.11) with ESMTP id l02LeSNi071132; Tue, 2 Jan 2007 13:40:28 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <459AD141.5010502@elischer.org> Date: Tue, 02 Jan 2007 13:40:17 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Steve Watt References: <200701020825.l028PMBK034571@wattres.watt.com> In-Reply-To: <200701020825.l028PMBK034571@wattres.watt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org, Andre Oppermann Subject: Re: Interesting TCP issue 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, 02 Jan 2007 21:40:31 -0000 Steve Watt wrote: > On Jan 2, 0:06, Steve Watt wrote: > } Subject: Re: Interesting TCP issue > } On Jan 1, 23:56, Julian Elischer wrote: > } } Subject: Re: Interesting TCP issue > } } Steve Watt wrote: > } } > One of my users is having trouble receiving mail from Skype. So, > } } > after some sniffing, I discovered this: > } } > > } } > # tcpdump -vv -s 1500 -i dc0 -X net 213.244.128.0/18 > } } > tcpdump: lestening on dc0, link-type EN10MB (Ethernet), capture size 1500 bytes > } } > 13:18:13.607493 IP (tos 0x20, ttl 58, id 12896, offset 0, flags [DF], proto: TCP (6), length: 74) share.skype.net.50406 > wattres.watt.com.smtp: P, cksum 0x9297 (correct), 4072464914:4072464936(22) ack 1248591103 win 46 > } [ sneck ] > } } > > } } > And no responses from my system. > } } > > } } > Interesting. I presume it has something to do with the > } } > idiotically small window the remote server is advertising. So I > } } > set net.inet.tcp.minmss down to 46, and that resulted in a RST > } } > being spit back to skype's server when its retransmit happened. > } } > [...] > } } > } } turn off window scaling (I forget the sysctl) and see if that helps > } } It's broken in some versions of freeBSD at least. > } > } Duh, should've mentioned the version: > } > } FreeBSD wattres.Watt.COM 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #6: Tue Dec 26 11:46:36 PST 2006 root@wattres.Watt.COM:/usr/obj/usr/src/sys/WATTRES i386 > } > } I did the cvsup just before the build time above. > } > } I just turned off net.inet.tcp.rfc1323; we'll see if that helps on the > } next polling attempt by skype's server. > > We have a winner -- setting net.inet.tcp.rfc1323=0 let the mail message > come in on the next try. > > p0f's guess at the remote machine is that it's a newer Linux 2.6 box; > that doesn't seem like an interoperability problem that should've > slipped through -BETA, given how common those are... > > The exchange with rfc1323 looks completely normal, with the remote end > giving windows of 5840. But it ended the conversation in a very Windows > way by sending a couple of RSTs after the FIN exchange. Or has that > brokenness now extended itself to Linux as well? we have seen this since 4.x I think a fix may be in 7.0 but I'm not sure.. I thin kthere is a problem when the far end sets the window down to 1 but scales it by a factor of 2^{big number}. the FreeBSD tcp code aparently scales the wrong variable leading it to ahve a 1 byte window. Andre, can you check out this problem and MFC the correct fix if it is indeed the same problem in 6.2? I enclose part of our trouble ticket info. on the topic. ---------------------- Problem Description ----------------------- The TCP window scaling (rfc 1323) implementation of FreeBSD is broken such that we initially under-estimate the TCP receive window size of the remote server. Depending on the scaling options requested by the remote server, this can cause us to send our SMTP banner spanning more than a single TCP packet. In at least one customer case, the remote MTA doesn't like what appears to be a truncated SMTP banner and immediately RST's the connection (instead of ACK'ing the first packet and receiving the rest of the banner in the next packet). The fact that the remote server won't accept our SMTP banner in more than one packet is a problem on their end. But the fact that we break up the banner in the first place is due to a bug in FreeBSD related to TCP window scaling. See AE ticket # 78590. here's what happens: - In the originating TCP SYN packet, the remote side says "we want to use a window scaling factor of 9" (ie: multiply their TCP window size values by 2**9=512 to calculate the real window size they are able to accept.) - We ACK this SYN, saying that we support their scaling request, but we don't need any window scaling done. (We send TCP option window scale = 0. nothing wrong here yet) - They send us an ACK with a window size of 12 (by which they really mean 12*512=6144) - We seem to forget about the scaling and think they can only handle a 12 byte TCP window, so we send only the first 12 bytes of our SMTP banner in the first packet. - We intend to send the rest of the banner when they ACK the previous packet, but they are too impatient and hang up the phone without ACK'ing our partial banner so we can send the rest. This problem likely affects all cases in which window scaling is requested in the TCP options, but is usually not noticed because it just causes us to send smaller packets than we could. In most instances, this only affects theoretical peak throughtput (since we could conceivably be sending more data before requiring an ACK) a possible workaround is to use 'sysctl' to completely disable our support for rfc1323. for example, snooper:service 37] sysctl net.inet.tcp.rfc1323=0 net.inet.tcp.rfc1323: 1 -> 0 This SHOULD cause us to not repond to the TCP window scaling option at all, thus telling the remote server that we are not supporting it (which is better than saying we do support it, then getting it wrong). Pending customer feedback to see if this workaround addresses the issue, then we might make the change permanent in /etc/sysctl.conf. Also pending information about what MTA software and OS is running on the remote server. Evan did a little digging and noticed that TCP window scaling implementation is just being addressed in FreeBSD HEAD. see: http://cvs.ironport.com/cgi-bin/viewcvs.cgi/freebsd/src/sys/netinet/tcp_syncache.c.diff?r1=1.84&r2=1.85 It could well be that window scaling works fine AFTER the initial connection is made, but in at least this one case, it is affecting customer's ability to receive email from certain domains... We have info on reproducing the problem by crafting TCP SYN packets with window scaling options. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 2 23:47:30 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B19A216A407 for ; Tue, 2 Jan 2007 23:47:30 +0000 (UTC) (envelope-from admin@intron.ac) Received: from intron.ac (unknown [210.51.165.237]) by mx1.freebsd.org (Postfix) with ESMTP id 4928713C441 for ; Tue, 2 Jan 2007 23:47:30 +0000 (UTC) (envelope-from admin@intron.ac) Received: from localhost (localhost [127.0.0.1]) (uid 1003) by intron.ac with local; Wed, 03 Jan 2007 07:47:28 +0800 id 0011F803.459AEF10.00006EA6 From: "Intron is my alias on the Internet" To: freebsd-hackers@freebsd.org Date: Wed, 03 Jan 2007 07:47:28 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-ID: X-Mailman-Approved-At: Wed, 03 Jan 2007 00:41:04 +0000 Subject: Partially Unbreak Adobe Reader 7.0.8 for the New Linux Emulator 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, 02 Jan 2007 23:47:30 -0000 My patch for /sys/compat/linux/linux_file.c (7.0-CURRENT) can partially unbreak Adobe Reader 7.0.8 for Linux when the sysctl compat.linux.osrelease is set to "2.6.16". You may download the patch at: http://ftp.intron.ac/tmp/linux_file.c.diff But probably to your disappointment, the problem hasn't been completely solved yet. Even after you have applied my patch (Don't forget to set compat.linux.osrelease to "2.6.16"), you must remove the directory ~/.adobe before you start Adobe Reader 7.0.8 every time, otherwise the PDF file cannot be properly browsed. I have noticed that the calling behavior against the Linux system call mmap2(2) is strange: 1658: linux_mmap2(0x0,0x8974,0x1,0x1,0x0,0x6) = 790032384 (0x2f16f000) 1658: linux_mmap2(0x0,0x8fd8,0x1,0x1,0x0,0x6) = 790032384 (0x2f16f000) 1658: linux_mmap2(0x0,0x8974,0x1,0x1,0x0,0x6) = 790032384 (0x2f16f000) 1658: linux_mmap2(0x0,0x1000,0x3,0x22,0xffffffff,0x6) = 790069248 (0x2f178000) 1658: linux_mmap2(0x0,0x1000,0x3,0x22,0xffffffff,0x6) = 790069248 (0x2f178000) 1658: linux_mmap2(0x0,0x8fd8,0x1,0x1,0x0,0x6) = 790032384 (0x2f16f000) 1658: linux_mmap2(0x0,0x8974,0x1,0x1,0x0,0x6) = 790032384 (0x2f16f000) 1658: linux_mmap2(0x0,0x8a78,0x1,0x1,0x0,0x6) = 790032384 (0x2f16f000) 1658: linux_mmap2(0x0,0x8974,0x1,0x1,0x0,0x6) = 790032384 (0x2f16f000) The last calling argument is always stupid 6, which doesn't agree with the calling behavior against mmap(2) when compat.linux.osrelease is set to 2.4.2. This probably means that all files mapped by mmap2(2) cannot be properly read from memory space. Screenshots: Normal cases: 1. FreeBSD Handbook, Chinese version: (This PDF file is much more complicated than the English one) http://ftp.intron.ac/tmp/adobereader-20070103-1.png 2. The manual page ls(1), produced by groff(1) + GhostScript: http://ftp.intron.ac/tmp/adobereader-20070103-2.png Abnormal case: Failed to remove ~/.adobe http://ftp.intron.ac/tmp/adobereader-20070103-3.png ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 3 10:06:52 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A9A016A403 for ; Wed, 3 Jan 2007 10:06:52 +0000 (UTC) (envelope-from erik.udo@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.228]) by mx1.freebsd.org (Postfix) with ESMTP id 1D22313C428 for ; Wed, 3 Jan 2007 10:06:51 +0000 (UTC) (envelope-from erik.udo@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so2702427nzh for ; Wed, 03 Jan 2007 02:06:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ug2DJAZ2+inW2Pq5YgTZr5KzkJ7ufitjUkGpwvH7wEG3d5UbblERENgbnRJR3whhXSrKY1hRvf05sR1SbiboicFeiLtWsWF+dIN2oV8sgkc0umJq0oAqGkffLN7Qpv+HD1qqcZxWum7ODy2JqqI+47L2Anv01Lc+vTjfKFLUUzI= Received: by 10.65.180.7 with SMTP id h7mr27687103qbp.1167818811512; Wed, 03 Jan 2007 02:06:51 -0800 (PST) Received: by 10.65.132.14 with HTTP; Wed, 3 Jan 2007 02:06:51 -0800 (PST) Message-ID: <6e3d78920701030206he4dd6e7h41445b0275fde50d@mail.gmail.com> Date: Wed, 3 Jan 2007 12:06:51 +0200 From: "Erik Udo" To: freebsd-hackers@freebsd.org In-Reply-To: <6e3d78920701030151o3bcbf129yeff694d9f064985f@mail.gmail.com> MIME-Version: 1.0 References: <4592C91C.2040801@gmail.com> <6e3d78920701030151o3bcbf129yeff694d9f064985f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Init.c, making it chroot 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, 03 Jan 2007 10:06:52 -0000 Nah, forget that patch, it's missing alot of stuff. On 1/3/07, Erik Udo wrote: > > I just made patch. It's supposed to run /etc/rc before chrooting. This is > the NetBSD "way" of doing it. All i can say is that it compiled. So if > anyone can look at it before i get to test it becouse i might be forgetting > something. (i can't even test it now) > > diff attached. > > On 12/27/06, Erik Udo < erik.udo@gmail.com> wrote: > > > > How can i make init chroot after executing /etc/rc, and executing > > /etc/rc again in the chrooted enviroment? > > > > For this to work, i'd like to know at what point do i call chroot(), > > becouse init.c uses fork() at the point where it runs the rc script. > > > > The thing is, i want to run a whole system in a chrooted enviroment in > > this livecd i'm making. But the command "chroot /mnt/root /etc/rc" > > returns after the /etc/rc has been run, dropping me back from the > > chrooted enviroment. And if it doesn't, init never starts the multiuser > > mode. > > > > So how can i go to the multiuser mode in a chrooted enviroment? I guess > > the only way to do that is to modify init.c > > > > Any help/feedback is appreciated. > > > > Cheers, Erik > > > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org > > " > > > > > From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 3 10:19:25 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AC70A16A415 for ; Wed, 3 Jan 2007 10:19:25 +0000 (UTC) (envelope-from erik.udo@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.228]) by mx1.freebsd.org (Postfix) with ESMTP id 6D3BF13C441 for ; Wed, 3 Jan 2007 10:19:25 +0000 (UTC) (envelope-from erik.udo@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so2704381nzh for ; Wed, 03 Jan 2007 02:19:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=HqvakdtrvUBz0LDbKXxdnqJC/MOisJ59wxdTDkAt+b8LyD0W0SsDdkdbLAlOJAul5R9/bpB3xKRiFIf7YsD5UvyZAboDsPv431up2ndm+CRfJBuLMMql8/3L1QOtiXFfYFOmLG7iB7MSN2NW5vwr+g8bKq4/O12ftxCh4zW8WH0= Received: by 10.64.243.15 with SMTP id q15mr27636627qbh.1167817883288; Wed, 03 Jan 2007 01:51:23 -0800 (PST) Received: by 10.65.132.14 with HTTP; Wed, 3 Jan 2007 01:51:22 -0800 (PST) Message-ID: <6e3d78920701030151o3bcbf129yeff694d9f064985f@mail.gmail.com> Date: Wed, 3 Jan 2007 11:51:22 +0200 From: "Erik Udo" To: freebsd-hackers@freebsd.org In-Reply-To: <4592C91C.2040801@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_120572_3556868.1167817882653" References: <4592C91C.2040801@gmail.com> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Init.c, making it chroot 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, 03 Jan 2007 10:19:25 -0000 ------=_Part_120572_3556868.1167817882653 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I just made patch. It's supposed to run /etc/rc before chrooting. This is the NetBSD "way" of doing it. All i can say is that it compiled. So if anyone can look at it before i get to test it becouse i might be forgetting something. (i can't even test it now) diff attached. On 12/27/06, Erik Udo wrote: > > How can i make init chroot after executing /etc/rc, and executing > /etc/rc again in the chrooted enviroment? > > For this to work, i'd like to know at what point do i call chroot(), > becouse init.c uses fork() at the point where it runs the rc script. > > The thing is, i want to run a whole system in a chrooted enviroment in > this livecd i'm making. But the command "chroot /mnt/root /etc/rc" > returns after the /etc/rc has been run, dropping me back from the > chrooted enviroment. And if it doesn't, init never starts the multiuser > mode. > > So how can i go to the multiuser mode in a chrooted enviroment? I guess > the only way to do that is to modify init.c > > Any help/feedback is appreciated. > > Cheers, Erik > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > ------=_Part_120572_3556868.1167817882653 Content-Type: application/octet-stream; name=init.diff Content-Transfer-Encoding: base64 X-Attachment-Id: f_ewhkki9n Content-Disposition: attachment; filename="init.diff" LS0tIGluaXQuYy5vcmlnCVdlZCBKYW4gIDMgMDk6MTc6MzMgMjAwNworKysgaW5pdC5jCVdlZCBK YW4gIDMgMTA6MDg6MzggMjAwNwpAQCAtNjcsNiArNjcsNyBAQAogI2luY2x1ZGUgPHVuaXN0ZC5o PgogI2luY2x1ZGUgPHN5cy9yZWJvb3QuaD4KICNpbmNsdWRlIDxlcnIuaD4KKyNpbmNsdWRlIDxr ZW52Lmg+CiAKICNpbmNsdWRlIDxzdGRhcmcuaD4KIApAQCAtMTE1LDYgKzExNiw3IEBACiAKIHN0 YXRlX2Z1bmNfdCBzaW5nbGVfdXNlcih2b2lkKTsKIHN0YXRlX2Z1bmNfdCBydW5jb20odm9pZCk7 CitzdGF0ZV9mdW5jX3QgcnVuZXRjcmMoaW50IHRyeWNocm9vdCk7CiBzdGF0ZV9mdW5jX3QgcmVh ZF90dHlzKHZvaWQpOwogc3RhdGVfZnVuY190IG11bHRpX3VzZXIodm9pZCk7CiBzdGF0ZV9mdW5j X3QgY2xlYW5fdHR5cyh2b2lkKTsKQEAgLTE3NSwxMiArMTc3LDE3IEBACiAKIHZvaWQgY2xlYXJf c2Vzc2lvbl9sb2dzKHNlc3Npb25fdCAqKTsKIAoraW50IHNob3VsZGNocm9vdCh2b2lkKTsKK2No YXIgaW5pdF9jaHJvb3RbUEFUSF9NQVhdOworaW50IGRpZF9tdWx0aXVzZXJfY2hyb290OworCiBp bnQgc3RhcnRfc2Vzc2lvbl9kYih2b2lkKTsKIHZvaWQgYWRkX3Nlc3Npb24oc2Vzc2lvbl90ICop Owogdm9pZCBkZWxfc2Vzc2lvbihzZXNzaW9uX3QgKik7CiBzZXNzaW9uX3QgKmZpbmRfc2Vzc2lv bihwaWRfdCk7CiBEQiAqc2Vzc2lvbl9kYjsKIAorCiAvKgogICogVGhlIG1vdGhlciBvZiBhbGwg cHJvY2Vzc2VzLgogICovCkBAIC03MTgsNiArNzI1LDM4IEBACiBzdGF0ZV9mdW5jX3QKIHJ1bmNv bSh2b2lkKQogeworCXN0YXRlX2Z1bmNfdCBuZXh0X3N0ZXA7CisKKwkvKiBSdW4gL2V0Yy9yYyBh bmQgY2hvb3NlIG5leHQgc3RhdGUgZGVwZW5kaW5nIG9uIHRoZSByZXN1bHQuICovCisJbmV4dF9z dGVwID0gcnVuZXRjcmMoMCk7CisJaWYgKG5leHRfc3RlcCAhPSAoc3RhdGVfZnVuY190KSByZWFk X3R0eXMpCisJCXJldHVybiAoc3RhdGVfZnVuY190KSBuZXh0X3N0ZXA7CisKKwlpZiAoc2hvdWxk Y2hyb290KCkpIHsKKwkJbmV4dF9zdGVwID0gcnVuZXRjcmMoMSk7CisJCWlmIChuZXh0X3N0ZXAg IT0gKHN0YXRlX2Z1bmNfdCkgcmVhZF90dHlzKQorCQkJcmV0dXJuIChzdGF0ZV9mdW5jX3QpIG5l eHRfc3RlcDsKKworCQlkaWRfbXVsdGl1c2VyX2Nocm9vdCA9IDE7CisJfSBlbHNlIHsKKwkJZGlk X211bHRpdXNlcl9jaHJvb3QgPSAwOworCX0KKworCS8qCisJICogUmVnYXJkbGVzcyBvZiB3aGV0 aGVyIGluIGNocm9vdCBvciBub3QsIHdlIGJvb3RlZCBzdWNjZXNzZnVseS4KKwkgKiBJdCdzIHRp bWUgdG8gc3Bhd24gZ2V0dHlzIChpZS4gbmV4dF9zdGVwJ3MgdmFsdWUgYXQgdGhpcyBwb2ludCku CisJICovCisJcnVuY29tX21vZGUgPSBBVVRPQk9PVDsJCS8qIHRoZSBkZWZhdWx0ICovCisJbG9n d3RtcCgifiIsICJyZWJvb3QiLCAiIik7CisJcmV0dXJuIChzdGF0ZV9mdW5jX3QpIHJlYWRfdHR5 czsKK30KKworLyoKKyAqIFJ1biB0aGUgc3lzdGVtIHN0YXJ0dXAgc2NyaXB0LgorICovCitzdGF0 ZV9mdW5jX3QKK3J1bmV0Y3JjKGludCB0cnljaHJvb3QpCit7CiAJcGlkX3QgcGlkLCB3cGlkOwog CWludCBzdGF0dXM7CiAJY2hhciAqYXJndls0XTsKQEAgLTc0Myw2ICs3ODIsMTIgQEAKIAogCQlz aWdwcm9jbWFzayhTSUdfU0VUTUFTSywgJnNhLnNhX21hc2ssIChzaWdzZXRfdCAqKSAwKTsKIAor CQlpZiAodHJ5Y2hyb290KQorCQkJaWYgKGNocm9vdChpbml0X2Nocm9vdCkgIT0gMCkgeworCQkJ CXdhcm5pbmcoImZhaWxlZCB0byBjaHJvb3QgdG8gYCVzJzogJW0iLAorCQkJCSAgICBpbml0X2No cm9vdCk7CisJCQkJX2V4aXQoMSk7IAkvKiBmb3JjZSBzaW5nbGUgdXNlciBtb2RlICovCisJCQl9 CiAjaWZkZWYgTE9HSU5fQ0FQCiAJCXNldHByb2NyZXNvdXJjZXMoUkVTT1VSQ0VfUkMpOwogI2Vu ZGlmCkBAIC04MDMsOSArODQ4LDYgQEAKIAlpZiAoV0VYSVRTVEFUVVMoc3RhdHVzKSkKIAkJcmV0 dXJuIChzdGF0ZV9mdW5jX3QpIHNpbmdsZV91c2VyOwogCi0JcnVuY29tX21vZGUgPSBBVVRPQk9P VDsJCS8qIHRoZSBkZWZhdWx0ICovCi0JLyogTkI6IHNob3VsZCBzZW5kIGEgbWVzc2FnZSB0byB0 aGUgc2Vzc2lvbiBsb2dnZXIgdG8gYXZvaWQgYmxvY2tpbmcuICovCi0JbG9nd3RtcCgifiIsICJy ZWJvb3QiLCAiIik7CiAJcmV0dXJuIChzdGF0ZV9mdW5jX3QpIHJlYWRfdHR5czsKIH0KIApAQCAt MTYzMywzICsxNjc1LDIyIEBACiAJfQogfQogI2VuZGlmCisKKworaW50IHNob3VsZGNocm9vdCh2 b2lkKSB7CisJY2hhciBpY25hbWVbXSA9ICJpbml0X2Nocm9vdCI7CisJKmluaXRfY2hyb290ID0g J1wwJzsKKworCWlmKGtlbnYoS0VOVl9HRVQsIGljbmFtZSwgaW5pdF9jaHJvb3QsIAorICAgICAg ICAgICBzaXplb2YoaW5pdF9jaHJvb3QpKSA9PSAtMSkgeworCQl3YXJuaW5nKCJDYW4ndCBmZXRj aCBpbml0X2Nocm9vdCBmcm9tIGtlbnYoKTogJW0iKTsKKwkJcmV0dXJuIDA7CisJfQorCisJaWYg KGNoZGlyKGluaXRfY2hyb290KSAhPSAwIHx8IGNocm9vdCgiLiIpICE9IDApIHsKKwkJd2Fybmlu ZygiQ2FuJ3QgY2hyb290IHRvICVzOiAlbSIsIGluaXRfY2hyb290KTsKKwkJcmV0dXJuIDA7CisJ fQorCisJcmV0dXJuIDE7Cit9Cg== ------=_Part_120572_3556868.1167817882653-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 3 11:28:46 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 15D4E16A407 for ; Wed, 3 Jan 2007 11:28:46 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id A831E13C467 for ; Wed, 3 Jan 2007 11:28:45 +0000 (UTC) (envelope-from killing@multiplay.co.uk) X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on core6.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-24.7 required=6.0 tests=BAYES_00, USER_IN_WHITELIST, USER_IN_WHITELIST_TO autolearn=ham version=3.1.5 Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.5.4) with ESMTP id md50003354905.msg for ; Wed, 03 Jan 2007 11:17:00 +0000 Message-ID: <007501c72f28$af27ffe0$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: Date: Wed, 3 Jan 2007 11:16:52 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-Spam-Processed: multiplay.co.uk, Wed, 03 Jan 2007 11:17:00 +0000 X-MDAV-Processed: multiplay.co.uk, Wed, 03 Jan 2007 11:17:01 +0000 Subject: SMP initialisation changes 6.1-PRERELEASE and 6.1-RELEASE? 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, 03 Jan 2007 11:28:46 -0000 Is anyone aware of any significant changes between 6.1-PRERELEASE and 6.1-RELEASE which could cause and SMP kernel to hang when initialising the CPU's? I have a Tyan s2892 based machine here which has been running 6.1-PRELEASE happily for months, I finally got round to updating to 6.1-RELEASE and it now just hangs. I've also tried 6.2-RC2 and the same high happens with that. Also of note is that since updating to the latest BIOS on said machine 2.03 from 2.0 I'm constantly seeing: "calcru: runtime went backwards" messages from all processes including idle. Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 3 09:01:05 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4BBF316A412 for ; Wed, 3 Jan 2007 09:01:05 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id C57C013C44C for ; Wed, 3 Jan 2007 09:01:01 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (aronkd@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l0390mGt077124; Wed, 3 Jan 2007 10:00:54 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l0390mAP077122; Wed, 3 Jan 2007 10:00:48 +0100 (CET) (envelope-from olli) From: Oliver Fromme Message-Id: <200701030900.l0390mAP077122@lurza.secnetix.de> To: imp@bsdimp.com (M. Warner Losh) Date: Wed, 3 Jan 2007 10:00:48 +0100 (CET) In-Reply-To: <20061230.104309.35221148.imp@bsdimp.com> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 03 Jan 2007 10:00:55 +0100 (CET) X-Mailman-Approved-At: Wed, 03 Jan 2007 12:30:06 +0000 Cc: erik.udo@gmail.com, freebsd-hackers@freebsd.org, rwatson@freebsd.org Subject: Re: Init.c, making it chroot 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, 03 Jan 2007 09:01:05 -0000 M. Warner Losh wrote: > In message: <200612301119.kBUBJNno062104@lurza.secnetix.de> > Oliver Fromme writes: > : 1- Why does the kernel try to mount /dev at all? Why not > : simply let init mount it in all cases, with ot without > : init_chroot? Would make things simpler. There doesn't > : seem to be a clear reason why the kernel needs to mount > : it. (Or maybe there _are_ reasons, byt they don't > : appear during my testing.) > > The kernel needs to mount /, and to do that it needs to have a /dev to > look things up in. Well, it actually mounts devfs on / before > looking up and mounting the real /. After it does that, it pivots the > devfs mounted on / into /dev, which is the source of the warning that > you see. OK, it's clear to me now. Also thanks to Robert Watson for the detailed explanation. So the warning is caused by the inability of the "fixup" code to move the devfs mount from / to /dev. This is to be expected in the init_chroot case (because there's no /dev outside of the chroot), so the warning can be safely ignored. Just a small question: What happens with the devfs mount previously mounted on /? Does the kernel silently discard it when the fixup fails, or is it still "hanging around" somehow? I don't see it in mount(8) or df(1) output, so I assume it is discarded. > : 2- Another solution would be to let init(8) autodetect > : whether /dev needs to be mounted. However, that might > : not be as trivial as it sounds. > > Indeed. As far as I can tell, the -d fallback in init is totally > unused these days. Since the kernel doesn't have a general list of > args passed to init, but instead has to construct them one at time > from flags set by the boot loader, I'm pretty sure that it can't be > easily specified. Yes, that seems to be right. An idea that just came to my mind: init could call stat() on / and on /dev (_after_ calling chroot() if applicable), and if the devices (st_dev) are the same, then devfs isn't mounted yet, so the devfs flag must be set for init to proceed successfully. That kind of autodetection should work reliably in all cases. What do you think? Any way, the latest patch that you mailed works perfectly, as I wrote earlier. Should I submit a PR with that patch, or would that be unneccessary? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "When your hammer is C++, everything begins to look like a thumb." -- Steve Haflich, in comp.lang.c++ From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 3 12:48:50 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E654716A403 for ; Wed, 3 Jan 2007 12:48:50 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.freebsd.org (Postfix) with ESMTP id 7D68713C469 for ; Wed, 3 Jan 2007 12:48:50 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.8/8.13.7) with ESMTP id l03CLcLW076289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jan 2007 13:21:38 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id l03CLYZD076280; Wed, 3 Jan 2007 13:21:34 +0100 (CET) Date: Wed, 3 Jan 2007 13:21:34 +0100 From: Divacky Roman To: Intron is my alias on the Internet Message-ID: <20070103122134.GA74544@stud.fit.vutbr.cz> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: freebsd-hackers@freebsd.org Subject: Re: Partially Unbreak Adobe Reader 7.0.8 for the New Linux Emulator 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, 03 Jan 2007 12:48:51 -0000 On Wed, Jan 03, 2007 at 07:47:28AM +0800, Intron is my alias on the Internet wrote: > My patch for /sys/compat/linux/linux_file.c (7.0-CURRENT) can > partially unbreak Adobe Reader 7.0.8 for Linux when the sysctl > compat.linux.osrelease is set to "2.6.16". You may download the patch > at: > > http://ftp.intron.ac/tmp/linux_file.c.diff this looks good. can you explain why this patch is not needed in 2.4 emulation? I cannot imagine why this differs in 2.6 and 2.4... does this cause the different read output I told you about? > But probably to your disappointment, the problem hasn't been > completely solved yet. Even after you have applied my patch (Don't > forget to set compat.linux.osrelease to "2.6.16"), you must remove > the directory ~/.adobe before you start Adobe Reader 7.0.8 every time, > otherwise the PDF file cannot be properly browsed. > > I have noticed that the calling behavior against the Linux > system call mmap2(2) is strange: > > 1658: linux_mmap2(0x0,0x8974,0x1,0x1,0x0,0x6) = 790032384 (0x2f16f000) > 1658: linux_mmap2(0x0,0x8fd8,0x1,0x1,0x0,0x6) = 790032384 (0x2f16f000) > 1658: linux_mmap2(0x0,0x8974,0x1,0x1,0x0,0x6) = 790032384 (0x2f16f000) > 1658: linux_mmap2(0x0,0x1000,0x3,0x22,0xffffffff,0x6) = 790069248 > (0x2f178000) > 1658: linux_mmap2(0x0,0x1000,0x3,0x22,0xffffffff,0x6) = 790069248 > (0x2f178000) > 1658: linux_mmap2(0x0,0x8fd8,0x1,0x1,0x0,0x6) = 790032384 (0x2f16f000) > 1658: linux_mmap2(0x0,0x8974,0x1,0x1,0x0,0x6) = 790032384 (0x2f16f000) > 1658: linux_mmap2(0x0,0x8a78,0x1,0x1,0x0,0x6) = 790032384 (0x2f16f000) > 1658: linux_mmap2(0x0,0x8974,0x1,0x1,0x0,0x6) = 790032384 (0x2f16f000) > > The last calling argument is always stupid 6, which doesn't agree with > the calling behavior against mmap(2) when compat.linux.osrelease is set > to 2.4.2. This probably means that all files mapped by mmap2(2) cannot be > properly read from memory space. well.. the last argument is pgoff which sets an offset. I dont see anything particularly wrong with this. why do you think its bad? anyway.. thnx for the patch! roman From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 3 13:16:16 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A66AB16A40F for ; Wed, 3 Jan 2007 13:16:16 +0000 (UTC) (envelope-from jhs@flat.berklix.net) Received: from thin.berklix.org (thin.berklix.org [194.246.123.68]) by mx1.freebsd.org (Postfix) with ESMTP id 3B37913C455 for ; Wed, 3 Jan 2007 13:16:15 +0000 (UTC) (envelope-from jhs@flat.berklix.net) Received: from js.berklix.net (p549A7372.dip.t-dialin.net [84.154.115.114]) (authenticated bits=128) by thin.berklix.org (8.12.11/8.12.11) with ESMTP id l03CsQkY018094; Wed, 3 Jan 2007 13:54:27 +0100 (CET) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (fire.jhs.private [192.168.91.41]) by js.berklix.net (8.13.6/8.13.6) with ESMTP id l03CsPPv074926; Wed, 3 Jan 2007 13:54:25 +0100 (CET) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (localhost.jhs.private [127.0.0.1]) by fire.jhs.private (8.13.6/8.13.6) with ESMTP id l03CsPSF082168; Wed, 3 Jan 2007 13:54:25 +0100 (CET) (envelope-from jhs@fire.jhs.private) Message-Id: <200701031254.l03CsPSF082168@fire.jhs.private> To: "Steven Hartland" In-reply-to: <007501c72f28$af27ffe0$b3db87d4@multiplay.co.uk> References: <007501c72f28$af27ffe0$b3db87d4@multiplay.co.uk> Comments: In-reply-to "Steven Hartland" message dated "Wed, 03 Jan 2007 11:16:52 +0000." Date: Wed, 03 Jan 2007 13:54:25 +0100 From: "Julian H. Stacey" Cc: freebsd-hackers@freebsd.org Subject: Re: SMP initialisation changes 6.1-PRERELEASE and 6.1-RELEASE? 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, 03 Jan 2007 13:16:16 -0000 "Steven Hartland" wrote: > Is anyone aware of any significant changes between 6.1-PRERELEASE > and 6.1-RELEASE which could cause and SMP kernel to hang when > initialising the CPU's? > > I have a Tyan s2892 based machine here which has been running > 6.1-PRELEASE happily for months, I finally got round to updating > to 6.1-RELEASE and it now just hangs. I've also tried 6.2-RC2 > and the same high happens with that. > > Also of note is that since updating to the latest BIOS on said > machine 2.03 from 2.0 I'm constantly seeing: > "calcru: runtime went backwards" messages from all processes > including idle. > > Steve If you have old bins & kernel & src/, or spare old boot partition, or another 6.1-PRERELEASE host to cross compile from: also worth building another 6.1-PRERELEASE kernel, to see its perhaps a build system or hardware problem ? Or a loader.conf or kernel conf before that disabled dual maybe, & got swept away in upgrade ? > This e.mail is private and confidential between Multiplay (UK) Ltd. and Entire World. Archived. -- Julian Stacey. BSD Unix C Net Consultancy, Munich/Muenchen http://berklix.com Mail Ascii, not HTML. Ihr Rauch = mein allergischer Kopfschmerz. http://berklix.org/free-software From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 3 15:52:49 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D8E3516A415 for ; Wed, 3 Jan 2007 15:52:49 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 76A1D13C45B for ; Wed, 3 Jan 2007 15:52:48 +0000 (UTC) (envelope-from killing@multiplay.co.uk) X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on core6.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-24.7 required=6.0 tests=BAYES_00, USER_IN_WHITELIST, USER_IN_WHITELIST_TO autolearn=ham version=3.1.5 Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.5.4) with ESMTP id md50003355736.msg for ; Wed, 03 Jan 2007 15:48:13 +0000 Message-ID: <007201c72f4e$90de97d0$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: "Julian H. Stacey" References: <007501c72f28$af27ffe0$b3db87d4@multiplay.co.uk> <200701031254.l03CsPSF082168@fire.jhs.private> Date: Wed, 3 Jan 2007 15:48:01 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-Spam-Processed: multiplay.co.uk, Wed, 03 Jan 2007 15:48:14 +0000 X-MDAV-Processed: multiplay.co.uk, Wed, 03 Jan 2007 15:48:15 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: SMP initialisation changes 6.1-PRERELEASE and 6.1-RELEASE? 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, 03 Jan 2007 15:52:49 -0000 > If you have old bins & kernel & src/, or spare old boot partition, or > another 6.1-PRERELEASE host to cross compile from: also worth > building another 6.1-PRERELEASE kernel, to see its perhaps a build > system or hardware problem ? Or a loader.conf or kernel conf before > that disabled dual maybe, & got swept away in upgrade ? I still have the old PRERELEASE kernel which works just fine even with the new world. Unfortunately I dont have the old src with which to compare builds, never had any problems before and didn't even consider maintaining as it was only PRERELEASE -> RELEASE :( kernel conf was identical, I'm going to be building 6.2-RC2 ( current source on the machine ) with kernel debugging to see if I can break to the debugger when this happens. It happens 99.9% of the time on boot just after initialising the Highpoint controller where the next step is to initialise the other CPU's it just hard locks :( Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 3 14:33:15 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DABD16A403 for ; Wed, 3 Jan 2007 14:33:15 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.166]) by mx1.freebsd.org (Postfix) with ESMTP id BD06113C467 for ; Wed, 3 Jan 2007 14:33:14 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (localhost [127.0.0.1]) by grosbein.pp.ru (8.13.8/8.13.8) with ESMTP id l03EIK9S001035 for ; Wed, 3 Jan 2007 21:18:20 +0700 (KRAT) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.13.8/8.13.8/Submit) id l03EIK5r001034 for hackers@freebsd.org; Wed, 3 Jan 2007 21:18:20 +0700 (KRAT) (envelope-from eugen) Date: Wed, 3 Jan 2007 21:18:20 +0700 From: Eugene Grosbein To: hackers@freebsd.org Message-ID: <20070103141820.GA1014@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-Mailman-Approved-At: Wed, 03 Jan 2007 16:06:54 +0000 Cc: Subject: WITNESS & RELENG_6 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, 03 Jan 2007 14:33:15 -0000 Hi! I try to find bugs in 6.2-PRERELEASE by using it (q) :-) The question is: are kernel options WITNESS/WITNESS_KDB expected to be in usable kernel? I don't worry about performance overhead here. The problem is, I've found this is nearly impossible to run my home system with RELENG_6 build from yesterday's sources, X.org 6.9.0, mplayer etc. without panicing and crashdump generation after an hour or so. Just switch from X to vty and logon gave me another LOR and crashdump. One of these you can see here: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/107455 Perhaps, I should not use these options for everyday STABLE use? Eugene From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 3 16:31:01 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E587716A416 for ; Wed, 3 Jan 2007 16:31:01 +0000 (UTC) (envelope-from jhs@flat.berklix.net) Received: from thin.berklix.org (thin.berklix.org [194.246.123.68]) by mx1.freebsd.org (Postfix) with ESMTP id 7A0A013C474 for ; Wed, 3 Jan 2007 16:31:01 +0000 (UTC) (envelope-from jhs@flat.berklix.net) Received: from js.berklix.net (p549A6BB4.dip.t-dialin.net [84.154.107.180]) (authenticated bits=128) by thin.berklix.org (8.12.11/8.12.11) with ESMTP id l03GUwLe018712; Wed, 3 Jan 2007 17:30:58 +0100 (CET) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (fire.jhs.private [192.168.91.41]) by js.berklix.net (8.13.6/8.13.6) with ESMTP id l03GUuXD076093; Wed, 3 Jan 2007 17:30:57 +0100 (CET) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (localhost.jhs.private [127.0.0.1]) by fire.jhs.private (8.13.6/8.13.6) with ESMTP id l03GUu9A084720; Wed, 3 Jan 2007 17:30:56 +0100 (CET) (envelope-from jhs@fire.jhs.private) Message-Id: <200701031630.l03GUu9A084720@fire.jhs.private> To: "Steven Hartland" In-reply-to: <007201c72f4e$90de97d0$b3db87d4@multiplay.co.uk> References: <007501c72f28$af27ffe0$b3db87d4@multiplay.co.uk> <200701031254.l03CsPSF082168@fire.jhs.private> <007201c72f4e$90de97d0$b3db87d4@multiplay.co.uk> Comments: In-reply-to "Steven Hartland" message dated "Wed, 03 Jan 2007 15:48:01 +0000." Date: Wed, 03 Jan 2007 17:30:56 +0100 From: "Julian H. Stacey" Cc: freebsd-hackers@freebsd.org Subject: Re: SMP initialisation changes 6.1-PRERELEASE and 6.1-RELEASE? 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, 03 Jan 2007 16:31:02 -0000 "Steven Hartland" wrote: > > If you have old bins & kernel & src/, or spare old boot partition, or > > another 6.1-PRERELEASE host to cross compile from: also worth > > building another 6.1-PRERELEASE kernel, to see its perhaps a build > > system or hardware problem ? Or a loader.conf or kernel conf before > > that disabled dual maybe, & got swept away in upgrade ? > > I still have the old PRERELEASE kernel which works just fine even with > the new world. > > Unfortunately I dont have the old src with which to compare builds, > never had any problems before and didn't even consider maintaining > as it was only PRERELEASE -> RELEASE :( I looked in my CD collection, & on ftp.freebsd - No. No tag in CVS/src/Makefile (the re@ team use that other non CVS ) I guess re@freebsd can export you a tree though. http://www.google.com/search?hl=en&lr=&q=i386++6.1+PRE+RELEASE+.iso&btnG=Search -> Not on: http://www.freebsd.org/releng/ http://www.freebsd.org/where.html#helptest Good luck -- Julian Stacey. BSD Unix C Net Consultancy, Munich/Muenchen http://berklix.com Mail Ascii, not HTML. Ihr Rauch = mein allergischer Kopfschmerz. http://berklix.org/free-software From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 3 16:32:50 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1172F16A49E for ; Wed, 3 Jan 2007 16:32:50 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id A084213C4AC for ; Wed, 3 Jan 2007 16:32:49 +0000 (UTC) (envelope-from killing@multiplay.co.uk) X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on core6.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-24.7 required=6.0 tests=BAYES_00, USER_IN_WHITELIST, USER_IN_WHITELIST_TO autolearn=ham version=3.1.5 Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.5.4) with ESMTP id md50003355867.msg for ; Wed, 03 Jan 2007 16:29:52 +0000 Message-ID: <009d01c72f54$63841f70$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: References: <007501c72f28$af27ffe0$b3db87d4@multiplay.co.uk><200701031254.l03CsPSF082168@fire.jhs.private> <007201c72f4e$90de97d0$b3db87d4@multiplay.co.uk> Date: Wed, 3 Jan 2007 16:29:40 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-Spam-Processed: multiplay.co.uk, Wed, 03 Jan 2007 16:29:54 +0000 X-MDAV-Processed: multiplay.co.uk, Wed, 03 Jan 2007 16:29:54 +0000 Subject: Re: SMP initialisation changes 6.1-PRERELEASE and 6.1-RELEASE? 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, 03 Jan 2007 16:32:50 -0000 Steven Hartland wrote: > kernel conf was identical, I'm going to be building 6.2-RC2 ( current > source on the machine ) with kernel debugging to see if I can break > to the debugger when this happens. > > It happens 99.9% of the time on boot just after initialising the > Highpoint controller where the next step is to initialise the other > CPU's it just hard locks :( Tried adding GDB and DDB but I cant break to the debugger once its hung. I'm going to try adding WITNESS and INVARIANTS but I dont hold much hope that this will help. Anyone got any pointers on how to proceed beyond this? Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 3 17:26:50 2007 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 52B6B16A415 for ; Wed, 3 Jan 2007 17:26:50 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-out-04.forthnet.gr (mx-out.forthnet.gr [193.92.150.105]) by mx1.freebsd.org (Postfix) with ESMTP id BAFE713C457 for ; Wed, 3 Jan 2007 17:26:49 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-av-02.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-04.forthnet.gr (8.13.7/8.13.7) with ESMTP id l03H4WQU020209 for ; Wed, 3 Jan 2007 19:04:32 +0200 Received: from mx-in-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-02.forthnet.gr (8.13.7/8.13.7) with ESMTP id l03H4WI8009840 for ; Wed, 3 Jan 2007 19:04:32 +0200 Received: from [192.168.136.22] (ppp197-7.adsl.forthnet.gr [62.1.146.7]) by mx-in-04.forthnet.gr (8.13.7/8.13.7) with ESMTP id l03H4Uld004412 for ; Wed, 3 Jan 2007 19:04:31 +0200 Authentication-Results: mx-in-04.forthnet.gr from=dds@aueb.gr; sender-id=neutral; spf=neutral Message-ID: <459BE218.7070605@aueb.gr> Date: Wed, 03 Jan 2007 19:04:24 +0200 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061211 SeaMonkey/1.0.7 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Filesystem layering 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, 03 Jan 2007 17:26:50 -0000 I've been puzzling for a couple of days to understand how the code moves from one layer to another in the FreeeBSD stacked filesystems, but I'm stuck. I've scrutinized the code, and I've read carefully pp. 254-257 of the "Design and Implementation of the FreeBSD Operating System", but one detail still escapes me. When is control passed from one layer with a bypass function to a lower one? Consider a case when umapfs is layered on top of another filesystem. As far as I can tell, the following excerpted sequence of function calls will end up continuously calling VOP_READ_APV passing umap_vnodeop as its first argument. Obviously somewhere somewhere the cycle breaks, but I can't see where. static int vn_read(fp, uio, active_cred, flags, td) struct file *fp; struct uio *uio; struct ucred *active_cred; struct thread *td; int flags; { struct vnode *vp; vp = fp->f_vnode; /* dds: vp->v_op == umap_vnodeops */ error = VOP_READ(vp, uio, ioflag, fp->f_cred); } static __inline int VOP_READ( struct vnode *vp, struct uio *uio, int ioflag, struct ucred *cred) { struct vop_read_args a; a.a_gen.a_desc = &vop_read_desc; a.a_vp = vp; /* dds: a.a_vp->v_op == umap_vnodeops */ a.a_uio = uio; a.a_ioflag = ioflag; a.a_cred = cred; /* dds: vp->v_op == umap_vnodeops */ return (VOP_READ_APV(vp->v_op, &a)); } int VOP_READ_APV(struct vop_vector *vop, struct vop_read_args *a) { int rc; /* dds: vop->vop_bypass == umap_bypass; while body skipped */ while(vop != NULL && vop->vop_read == NULL && vop->vop_bypass == NULL) vop = vop->vop_default; if (vop->vop_read != NULL) rc = vop->vop_read(a); else rc = vop->vop_bypass(&a->a_gen); /* dds: this is executed */ } static int umap_bypass(ap) struct vop_generic_args /* { struct vnodeop_desc *a_desc; } */ *ap; { /* ... */ error = VCALL(ap); /* dds: ap->a_desc == &vop_read_desc */ } #define VCALL(c) ((c)->a_desc->vdesc_call(c)) /* dds: vdesc_call == VOP_READ_AP */ int VOP_READ_AP(struct vop_read_args *a) { /* dds: a->a_vp->v_op still == umap_vnodeops ???? */ return(VOP_READ_APV(a->a_vp->v_op, a)); } /* dds: again VOP_READ_APV with the same arguments? */ int VOP_READ_APV(struct vop_vector *vop, struct vop_read_args *a) { int rc; while(vop != NULL && vop->vop_read == NULL && vop->vop_bypass == NULL) vop = vop->vop_default; if (vop->vop_read != NULL) rc = vop->vop_read(a); else rc = vop->vop_bypass(&a->a_gen); } Diomidis Spinellis - http://www.spinellis.gr From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 3 17:47:52 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64F8316A403 for ; Wed, 3 Jan 2007 17:47:52 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 0076213C478 for ; Wed, 3 Jan 2007 17:47:51 +0000 (UTC) (envelope-from killing@multiplay.co.uk) X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on core6.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-24.7 required=6.0 tests=BAYES_00, USER_IN_WHITELIST, USER_IN_WHITELIST_TO autolearn=ham version=3.1.5 Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.5.4) with ESMTP id md50003356098.msg for ; Wed, 03 Jan 2007 17:47:02 +0000 Message-ID: <00ef01c72f5f$28d3b470$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: "Steven Hartland" , References: <007501c72f28$af27ffe0$b3db87d4@multiplay.co.uk><200701031254.l03CsPSF082168@fire.jhs.private><007201c72f4e$90de97d0$b3db87d4@multiplay.co.uk> <009d01c72f54$63841f70$b3db87d4@multiplay.co.uk> Date: Wed, 3 Jan 2007 17:46:48 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-Spam-Processed: multiplay.co.uk, Wed, 03 Jan 2007 17:47:02 +0000 X-MDAV-Processed: multiplay.co.uk, Wed, 03 Jan 2007 17:47:02 +0000 Cc: Subject: Re: SMP initialisation changes 6.1-PRERELEASE and 6.1-RELEASE? 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, 03 Jan 2007 17:47:52 -0000 Steven Hartland wrote: > Tried adding GDB and DDB but I cant break to the debugger once its > hung. > I'm going to try adding WITNESS and INVARIANTS but I dont hold much > hope that this will help. Anyone got any pointers on how to proceed > beyond this? This now panics in the initial hpt driver init with: panic: blocakble sleep lock ( sleep mutex ) 128 @ vm/uma_core.c: 1845 This looks to me like a seperate issue as the driver is aquiring a spinlock MTX_SPIN instead of MTX_DEF? I'm quite out of my depth at this point so any pointers would be really appreciated. Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 3 20:42:40 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EE6EC16A412 for ; Wed, 3 Jan 2007 20:42:40 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) by mx1.freebsd.org (Postfix) with ESMTP id CEEF913C465 for ; Wed, 3 Jan 2007 20:42:40 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id l03KgeHo001577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 3 Jan 2007 12:42:40 -0800 X-Auth-Received: from [192.168.0.101] (dsl254-013-145.sea1.dsl.speakeasy.net [216.254.13.145]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id l03KgdPe017353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 3 Jan 2007 12:42:40 -0800 Message-ID: <459C153E.5090801@u.washington.edu> Date: Wed, 03 Jan 2007 12:42:38 -0800 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.9 (X11/20061226) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.3.122933 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __LINES_OF_YELLING 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: How to make an .so file for Linux binaries 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, 03 Jan 2007 20:42:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Trying to add Flashplayer 9 functionality to FreeBSD (via the Linux binary and www/linux-pluginwrapper) and I was wondering how I should go about determining which symbols need to be used in the .so file, and also how I should go about including the files (#include for the C files, `cat`, etc?). Thanks, - -Garrett -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFnBU+EnKyINQw/HARAudHAKCeKniPcqp3vIpTnvfKlfKYL52V+wCgldJi rMcySI93qEECfDjTtTMSiSM= =z3vI -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 3 21:23:19 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A43AB16A50A for ; Wed, 3 Jan 2007 21:23:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 3390C13C441 for ; Wed, 3 Jan 2007 21:23:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l03LNG2G023127; Wed, 3 Jan 2007 16:23:16 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 3 Jan 2007 15:56:52 -0500 User-Agent: KMail/1.9.1 References: <9bf098930701020242t232a1131r355c693618169441@mail.gmail.com> In-Reply-To: <9bf098930701020242t232a1131r355c693618169441@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701031556.52960.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 03 Jan 2007 16:23:17 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2411/Wed Jan 3 13:04:33 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: hackers@freebsd.org, "Anand H. Krishnan" Subject: Re: Doubts with scheduler code 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, 03 Jan 2007 21:23:19 -0000 On Tuesday 02 January 2007 05:42, Anand H. Krishnan wrote: > Hi, > > I had a couple of doubts when I was going through 6.1 freebsd code. > > * First one is in the wakeup() code. After a series of calls wakeup() > lands in maybe_preempt() and if preemption is enabled maybe_preempt() > switches to a new thread (if a high priority thread has been made runnable). > That means that an interrupt handler which calls wakeup() will not return > immediately. (I'm looking @ ULE scheduler). > > So is there a problem when wakeup() is called from high priority (fast interr > upt) handlers ? Interrupt threads have higher priority than the threads they wakeup. For the INTR_FAST case we run INTR_FAST handlers inside a critical section so that if a INTR_FAST handler wakes up a thread such as the clock or serial SWI, the preemption is deferred until after the INTR_FAST handler returns. > * Second one is in spinlock code. Can anyone say why critical_enter is > called from spinlock_enter() ? The only thing that critical_enter seems to > be doing is to increment td_critnest which probably helps in finding out > whether a thread can be pre-empted or not. But spinlock_enter() disables > interrupts and I fail to understand how can any thread become runnable > and get scheduled in between. A thread may wake up another thread while holding a spin lock. There are numerous examples of this. > I've one more.. > > * msleep() allows a thread to change it's priority when it gets woken up and > in many places they gets woken up with very high priority indeed. Is there > any convincing reason as to why it should be ? This is something that the 4BSD scheduler has done since before FreeBSD existed. The priority boost is intended to give higher priority to interactive processes (since they tend to sleep on I/O a lot) versus compute-bound processes. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 3 21:23:23 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1DBA816A50B for ; Wed, 3 Jan 2007 21:23:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id C478B13C428 for ; Wed, 3 Jan 2007 21:23:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l03LNG2H023127; Wed, 3 Jan 2007 16:23:18 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 3 Jan 2007 16:01:04 -0500 User-Agent: KMail/1.9.1 References: <20070103141820.GA1014@grosbein.pp.ru> In-Reply-To: <20070103141820.GA1014@grosbein.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701031601.05541.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 03 Jan 2007 16:23:20 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2411/Wed Jan 3 13:04:33 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: hackers@freebsd.org, Eugene Grosbein Subject: Re: WITNESS & RELENG_6 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, 03 Jan 2007 21:23:23 -0000 On Wednesday 03 January 2007 09:18, Eugene Grosbein wrote: > Hi! > > I try to find bugs in 6.2-PRERELEASE by using it (q) :-) > The question is: are kernel options WITNESS/WITNESS_KDB expected > to be in usable kernel? I don't worry about performance overhead here. > > The problem is, I've found this is nearly impossible to run > my home system with RELENG_6 build from yesterday's sources, > X.org 6.9.0, mplayer etc. without panicing and crashdump generation > after an hour or so. Just switch from X to vty and logon gave me another > LOR and crashdump. One of these you can see here: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/107455 > > Perhaps, I should not use these options for everyday STABLE use? > > Eugene I think you are running into devfs bugs actually. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 3 21:23:37 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A6B5416A50B for ; Wed, 3 Jan 2007 21:23:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 5CBED13C442 for ; Wed, 3 Jan 2007 21:23:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l03LNG2I023127; Wed, 3 Jan 2007 16:23:22 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 3 Jan 2007 16:06:59 -0500 User-Agent: KMail/1.9.1 References: <459BE218.7070605@aueb.gr> In-Reply-To: <459BE218.7070605@aueb.gr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701031607.00199.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 03 Jan 2007 16:23:23 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2411/Wed Jan 3 13:04:33 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Diomidis Spinellis Subject: Re: Filesystem layering 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, 03 Jan 2007 21:23:37 -0000 On Wednesday 03 January 2007 12:04, Diomidis Spinellis wrote: > static int > umap_bypass(ap) > struct vop_generic_args /* { > struct vnodeop_desc *a_desc; > > } */ *ap; > { > /* ... */ In this magic code here this function changes the vnode pointers in ap. > error = VCALL(ap); /* dds: ap->a_desc == &vop_read_desc */ > } -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 3 21:27:21 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F38E816A403 for ; Wed, 3 Jan 2007 21:27:20 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.freebsd.org (Postfix) with ESMTP id 89C4213C459 for ; Wed, 3 Jan 2007 21:27:20 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so7284086nfc for ; Wed, 03 Jan 2007 13:27:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=TSGkf+OzJGNA0UaS5Lu2hF3OBbyscmwS6ZOlOA55cyT5woaPVWfn5gpAFog1vpqnA3gKHoPXlcN0pYDmsHtQd0dhOgrzplm/B9AJelHuAx7xzxYJGecMFN1wtSh0DBqGXfg4FOgb85pOcfpC1lgrqiyPUC4leo2VAfp3z1NF5Cc= Received: by 10.82.127.15 with SMTP id z15mr2186020buc.1167857957746; Wed, 03 Jan 2007 12:59:17 -0800 (PST) Received: by 10.82.191.16 with HTTP; Wed, 3 Jan 2007 12:59:17 -0800 (PST) Message-ID: Date: Wed, 3 Jan 2007 12:59:17 -0800 From: "Kip Macy" To: "Eugene Grosbein" In-Reply-To: <20070103141820.GA1014@grosbein.pp.ru> MIME-Version: 1.0 References: <20070103141820.GA1014@grosbein.pp.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: hackers@freebsd.org Subject: Re: WITNESS & RELENG_6 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, 03 Jan 2007 21:27:21 -0000 The bug you're hitting there is a bad pointer reference in devfs_populate_loop - you shouldn't be taking a page fault there. I hope that someone who knows more about devfs will take a look. -Kip On 1/3/07, Eugene Grosbein wrote: > > Hi! > > I try to find bugs in 6.2-PRERELEASE by using it (q) :-) > The question is: are kernel options WITNESS/WITNESS_KDB expected > to be in usable kernel? I don't worry about performance overhead here. > > The problem is, I've found this is nearly impossible to run > my home system with RELENG_6 build from yesterday's sources, > X.org 6.9.0, mplayer etc. without panicing and crashdump generation > after an hour or so. Just switch from X to vty and logon gave me another > LOR and crashdump. One of these you can see here: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/107455 > > Perhaps, I should not use these options for everyday STABLE use? > > Eugene > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 3 21:52:29 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2BA7A16A403 for ; Wed, 3 Jan 2007 21:52:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id CB3B913C458 for ; Wed, 3 Jan 2007 21:52:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l03LNG2H023127; Wed, 3 Jan 2007 16:23:18 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 3 Jan 2007 16:01:04 -0500 User-Agent: KMail/1.9.1 References: <20070103141820.GA1014@grosbein.pp.ru> In-Reply-To: <20070103141820.GA1014@grosbein.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701031601.05541.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 03 Jan 2007 16:23:20 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2411/Wed Jan 3 13:04:33 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: hackers@freebsd.org, Eugene Grosbein Subject: Re: WITNESS & RELENG_6 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, 03 Jan 2007 21:52:29 -0000 On Wednesday 03 January 2007 09:18, Eugene Grosbein wrote: > Hi! > > I try to find bugs in 6.2-PRERELEASE by using it (q) :-) > The question is: are kernel options WITNESS/WITNESS_KDB expected > to be in usable kernel? I don't worry about performance overhead here. > > The problem is, I've found this is nearly impossible to run > my home system with RELENG_6 build from yesterday's sources, > X.org 6.9.0, mplayer etc. without panicing and crashdump generation > after an hour or so. Just switch from X to vty and logon gave me another > LOR and crashdump. One of these you can see here: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/107455 > > Perhaps, I should not use these options for everyday STABLE use? > > Eugene I think you are running into devfs bugs actually. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 3 21:52:29 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F19E716A407 for ; Wed, 3 Jan 2007 21:52:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 6C67113C461 for ; Wed, 3 Jan 2007 21:52:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l03LNG2G023127; Wed, 3 Jan 2007 16:23:16 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 3 Jan 2007 15:56:52 -0500 User-Agent: KMail/1.9.1 References: <9bf098930701020242t232a1131r355c693618169441@mail.gmail.com> In-Reply-To: <9bf098930701020242t232a1131r355c693618169441@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701031556.52960.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 03 Jan 2007 16:23:17 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2411/Wed Jan 3 13:04:33 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: hackers@freebsd.org, "Anand H. Krishnan" Subject: Re: Doubts with scheduler code 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, 03 Jan 2007 21:52:30 -0000 On Tuesday 02 January 2007 05:42, Anand H. Krishnan wrote: > Hi, > > I had a couple of doubts when I was going through 6.1 freebsd code. > > * First one is in the wakeup() code. After a series of calls wakeup() > lands in maybe_preempt() and if preemption is enabled maybe_preempt() > switches to a new thread (if a high priority thread has been made runnable). > That means that an interrupt handler which calls wakeup() will not return > immediately. (I'm looking @ ULE scheduler). > > So is there a problem when wakeup() is called from high priority (fast interr > upt) handlers ? Interrupt threads have higher priority than the threads they wakeup. For the INTR_FAST case we run INTR_FAST handlers inside a critical section so that if a INTR_FAST handler wakes up a thread such as the clock or serial SWI, the preemption is deferred until after the INTR_FAST handler returns. > * Second one is in spinlock code. Can anyone say why critical_enter is > called from spinlock_enter() ? The only thing that critical_enter seems to > be doing is to increment td_critnest which probably helps in finding out > whether a thread can be pre-empted or not. But spinlock_enter() disables > interrupts and I fail to understand how can any thread become runnable > and get scheduled in between. A thread may wake up another thread while holding a spin lock. There are numerous examples of this. > I've one more.. > > * msleep() allows a thread to change it's priority when it gets woken up and > in many places they gets woken up with very high priority indeed. Is there > any convincing reason as to why it should be ? This is something that the 4BSD scheduler has done since before FreeBSD existed. The priority boost is intended to give higher priority to interactive processes (since they tend to sleep on I/O a lot) versus compute-bound processes. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 3 22:51:21 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E09716A47B for ; Wed, 3 Jan 2007 22:51:21 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-out-01.forthnet.gr (mx-out.forthnet.gr [193.92.150.105]) by mx1.freebsd.org (Postfix) with ESMTP id 5480D13C4A8 for ; Wed, 3 Jan 2007 22:51:19 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-av-01.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.13.7/8.13.7) with ESMTP id l03MpE8e017031; Thu, 4 Jan 2007 00:51:14 +0200 Received: from mx-in-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-01.forthnet.gr (8.13.7/8.13.7) with ESMTP id l03MpEW2024071; Thu, 4 Jan 2007 00:51:14 +0200 Received: from [192.168.136.22] (ppp197-7.adsl.forthnet.gr [62.1.146.7]) by mx-in-04.forthnet.gr (8.13.7/8.13.7) with ESMTP id l03MpCpj007862; Thu, 4 Jan 2007 00:51:13 +0200 Authentication-Results: mx-in-04.forthnet.gr from=dds@aueb.gr; sender-id=neutral; spf=neutral Message-ID: <459C335A.1030200@aueb.gr> Date: Thu, 04 Jan 2007 00:51:06 +0200 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061211 SeaMonkey/1.0.7 MIME-Version: 1.0 To: John Baldwin References: <459BE218.7070605@aueb.gr> <200701031607.00199.jhb@freebsd.org> In-Reply-To: <200701031607.00199.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Filesystem layering 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, 03 Jan 2007 22:51:21 -0000 John Baldwin wrote: > On Wednesday 03 January 2007 12:04, Diomidis Spinellis wrote: >> static int >> umap_bypass(ap) >> struct vop_generic_args /* { >> struct vnodeop_desc *a_desc; >> >> } */ *ap; >> { >> /* ... */ > > In this magic code here this function changes the vnode pointers in > ap. I presume you mean the part starting with the comment: /* * Map the vnodes going in. * Later, we'll invoke the operation based on * the first mapped vnode's operation vector. */ Thanks! I don't think I'd guess it by reading the code; I was looking for a a simple assignment or indirection. My next plan was to add debugging statements along the way, which would have been quite painful. Diomidis From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 00:02:57 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B53D16A403 for ; Thu, 4 Jan 2007 00:02:57 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 293FB13C45B for ; Thu, 4 Jan 2007 00:02:56 +0000 (UTC) (envelope-from killing@multiplay.co.uk) X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on core6.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-24.7 required=6.0 tests=BAYES_00, USER_IN_WHITELIST, USER_IN_WHITELIST_TO autolearn=ham version=3.1.5 Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.5.4) with ESMTP id md50003356772.msg for ; Wed, 03 Jan 2007 23:58:42 +0000 Message-ID: <006301c72f93$0ffceb40$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: Date: Wed, 3 Jan 2007 23:58:20 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-Spam-Processed: multiplay.co.uk, Wed, 03 Jan 2007 23:58:42 +0000 X-MDAV-Processed: multiplay.co.uk, Wed, 03 Jan 2007 23:58:42 +0000 Subject: hptmv not compatible with WITNESS / INVARIANTS pointers required 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, 04 Jan 2007 00:02:57 -0000 I'm currently trying to debug an issue with Tyan s2892 based machine but when I enable WITNESS / INVARIANTS the Highpoint 182x driver panics the kernel with: panic: blocakble sleep lock ( sleep mutex ) 128 @ vm/uma_core.c: 1845 I believe this is due to the fact that you cant hold a spin mutex while using: bus_dma_tag_create, malloc bus_dmamem_alloc etc which the driver currently does, but I have no experience with drivers hence dont know what it should be doing instead. If someone's willing to give me some pointers I'd be willing to give creating a patch and testing it a go. Here's a snipet of what I think is causing the issue: /* This uses a mtx_lock_spin */ intrmask_t oldspl = lock_driver(); pAdapter->next = 0; if(gIal_Adapter == 0) { gIal_Adapter = pAdapter; pCurAdapter = gIal_Adapter; } else { pCurAdapter->next = pAdapter; pCurAdapter = pAdapter; } pAdapter->outstandingCommands = 0; pMvSataAdapter = &(pAdapter->mvSataAdapter); _vbus_p->OsExt = (void *)pAdapter; pMvSataAdapter->IALData = pAdapter; /* Errors due to lock_driver holding mtx_lock_spin?? */ if (bus_dma_tag_create(NULL, 1, 0, BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, BUS_SPACE_MAXSIZE_32BIT, MV_MAX_SEGMENTS, BUS_SPACE_MAXSIZE_32BIT, 0, NULL, NULL, &pAdapter->parent_dmat) != 0) { MV_ERROR("RR182x: Failed to create busdma resources\n"); unlock_driver(oldspl); return (ENOMEM); } ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 01:50:27 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1192A16A407 for ; Thu, 4 Jan 2007 01:50:27 +0000 (UTC) (envelope-from bsd.devil@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.231]) by mx1.freebsd.org (Postfix) with ESMTP id C414B13C45A for ; Thu, 4 Jan 2007 01:50:26 +0000 (UTC) (envelope-from bsd.devil@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so2865945nzh for ; Wed, 03 Jan 2007 17:50:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=T6WvA2Rs0o2ElBGU0x3piECcrqsgOBsoQe6y+OYjIG5k879N7jkrVMLmRfE5iiiQvzXhU4FIBm/+mOpv3RLzuTeWL3h8mvxE2bP5hLXMpMlYznFQQiBA8Cs2RxryQpCWKtRCEv/k5EJL/TZej258OeRgSasXJfaMmZOjZxWNm2Q= Received: by 10.65.137.15 with SMTP id p15mr29006876qbn.1167875426248; Wed, 03 Jan 2007 17:50:26 -0800 (PST) Received: by 10.65.249.17 with HTTP; Wed, 3 Jan 2007 17:50:26 -0800 (PST) Message-ID: Date: Wed, 3 Jan 2007 20:50:26 -0500 From: "Vishal Patil" To: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org. In-Reply-To: MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: vpnc problem 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, 04 Jan 2007 01:50:27 -0000 I have found the answer to this question. I basically had to edit the vpnc-script and replace the body of the function "get_default_gw" with netstat -r -n | sed 's/default/0.0.0.0/' | grep '^0.0.0.0' | awk '{print $2}' So now I have vpnc-0.3.3 working on FreeBSD. - Vishal On 1/1/07, Vishal Patil wrote: > > I am trying to use vpnc 0.3.3 on FreeBSD 6.1 but I get the following > errors > > route: bad address: > delete net default > > Also this completely screws up the network on my machine :( > Has anyone being successfully in using vpnc 0.3.3 on FreeBSD 6.1? > Thanks. > > - Vishal > > > From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 03:59:15 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25BEE16A40F for ; Thu, 4 Jan 2007 03:59:15 +0000 (UTC) (envelope-from anandhkrishnan@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by mx1.freebsd.org (Postfix) with ESMTP id DE9DF13C45A for ; Thu, 4 Jan 2007 03:59:14 +0000 (UTC) (envelope-from anandhkrishnan@gmail.com) Received: by wr-out-0506.google.com with SMTP id 55so2145426wri for ; Wed, 03 Jan 2007 19:59:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Tawe3zXF15nI5BipirKOCCh6S2Bh/UcAJxZdKDHtOfzTuFjlUUNxobcA0g2XvUrzIaqdWiuz6P+Y4K7VKtoEADeh1NhZ7gBqnIcn9O5VEywNgTwohRWD7WzXmTyD5OSothiqMBTRTQLcYf1rvvBgofgkozJudN88xke5qTXcJjE= Received: by 10.90.90.16 with SMTP id n16mr15365041agb.1167883154365; Wed, 03 Jan 2007 19:59:14 -0800 (PST) Received: by 10.90.74.4 with HTTP; Wed, 3 Jan 2007 19:59:14 -0800 (PST) Message-ID: <9bf098930701031959o3956bdfw7628cf1a5ef5b698@mail.gmail.com> Date: Thu, 4 Jan 2007 09:29:14 +0530 From: "Anand H. Krishnan" To: "John Baldwin" In-Reply-To: <200701031556.52960.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9bf098930701020242t232a1131r355c693618169441@mail.gmail.com> <200701031556.52960.jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: Doubts with scheduler code 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, 04 Jan 2007 03:59:15 -0000 Hi, > > * First one is in the wakeup() code. After a series of calls wakeup() > > lands in maybe_preempt() and if preemption is enabled maybe_preempt() > > switches to a new thread (if a high priority thread has been made runnable). > > That means that an interrupt handler which calls wakeup() will not return > > immediately. (I'm looking @ ULE scheduler). > > > > So is there a problem when wakeup() is called from high priority (fast > interr > > upt) handlers ? > > Interrupt threads have higher priority than the threads they wakeup. For > the INTR_FAST case we run INTR_FAST handlers inside a critical section so > that if a INTR_FAST handler wakes up a thread such as the clock or serial > SWI, the preemption is deferred until after the INTR_FAST handler returns. Saw that yesterday. Thanks for the clarification... > > > * Second one is in spinlock code. Can anyone say why critical_enter is > > called from spinlock_enter() ? The only thing that critical_enter seems to > > be doing is to increment td_critnest which probably helps in finding out > > whether a thread can be pre-empted or not. But spinlock_enter() disables > > interrupts and I fail to understand how can any thread become runnable > > and get scheduled in between. > > A thread may wake up another thread while holding a spin lock. There are > numerous examples of this. Never thought about that.. > > > I've one more.. > > > > * msleep() allows a thread to change it's priority when it gets woken up and > > in many places they gets woken up with very high priority indeed. Is there > > any convincing reason as to why it should be ? > > This is something that the 4BSD scheduler has done since before FreeBSD > existed. The priority boost is intended to give higher priority to > interactive processes (since they tend to sleep on I/O a lot) versus > compute-bound processes. Thanks John and Coleman for your replies. Anand > > -- > John Baldwin > From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 04:08:14 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D46A716A412; Thu, 4 Jan 2007 04:08:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by mx1.freebsd.org (Postfix) with ESMTP id 7C9D713C44C; Thu, 4 Jan 2007 04:08:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.227] (helo=fw.zoral.com.ua) by relay01.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1H2Jtc-000Ok0-EI; Thu, 04 Jan 2007 06:08:12 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id l0447SJj023161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jan 2007 06:07:28 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id l0447RTF059291; Thu, 4 Jan 2007 06:07:27 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id l0447RZj059290; Thu, 4 Jan 2007 06:07:27 +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, 4 Jan 2007 06:07:27 +0200 From: Kostik Belousov To: John Baldwin Message-ID: <20070104040727.GD21325@deviant.kiev.zoral.com.ua> References: <20070103141820.GA1014@grosbein.pp.ru> <200701031601.05541.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZATCr4BkWovzAAkA" Content-Disposition: inline In-Reply-To: <200701031601.05541.jhb@freebsd.org> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-0.1 required=5.0 tests=ALL_TRUSTED,SPF_NEUTRAL autolearn=failed version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on fw.zoral.com.ua X-Scanner-Signature: 4fe2b897d4d72954524b6b73d18f8617 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 661 [Dec 30 2006] 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, Eugene Grosbein Subject: Re: WITNESS & RELENG_6 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, 04 Jan 2007 04:08:14 -0000 --ZATCr4BkWovzAAkA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 03, 2007 at 04:01:04PM -0500, John Baldwin wrote: > On Wednesday 03 January 2007 09:18, Eugene Grosbein wrote: > > Hi! > >=20 > > I try to find bugs in 6.2-PRERELEASE by using it (q) :-) > > The question is: are kernel options WITNESS/WITNESS_KDB expected > > to be in usable kernel? I don't worry about performance overhead here. > >=20 > > The problem is, I've found this is nearly impossible to run > > my home system with RELENG_6 build from yesterday's sources, > > X.org 6.9.0, mplayer etc. without panicing and crashdump generation > > after an hour or so. Just switch from X to vty and logon gave me another > > LOR and crashdump. One of these you can see here: > >=20 > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/107455 > >=20 > > Perhaps, I should not use these options for everyday STABLE use? > >=20 > > Eugene >=20 > I think you are running into devfs bugs actually. I would suggest that the problem may be in the nvidia driver instead. It seems to be related to dev cloning. Anyway, obtaining exact location of fault in devfs_populate_loop (either with crashdump/kgdb or manually) would be first step. --ZATCr4BkWovzAAkA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFnH1+C3+MBN1Mb4gRAlkGAKDuiii4+WqrTYLX5GkdbgAIf8oeDACgmaUJ VnGRs6y4wzKtxvk5D7iId1A= =9MVp -----END PGP SIGNATURE----- --ZATCr4BkWovzAAkA-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 04:28:06 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75EA416A403 for ; Thu, 4 Jan 2007 04:28:06 +0000 (UTC) (envelope-from anandhkrishnan@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by mx1.freebsd.org (Postfix) with ESMTP id 3A44113C442 for ; Thu, 4 Jan 2007 04:28:06 +0000 (UTC) (envelope-from anandhkrishnan@gmail.com) Received: by wr-out-0506.google.com with SMTP id 55so2146267wri for ; Wed, 03 Jan 2007 20:28:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Tawe3zXF15nI5BipirKOCCh6S2Bh/UcAJxZdKDHtOfzTuFjlUUNxobcA0g2XvUrzIaqdWiuz6P+Y4K7VKtoEADeh1NhZ7gBqnIcn9O5VEywNgTwohRWD7WzXmTyD5OSothiqMBTRTQLcYf1rvvBgofgkozJudN88xke5qTXcJjE= Received: by 10.90.90.16 with SMTP id n16mr15365041agb.1167883154365; Wed, 03 Jan 2007 19:59:14 -0800 (PST) Received: by 10.90.74.4 with HTTP; Wed, 3 Jan 2007 19:59:14 -0800 (PST) Message-ID: <9bf098930701031959o3956bdfw7628cf1a5ef5b698@mail.gmail.com> Date: Thu, 4 Jan 2007 09:29:14 +0530 From: "Anand H. Krishnan" To: "John Baldwin" In-Reply-To: <200701031556.52960.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9bf098930701020242t232a1131r355c693618169441@mail.gmail.com> <200701031556.52960.jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: Doubts with scheduler code 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, 04 Jan 2007 04:28:06 -0000 Hi, > > * First one is in the wakeup() code. After a series of calls wakeup() > > lands in maybe_preempt() and if preemption is enabled maybe_preempt() > > switches to a new thread (if a high priority thread has been made runnable). > > That means that an interrupt handler which calls wakeup() will not return > > immediately. (I'm looking @ ULE scheduler). > > > > So is there a problem when wakeup() is called from high priority (fast > interr > > upt) handlers ? > > Interrupt threads have higher priority than the threads they wakeup. For > the INTR_FAST case we run INTR_FAST handlers inside a critical section so > that if a INTR_FAST handler wakes up a thread such as the clock or serial > SWI, the preemption is deferred until after the INTR_FAST handler returns. Saw that yesterday. Thanks for the clarification... > > > * Second one is in spinlock code. Can anyone say why critical_enter is > > called from spinlock_enter() ? The only thing that critical_enter seems to > > be doing is to increment td_critnest which probably helps in finding out > > whether a thread can be pre-empted or not. But spinlock_enter() disables > > interrupts and I fail to understand how can any thread become runnable > > and get scheduled in between. > > A thread may wake up another thread while holding a spin lock. There are > numerous examples of this. Never thought about that.. > > > I've one more.. > > > > * msleep() allows a thread to change it's priority when it gets woken up and > > in many places they gets woken up with very high priority indeed. Is there > > any convincing reason as to why it should be ? > > This is something that the 4BSD scheduler has done since before FreeBSD > existed. The priority boost is intended to give higher priority to > interactive processes (since they tend to sleep on I/O a lot) versus > compute-bound processes. Thanks John and Coleman for your replies. Anand > > -- > John Baldwin > From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 3 22:05:28 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3EF6A16A415; Wed, 3 Jan 2007 22:05:28 +0000 (UTC) (envelope-from admin@intron.ac) Received: from intron.ac (unknown [210.51.165.237]) by mx1.freebsd.org (Postfix) with ESMTP id 76AA113C441; Wed, 3 Jan 2007 22:05:27 +0000 (UTC) (envelope-from admin@intron.ac) Received: from localhost (localhost [127.0.0.1]) (uid 1003) by intron.ac with local; Thu, 04 Jan 2007 06:05:25 +0800 id 0011F80B.459C28A5.000097CD References: <20070103122134.GA74544@stud.fit.vutbr.cz> In-Reply-To: <20070103122134.GA74544@stud.fit.vutbr.cz> From: "Intron is my alias on the Internet" To: freebsd-emulation@freebsd.org, freebsd-hackers@freebsd.org Date: Thu, 04 Jan 2007 06:05:25 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-ID: X-Mailman-Approved-At: Thu, 04 Jan 2007 06:06:33 +0000 Cc: Subject: Successfully Unbreak Adobe Reader 7.0.8 for the New Linux Emulator 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, 03 Jan 2007 22:05:28 -0000 It's dawning in Beijing now. I'm quite tired. Here, I only summarize the solution as is. I will write a complete hacking report after a rest. 1. Restore your /sys/compat/linux/linux_file.c to the original revision 1.99 (7.0-CURRENT) if you have applied my yesterday's patch. You have two convenient ways to do this: 1) Overwrite linux_file.c with linux_file.c.orig backuped by patch(1) OR 2) Download the revision 1.99 from: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/linux/linux_file.c 2. Apply my new patch for /sys/compat/linux/linux_file.c: http://ftp.intron.ac/tmp/linux_file.c.2.diff 3. Recompile and reload the module linux.ko. 4. sysctl compat.linux.osrelease=2.6.16 5. Remove ~/.adobe/Acrobat/7.0/UserCache.bin if something troubles you. My brain is a little foggy now. If I make something wrong, please do not laugh at me. Screenshots: 1. FreeBSD Developers' Handbook, Chinese version: http://ftp.intron.ac/tmp/adobereader-20070104-1.png 2. Unicode 4.1 Code Charts, a page for ancient Chinese characters: http://ftp.intron.ac/tmp/adobereader-20070104-2.png 3. The English novel Jane Eyre (got from http://www.planetpdf.com/): http://ftp.intron.ac/tmp/adobereader-20070104-3.png ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 10:38:00 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6890116A40F; Thu, 4 Jan 2007 10:38:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 022B713C457; Thu, 4 Jan 2007 10:37:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.227] (helo=fw.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1H2Pyo-000Fcm-8o; Thu, 04 Jan 2007 12:37:58 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id l04Ab9bB034207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jan 2007 12:37:10 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id l04Ab9P1001494; Thu, 4 Jan 2007 12:37:09 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id l04Ab9Kx001311; Thu, 4 Jan 2007 12:37:09 +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, 4 Jan 2007 12:37:08 +0200 From: Kostik Belousov To: Eugene Grosbein Message-ID: <20070104103708.GF21325@deviant.kiev.zoral.com.ua> References: <20070103141820.GA1014@grosbein.pp.ru> <200701031601.05541.jhb@freebsd.org> <20070104040727.GD21325@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a/RL+Md+4nRpYrpt" Content-Disposition: inline In-Reply-To: <20070104040727.GD21325@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-0.1 required=5.0 tests=ALL_TRUSTED,SPF_NEUTRAL autolearn=failed version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on fw.zoral.com.ua X-Scanner-Signature: 1e0f9aa0c43ce3c3744db576a35a93a3 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 661 [Dec 30 2006] 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: WITNESS & RELENG_6 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, 04 Jan 2007 10:38:00 -0000 --a/RL+Md+4nRpYrpt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 04, 2007 at 06:07:27AM +0200, Kostik Belousov wrote: > On Wed, Jan 03, 2007 at 04:01:04PM -0500, John Baldwin wrote: > > On Wednesday 03 January 2007 09:18, Eugene Grosbein wrote: > > > Hi! > > >=20 > > > I try to find bugs in 6.2-PRERELEASE by using it (q) :-) > > > The question is: are kernel options WITNESS/WITNESS_KDB expected > > > to be in usable kernel? I don't worry about performance overhead here. > > >=20 > > > The problem is, I've found this is nearly impossible to run > > > my home system with RELENG_6 build from yesterday's sources, > > > X.org 6.9.0, mplayer etc. without panicing and crashdump generation > > > after an hour or so. Just switch from X to vty and logon gave me anot= her > > > LOR and crashdump. One of these you can see here: > > >=20 > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/107455 > > >=20 > > > Perhaps, I should not use these options for everyday STABLE use? > > >=20 > > > Eugene > >=20 > > I think you are running into devfs bugs actually. >=20 > I would suggest that the problem may be in the nvidia driver instead. > It seems to be related to dev cloning. >=20 > Anyway, obtaining exact location of fault in devfs_populate_loop (either > with crashdump/kgdb or manually) would be first step. Ok, thanks to Eugene for sending me requested information in private messag= e. The problem is revealed by INVARIANTS option, not by WITNESS, and is defini= tely the use-after-free. in src/nvidia_dev.c, nvidia_dev_close(), that is cdevsw.d_close proc, the destroy_dev() is called. Please, apply rev. 1.199 of sys/kern/kern_conf= .c. I expect that crashes shall stop, but non-killable processes (in the "devdr= n") state would accumulate. Please, confirm. --a/RL+Md+4nRpYrpt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD4DBQFFnNjUC3+MBN1Mb4gRAmiGAJ4pbkgJHnMzK6mgf1H8uVBL4CPinACVGh79 F4mh5TrVWMrPGHHwzc21uQ== =RPvu -----END PGP SIGNATURE----- --a/RL+Md+4nRpYrpt-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 11:02:50 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 33F9C16A403 for ; Thu, 4 Jan 2007 11:02:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by mx1.freebsd.org (Postfix) with ESMTP id B376913C45E for ; Thu, 4 Jan 2007 11:02:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.227] (helo=fw.zoral.com.ua) by relay01.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1H2QMq-000Lo1-6g for freebsd-hackers@freebsd.org; Thu, 04 Jan 2007 13:02:48 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id l04B29ge034912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jan 2007 13:02:09 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id l04B29Xc019842; Thu, 4 Jan 2007 13:02:09 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id l04B289P019841; Thu, 4 Jan 2007 13:02:08 +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, 4 Jan 2007 13:02:08 +0200 From: Kostik Belousov To: Eugene Grosbein Message-ID: <20070104110208.GG21325@deviant.kiev.zoral.com.ua> References: <20070103141820.GA1014@grosbein.pp.ru> <200701031601.05541.jhb@freebsd.org> <20070104040727.GD21325@deviant.kiev.zoral.com.ua> <20070104103708.GF21325@deviant.kiev.zoral.com.ua> <20070104105208.GA78979@svzserv.kemerovo.su> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="719vRtZnJj4YbTia" Content-Disposition: inline In-Reply-To: <20070104105208.GA78979@svzserv.kemerovo.su> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-0.1 required=5.0 tests=ALL_TRUSTED,SPF_NEUTRAL autolearn=failed version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on fw.zoral.com.ua X-Scanner-Signature: 021e97fb5facab6d3ae496d7b6c27559 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 661 [Dec 30 2006] 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, Eugene Grosbein Subject: Re: WITNESS & RELENG_6 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, 04 Jan 2007 11:02:50 -0000 --719vRtZnJj4YbTia Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 04, 2007 at 05:52:08PM +0700, Eugene Grosbein wrote: > On Thu, Jan 04, 2007 at 12:37:08PM +0200, Kostik Belousov wrote: >=20 > > The problem is revealed by INVARIANTS option, not by WITNESS, and is de= finitely the use-after-free. > >=20 > > in src/nvidia_dev.c, nvidia_dev_close(), that is cdevsw.d_close proc, > > the destroy_dev() is called. Please, apply rev. 1.199 of sys/kern/kern_= conf.c. > > I expect that crashes shall stop, but non-killable processes (in the "d= evdrn") > > state would accumulate. > >=20 > > Please, confirm. >=20 > I've tried to apply 1.199 to RELENG_6 but failed: > one of three chunks has been rejected. >=20 Hmm, it needs 1.198 as well. Below is aggregated patch against RELENG_6. Index: kern_conf.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/local/arch/ncvs/src/sys/kern/kern_conf.c,v retrieving revision 1.186.2.7 diff -u -r1.186.2.7 kern_conf.c --- kern_conf.c 30 Oct 2006 15:43:56 -0000 1.186.2.7 +++ kern_conf.c 4 Jan 2007 10:59:33 -0000 @@ -676,16 +676,20 @@ dev->si_flags &=3D ~SI_CLONELIST; } =20 + dev->si_refcount++; /* Avoid race with dev_rel() */ csw =3D dev->si_devsw; dev->si_devsw =3D NULL; /* already NULL for SI_ALIAS */ while (csw !=3D NULL && csw->d_purge !=3D NULL && dev->si_threadcount) { - printf("Purging %lu threads from %s\n", - dev->si_threadcount, devtoname(dev)); csw->d_purge(dev); msleep(csw, &devmtx, PRIBIO, "devprg", hz/10); + if (dev->si_threadcount) + printf("Still %lu threads in %s\n", + dev->si_threadcount, devtoname(dev)); + } + while (dev->si_threadcount !=3D 0) { + /* Use unique dummy wait ident */ + msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10); } - if (csw !=3D NULL && csw->d_purge !=3D NULL) - printf("All threads purged from %s\n", devtoname(dev)); =20 dev->si_drv1 =3D 0; dev->si_drv2 =3D 0; @@ -700,6 +704,7 @@ fini_cdevsw(csw); } dev->si_flags &=3D ~SI_ALIAS; + dev->si_refcount--; /* Avoid race with dev_rel() */ =20 if (dev->si_refcount > 0) { LIST_INSERT_HEAD(&dead_cdevsw.d_devs, dev, si_list); --719vRtZnJj4YbTia Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFnN6wC3+MBN1Mb4gRApPjAKCt66RlKWkHZE7fNYxvHsnxrD0WvACfRzLl cLbrG/qv/LLo87HEaNAD4A0= =ZIUk -----END PGP SIGNATURE----- --719vRtZnJj4YbTia-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 11:49:34 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9171916A407 for ; Thu, 4 Jan 2007 11:49:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 2B7E913C43E for ; Thu, 4 Jan 2007 11:49:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.227] (helo=fw.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1H2R64-00067B-MR for freebsd-hackers@freebsd.org; Thu, 04 Jan 2007 13:49:33 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id l04Bmn37036369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jan 2007 13:48:49 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id l04BmnWv020723; Thu, 4 Jan 2007 13:48:49 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id l04BmnYn020722; Thu, 4 Jan 2007 13:48:49 +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, 4 Jan 2007 13:48:49 +0200 From: Kostik Belousov To: Eugene Grosbein Message-ID: <20070104114849.GH21325@deviant.kiev.zoral.com.ua> References: <20070103141820.GA1014@grosbein.pp.ru> <200701031601.05541.jhb@freebsd.org> <20070104040727.GD21325@deviant.kiev.zoral.com.ua> <20070104103708.GF21325@deviant.kiev.zoral.com.ua> <20070104105208.GA78979@svzserv.kemerovo.su> <20070104110208.GG21325@deviant.kiev.zoral.com.ua> <20070104114327.GA81011@svzserv.kemerovo.su> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xLfTzkWEurH/gki3" Content-Disposition: inline In-Reply-To: <20070104114327.GA81011@svzserv.kemerovo.su> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-0.1 required=5.0 tests=ALL_TRUSTED,SPF_NEUTRAL autolearn=failed version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on fw.zoral.com.ua X-Scanner-Signature: a0e7373be156534abcc10f92c304d741 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 661 [Dec 30 2006] 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: WITNESS & RELENG_6 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, 04 Jan 2007 11:49:34 -0000 --xLfTzkWEurH/gki3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 04, 2007 at 06:43:27PM +0700, Eugene Grosbein wrote: > On Thu, Jan 04, 2007 at 01:02:08PM +0200, Kostik Belousov wrote: >=20 > > Hmm, it needs 1.198 as well. Below is aggregated patch against RELENG_6. > >=20 > > Index: kern_conf.c > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > RCS file: /usr/local/arch/ncvs/src/sys/kern/kern_conf.c,v > > retrieving revision 1.186.2.7 > > diff -u -r1.186.2.7 kern_conf.c > > --- kern_conf.c 30 Oct 2006 15:43:56 -0000 1.186.2.7 > > +++ kern_conf.c 4 Jan 2007 10:59:33 -0000 > > @@ -676,16 +676,20 @@ > > dev->si_flags &=3D ~SI_CLONELIST; > > } > > =20 > > + dev->si_refcount++; /* Avoid race with dev_rel() */ > > csw =3D dev->si_devsw; > > dev->si_devsw =3D NULL; /* already NULL for SI_ALIAS */ > > while (csw !=3D NULL && csw->d_purge !=3D NULL && dev->si_threadcount= ) { > > - printf("Purging %lu threads from %s\n", > > - dev->si_threadcount, devtoname(dev)); > > csw->d_purge(dev); > > msleep(csw, &devmtx, PRIBIO, "devprg", hz/10); > > + if (dev->si_threadcount) > > + printf("Still %lu threads in %s\n", > > + dev->si_threadcount, devtoname(dev)); > > + } > > + while (dev->si_threadcount !=3D 0) { > > + /* Use unique dummy wait ident */ > > + msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10); > > } > > - if (csw !=3D NULL && csw->d_purge !=3D NULL) > > - printf("All threads purged from %s\n", devtoname(dev)); > > =20 > > dev->si_drv1 =3D 0; > > dev->si_drv2 =3D 0; > > @@ -700,6 +704,7 @@ > > fini_cdevsw(csw); > > } > > dev->si_flags &=3D ~SI_ALIAS; > > + dev->si_refcount--; /* Avoid race with dev_rel() */ > > =20 > > if (dev->si_refcount > 0) { > > LIST_INSERT_HEAD(&dead_cdevsw.d_devs, dev, si_list); >=20 > I've tried. Now machine just hangs if I try to switch from X to vty. > It stays in graphics mode locked. Does it crash when exiting glxgears/some video player ? When hangs, does it answer ping/allow ssh connections ? --xLfTzkWEurH/gki3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFnOmhC3+MBN1Mb4gRAjryAKDLAszKpOORhnIB61ucTgRym4R01ACg0Tsg EHwo2hiUQqg0CR/tPkcrh8s= =0PT2 -----END PGP SIGNATURE----- --xLfTzkWEurH/gki3-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 12:06:11 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8AD2816A4FC for ; Thu, 4 Jan 2007 12:06:11 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id D80A013C4EA for ; Thu, 4 Jan 2007 12:06:08 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id l04C63jU086067; Thu, 4 Jan 2007 19:06:03 +0700 (KRAT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id l04C63Za086066; Thu, 4 Jan 2007 19:06:03 +0700 (KRAT) (envelope-from eugen) Date: Thu, 4 Jan 2007 19:06:03 +0700 From: Eugene Grosbein To: Kostik Belousov Message-ID: <20070104120603.GA84934@svzserv.kemerovo.su> References: <20070103141820.GA1014@grosbein.pp.ru> <200701031601.05541.jhb@freebsd.org> <20070104040727.GD21325@deviant.kiev.zoral.com.ua> <20070104103708.GF21325@deviant.kiev.zoral.com.ua> <20070104105208.GA78979@svzserv.kemerovo.su> <20070104110208.GG21325@deviant.kiev.zoral.com.ua> <20070104114327.GA81011@svzserv.kemerovo.su> <20070104114849.GH21325@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070104114849.GH21325@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: WITNESS & RELENG_6 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, 04 Jan 2007 12:06:12 -0000 On Thu, Jan 04, 2007 at 01:48:49PM +0200, Kostik Belousov wrote: > > I've tried. Now machine just hangs if I try to switch from X to vty. > > It stays in graphics mode locked. > > Does it crash when exiting glxgears/some video player ? It does not crash now when exiting glxgears but glxgears does not exit really, this process "hangs" in the "devdrn" state. mplayer hangs hard the whole system in the moment it switches to full-screen. > When hangs, does it answer ping/allow ssh connections ? Can't check just now, but can establish serial console if you wish. Eugene From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 12:13:05 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3AD8016A403 for ; Thu, 4 Jan 2007 12:13:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id D2C5113C45B for ; Thu, 4 Jan 2007 12:13:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.227] (helo=fw.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1H2RSn-000BTX-9C for freebsd-hackers@freebsd.org; Thu, 04 Jan 2007 14:13:01 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id l04CCj85037146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jan 2007 14:12:45 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id l04CCjDv021337; Thu, 4 Jan 2007 14:12:45 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id l04CCjHB021336; Thu, 4 Jan 2007 14:12:45 +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, 4 Jan 2007 14:12:45 +0200 From: Kostik Belousov To: Eugene Grosbein Message-ID: <20070104121245.GI21325@deviant.kiev.zoral.com.ua> References: <20070103141820.GA1014@grosbein.pp.ru> <200701031601.05541.jhb@freebsd.org> <20070104040727.GD21325@deviant.kiev.zoral.com.ua> <20070104103708.GF21325@deviant.kiev.zoral.com.ua> <20070104105208.GA78979@svzserv.kemerovo.su> <20070104110208.GG21325@deviant.kiev.zoral.com.ua> <20070104114327.GA81011@svzserv.kemerovo.su> <20070104114849.GH21325@deviant.kiev.zoral.com.ua> <20070104120603.GA84934@svzserv.kemerovo.su> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikCwydJVc3YoFZrT" Content-Disposition: inline In-Reply-To: <20070104120603.GA84934@svzserv.kemerovo.su> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-0.1 required=5.0 tests=ALL_TRUSTED,SPF_NEUTRAL autolearn=failed version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on fw.zoral.com.ua X-Scanner-Signature: bb9f355b5be917825c280d06cf0e20ab X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 661 [Dec 30 2006] 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: WITNESS & RELENG_6 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, 04 Jan 2007 12:13:05 -0000 --ikCwydJVc3YoFZrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 04, 2007 at 07:06:03PM +0700, Eugene Grosbein wrote: > On Thu, Jan 04, 2007 at 01:48:49PM +0200, Kostik Belousov wrote: >=20 > > > I've tried. Now machine just hangs if I try to switch from X to vty. > > > It stays in graphics mode locked. > >=20 > > Does it crash when exiting glxgears/some video player ? >=20 > It does not crash now when exiting glxgears but glxgears does not > exit really, this process "hangs" in the "devdrn" state. As expected. > mplayer hangs hard the whole system in the moment it switches to full-scr= een. > > When hangs, does it answer ping/allow ssh connections ? > Can't check just now, but can establish serial console if you wish. It would be better to check this in both cases (mplayer and return to vty). But, most likely, the problem is in nvidia driver that calls destroy_dev() from d_close(). You should ask the vendor for the fix. As a side note, responsible engineer is aware of the bug. --ikCwydJVc3YoFZrT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFnO88C3+MBN1Mb4gRAkpsAJ4mGaioAQTtCUoRPpcMUZM1gOgVMACfdy9l TDoZohFE2HE70HqsFG/WQDE= =qxiq -----END PGP SIGNATURE----- --ikCwydJVc3YoFZrT-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 07:37:38 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CFAAB16A403; Thu, 4 Jan 2007 07:37:38 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 8737F13C448; Thu, 4 Jan 2007 07:37:38 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5F451.dip.t-dialin.net [84.165.244.81]) by redbull.bpaserver.net (Postfix) with ESMTP id 205922E1BA; Thu, 4 Jan 2007 08:41:54 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 86CEC5B4847; Thu, 4 Jan 2007 08:37:31 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l047bSIP085011; Thu, 4 Jan 2007 08:37:28 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Thu, 04 Jan 2007 08:37:28 +0100 Message-ID: <20070104083728.3bs0ltbw84okk84g@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 04 Jan 2007 08:37:28 +0100 From: Alexander Leidinger To: Intron is my alias on the Internet References: <20070103122134.GA74544@stud.fit.vutbr.cz> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.864, required 6, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No X-Mailman-Approved-At: Thu, 04 Jan 2007 12:24:43 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org Subject: Re: Successfully Unbreak Adobe Reader 7.0.8 for the New Linux Emulator 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, 04 Jan 2007 07:37:38 -0000 Quoting Intron is my alias on the Internet (from Thu, 04 Jan 2007 06:05:25 +0800): > 2. Apply my new patch for /sys/compat/linux/linux_file.c: > http://ftp.intron.ac/tmp/linux_file.c.2.diff What about printing a message in the LINUX_O_NOATIME case (maybe only if bootverbose or debug)? Are there other flags which are not handled there? Maybe we should add some code to detect flags which we don't know about (adding the flags we know about to a variable when we see them, comparing this variable to the input and print a message when there's a difference). Bye, Alexander. -- A man is already halfway in love with any woman who listens to him. -- Brendan Francis http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 08:58:32 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6652816A407 for ; Thu, 4 Jan 2007 08:58:32 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 1E16113C455 for ; Thu, 4 Jan 2007 08:58:32 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5F451.dip.t-dialin.net [84.165.244.81]) by redbull.bpaserver.net (Postfix) with ESMTP id F08C02E205; Thu, 4 Jan 2007 10:02:44 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 822D95B4847; Thu, 4 Jan 2007 09:58:21 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l048wLmj098321; Thu, 4 Jan 2007 09:58:21 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Thu, 04 Jan 2007 09:58:21 +0100 Message-ID: <20070104095821.6aiio7gs4ccwwkks@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 04 Jan 2007 09:58:21 +0100 From: Alexander Leidinger To: Divacky Roman References: <20070103122134.GA74544@stud.fit.vutbr.cz> In-Reply-To: <20070103122134.GA74544@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-15.364, required 6, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14, SMILEY -0.50) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No X-Mailman-Approved-At: Thu, 04 Jan 2007 12:24:54 +0000 Cc: freebsd-hackers@freebsd.org, Intron is my alias on the Internet Subject: Re: Partially Unbreak Adobe Reader 7.0.8 for the New Linux Emulator 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, 04 Jan 2007 08:58:32 -0000 Quoting Divacky Roman (from Wed, 3 Jan =20 2007 13:21:34 +0100): > On Wed, Jan 03, 2007 at 07:47:28AM +0800, Intron is my alias on the =20 > Internet wrote: >> My patch for /sys/compat/linux/linux_file.c (7.0-CURRENT) can >> partially unbreak Adobe Reader 7.0.8 for Linux when the sysctl >> compat.linux.osrelease is set to "2.6.16". You may download the patch >> at: >> >> http://ftp.intron.ac/tmp/linux_file.c.diff > > this looks good. can you explain why this patch is not needed in 2.4 =20 > emulation? > I cannot imagine why this differs in 2.6 and 2.4... FC4 (glibc) behaves differently based upon the version of the emulated =20 kernel. Either acroread uses a part of glibc which behaves =20 differently, or acroread checks the version and behaves differently =20 too. Either way: I'm not surprised. ;-) Bye, Alexander. --=20 It is a wise father that knows his own child. =09=09-- William Shakespeare, "The Merchant of Venice" http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 09:03:55 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F3A516A403 for ; Thu, 4 Jan 2007 09:03:55 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 08DE813C441 for ; Thu, 4 Jan 2007 09:03:55 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5F451.dip.t-dialin.net [84.165.244.81]) by redbull.bpaserver.net (Postfix) with ESMTP id 0C1AA2E205; Thu, 4 Jan 2007 10:08:10 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 8D4D55B4847; Thu, 4 Jan 2007 10:03:46 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l0493kxP099323; Thu, 4 Jan 2007 10:03:46 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Thu, 04 Jan 2007 10:03:46 +0100 Message-ID: <20070104100346.dwrc6hrweoc4w4sc@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 04 Jan 2007 10:03:46 +0100 From: Alexander Leidinger To: Garrett Cooper References: <459C153E.5090801@u.washington.edu> In-Reply-To: <459C153E.5090801@u.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.864, required 6, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No X-Mailman-Approved-At: Thu, 04 Jan 2007 12:25:03 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: How to make an .so file for Linux binaries 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, 04 Jan 2007 09:03:55 -0000 Quoting Garrett Cooper (from Wed, 03 Jan =20 2007 12:42:38 -0800): > =09Trying to add Flashplayer 9 functionality to FreeBSD (via the > Linux binary and www/linux-pluginwrapper) and I was wondering how I > should go about determining which symbols need to be used in the .so > file, and also how I should go about including the files (#include for > the C files, `cat`, etc?). You should see complaints about missing symbols when you start the =20 browser on the console and the output is not redirected to /dev/null =20 (this may be done in a shell wrapper of the browser, you should =20 check). You can also use "nm" to have a look at missing symbols in the =20 .so. Regarding the last part of your question... have a look at what the =20 linux-pluginwrapper does. Note: linux-pluginwrapper will not work on 7-current because of symbol =20 versioning. Bye, Alexander. --=20 I don't make the rules, Gil, I only play the game. =09=09-- Cash McCall http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 11:02:36 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9EF5A16A403 for ; Thu, 4 Jan 2007 11:02:36 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id D66B213C442 for ; Thu, 4 Jan 2007 11:02:35 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id l04Aq8fD079675; Thu, 4 Jan 2007 17:52:08 +0700 (KRAT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id l04Aq8Yq079674; Thu, 4 Jan 2007 17:52:08 +0700 (KRAT) (envelope-from eugen) Date: Thu, 4 Jan 2007 17:52:08 +0700 From: Eugene Grosbein To: Kostik Belousov Message-ID: <20070104105208.GA78979@svzserv.kemerovo.su> References: <20070103141820.GA1014@grosbein.pp.ru> <200701031601.05541.jhb@freebsd.org> <20070104040727.GD21325@deviant.kiev.zoral.com.ua> <20070104103708.GF21325@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070104103708.GF21325@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Thu, 04 Jan 2007 12:25:16 +0000 Cc: freebsd-hackers@freebsd.org, Eugene Grosbein Subject: Re: WITNESS & RELENG_6 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, 04 Jan 2007 11:02:36 -0000 On Thu, Jan 04, 2007 at 12:37:08PM +0200, Kostik Belousov wrote: > The problem is revealed by INVARIANTS option, not by WITNESS, and is definitely the use-after-free. > > in src/nvidia_dev.c, nvidia_dev_close(), that is cdevsw.d_close proc, > the destroy_dev() is called. Please, apply rev. 1.199 of sys/kern/kern_conf.c. > I expect that crashes shall stop, but non-killable processes (in the "devdrn") > state would accumulate. > > Please, confirm. I've tried to apply 1.199 to RELENG_6 but failed: one of three chunks has been rejected. Eugene From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 11:08:16 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78B1A16A407 for ; Thu, 4 Jan 2007 11:08:16 +0000 (UTC) (envelope-from david@dcook09.wanadoo.co.uk) Received: from smtp1.freeserve.com (smtp1.wanadoo.co.uk [193.252.22.158]) by mx1.freebsd.org (Postfix) with ESMTP id 389C613C44B for ; Thu, 4 Jan 2007 11:08:16 +0000 (UTC) (envelope-from david@dcook09.wanadoo.co.uk) Received: from smtp1.freeserve.com (mwinf3003 [172.22.159.25]) by mwinf3005.me.freeserve.com (SMTP Server) with ESMTP id 11BE51000353 for ; Thu, 4 Jan 2007 11:41:50 +0100 (CET) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3003.me.freeserve.com (SMTP Server) with ESMTP id A85A21C002EB for ; Thu, 4 Jan 2007 11:41:47 +0100 (CET) Received: from davidsgodsend (user-54403548.l6.c3.dsl.pol.co.uk [84.64.53.72]) by mwinf3003.me.freeserve.com (SMTP Server) with SMTP id 230F21C002E5 for ; Thu, 4 Jan 2007 11:41:47 +0100 (CET) X-ME-UUID: 20070104104147144.230F21C002E5@mwinf3003.me.freeserve.com Message-ID: <000501c72fec$f27db360$6901a8c0@davidsgodsend> From: "david cook" To: Date: Thu, 4 Jan 2007 10:41:52 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 0701-0, 03/01/2007), Outbound message X-Antivirus-Status: Clean X-Mailman-Approved-At: Thu, 04 Jan 2007 12:25:33 +0000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: NVIDIA FreeBSD kernel feature requests 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, 04 Jan 2007 11:08:16 -0000 Hi I have got , a geforce 6600gt 256mb/ddr3=20 can you tell me ? if it will play hd games if ,I BUY a hd ready monitor, = david@dcook09.wanadoo.co.uk=20 your faithfully , d From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 11:43:30 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC4C316A403 for ; Thu, 4 Jan 2007 11:43:30 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 46E3813C45B for ; Thu, 4 Jan 2007 11:43:30 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id l04BhSd2084132; Thu, 4 Jan 2007 18:43:28 +0700 (KRAT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id l04BhRF6084131; Thu, 4 Jan 2007 18:43:27 +0700 (KRAT) (envelope-from eugen) Date: Thu, 4 Jan 2007 18:43:27 +0700 From: Eugene Grosbein To: Kostik Belousov Message-ID: <20070104114327.GA81011@svzserv.kemerovo.su> References: <20070103141820.GA1014@grosbein.pp.ru> <200701031601.05541.jhb@freebsd.org> <20070104040727.GD21325@deviant.kiev.zoral.com.ua> <20070104103708.GF21325@deviant.kiev.zoral.com.ua> <20070104105208.GA78979@svzserv.kemerovo.su> <20070104110208.GG21325@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070104110208.GG21325@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Thu, 04 Jan 2007 12:25:42 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: WITNESS & RELENG_6 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, 04 Jan 2007 11:43:30 -0000 On Thu, Jan 04, 2007 at 01:02:08PM +0200, Kostik Belousov wrote: > Hmm, it needs 1.198 as well. Below is aggregated patch against RELENG_6. > > Index: kern_conf.c > =================================================================== > RCS file: /usr/local/arch/ncvs/src/sys/kern/kern_conf.c,v > retrieving revision 1.186.2.7 > diff -u -r1.186.2.7 kern_conf.c > --- kern_conf.c 30 Oct 2006 15:43:56 -0000 1.186.2.7 > +++ kern_conf.c 4 Jan 2007 10:59:33 -0000 > @@ -676,16 +676,20 @@ > dev->si_flags &= ~SI_CLONELIST; > } > > + dev->si_refcount++; /* Avoid race with dev_rel() */ > csw = dev->si_devsw; > dev->si_devsw = NULL; /* already NULL for SI_ALIAS */ > while (csw != NULL && csw->d_purge != NULL && dev->si_threadcount) { > - printf("Purging %lu threads from %s\n", > - dev->si_threadcount, devtoname(dev)); > csw->d_purge(dev); > msleep(csw, &devmtx, PRIBIO, "devprg", hz/10); > + if (dev->si_threadcount) > + printf("Still %lu threads in %s\n", > + dev->si_threadcount, devtoname(dev)); > + } > + while (dev->si_threadcount != 0) { > + /* Use unique dummy wait ident */ > + msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10); > } > - if (csw != NULL && csw->d_purge != NULL) > - printf("All threads purged from %s\n", devtoname(dev)); > > dev->si_drv1 = 0; > dev->si_drv2 = 0; > @@ -700,6 +704,7 @@ > fini_cdevsw(csw); > } > dev->si_flags &= ~SI_ALIAS; > + dev->si_refcount--; /* Avoid race with dev_rel() */ > > if (dev->si_refcount > 0) { > LIST_INSERT_HEAD(&dead_cdevsw.d_devs, dev, si_list); I've tried. Now machine just hangs if I try to switch from X to vty. It stays in graphics mode locked. Eugene From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 14:32:55 2007 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6924316A416 for ; Thu, 4 Jan 2007 14:32:55 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id BCBE213C44C for ; Thu, 4 Jan 2007 14:32:54 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (jividq@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l04EWhQh057040; Thu, 4 Jan 2007 15:32:49 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l04EWgXA057039; Thu, 4 Jan 2007 15:32:42 +0100 (CET) (envelope-from olli) Date: Thu, 4 Jan 2007 15:32:42 +0100 (CET) Message-Id: <200701041432.l04EWgXA057039@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, imp@bsdimp.com, dougb@FreeBSD.ORG, erik.udo@gmail.com In-Reply-To: <20061231.005302.174088308.imp@bsdimp.com> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 04 Jan 2007 15:32:49 +0100 (CET) X-Mailman-Approved-At: Thu, 04 Jan 2007 14:49:16 +0000 Cc: Subject: Re: Init.c, making it chroot 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, 04 Jan 2007 14:32:55 -0000 M. Warner Losh wrote: > In message: <45975B7B.7030002@FreeBSD.org> > Doug Barton writes: > : Erik Udo wrote: > : > That's nice. But NetBSDs init.c executes /etc/rc before calling > : > chroot(), and that's what i'm looking for > : > : Sorry if I missed your rationale earlier, but could you perhaps > : explain a bit more about why you want to do this? I ask because I'm > : generally interested in boot-time issues, and this sounds like an > : interesting problem. > > This allows one to have a 'simple' /etc/rc that arranges things so > that a new '/' is ready to 'boot'. Sorry, I missed that part of the thread because I wasn't on Cc and didn't look at the list for a while. I've created (and tested!) a new patch. I've tested on RELENG_6, but I think init(8) isn't very different on HEAD, so it should work there, too. The patched init does the following: - If the kenv variable "init_script" is set, it is expected to be the name of a shell script that is executed before init(8) enters its usual state machine, and before chrooting (if requested, see below). If the script terminates with an exit code other than 0, single user mode is enforced. - If the kenv variable "init_chroot" is set, init(8) performs a chroot(2) operation into that directory. That happens after executing the init_script, if any, but before entering the usual state machine, i.e. before going into single or multi user mode. - A check is performed whether /dev is mounted (inside the chroot, if any). If not, it is mounted. - Afterwards, init(8) proceeds normally. It should be noted that the init_script can create or modify the "init_chroot" variable using the kenv(1) tool. So the chroot directory can be specified dynamically by the init_script; it does not have to be hardcoded in /boot/loader.conf. It should also be noted that the init_script requires a few files and directories to be present _outside_ of any chroot: /bin/sh /dev /lib/libc.so.6 /lib/libedit.so.5 /lib/libncurses.so.6 /libexec/ld-elf.so.1 Alternatively you can compile a static shell binary, then you only need /bin/sh and dev (I haven't tested this, though). Note that the /dev directory must exist (outside the chroot), because running the init_script requires certain devices (/dev/console). It is mounted by the kernel before starting init(8). As usual, have prepared an ISO image which tests and demonstrates the patch. It's 17.5 MB compressed: http://www.secnetix.de/tmp/init_chroot/ The /boot/loader.conf file looks like this: kernel_options="-C" init_path="/ochroot/sbin/init" init_script="/ochroot/etc/rc.init" init_chroot="/ochroot" The /ochroot/etc/rc.init just prints a few messages, so you can see that it actually does something. It does not have to be inside the chroot (I put it there because of convenience only). Any comments are welcome. I particularly appreciate if others test this stuff. Best regards Oliver PS: Here's the patch, relatve to rev. 1.60.2.2. I had to move some parts of the original code around, so the setup of the signal handlers happen before any script is run, and the mount of /dev happens afterwards. That's why the diff grew somewhat, even though my actual code changes aren't that many. For executing the init_script, I re-used the runcom() function which required a few minor modifications to it so it was a bit more flexible. In particular I had to move the _PATH_RUNCOM constant into a variable. --- src/sbin/init/init.c.orig Mon Aug 7 15:10:25 2006 +++ src/sbin/init/init.c Thu Jan 4 11:53:00 2007 @@ -55,6 +55,7 @@ #include #include #include +#include #include #include #include @@ -121,6 +122,7 @@ state_func_t catatonia(void); state_func_t death(void); +const char *runcom_script = _PATH_RUNCOM; enum { AUTOBOOT, FASTBOOT } runcom_mode = AUTOBOOT; #define FALSE 0 #define TRUE 1 @@ -187,6 +189,9 @@ int main(int argc, char *argv[]) { + char kenv_value[PATH_MAX]; + char ichroot_name[] = "init_chroot"; + char iscript_name[] = "init_script"; int c; struct sigaction sa; sigset_t mask; @@ -275,6 +280,66 @@ if (optind != argc) warning("ignoring excess arguments"); + /* + * We catch or block signals rather than ignore them, + * so that they get reset on exec. + */ + handle(badsys, SIGSYS, 0); + handle(disaster, SIGABRT, SIGFPE, SIGILL, SIGSEGV, + SIGBUS, SIGXCPU, SIGXFSZ, 0); + handle(transition_handler, SIGHUP, SIGINT, SIGTERM, SIGTSTP, + SIGUSR1, SIGUSR2, 0); + handle(alrm_handler, SIGALRM, 0); + sigfillset(&mask); + delset(&mask, SIGABRT, SIGFPE, SIGILL, SIGSEGV, SIGBUS, SIGSYS, + SIGXCPU, SIGXFSZ, SIGHUP, SIGINT, SIGTERM, SIGTSTP, SIGALRM, + SIGUSR1, SIGUSR2, 0); + sigprocmask(SIG_SETMASK, &mask, (sigset_t *) 0); + sigemptyset(&sa.sa_mask); + sa.sa_flags = 0; + sa.sa_handler = SIG_IGN; + (void) sigaction(SIGTTIN, &sa, (struct sigaction *)0); + (void) sigaction(SIGTTOU, &sa, (struct sigaction *)0); + + /* + * Paranoia. + */ + close(0); + close(1); + close(2); + + if (kenv(KENV_GET, iscript_name, kenv_value, sizeof(kenv_value)) > 0) { + runcom_script = kenv_value; + runcom(); + runcom_script = _PATH_RUNCOM; + if (requested_transition == 0) + requested_transition = runcom; + } + + if (kenv(KENV_GET, ichroot_name, kenv_value, sizeof(kenv_value)) > 0) { + if (chdir(kenv_value) != 0 || chroot(".") != 0) + warning("Can't chroot to %s: %m", kenv_value); + } + + /* + * Additional check if devfs needs to be mounted: + * If "/" and "/dev" have the same device number, + * then it hasn't been mounted yet. + */ + if (!devfs) { + struct stat stst; + dev_t root_devno; + + stat("/", &stst); + root_devno = stst.st_dev; + if (stat("/dev", &stst) != 0) + warning("Can't stat /dev: %m"); + else { + if (stst.st_dev == root_devno) + devfs++; + } + } + if (devfs) { struct iovec iov[4]; char *s; @@ -312,34 +377,6 @@ } /* - * We catch or block signals rather than ignore them, - * so that they get reset on exec. - */ - handle(badsys, SIGSYS, 0); - handle(disaster, SIGABRT, SIGFPE, SIGILL, SIGSEGV, - SIGBUS, SIGXCPU, SIGXFSZ, 0); - handle(transition_handler, SIGHUP, SIGINT, SIGTERM, SIGTSTP, - SIGUSR1, SIGUSR2, 0); - handle(alrm_handler, SIGALRM, 0); - sigfillset(&mask); - delset(&mask, SIGABRT, SIGFPE, SIGILL, SIGSEGV, SIGBUS, SIGSYS, - SIGXCPU, SIGXFSZ, SIGHUP, SIGINT, SIGTERM, SIGTSTP, SIGALRM, - SIGUSR1, SIGUSR2, 0); - sigprocmask(SIG_SETMASK, &mask, (sigset_t *) 0); - sigemptyset(&sa.sa_mask); - sa.sa_flags = 0; - sa.sa_handler = SIG_IGN; - (void) sigaction(SIGTTIN, &sa, (struct sigaction *)0); - (void) sigaction(SIGTTOU, &sa, (struct sigaction *)0); - - /* - * Paranoia. - */ - close(0); - close(1); - close(2); - - /* * Start the state machine. */ transition(requested_transition); @@ -733,11 +770,10 @@ setctty(_PATH_CONSOLE); char _sh[] = "sh"; - char _path_runcom[] = _PATH_RUNCOM; char _autoboot[] = "autoboot"; argv[0] = _sh; - argv[1] = _path_runcom; + argv[1] = __DECONST(char *, runcom_script); argv[2] = runcom_mode == AUTOBOOT ? _autoboot : 0; argv[3] = 0; @@ -747,13 +783,13 @@ setprocresources(RESOURCE_RC); #endif execv(_PATH_BSHELL, argv); - stall("can't exec %s for %s: %m", _PATH_BSHELL, _PATH_RUNCOM); + stall("can't exec %s for %s: %m", _PATH_BSHELL, runcom_script); _exit(1); /* force single user mode */ } if (pid == -1) { emergency("can't fork for %s on %s: %m", - _PATH_BSHELL, _PATH_RUNCOM); + _PATH_BSHELL, runcom_script); while (waitpid(-1, (int *) 0, WNOHANG) > 0) continue; sleep(STALL_TIMEOUT); @@ -773,12 +809,12 @@ if (errno == EINTR) continue; warning("wait for %s on %s failed: %m; going to single user mode", - _PATH_BSHELL, _PATH_RUNCOM); + _PATH_BSHELL, runcom_script); return (state_func_t) single_user; } if (wpid == pid && WIFSTOPPED(status)) { warning("init: %s on %s stopped, restarting\n", - _PATH_BSHELL, _PATH_RUNCOM); + _PATH_BSHELL, runcom_script); kill(pid, SIGCONT); wpid = -1; } @@ -796,7 +832,7 @@ if (!WIFEXITED(status)) { warning("%s on %s terminated abnormally, going to single user mode", - _PATH_BSHELL, _PATH_RUNCOM); + _PATH_BSHELL, runcom_script); return (state_func_t) single_user; } -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "The scanf() function is a large and complex beast that often does something almost but not quite entirely unlike what you desired." -- Chris Torek From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 15:27:58 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 324F316A412; Thu, 4 Jan 2007 15:27:58 +0000 (UTC) (envelope-from bsd@bsdhome.com) Received: from ms-smtp-04.southeast.rr.com (ms-smtp-04.southeast.rr.com [24.25.9.103]) by mx1.freebsd.org (Postfix) with ESMTP id E428013C455; Thu, 4 Jan 2007 15:27:57 +0000 (UTC) (envelope-from bsd@bsdhome.com) Received: from neutrino.bsdhome.com (cpe-071-070-208-236.nc.res.rr.com [71.70.208.236]) by ms-smtp-04.southeast.rr.com (8.13.6/8.13.6) with ESMTP id l04FRtNa014764; Thu, 4 Jan 2007 10:27:55 -0500 (EST) Received: from neutrino.bsdhome.com (localhost [127.0.0.1]) by neutrino.bsdhome.com (8.13.1/8.13.1) with ESMTP id l04FRscl094958; Thu, 4 Jan 2007 10:27:54 -0500 (EST) (envelope-from bsd@neutrino.bsdhome.com) Received: (from bsd@localhost) by neutrino.bsdhome.com (8.13.1/8.13.1/Submit) id l04FRsNA094957; Thu, 4 Jan 2007 10:27:54 -0500 (EST) (envelope-from bsd) Date: Thu, 4 Jan 2007 10:27:54 -0500 From: Brian Dean To: John Baldwin Message-ID: <20070104152754.GA94609@neutrino.bsdhome.com> References: <20061214190510.GA26590@neutrino.bsdhome.com> <552E24DE-C1D1-41B1-83D2-157F0A3E0449@bleepsoft.com> <200612272350.43680.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200612272350.43680.jhb@freebsd.org> User-Agent: Mutt/1.5.11 X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: freebsd-hackers@freebsd.org, "R. Tyler Ballance" , Brian Dean Subject: Re: Kernel hang on 6.x 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, 04 Jan 2007 15:27:58 -0000 On Wed, Dec 27, 2006 at 11:50:43PM -0500, John Baldwin wrote: > The 'traceall' seemed to miss several threads actually (like pid > 18). Can you get a 'ps'? Also, are you able to get a kernel dump > when this happens? I can't ps that particular session since it is no longer available, however I can reproduce another one and generate a new set of debug output. One note, the "swap_pager: indefinite wait buffer: ..." timeout message may have been a result of a misconfigured secondary swap file, so that might be a red herring. However, we can still reliably reproduce the hang with 32 Gig swap, but we don't get any console messages associated with it. The system is set up as a test system so I'm not under any pressure to get it rebooted and back up when it hangs, so I have the ability to take some time to debug it. I believe that I can generate a kernel dump. We tried this yesterday but didn't have a dump device configured. I think we've got that set up now and plan to generate a kernel dump. I'm assuming that since the process size and swap size is so large, that the dump size is going to be very large also, on the order of 32 Gig. I beleive I can host this on a server and make it accessible to you if you are willing to download it. -Brian From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 17:34:01 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 104D716A415 for ; Thu, 4 Jan 2007 17:34:01 +0000 (UTC) (envelope-from erik.udo@gmail.com) Received: from satakieli.dnainternet.net (satakieli.dnainternet.net [212.149.75.40]) by mx1.freebsd.org (Postfix) with ESMTP id A97F313C45D for ; Thu, 4 Jan 2007 17:34:00 +0000 (UTC) (envelope-from erik.udo@gmail.com) Received: from [192.168.1.11] (host-212-149-186-30.kpylaajakaista.net [212.149.186.30]) by satakieli.dnainternet.net (Postfix) with ESMTP id 1E65BC983; Thu, 4 Jan 2007 19:33:56 +0200 (EET) Message-ID: <459D3A7E.7070300@gmail.com> Date: Thu, 04 Jan 2007 19:33:50 +0200 From: Erik Udo User-Agent: Thunderbird 1.5.0.9 (X11/20061226) MIME-Version: 1.0 To: Oliver Fromme References: <200701041432.l04EWgXA057039@lurza.secnetix.de> In-Reply-To: <200701041432.l04EWgXA057039@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Init.c, making it chroot 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, 04 Jan 2007 17:34:01 -0000 PERFECT! Just what i needed. Thanks :) Oliver Fromme wrote: > M. Warner Losh wrote: > > In message: <45975B7B.7030002@FreeBSD.org> > > Doug Barton writes: > > : Erik Udo wrote: > > : > That's nice. But NetBSDs init.c executes /etc/rc before calling > > : > chroot(), and that's what i'm looking for > > : > > : Sorry if I missed your rationale earlier, but could you perhaps > > : explain a bit more about why you want to do this? I ask because I'm > > : generally interested in boot-time issues, and this sounds like an > > : interesting problem. > > > > This allows one to have a 'simple' /etc/rc that arranges things so > > that a new '/' is ready to 'boot'. > > Sorry, I missed that part of the thread because I wasn't > on Cc and didn't look at the list for a while. > > I've created (and tested!) a new patch. I've tested on > RELENG_6, but I think init(8) isn't very different on > HEAD, so it should work there, too. > > The patched init does the following: > > - If the kenv variable "init_script" is set, it is > expected to be the name of a shell script that is > executed before init(8) enters its usual state > machine, and before chrooting (if requested, see > below). If the script terminates with an exit code > other than 0, single user mode is enforced. > > - If the kenv variable "init_chroot" is set, init(8) > performs a chroot(2) operation into that directory. > That happens after executing the init_script, if > any, but before entering the usual state machine, > i.e. before going into single or multi user mode. > > - A check is performed whether /dev is mounted (inside > the chroot, if any). If not, it is mounted. > > - Afterwards, init(8) proceeds normally. > > It should be noted that the init_script can create or > modify the "init_chroot" variable using the kenv(1) > tool. So the chroot directory can be specified > dynamically by the init_script; it does not have to > be hardcoded in /boot/loader.conf. > > It should also be noted that the init_script requires > a few files and directories to be present _outside_ of > any chroot: > > /bin/sh > /dev > /lib/libc.so.6 > /lib/libedit.so.5 > /lib/libncurses.so.6 > /libexec/ld-elf.so.1 > > Alternatively you can compile a static shell binary, > then you only need /bin/sh and dev (I haven't tested > this, though). Note that the /dev directory must > exist (outside the chroot), because running the > init_script requires certain devices (/dev/console). > It is mounted by the kernel before starting init(8). > > As usual, have prepared an ISO image which tests and > demonstrates the patch. It's 17.5 MB compressed: > > http://www.secnetix.de/tmp/init_chroot/ > > The /boot/loader.conf file looks like this: > > kernel_options="-C" > init_path="/ochroot/sbin/init" > init_script="/ochroot/etc/rc.init" > init_chroot="/ochroot" > > The /ochroot/etc/rc.init just prints a few messages, > so you can see that it actually does something. It > does not have to be inside the chroot (I put it there > because of convenience only). > > Any comments are welcome. I particularly appreciate > if others test this stuff. > > Best regards > Oliver > > PS: Here's the patch, relatve to rev. 1.60.2.2. > > I had to move some parts of the original code around, > so the setup of the signal handlers happen before any > script is run, and the mount of /dev happens afterwards. > That's why the diff grew somewhat, even though my actual > code changes aren't that many. > > For executing the init_script, I re-used the runcom() > function which required a few minor modifications to it > so it was a bit more flexible. In particular I had to > move the _PATH_RUNCOM constant into a variable. > > --- src/sbin/init/init.c.orig Mon Aug 7 15:10:25 2006 > +++ src/sbin/init/init.c Thu Jan 4 11:53:00 2007 > @@ -55,6 +55,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -121,6 +122,7 @@ > state_func_t catatonia(void); > state_func_t death(void); > > +const char *runcom_script = _PATH_RUNCOM; > enum { AUTOBOOT, FASTBOOT } runcom_mode = AUTOBOOT; > #define FALSE 0 > #define TRUE 1 > @@ -187,6 +189,9 @@ > int > main(int argc, char *argv[]) > { > + char kenv_value[PATH_MAX]; > + char ichroot_name[] = "init_chroot"; > + char iscript_name[] = "init_script"; > int c; > struct sigaction sa; > sigset_t mask; > @@ -275,6 +280,66 @@ > if (optind != argc) > warning("ignoring excess arguments"); > > + /* > + * We catch or block signals rather than ignore them, > + * so that they get reset on exec. > + */ > + handle(badsys, SIGSYS, 0); > + handle(disaster, SIGABRT, SIGFPE, SIGILL, SIGSEGV, > + SIGBUS, SIGXCPU, SIGXFSZ, 0); > + handle(transition_handler, SIGHUP, SIGINT, SIGTERM, SIGTSTP, > + SIGUSR1, SIGUSR2, 0); > + handle(alrm_handler, SIGALRM, 0); > + sigfillset(&mask); > + delset(&mask, SIGABRT, SIGFPE, SIGILL, SIGSEGV, SIGBUS, SIGSYS, > + SIGXCPU, SIGXFSZ, SIGHUP, SIGINT, SIGTERM, SIGTSTP, SIGALRM, > + SIGUSR1, SIGUSR2, 0); > + sigprocmask(SIG_SETMASK, &mask, (sigset_t *) 0); > + sigemptyset(&sa.sa_mask); > + sa.sa_flags = 0; > + sa.sa_handler = SIG_IGN; > + (void) sigaction(SIGTTIN, &sa, (struct sigaction *)0); > + (void) sigaction(SIGTTOU, &sa, (struct sigaction *)0); > + > + /* > + * Paranoia. > + */ > + close(0); > + close(1); > + close(2); > + > + if (kenv(KENV_GET, iscript_name, kenv_value, sizeof(kenv_value)) > 0) { > + runcom_script = kenv_value; > + runcom(); > + runcom_script = _PATH_RUNCOM; > + if (requested_transition == 0) > + requested_transition = runcom; > + } > + > + if (kenv(KENV_GET, ichroot_name, kenv_value, sizeof(kenv_value)) > 0) { > + if (chdir(kenv_value) != 0 || chroot(".") != 0) > + warning("Can't chroot to %s: %m", kenv_value); > + } > + > + /* > + * Additional check if devfs needs to be mounted: > + * If "/" and "/dev" have the same device number, > + * then it hasn't been mounted yet. > + */ > + if (!devfs) { > + struct stat stst; > + dev_t root_devno; > + > + stat("/", &stst); > + root_devno = stst.st_dev; > + if (stat("/dev", &stst) != 0) > + warning("Can't stat /dev: %m"); > + else { > + if (stst.st_dev == root_devno) > + devfs++; > + } > + } > + > if (devfs) { > struct iovec iov[4]; > char *s; > @@ -312,34 +377,6 @@ > } > > /* > - * We catch or block signals rather than ignore them, > - * so that they get reset on exec. > - */ > - handle(badsys, SIGSYS, 0); > - handle(disaster, SIGABRT, SIGFPE, SIGILL, SIGSEGV, > - SIGBUS, SIGXCPU, SIGXFSZ, 0); > - handle(transition_handler, SIGHUP, SIGINT, SIGTERM, SIGTSTP, > - SIGUSR1, SIGUSR2, 0); > - handle(alrm_handler, SIGALRM, 0); > - sigfillset(&mask); > - delset(&mask, SIGABRT, SIGFPE, SIGILL, SIGSEGV, SIGBUS, SIGSYS, > - SIGXCPU, SIGXFSZ, SIGHUP, SIGINT, SIGTERM, SIGTSTP, SIGALRM, > - SIGUSR1, SIGUSR2, 0); > - sigprocmask(SIG_SETMASK, &mask, (sigset_t *) 0); > - sigemptyset(&sa.sa_mask); > - sa.sa_flags = 0; > - sa.sa_handler = SIG_IGN; > - (void) sigaction(SIGTTIN, &sa, (struct sigaction *)0); > - (void) sigaction(SIGTTOU, &sa, (struct sigaction *)0); > - > - /* > - * Paranoia. > - */ > - close(0); > - close(1); > - close(2); > - > - /* > * Start the state machine. > */ > transition(requested_transition); > @@ -733,11 +770,10 @@ > setctty(_PATH_CONSOLE); > > char _sh[] = "sh"; > - char _path_runcom[] = _PATH_RUNCOM; > char _autoboot[] = "autoboot"; > > argv[0] = _sh; > - argv[1] = _path_runcom; > + argv[1] = __DECONST(char *, runcom_script); > argv[2] = runcom_mode == AUTOBOOT ? _autoboot : 0; > argv[3] = 0; > > @@ -747,13 +783,13 @@ > setprocresources(RESOURCE_RC); > #endif > execv(_PATH_BSHELL, argv); > - stall("can't exec %s for %s: %m", _PATH_BSHELL, _PATH_RUNCOM); > + stall("can't exec %s for %s: %m", _PATH_BSHELL, runcom_script); > _exit(1); /* force single user mode */ > } > > if (pid == -1) { > emergency("can't fork for %s on %s: %m", > - _PATH_BSHELL, _PATH_RUNCOM); > + _PATH_BSHELL, runcom_script); > while (waitpid(-1, (int *) 0, WNOHANG) > 0) > continue; > sleep(STALL_TIMEOUT); > @@ -773,12 +809,12 @@ > if (errno == EINTR) > continue; > warning("wait for %s on %s failed: %m; going to single user mode", > - _PATH_BSHELL, _PATH_RUNCOM); > + _PATH_BSHELL, runcom_script); > return (state_func_t) single_user; > } > if (wpid == pid && WIFSTOPPED(status)) { > warning("init: %s on %s stopped, restarting\n", > - _PATH_BSHELL, _PATH_RUNCOM); > + _PATH_BSHELL, runcom_script); > kill(pid, SIGCONT); > wpid = -1; > } > @@ -796,7 +832,7 @@ > > if (!WIFEXITED(status)) { > warning("%s on %s terminated abnormally, going to single user mode", > - _PATH_BSHELL, _PATH_RUNCOM); > + _PATH_BSHELL, runcom_script); > return (state_func_t) single_user; > } > > > > From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 17:45:25 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D6B8F16A40F; Thu, 4 Jan 2007 17:45:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 649EB13C4AC; Thu, 4 Jan 2007 17:45:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l04HjGsL031320; Thu, 4 Jan 2007 12:45:18 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 4 Jan 2007 12:35:36 -0500 User-Agent: KMail/1.9.1 References: <200701041432.l04EWgXA057039@lurza.secnetix.de> In-Reply-To: <200701041432.l04EWgXA057039@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701041235.37141.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 04 Jan 2007 12:45:18 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2413/Thu Jan 4 04:46:27 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: erik.udo@gmail.com, dougb@freebsd.org, Oliver Fromme Subject: Re: Init.c, making it chroot 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, 04 Jan 2007 17:45:25 -0000 On Thursday 04 January 2007 09:32, Oliver Fromme wrote: > M. Warner Losh wrote: > > In message: <45975B7B.7030002@FreeBSD.org> > > Doug Barton writes: > > : Erik Udo wrote: > > : > That's nice. But NetBSDs init.c executes /etc/rc before calling > > : > chroot(), and that's what i'm looking for > > : > > : Sorry if I missed your rationale earlier, but could you perhaps > > : explain a bit more about why you want to do this? I ask because I'm > > : generally interested in boot-time issues, and this sounds like an > > : interesting problem. > > > > This allows one to have a 'simple' /etc/rc that arranges things so > > that a new '/' is ready to 'boot'. > > I've created (and tested!) a new patch. I've tested on > RELENG_6, but I think init(8) isn't very different on > HEAD, so it should work there, too. > > Any comments are welcome. I particularly appreciate > if others test this stuff. Some things I noticed: - Why do you have the 'ichroot_name' and 'iscript_name' variables? I would just pass the string literal to the kenv() function, e.g. if (kenv(KENV_GET, "init_script", kenv_value, sizeof(kenv_value)) > 0) { I think that putting the constant right there is easier for someone who is reading the code to see what is going on. - Rather than abusing a global runcom_script variable that you change to get side effects when you invoke runcom(), why not change runcom() to take a single 'char *script' as an argument and just pass _PATH_RUNCOM or kenv_value as appropriate and get rid of the global runcom_script variable? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 17:45:26 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 647AF16A47B for ; Thu, 4 Jan 2007 17:45:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id EA93F13C45E for ; Thu, 4 Jan 2007 17:45:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l04HjGsM031320; Thu, 4 Jan 2007 12:45:23 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 4 Jan 2007 12:45:34 -0500 User-Agent: KMail/1.9.1 References: <006301c72f93$0ffceb40$b3db87d4@multiplay.co.uk> In-Reply-To: <006301c72f93$0ffceb40$b3db87d4@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701041245.34582.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 04 Jan 2007 12:45:24 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2413/Thu Jan 4 04:46:27 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Steven Hartland Subject: Re: hptmv not compatible with WITNESS / INVARIANTS pointers required 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, 04 Jan 2007 17:45:26 -0000 On Wednesday 03 January 2007 18:58, Steven Hartland wrote: > I'm currently trying to debug an issue with Tyan s2892 > based machine but when I enable WITNESS / INVARIANTS > the Highpoint 182x driver panics the kernel with: > panic: blocakble sleep lock ( sleep mutex ) > 128 @ vm/uma_core.c: 1845 > > I believe this is due to the fact that you cant hold > a spin mutex while using: bus_dma_tag_create, malloc > bus_dmamem_alloc etc which the driver currently does, > but I have no experience with drivers hence dont know > what it should be doing instead. > > If someone's willing to give me some pointers I'd be > willing to give creating a patch and testing it a go. > > Here's a snipet of what I think is causing the issue: > /* This uses a mtx_lock_spin */ > intrmask_t oldspl = lock_driver(); > > pAdapter->next = 0; > > if(gIal_Adapter == 0) { > gIal_Adapter = pAdapter; > pCurAdapter = gIal_Adapter; > } else { > pCurAdapter->next = pAdapter; > pCurAdapter = pAdapter; > } > > pAdapter->outstandingCommands = 0; > > pMvSataAdapter = &(pAdapter->mvSataAdapter); > _vbus_p->OsExt = (void *)pAdapter; > pMvSataAdapter->IALData = pAdapter; > > /* Errors due to lock_driver holding mtx_lock_spin?? */ > if (bus_dma_tag_create(NULL, 1, 0, BUS_SPACE_MAXADDR_32BIT, > BUS_SPACE_MAXADDR, NULL, NULL, BUS_SPACE_MAXSIZE_32BIT, > MV_MAX_SEGMENTS, BUS_SPACE_MAXSIZE_32BIT, 0, NULL, NULL, > &pAdapter->parent_dmat) != 0) { > MV_ERROR("RR182x: Failed to create busdma resources\n"); > unlock_driver(oldspl); > return (ENOMEM); > } I would start off making it use a regular mutex (it doesn't need a spin mutex anyway). It also doesn't need any locking during the init_adapter() routine so I've removed that as well. Try this: Index: entry.c =================================================================== RCS file: /usr/cvs/src/sys/dev/hptmv/entry.c,v retrieving revision 1.12 diff -u -r1.12 entry.c --- entry.c 16 May 2006 14:36:25 -0000 1.12 +++ entry.c 4 Jan 2007 17:44:12 -0000 @@ -166,12 +166,12 @@ { intrmask_t spl = 0; - mtx_lock_spin(&driver_lock); + mtx_lock(&driver_lock); return spl; } void unlock_driver(intrmask_t spl) { - mtx_unlock_spin(&driver_lock); + mtx_unlock(&driver_lock); } #else static int driver_locked = 0; @@ -1168,7 +1168,7 @@ #if __FreeBSD_version >= 500000 static void hpt_init(void *dummy) { - mtx_init(&driver_lock, "hptlock", NULL, MTX_SPIN); + mtx_init(&driver_lock, "hptlock", NULL, MTX_DEF); } SYSINIT(hptinit, SI_SUB_CONFIGURE, SI_ORDER_FIRST, hpt_init, NULL); #endif @@ -1183,8 +1183,6 @@ PVDevice pVDev; - intrmask_t oldspl = lock_driver(); - pAdapter->next = 0; if(gIal_Adapter == 0){ @@ -1225,7 +1223,6 @@ if (hptmv_allocate_edma_queues(pAdapter)) { MV_ERROR("RR182x: Failed to allocate memory for EDMA queues\n"); - unlock_driver(oldspl); return ENOMEM; } @@ -1238,7 +1235,6 @@ { MV_ERROR("RR182x: Failed to remap memory space\n"); hptmv_free_edma_queues(pAdapter); - unlock_driver(oldspl); return ENXIO; } else @@ -1268,7 +1264,6 @@ unregister: bus_release_resource(pAdapter->hpt_dev, SYS_RES_MEMORY, rid, pAdapter->mem_res); hptmv_free_edma_queues(pAdapter); - unlock_driver(oldspl); return ENXIO; } pAdapter->ver_601 = pMvSataAdapter->pcbVersion; @@ -1411,7 +1406,6 @@ #endif mvSataUnmaskAdapterInterrupt(pMvSataAdapter); - unlock_driver(oldspl); return 0; } -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 17:51:17 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ADAB216A412 for ; Thu, 4 Jan 2007 17:51:17 +0000 (UTC) (envelope-from erik.udo@gmail.com) Received: from satakieli.dnainternet.net (satakieli.dnainternet.net [212.149.75.40]) by mx1.freebsd.org (Postfix) with ESMTP id 5401D13C468 for ; Thu, 4 Jan 2007 17:51:17 +0000 (UTC) (envelope-from erik.udo@gmail.com) Received: from [192.168.1.11] (host-212-149-186-30.kpylaajakaista.net [212.149.186.30]) by satakieli.dnainternet.net (Postfix) with ESMTP id 4DB55CA4B; Thu, 4 Jan 2007 19:51:15 +0200 (EET) Message-ID: <459D3E8E.10903@gmail.com> Date: Thu, 04 Jan 2007 19:51:10 +0200 From: Erik Udo User-Agent: Thunderbird 1.5.0.9 (X11/20061226) MIME-Version: 1.0 To: Oliver Fromme References: <200701041432.l04EWgXA057039@lurza.secnetix.de> In-Reply-To: <200701041432.l04EWgXA057039@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Init.c, making it chroot 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, 04 Jan 2007 17:51:17 -0000 Oh and i tested it on 6.1-RELEASE on my own livecd. It works! Oliver Fromme wrote: > M. Warner Losh wrote: > > In message: <45975B7B.7030002@FreeBSD.org> > > Doug Barton writes: > > : Erik Udo wrote: > > : > That's nice. But NetBSDs init.c executes /etc/rc before calling > > : > chroot(), and that's what i'm looking for > > : > > : Sorry if I missed your rationale earlier, but could you perhaps > > : explain a bit more about why you want to do this? I ask because I'm > > : generally interested in boot-time issues, and this sounds like an > > : interesting problem. > > > > This allows one to have a 'simple' /etc/rc that arranges things so > > that a new '/' is ready to 'boot'. > > Sorry, I missed that part of the thread because I wasn't > on Cc and didn't look at the list for a while. > > I've created (and tested!) a new patch. I've tested on > RELENG_6, but I think init(8) isn't very different on > HEAD, so it should work there, too. > > The patched init does the following: > > - If the kenv variable "init_script" is set, it is > expected to be the name of a shell script that is > executed before init(8) enters its usual state > machine, and before chrooting (if requested, see > below). If the script terminates with an exit code > other than 0, single user mode is enforced. > > - If the kenv variable "init_chroot" is set, init(8) > performs a chroot(2) operation into that directory. > That happens after executing the init_script, if > any, but before entering the usual state machine, > i.e. before going into single or multi user mode. > > - A check is performed whether /dev is mounted (inside > the chroot, if any). If not, it is mounted. > > - Afterwards, init(8) proceeds normally. > > It should be noted that the init_script can create or > modify the "init_chroot" variable using the kenv(1) > tool. So the chroot directory can be specified > dynamically by the init_script; it does not have to > be hardcoded in /boot/loader.conf. > > It should also be noted that the init_script requires > a few files and directories to be present _outside_ of > any chroot: > > /bin/sh > /dev > /lib/libc.so.6 > /lib/libedit.so.5 > /lib/libncurses.so.6 > /libexec/ld-elf.so.1 > > Alternatively you can compile a static shell binary, > then you only need /bin/sh and dev (I haven't tested > this, though). Note that the /dev directory must > exist (outside the chroot), because running the > init_script requires certain devices (/dev/console). > It is mounted by the kernel before starting init(8). > > As usual, have prepared an ISO image which tests and > demonstrates the patch. It's 17.5 MB compressed: > > http://www.secnetix.de/tmp/init_chroot/ > > The /boot/loader.conf file looks like this: > > kernel_options="-C" > init_path="/ochroot/sbin/init" > init_script="/ochroot/etc/rc.init" > init_chroot="/ochroot" > > The /ochroot/etc/rc.init just prints a few messages, > so you can see that it actually does something. It > does not have to be inside the chroot (I put it there > because of convenience only). > > Any comments are welcome. I particularly appreciate > if others test this stuff. > > Best regards > Oliver > > PS: Here's the patch, relatve to rev. 1.60.2.2. > > I had to move some parts of the original code around, > so the setup of the signal handlers happen before any > script is run, and the mount of /dev happens afterwards. > That's why the diff grew somewhat, even though my actual > code changes aren't that many. > > For executing the init_script, I re-used the runcom() > function which required a few minor modifications to it > so it was a bit more flexible. In particular I had to > move the _PATH_RUNCOM constant into a variable. > > --- src/sbin/init/init.c.orig Mon Aug 7 15:10:25 2006 > +++ src/sbin/init/init.c Thu Jan 4 11:53:00 2007 > @@ -55,6 +55,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -121,6 +122,7 @@ > state_func_t catatonia(void); > state_func_t death(void); > > +const char *runcom_script = _PATH_RUNCOM; > enum { AUTOBOOT, FASTBOOT } runcom_mode = AUTOBOOT; > #define FALSE 0 > #define TRUE 1 > @@ -187,6 +189,9 @@ > int > main(int argc, char *argv[]) > { > + char kenv_value[PATH_MAX]; > + char ichroot_name[] = "init_chroot"; > + char iscript_name[] = "init_script"; > int c; > struct sigaction sa; > sigset_t mask; > @@ -275,6 +280,66 @@ > if (optind != argc) > warning("ignoring excess arguments"); > > + /* > + * We catch or block signals rather than ignore them, > + * so that they get reset on exec. > + */ > + handle(badsys, SIGSYS, 0); > + handle(disaster, SIGABRT, SIGFPE, SIGILL, SIGSEGV, > + SIGBUS, SIGXCPU, SIGXFSZ, 0); > + handle(transition_handler, SIGHUP, SIGINT, SIGTERM, SIGTSTP, > + SIGUSR1, SIGUSR2, 0); > + handle(alrm_handler, SIGALRM, 0); > + sigfillset(&mask); > + delset(&mask, SIGABRT, SIGFPE, SIGILL, SIGSEGV, SIGBUS, SIGSYS, > + SIGXCPU, SIGXFSZ, SIGHUP, SIGINT, SIGTERM, SIGTSTP, SIGALRM, > + SIGUSR1, SIGUSR2, 0); > + sigprocmask(SIG_SETMASK, &mask, (sigset_t *) 0); > + sigemptyset(&sa.sa_mask); > + sa.sa_flags = 0; > + sa.sa_handler = SIG_IGN; > + (void) sigaction(SIGTTIN, &sa, (struct sigaction *)0); > + (void) sigaction(SIGTTOU, &sa, (struct sigaction *)0); > + > + /* > + * Paranoia. > + */ > + close(0); > + close(1); > + close(2); > + > + if (kenv(KENV_GET, iscript_name, kenv_value, sizeof(kenv_value)) > 0) { > + runcom_script = kenv_value; > + runcom(); > + runcom_script = _PATH_RUNCOM; > + if (requested_transition == 0) > + requested_transition = runcom; > + } > + > + if (kenv(KENV_GET, ichroot_name, kenv_value, sizeof(kenv_value)) > 0) { > + if (chdir(kenv_value) != 0 || chroot(".") != 0) > + warning("Can't chroot to %s: %m", kenv_value); > + } > + > + /* > + * Additional check if devfs needs to be mounted: > + * If "/" and "/dev" have the same device number, > + * then it hasn't been mounted yet. > + */ > + if (!devfs) { > + struct stat stst; > + dev_t root_devno; > + > + stat("/", &stst); > + root_devno = stst.st_dev; > + if (stat("/dev", &stst) != 0) > + warning("Can't stat /dev: %m"); > + else { > + if (stst.st_dev == root_devno) > + devfs++; > + } > + } > + > if (devfs) { > struct iovec iov[4]; > char *s; > @@ -312,34 +377,6 @@ > } > > /* > - * We catch or block signals rather than ignore them, > - * so that they get reset on exec. > - */ > - handle(badsys, SIGSYS, 0); > - handle(disaster, SIGABRT, SIGFPE, SIGILL, SIGSEGV, > - SIGBUS, SIGXCPU, SIGXFSZ, 0); > - handle(transition_handler, SIGHUP, SIGINT, SIGTERM, SIGTSTP, > - SIGUSR1, SIGUSR2, 0); > - handle(alrm_handler, SIGALRM, 0); > - sigfillset(&mask); > - delset(&mask, SIGABRT, SIGFPE, SIGILL, SIGSEGV, SIGBUS, SIGSYS, > - SIGXCPU, SIGXFSZ, SIGHUP, SIGINT, SIGTERM, SIGTSTP, SIGALRM, > - SIGUSR1, SIGUSR2, 0); > - sigprocmask(SIG_SETMASK, &mask, (sigset_t *) 0); > - sigemptyset(&sa.sa_mask); > - sa.sa_flags = 0; > - sa.sa_handler = SIG_IGN; > - (void) sigaction(SIGTTIN, &sa, (struct sigaction *)0); > - (void) sigaction(SIGTTOU, &sa, (struct sigaction *)0); > - > - /* > - * Paranoia. > - */ > - close(0); > - close(1); > - close(2); > - > - /* > * Start the state machine. > */ > transition(requested_transition); > @@ -733,11 +770,10 @@ > setctty(_PATH_CONSOLE); > > char _sh[] = "sh"; > - char _path_runcom[] = _PATH_RUNCOM; > char _autoboot[] = "autoboot"; > > argv[0] = _sh; > - argv[1] = _path_runcom; > + argv[1] = __DECONST(char *, runcom_script); > argv[2] = runcom_mode == AUTOBOOT ? _autoboot : 0; > argv[3] = 0; > > @@ -747,13 +783,13 @@ > setprocresources(RESOURCE_RC); > #endif > execv(_PATH_BSHELL, argv); > - stall("can't exec %s for %s: %m", _PATH_BSHELL, _PATH_RUNCOM); > + stall("can't exec %s for %s: %m", _PATH_BSHELL, runcom_script); > _exit(1); /* force single user mode */ > } > > if (pid == -1) { > emergency("can't fork for %s on %s: %m", > - _PATH_BSHELL, _PATH_RUNCOM); > + _PATH_BSHELL, runcom_script); > while (waitpid(-1, (int *) 0, WNOHANG) > 0) > continue; > sleep(STALL_TIMEOUT); > @@ -773,12 +809,12 @@ > if (errno == EINTR) > continue; > warning("wait for %s on %s failed: %m; going to single user mode", > - _PATH_BSHELL, _PATH_RUNCOM); > + _PATH_BSHELL, runcom_script); > return (state_func_t) single_user; > } > if (wpid == pid && WIFSTOPPED(status)) { > warning("init: %s on %s stopped, restarting\n", > - _PATH_BSHELL, _PATH_RUNCOM); > + _PATH_BSHELL, runcom_script); > kill(pid, SIGCONT); > wpid = -1; > } > @@ -796,7 +832,7 @@ > > if (!WIFEXITED(status)) { > warning("%s on %s terminated abnormally, going to single user mode", > - _PATH_BSHELL, _PATH_RUNCOM); > + _PATH_BSHELL, runcom_script); > return (state_func_t) single_user; > } > > > > From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 18:08:12 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7014816A40F for ; Thu, 4 Jan 2007 18:08:12 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id DCB2313C442 for ; Thu, 4 Jan 2007 18:08:11 +0000 (UTC) (envelope-from killing@multiplay.co.uk) X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on core6.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-24.7 required=6.0 tests=BAYES_00, USER_IN_WHITELIST, USER_IN_WHITELIST_TO autolearn=ham version=3.1.5 Received: from vader ([85.236.96.60]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.5.4) with ESMTP id md50003358570.msg; Thu, 04 Jan 2007 18:03:32 +0000 Message-ID: <012401c7302a$a49d2430$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: "John Baldwin" , References: <006301c72f93$0ffceb40$b3db87d4@multiplay.co.uk> <200701041245.34582.jhb@freebsd.org> Date: Thu, 4 Jan 2007 18:03:19 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-MDRemoteIP: 85.236.96.60 X-Return-Path: killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-Spam-Processed: multiplay.co.uk, Thu, 04 Jan 2007 18:03:32 +0000 X-MDAV-Processed: multiplay.co.uk, Thu, 04 Jan 2007 18:03:32 +0000 Cc: Subject: Re: hptmv not compatible with WITNESS / INVARIANTS pointers required 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, 04 Jan 2007 18:08:12 -0000 Thanks john, I'll try applying that later tonight should apply cleanly even though I'm using v1.14 of the driver I dont think there are any changes in these areas. N.B. Already contacted Scott Long to get the v1.14 imported as it contains a number of critical fixes. Steve John Baldwin wrote: > On Wednesday 03 January 2007 18:58, Steven Hartland wrote: >> I'm currently trying to debug an issue with Tyan s2892 >> based machine but when I enable WITNESS / INVARIANTS >> the Highpoint 182x driver panics the kernel with: >> panic: blocakble sleep lock ( sleep mutex ) >> 128 @ vm/uma_core.c: 1845 >> >> I believe this is due to the fact that you cant hold >> a spin mutex while using: bus_dma_tag_create, malloc >> bus_dmamem_alloc etc which the driver currently does, >> but I have no experience with drivers hence dont know >> what it should be doing instead. >> >> If someone's willing to give me some pointers I'd be >> willing to give creating a patch and testing it a go. >> >> Here's a snipet of what I think is causing the issue: >> /* This uses a mtx_lock_spin */ >> intrmask_t oldspl = lock_driver(); >> >> pAdapter->next = 0; >> >> if(gIal_Adapter == 0) { >> gIal_Adapter = pAdapter; >> pCurAdapter = gIal_Adapter; >> } else { >> pCurAdapter->next = pAdapter; >> pCurAdapter = pAdapter; >> } >> >> pAdapter->outstandingCommands = 0; >> >> pMvSataAdapter = &(pAdapter->mvSataAdapter); >> _vbus_p->OsExt = (void *)pAdapter; >> pMvSataAdapter->IALData = pAdapter; >> >> /* Errors due to lock_driver holding mtx_lock_spin?? */ >> if (bus_dma_tag_create(NULL, 1, 0, BUS_SPACE_MAXADDR_32BIT, >> BUS_SPACE_MAXADDR, NULL, NULL, BUS_SPACE_MAXSIZE_32BIT, >> MV_MAX_SEGMENTS, BUS_SPACE_MAXSIZE_32BIT, 0, NULL, NULL, >> &pAdapter->parent_dmat) != 0) { >> MV_ERROR("RR182x: Failed to create busdma resources\n"); >> unlock_driver(oldspl); >> return (ENOMEM); >> } > > I would start off making it use a regular mutex (it doesn't need a > spin mutex anyway). It also doesn't need any locking during the > init_adapter() routine so I've removed that as well. Try this: > > Index: entry.c > =================================================================== > RCS file: /usr/cvs/src/sys/dev/hptmv/entry.c,v > retrieving revision 1.12 > diff -u -r1.12 entry.c > --- entry.c 16 May 2006 14:36:25 -0000 1.12 > +++ entry.c 4 Jan 2007 17:44:12 -0000 > @@ -166,12 +166,12 @@ > { > > intrmask_t spl = 0; > - mtx_lock_spin(&driver_lock); > + mtx_lock(&driver_lock); > return spl; > } > void unlock_driver(intrmask_t spl) > { > - mtx_unlock_spin(&driver_lock); > + mtx_unlock(&driver_lock); > } > #else > static int driver_locked = 0; > @@ -1168,7 +1168,7 @@ > #if __FreeBSD_version >= 500000 > static void hpt_init(void *dummy) > { > - mtx_init(&driver_lock, "hptlock", NULL, MTX_SPIN); > + mtx_init(&driver_lock, "hptlock", NULL, MTX_DEF); > } > SYSINIT(hptinit, SI_SUB_CONFIGURE, SI_ORDER_FIRST, hpt_init, NULL); > #endif > @@ -1183,8 +1183,6 @@ > > PVDevice pVDev; > > - intrmask_t oldspl = lock_driver(); > - > pAdapter->next = 0; > > if(gIal_Adapter == 0){ > @@ -1225,7 +1223,6 @@ > if (hptmv_allocate_edma_queues(pAdapter)) > { > MV_ERROR("RR182x: Failed to allocate memory for EDMA queues\n"); > - unlock_driver(oldspl); > return ENOMEM; > } > > @@ -1238,7 +1235,6 @@ > { > MV_ERROR("RR182x: Failed to remap memory space\n"); > hptmv_free_edma_queues(pAdapter); > - unlock_driver(oldspl); > return ENXIO; > } > else > @@ -1268,7 +1264,6 @@ > unregister: > bus_release_resource(pAdapter->hpt_dev, SYS_RES_MEMORY, rid, > pAdapter->mem_res); > hptmv_free_edma_queues(pAdapter); > - unlock_driver(oldspl); > return ENXIO; > } > pAdapter->ver_601 = pMvSataAdapter->pcbVersion; > @@ -1411,7 +1406,6 @@ > #endif > > mvSataUnmaskAdapterInterrupt(pMvSataAdapter); > - unlock_driver(oldspl); > return 0; > } ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 18:09:05 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6332216A412 for ; Thu, 4 Jan 2007 18:09:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 0AF5313C471 for ; Thu, 4 Jan 2007 18:09:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l04I90Zt031471; Thu, 4 Jan 2007 13:09:00 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Kostik Belousov Date: Thu, 4 Jan 2007 12:50:16 -0500 User-Agent: KMail/1.9.1 References: <20070103141820.GA1014@grosbein.pp.ru> <200701031601.05541.jhb@freebsd.org> <20070104040727.GD21325@deviant.kiev.zoral.com.ua> In-Reply-To: <20070104040727.GD21325@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701041250.17335.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 04 Jan 2007 13:09:01 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2413/Thu Jan 4 04:46:27 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-hackers@freebsd.org, Eugene Grosbein Subject: Re: WITNESS & RELENG_6 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, 04 Jan 2007 18:09:05 -0000 On Wednesday 03 January 2007 23:07, Kostik Belousov wrote: > On Wed, Jan 03, 2007 at 04:01:04PM -0500, John Baldwin wrote: > > On Wednesday 03 January 2007 09:18, Eugene Grosbein wrote: > > > Hi! > > > > > > I try to find bugs in 6.2-PRERELEASE by using it (q) :-) > > > The question is: are kernel options WITNESS/WITNESS_KDB expected > > > to be in usable kernel? I don't worry about performance overhead here. > > > > > > The problem is, I've found this is nearly impossible to run > > > my home system with RELENG_6 build from yesterday's sources, > > > X.org 6.9.0, mplayer etc. without panicing and crashdump generation > > > after an hour or so. Just switch from X to vty and logon gave me another > > > LOR and crashdump. One of these you can see here: > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/107455 > > > > > > Perhaps, I should not use these options for everyday STABLE use? > > > > > > Eugene > > > > I think you are running into devfs bugs actually. > > I would suggest that the problem may be in the nvidia driver instead. > It seems to be related to dev cloning. > > Anyway, obtaining exact location of fault in devfs_populate_loop (either > with crashdump/kgdb or manually) would be first step. I know of at least one devfs cloning bug the nvidia driver ran into that phk@ verified is a bug in devfs, but I can't understand the patch well enough. I'll forward you the details. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 18:09:25 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8865616A660 for ; Thu, 4 Jan 2007 18:09:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 17E4A13C459 for ; Thu, 4 Jan 2007 18:09:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l04I90Zv031471; Thu, 4 Jan 2007 13:09:12 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Brian Dean Date: Thu, 4 Jan 2007 12:53:47 -0500 User-Agent: KMail/1.9.1 References: <20061214190510.GA26590@neutrino.bsdhome.com> <200612272350.43680.jhb@freebsd.org> <20070104152754.GA94609@neutrino.bsdhome.com> In-Reply-To: <20070104152754.GA94609@neutrino.bsdhome.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701041253.48092.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 04 Jan 2007 13:09:12 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2413/Thu Jan 4 04:46:27 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-hackers@freebsd.org, "R. Tyler Ballance" , Brian Dean Subject: Re: Kernel hang on 6.x 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, 04 Jan 2007 18:09:25 -0000 On Thursday 04 January 2007 10:27, Brian Dean wrote: > On Wed, Dec 27, 2006 at 11:50:43PM -0500, John Baldwin wrote: > > > The 'traceall' seemed to miss several threads actually (like pid > > 18). Can you get a 'ps'? Also, are you able to get a kernel dump > > when this happens? > > I can't ps that particular session since it is no longer available, > however I can reproduce another one and generate a new set of debug > output. One note, the "swap_pager: indefinite wait buffer: ..." > timeout message may have been a result of a misconfigured secondary > swap file, so that might be a red herring. However, we can still > reliably reproduce the hang with 32 Gig swap, but we don't get any > console messages associated with it. > > The system is set up as a test system so I'm not under any pressure to > get it rebooted and back up when it hangs, so I have the ability to > take some time to debug it. > > I believe that I can generate a kernel dump. We tried this yesterday > but didn't have a dump device configured. I think we've got that set > up now and plan to generate a kernel dump. I'm assuming that since > the process size and swap size is so large, that the dump size is > going to be very large also, on the order of 32 Gig. I beleive I can > host this on a server and make it accessible to you if you are willing > to download it. If this is 6.x, turn on minidumps via the sysctl. The dump size normally is the size of RAM. With minidumps it can be a lot smaller. If you get a dump, let me know and I'll point you at some gdb scripts to generate 'ps' type output, etc. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 18:11:49 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C356F16A416 for ; Thu, 4 Jan 2007 18:11:49 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 1215813C455 for ; Thu, 4 Jan 2007 18:11:48 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id l04IBkcq013004; Fri, 5 Jan 2007 01:11:46 +0700 (KRAT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id l04IBkUG013003; Fri, 5 Jan 2007 01:11:46 +0700 (KRAT) (envelope-from eugen) Date: Fri, 5 Jan 2007 01:11:46 +0700 From: Eugene Grosbein To: Kostik Belousov Message-ID: <20070104181146.GA90801@svzserv.kemerovo.su> References: <20070103141820.GA1014@grosbein.pp.ru> <200701031601.05541.jhb@freebsd.org> <20070104040727.GD21325@deviant.kiev.zoral.com.ua> <20070104103708.GF21325@deviant.kiev.zoral.com.ua> <20070104105208.GA78979@svzserv.kemerovo.su> <20070104110208.GG21325@deviant.kiev.zoral.com.ua> <20070104114327.GA81011@svzserv.kemerovo.su> <20070104114849.GH21325@deviant.kiev.zoral.com.ua> <20070104120603.GA84934@svzserv.kemerovo.su> <20070104121245.GI21325@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070104121245.GI21325@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: WITNESS & RELENG_6 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, 04 Jan 2007 18:11:49 -0000 On Thu, Jan 04, 2007 at 02:12:45PM +0200, Kostik Belousov wrote: > > > > I've tried. Now machine just hangs if I try to switch from X to vty. > > > > It stays in graphics mode locked. > > > Does it crash when exiting glxgears/some video player ? > > It does not crash now when exiting glxgears but glxgears does not > > exit really, this process "hangs" in the "devdrn" state. > As expected. > > mplayer hangs hard the whole system in the moment it switches to full-screen. > > > When hangs, does it answer ping/allow ssh connections ? > > Can't check just now, but can establish serial console if you wish. > It would be better to check this in both cases (mplayer and return to vty). I've established ethernet and serial links with this box and checked. In both cases this is X server locked in "devdrn" state. All other processes and the kernel run just fine. > But, most likely, the problem is in nvidia driver that calls destroy_dev() > from d_close(). > > You should ask the vendor for the fix. As a side note, responsible engineer > is aware of the bug. So, I need not bother him ones more? Eugene From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 18:58:24 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EDC9816A407 for ; Thu, 4 Jan 2007 18:58:24 +0000 (UTC) (envelope-from risner@matrix.stdio.com) Received: from matrix.stdio.com (matrix.stdio.com [199.89.192.20]) by mx1.freebsd.org (Postfix) with ESMTP id A41C013C441 for ; Thu, 4 Jan 2007 18:58:20 +0000 (UTC) (envelope-from risner@matrix.stdio.com) Received: from matrix.stdio.com (localhost [127.0.0.1]) by matrix.stdio.com (8.13.4/8.13.4) with ESMTP id l04IeeCv012321 for ; Thu, 4 Jan 2007 13:40:40 -0500 (EST) (envelope-from risner@matrix.stdio.com) Received: (from risner@localhost) by matrix.stdio.com (8.13.4/8.13.4/Submit) id l04Ieepw012320 for freebsd-hackers@freebsd.org; Thu, 4 Jan 2007 13:40:40 -0500 (EST) (envelope-from risner) Date: Thu, 4 Jan 2007 13:40:40 -0500 From: James Risner To: freebsd-hackers@freebsd.org Message-ID: <20070104184040.GA12048@matrix.stdio.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: /bin/dd fails with big disks containing bad sectors 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, 04 Jan 2007 18:58:25 -0000 Hello, I filed this PR (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/107443) and it was suggested I bring the issue to this list. If you have a defective disk larger than 2 gb with many bad sectors and attempt to use dd under FreeBSD to duplicate the disk, the operation will fail with sectors being out of alignment. dd bs=512 if=src of=dst conv=noerror,sync Under Linux, this operation performs as expected. There are faster methods of duplicating the disk (tools/recoverdisk is one.) But sometimes you only have /bin/dd and a fixit disk. It isn't intuitive that dd should fail in the way it is failing. The user (in this case me) doesn't expect to have a disk improperly aligned. I once resolved this issue several years ago with a patch to dd that is no long valid with current sources. I recently resolved this issue by writing my own tiny dd program (code is provided for curious people in the pr kern/107443) to properly copy the blocks. >From what I can tell there are several requirements for this issue: 1) Disk > 2Gb 2) Disk has more than a few bad sectors. 3) Use dd to copy the disk. It seems despite using "sync", dd is getting confused as to the input and output seek position. They get out of sync with each other and all future output blocks are written earlier on the disk than is required. James Risner From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 19:03:12 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A17E16A416; Thu, 4 Jan 2007 19:03:12 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 7641E13C459; Thu, 4 Jan 2007 19:03:11 +0000 (UTC) (envelope-from killing@multiplay.co.uk) X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on core6.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-24.7 required=6.0 tests=BAYES_00, USER_IN_WHITELIST, USER_IN_WHITELIST_TO autolearn=ham version=3.1.5 Received: from vader ([85.236.96.60]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.5.4) with ESMTP id md50003358666.msg; Thu, 04 Jan 2007 19:02:56 +0000 Message-ID: <018801c73032$ee748460$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: "Steven Hartland" , "John Baldwin" , References: <006301c72f93$0ffceb40$b3db87d4@multiplay.co.uk><200701041245.34582.jhb@freebsd.org> <012401c7302a$a49d2430$b3db87d4@multiplay.co.uk> Date: Thu, 4 Jan 2007 19:02:43 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-MDRemoteIP: 85.236.96.60 X-Return-Path: killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-Spam-Processed: multiplay.co.uk, Thu, 04 Jan 2007 19:02:57 +0000 X-MDAV-Processed: multiplay.co.uk, Thu, 04 Jan 2007 19:02:58 +0000 Cc: Subject: Re: hptmv not compatible with WITNESS / INVARIANTS pointers required 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, 04 Jan 2007 19:03:12 -0000 This appears to fix the problem, no panic during init of the adapter or detection of da0. I say appears as now I'm still stuck with SMP cpu init issue I was originally looking at :( Thanks for the fix most appreciated. Steve Steven Hartland wrote: > Thanks john, I'll try applying that later tonight should > apply cleanly even though I'm using v1.14 of the driver > I dont think there are any changes in these areas. > > N.B. Already contacted Scott Long to get the v1.14 > imported as it contains a number of critical fixes. > > Steve > John Baldwin wrote: >> On Wednesday 03 January 2007 18:58, Steven Hartland wrote: >>> I'm currently trying to debug an issue with Tyan s2892 >>> based machine but when I enable WITNESS / INVARIANTS >>> the Highpoint 182x driver panics the kernel with: >>> panic: blocakble sleep lock ( sleep mutex ) >>> 128 @ vm/uma_core.c: 1845 >>> >>> I believe this is due to the fact that you cant hold >>> a spin mutex while using: bus_dma_tag_create, malloc >>> bus_dmamem_alloc etc which the driver currently does, >>> but I have no experience with drivers hence dont know >>> what it should be doing instead. >>> >>> If someone's willing to give me some pointers I'd be >>> willing to give creating a patch and testing it a go. >>> >>> Here's a snipet of what I think is causing the issue: >>> /* This uses a mtx_lock_spin */ >>> intrmask_t oldspl = lock_driver(); >>> >>> pAdapter->next = 0; >>> >>> if(gIal_Adapter == 0) { >>> gIal_Adapter = pAdapter; >>> pCurAdapter = gIal_Adapter; >>> } else { >>> pCurAdapter->next = pAdapter; >>> pCurAdapter = pAdapter; >>> } >>> >>> pAdapter->outstandingCommands = 0; >>> >>> pMvSataAdapter = &(pAdapter->mvSataAdapter); >>> _vbus_p->OsExt = (void *)pAdapter; >>> pMvSataAdapter->IALData = pAdapter; >>> >>> /* Errors due to lock_driver holding mtx_lock_spin?? */ >>> if (bus_dma_tag_create(NULL, 1, 0, BUS_SPACE_MAXADDR_32BIT, >>> BUS_SPACE_MAXADDR, NULL, NULL, BUS_SPACE_MAXSIZE_32BIT, >>> MV_MAX_SEGMENTS, BUS_SPACE_MAXSIZE_32BIT, 0, NULL, NULL, >>> &pAdapter->parent_dmat) != 0) { >>> MV_ERROR("RR182x: Failed to create busdma resources\n"); >>> unlock_driver(oldspl); >>> return (ENOMEM); >>> } >> >> I would start off making it use a regular mutex (it doesn't need a >> spin mutex anyway). It also doesn't need any locking during the >> init_adapter() routine so I've removed that as well. Try this: >> >> Index: entry.c >> =================================================================== >> RCS file: /usr/cvs/src/sys/dev/hptmv/entry.c,v >> retrieving revision 1.12 >> diff -u -r1.12 entry.c >> --- entry.c 16 May 2006 14:36:25 -0000 1.12 >> +++ entry.c 4 Jan 2007 17:44:12 -0000 >> @@ -166,12 +166,12 @@ >> { >> >> intrmask_t spl = 0; >> - mtx_lock_spin(&driver_lock); >> + mtx_lock(&driver_lock); >> return spl; >> } >> void unlock_driver(intrmask_t spl) >> { >> - mtx_unlock_spin(&driver_lock); >> + mtx_unlock(&driver_lock); >> } >> #else >> static int driver_locked = 0; >> @@ -1168,7 +1168,7 @@ >> #if __FreeBSD_version >= 500000 >> static void hpt_init(void *dummy) >> { >> - mtx_init(&driver_lock, "hptlock", NULL, MTX_SPIN); >> + mtx_init(&driver_lock, "hptlock", NULL, MTX_DEF); >> } >> SYSINIT(hptinit, SI_SUB_CONFIGURE, SI_ORDER_FIRST, hpt_init, NULL); >> #endif >> @@ -1183,8 +1183,6 @@ >> >> PVDevice pVDev; >> >> - intrmask_t oldspl = lock_driver(); >> - >> pAdapter->next = 0; >> >> if(gIal_Adapter == 0){ >> @@ -1225,7 +1223,6 @@ >> if (hptmv_allocate_edma_queues(pAdapter)) >> { >> MV_ERROR("RR182x: Failed to allocate memory for EDMA queues\n"); >> - unlock_driver(oldspl); >> return ENOMEM; >> } >> >> @@ -1238,7 +1235,6 @@ >> { >> MV_ERROR("RR182x: Failed to remap memory space\n"); >> hptmv_free_edma_queues(pAdapter); >> - unlock_driver(oldspl); >> return ENXIO; >> } >> else >> @@ -1268,7 +1264,6 @@ >> unregister: >> bus_release_resource(pAdapter->hpt_dev, SYS_RES_MEMORY, rid, >> pAdapter->mem_res); >> hptmv_free_edma_queues(pAdapter); >> - unlock_driver(oldspl); >> return ENXIO; >> } >> pAdapter->ver_601 = pMvSataAdapter->pcbVersion; >> @@ -1411,7 +1406,6 @@ >> #endif >> >> mvSataUnmaskAdapterInterrupt(pMvSataAdapter); >> - unlock_driver(oldspl); >> return 0; >> } > > > > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. > and the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, > printing or otherwise disseminating it or any information contained > in it. > > In the event of misdirection, illegible or incomplete transmission > please telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 20:04:53 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D87016A412; Thu, 4 Jan 2007 20:04:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id BBC8913C45D; Thu, 4 Jan 2007 20:04:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l04K4g4p032386; Thu, 4 Jan 2007 15:04:42 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Oliver Fromme Date: Thu, 4 Jan 2007 14:59:17 -0500 User-Agent: KMail/1.9.1 References: <200701041803.l04I3oDo068148@lurza.secnetix.de> In-Reply-To: <200701041803.l04I3oDo068148@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701041459.18321.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 04 Jan 2007 15:04:45 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2413/Thu Jan 4 04:46:27 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: erik.udo@gmail.com, freebsd-hackers@freebsd.org, dougb@freebsd.org Subject: Re: Init.c, making it chroot 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, 04 Jan 2007 20:04:53 -0000 On Thursday 04 January 2007 13:03, Oliver Fromme wrote: > > John Baldwin wrote: > > Oliver Fromme wrote: > > > I've created (and tested!) a new patch. I've tested on > > > RELENG_6, but I think init(8) isn't very different on > > > HEAD, so it should work there, too. > > > > > > Any comments are welcome. I particularly appreciate > > > if others test this stuff. > > > > Some things I noticed: > > > > - Why do you have the 'ichroot_name' and 'iscript_name' variables? I would > > just pass the string literal to the kenv() function, e.g. > > > > if (kenv(KENV_GET, "init_script", kenv_value, sizeof(kenv_value)) > 0) { > > > > I think that putting the constant right there is easier for someone who > > is reading the code to see what is going on. > > In fact that's what I tried first ... Alas: > warning: passing arg 2 of `kenv' discards qualifiers from pointer target type It's fixed in HEAD, I'll MFC the prototype fix for kenv() to 6.x. > > - Rather than abusing a global runcom_script variable that you change to > > get side effects when you invoke runcom(), why not change runcom() to > > take a single 'char *script' as an argument and just pass _PATH_RUNCOM > > or kenv_value as appropriate and get rid of the global runcom_script > > variable? > > You are right, the global runcom_script variable does not > look very clean. However, the problem is that runcom() is > one of the transition action functions, i.e. it is called > by the transition() function and never gets an argument. > > Of course it is possible to write an additional function > run_script(char *script) which contains runcom's current > code, and make the runcom() function a wrapper that just > calls run_script(_PATH_RUNCOM). This isn't a perfectly > clean solution either, but maybe it's at least a little bit > better. > > e.g. basically: > > state_func_t > runcom (void) > { > return run_script(_PATH_RUNCOM); > } > > state_func_t > run_script (char *script) > { > /* all the code formerly in runcom() */ > } > > Then the init_script code would call run_script(kenv_value) > instead of runcom(), of course. > > Would that be acceptable? Or do you have an even better > solution in mind? That sounds great. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 18:04:01 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4AFF516A403; Thu, 4 Jan 2007 18:04:01 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id AB1ED13C43E; Thu, 4 Jan 2007 18:04:00 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (jylqnu@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l04I3px9068149; Thu, 4 Jan 2007 19:03:56 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l04I3oDo068148; Thu, 4 Jan 2007 19:03:50 +0100 (CET) (envelope-from olli) From: Oliver Fromme Message-Id: <200701041803.l04I3oDo068148@lurza.secnetix.de> To: jhb@freebsd.org (John Baldwin) Date: Thu, 4 Jan 2007 19:03:50 +0100 (CET) In-Reply-To: <200701041235.37141.jhb@freebsd.org> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 04 Jan 2007 19:03:57 +0100 (CET) X-Mailman-Approved-At: Thu, 04 Jan 2007 21:10:23 +0000 Cc: erik.udo@gmail.com, freebsd-hackers@freebsd.org, dougb@freebsd.org Subject: Re: Init.c, making it chroot 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, 04 Jan 2007 18:04:01 -0000 John Baldwin wrote: > Oliver Fromme wrote: > > I've created (and tested!) a new patch. I've tested on > > RELENG_6, but I think init(8) isn't very different on > > HEAD, so it should work there, too. > > > > Any comments are welcome. I particularly appreciate > > if others test this stuff. > > Some things I noticed: > > - Why do you have the 'ichroot_name' and 'iscript_name' variables? I would > just pass the string literal to the kenv() function, e.g. > > if (kenv(KENV_GET, "init_script", kenv_value, sizeof(kenv_value)) > 0) { > > I think that putting the constant right there is easier for someone who > is reading the code to see what is going on. In fact that's what I tried first ... Alas: warning: passing arg 2 of `kenv' discards qualifiers from pointer target type > - Rather than abusing a global runcom_script variable that you change to > get side effects when you invoke runcom(), why not change runcom() to > take a single 'char *script' as an argument and just pass _PATH_RUNCOM > or kenv_value as appropriate and get rid of the global runcom_script > variable? You are right, the global runcom_script variable does not look very clean. However, the problem is that runcom() is one of the transition action functions, i.e. it is called by the transition() function and never gets an argument. Of course it is possible to write an additional function run_script(char *script) which contains runcom's current code, and make the runcom() function a wrapper that just calls run_script(_PATH_RUNCOM). This isn't a perfectly clean solution either, but maybe it's at least a little bit better. e.g. basically: state_func_t runcom (void) { return run_script(_PATH_RUNCOM); } state_func_t run_script (char *script) { /* all the code formerly in runcom() */ } Then the init_script code would call run_script(kenv_value) instead of runcom(), of course. Would that be acceptable? Or do you have an even better solution in mind? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 20:32:04 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B40DC16A47B; Thu, 4 Jan 2007 20:32:04 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (palm.hoeg.nl [83.98.131.212]) by mx1.freebsd.org (Postfix) with ESMTP id 7E49613C46A; Thu, 4 Jan 2007 20:32:04 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 6E94A1CC5D; Thu, 4 Jan 2007 21:14:34 +0100 (CET) Date: Thu, 4 Jan 2007 21:14:34 +0100 From: Ed Schouten To: bug-followup@FreeBSD.org, philippe.lang@attiksystem.ch Message-ID: <20070104201434.GS1072@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OE5XN2KVoD5QaTkR" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Mailman-Approved-At: Thu, 04 Jan 2007 21:10:52 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: kern/89528: [jail] impossible to kill a jail 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, 04 Jan 2007 20:32:04 -0000 --OE5XN2KVoD5QaTkR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone, I decided to investigate this bug because I think the bug is quite irritating. After adding some ddb show commands to the source and reading a lot of code, I think I understand the problem: The tty code doesn't leak any ucreds, it's the devfs code that crhold()'s an ucred structure. When a new pty is needed, the tty_pty code allocates a new pty. It also runs make_dev_cred(), to which it passes the thread's ucred. This function calls make_dev_credv(), which finally runs crhold(). As long as pty's have been allocated that have been created by threads in a jail, the prison structure has more references, causing the zombie jails to exist. Yours, --=20 Ed Schouten WWW: http://g-rave.nl/ --OE5XN2KVoD5QaTkR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFnWAq52SDGA2eCwURAukZAJ4lGKkBlyXrtMLY/nN1EpH35f68hgCdHWSS /KmDk8nFZrT/tyvNyQu2Zek= =6L9c -----END PGP SIGNATURE----- --OE5XN2KVoD5QaTkR-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 20:49:54 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0C45016A415; Thu, 4 Jan 2007 20:49:54 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (palm.hoeg.nl [83.98.131.212]) by mx1.freebsd.org (Postfix) with ESMTP id C961713C43E; Thu, 4 Jan 2007 20:49:53 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id EBB7B1CC5D; Thu, 4 Jan 2007 21:49:52 +0100 (CET) Date: Thu, 4 Jan 2007 21:49:52 +0100 From: Ed Schouten To: bug-followup@FreeBSD.org, philippe.lang@attiksystem.ch Message-ID: <20070104204952.GT1072@hoeg.nl> References: <20070104201434.GS1072@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aE2Tjr+Wh4rS13mJ" Content-Disposition: inline In-Reply-To: <20070104201434.GS1072@hoeg.nl> User-Agent: Mutt/1.5.13 (2006-08-11) X-Mailman-Approved-At: Thu, 04 Jan 2007 21:11:02 +0000 Cc: FreeBSD Hackers Subject: Re: kern/89528: [jail] impossible to kill a jail 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, 04 Jan 2007 20:49:54 -0000 --aE2Tjr+Wh4rS13mJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Ed Schouten wrote: > As long as pty's have been allocated that have been created by threads > in a jail, the prison structure has more references, causing the zombie > jails to exist. We could change the make_dev_credv() routine to crcopy() everything except the prison when we're creating a node in a jail. The following patch fixes the zombie jail bug on my machine: --- src/sys/kern/kern_conf.c Fri Oct 20 09:59:50 2006 +++ src/sys/kern/kern_conf.c Thu Jan 4 21:36:44 2007 @@ -42,6 +42,7 @@ #include #include #include +#include #include =20 #include @@ -563,7 +564,15 @@ =09 dev->si_flags |=3D SI_NAMED; if (cr !=3D NULL) - dev->si_cred =3D crhold(cr); + if (cr->cr_prison =3D=3D NULL) { + dev->si_cred =3D crhold(cr); + } else { + /* Don't let the node depend on a prison */ + dev->si_cred =3D crget(); + crcopy(dev->si_cred, cr); + prison_free(dev->si_cred->cr_prison); + dev->si_cred->cr_prison =3D NULL; + } else dev->si_cred =3D NULL; dev->si_uid =3D uid; Could other people experiencing this problem as well give this patch a try? Thanks a lot! Yours, --=20 Ed Schouten WWW: http://g-rave.nl/ --aE2Tjr+Wh4rS13mJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFnWhw52SDGA2eCwURAnf9AJ47ZpkxiM8s2KznHU+NncdjiqjHpACcCzJQ jfxOzPnh9zjiOAxisCY8e5A= =TOCY -----END PGP SIGNATURE----- --aE2Tjr+Wh4rS13mJ-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 22:01:46 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F21BB16A585 for ; Thu, 4 Jan 2007 22:01:46 +0000 (UTC) (envelope-from zombyfork@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by mx1.freebsd.org (Postfix) with ESMTP id 9D1C313C448 for ; Thu, 4 Jan 2007 22:01:46 +0000 (UTC) (envelope-from zombyfork@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so6396863wxc for ; Thu, 04 Jan 2007 14:01:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=AqvqhB5bQBATA7kqdJMWQcTIVVhjYwBa3men7Ni93iaxuEzdJDFhsCoiCyTfx0Ek1Z6+eaS+W1+2P1JhL7vcwgSEC/jlmNF9cQNhRfpNk/i7cSbN/dV+loIaPzHqKnd8Z1Rhh0MG9A1vRLSHRA75D8NJMQg0HaRonsGrymL+/+k= Received: by 10.90.93.6 with SMTP id q6mr550789agb.1167946456621; Thu, 04 Jan 2007 13:34:16 -0800 (PST) Received: by 10.90.101.15 with HTTP; Thu, 4 Jan 2007 13:34:16 -0800 (PST) Message-ID: <346a80220701041334x484380a6n4d8d7a575d8fc659@mail.gmail.com> Date: Thu, 4 Jan 2007 14:34:16 -0700 From: "Coleman Kane" To: "Ed Schouten" In-Reply-To: <20070104204952.GT1072@hoeg.nl> MIME-Version: 1.0 References: <20070104201434.GS1072@hoeg.nl> <20070104204952.GT1072@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Hackers , philippe.lang@attiksystem.ch, bug-followup@freebsd.org Subject: Re: kern/89528: [jail] impossible to kill a jail X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cokane@cokane.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2007 22:01:47 -0000 On 1/4/07, Ed Schouten wrote: > > * Ed Schouten wrote: > > As long as pty's have been allocated that have been created by threads > > in a jail, the prison structure has more references, causing the zombie > > jails to exist. > > We could change the make_dev_credv() routine to crcopy() everything > except the prison when we're creating a node in a jail. The following > patch fixes the zombie jail bug on my machine: > > --- src/sys/kern/kern_conf.c Fri Oct 20 09:59:50 2006 > +++ src/sys/kern/kern_conf.c Thu Jan 4 21:36:44 2007 > @@ -42,6 +42,7 @@ > #include > #include > #include > +#include > #include > > #include > @@ -563,7 +564,15 @@ > > dev->si_flags |= SI_NAMED; > if (cr != NULL) > - dev->si_cred = crhold(cr); > + if (cr->cr_prison == NULL) { > + dev->si_cred = crhold(cr); > + } else { > + /* Don't let the node depend on a prison */ > + dev->si_cred = crget(); > + crcopy(dev->si_cred, cr); > + prison_free(dev->si_cred->cr_prison); > + dev->si_cred->cr_prison = NULL; > + } > else > dev->si_cred = NULL; > dev->si_uid = uid; > > Could other people experiencing this problem as well give this patch a > try? Thanks a lot! > > Yours, > -- > Ed Schouten > WWW: http://g-rave.nl/ > > > Does this behavior still occur if you set sysctl kern.pts.enable=1 ? Is this at all related to why I have been experiencing zombies left behind for any process that alloc's its own tty (such as gnome-terminal [actually gnome-pty-helper])? If I CTRL-D to end a gnome-terminal session, it will hang all of the gnome-terminals I have open and I typically have to reboot to clear out the zombies that remain. I can't open any more apps that use gnome-pty-helper to allocate ttys unless I attempt to kill it and start it anew (and I am not even completely sure if that works). -- Coleman Kane From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 23:04:19 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96CFC16A40F for ; Thu, 4 Jan 2007 23:04:19 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outH.internet-mail-service.net (outH.internet-mail-service.net [216.240.47.231]) by mx1.freebsd.org (Postfix) with ESMTP id 7BFB013C441 for ; Thu, 4 Jan 2007 23:04:19 +0000 (UTC) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Thu, 04 Jan 2007 14:36:02 -0800 Received: from [10.251.18.229] (nat.ironport.com [63.251.108.100]) by idiom.com (8.12.11/8.12.11) with ESMTP id l04JC6PM086945; Thu, 4 Jan 2007 11:12:07 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <459D5179.20809@elischer.org> Date: Thu, 04 Jan 2007 11:11:53 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: James Risner References: <20070104184040.GA12048@matrix.stdio.com> In-Reply-To: <20070104184040.GA12048@matrix.stdio.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: /bin/dd fails with big disks containing bad sectors 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, 04 Jan 2007 23:04:19 -0000 James Risner wrote: > Hello, > I filed this PR (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/107443) and it was > suggested I bring the issue to this list. > > If you have a defective disk larger than 2 gb with many bad sectors and attempt to use > dd under FreeBSD to duplicate the disk, the operation will fail with sectors being out of alignment. > > dd bs=512 if=src of=dst conv=noerror,sync > > Under Linux, this operation performs as expected. > There are faster methods of duplicating the disk (tools/recoverdisk is one.) > But sometimes you only have /bin/dd and a fixit disk. It isn't intuitive that > dd should fail in the way it is failing. The user (in this case me) doesn't expect > to have a disk improperly aligned. > > I once resolved this issue several years ago with a patch to dd that is no long valid with > current sources. I recently resolved this issue by writing my own tiny dd program (code > is provided for curious people in the pr kern/107443) to properly copy the blocks. > >>From what I can tell there are several requirements for this issue: > 1) Disk > 2Gb > 2) Disk has more than a few bad sectors. > 3) Use dd to copy the disk. > > It seems despite using "sync", dd is getting confused as to the input and output seek position. > They get out of sync with each other and all future output blocks are written earlier on the disk > than is required. there is a tool in the tools directory (i forget the name) that is specifically for reading bad disks.. written by phk.. gets this right..along with various tricks to try get back more data. > > James Risner > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 23:08:19 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6414516A416 for ; Thu, 4 Jan 2007 23:08:19 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 0199C13C44B for ; Thu, 4 Jan 2007 23:08:18 +0000 (UTC) (envelope-from killing@multiplay.co.uk) X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on core6.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-24.7 required=6.0 tests=BAYES_00, USER_IN_WHITELIST, USER_IN_WHITELIST_TO autolearn=ham version=3.1.5 Received: from vader ([85.236.96.60]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.5.4) with ESMTP id md50003359103.msg for ; Thu, 04 Jan 2007 23:06:04 +0000 Message-ID: <002601c73054$e42f26f0$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: References: <007501c72f28$af27ffe0$b3db87d4@multiplay.co.uk><200701031254.l03CsPSF082168@fire.jhs.private><007201c72f4e$90de97d0$b3db87d4@multiplay.co.uk><009d01c72f54$63841f70$b3db87d4@multiplay.co.uk> <00ef01c72f5f$28d3b470$b3db87d4@multiplay.co.uk> Date: Thu, 4 Jan 2007 23:05:49 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-MDRemoteIP: 85.236.96.60 X-Return-Path: killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-Spam-Processed: multiplay.co.uk, Thu, 04 Jan 2007 23:06:05 +0000 X-MDAV-Processed: multiplay.co.uk, Thu, 04 Jan 2007 23:06:05 +0000 Subject: Re: SMP initialisation changes 6.1-PRERELEASE and 6.1-RELEASE? 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, 04 Jan 2007 23:08:19 -0000 Steven Hartland wrote: > This now panics in the initial hpt driver init with: > panic: blocakble sleep lock ( sleep mutex ) > 128 @ vm/uma_core.c: 1845 > > This looks to me like a seperate issue as the driver is aquiring a > spinlock MTX_SPIN instead of MTX_DEF? I'm quite out of my depth at > this point so any pointers would be really appreciated. Thanks to John Baldwin's patch for hptmv I'm now back at the stage where the machine hangs as during initialisation of the CPU's. I've got WITNESS, INVARIANTS, KDB and DDB installed but I cant break to the debugger as it seems to be totally wedged. If I break to the debugger earlier and continue it doesnt hang any ideas on how to proceed would be greatfully appreciated. Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 21:35:12 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0474716A412 for ; Thu, 4 Jan 2007 21:35:12 +0000 (UTC) (envelope-from fbsd@synoptic.org) Received: from gort.synoptic.org (gort.synoptic.org [216.254.17.65]) by mx1.freebsd.org (Postfix) with ESMTP id DF28513C44B for ; Thu, 4 Jan 2007 21:35:11 +0000 (UTC) (envelope-from fbsd@synoptic.org) Received: by gort.synoptic.org (Postfix, from userid 1000) id A7DED6352884; Thu, 4 Jan 2007 13:09:58 -0800 (PST) Date: Thu, 4 Jan 2007 13:09:58 -0800 From: Matthew Hudson To: freebsd-hackers@freebsd.org Message-ID: <20070104210958.GB46929@gort.synoptic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-Mailman-Approved-At: Fri, 05 Jan 2007 00:15:27 +0000 Subject: Re: Reading in real time from a file without pipes 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, 04 Jan 2007 21:35:12 -0000 Mon Dec 11 09:08:37 PST 2006 c0re dumped wrote: > I wonder if is possible to read data from a > certain file without using a pipe. > > Let me explain: > > I have a process already writing messages to > a logfile. I want to read all written data > (without neither stop nor interfere normal > log process) from another process in real > time. > > How can I achieve it ? When on the command line, I do this using the program 'socat' (net/socat in ports). I.e. socat FILE:/var/log/messages,ignoreeof - This gives me the same sort of behavior as 'tail -f' except that it reads the entire file in first. I also use this when I'm say scp'ing over a really large tarball of text files and want to start looking at the files as they're coming in: * bigdir.tgz is a big tarball being scp'd over, 3 hours remaining * socat FILE:bigdir.tgz,ignoreeof - | gzip -dc | tar xf - & and just like that I now have bigdir.tgz being expanded in realtime without having to do anything that may have interfered with the scp (such as using ssh to run 'tee' on the remote host and do it that way. I know this isn't what you were asking since but I wanted to take the quick opportunity to brag about socat since I think it's the most powerful and useful utility that nobody seems to have heard about. More in line to what you're asking, I think the magic you're looking for is hinted to by the name of the option that socat uses, i.e. 'ignoreeof'. I'd surmise that all that socat and 'tail -f' are doing are reading until the end of a file and when they get a EOF, they simply wait a few milliseconds and try again. cheers -- Matthew Hudson From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 4 21:37:48 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65A5516A412; Thu, 4 Jan 2007 21:37:48 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (palm.hoeg.nl [83.98.131.212]) by mx1.freebsd.org (Postfix) with ESMTP id 2C72A13C467; Thu, 4 Jan 2007 21:37:48 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 8155C1CC6E; Thu, 4 Jan 2007 22:37:47 +0100 (CET) Date: Thu, 4 Jan 2007 22:37:47 +0100 From: Ed Schouten To: cokane@cokane.org Message-ID: <20070104213747.GV1072@hoeg.nl> References: <20070104201434.GS1072@hoeg.nl> <20070104204952.GT1072@hoeg.nl> <346a80220701041334x484380a6n4d8d7a575d8fc659@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W1G4cAX3lNqeBRc9" Content-Disposition: inline In-Reply-To: <346a80220701041334x484380a6n4d8d7a575d8fc659@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Mailman-Approved-At: Fri, 05 Jan 2007 00:15:40 +0000 Cc: FreeBSD Hackers , philippe.lang@attiksystem.ch, bug-followup@freebsd.org Subject: Re: kern/89528: [jail] impossible to kill a jail 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, 04 Jan 2007 21:37:48 -0000 --W1G4cAX3lNqeBRc9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Coleman Kane wrote: > Does this behavior still occur if you set sysctl kern.pts.enable=3D1 ? Well, I haven't tested that, but it should be fixed as well, because it also calls make_dev_cred(). > Is this at all related to why I have been experiencing zombies left behind > for any process that alloc's its own tty (such as gnome-terminal [actually > gnome-pty-helper])? If I CTRL-D to end a gnome-terminal session, it will > hang all of the gnome-terminals I have open and I typically have to reboot > to clear out the zombies that remain. I can't open any more apps that use > gnome-pty-helper to allocate ttys unless I attempt to kill it and start it > anew (and I am not even completely sure if that works). As far as I know, this is unrelated. The patch in my previous mail only fixes device node creation in jails. --=20 Ed Schouten WWW: http://g-rave.nl/ --W1G4cAX3lNqeBRc9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFnXOr52SDGA2eCwURArUyAJ4wenRYkZqHyHCyWPdJvkA3kW25YACdF+cE IxKmII5ArYEfxDb+iOJ4C24= =HoIt -----END PGP SIGNATURE----- --W1G4cAX3lNqeBRc9-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 5 00:32:25 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1554016A5D5 for ; Fri, 5 Jan 2007 00:32:25 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from sccmmhc92.asp.att.net (sccmmhc92.asp.att.net [204.127.203.212]) by mx1.freebsd.org (Postfix) with ESMTP id C615713C45D for ; Fri, 5 Jan 2007 00:32:24 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from [10.0.0.4] (12-216-254-44.client.mchsi.com[12.216.254.44]) by sccmmhc92.asp.att.net (sccmmhc92) with ESMTP id <20070105002221m9200kadkoe>; Fri, 5 Jan 2007 00:22:21 +0000 Message-ID: <459D9A3C.5000800@math.missouri.edu> Date: Thu, 04 Jan 2007 18:22:20 -0600 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20061230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <20070104210958.GB46929@gort.synoptic.org> In-Reply-To: <20070104210958.GB46929@gort.synoptic.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Reading in real time from a file without pipes 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, 05 Jan 2007 00:32:25 -0000 Matthew Hudson wrote: > Mon Dec 11 09:08:37 PST 2006 c0re dumped wrote: > >>I wonder if is possible to read data from a >>certain file without using a pipe. >> >>Let me explain: >> >>I have a process already writing messages to >>a logfile. I want to read all written data >>(without neither stop nor interfere normal >>log process) from another process in real >>time. >> >>How can I achieve it ? > > > When on the command line, I do this using the program 'socat' > (net/socat in ports). I.e. > socat FILE:/var/log/messages,ignoreeof - > > This gives me the same sort of behavior as 'tail -f' except that > it reads the entire file in first. I also use this when I'm > say scp'ing over a really large tarball of text files and want > to start looking at the files as they're coming in: > * bigdir.tgz is a big tarball being scp'd over, 3 hours remaining * > > socat FILE:bigdir.tgz,ignoreeof - | gzip -dc | tar xf - & > > and just like that I now have bigdir.tgz being expanded in realtime > without having to do anything that may have interfered with the scp (such > as using ssh to run 'tee' on the remote host and do it that way. Wouldn't "tail -f +1" do the same thing? From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 5 11:42:45 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F68716A407 for ; Fri, 5 Jan 2007 11:42:45 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 1D28313C461 for ; Fri, 5 Jan 2007 11:42:45 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1H2moi-000DOe-DJ; Fri, 05 Jan 2007 14:00:56 +0300 Date: Fri, 5 Jan 2007 14:00:51 +0300 From: Eygene Ryabinkin To: James Risner Message-ID: <20070105110051.GG37482@codelabs.ru> References: <20070104184040.GA12048@matrix.stdio.com> <459D5179.20809@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <459D5179.20809@elischer.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.9 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: freebsd-hackers@freebsd.org Subject: Re: /bin/dd fails with big disks containing bad sectors 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, 05 Jan 2007 11:42:45 -0000 > there is a tool in the tools directory (i forget the name) that is > specifically for reading bad disks.. The utility is named 'recoverdisk'. -- Eygene From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 5 08:56:05 2007 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 68F3616A407 for ; Fri, 5 Jan 2007 08:56:05 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id CFD2413C458 for ; Fri, 5 Jan 2007 08:56:04 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (zebixs@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l058tvgn007600; Fri, 5 Jan 2007 09:56:03 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l058tv4w007599; Fri, 5 Jan 2007 09:55:57 +0100 (CET) (envelope-from olli) Date: Fri, 5 Jan 2007 09:55:57 +0100 (CET) Message-Id: <200701050855.l058tv4w007599@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, fbsd@synoptic.org In-Reply-To: <20070104210958.GB46929@gort.synoptic.org> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 05 Jan 2007 09:56:03 +0100 (CET) X-Mailman-Approved-At: Fri, 05 Jan 2007 12:32:24 +0000 Cc: Subject: Re: Reading in real time from a file without pipes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG, fbsd@synoptic.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2007 08:56:05 -0000 Matthew Hudson wrote: > Mon Dec 11 09:08:37 PST 2006 c0re dumped wrote: > > I wonder if is possible to read data from a > > certain file without using a pipe. > > > > Let me explain: > > > > I have a process already writing messages to > > a logfile. I want to read all written data > > (without neither stop nor interfere normal > > log process) from another process in real > > time. > > > > How can I achieve it ? > > When on the command line, I do this using the program 'socat' > (net/socat in ports). I.e. > socat FILE:/var/log/messages,ignoreeof - How is that different from "tail -f +1"? > This gives me the same sort of behavior as 'tail -f' except that > it reads the entire file in first. That's what "+1" with tail(1) does. > I know this isn't what you were asking since but I wanted to take > the quick opportunity to brag about socat since I think it's the > most powerful and useful utility that nobody seems to have heard > about. Maybe that's because we already have tail(1) in the base system. ;-) > More in line to what you're asking, I think the magic you're looking > for is hinted to by the name of the option that socat uses, i.e. > 'ignoreeof'. I'd surmise that all that socat and 'tail -f' are > doing are reading until the end of a file and when they get a EOF, > they simply wait a few milliseconds and try again. No. FreeBSD's tail(1) does not "poll" at EOF, which would be quite ugly and inefficient. Instead it uses the kqueue interface, so the kernel notifies tail when more data is available. I've had a quick look at the socat sources; it doesn't seem to use the kqueue interface, so it probably polls at EOF. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "Being really good at C++ is like being really good at using rocks to sharpen sticks." -- Thant Tessman From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 5 15:00:43 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40A7D16A40F; Fri, 5 Jan 2007 15:00:43 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) Received: from ipmail03.adl2.internode.on.net (ipmail03.adl2.internode.on.net [203.16.214.135]) by mx1.freebsd.org (Postfix) with ESMTP id 90C2D13C455; Fri, 5 Jan 2007 15:00:42 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) Received: from ppp192-183.lns1.adl4.internode.on.net (HELO mail.clearchain.com) ([203.122.192.183]) by ipmail03.adl2.internode.on.net with ESMTP; 06 Jan 2007 01:15:22 +1030 X-IronPort-AV: i="4.12,243,1165152600"; d="scan'208"; a="30461427:sNHT21361739" Received: from [192.168.155.246] ([192.168.155.246]) (authenticated bits=0) by mail.clearchain.com (8.13.8/8.13.8) with ESMTP id l05EjCik086242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Jan 2007 01:15:18 +1030 (CST) (envelope-from Benjamin.Close@clearchain.com) Message-ID: <459E6477.2010508@clearchain.com> Date: Sat, 06 Jan 2007 01:15:11 +1030 From: Benjamin Close User-Agent: Thunderbird 1.5.0.8 (X11/20061211) MIME-Version: 1.0 To: freebsd-drivers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.7/2414/Fri Jan 5 12:11:51 2007 on pegasus.clearchain.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (mail.clearchain.com [192.168.155.1]); Sat, 06 Jan 2007 01:15:18 +1030 (CST) X-Mailman-Approved-At: Fri, 05 Jan 2007 15:11:30 +0000 Cc: freebsd-hackers@freebsd.org, damien.bergamini@free.fr Subject: Updated Driver for 3945ABG Intel 3945ABG Wireless 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: Fri, 05 Jan 2007 15:00:43 -0000 Hi All, After getting a new laptop I discovered being tied to a wire when your used to wireless is extremely annoying. Hence I've done a port of the NetBSD driver wpi (20070106 rev) for the Intel3945ABG wireless card to FreeBSD Many thanks to Damien for writing the NetBSD driver in the first place and the initial FreeBSD port which I referenced extensively. The driver is available at: http://www.clearchain.com/~benjsc/download/20070106-wpi-freebsd.tar.gz (dynamic dns host, so just retry later if it's down): Please let me know if you have any issues and I'll try to address them. I'm not sure how well it will work on -stable, I'm running FreeBSD wolf.clearchain.com 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Wed Dec 13 16:09:21 CST 2006 benjsc@wolf.clearchain.com:/usr/src/sys/amd64/compile/GENERIC amd64 and don't have a -stable machine for testing. Those not using -current, be sure to remove #define WPI_CURRENT in if_wpi.c before compiling. This email was sent through the driver :) Cheers, Benjamin From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 5 15:47:43 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E8EF16A403; Fri, 5 Jan 2007 15:47:43 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 8C27613C442; Fri, 5 Jan 2007 15:47:42 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.25.32] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1H2r500n0N-0006ld; Fri, 05 Jan 2007 16:34:04 +0100 From: Max Laier Organization: FreeBSD To: freebsd-hackers@freebsd.org Date: Fri, 5 Jan 2007 16:33:52 +0100 User-Agent: KMail/1.9.5 References: <459E6477.2010508@clearchain.com> In-Reply-To: <459E6477.2010508@clearchain.com> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart16001069.ONvuKxxUA3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200701051634.00293.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Benjamin Close , Florent Thoumie , freebsd-drivers@freebsd.org, Attilio Rao , damien.bergamini@free.fr, gabor@freebsd.org Subject: Re: Updated Driver for 3945ABG Intel 3945ABG Wireless 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: Fri, 05 Jan 2007 15:47:43 -0000 --nextPart16001069.ONvuKxxUA3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 05 January 2007 15:45, Benjamin Close wrote: > Hi All, > After getting a new laptop I discovered being tied to a wire when > your used to wireless is extremely annoying. > > Hence I've done a port of the NetBSD driver wpi (20070106 rev) for the > Intel3945ABG wireless card to FreeBSD > Many thanks to Damien for writing the NetBSD driver in the first place > and the initial FreeBSD port which I referenced extensively. > > The driver is available at: > > http://www.clearchain.com/~benjsc/download/20070106-wpi-freebsd.tar.gz > > (dynamic dns host, so just retry later if it's down): Mirror'ed at: http://people.freebsd.org/~mlaier/wpi_port/ > > Please let me know if you have any issues and I'll try to address them. > I'm not sure how well it will work on -stable, I'm running > > FreeBSD wolf.clearchain.com 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Wed Dec > 13 16:09:21 CST 2006 > benjsc@wolf.clearchain.com:/usr/src/sys/amd64/compile/GENERIC amd64 > > and don't have a -stable machine for testing. > Those not using -current, be sure to remove > > #define WPI_CURRENT > > in if_wpi.c before compiling. > > This email was sent through the driver :) =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart16001069.ONvuKxxUA3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFnm/oXyyEoT62BG0RAqCCAJ9Y5tPvjUpOJYbAdi7Q4VcMm5WT+ACbBrUC 1qt3o5hIdStqRW4152kNKLM= =u5nd -----END PGP SIGNATURE----- --nextPart16001069.ONvuKxxUA3-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 5 16:20:46 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2363C16A605; Fri, 5 Jan 2007 16:20:46 +0000 (UTC) (envelope-from flz@FreeBSD.org) Received: from postfix1-g20.free.fr (postfix1-g20.free.fr [212.27.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id 71D7713C45B; Fri, 5 Jan 2007 16:20:43 +0000 (UTC) (envelope-from flz@FreeBSD.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix1-g20.free.fr (Postfix) with ESMTP id CBE1D74F280; Fri, 5 Jan 2007 16:58:48 +0100 (CET) Received: from smtp.xbsd.org (unknown [82.233.2.192]) by smtp5-g19.free.fr (Postfix) with ESMTP id 56DF527B96; Fri, 5 Jan 2007 16:58:47 +0100 (CET) Received: from localhost (localhost.xbsd.org [127.0.0.1]) by smtp.xbsd.org (Postfix) with ESMTP id 850C411443; Fri, 5 Jan 2007 16:58:46 +0100 (CET) X-Virus-Scanned: amavisd-new at xbsd.org Received: from smtp.xbsd.org ([127.0.0.1]) by localhost (srv1.xbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lFpq6ykInK2; Fri, 5 Jan 2007 16:58:38 +0100 (CET) Received: from [193.95.134.156] (mayday.esat.net [193.95.134.156]) by smtp.xbsd.org (Postfix) with ESMTP id 5019311411; Fri, 5 Jan 2007 16:58:37 +0100 (CET) Message-ID: <459E75A5.7000309@FreeBSD.org> Date: Fri, 05 Jan 2007 15:58:29 +0000 From: Florent Thoumie User-Agent: Thunderbird 1.5.0.8 (X11/20061121) MIME-Version: 1.0 To: Max Laier References: <459E6477.2010508@clearchain.com> <200701051634.00293.max@love2party.net> In-Reply-To: <200701051634.00293.max@love2party.net> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigBC0EB8E196D708065E240718" Cc: Benjamin Close , freebsd-hackers@freebsd.org, freebsd-drivers@freebsd.org, Attilio Rao , damien.bergamini@free.fr, gabor@freebsd.org Subject: Re: Updated Driver for 3945ABG Intel 3945ABG Wireless 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: Fri, 05 Jan 2007 16:20:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBC0EB8E196D708065E240718 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Max Laier wrote: > On Friday 05 January 2007 15:45, Benjamin Close wrote: >> Hi All, >> After getting a new laptop I discovered being tied to a wire when >> your used to wireless is extremely annoying. >> >> Hence I've done a port of the NetBSD driver wpi (20070106 rev) for the= >> Intel3945ABG wireless card to FreeBSD >> Many thanks to Damien for writing the NetBSD driver in the first place= >> and the initial FreeBSD port which I referenced extensively. >> >> The driver is available at: >> >> http://www.clearchain.com/~benjsc/download/20070106-wpi-freebsd.tar.g= z >> >> (dynamic dns host, so just retry later if it's down): >=20 > Mirror'ed at: http://people.freebsd.org/~mlaier/wpi_port/ >=20 >> Please let me know if you have any issues and I'll try to address them= =2E >> I'm not sure how well it will work on -stable, I'm running >> >> FreeBSD wolf.clearchain.com 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Wed De= c >> 13 16:09:21 CST 2006 >> benjsc@wolf.clearchain.com:/usr/src/sys/amd64/compile/GENERIC amd64 >> >> and don't have a -stable machine for testing. >> Those not using -current, be sure to remove >> >> #define WPI_CURRENT >> >> in if_wpi.c before compiling. >> >> This email was sent through the driver :) >=20 While I'm really happy to see people working on this, isn't this a duplicated effort? This is at least the third attempt to get a wpi(4) driver on FreeBSD (and I'm sure two of them are based on Damien's driver). I might be missing something though. --=20 Florent Thoumie flz@FreeBSD.org FreeBSD Committer --------------enigBC0EB8E196D708065E240718 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFnnWrMxEkbVFH3PQRCq5WAJ0bGR6kFVrMDhda/mSy0g5/j9m7kwCfQzS2 UTofyjFtTammJ6wiA+w55FI= =WPVA -----END PGP SIGNATURE----- --------------enigBC0EB8E196D708065E240718-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 5 16:32:42 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B1E416A407; Fri, 5 Jan 2007 16:32:42 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 09C5A13C428; Fri, 5 Jan 2007 16:32:41 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.25.32] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1H2rzY22TV-0003Bn; Fri, 05 Jan 2007 17:32:28 +0100 From: Max Laier Organization: FreeBSD To: Florent Thoumie Date: Fri, 5 Jan 2007 17:32:18 +0100 User-Agent: KMail/1.9.5 References: <459E6477.2010508@clearchain.com> <200701051634.00293.max@love2party.net> <459E75A5.7000309@FreeBSD.org> In-Reply-To: <459E75A5.7000309@FreeBSD.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2213065.Iqai8T0Pqy"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200701051732.27176.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Benjamin Close , freebsd-hackers@freebsd.org, freebsd-drivers@freebsd.org, Attilio Rao , damien.bergamini@free.fr, gabor@freebsd.org Subject: Re: Updated Driver for 3945ABG Intel 3945ABG Wireless 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: Fri, 05 Jan 2007 16:32:42 -0000 --nextPart2213065.Iqai8T0Pqy Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 05 January 2007 16:58, Florent Thoumie wrote: > Max Laier wrote: > > On Friday 05 January 2007 15:45, Benjamin Close wrote: > >> Hi All, > >> After getting a new laptop I discovered being tied to a wire > >> when your used to wireless is extremely annoying. > >> > >> Hence I've done a port of the NetBSD driver wpi (20070106 rev) for > >> the Intel3945ABG wireless card to FreeBSD > >> Many thanks to Damien for writing the NetBSD driver in the first > >> place and the initial FreeBSD port which I referenced extensively. > >> > >> The driver is available at: > >> > >>=20 > >> http://www.clearchain.com/~benjsc/download/20070106-wpi-freebsd.tar. > >>gz > >> > >> (dynamic dns host, so just retry later if it's down): > > > > Mirror'ed at: http://people.freebsd.org/~mlaier/wpi_port/ > > > >> Please let me know if you have any issues and I'll try to address > >> them. I'm not sure how well it will work on -stable, I'm running > >> > >> FreeBSD wolf.clearchain.com 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Wed > >> Dec 13 16:09:21 CST 2006 > >> benjsc@wolf.clearchain.com:/usr/src/sys/amd64/compile/GENERIC amd64 > >> > >> and don't have a -stable machine for testing. > >> Those not using -current, be sure to remove > >> > >> #define WPI_CURRENT > >> > >> in if_wpi.c before compiling. > >> > >> This email was sent through the driver :) > > While I'm really happy to see people working on this, isn't this a > duplicated effort? This is at least the third attempt to get a wpi(4) > driver on FreeBSD (and I'm sure two of them are based on Damien's > driver). I might be missing something though. Hence the extensive CC-list ... I'm trying to get all people involved to=20 talk to each other and coordinate. From what I hear the other drivers=20 showed some problems regarding resource allocation - maybe this one does=20 better ... I'm more than willing to shepherd one of these drivers into the tree, but=20 I'd need people with the actual hardware to say: "Yes it works" (for a=20 large enough fraction of cases) and possibly somebody to serve as a=20 maintainer willing to deal with PRs and stuff in the future. Given that part one of this is fullfilled by either of the available=20 drivers - let's get something in and work from there. Thoughts? Volunteers? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2213065.Iqai8T0Pqy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFnn2bXyyEoT62BG0RAvImAJ9C0aPbLBgsoEx0gx/g/U0nilykgQCfY3Fg 07j/3Z095qwCpjzGC2gekhQ= =zdwQ -----END PGP SIGNATURE----- --nextPart2213065.Iqai8T0Pqy-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 5 16:58:18 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E468116A407 for ; Fri, 5 Jan 2007 16:58:18 +0000 (UTC) (envelope-from mlusetti@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id 5ADFC13C43E for ; Fri, 5 Jan 2007 16:58:18 +0000 (UTC) (envelope-from mlusetti@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so7887184nfc for ; Fri, 05 Jan 2007 08:58:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BeNSuLAu7CI95YOIjNm3imqpR5U7cfN5JGMGm7rRs3GMtJneWinK0/umqHFgnwKOjaaLJbTvNe60/LDtWuGkHcN+rnVQOx12fsqh9x1kaZ/D42/ypHhUMd7ympQlgIf6AX5UvVBEDxL8PUGLsNtJTUIswRle1lvWfyu2DjLiq7Q= Received: by 10.82.113.6 with SMTP id l6mr2334123buc.1168015463557; Fri, 05 Jan 2007 08:44:23 -0800 (PST) Received: by 10.82.134.10 with HTTP; Fri, 5 Jan 2007 08:44:23 -0800 (PST) Message-ID: Date: Fri, 5 Jan 2007 17:44:23 +0100 From: "Massimo Lusetti" To: "Max Laier" In-Reply-To: <200701051732.27176.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <459E6477.2010508@clearchain.com> <200701051634.00293.max@love2party.net> <459E75A5.7000309@FreeBSD.org> <200701051732.27176.max@love2party.net> Cc: Benjamin Close , Florent Thoumie , freebsd-hackers@freebsd.org, freebsd-drivers@freebsd.org, Attilio Rao , damien.bergamini@free.fr, gabor@freebsd.org Subject: Re: Updated Driver for 3945ABG Intel 3945ABG Wireless 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: Fri, 05 Jan 2007 16:58:19 -0000 On 1/5/07, Max Laier wrote: > Thoughts? Volunteers? I can say that the first attempt still running fine here on my laptop on a -STABLE as of yesterday. I use it on a daily basis without any glitch. I must say i don't do or tried to do nothing special or network intensive job, but for reading emails, doing a lot of ssh and http/https the drivers is working smoothly. I will try to compile this new one on my stable during the week end and will see on Monday how it will perform on my office wi-lan. For the records: my wpi doesn't still work on OpenBSD-current cause it's integrated and the switch used to turn it on seems an acpi one which OpenBSD doesn't attach very well yet. Best regards -- Massimo http://meridio.blogspot.com From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 5 17:06:04 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD0EF16A415 for ; Fri, 5 Jan 2007 17:06:04 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id 51F7113C4A6 for ; Fri, 5 Jan 2007 17:06:04 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so7889144nfc for ; Fri, 05 Jan 2007 09:06:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=lGc7LwXBt4xOuKn7Kq9CR3lM4MkBMEQId8CcdIzbG+RWFOt30DgFcFQ01tfc1oVY+E/JXLp950mex3SnRFx68V6E4z5cokEWF415a2iEwUzQBlwuLYtZkj+kI8G+D1Znfs8j4nBWWbj7UePQznJj1bI6QhDnj3eRtImIIqXX8Iw= Received: by 10.49.8.1 with SMTP id l1mr29222887nfi.1168015296070; Fri, 05 Jan 2007 08:41:36 -0800 (PST) Received: from ?192.168.123.201? ( [195.241.221.201]) by mx.google.com with ESMTP id l38sm90057276nfc.2007.01.05.08.41.34; Fri, 05 Jan 2007 08:41:35 -0800 (PST) Message-ID: <459E7FBD.4050707@gmail.com> Date: Fri, 05 Jan 2007 17:41:33 +0100 From: Rene Ladan User-Agent: Thunderbird 1.5.0.9 (X11/20061224) MIME-Version: 1.0 To: Max Laier References: <459E6477.2010508@clearchain.com> <200701051634.00293.max@love2party.net> <459E75A5.7000309@FreeBSD.org> <200701051732.27176.max@love2party.net> In-Reply-To: <200701051732.27176.max@love2party.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Benjamin Close , Gavin Atkinson , Florent Thoumie , freebsd-hackers@freebsd.org, freebsd-drivers@freebsd.org, Attilio Rao , damien.bergamini@free.fr, gabor@freebsd.org Subject: Re: Updated Driver for 3945ABG Intel 3945ABG Wireless 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: Fri, 05 Jan 2007 17:06:04 -0000 Max Laier schreef: > On Friday 05 January 2007 16:58, Florent Thoumie wrote: >> Max Laier wrote: >>> On Friday 05 January 2007 15:45, Benjamin Close wrote: >>>> Hi All, >>>> After getting a new laptop I discovered being tied to a wire >>>> when your used to wireless is extremely annoying. >>>> >>>> Hence I've done a port of the NetBSD driver wpi (20070106 rev) for >>>> the Intel3945ABG wireless card to FreeBSD >>>> Many thanks to Damien for writing the NetBSD driver in the first >>>> place and the initial FreeBSD port which I referenced extensively. >>>> >>>> The driver is available at: >>>> >>>> >>>> http://www.clearchain.com/~benjsc/download/20070106-wpi-freebsd.tar. >>>> gz >>>> >>>> (dynamic dns host, so just retry later if it's down): >>> Mirror'ed at: http://people.freebsd.org/~mlaier/wpi_port/ >>> >>>> Please let me know if you have any issues and I'll try to address >>>> them. I'm not sure how well it will work on -stable, I'm running >>>> >>>> FreeBSD wolf.clearchain.com 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Wed >>>> Dec 13 16:09:21 CST 2006 >>>> benjsc@wolf.clearchain.com:/usr/src/sys/amd64/compile/GENERIC amd64 >>>> >>>> and don't have a -stable machine for testing. >>>> Those not using -current, be sure to remove >>>> >>>> #define WPI_CURRENT >>>> >>>> in if_wpi.c before compiling. >>>> >>>> This email was sent through the driver :) >> While I'm really happy to see people working on this, isn't this a >> duplicated effort? This is at least the third attempt to get a wpi(4) >> driver on FreeBSD (and I'm sure two of them are based on Damien's >> driver). I might be missing something though. > > Hence the extensive CC-list ... I'm trying to get all people involved to > talk to each other and coordinate. From what I hear the other drivers > showed some problems regarding resource allocation - maybe this one does > better ... > [...] Added Gavin Atkinson to the CC list, he is working on a wpi(4) clone which I'm using at the moment. It has some memory corruption error, but is otherwise behaving quite good. Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 5 19:28:08 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E95816A415 for ; Fri, 5 Jan 2007 19:28:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 3B5E513C455 for ; Fri, 5 Jan 2007 19:28:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l05JRXr9041343; Fri, 5 Jan 2007 14:28:05 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 5 Jan 2007 14:18:53 -0500 User-Agent: KMail/1.9.1 References: <007501c72f28$af27ffe0$b3db87d4@multiplay.co.uk> <00ef01c72f5f$28d3b470$b3db87d4@multiplay.co.uk> <002601c73054$e42f26f0$b3db87d4@multiplay.co.uk> In-Reply-To: <002601c73054$e42f26f0$b3db87d4@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701051418.54086.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 05 Jan 2007 14:28:06 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2414/Thu Jan 4 20:41:51 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Steven Hartland Subject: Re: SMP initialisation changes 6.1-PRERELEASE and 6.1-RELEASE? 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, 05 Jan 2007 19:28:08 -0000 On Thursday 04 January 2007 18:05, Steven Hartland wrote: > Steven Hartland wrote: > > This now panics in the initial hpt driver init with: > > panic: blocakble sleep lock ( sleep mutex ) > > 128 @ vm/uma_core.c: 1845 > > > > This looks to me like a seperate issue as the driver is aquiring a > > spinlock MTX_SPIN instead of MTX_DEF? I'm quite out of my depth at > > this point so any pointers would be really appreciated. > > Thanks to John Baldwin's patch for hptmv I'm now back at the stage > where the machine hangs as during initialisation of the CPU's. > > I've got WITNESS, INVARIANTS, KDB and DDB installed but I cant > break to the debugger as it seems to be totally wedged. > > If I break to the debugger earlier and continue it doesnt hang > any ideas on how to proceed would be greatfully appreciated. If there is any way to figure out a date for a working kernel that would be very helpful. Can you try using cvsup or cvs to step back to a RELENG_6 kernel that works and then using the binary date trick to figure out which commit breaks your box? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 5 19:28:18 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F1FCF16A51E; Fri, 5 Jan 2007 19:28:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 9F04013C448; Fri, 5 Jan 2007 19:28:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l05JRXrA041343; Fri, 5 Jan 2007 14:28:07 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 5 Jan 2007 14:27:44 -0500 User-Agent: KMail/1.9.1 References: <20070104201434.GS1072@hoeg.nl> In-Reply-To: <20070104201434.GS1072@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701051427.46146.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 05 Jan 2007 14:28:10 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2414/Thu Jan 4 20:41:51 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: philippe.lang@attiksystem.ch, Ed Schouten , bug-followup@freebsd.org Subject: Re: kern/89528: [jail] impossible to kill a jail 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, 05 Jan 2007 19:28:19 -0000 On Thursday 04 January 2007 15:14, Ed Schouten wrote: > Hello everyone, > > I decided to investigate this bug because I think the bug is quite > irritating. After adding some ddb show commands to the source and > reading a lot of code, I think I understand the problem: > > The tty code doesn't leak any ucreds, it's the devfs code that > crhold()'s an ucred structure. When a new pty is needed, the tty_pty > code allocates a new pty. It also runs make_dev_cred(), to which it > passes the thread's ucred. This function calls make_dev_credv(), which > finally runs crhold(). > > As long as pty's have been allocated that have been created by threads > in a jail, the prison structure has more references, causing the zombie > jails to exist. Why aren't the pty's destroyed? Once all references to the pty are closed it should be destroyed and the resulting devfs_free() should drop the reference. Is the pty somehow stuck on the dead_cdevsw? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 5 20:23:27 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C147D16A412; Fri, 5 Jan 2007 20:23:27 +0000 (UTC) (envelope-from rink@thunderstone.rink.nu) Received: from mx1.rink.nu (thunderstone.rink.nu [80.112.228.34]) by mx1.freebsd.org (Postfix) with ESMTP id 28A7B13C441; Fri, 5 Jan 2007 20:23:27 +0000 (UTC) (envelope-from rink@thunderstone.rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id BF563D4C33; Fri, 5 Jan 2007 20:50:04 +0100 (CET) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([127.0.0.1]) by localhost (thunderstone.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoCFuHv5yLKN; Fri, 5 Jan 2007 20:49:59 +0100 (CET) Received: from thunderstone.rink.nu (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.rink.nu (Postfix) with ESMTP id 68D1DD4C2A; Fri, 5 Jan 2007 20:49:59 +0100 (CET) Received: (from rink@localhost) by thunderstone.rink.nu (8.13.8/8.13.8/Submit) id l05Jnwsk070700; Fri, 5 Jan 2007 20:49:59 +0100 (CET) (envelope-from rink) Date: Fri, 5 Jan 2007 20:49:58 +0100 From: Rink Springer To: Benjamin Close Message-ID: <20070105194958.GB34087@rink.nu> References: <459E6477.2010508@clearchain.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="BwCQnh7xodEAoBMC" Content-Disposition: inline In-Reply-To: <459E6477.2010508@clearchain.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-hackers@freebsd.org, damien.bergamini@free.fr, freebsd-drivers@freebsd.org Subject: Re: Updated Driver for 3945ABG Intel 3945ABG Wireless 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: Fri, 05 Jan 2007 20:23:27 -0000 --BwCQnh7xodEAoBMC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Benajmin, On Sat, Jan 06, 2007 at 01:15:11AM +1030, Benjamin Close wrote: > Hi All, > After getting a new laptop I discovered being tied to a wire when=20 > your used to wireless is extremely annoying. >=20 > Hence I've done a port of the NetBSD driver wpi (20070106 rev) for the=20 > Intel3945ABG wireless card to FreeBSD > Many thanks to Damien for writing the NetBSD driver in the first place=20 > and the initial FreeBSD port which I referenced extensively. >=20 > The driver is available at: >=20 > http://www.clearchain.com/~benjsc/download/20070106-wpi-freebsd.tar.gz >=20 > (dynamic dns host, so just retry later if it's down): >=20 > Please let me know if you have any issues and I'll try to address them. > I'm not sure how well it will work on -stable, I'm running >=20 > FreeBSD wolf.clearchain.com 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Wed Dec= =20 > 13 16:09:21 CST 2006 =20 > benjsc@wolf.clearchain.com:/usr/src/sys/amd64/compile/GENERIC amd64 >=20 > and don't have a -stable machine for testing. > Those not using -current, be sure to remove >=20 > #define WPI_CURRENT >=20 > in if_wpi.c before compiling. >=20 > This email was sent through the driver :) This is FreeBSD 6-STABLE of 19 Dec; laptop is a Dell Latitude D820. The driver loads OK. Mind you, I had to manually copy the wlan_amrr code =66rom CURRENT to get it to compile on this STABLE box (along with some minor .h file merging).=20 However, it does not work correctly. dmesg(8) output can be found on http://rink.nu/tmp/dmesg-wpi Any advice would be very appreciated! Thanks for working on this! --=20 Rink P.W. Springer - http://rink.nu "It is such a quiet thing, to fall. But yet a far more terrible thing, to admit it." - Darth Traya --BwCQnh7xodEAoBMC Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIJawYJKoZIhvcNAQcCoIIJXDCCCVgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BuIwggObMIIDBKADAgECAhAiuN7bs9pg6t3I0n6G5OOTMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjExMDgwOTI2 NTNaFw0wNzExMDgwOTI2NTNaMIHSMREwDwYDVQQEEwhTcHJpbmdlcjEaMBgGA1UEKhMRUmlu ayBQZXRlciBXeWNoZXIxIzAhBgNVBAMTGlJpbmsgUGV0ZXIgV3ljaGVyIFNwcmluZ2VyMRsw GQYJKoZIhvcNAQkBFgxtYWlsQHJpbmsubnUxHzAdBgkqhkiG9w0BCQEWEHJpbmtAZnJlZWJz ZC5vcmcxIDAeBgkqhkiG9w0BCQEWEXJpbmtAaWwuZm9udHlzLm5sMRwwGgYJKoZIhvcNAQkB Fg1yaW5rQHN0YWNrLm5sMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxryGDfel YzzENX7wodkbVY1NALfaiPfNEG10YjD8ZWdK9zkN26Tc878Shbqapq0KYFD8TACGfEhKoMvo qbf0PHAS/gNYr81Arqa9FRPUfzvtDE/cMbhvI+p7ufBITyYnPJp9MUD72iT+DohRR2ISVi3i NAEgDuSbYYNxctnvXqU6O6EPy3mzoFPDoiOQwBfVtFrjxBbND9BUK2bjtUyGt4x8I/Vulzrt qLPTokva+b97DHRgbCA/aLLYIrU6QoqOFJ8GrAbro/FZLYh4m1oJk3FEHVQOKkk7xzIaFmmP QGJRL8m6nrIZFTrQ+X2wmzfLD55K/UiqbekOuMiWbY9EbwIDAQABo10wWzBLBgNVHREERDBC gQxtYWlsQHJpbmsubnWBEHJpbmtAZnJlZWJzZC5vcmeBEXJpbmtAaWwuZm9udHlzLm5sgQ1y aW5rQHN0YWNrLm5sMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAIfIcieRjePBA wjZqvOdGpyPcNDnK/ubeQSTV5Y4AHWxm1sXhQxB/XrQ3RVdz1qDnBRL1AjkEBAl8e9+am4s6 D6TaSlmJeNXn6ZPJTQecisz3M+AKiMckShM3oAeUi0ktn1yNYR+hz5aQN612XT5OZRYznJVZ kPf1DiA2RVVyz+MwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQG EwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNV BAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2Vz IERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkq hkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAw WhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUE cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH 5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBly YLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJo dHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNV HQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYv wPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3 h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYICUTCCAk0CAQEwdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECECK43tuz2mDq3cjS fobk45MwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wNzAxMDUxOTQ5NThaMCMGCSqGSIb3DQEJBDEWBBRKAXdJLbKJhnMfwNTmOeQm nNH0WzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQAb utKLROv5w0B2jHKyAp+YxgAaZu3FNqWJ7DhdvEm+VWwrrWCdy6fycBpyy3z1+x/iNfMyFKE6 KGGDcj2tOMxe1wDN+SuE8BDDOc1LR8oZZOWVuFz9Dctp90sm7sVVv3b6PUXPxTIK0nfGObCp W1025xFeeK6GTywugieYCY5EiuOhOFfIfYBLXB0zeGPOuZDu8zC63IM4DUsKFMTBtfAQJ8bh W5adlSjTOZEHSQIXLjknvtECJP+7ZUItaT3oKrxjBAVYQiJ4R0wqxL+k8NxhtSMvnZGdWy5B Iz1Nqc2UDi2bL13qJPPJB4KISMNJ+o3bv3cNAWJDgIAKn2aZjTHp --BwCQnh7xodEAoBMC-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 5 22:13:26 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C99EF16A407; Fri, 5 Jan 2007 22:13:26 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.t-hosting.hu (server.t-hosting.hu [217.20.133.7]) by mx1.freebsd.org (Postfix) with ESMTP id 808F413C458; Fri, 5 Jan 2007 22:13:26 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by server.t-hosting.hu (Postfix) with ESMTP id E3C349C0942; Fri, 5 Jan 2007 22:48:31 +0100 (CET) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.t-hosting.hu ([127.0.0.1]) by localhost (server.t-hosting.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xMmOt37F1-QS; Fri, 5 Jan 2007 22:48:26 +0100 (CET) Received: from [192.168.2.186] (catv-50635cb6.catv.broadband.hu [80.99.92.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.t-hosting.hu (Postfix) with ESMTP id 4571C9C0950; Fri, 5 Jan 2007 22:48:26 +0100 (CET) Message-ID: <459EC79F.8070106@FreeBSD.org> Date: Fri, 05 Jan 2007 22:48:15 +0100 From: Gabor Kovesdan User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Rene Ladan References: <459E6477.2010508@clearchain.com> <200701051634.00293.max@love2party.net> <459E75A5.7000309@FreeBSD.org> <200701051732.27176.max@love2party.net> <459E7FBD.4050707@gmail.com> In-Reply-To: <459E7FBD.4050707@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Benjamin Close , Gavin Atkinson , Florent Thoumie , freebsd-hackers@freebsd.org, freebsd-drivers@freebsd.org, Attilio Rao , damien.bergamini@free.fr, Max Laier Subject: Re: Updated Driver for 3945ABG Intel 3945ABG Wireless 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: Fri, 05 Jan 2007 22:13:26 -0000 Rene Ladan schrieb: > [...] > > Added Gavin Atkinson to the CC list, he is working on a wpi(4) clone > which I'm using at the moment. It has some memory corruption error, but > is otherwise behaving quite good. > > Regards, > Rene > I did a quick try with this driver and unfortunately it suffers from the same allocation issue as the old one. I talked to Gavin about this issue and I promised I'll provide him the pieces of information he asked when I have a bit more time, but I have a very busy period now due to the uni exams. The problem seems to be the same for both version. Regards, Gabor From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 5 21:06:17 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49F2916A407; Fri, 5 Jan 2007 21:06:17 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 88F7813C45E; Fri, 5 Jan 2007 21:06:14 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (kdapat@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l05L62l1042600; Fri, 5 Jan 2007 22:06:07 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l05L60a6042599; Fri, 5 Jan 2007 22:06:00 +0100 (CET) (envelope-from olli) From: Oliver Fromme Message-Id: <200701052106.l05L60a6042599@lurza.secnetix.de> To: jhb@freebsd.org (John Baldwin) Date: Fri, 5 Jan 2007 22:06:00 +0100 (CET) In-Reply-To: <200701041459.18321.jhb@freebsd.org> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 05 Jan 2007 22:06:08 +0100 (CET) X-Mailman-Approved-At: Sat, 06 Jan 2007 02:35:07 +0000 Cc: erik.udo@gmail.com, freebsd-hackers@freebsd.org, dougb@freebsd.org Subject: Re: Init.c, making it chroot 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, 05 Jan 2007 21:06:17 -0000 John Baldwin wrote: > Oliver Fromme wrote: > > John Baldwin wrote: > > > just pass the string literal to the kenv() function, e.g. > > > > In fact that's what I tried first ... Alas: > > warning: passing arg 2 of `kenv' discards qualifiers from pointer target type > > It's fixed in HEAD, I'll MFC the prototype fix for kenv() to 6.x. Thankyou! That const stuff really drives me crazy. I still need the ugly __DECONST macro to assign the script name to argv[2] for the execv() call. :-( > > Of course it is possible to write an additional function > > run_script(char *script) which contains runcom's current > > code, and make the runcom() function a wrapper that just > > calls run_script(_PATH_RUNCOM). > > [...] > > That sounds great. I have updated the patch and included your suggestions. Also, a bug has been fixed: The -s option was ignored if an init_script was executed that terminated successfully (exit code 0). That's the one case that I didn't test earlier. :-) To fix it, I needed to introduce a new variable for the initial state transition. By the way, I'm wondering why the requested_transition variable is not declared "volatile". It is modified from a signal handler, so it should be declared volatile in order to prevent the compiler from optimizing certain access patterns. Is there a reason why it isn't declared that way, or have we just been lucky that it didn't break? While I was there, I added a third kenv variable called "init_shell". If it is set, it is used as the shell executable for running scripts, instead of the default /bin/sh. I think that's useful, because when using the init_script and init_chroot features, it might make sense to use a shell binary (maybe statically linked) that's located at a special place inside the chroot. After all, the point of allowing chrooted systems is to share the file system with other systems, so it's better to keep as few files as possible outside the chroot. On my test ISO -- which uses all of the new features -- the root directory only contains /boot, /dev and /ochroot. As usual, the new ISO is here (17.5 MB): http://www.secnetix.de/tmp/init_chroot/ (BTW, when you boot it to multi-user mode, you can log in as "root" without password.) /boot/loader.conf contains these lines: init_path="/ochroot/sbin/init" init_shell="/ochroot/static/sh" init_script="/ochroot/etc/rc.init" init_chroot="/ochroot" That means that init(8) runs /ochroot/etc/rc.init first, using /ochroot/static/sh as the shell. The rc.init file prints a message and changes init_shell to the default "/bin/sh" (using the kenv(1) utility). Then init(8) performs a chroot to /ochroot and runs /etc/rc within it, now using /bin/sh as the shell (inside chroot), as usual. A final note: With my patch, the init binary grows from 535 KB to 537 KB (on RELENG_6), i.e. < 0.5%. Best regards Oliver --- init.c.orig Mon Aug 7 15:10:25 2006 +++ init.c Fri Jan 5 21:16:05 2007 @@ -55,6 +55,7 @@ #include #include #include +#include #include #include #include @@ -121,6 +122,8 @@ state_func_t catatonia(void); state_func_t death(void); +state_func_t run_script(const char *); + enum { AUTOBOOT, FASTBOOT } runcom_mode = AUTOBOOT; #define FALSE 0 #define TRUE 1 @@ -131,9 +134,11 @@ int devfs; void transition(state_t); -state_t requested_transition = runcom; +state_t requested_transition; void setctty(const char *); +const char *get_shell(void); +void write_stderr(const char *message); typedef struct init_session { int se_index; /* index of entry in ttys file */ @@ -187,6 +192,8 @@ int main(int argc, char *argv[]) { + state_t initial_transition = runcom; + char kenv_value[PATH_MAX]; int c; struct sigaction sa; sigset_t mask; @@ -262,7 +269,7 @@ devfs = 1; break; case 's': - requested_transition = single_user; + initial_transition = single_user; break; case 'f': runcom_mode = FASTBOOT; @@ -275,6 +282,65 @@ if (optind != argc) warning("ignoring excess arguments"); + /* + * We catch or block signals rather than ignore them, + * so that they get reset on exec. + */ + handle(badsys, SIGSYS, 0); + handle(disaster, SIGABRT, SIGFPE, SIGILL, SIGSEGV, + SIGBUS, SIGXCPU, SIGXFSZ, 0); + handle(transition_handler, SIGHUP, SIGINT, SIGTERM, SIGTSTP, + SIGUSR1, SIGUSR2, 0); + handle(alrm_handler, SIGALRM, 0); + sigfillset(&mask); + delset(&mask, SIGABRT, SIGFPE, SIGILL, SIGSEGV, SIGBUS, SIGSYS, + SIGXCPU, SIGXFSZ, SIGHUP, SIGINT, SIGTERM, SIGTSTP, SIGALRM, + SIGUSR1, SIGUSR2, 0); + sigprocmask(SIG_SETMASK, &mask, (sigset_t *) 0); + sigemptyset(&sa.sa_mask); + sa.sa_flags = 0; + sa.sa_handler = SIG_IGN; + (void) sigaction(SIGTTIN, &sa, (struct sigaction *)0); + (void) sigaction(SIGTTOU, &sa, (struct sigaction *)0); + + /* + * Paranoia. + */ + close(0); + close(1); + close(2); + + if (kenv(KENV_GET, "init_script", kenv_value, sizeof(kenv_value)) > 0) { + state_func_t next_transition; + + if ((next_transition = run_script(kenv_value)) != 0) + initial_transition = (state_t) next_transition; + } + + if (kenv(KENV_GET, "init_chroot", kenv_value, sizeof(kenv_value)) > 0) { + if (chdir(kenv_value) != 0 || chroot(".") != 0) + warning("Can't chroot to %s: %m", kenv_value); + } + + /* + * Additional check if devfs needs to be mounted: + * If "/" and "/dev" have the same device number, + * then it hasn't been mounted yet. + */ + if (!devfs) { + struct stat stst; + dev_t root_devno; + + stat("/", &stst); + root_devno = stst.st_dev; + if (stat("/dev", &stst) != 0) + warning("Can't stat /dev: %m"); + else { + if (stst.st_dev == root_devno) + devfs++; + } + } + if (devfs) { struct iovec iov[4]; char *s; @@ -312,37 +378,9 @@ } /* - * We catch or block signals rather than ignore them, - * so that they get reset on exec. - */ - handle(badsys, SIGSYS, 0); - handle(disaster, SIGABRT, SIGFPE, SIGILL, SIGSEGV, - SIGBUS, SIGXCPU, SIGXFSZ, 0); - handle(transition_handler, SIGHUP, SIGINT, SIGTERM, SIGTSTP, - SIGUSR1, SIGUSR2, 0); - handle(alrm_handler, SIGALRM, 0); - sigfillset(&mask); - delset(&mask, SIGABRT, SIGFPE, SIGILL, SIGSEGV, SIGBUS, SIGSYS, - SIGXCPU, SIGXFSZ, SIGHUP, SIGINT, SIGTERM, SIGTSTP, SIGALRM, - SIGUSR1, SIGUSR2, 0); - sigprocmask(SIG_SETMASK, &mask, (sigset_t *) 0); - sigemptyset(&sa.sa_mask); - sa.sa_flags = 0; - sa.sa_handler = SIG_IGN; - (void) sigaction(SIGTTIN, &sa, (struct sigaction *)0); - (void) sigaction(SIGTTOU, &sa, (struct sigaction *)0); - - /* - * Paranoia. - */ - close(0); - close(1); - close(2); - - /* * Start the state machine. */ - transition(requested_transition); + transition(initial_transition); /* * Should never reach here. @@ -558,6 +596,23 @@ } } +const char * +get_shell(void) +{ + static char kenv_value[PATH_MAX]; + + if (kenv(KENV_GET, "init_shell", kenv_value, sizeof(kenv_value)) > 0) + return kenv_value; + else + return _PATH_BSHELL; +} + +void +write_stderr(const char *message) +{ + write(STDERR_FILENO, message, strlen(message)); +} + /* * Bring the system up single user. */ @@ -567,7 +622,7 @@ pid_t pid, wpid; int status; sigset_t mask; - const char *shell = _PATH_BSHELL; + const char *shell; char *argv[2]; #ifdef SECURE struct ttyent *typ; @@ -589,6 +644,8 @@ _exit(0); } + shell = get_shell(); + if ((pid = fork()) == 0) { /* * Start the single user session. @@ -605,7 +662,7 @@ pp = getpwnam("root"); if (typ && (typ->ty_status & TTY_SECURE) == 0 && pp && *pp->pw_passwd) { - write(STDERR_FILENO, banner, sizeof banner - 1); + write_stderr(banner); for (;;) { clear = getpass("Password:"); if (clear == 0 || *clear == '\0') @@ -626,10 +683,10 @@ char *cp = altshell; int num; -#define SHREQUEST \ - "Enter full pathname of shell or RETURN for " _PATH_BSHELL ": " - (void)write(STDERR_FILENO, - SHREQUEST, sizeof(SHREQUEST) - 1); +#define SHREQUEST "Enter full pathname of shell or RETURN for " + write_stderr(SHREQUEST); + write_stderr(shell); + write_stderr(": "); while ((num = read(STDIN_FILENO, cp, 1)) != -1 && num != 0 && *cp != '\n' && cp < &altshell[127]) cp++; @@ -718,11 +775,35 @@ state_func_t runcom(void) { + state_func_t next_transition; + + if ((next_transition = run_script(_PATH_RUNCOM)) != 0) + return next_transition; + + runcom_mode = AUTOBOOT; /* the default */ + /* NB: should send a message to the session logger to avoid blocking. */ + logwtmp("~", "reboot", ""); + return (state_func_t) read_ttys; +} + +/* + * Run a shell script. + * Returns 0 on success, otherwise the next transition to enter: + * - single_user if fork/execv/waitpid failed, or if the script + * terminated with a signal or exit code != 0. + * - death if a SIGTERM was delivered to init(8). + */ +state_func_t +run_script(const char *script) +{ pid_t pid, wpid; int status; char *argv[4]; + const char *shell; struct sigaction sa; + shell = get_shell(); + if ((pid = fork()) == 0) { sigemptyset(&sa.sa_mask); sa.sa_flags = 0; @@ -733,11 +814,10 @@ setctty(_PATH_CONSOLE); char _sh[] = "sh"; - char _path_runcom[] = _PATH_RUNCOM; char _autoboot[] = "autoboot"; argv[0] = _sh; - argv[1] = _path_runcom; + argv[1] = __DECONST(char *, script); argv[2] = runcom_mode == AUTOBOOT ? _autoboot : 0; argv[3] = 0; @@ -746,14 +826,13 @@ #ifdef LOGIN_CAP setprocresources(RESOURCE_RC); #endif - execv(_PATH_BSHELL, argv); - stall("can't exec %s for %s: %m", _PATH_BSHELL, _PATH_RUNCOM); + execv(shell, argv); + stall("can't exec %s for %s: %m", shell, script); _exit(1); /* force single user mode */ } if (pid == -1) { - emergency("can't fork for %s on %s: %m", - _PATH_BSHELL, _PATH_RUNCOM); + emergency("can't fork for %s on %s: %m", shell, script); while (waitpid(-1, (int *) 0, WNOHANG) > 0) continue; sleep(STALL_TIMEOUT); @@ -772,13 +851,13 @@ return (state_func_t) death; if (errno == EINTR) continue; - warning("wait for %s on %s failed: %m; going to single user mode", - _PATH_BSHELL, _PATH_RUNCOM); + warning("wait for %s on %s failed: %m; going to " + "single user mode", shell, script); return (state_func_t) single_user; } if (wpid == pid && WIFSTOPPED(status)) { warning("init: %s on %s stopped, restarting\n", - _PATH_BSHELL, _PATH_RUNCOM); + shell, script); kill(pid, SIGCONT); wpid = -1; } @@ -795,18 +874,15 @@ } if (!WIFEXITED(status)) { - warning("%s on %s terminated abnormally, going to single user mode", - _PATH_BSHELL, _PATH_RUNCOM); + warning("%s on %s terminated abnormally, going to single " + "user mode", shell, script); return (state_func_t) single_user; } if (WEXITSTATUS(status)) return (state_func_t) single_user; - runcom_mode = AUTOBOOT; /* the default */ - /* NB: should send a message to the session logger to avoid blocking. */ - logwtmp("~", "reboot", ""); - return (state_func_t) read_ttys; + return (state_func_t) 0; } /* @@ -1465,6 +1541,7 @@ int shutdowntimeout; size_t len; char *argv[4]; + const char *shell; struct sigaction sa; struct stat sb; @@ -1477,6 +1554,8 @@ if (stat(_PATH_RUNDOWN, &sb) == -1 && errno == ENOENT) return 0; + shell = get_shell(); + if ((pid = fork()) == 0) { int fd; @@ -1517,14 +1596,13 @@ #ifdef LOGIN_CAP setprocresources(RESOURCE_RC); #endif - execv(_PATH_BSHELL, argv); - warning("can't exec %s for %s: %m", _PATH_BSHELL, _PATH_RUNDOWN); + execv(shell, argv); + warning("can't exec %s for %s: %m", shell, _PATH_RUNDOWN); _exit(1); /* force single user mode */ } if (pid == -1) { - emergency("can't fork for %s on %s: %m", - _PATH_BSHELL, _PATH_RUNDOWN); + emergency("can't fork for %s on %s: %m", shell, _PATH_RUNDOWN); while (waitpid(-1, (int *) 0, WNOHANG) > 0) continue; sleep(STALL_TIMEOUT); @@ -1548,20 +1626,20 @@ if (clang == 1) { /* we were waiting for the sub-shell */ kill(wpid, SIGTERM); - warning("timeout expired for %s on %s: %m; going to single user mode", - _PATH_BSHELL, _PATH_RUNDOWN); + warning("timeout expired for %s on %s: %m; going to " + "single user mode", shell, _PATH_RUNDOWN); return -1; } if (wpid == -1) { if (errno == EINTR) continue; - warning("wait for %s on %s failed: %m; going to single user mode", - _PATH_BSHELL, _PATH_RUNDOWN); + warning("wait for %s on %s failed: %m; going to " + "single user mode", shell, _PATH_RUNDOWN); return -1; } if (wpid == pid && WIFSTOPPED(status)) { warning("init: %s on %s stopped, restarting\n", - _PATH_BSHELL, _PATH_RUNDOWN); + shell, _PATH_RUNDOWN); kill(pid, SIGCONT); wpid = -1; } @@ -1584,8 +1662,8 @@ } if (!WIFEXITED(status)) { - warning("%s on %s terminated abnormally, going to single user mode", - _PATH_BSHELL, _PATH_RUNDOWN); + warning("%s on %s terminated abnormally, going to " + "single user mode", shell, _PATH_RUNDOWN); return -2; } -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "File names are infinite in length, where infinity is set to 255 characters." -- Peter Collinson, "The Unix File System" From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 6 00:06:33 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D5BC216A47B; Sat, 6 Jan 2007 00:06:33 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (palm.hoeg.nl [83.98.131.212]) by mx1.freebsd.org (Postfix) with ESMTP id 8FFC413C46B; Sat, 6 Jan 2007 00:06:33 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 98B391CC6E; Sat, 6 Jan 2007 01:06:32 +0100 (CET) Date: Sat, 6 Jan 2007 01:06:32 +0100 From: Ed Schouten To: John Baldwin Message-ID: <20070106000632.GA46094@hoeg.nl> References: <20070104201434.GS1072@hoeg.nl> <200701051427.46146.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <200701051427.46146.jhb@freebsd.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Mailman-Approved-At: Sat, 06 Jan 2007 02:35:17 +0000 Cc: FreeBSD Hackers , philippe.lang@attiksystem.ch, bug-followup@freebsd.org Subject: Re: kern/89528: [jail] impossible to kill a jail 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, 06 Jan 2007 00:06:33 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * John Baldwin wrote: > Why aren't the pty's destroyed? Once all references to the pty are close= d it =20 > should be destroyed and the resulting devfs_free() should drop the refere= nce. > Is the pty somehow stuck on the dead_cdevsw? Ouch! I found a comment in tty_pty.c that it doesn't deallocate pty's anymore. Not a single destroy_dev() is called by tty_pty.c. This means the FreeBSD kernel leaks a lot of cdev's and thus ucred's and my patch is working around another bug. Yours, --=20 Ed Schouten WWW: http://g-rave.nl/ --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFnugI52SDGA2eCwURAggEAJsF9WpUHCnKZaGvtoGp45MFTZRbDwCfexxV UAdEvGoYVyK0gLlbI+8p8VU= =Uo2h -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 6 18:34:17 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A42D816A415; Sat, 6 Jan 2007 18:34:17 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 634B213C469; Sat, 6 Jan 2007 18:34:17 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id l06IXax0085038; Sat, 6 Jan 2007 11:33:36 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 06 Jan 2007 11:33:48 -0700 (MST) Message-Id: <20070106.113348.353676879.imp@bsdimp.com> To: olli@lurza.secnetix.de From: "M. Warner Losh" In-Reply-To: <200701052106.l05L60a6042599@lurza.secnetix.de> References: <200701041459.18321.jhb@freebsd.org> <200701052106.l05L60a6042599@lurza.secnetix.de> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 06 Jan 2007 11:33:36 -0700 (MST) Cc: erik.udo@gmail.com, freebsd-hackers@freebsd.org, dougb@freebsd.org Subject: Re: Init.c, making it chroot 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, 06 Jan 2007 18:34:17 -0000 this patch looks good, however, one nit: In message: <200701052106.l05L60a6042599@lurza.secnetix.de> Oliver Fromme writes: : + if (stat("/dev", &stst) != 0) : + warning("Can't stat /dev: %m"); : + else { : + if (stst.st_dev == root_devno) : + devfs++; : + } is more succinctly expressed as: + if (stat("/dev", &stst) != 0) + warning("Can't stat /dev: %m"); + else if (stst.st_dev == root_devno) + devfs++; Also, kenv(KENV_GET, ... is used a lot. Maybe it makes sense to have a simple kenvget call. Would make a few lines a little shorter if nothing else. Otherwise, I think this is a great patch. I don't see other problems with it. Warner From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 6 19:27:49 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DAC416A416; Sat, 6 Jan 2007 19:27:49 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 779BE13C4A8; Sat, 6 Jan 2007 19:27:48 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (bapqbq@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l06JRXbD095829; Sat, 6 Jan 2007 20:27:39 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l06JRWoB095827; Sat, 6 Jan 2007 20:27:32 +0100 (CET) (envelope-from olli) From: Oliver Fromme Message-Id: <200701061927.l06JRWoB095827@lurza.secnetix.de> To: imp@bsdimp.com (M. Warner Losh) Date: Sat, 6 Jan 2007 20:27:32 +0100 (CET) In-Reply-To: <20070106.113348.353676879.imp@bsdimp.com> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Sat, 06 Jan 2007 20:27:40 +0100 (CET) X-Mailman-Approved-At: Sat, 06 Jan 2007 21:25:48 +0000 Cc: erik.udo@gmail.com, freebsd-hackers@freebsd.org, dougb@freebsd.org Subject: Re: Init.c, making it chroot 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, 06 Jan 2007 19:27:49 -0000 M. Warner Losh wrote: > > this patch looks good, however, one nit: > > In message: <200701052106.l05L60a6042599@lurza.secnetix.de> > Oliver Fromme writes: > : + if (stat("/dev", &stst) != 0) > : + warning("Can't stat /dev: %m"); > : + else { > : + if (stst.st_dev == root_devno) > : + devfs++; > : + } > > is more succinctly expressed as: > > + if (stat("/dev", &stst) != 0) > + warning("Can't stat /dev: %m"); > + else if (stst.st_dev == root_devno) > + devfs++; Agreed. I thought style(9) would forbid nesting "else if" like that, but I was wrong. > Also, kenv(KENV_GET, ... is used a lot. Maybe it makes sense to have > a simple kenvget call. Would make a few lines a little shorter if > nothing else. KENV_GET is used three times. Using a wrapper function would save 7 characters per call. I don't think it's really worth it. But if you insist, I can update the patch with such a function. By the way, how about declaring requested_transition volatile, as explained in my previus mail? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. cat man du : where Unix geeks go when they die From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 6 22:51:56 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 439CF16A40F for ; Sat, 6 Jan 2007 22:51:56 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 06A8313C448 for ; Sat, 6 Jan 2007 22:51:55 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from localhost (localhost [127.0.0.1]) by people.fsn.hu (Postfix) with ESMTP id 2591F8442F for ; Sat, 6 Jan 2007 23:28:59 +0100 (CET) Received: from people.fsn.hu ([127.0.0.1]) by localhost (people.fsn.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 67039-08 for ; Sat, 6 Jan 2007 23:28:50 +0100 (CET) Received: from [172.16.164.1] (fw.axelero.hu [195.228.243.120]) by people.fsn.hu (Postfix) with ESMTP id A81E284420 for ; Sat, 6 Jan 2007 23:28:50 +0100 (CET) Message-ID: <45A0229F.7070701@fsn.hu> Date: Sat, 06 Jan 2007 23:28:47 +0100 From: Attila Nagy User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at fsn.hu Subject: ufs_rename: fvp == tvp (can't happen), but it did 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, 06 Jan 2007 22:51:56 -0000 Hello, I have two, completely identical machines, which run completely identical services, with approximately the same load and access patterns. The servers run qmail for receiving e-mails via the network and courier for feeding the users via pop and imap. The problem is the following: on machine A the mail spool is on a local disk array (via ciss). On machine B we run experiments with an FC disk array, so the e-mails are on gmirror'ed filesystems (on ciss for the local disks and on isp for the FC array). The strange thing happens when both the local and FC disks are working in the mirrors. I get the following warning very often: ufs_rename: fvp == tvp (can't happen) If I do a gmirror remove for the FC array, these go away. Also, the other machine (with only local disks) is free from this. The servers run RELENG_6 (latest), have 1.271.2.7 from ufs_vnops.c (which prints this error). The architecture is i386 and there are quad cores (2xdual core Xeons), so the kernel is SMP. Any ideas? Thanks,