From owner-freebsd-stable@FreeBSD.ORG Sun Dec 13 04:08:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF1F8106568D for ; Sun, 13 Dec 2009 04:08:56 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (dsl081-172-045.sea1.dsl.speakeasy.net [64.81.172.45]) by mx1.freebsd.org (Postfix) with ESMTP id 6EEDF8FC1B for ; Sun, 13 Dec 2009 04:08:56 +0000 (UTC) Received: from webmail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id nBD48NGD098759; Sat, 12 Dec 2009 20:08:29 -0800 (PST) (envelope-from chris#@1command.com) Received: from hitme.hitometer.net ([64.81.172.194]) (Local authenticated user inf0s) by webmail.1command.com with HTTP; Sat, 12 Dec 2009 20:08:53 -0800 (PST) Message-ID: <7f052646787bb8c47f847ecd3176e706.HRCIM@webmail.1command.com> In-Reply-To: <1260628594.2281.30.camel@balrog.2hip.net> References: <1260628594.2281.30.camel@balrog.2hip.net> Date: Sat, 12 Dec 2009 20:08:53 -0800 (PST) From: "Chris H" To: freebsd-stable@freebsd.org User-Agent: HRC Internet Messaging/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Robert Noland Subject: Re: MTRR failure revisited (nVidia) 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 04:08:56 -0000 On Sat, December 12, 2009 6:36 am, Robert Noland wrote: > On Sat, 2009-12-12 at 03:47 -0800, Chris H wrote: > >> Greetings, >> I brought this same error to the list back in May 2009. >> Under: failed to set mtrr: invalid argument. >> Well, I'm back using the same card: >> GeForce4 MX 440-SE - VideoRam 65536 - BusID PCI:1:3:0. >> The driver is different, I'm using: nvidia-driver-96.43.13 out of ports on a >> custom 8-STABLE kernel. Xorg starts up, and produces a desktop. But it's "dog >> slow" UPDATE: Disabling HAL /greatly/ increased performance eg; hal_enable="YES" --> hal_enable="NO" in /etc/rc.conf More specifically, response times are now closer to what one would anticipate/ expect now that HAL has been dis-abled in rc.conf. >> , and the nvidia driver emits the following error: NVIDIA: failed to set >> MTRR 0xf0000000, 0M (write-combining) >> several times. I understand John Baldwin provided some "invaluable" help some >> time ago: >> http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016995.html >> and I was wondering if anyone has gained any further "insight" with these >> cards, and how to better "interface" them in BSD. Last I spoke on the topic, I >> was informed that the memory was basically "untouchable" - or perhaps in other >> words; can't be manipulated. Has this changed? Surely someone else has had to >> deal with this besides me. It seems crazy to spend a "boat load" of $$ on >> these high performers, and not be able to use them on a high performing OS - >> no? :) Sure, the one I'm working with now is "legacy". But I have 3 near new, >> top of their line cards, and thus far it appears that if I ever hope to use >> them, I'll be forced to... hack, choke.. spin up a WIN CD. :( >> >> Thank you for all your time, consideration, and insight. >> Greetings Robert, and thank you for taking the time to respond. > > The mtrr issue has to do with the system / bios, not the graphics card. > While I've not used the blob driver, the issue in Nouveau and other drm > drivers is that on many systems if you run "memcontrol list", you will see a line > something like this: > > 0x0/0x100000000 BIOS write-back set-by-firmware active I see the following (condensed for brevity): 0x0/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x10000/0x10000-0x70000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x80000/0x4000 BIOS-0x9c000/0x4000 write-back fixed-base fixed-length set-by-firmware active 0xa0000/0x4000-0xbc000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xc0000/0x10000xc7000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc8000/0x1000-0xff000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0x0/0x40000000 BIOS write-back set-by-firmware active 0xe0000000/0x20000000 BIOS uncacheable set-by-firmware active While I could pull the BIOS out of it's socket after POST. I don't suppose I could read it's contents to file, and then allow manipulation of the regions currently "off limits"? > > > This says that all of memory defaults to write-back. We aren't allowed > to overlap write-combined on top of write-back, so the setting of mtrr fails. Isn't it /best/ to choose write-back, so as to mark the memory dirty? I /could/ choose write-ahead, or write-through. > I've looked at ways to try to fix this in the past, but > generally found it more practical to use PAT than try to override/fix bios > behavior. Marius Nünnerich also mentioned this in a response to this thread. Would you be willing to share any additional information, based on your experiences using PAT? > > I've been told that linux does apply some BIOS fixups to address this > issue, which I might look into again, but I make no promises. Is there anything I could do that would help you in this regard? There are also a > very limited number of variable mtrr registers (7 on most hardware, iirc) for > managing caching. Thank you again for taking the time to respond. --Chris H > > robert. > >> --Chris H >> >> >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > -- > Robert Noland > FreeBSD > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > From owner-freebsd-stable@FreeBSD.ORG Sun Dec 13 04:36:44 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D06CF106566B for ; Sun, 13 Dec 2009 04:36:44 +0000 (UTC) (envelope-from graham@menhennitt.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 532F18FC12 for ; Sun, 13 Dec 2009 04:36:44 +0000 (UTC) Received: from maxwell.mencon.com.au (c122-107-224-152.eburwd5.vic.optusnet.com.au [122.107.224.152]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id nBD4afTL001844 for ; Sun, 13 Dec 2009 15:36:42 +1100 Received: from [203.2.73.73] (chief.mencon.com.au [203.2.73.73]) by maxwell.mencon.com.au (Postfix) with ESMTP id 59B665CD2 for ; Sun, 13 Dec 2009 15:36:41 +1100 (EST) Message-ID: <4B246F59.4020206@menhennitt.com.au> Date: Sun, 13 Dec 2009 15:36:41 +1100 From: Graham Menhennitt User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: FreeBSD stable Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: HP LJ 1020: "ulpt0: offline" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 04:36:44 -0000 I have a HP Laserjet 1020 printer that I've been using with FreeBSD 7 and 8 for the last few years. It's connected via USB as described in my blog at http://menhenitt.com.au and it's been working up until today. I just did a csup to RELENG_8 as of yesterday. After a make build/installworld and build/installkernel and "portupgrade -a", it's stopped working. When I power it on, I hear its startup noise and then the second noise as the firmware is downloaded to it. After that, it doesn't respond. CUPS reports "Waiting for printer to become available..." and dmesg shows: ugen1.3: at usbus1 ulpt0: on usbus1 ulpt0: using bi-directional mode ulpt0: offline The last line "ulpt0: offline" appears just after the firmware download. Foo2zjs doesn't seem to have changed recently. CUPS has changed but I doubt that's the problem. Maybe something to do with USB drivers? Does anybody have any clues please. Thanks, Graham From owner-freebsd-stable@FreeBSD.ORG Sun Dec 13 09:59:21 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55BDA106566B for ; Sun, 13 Dec 2009 09:59:21 +0000 (UTC) (envelope-from usselmann.m@icg-online.de) Received: from oslo074.server4you.de (oslo074.server4you.de [62.75.178.74]) by mx1.freebsd.org (Postfix) with ESMTP id A2B388FC08 for ; Sun, 13 Dec 2009 09:59:20 +0000 (UTC) Received: (qmail 18289 invoked from network); 13 Dec 2009 10:32:44 +0100 Received: from p54b2381e.dip.t-dialin.net (HELO icg-pc209.icg-pc213) (84.178.56.30) by oslo074.server4you.de with SMTP; 13 Dec 2009 10:32:44 +0100 Date: Sun, 13 Dec 2009 10:32:37 +0100 From: Manfred Usselmann To: freebsd-stable@freebsd.org Message-Id: <20091213103237.d01b51f2.usselmann.m@icg-online.de> Organization: ICG IT Consulting GmbH X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.3; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: duplicity ftp backup / ncftp no longer working since 8.0-Release X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 09:59:21 -0000 Hi, since my upgrade to 8.0-RELEASE my backup solution with duplicity is no longer working because ncftpput fails. The error message from ncftp 3.2.2_1: Could not read reply from control connection -- timed out. S.a. http://www.freebsd.org/cgi/query-pr.cgi?pr=140934 Does anybody know a solution or a workaround? Thanks, Manfred -- Manfred Usselmann ICG IT Consulting GmbH, Kelkheim From owner-freebsd-stable@FreeBSD.ORG Sun Dec 13 14:05:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DD9C106568D for ; Sun, 13 Dec 2009 14:05:15 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 31CA58FC0A for ; Sun, 13 Dec 2009 14:05:14 +0000 (UTC) Received: from [192.168.1.4] (adsl-156-16-112.bna.bellsouth.net [70.156.16.112]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nBDE531D067040 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 13 Dec 2009 09:05:03 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Chris H In-Reply-To: <7f052646787bb8c47f847ecd3176e706.HRCIM@webmail.1command.com> References: <1260628594.2281.30.camel@balrog.2hip.net> <7f052646787bb8c47f847ecd3176e706.HRCIM@webmail.1command.com> Content-Type: text/plain; charset="ISO-8859-1" Organization: FreeBSD Date: Sun, 13 Dec 2009 08:04:57 -0600 Message-Id: <1260713097.2281.61.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-stable@freebsd.org Subject: Re: MTRR failure revisited (nVidia) 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 14:05:15 -0000 On Sat, 2009-12-12 at 20:08 -0800, Chris H wrote: > On Sat, December 12, 2009 6:36 am, Robert Noland wrote: > > On Sat, 2009-12-12 at 03:47 -0800, Chris H wrote: > > > >> Greetings, > >> I brought this same error to the list back in May 2009. > >> Under: failed to set mtrr: invalid argument. > >> Well, I'm back using the same card: > >> GeForce4 MX 440-SE - VideoRam 65536 - BusID PCI:1:3:0. > >> The driver is different, I'm using: nvidia-driver-96.43.13 out of ports on a > >> custom 8-STABLE kernel. Xorg starts up, and produces a desktop. But it's "dog > >> slow" > UPDATE: > Disabling HAL /greatly/ increased performance > eg; hal_enable="YES" --> hal_enable="NO" in /etc/rc.conf > More specifically, response times are now closer to what one would anticipate/ > expect now that HAL has been dis-abled in rc.conf. > >> , and the nvidia driver emits the following error: NVIDIA: failed to set > >> MTRR 0xf0000000, 0M (write-combining) > >> several times. I understand John Baldwin provided some "invaluable" help some > >> time ago: > >> http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016995.html > >> and I was wondering if anyone has gained any further "insight" with these > >> cards, and how to better "interface" them in BSD. Last I spoke on the topic, I > >> was informed that the memory was basically "untouchable" - or perhaps in other > >> words; can't be manipulated. Has this changed? Surely someone else has had to > >> deal with this besides me. It seems crazy to spend a "boat load" of $$ on > >> these high performers, and not be able to use them on a high performing OS - > >> no? :) Sure, the one I'm working with now is "legacy". But I have 3 near new, > >> top of their line cards, and thus far it appears that if I ever hope to use > >> them, I'll be forced to... hack, choke.. spin up a WIN CD. :( > >> > >> Thank you for all your time, consideration, and insight. > >> > Greetings Robert, and thank you for taking the time to respond. > > > > The mtrr issue has to do with the system / bios, not the graphics card. > > While I've not used the blob driver, the issue in Nouveau and other drm > > drivers is that on many systems if you run "memcontrol list", you will see a line > > something like this: > > > > 0x0/0x100000000 BIOS write-back set-by-firmware active > I see the following (condensed for brevity): > 0x0/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active > 0x10000/0x10000-0x70000/0x10000 BIOS write-back fixed-base fixed-length > set-by-firmware active > 0x80000/0x4000 BIOS-0x9c000/0x4000 write-back fixed-base fixed-length > set-by-firmware active > 0xa0000/0x4000-0xbc000/0x4000 BIOS uncacheable fixed-base fixed-length > set-by-firmware active > 0xc0000/0x10000xc7000/0x1000 BIOS write-protect fixed-base fixed-length > set-by-firmware active > 0xc8000/0x1000-0xff000/0x1000 BIOS uncacheable fixed-base fixed-length > set-by-firmware active > 0x0/0x40000000 BIOS write-back set-by-firmware active The above entry is the one that causes setting write-combine MTRR to fail. > 0xe0000000/0x20000000 BIOS uncacheable set-by-firmware active > > While I could pull the BIOS out of it's socket after POST. I don't suppose > I could read it's contents to file, and then allow manipulation of the > regions currently "off limits"? This is more easily achieved in our MTRR code I expect, certainly than BIOS hacking all of the effected machines. Frankly, all of my more modern machines have this issue. > > > > This says that all of memory defaults to write-back. We aren't allowed > > to overlap write-combined on top of write-back, so the setting of mtrr fails. > Isn't it /best/ to choose write-back, so as to mark the memory dirty? I /could/ > choose write-ahead, or write-through. > > I've looked at ways to try to fix this in the past, but > > generally found it more practical to use PAT than try to override/fix bios > > behavior. > Marius Nünnerich also mentioned this in a response to this thread. Would you be > willing to share any additional information, based on your experiences using PAT? PAT and MTRR both allow for the setting of cache attributes for a range of memory. For MTRR, there are a certain number of variable range registers in a given CPU which allow the setting of global cache attributes for a given memory range. There are a number of rules about what memory types may overlap though, so having that entry that covers all of memory means that setting MTRR to anything other than uncached will always fail. PAT is less restrictive in this regard and a table exists in the intel documentation showing the effective cache method for various combinations of MTRR/PAT. The difficulty with PAT is that it is an attribute of the individual page mapping and so all mappings of the same physical region of memory need to have the same PAT type set. jhb@, alc@ and I (my contribution has mostly consisted of whining and testing) have recently (over the last year at least) been adding the ability to handle allowing userspace mappings of memory regions to be mapped with consistent PAT attributes. This was also one of the key features that nvidia wanted before they would deliver an amd64 blob driver. Much of the needed infrastructure is in place now, however there is still some work to be done on bus_dma to make use of the features. I have some local hacks to bus_dma that I am using in my trees to allow me to more easily manipulate the PAT attributes, but they aren't practical to commit. We need to revisit this topic and decide what is the correct way to proceed. robert. > > I've been told that linux does apply some BIOS fixups to address this > > issue, which I might look into again, but I make no promises. > Is there anything I could do that would help you in this regard? > There are also a > > very limited number of variable mtrr registers (7 on most hardware, iirc) for > > managing caching. > > Thank you again for taking the time to respond. > > --Chris H > > > > robert. > > > >> --Chris H > >> > >> > >> > >> _______________________________________________ > >> freebsd-stable@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > >> > > -- > > Robert Noland > > FreeBSD > > > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > > > > -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Sun Dec 13 14:53:28 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33E591065676; Sun, 13 Dec 2009 14:53:28 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (dsl081-172-045.sea1.dsl.speakeasy.net [64.81.172.45]) by mx1.freebsd.org (Postfix) with ESMTP id DC94B8FC0A; Sun, 13 Dec 2009 14:53:27 +0000 (UTC) Received: from webmail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id nBDErJH1008390; Sun, 13 Dec 2009 06:53:25 -0800 (PST) (envelope-from chris#@1command.com) Received: from hitme.hitometer.net ([64.81.172.194]) (Local authenticated user inf0s) by webmail.1command.com with HTTP; Sun, 13 Dec 2009 06:53:25 -0800 (PST) Message-ID: <3a3d4fb449dab5da292f47d4de1b6b58.HRCIM@webmail.1command.com> In-Reply-To: <1260713097.2281.61.camel@balrog.2hip.net> References: <1260628594.2281.30.camel@balrog.2hip.net> <7f052646787bb8c47f847ecd3176e706.HRCIM@webmail.1command.com> <1260713097.2281.61.camel@balrog.2hip.net> Date: Sun, 13 Dec 2009 06:53:25 -0800 (PST) From: "Chris H" To: freebsd-stable@freebsd.org User-Agent: HRC Internet Messaging/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Robert Noland Subject: Re: MTRR failure revisited (nVidia) 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 14:53:28 -0000 On Sun, December 13, 2009 6:04 am, Robert Noland wrote: > On Sat, 2009-12-12 at 20:08 -0800, Chris H wrote: > >> On Sat, December 12, 2009 6:36 am, Robert Noland wrote: >> >>> On Sat, 2009-12-12 at 03:47 -0800, Chris H wrote: >>> >>> >>>> Greetings, >>>> I brought this same error to the list back in May 2009. >>>> Under: failed to set mtrr: invalid argument. >>>> Well, I'm back using the same card: >>>> GeForce4 MX 440-SE - VideoRam 65536 - BusID PCI:1:3:0. >>>> The driver is different, I'm using: nvidia-driver-96.43.13 out of ports on >>>> a custom 8-STABLE kernel. Xorg starts up, and produces a desktop. But it's >>>> "dog >>>> slow" >> UPDATE: >> Disabling HAL /greatly/ increased performance >> eg; hal_enable="YES" --> hal_enable="NO" in /etc/rc.conf More specifically, >> response times are now closer to what one would anticipate/ expect now that >> HAL has been dis-abled in rc.conf. >> >>>> , and the nvidia driver emits the following error: NVIDIA: failed to set >>>> MTRR 0xf0000000, 0M (write-combining) >>>> several times. I understand John Baldwin provided some "invaluable" help >>>> some time ago: >>>> http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016995.html >>>> and I was wondering if anyone has gained any further "insight" with these >>>> cards, and how to better "interface" them in BSD. Last I spoke on the >>>> topic, I was informed that the memory was basically "untouchable" - or >>>> perhaps in other words; can't be manipulated. Has this changed? Surely >>>> someone else has had to deal with this besides me. It seems crazy to spend >>>> a "boat load" of $$ on these high performers, and not be able to use them >>>> on a high performing OS - no? :) Sure, the one I'm working with now is >>>> "legacy". But I have 3 near new, >>>> top of their line cards, and thus far it appears that if I ever hope to >>>> use them, I'll be forced to... hack, choke.. spin up a WIN CD. :( >>>> >>>> Thank you for all your time, consideration, and insight. >>>> >>>> >> Greetings Robert, and thank you for taking the time to respond. >> >>> >>> The mtrr issue has to do with the system / bios, not the graphics card. >>> While I've not used the blob driver, the issue in Nouveau and other drm >>> drivers is that on many systems if you run "memcontrol list", you will see a >>> line something like this: >>> >>> 0x0/0x100000000 BIOS write-back set-by-firmware active >>> >> I see the following (condensed for brevity): >> 0x0/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active >> 0x10000/0x10000-0x70000/0x10000 BIOS write-back fixed-base fixed-length >> set-by-firmware active 0x80000/0x4000 BIOS-0x9c000/0x4000 write-back fixed-base >> fixed-length set-by-firmware active 0xa0000/0x4000-0xbc000/0x4000 BIOS >> uncacheable fixed-base fixed-length set-by-firmware active >> 0xc0000/0x10000xc7000/0x1000 BIOS write-protect fixed-base fixed-length >> set-by-firmware active 0xc8000/0x1000-0xff000/0x1000 BIOS uncacheable >> fixed-base fixed-length set-by-firmware active 0x0/0x40000000 BIOS write-back >> set-by-firmware active Hello Robert, and thank you for your thoughtful response. > > The above entry is the one that causes setting write-combine MTRR to > fail. > >> 0xe0000000/0x20000000 BIOS uncacheable set-by-firmware active >> >> >> While I could pull the BIOS out of it's socket after POST. I don't suppose >> I could read it's contents to file, and then allow manipulation of the >> regions currently "off limits"? > > This is more easily achieved in our MTRR code I expect, certainly than > BIOS hacking all of the effected machines. Frankly, all of my more > modern machines have this issue. > Ahhh, OK. >>> >>> This says that all of memory defaults to write-back. We aren't allowed >>> to overlap write-combined on top of write-back, so the setting of mtrr >>> fails. >> Isn't it /best/ to choose write-back, so as to mark the memory dirty? I >> /could/ >> choose write-ahead, or write-through. >>> I've looked at ways to try to fix this in the past, but >>> generally found it more practical to use PAT than try to override/fix bios >>> behavior. >> Marius Nünnerich also mentioned this in a response to this thread. Would you >> be willing to share any additional information, based on your experiences >> using PAT? > > PAT and MTRR both allow for the setting of cache attributes for a range > of memory. For MTRR, there are a certain number of variable range registers in a > given CPU which allow the setting of global cache attributes for a given memory > range. There are a number of rules about what memory types may overlap though, > so having that entry that covers all of memory means that setting MTRR to > anything other than uncached will always fail. > > PAT is less restrictive in this regard and a table exists in the intel > documentation showing the effective cache method for various combinations of > MTRR/PAT. The difficulty with PAT is that it is an > attribute of the individual page mapping and so all mappings of the same physical > region of memory need to have the same PAT type set. jhb@, alc@ and I (my > contribution has mostly consisted of whining and testing) have recently (over > the last year at least) been adding the ability to handle allowing userspace > mappings of memory regions to be mapped with consistent PAT attributes. This > was also one of the key features that nvidia wanted before they would deliver an > amd64 blob driver. Much of the needed infrastructure is in place now, however > there is still some work to be done on bus_dma to make use of the features. I > have some local hacks to bus_dma that I am using in my trees to allow me to more > easily manipulate the PAT attributes, but they aren't practical to commit. We > need to revisit this topic and decide what is the correct way to proceed. If I may be so bold... can we anticipate this in 8? Or are we looking at 9? One last thing, it would appear that you use the Nouveau driver as your preferred nVidia driver. Overall, would you say this one has more advantages than the blob drivers? Thank you again for your thoughtful, and informative response. --Chris H > > robert. > >>> I've been told that linux does apply some BIOS fixups to address this >>> issue, which I might look into again, but I make no promises. >> Is there anything I could do that would help you in this regard? >> There are also a >> >>> very limited number of variable mtrr registers (7 on most hardware, iirc) >>> for managing caching. >> >> Thank you again for taking the time to respond. >> >> >> --Chris H >> >>> >>> robert. >>> >>>> --Chris H >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> freebsd-stable@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >>>> >>>> >>> -- >>> Robert Noland >>> FreeBSD >>> >>> >>> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >>> >>> >>> >> >> > -- > Robert Noland > FreeBSD > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > From owner-freebsd-stable@FreeBSD.ORG Sun Dec 13 15:25:50 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23B301065670 for ; Sun, 13 Dec 2009 15:25:50 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id CE9308FC14 for ; Sun, 13 Dec 2009 15:25:49 +0000 (UTC) Received: from [192.168.1.4] (adsl-156-16-112.bna.bellsouth.net [70.156.16.112]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nBDFPcSX067438 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 13 Dec 2009 10:25:38 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Chris H In-Reply-To: <3a3d4fb449dab5da292f47d4de1b6b58.HRCIM@webmail.1command.com> References: <1260628594.2281.30.camel@balrog.2hip.net> <7f052646787bb8c47f847ecd3176e706.HRCIM@webmail.1command.com> <1260713097.2281.61.camel@balrog.2hip.net> <3a3d4fb449dab5da292f47d4de1b6b58.HRCIM@webmail.1command.com> Content-Type: text/plain; charset="ISO-8859-1" Organization: FreeBSD Date: Sun, 13 Dec 2009 09:25:32 -0600 Message-Id: <1260717932.2281.73.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-stable@freebsd.org Subject: Re: MTRR failure revisited (nVidia) 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 15:25:50 -0000 On Sun, 2009-12-13 at 06:53 -0800, Chris H wrote: > On Sun, December 13, 2009 6:04 am, Robert Noland wrote: > > On Sat, 2009-12-12 at 20:08 -0800, Chris H wrote: > > > >> On Sat, December 12, 2009 6:36 am, Robert Noland wrote: > >> > >>> On Sat, 2009-12-12 at 03:47 -0800, Chris H wrote: > >>> > >>> > >>>> Greetings, > >>>> I brought this same error to the list back in May 2009. > >>>> Under: failed to set mtrr: invalid argument. > >>>> Well, I'm back using the same card: > >>>> GeForce4 MX 440-SE - VideoRam 65536 - BusID PCI:1:3:0. > >>>> The driver is different, I'm using: nvidia-driver-96.43.13 out of ports on > >>>> a custom 8-STABLE kernel. Xorg starts up, and produces a desktop. But it's > >>>> "dog > >>>> slow" > >> UPDATE: > >> Disabling HAL /greatly/ increased performance > >> eg; hal_enable="YES" --> hal_enable="NO" in /etc/rc.conf More specifically, > >> response times are now closer to what one would anticipate/ expect now that > >> HAL has been dis-abled in rc.conf. > >> > >>>> , and the nvidia driver emits the following error: NVIDIA: failed to set > >>>> MTRR 0xf0000000, 0M (write-combining) > >>>> several times. I understand John Baldwin provided some "invaluable" help > >>>> some time ago: > >>>> http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016995.html > >>>> and I was wondering if anyone has gained any further "insight" with these > >>>> cards, and how to better "interface" them in BSD. Last I spoke on the > >>>> topic, I was informed that the memory was basically "untouchable" - or > >>>> perhaps in other words; can't be manipulated. Has this changed? Surely > >>>> someone else has had to deal with this besides me. It seems crazy to spend > >>>> a "boat load" of $$ on these high performers, and not be able to use them > >>>> on a high performing OS - no? :) Sure, the one I'm working with now is > >>>> "legacy". But I have 3 near new, > >>>> top of their line cards, and thus far it appears that if I ever hope to > >>>> use them, I'll be forced to... hack, choke.. spin up a WIN CD. :( > >>>> > >>>> Thank you for all your time, consideration, and insight. > >>>> > >>>> > >> Greetings Robert, and thank you for taking the time to respond. > >> > >>> > >>> The mtrr issue has to do with the system / bios, not the graphics card. > >>> While I've not used the blob driver, the issue in Nouveau and other drm > >>> drivers is that on many systems if you run "memcontrol list", you will see a > >>> line something like this: > >>> > >>> 0x0/0x100000000 BIOS write-back set-by-firmware active > >>> > >> I see the following (condensed for brevity): > >> 0x0/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active > >> 0x10000/0x10000-0x70000/0x10000 BIOS write-back fixed-base fixed-length > >> set-by-firmware active 0x80000/0x4000 BIOS-0x9c000/0x4000 write-back fixed-base > >> fixed-length set-by-firmware active 0xa0000/0x4000-0xbc000/0x4000 BIOS > >> uncacheable fixed-base fixed-length set-by-firmware active > >> 0xc0000/0x10000xc7000/0x1000 BIOS write-protect fixed-base fixed-length > >> set-by-firmware active 0xc8000/0x1000-0xff000/0x1000 BIOS uncacheable > >> fixed-base fixed-length set-by-firmware active 0x0/0x40000000 BIOS write-back > >> set-by-firmware active > Hello Robert, and thank you for your thoughtful response. > > > > The above entry is the one that causes setting write-combine MTRR to > > fail. > > > >> 0xe0000000/0x20000000 BIOS uncacheable set-by-firmware active > >> > >> > >> While I could pull the BIOS out of it's socket after POST. I don't suppose > >> I could read it's contents to file, and then allow manipulation of the > >> regions currently "off limits"? > > > > This is more easily achieved in our MTRR code I expect, certainly than > > BIOS hacking all of the effected machines. Frankly, all of my more > > modern machines have this issue. > > > Ahhh, OK. > >>> > >>> This says that all of memory defaults to write-back. We aren't allowed > >>> to overlap write-combined on top of write-back, so the setting of mtrr > >>> fails. > >> Isn't it /best/ to choose write-back, so as to mark the memory dirty? I > >> /could/ > >> choose write-ahead, or write-through. > >>> I've looked at ways to try to fix this in the past, but > >>> generally found it more practical to use PAT than try to override/fix bios > >>> behavior. > >> Marius Nünnerich also mentioned this in a response to this thread. Would you > >> be willing to share any additional information, based on your experiences > >> using PAT? > > > > PAT and MTRR both allow for the setting of cache attributes for a range > > of memory. For MTRR, there are a certain number of variable range registers in a > > given CPU which allow the setting of global cache attributes for a given memory > > range. There are a number of rules about what memory types may overlap though, > > so having that entry that covers all of memory means that setting MTRR to > > anything other than uncached will always fail. > > > > PAT is less restrictive in this regard and a table exists in the intel > > documentation showing the effective cache method for various combinations of > > MTRR/PAT. The difficulty with PAT is that it is an > > attribute of the individual page mapping and so all mappings of the same physical > > region of memory need to have the same PAT type set. jhb@, alc@ and I (my > > contribution has mostly consisted of whining and testing) have recently (over > > the last year at least) been adding the ability to handle allowing userspace > > mappings of memory regions to be mapped with consistent PAT attributes. This > > was also one of the key features that nvidia wanted before they would deliver an > > amd64 blob driver. Much of the needed infrastructure is in place now, however > > there is still some work to be done on bus_dma to make use of the features. I > > have some local hacks to bus_dma that I am using in my trees to allow me to more > > easily manipulate the PAT attributes, but they aren't practical to commit. We > > need to revisit this topic and decide what is the correct way to proceed. > If I may be so bold... can we anticipate this in 8? Or are we looking at 9? > One last thing, it would appear that you use the Nouveau driver as your preferred > nVidia driver. Overall, would you say this one has more advantages than the blob > drivers? Well, it isn't without issues... My current nouveau patch will get you EXA and Xv acceleration on i386 and amd64. Until about a week or so ago, it was the only solution for amd64. The nouveau project has removed the fake buffer object support that we use in the current patch in favor of TTM, which is preventing me from updating the code right now. TTM is one of two drm memory managers, the other being GEM. I'm just not inclined to use a closed source driver, when every other vendor is actively providing code and docs. ATI/AMD is currently the most friendly when it comes to supporting open drivers on anything besides linux. Intel does provide both docs and code, however they continue to frustrate me by ripping out code that supported the traditional drm in favor of all of their new linux code. VIA is also providing docs and some code, but they don't quite have the hang of working with the drm/Xorg crowd yet, so much of the code that they have published hasn't gone anywhere. robert. > Thank you again for your thoughtful, and informative response. > > --Chris H > > > > > robert. > > > >>> I've been told that linux does apply some BIOS fixups to address this > >>> issue, which I might look into again, but I make no promises. > >> Is there anything I could do that would help you in this regard? > >> There are also a > >> > >>> very limited number of variable mtrr registers (7 on most hardware, iirc) > >>> for managing caching. > >> > >> Thank you again for taking the time to respond. > >> > >> > >> --Chris H > >> > >>> > >>> robert. > >>> > >>>> --Chris H > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> freebsd-stable@freebsd.org mailing list > >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >>>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > >>>> > >>>> > >>> -- > >>> Robert Noland > >>> FreeBSD > >>> > >>> > >>> > >>> _______________________________________________ > >>> freebsd-stable@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > >>> > >>> > >>> > >> > >> > > -- > > Robert Noland > > FreeBSD > > > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > > > > -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Sun Dec 13 16:50:04 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A14A01065670 for ; Sun, 13 Dec 2009 16:50:04 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 20A4B8FC0A for ; Sun, 13 Dec 2009 16:50:03 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id EDD831E0075C; Sun, 13 Dec 2009 17:50:02 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id nBDGkj1v010831; Sun, 13 Dec 2009 17:46:45 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id nBDGkiPX010830; Sun, 13 Dec 2009 17:46:44 +0100 (CET) (envelope-from nox) Date: Sun, 13 Dec 2009 17:46:44 +0100 (CET) From: Juergen Lock Message-Id: <200912131646.nBDGkiPX010830@triton8.kn-bremen.de> To: karl@denninger.net X-Newsgroups: local.list.freebsd.stable In-Reply-To: <4B150D60.5050200@denninger.net> References: <4B100262.6000900@denninger.net> <4B102059.6040003@denninger.net> <20091127190319.GA12437@icarus.home.lan> <4B102C41.6040205@denninger.net> <4B11EDDD.8060108@denninger.net> <20091129205814.GB77530@icarus.home.lan> Organization: home Cc: marcel@freebsd.org, freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: PUC Serial I/O problem - copy of gnats-filed bug report (as discussed previously) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 16:50:04 -0000 Hi! In article <4B150D60.5050200@denninger.net> you write: >-=-=-=-=-=- > >Jeremy Chadwick wrote: >> On Sat, Nov 28, 2009 at 09:43:25PM -0600, Karl Denninger wrote: >> >>> Karl Denninger wrote: >>> >>>> Jeremy Chadwick wrote: >>>> >>>> >>>>> On Fri, Nov 27, 2009 at 12:54:17PM -0600, Karl Denninger wrote: >>>>> >>>>> >>>>> >>>>>> For what its worth, USB-based serial adapters also fail in the same way, >>>>>> but faster (they have NEVER been reliable in this regard, and this >>>>>> hasn't improved) >>>>>> >>>>>> >>>>>> >>>>> There must be a regression of some kind, given that some FreeBSD >>>>> developers have stated in the past that FTDI-based USB serial adapters >>>>> work great: >>>>> >>>>> http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041615.html >>>>> >>>>> Original thread: >>>>> >>>>> http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041610.html >>>>> >>>>> >>>>> >>>> I don't know where "works great" has come from. Certainly not my >>>> experience in "heavy" use. >>>> >>>> For non-modem-control heavy use, it works ok. I use an 8-port fanout on >>>> 7.x to drive process control and it's stable. >>>> >>>> However, for heavy modem use (e.g. Hylafax) it has NEVER been stable - >>>> although in 8.x it won't even manage to send ONE 10-page fax most of the >>>> time, where under 7.x it would randomly fail in that use. Then again >>>> the puc() driver based serial I/O was completely stable under 7.x and >>>> now, with the "new architecture" it will get one or two jobs through it >>>> before it blows up. >>>> >>>> -- Karl >>>> >>>> >>> FYI I downgraded back to 7.2-STABLE (it was a bit hairy but I got it to >>> work after a small amount of screwing around) via sources >>> and again the machine and those serial ports are 100% stable with the >>> old driver infrastructure. >>> >>> The uart() infrastructure in 8.x has to be considered broken and >>> unusable for modems at this point folks. I recognize that nobody >>> flagged it until just before the release (I hadn't tried it until RC2, >>> and thus didn't know) but this is a literal dagger in the heart of >>> anyone who needs to put an actual modem on an 8.x box using the common >>> cards out there, and I assume it will bite just as hard for things like >>> a dial-in console as it will for a fax server. >>> >> >> Karl, >> >> I agree with you in this regard. However, I'm not sure what to >> recommend to you with regards to getting this issue the proper attention >> it needs. I fully agree with the Severity (serious) and Priority >> (high) of the PR: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/140947 >> >> Ed Schouten appears to be giving this attention, but I'd recommend that >> Email communication include marcel@FreeBSD.org, "just in case" it turns >> out that puc(4) needs some changes. I'm certain Ed will do his best to >> assist tracking this one down. :-) >> >Added the suggested forward address to the list..... just in case :) > >Yeah, this is pretty serious. It looks to me, at first blush, like an >interrupt is being dropped on occasion and there is no watchdog timer in >the driver code to catch it and unwedge the state machine. That's not >supposed to be possible (dropped interrupts) on PCI (and PCI/Express) >cards unless something is dramatically wrong in the code somewhere. It just occured to me that this might be related to a bug I fixed in qemu's serial hw emulation, http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=2d6ee8e7e17227d5eb8c6e9a054dd88d5b37c5ae which also caused tx irqs to get lost and which the old sio(4) driver had no problem with, only output on uart(4) then hung as a result. On that occasion I also learned that there is a priority list for irqs, for example rx irqs take precedence over tx ones, so maybe that explains why some irqs can get lost during `heavy use'? (And which the old driver recovered from I guess by checking status registers at least in the tx path too in addition to just accounting for irqs.) HTH, Juergen From owner-freebsd-stable@FreeBSD.ORG Sun Dec 13 19:19:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA6101065672 for ; Sun, 13 Dec 2009 19:19:08 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from chen.org.nz (ip-58-28-152-174.static-xdsl.xnet.co.nz [58.28.152.174]) by mx1.freebsd.org (Postfix) with ESMTP id A12058FC08 for ; Sun, 13 Dec 2009 19:19:08 +0000 (UTC) Received: by chen.org.nz (Postfix, from userid 1000) id 539DE2840B; Mon, 14 Dec 2009 08:19:05 +1300 (NZDT) Date: Mon, 14 Dec 2009 08:19:05 +1300 From: Jonathan Chen To: freebsd-stable@freebsd.org Message-ID: <20091213191905.GA76785@osiris.chen.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: Dell D830, nVidia and FreeBSD-8/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 19:19:09 -0000 Hi, This is a general rehash of a problem that I've been having with my Dell Latitude D830 with an nVidia Quadro NVS 140M internal graphics card. I've been using the XOrg's "vesa" driver ever since something in the code rendered the "nvidia" driver inoperable in 7-STABLE sometime mid last year. With nVidia's new 195.22 (BETA) drivers, I had hoped that I could bypass the problem. Unfortunately, I seem to be experiencing the same problem as described in the following thread: http://www.nvnews.net/vbulletin/showthread.php?t=142391 which appears to be implying that something in the kernel is interfering with memory allocation. Would it be possible for someone with deeper kernel-fu be able to take a look at this issue? Cheers. -- Jonathan Chen ---------------------------------------------------------------------- "With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead." -- RFC 1925 From owner-freebsd-stable@FreeBSD.ORG Sun Dec 13 20:43:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99F79106566C for ; Sun, 13 Dec 2009 20:43:56 +0000 (UTC) (envelope-from freebsd-stable@adam.gs) Received: from mail.adam.gs (mail.adam.gs [76.9.2.116]) by mx1.freebsd.org (Postfix) with ESMTP id 7885E8FC13 for ; Sun, 13 Dec 2009 20:43:56 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.adam.gs (Postfix) with ESMTP id CE7333E2CE3 for ; Sun, 13 Dec 2009 15:26:05 -0500 (EST) From: Adam Jacob Muller Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 13 Dec 2009 15:26:04 -0500 Message-Id: <2A3A50FE-13F4-4AA7-976E-37354E5736B5@adam.gs> To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1077) X-Authentication: /Hphuv96B4gFIFCSql24xc1Eeu8eUiJ1DqW71Oj1YKqJiEsZhL0P5lDyYGDSnNW4KKEeQIsj9hl/TEylvcEwgRmQQveNMmhG9ss1uHyOEoXHC7vlPq3FrjJVGtP5xZ+Z47tglAfQjdmF4C2ndhkKbsEeGhuQusiPiqvJ/5QOGGVbOpz4Go7O1sht8A== Subject: freebsd / gpt boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 20:43:56 -0000 Hi, I'm trying to setup a system with a very large RAID array (total ~10TB), = I would ideally like to have the system boot directly off that 10TB = array, so i'm trying to get the system setup with GPT but running into = an issue. The initial pre-loader (boot0 I think? -- i'm not sure what this is = called) is unable to find loader at /boot/loader nor can it load = /boot/kernel/kernel Copying /boot/loader to /loader allows me to enter /loader at the = "boot:" prompt and the loader will load, however, its unable to load the = kernel. If I do an "ls" at the loader prompt I can see boot listed as a = directory (with a "d" before it) Trying to do "ls boot" inexplicably it says "boot: not a directory" re-applying my /boot/loader.conf settings (for some reason = vfs.root.mountfrom=3Dufs:/dev/label/root is required, or else I get a = mountroot>) and then: load /kernel boot does work, and lets the system boot normally and everything is as = expected (/boot is a directory etc). Anyone have any ideas about either of these things (the = vfs.root.mountfrom is minor i guess but i'm curious if they are = related?) Thanks in advance, -Adam From owner-freebsd-stable@FreeBSD.ORG Sun Dec 13 22:42:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7B771065692 for ; Sun, 13 Dec 2009 22:42:07 +0000 (UTC) (envelope-from lazlar@lazlarlyricon.com) Received: from proxy1.bredband.net (proxy1.bredband.net [195.54.101.71]) by mx1.freebsd.org (Postfix) with ESMTP id A377C8FC18 for ; Sun, 13 Dec 2009 22:42:07 +0000 (UTC) Received: from ipb2.telenor.se (195.54.127.165) by proxy1.bredband.net (7.3.140.3) id 4AD3E1C001AC733F for freebsd-stable@freebsd.org; Sun, 13 Dec 2009 23:22:00 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoBvAKr3JEtV44PPPGdsb2JhbACBSpccgkcBAQEBN7YphCsEgWKEAQ X-IronPort-AV: E=Sophos;i="4.47,391,1257116400"; d="scan'208";a="15304078" Received: from c-cf83e355.09-42-6e6b7010.cust.bredbandsbolaget.se (HELO lazlar.kicks-ass.net) ([85.227.131.207]) by ipb2.telenor.se with ESMTP; 13 Dec 2009 23:22:00 +0100 Message-ID: <4B256907.4060805@lazlarlyricon.com> Date: Sun, 13 Dec 2009 23:21:59 +0100 From: Rolf G Nielsen User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Adam Jacob Muller References: <2A3A50FE-13F4-4AA7-976E-37354E5736B5@adam.gs> In-Reply-To: <2A3A50FE-13F4-4AA7-976E-37354E5736B5@adam.gs> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: freebsd / gpt boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 22:42:08 -0000 Adam Jacob Muller wrote: > Hi, > I'm trying to setup a system with a very large RAID array (total ~10TB), I would ideally like to have the system boot directly off that 10TB array, so i'm trying to get the system setup with GPT but running into an issue. > > > The initial pre-loader (boot0 I think? -- i'm not sure what this is called) is unable to find loader at /boot/loader nor can it load /boot/kernel/kernel > Is the partitioning done correctly (have you created a small boot partition, 15 sectors is enough for booting from ufs, but the tutorials I've found deal mainly with booting from zfs and they recommend 128 sectors to make future bootcode changes easier)? gpart add -b 34 -s 128 -t freebsd-boot -i 1 da0 Have you embedded the correct boot code? gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 da0 (for booting from ufs). or gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 (for booting from zfs). You may also need to set it active by gpart set -a active -i 1 da0 And of course, substitute your arrays device node for da0 in my examples. > Copying /boot/loader to /loader allows me to enter /loader at the "boot:" prompt and the loader will load, however, its unable to load the kernel. > > If I do an "ls" at the loader prompt I can see boot listed as a directory (with a "d" before it) > Trying to do "ls boot" inexplicably it says "boot: not a directory" > > re-applying my /boot/loader.conf settings (for some reason vfs.root.mountfrom=ufs:/dev/label/root is required, or else I get a mountroot>) and then: > load /kernel > boot > > does work, and lets the system boot normally and everything is as expected (/boot is a directory etc). > > Anyone have any ideas about either of these things (the vfs.root.mountfrom is minor i guess but i'm curious if they are related?) > > Thanks in advance, > > -Adam > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > From owner-freebsd-stable@FreeBSD.ORG Sun Dec 13 23:00:41 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C8641065672 for ; Sun, 13 Dec 2009 23:00:41 +0000 (UTC) (envelope-from freebsd-stable@adam.gs) Received: from mail.adam.gs (mail.adam.gs [76.9.2.116]) by mx1.freebsd.org (Postfix) with ESMTP id 267C38FC08 for ; Sun, 13 Dec 2009 23:00:41 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.adam.gs (Postfix) with ESMTP id A78D63E2D27 for ; Sun, 13 Dec 2009 18:00:39 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Adam Jacob Muller In-Reply-To: <4B256907.4060805@lazlarlyricon.com> Date: Sun, 13 Dec 2009 18:00:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <586264AE-3DB3-4999-8F8C-A51329DA2BEA@adam.gs> References: <2A3A50FE-13F4-4AA7-976E-37354E5736B5@adam.gs> <4B256907.4060805@lazlarlyricon.com> To: Rolf G Nielsen X-Authentication: mWYn0sA4iJNVIGTLRuR9dPHblsRLmIv2OpzjB04BNZEd0bUQWjnAmVF/YI1BxqYOGsWZ7riwulYdLto636ZaBfiSlEdgJTIsrRJDFDL12E5S3qP0ENRjF6r23kQhQwZwdWxkKNwSrFHiaoJuzXMJ9qxKNoDLtdpiMY6wBeJB7wlf4kjo8+ph5//wtQ== Cc: freebsd-stable@freebsd.org, Adam Jacob Muller Subject: Re: freebsd / gpt boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 23:00:41 -0000 Hi Rolf, I am using the "gpt boot" command right after calling "gpart create" = which should combine the add/bootcode. Things do look right from a "gpart show" # gpart show =3D> 34 19529727933 mfid0 GPT (9.1T) 34 128 1 freebsd-boot (64K) 162 1048576 2 freebsd-swap (512M) 1048738 19528679229 3 freebsd-ufs (9.1T) This does not work though, > gpart set -a active -i 1 da0 # gpart set -a active -i 1 mfid0 gpart: attrib 'active': Device not configured -Adam On Dec 13, 2009, at 5:21 PM, Rolf G Nielsen wrote: > Adam Jacob Muller wrote: >> Hi, >> I'm trying to setup a system with a very large RAID array (total = ~10TB), I would ideally like to have the system boot directly off that = 10TB array, so i'm trying to get the system setup with GPT but running = into an issue. >> The initial pre-loader (boot0 I think? -- i'm not sure what this is = called) is unable to find loader at /boot/loader nor can it load = /boot/kernel/kernel >=20 > Is the partitioning done correctly (have you created a small boot = partition, 15 sectors is enough for booting from ufs, but the tutorials = I've found deal mainly with booting from zfs and they recommend 128 = sectors to make future bootcode changes easier)? >=20 > gpart add -b 34 -s 128 -t freebsd-boot -i 1 da0 >=20 > Have you embedded the correct boot code? >=20 > gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 da0 > (for booting from ufs). >=20 > or >=20 > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 > (for booting from zfs). >=20 > You may also need to set it active by >=20 > gpart set -a active -i 1 da0 >=20 > And of course, substitute your arrays device node for da0 in my = examples. >=20 >> Copying /boot/loader to /loader allows me to enter /loader at the = "boot:" prompt and the loader will load, however, its unable to load the = kernel. >> If I do an "ls" at the loader prompt I can see boot listed as a = directory (with a "d" before it) >> Trying to do "ls boot" inexplicably it says "boot: not a directory" >> re-applying my /boot/loader.conf settings (for some reason = vfs.root.mountfrom=3Dufs:/dev/label/root is required, or else I get a = mountroot>) and then: >> load /kernel >> boot >> does work, and lets the system boot normally and everything is as = expected (/boot is a directory etc). >> Anyone have any ideas about either of these things (the = vfs.root.mountfrom is minor i guess but i'm curious if they are = related?) >> Thanks in advance, >> -Adam >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" >=20 From owner-freebsd-stable@FreeBSD.ORG Sun Dec 13 23:04:31 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 700AD1065672 for ; Sun, 13 Dec 2009 23:04:31 +0000 (UTC) (envelope-from prvs=1598a80773=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 0521D8FC20 for ; Sun, 13 Dec 2009 23:04:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1260744828; x=1261349628; q=dns/txt; h=Received: Message-ID:From:To:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=i9IA2uPnoZHrAX8+JPI11 SJMXEPDRDrNTF24NhnLZu4=; b=E0MDEZgAPITDNGHx3EzSOhwfBdDvHPoaH4Cra RIVB3iPavuBUdUuDXUZaqydrXwlxT1LCICXuhQX+QKttDUaaz+a6NcTZ/cBDKXEZ /LmpIqmDnhxjLFBYNZei5G2LrrszKWZAUfI/nVu7MjLpiwYj0X2QGr8kKr0Lh6/Q VJ/VgQ= X-MDAV-Processed: mail1.multiplay.co.uk, Sun, 13 Dec 2009 22:53:48 +0000 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50008856283.msg for ; Sun, 13 Dec 2009 22:53:48 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 13 Dec 2009 22:53:48 +0000 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 213.123.247.160 X-Return-Path: prvs=1598a80773=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <9D30BF6BFAFC4DA3B9564C822CA53E1A@multiplay.co.uk> From: "Steven Hartland" To: "Adam Jacob Muller" , References: <2A3A50FE-13F4-4AA7-976E-37354E5736B5@adam.gs> Date: Sun, 13 Dec 2009 22:53:44 -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.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Subject: Re: freebsd / gpt boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 23:04:31 -0000 There's already a thread about this last week, which contains the info you need to set this up. The only thing I'd warn you about is to ensure you use the DVD not the CD as the CD doesn't have all the things you'll need on it. Regards Steve ----- Original Message ----- From: "Adam Jacob Muller" To: Sent: Sunday, December 13, 2009 8:26 PM Subject: freebsd / gpt boot Hi, I'm trying to setup a system with a very large RAID array (total ~10TB), I would ideally like to have the system boot directly off that 10TB array, so i'm trying to get the system setup with GPT but running into an issue. The initial pre-loader (boot0 I think? -- i'm not sure what this is called) is unable to find loader at /boot/loader nor can it load /boot/kernel/kernel Copying /boot/loader to /loader allows me to enter /loader at the "boot:" prompt and the loader will load, however, its unable to load the kernel. If I do an "ls" at the loader prompt I can see boot listed as a directory (with a "d" before it) Trying to do "ls boot" inexplicably it says "boot: not a directory" re-applying my /boot/loader.conf settings (for some reason vfs.root.mountfrom=ufs:/dev/label/root is required, or else I get a mountroot>) and then: load /kernel boot does work, and lets the system boot normally and everything is as expected (/boot is a directory etc). Anyone have any ideas about either of these things (the vfs.root.mountfrom is minor i guess but i'm curious if they are related?) Thanks in advance, -Adam _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" ================================================ 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-stable@FreeBSD.ORG Sun Dec 13 23:07:00 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E73D9106566B for ; Sun, 13 Dec 2009 23:07:00 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by mx1.freebsd.org (Postfix) with ESMTP id EDB868FC13 for ; Sun, 13 Dec 2009 23:06:58 +0000 (UTC) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 3A61F9400F2; Mon, 14 Dec 2009 00:06:53 +0100 (CET) Received: from endor.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp1-g21.free.fr (Postfix) with ESMTP id 471F4940091; Mon, 14 Dec 2009 00:06:51 +0100 (CET) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 0B8A433E94; Sun, 13 Dec 2009 23:06:51 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id DBC4BA1262; Sun, 13 Dec 2009 23:06:50 +0000 (UTC) Date: Mon, 14 Dec 2009 00:06:50 +0100 From: Jeremie Le Hen To: freebsd-stable@FreeBSD.org Message-ID: <20091213230650.GA45540@felucia.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Rick Macklem Subject: Cannot list a particular directory through NFS with UDP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 23:07:01 -0000 Hi, __ Please Cc: me when replying as I'm not subscribed. Thanks. __ My NFS server is running FreeBSD 8.0 from December 6th. The client is a NetBSD 5.0. The directory exported is /data/repos on the server (192.168.1.222) and is mounted on /mnt/repos on the client (192.168.1.1). The problem exists in /data/repos/netbsd-cvsroot/pkgsrc when using NFS over UDP: ls(1) stalls. OTOH, for instance, listing another directory or using NFS over TCP work flawlessly. "ktruss ls" shows the following: % 26964 1 ls open(".", 0, 0) = 3 % 26964 1 ls fcntl(0x3, 0x2, 0x1) = 0 % 26964 1 ls fchdir(0x3) = 0 % 26964 1 ls open(".", 0, 0) = 5 % 26964 1 ls open(".", 0x4, 0) = 6 % 26964 1 ls fcntl(0x6, 0x2, 0x1) = 0 % 26964 1 ls __fstat30(0x6, 0xbfbfdef0) = 0 % 26964 1 ls fstatvfs1(0x6, 0xbfbfdf54, 0x2) = 0 % 26964 1 ls lseek(0x6, 0, 0, 0, 0x1) = 0 <---------- stalls here Here is a trace from the stalling ls(1). Please ask me if you need more informations: 23:58:37.735792 IP (tos 0x0, ttl 64, id 48150, offset 0, flags [none], proto UDP (17), length 168) 192.168.1.1.3819288088 > 192.168.1.222.2049: 140 lookup [|nfs] 23:58:37.736635 IP (tos 0x0, ttl 64, id 62453, offset 0, flags [none], proto UDP (17), length 264) 192.168.1.222.2049 > 192.168.1.1.3819288088: reply ok 236 lookup [|nfs] 23:58:37.736727 IP (tos 0x0, ttl 64, id 48152, offset 0, flags [none], proto UDP (17), length 160) 192.168.1.1.3819288089 > 192.168.1.222.2049: 132 lookup [|nfs] 23:58:37.737232 IP (tos 0x0, ttl 64, id 18881, offset 0, flags [none], proto UDP (17), length 264) 192.168.1.222.2049 > 192.168.1.1.3819288089: reply ok 236 lookup [|nfs] 23:58:37.737411 IP (tos 0x0, ttl 64, id 48153, offset 0, flags [none], proto UDP (17), length 152) 192.168.1.1.3819288090 > 192.168.1.222.2049: 124 access [|nfs] 23:58:37.737783 IP (tos 0x0, ttl 64, id 57308, offset 0, flags [none], proto UDP (17), length 148) 192.168.1.222.2049 > 192.168.1.1.3819288090: reply ok 120 access attr: DIR 755 ids 0/0 [|nfs] 23:58:37.737927 IP (tos 0x0, ttl 64, id 48154, offset 0, flags [none], proto UDP (17), length 152) 192.168.1.1.3819288091 > 192.168.1.222.2049: 124 access [|nfs] 23:58:37.738412 IP (tos 0x0, ttl 64, id 21511, offset 0, flags [none], proto UDP (17), length 148) 192.168.1.222.2049 > 192.168.1.1.3819288091: reply ok 120 access attr: DIR 755 ids 0/0 [|nfs] 23:58:37.738477 IP (tos 0x0, ttl 64, id 48155, offset 0, flags [none], proto UDP (17), length 152) 192.168.1.1.3819288092 > 192.168.1.222.2049: 124 access [|nfs] 23:58:37.738914 IP (tos 0x0, ttl 64, id 33831, offset 0, flags [none], proto UDP (17), length 148) 192.168.1.222.2049 > 192.168.1.1.3819288092: reply ok 120 access attr: DIR 755 ids 0/0 [|nfs] 23:58:37.738990 IP (tos 0x0, ttl 64, id 48156, offset 0, flags [none], proto UDP (17), length 148) 192.168.1.1.3819288093 > 192.168.1.222.2049: 120 getattr [|nfs] 23:58:37.739377 IP (tos 0x0, ttl 64, id 26761, offset 0, flags [none], proto UDP (17), length 140) 192.168.1.222.2049 > 192.168.1.1.3819288093: reply ok 112 getattr DIR 755 ids 0/0 [|nfs] 23:58:37.740301 IP (tos 0x0, ttl 64, id 48158, offset 0, flags [none], proto UDP (17), length 168) 192.168.1.1.3819288094 > 192.168.1.222.2049: 140 readdir [|nfs] 23:58:37.764039 IP (tos 0x0, ttl 64, id 46859, offset 0, flags [+], proto UDP (17), length 1500) 192.168.1.222.2049 > 192.168.1.1.3819288094: reply ok 1472 readdir POST: DIR 755 ids 0/0 [|nfs] 23:58:37.764088 IP (tos 0x0, ttl 64, id 46859, offset 1480, flags [none], proto UDP (17), length 632) 192.168.1.222 > 192.168.1.1: udp 23:58:43.353108 IP (tos 0x0, ttl 64, id 48242, offset 0, flags [none], proto UDP (17), length 168) 192.168.1.1.3819288094 > 192.168.1.222.2049: 140 readdir [|nfs] 23:58:43.353640 IP (tos 0x0, ttl 64, id 35118, offset 0, flags [+], proto UDP (17), length 1500) 192.168.1.222.2049 > 192.168.1.1.3819288094: reply ok 1472 readdir POST: DIR 755 ids 0/0 [|nfs] 23:58:43.353687 IP (tos 0x0, ttl 64, id 35118, offset 1480, flags [none], proto UDP (17), length 632) 192.168.1.222 > 192.168.1.1: udp 23:58:54.587373 IP (tos 0x0, ttl 64, id 48349, offset 0, flags [none], proto UDP (17), length 168) 192.168.1.1.3819288094 > 192.168.1.222.2049: 140 readdir [|nfs] 23:58:54.587822 IP (tos 0x0, ttl 64, id 20689, offset 0, flags [+], proto UDP (17), length 1500) 192.168.1.222.2049 > 192.168.1.1.3819288094: reply ok 1472 readdir POST: DIR 755 ids 0/0 [|nfs] 23:58:54.587875 IP (tos 0x0, ttl 64, id 20689, offset 1480, flags [none], proto UDP (17), length 632) 192.168.1.222 > 192.168.1.1: udp 23:59:17.045978 IP (tos 0x0, ttl 64, id 48635, offset 0, flags [none], proto UDP (17), length 168) 192.168.1.1.3819288094 > 192.168.1.222.2049: 140 readdir [|nfs] 23:59:17.046483 IP (tos 0x0, ttl 64, id 53175, offset 0, flags [+], proto UDP (17), length 1500) 192.168.1.222.2049 > 192.168.1.1.3819288094: reply ok 1472 readdir POST: DIR 755 ids 0/0 [|nfs] 23:59:17.046538 IP (tos 0x0, ttl 64, id 53175, offset 1480, flags [none], proto UDP (17), length 632) 192.168.1.222 > 192.168.1.1: udp 00:00:01.953196 IP (tos 0x0, ttl 64, id 48966, offset 0, flags [none], proto UDP (17), length 168) 192.168.1.1.3819288094 > 192.168.1.222.2049: 140 readdir [|nfs] 00:00:01.953665 IP (tos 0x0, ttl 64, id 27028, offset 0, flags [+], proto UDP (17), length 1500) 192.168.1.222.2049 > 192.168.1.1.3819288094: reply ok 1472 readdir POST: DIR 755 ids 0/0 [|nfs] 00:00:01.953711 IP (tos 0x0, ttl 64, id 27028, offset 1480, flags [none], proto UDP (17), length 632) 192.168.1.222 > 192.168.1.1: udp Regards, -- Jeremie Le Hen From owner-freebsd-stable@FreeBSD.ORG Sun Dec 13 23:10:21 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1B74106566C for ; Sun, 13 Dec 2009 23:10:21 +0000 (UTC) (envelope-from pim.bliek@gmail.com) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by mx1.freebsd.org (Postfix) with ESMTP id 5A36D8FC19 for ; Sun, 13 Dec 2009 23:10:20 +0000 (UTC) Received: by fxm28 with SMTP id 28so901750fxm.13 for ; Sun, 13 Dec 2009 15:10:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=NuLJRs0854kVAwarTZWJtToTbxuEex3gdKiEQGhm14k=; b=Ytvb3+A3pOpwqKrwIMyCY/B+1uF1c4ZxMmze7udTrMd6MYYvOXGhiNUPI5WMy0038L tHU5EUmf7xwpZg/yBvWWbqF4dUqXVft/HZoYZJqHEG1pDT73yerVCJdVHrzqHcWccGuo Qz1mPfig02s3kZBI6OMymFSwvH7FatCLnnmSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=XYUHIqSQbXkGyFE2oAHFn3Y7v1iNE6FvQP1pUXyE7H33/UY3AI99Upev1FOBU7g2WB B9ZV953ah37UjZ287SJboxanT/Mra2w8bsCo6pF9rgX4W3ja3vjzlU55f9AfgZrXdp6X TxliMNUnGUnK7sVb3LoZFC4jXV5PrR400VxU4= MIME-Version: 1.0 Received: by 10.223.75.136 with SMTP id y8mr4565612faj.69.1260744444595; Sun, 13 Dec 2009 14:47:24 -0800 (PST) Date: Sun, 13 Dec 2009 23:47:24 +0100 Message-ID: From: Pim Bliek To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: USB GPS mouse in Wine X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 23:10:21 -0000 Hi, I am pretty new to FreeBSD, but experienced in Linux. Currently, I am running a fresh FreeBSD 8.0 on my netbook. I want to use it as a stable platform for my sailing computing needs. But.. I have to use Windows navigation software in conjunction with a GPS mouse via USB, and another USB serial device (a NMEA multiplexer). So far no luck. I have a USB mouse with a profilic chip. Works fine with gpsd, gpsmon etc. It fixes, it displays my location etc. Next step: Wine. I created a link in .wine/dosdevices from /dev/cuaU0 to com5 (just chose one comX). It does not work. I also added the comports to the system.reg, and now I have these comports in my windows app. However, I cannot connect to this com5. Anyone any suggestions on this issue? I did a lot of Google... but did not find anything usefull beyond this point. Seems this works on Linux with Wine, but no clues for getting this working in FreeBSD. Any help greatly appreciated! Lost here... Pim From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 00:23:49 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8F891065670 for ; Mon, 14 Dec 2009 00:23:48 +0000 (UTC) (envelope-from freebsd-stable@adam.gs) Received: from mail.adam.gs (mail.adam.gs [76.9.2.116]) by mx1.freebsd.org (Postfix) with ESMTP id A9D098FC15 for ; Mon, 14 Dec 2009 00:23:48 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.adam.gs (Postfix) with ESMTP id EF2723E2D5E for ; Sun, 13 Dec 2009 19:23:45 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Adam Jacob Muller X-Priority: 3 In-Reply-To: <9D30BF6BFAFC4DA3B9564C822CA53E1A@multiplay.co.uk> Date: Sun, 13 Dec 2009 19:23:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <467D65E4-A4F5-4DD5-A447-EF2D6020E405@adam.gs> References: <2A3A50FE-13F4-4AA7-976E-37354E5736B5@adam.gs> <9D30BF6BFAFC4DA3B9564C822CA53E1A@multiplay.co.uk> To: Steven Hartland X-Authentication: b+8ttet5ATo2IEWsfnuZ9gwNHsEeTs9Rrjl46gicaau8TUtL+0XmQe/IYOwX7v9g7C1vwMQjsASMvjYIIFmOpIMznhbQda81fTdhf46F9zaUfQwsc2SUFVPyy02izMTrqU1cC083mAIL5BE+GgCVXzKjmbvHfI28CBCVIidK8SaCH7JqgfMq/1a8MA== Cc: freebsd-stable@freebsd.org, Adam Jacob Muller Subject: Re: freebsd / gpt boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 00:23:49 -0000 I'm assuming your referring to " FreeBSD 8 GPT install, how?" thread you = originated? While that thread covers generically installing on GPT, it does not = cover this issue. Also, even after adjusting a few things -- using gpart instead of gpt to = make partitions and "gpart bootcode" instead of "gpt boot" which is the = only difference between what these faqs suggest and what I was doing -- = I am still encountering the same issue. -Adam On Dec 13, 2009, at 5:53 PM, Steven Hartland wrote: > There's already a thread about this last week, which contains the info = you need to set this up. >=20 > The only thing I'd warn you about is to ensure you use the DVD not the = CD as the CD doesn't have > all the things you'll need on it. >=20 > Regards > Steve >=20 > ----- Original Message ----- From: "Adam Jacob Muller" = > To: > Sent: Sunday, December 13, 2009 8:26 PM > Subject: freebsd / gpt boot >=20 >=20 > Hi, > I'm trying to setup a system with a very large RAID array (total = ~10TB), I would ideally like to have the system boot directly off that = 10TB array, so i'm trying to get the system setup with GPT but running = into an issue. >=20 >=20 > The initial pre-loader (boot0 I think? -- i'm not sure what this is = called) is unable to find loader at /boot/loader nor can it load = /boot/kernel/kernel >=20 > Copying /boot/loader to /loader allows me to enter /loader at the = "boot:" prompt and the loader will load, however, its unable to load the = kernel. >=20 > If I do an "ls" at the loader prompt I can see boot listed as a = directory (with a "d" before it) > Trying to do "ls boot" inexplicably it says "boot: not a directory" >=20 > re-applying my /boot/loader.conf settings (for some reason = vfs.root.mountfrom=3Dufs:/dev/label/root is required, or else I get a = mountroot>) and then: > load /kernel > boot >=20 > does work, and lets the system boot normally and everything is as = expected (/boot is a directory etc). >=20 > Anyone have any ideas about either of these things (the = vfs.root.mountfrom is minor i guess but i'm curious if they are = related?) >=20 > Thanks in advance, >=20 > -Adam >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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.=20 > 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. >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 00:57:05 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 221681065692 for ; Mon, 14 Dec 2009 00:57:05 +0000 (UTC) (envelope-from lazlar@lazlarlyricon.com) Received: from proxy2.bredband.net (proxy2.bredband.net [195.54.101.72]) by mx1.freebsd.org (Postfix) with ESMTP id CD6E48FC1B for ; Mon, 14 Dec 2009 00:57:04 +0000 (UTC) Received: from ipb2.telenor.se (195.54.127.165) by proxy2.bredband.net (7.3.140.3) id 4AD3E1BC01AF999C for freebsd-stable@freebsd.org; Mon, 14 Dec 2009 01:57:03 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoBvAPobJUtV44PPPGdsb2JhbACBSpccgkcBAQEBN7d6hCsEgWKEAQ X-IronPort-AV: E=Sophos;i="4.47,392,1257116400"; d="scan'208";a="15338699" Received: from c-cf83e355.09-42-6e6b7010.cust.bredbandsbolaget.se (HELO lazlar.kicks-ass.net) ([85.227.131.207]) by ipb2.telenor.se with ESMTP; 14 Dec 2009 01:57:03 +0100 Message-ID: <4B258D5E.6090704@lazlarlyricon.com> Date: Mon, 14 Dec 2009 01:57:02 +0100 From: Rolf G Nielsen User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Adam Jacob Muller References: <2A3A50FE-13F4-4AA7-976E-37354E5736B5@adam.gs> <4B256907.4060805@lazlarlyricon.com> <586264AE-3DB3-4999-8F8C-A51329DA2BEA@adam.gs> <4B257A3E.9080902@lazlarlyricon.com> <2C20D943-171F-4C0A-88EC-6C01CB9F4F13@adam.gs> <4B258AC5.2010102@lazlarlyricon.com> <3E54503F-811A-43A6-BA49-233E3734F34A@adam.gs> In-Reply-To: <3E54503F-811A-43A6-BA49-233E3734F34A@adam.gs> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: freebsd / gpt boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 00:57:05 -0000 Adam Jacob Muller wrote: > On Dec 13, 2009, at 7:45 PM, Rolf G Nielsen wrote: > >> Adam Jacob Muller wrote: >>> On Dec 13, 2009, at 6:35 PM, Rolf G Nielsen wrote: >>>> Adam Jacob Muller wrote: >>>>> Hi Rolf, >>>>> I am using the "gpt boot" command right after calling "gpart create" which should combine the add/bootcode. >>>> Sorry, but I can't help you there. I moved to GUID partitions when upgrading to 8.0, and 8.0 doesn't have the gpt command (at least my install doesn't), thus I'm not familiar with it. >>> Interesting, I hadn't realized that gpt was removed in 8.0 and replaced with gpart, I just redid everything I was doing using "gpart" instead of "gpt" and unfortunately I have the same result. >>>>> Things do look right from a "gpart show" >>>>> # gpart show >>>>> => 34 19529727933 mfid0 GPT (9.1T) >>>>> 34 128 1 freebsd-boot (64K) >>>>> 162 1048576 2 freebsd-swap (512M) >>>>> 1048738 19528679229 3 freebsd-ufs (9.1T) >>>>> This does not work though, >>>>>> gpart set -a active -i 1 da0 >>>>> # gpart set -a active -i 1 mfid0 >>>>> gpart: attrib 'active': Device not configured >>>> I've never actually tried it myself, because it worked for me without it. I just took it from a tutorial I read after I had made the switch. I didn't bother to keep the address, but I stumbled upon it when reading about booting from ZFS. >>>> >>>>> -Adam >>>> Anyway, I saw someone else had replied saying that there recently was a thread about this. I hope you find it, and that it will help you. >>> unfortunately that thread is really not really relevant beyond generic having a few pointers to generic install-howtos. >>>> Good Luck! >>>> >>>> Rolf Nielsen >>>> >>>>> On Dec 13, 2009, at 5:21 PM, Rolf G Nielsen wrote: >>>>>> Adam Jacob Muller wrote: >>>>>>> Hi, >>>>>>> I'm trying to setup a system with a very large RAID array (total ~10TB), I would ideally like to have the system boot directly off that 10TB array, so i'm trying to get the system setup with GPT but running into an issue. >>>>>>> The initial pre-loader (boot0 I think? -- i'm not sure what this is called) is unable to find loader at /boot/loader nor can it load /boot/kernel/kernel >>>>>> Is the partitioning done correctly (have you created a small boot partition, 15 sectors is enough for booting from ufs, but the tutorials I've found deal mainly with booting from zfs and they recommend 128 sectors to make future bootcode changes easier)? >>>>>> >>>>>> gpart add -b 34 -s 128 -t freebsd-boot -i 1 da0 >>>>>> >>>>>> Have you embedded the correct boot code? >>>>>> >>>>>> gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 da0 >>>>>> (for booting from ufs). >>>>>> >>>>>> or >>>>>> >>>>>> gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 >>>>>> (for booting from zfs). >>>>>> >>>>>> You may also need to set it active by >>>>>> >>>>>> gpart set -a active -i 1 da0 >>>>>> >>>>>> And of course, substitute your arrays device node for da0 in my examples. >>>>>> >>>>>>> Copying /boot/loader to /loader allows me to enter /loader at the "boot:" prompt and the loader will load, however, its unable to load the kernel. >>>>>>> If I do an "ls" at the loader prompt I can see boot listed as a directory (with a "d" before it) >>>>>>> Trying to do "ls boot" inexplicably it says "boot: not a directory" >>>>>>> re-applying my /boot/loader.conf settings (for some reason vfs.root.mountfrom=ufs:/dev/label/root is required, or else I get a mountroot>) and then: >>>>>>> load /kernel >>>>>>> boot >>>>>>> does work, and lets the system boot normally and everything is as expected (/boot is a directory etc). >>>>>>> Anyone have any ideas about either of these things (the vfs.root.mountfrom is minor i guess but i'm curious if they are related?) >>>>>>> Thanks in advance, >>>>>>> -Adam >>>>>>> _______________________________________________ >>>>>>> freebsd-stable@freebsd.org mailing list >>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>>>>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> Just a thought. Do you have options GEOM_PART_GPT in your kernel? It's a longshot, as without it you probably wouldn't get as far as you do. It's included in the 8.0 GENERIC kernel, but in case you have a custom kernel whose config you imported from a previous version, it may be worth checking. > > > Yes, it is in there, but I don't see that affecting the boot0 or loader.. > > -Adam > > > You're right. Shouldn't affect anything before the kernel. Like I said, a longshot. I'm out of ideas. Hope you solve it. Rolf P.S. I just realised I'd been omitting the list in my replies. Apologies. From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 01:12:49 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2FEF1065692 for ; Mon, 14 Dec 2009 01:12:49 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 337F48FC1C for ; Mon, 14 Dec 2009 01:12:48 +0000 (UTC) Received: from inchoate.gsoft.com.au (ppp121-45-158-182.lns6.adl6.internode.on.net [121.45.158.182]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id nBE1Cj5f088336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 14 Dec 2009 11:42:46 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Mon, 14 Dec 2009 11:42:39 +1030 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6929712.RLMPNoH0ki"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200912141142.41897.doconnor@gsoft.com.au> X-Spam-Score: -2.212 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Pim Bliek Subject: Re: USB GPS mouse in Wine X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 01:12:49 -0000 --nextPart6929712.RLMPNoH0ki Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 14 Dec 2009, Pim Bliek wrote: > Anyone any suggestions on this issue? I did a lot of Google... but > did not find anything usefull beyond this point. Seems this works on > Linux with Wine, but no clues for getting this working in FreeBSD. I have a Bluetooth GPS device and I can talk to it under Wine. I am not really sure what you mean by a GPS mouse.. You mean a USB GPS=20 receiver? I found that this program worked -=20 http://www.visualgps.net/VisualGPS/Download/Download.html Can you get it to talk to your device? =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart6929712.RLMPNoH0ki Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLJZEJ5ZPcIHs/zowRArmRAKCjRFSbDJAAEYiPyOGKibf7Syrt6wCfeum5 MQQDJh1Pw1ez6jmhYgD68M4= =m1EQ -----END PGP SIGNATURE----- --nextPart6929712.RLMPNoH0ki-- From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 02:01:40 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22BE91065692 for ; Mon, 14 Dec 2009 02:01:40 +0000 (UTC) (envelope-from kasahara@nc.kyushu-u.ac.jp) Received: from elvenbow.cc.kyushu-u.ac.jp (unknown [IPv6:2001:200:905:1407:202:2aff:fedd:c31]) by mx1.freebsd.org (Postfix) with ESMTP id A27748FC0C for ; Mon, 14 Dec 2009 02:01:39 +0000 (UTC) Received: from localhost (kasahara@localhost [IPv6:::1]) by elvenbow.cc.kyushu-u.ac.jp (8.14.3/8.14.3) with ESMTP id nBE21br1005796; Mon, 14 Dec 2009 11:01:37 +0900 (JST) (envelope-from kasahara@nc.kyushu-u.ac.jp) Date: Mon, 14 Dec 2009 11:01:37 +0900 (JST) Message-Id: <20091214.110137.585114676083292120.kasahara@nc.kyushu-u.ac.jp> To: pyunyh@gmail.com From: Yoshiaki Kasahara In-Reply-To: <20091211000848.GK10121@michelle.cdnetworks.com> References: <20091208180836.GL1366@michelle.cdnetworks.com> <20091210215249.GG10121@michelle.cdnetworks.com> <20091211000848.GK10121@michelle.cdnetworks.com> X-Fingerprint: CDA2 B6B6 6796 0DD3 9D80 2602 E909 4623 A15E A074 X-URL: http://www.nc.kyushu-u.ac.jp/~kasahara/ X-Mailer: Mew version 6.2.50 on Emacs 23.1.50 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: vge problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 02:01:40 -0000 On Thu, 10 Dec 2009 16:08:49 -0800, Pyun YongHyeon said: > While reading the code again I found some suspicious part which > could be related with your issue. The controller's CMZ field has > 3bits so it can handle 7 fragments of a TX frame. However, > controller wants to see number of fragments + 1 in this field which > means we can't use all 7 fragments in a TX descriptor. I changed > the patch to reduce number of TX fragments to 6. Does the following > patch make any difference for you? > http://people.freebsd.org/~yongari/vge/vge.busdma.diff3 I'm sorry I was away from the console during last weekend.... Today I booted new kernel with diff3 patch, and did a couple of tests (massive thumbnail loading and csup). All of them worked as expected and no Send-Q stack observed, so I believe the problem is fixed by this patch. I really appreciate your swift update! Regards, -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University kasahara@nc.kyushu-u.ac.jp From owner-freebsd-stable@FreeBSD.ORG Sun Dec 13 21:41:16 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BEB31065670 for ; Sun, 13 Dec 2009 21:41:16 +0000 (UTC) (envelope-from jack@jarasoft.net) Received: from raats.xs4all.nl (raats.xs4all.nl [82.95.230.43]) by mx1.freebsd.org (Postfix) with ESMTP id 308B18FC14 for ; Sun, 13 Dec 2009 21:41:16 +0000 (UTC) Received: from raats.xs4all.nl (localhost.jarasoft.net [127.0.0.1]) by raats.xs4all.nl (Postfix) with ESMTP id 0B41223446 for ; Sun, 13 Dec 2009 22:28:57 +0100 (CET) Received: from jarasc430 (unknown [10.10.10.110]) by raats.xs4all.nl (Postfix) with ESMTPA id B7EC32339F for ; Sun, 13 Dec 2009 22:28:56 +0100 (CET) Message-ID: <07A054B7DD6A4672AC48684DEAB31697@jarasc430> From: "Jack Raats" To: Date: Sun, 13 Dec 2009 22:28:55 +0100 Organization: JaRaSoft, Steenbergen, Nederland MIME-Version: 1.0 X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Relayed-By: GPGrelay Version 0.959 (Win32) X-Virus-Scanned: ClamAV using ClamSMTP on orac.jarasoft.net X-Mailman-Approved-At: Mon, 14 Dec 2009 05:28:44 +0000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Jails and IPFW X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jack Raats List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 21:41:16 -0000 Hi, I'm looking for a good manual how to implement ipfw in and with jails. Google doesn't give anything usefull Thanks for your time Jack From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 05:34:01 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC3A7106568D for ; Mon, 14 Dec 2009 05:34:01 +0000 (UTC) (envelope-from pprocacci@datapipe.com) Received: from EXFESMQ01.datapipe-corp.net (exchange.datapipe.net [64.106.130.71]) by mx1.freebsd.org (Postfix) with ESMTP id A519B8FC16 for ; Mon, 14 Dec 2009 05:34:01 +0000 (UTC) Received: from [10.5.21.3] (192.168.128.24) by EXFESMQ01.datapipe-corp.net (64.106.130.71) with Microsoft SMTP Server id 8.1.393.1; Mon, 14 Dec 2009 00:34:00 -0500 Message-ID: <4B25CE1C.8030305@datapipe.com> Date: Sun, 13 Dec 2009 23:33:16 -0600 From: Paul Procacci User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jack Raats References: <07A054B7DD6A4672AC48684DEAB31697@jarasc430> In-Reply-To: <07A054B7DD6A4672AC48684DEAB31697@jarasc430> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "freebsd-stable@freebsd.org" Subject: Re: Jails and IPFW X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 05:34:01 -0000 If you are asking whether the root user of the jail can implement their own firewall, then no that is not possible. If you are asking whether you can use ipfw along side jails, then yes you can. The administration of said firewall doesn't change one bit due to the introduction of a jail. So, if it's information pertaining to ipfw that you need then `man ipfw` is what you seek. ~Paul Jack Raats wrote: > Hi, > > I'm looking for a good manual how to implement ipfw in and with jails. > Google doesn't give anything usefull > > Thanks for your time > > Jack > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > This message may contain confidential or privileged information. If you ar= e not the intended recipient, please advise us immediately and delete this = message. See http://www.datapipe.com/emaildisclaimer.aspx for further info= rmation on confidentiality and the risks of non-secure electronic communica= tion. If you cannot access these links, please notify us by reply message a= nd we will send the contents to you. From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 05:50:39 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 392BA1065693 for ; Mon, 14 Dec 2009 05:50:39 +0000 (UTC) (envelope-from n-butcher=freebsd-stable=freebsd.org=mmporwnv@fusiongol.com) Received: from smtp11.dentaku.gol.com (smtp11.dentaku.gol.com [203.216.5.73]) by mx1.freebsd.org (Postfix) with ESMTP id 0950D8FC14 for ; Mon, 14 Dec 2009 05:50:38 +0000 (UTC) Received: from pat.gol.ad.jp ([203.216.1.191] helo=[172.16.1.151]) by smtp11.dentaku.gol.com with esmtpsa (Dentaku) id 1NK3a0-0007Pm-3C for ; Mon, 14 Dec 2009 14:34:44 +0900 Message-ID: <4B25CE74.8070700@fusiongol.com> Date: Mon, 14 Dec 2009 14:34:44 +0900 From: Nathan Butcher User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20091214005717.20D6E10657A8@hub.freebsd.org> In-Reply-To: <20091214005717.20D6E10657A8@hub.freebsd.org> X-Enigmail-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV GOL (outbound) X-Abuse-Complaints: abuse@gol.com Subject: Jails working differently in FreeBSD-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 05:50:39 -0000 Jails appear to be working differently in 8.0 compared with 7.x (due to the networking changes in 8 most likely). Anyway, I've created a jail in 8.0 and given it it's own IPv4 IP address. Problem is, when I attempt to SSH to this jail IP address, I'm arriving in the host environment, and not the jailed environment. In 7.x I would have landed inside the jail.... so what's going on in 8? Hopefully someone who has already solved this issue can help me out a bit. From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 05:52:45 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E75ED106566B for ; Mon, 14 Dec 2009 05:52:45 +0000 (UTC) (envelope-from dhorn2000@gmail.com) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by mx1.freebsd.org (Postfix) with ESMTP id 7ED198FC12 for ; Mon, 14 Dec 2009 05:52:45 +0000 (UTC) Received: by fxm28 with SMTP id 28so1030404fxm.13 for ; Sun, 13 Dec 2009 21:52:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=+OIrn1OTQKLo0B8Wie8BhCZARtdf9qVddtuWdCD2pj0=; b=WjbSKzCZRdWk1QndyLRhmYQDSdPp3XjK/rY+L8IKuov7qvuAxFMUljHjXv6fEa4G6L YALnFUIDvz5bCIydhhJeL3b8o4vtrQxYB9HTPPjcPXw383F2il/JCskATgKHaCaQd1UE wnwdw6zIEZoSIKgL5J/0yrWMH0kyYWPb//uV4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dTHPlcLUkxFJyIjt00Mj5n+RCeyMmzwRl3Z9zobxYCUVOg+ueg2DumAXfQJQvG15SC CpYsmp9U2ZC5M8iGFKLN7ffvVSlcs6jsL/rjZZHFaMbAoPsZAmh202CcDK3QcT4OokkR LzxfAPwI9b60x07XAUBMp80IZOrpBJyJLdKDQ= MIME-Version: 1.0 Received: by 10.239.183.26 with SMTP id s26mr456588hbg.179.1260768197268; Sun, 13 Dec 2009 21:23:17 -0800 (PST) In-Reply-To: <20091213103237.d01b51f2.usselmann.m@icg-online.de> References: <20091213103237.d01b51f2.usselmann.m@icg-online.de> Date: Mon, 14 Dec 2009 00:23:17 -0500 Message-ID: <25ff90d60912132123x77198b1o6bfad3bffe0d01a0@mail.gmail.com> From: David Horn To: Manfred Usselmann Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: duplicity ftp backup / ncftp no longer working since 8.0-Release X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 05:52:46 -0000 On Sun, Dec 13, 2009 at 4:32 AM, Manfred Usselmann wrote: > Hi, > > since my upgrade to 8.0-RELEASE my backup solution with duplicity is no > longer working because ncftpput fails. > > The error message from ncftp 3.2.2_1: Could not read reply from control > connection -- timed out. > > S.a. http://www.freebsd.org/cgi/query-pr.cgi?pr=140934 > > Does anybody know a solution or a workaround? I have seen this with ncftpput as well, but at least in my case, it was a warning, and not a fatal error. Check your ftp server to see if the backup file has indeed been transferred. I believe that there is something unusual going on with the checking on select() return in ncftp3. If you change every instance of select() result checking in ftp/ncftp3 from "==1" to ">=1" the problem seems to go away. result = select(sfd + 1, NULL, SELECT_TYPE_ARG234 &ss, NULL, SELECT_TYPE_ARG5 &tv); -if (result == 1) { +if (result >= 1) { Good Luck. ---Dave H From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 06:16:24 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DFBE1065672 for ; Mon, 14 Dec 2009 06:16:24 +0000 (UTC) (envelope-from jack@jarasoft.net) Received: from raats.xs4all.nl (raats.xs4all.nl [82.95.230.43]) by mx1.freebsd.org (Postfix) with ESMTP id B81D98FC16 for ; Mon, 14 Dec 2009 06:16:23 +0000 (UTC) Received: from raats.xs4all.nl (localhost.jarasoft.net [127.0.0.1]) by raats.xs4all.nl (Postfix) with ESMTP id B7FEE2290E; Mon, 14 Dec 2009 07:16:24 +0100 (CET) Received: from jarasc430 (unknown [10.10.10.110]) by raats.xs4all.nl (Postfix) with ESMTPA id 619D322900; Mon, 14 Dec 2009 07:16:24 +0100 (CET) Message-ID: <2E2F1B2A67C84F5AAD96D20E72897EF6@jarasc430> From: "Jack Raats" To: "Paul Procacci" References: <07A054B7DD6A4672AC48684DEAB31697@jarasc430> <4B25CE1C.8030305@datapipe.com> Date: Mon, 14 Dec 2009 07:16:20 +0100 Organization: JaRaSoft, Steenbergen, Nederland 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.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Relayed-By: GPGrelay Version 0.959 (Win32) X-Virus-Scanned: ClamAV using ClamSMTP on orac.jarasoft.net Cc: freebsd-stable@freebsd.org Subject: Re: Jails and IPFW X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jack Raats List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 06:16:24 -0000 Hi Paul, I'll understand, but I want to run apache and ssh on both jails using their standard configs. (So they listen to every ip address and interface). >From your answer I learn than ipfw has to run on the host machine like: $IPF 6000 pass tcp from any to $jail1 22,80 in $IPF 6000 pass tcp from any to $jail2 22,80 in Jack ----- Original Message ----- From: "Paul Procacci" To: "Jack Raats" Cc: Sent: Monday, December 14, 2009 6:33 AM Subject: Re: Jails and IPFW If you are asking whether the root user of the jail can implement their own firewall, then no that is not possible. If you are asking whether you can use ipfw along side jails, then yes you can. The administration of said firewall doesn't change one bit due to the introduction of a jail. So, if it's information pertaining to ipfw that you need then `man ipfw` is what you seek. ~Paul Jack Raats wrote: > Hi, > > I'm looking for a good manual how to implement ipfw in and with jails. > Google doesn't give anything usefull > > Thanks for your time > > Jack > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/emaildisclaimer.aspx for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 06:16:41 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B24B01065781 for ; Mon, 14 Dec 2009 06:16:41 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 3EDA88FC13 for ; Mon, 14 Dec 2009 06:16:40 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 22so796317eye.9 for ; Sun, 13 Dec 2009 22:16:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=C+c06bwahK7ZpGzAL9fR1ZE16aaTR5J/KqLhTy6iK3w=; b=Mg4koZzxTFByD+nT6KzGMkH0srqLoafSKeJxfwiX0I/bh2hKYicRjN9UgsJGwRStqR or1gmt9Y7YdOOu2yrW9Uh/PZCBc+FNjw10cNkTQhxBk4lwD4x+UPMXCqpe/3NhagnWpO 8Qo7sJhLA8C082b/faHEi6obt4Vzr2JnhAL4o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RhqmKbgL0VhtXBemVLlZSff+7BN9fG9H9WHnFc/srtECw3QMa5aVxZTL1j8AIs5bod m+Dc6I91aXS7omCrMtifbWcmwnRjDI6eBYKt0gGRehMTfeSukWuNcGxUu6xJtnDtC29s wyQbjRv0FwO6VhERpXyE5fVaIDqIQnPAaBO64= MIME-Version: 1.0 Received: by 10.216.90.79 with SMTP id d57mr137024wef.117.1260771400055; Sun, 13 Dec 2009 22:16:40 -0800 (PST) In-Reply-To: <200912141142.41897.doconnor@gsoft.com.au> References: <200912141142.41897.doconnor@gsoft.com.au> Date: Mon, 14 Dec 2009 01:16:39 -0500 Message-ID: <5f67a8c40912132216p577fd75bqb329654f6e3b60ab@mail.gmail.com> From: Zaphod Beeblebrox To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Pim Bliek , freebsd-stable@freebsd.org Subject: Re: USB GPS mouse in Wine X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 06:16:41 -0000 On Sun, Dec 13, 2009 at 8:12 PM, Daniel O'Connor wrote: > On Mon, 14 Dec 2009, Pim Bliek wrote: > > Anyone any suggestions on this issue? I did a lot of Google... but > > did not find anything usefull beyond this point. Seems this works on > > Linux with Wine, but no clues for getting this working in FreeBSD. > > I have a Bluetooth GPS device and I can talk to it under Wine. > > I am not really sure what you mean by a GPS mouse.. You mean a USB GPS > receiver? > It seems that a "GPS mouse" is a GPS receiver that is the size and shape of a computer mouse --- although only rather approximately. It's a horrid term The first time I heard it, I considered for a moment if someone was using a GPS receiver as the sensor for a mouse (rather than a ball or laser optics). I only considered this for a moment... it's obviously not possible. I found that this program worked - > http://www.visualgps.net/VisualGPS/Download/Download.html > > Can you get it to talk to your device? > Isn't the key going to be finding one of the USB serial interfaces that work? For all the technology in a GPS, they communicate via serial protocols (s.t. the bluetooth ones present a serial profile --- that's how you get your bluetooth GPS working). Too bad there isn't a small number of standard USB serial protocols ... like bluetooth. From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 06:30:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 254661065670 for ; Mon, 14 Dec 2009 06:30:09 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id A8C538FC0A for ; Mon, 14 Dec 2009 06:30:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 200B041C75B; Mon, 14 Dec 2009 07:30:07 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 4Yv8GT1kIf0O; Mon, 14 Dec 2009 07:30:06 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 0013D41C759; Mon, 14 Dec 2009 07:30:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 1EB174448EC; Mon, 14 Dec 2009 06:27:25 +0000 (UTC) Date: Mon, 14 Dec 2009 06:27:24 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Nathan Butcher In-Reply-To: <4B25CE74.8070700@fusiongol.com> Message-ID: <20091214062601.E86040@maildrop.int.zabbadoz.net> References: <20091214005717.20D6E10657A8@hub.freebsd.org> <4B25CE74.8070700@fusiongol.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Jails working differently in FreeBSD-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 06:30:09 -0000 On Mon, 14 Dec 2009, Nathan Butcher wrote: > Jails appear to be working differently in 8.0 compared with 7.x (due to > the networking changes in 8 most likely). > > Anyway, I've created a jail in 8.0 and given it it's own IPv4 IP > address. Problem is, when I attempt to SSH to this jail IP address, I'm > arriving in the host environment, and not the jailed environment. > > In 7.x I would have landed inside the jail.... so what's going on in 8? > Hopefully someone who has already solved this issue can help me out a bit. It may sound silly but can you confirm that sshd is running inside the jail? Also, how did you start the jail? jls -av output might be interesting. /bz PS: there is a freebsd-jail list as well. -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 06:31:37 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E214106566C for ; Mon, 14 Dec 2009 06:31:37 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id B66EB8FC17 for ; Mon, 14 Dec 2009 06:31:36 +0000 (UTC) Received: from inchoate.gsoft.com.au (ppp121-45-158-182.lns6.adl6.internode.on.net [121.45.158.182]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id nBE6VXOF097562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 14 Dec 2009 17:01:34 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Zaphod Beeblebrox Date: Mon, 14 Dec 2009 17:01:19 +1030 User-Agent: KMail/1.9.10 References: <200912141142.41897.doconnor@gsoft.com.au> <5f67a8c40912132216p577fd75bqb329654f6e3b60ab@mail.gmail.com> In-Reply-To: <5f67a8c40912132216p577fd75bqb329654f6e3b60ab@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2179996.qZWW8ic1TJ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200912141701.28237.doconnor@gsoft.com.au> X-Spam-Score: -2.212 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Pim Bliek , freebsd-stable@freebsd.org Subject: Re: USB GPS mouse in Wine X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 06:31:37 -0000 --nextPart2179996.qZWW8ic1TJ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 14 Dec 2009, Zaphod Beeblebrox wrote: > > I am not really sure what you mean by a GPS mouse.. You mean a USB > > GPS receiver? > > It seems that a "GPS mouse" is a GPS receiver that is the size and > shape of a computer mouse --- although only rather approximately.=20 > It's a horrid term The first time I heard it, I considered for a > moment if someone was using a GPS receiver as the sensor for a mouse > (rather than a ball or laser optics). I only considered this for a > moment... it's obviously not possible. I guessed that's what you meant, but it IS a horrid term :) > > http://www.visualgps.net/VisualGPS/Download/Download.html > > > > Can you get it to talk to your device? > > Isn't the key going to be finding one of the USB serial interfaces > that work? For all the technology in a GPS, they communicate via > serial protocols (s.t. the bluetooth ones present a serial profile > --- that's how you get your bluetooth GPS working). I thought you said you had it working with gpsd, is that correct? If no, what appears in dmesg when you plug it in, and what is the output=20 of "sudo usbconfig dump_device_desc"? > Too bad there isn't a small number of standard USB serial protocols > ... like bluetooth. Yes, it is rather annoying :( That said, FreeBSD does support a very large subset of them. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2179996.qZWW8ic1TJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLJdvA5ZPcIHs/zowRAoyvAKClvIA4fEzK+nGoBMYI5bmcHvVzEACghLkP BVfDUbp1Fx7vWzzCzFN2gJs= =WqZd -----END PGP SIGNATURE----- --nextPart2179996.qZWW8ic1TJ-- From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 07:11:17 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FEE11065679 for ; Mon, 14 Dec 2009 07:11:17 +0000 (UTC) (envelope-from usselmann.m@icg-online.de) Received: from oslo074.server4you.de (oslo074.server4you.de [62.75.178.74]) by mx1.freebsd.org (Postfix) with ESMTP id CA26F8FC0A for ; Mon, 14 Dec 2009 07:11:16 +0000 (UTC) Received: (qmail 23744 invoked from network); 14 Dec 2009 08:11:18 +0100 Received: from p54b23b42.dip.t-dialin.net (HELO icg-pc209.icg-pc213) (84.178.59.66) by oslo074.server4you.de with SMTP; 14 Dec 2009 08:11:18 +0100 Date: Mon, 14 Dec 2009 08:11:03 +0100 From: Manfred Usselmann To: Nathan Butcher Message-Id: <20091214081103.56e317f1.usselmann.m@icg-online.de> In-Reply-To: <4B25CE74.8070700@fusiongol.com> References: <20091214005717.20D6E10657A8@hub.freebsd.org> <4B25CE74.8070700@fusiongol.com> Organization: ICG IT Consulting GmbH X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.3; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Jails working differently in FreeBSD-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 07:11:17 -0000 On Mon, 14 Dec 2009 14:34:44 +0900 Nathan Butcher wrote: > Jails appear to be working differently in 8.0 compared with 7.x (due to > the networking changes in 8 most likely). > > Anyway, I've created a jail in 8.0 and given it it's own IPv4 IP > address. Problem is, when I attempt to SSH to this jail IP address, I'm > arriving in the host environment, and not the jailed environment. Sounds like your host sshd is still listening on the ssh port of the IP address of your jail. Check your ListenAddress option in /etc/ssh/sshd_config. Manfred -- Manfred Usselmann ICG IT Consulting GmbH, Kelkheim From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 07:17:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1A831065695 for ; Mon, 14 Dec 2009 07:17:18 +0000 (UTC) (envelope-from usselmann.m@icg-online.de) Received: from oslo074.server4you.de (oslo074.server4you.de [62.75.178.74]) by mx1.freebsd.org (Postfix) with ESMTP id 2752D8FC1D for ; Mon, 14 Dec 2009 07:17:17 +0000 (UTC) Received: (qmail 24137 invoked from network); 14 Dec 2009 08:17:21 +0100 Received: from p54b23b42.dip.t-dialin.net (HELO icg-pc209.icg-pc213) (84.178.59.66) by oslo074.server4you.de with SMTP; 14 Dec 2009 08:17:21 +0100 Date: Mon, 14 Dec 2009 08:17:16 +0100 From: Manfred Usselmann To: David Horn Message-Id: <20091214081716.f6e96b85.usselmann.m@icg-online.de> In-Reply-To: <25ff90d60912132123x77198b1o6bfad3bffe0d01a0@mail.gmail.com> References: <20091213103237.d01b51f2.usselmann.m@icg-online.de> <25ff90d60912132123x77198b1o6bfad3bffe0d01a0@mail.gmail.com> Organization: ICG IT Consulting GmbH X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.3; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: duplicity ftp backup / ncftp no longer working since 8.0-Release X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 07:17:18 -0000 On Mon, 14 Dec 2009 00:23:17 -0500 David Horn wrote: > On Sun, Dec 13, 2009 at 4:32 AM, Manfred Usselmann > wrote: > > > > since my upgrade to 8.0-RELEASE my backup solution with duplicity is no > > longer working because ncftpput fails. > > > > The error message from ncftp 3.2.2_1: Could not read reply from control > > connection -- timed out. > > > > S.a. http://www.freebsd.org/cgi/query-pr.cgi?pr=140934 > > > > Does anybody know a solution or a workaround? > > I have seen this with ncftpput as well, but at least in my case, it > was a warning, and not a fatal error. Check your ftp server to see if > the backup file has indeed been transferred. The file is getting transferred, but duplicity assumes that it is not and abends. > I believe that there is something unusual going on with the checking > on select() return in ncftp3. If you change every instance of > select() result checking in ftp/ncftp3 from "==1" to ">=1" the problem > seems to go away. > > result = select(sfd + 1, NULL, SELECT_TYPE_ARG234 &ss, NULL, > SELECT_TYPE_ARG5 &tv); > -if (result == 1) { > +if (result >= 1) { I will try this. Thanks! Manfred -- Manfred Usselmann ICG IT Consulting GmbH, Kelkheim From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 08:21:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 495041065672 for ; Mon, 14 Dec 2009 08:21:12 +0000 (UTC) (envelope-from pprocacci@datapipe.com) Received: from EXFESMQ01.datapipe-corp.net (exchange.datapipe.net [64.106.130.71]) by mx1.freebsd.org (Postfix) with ESMTP id 11A4B8FC1D for ; Mon, 14 Dec 2009 08:21:12 +0000 (UTC) Received: from [10.5.21.3] (192.168.128.24) by EXFESMQ01.datapipe-corp.net (64.106.130.71) with Microsoft SMTP Server id 8.1.393.1; Mon, 14 Dec 2009 03:21:11 -0500 Message-ID: <4B25F54B.3000601@datapipe.com> Date: Mon, 14 Dec 2009 02:20:27 -0600 From: Paul Procacci User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jack Raats References: <07A054B7DD6A4672AC48684DEAB31697@jarasc430> <4B25CE1C.8030305@datapipe.com> <2E2F1B2A67C84F5AAD96D20E72897EF6@jarasc430> In-Reply-To: <2E2F1B2A67C84F5AAD96D20E72897EF6@jarasc430> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "freebsd-stable@freebsd.org" Subject: Re: Jails and IPFW X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 08:21:12 -0000 I hope I'm not misinterpreting your response. Given what you stated, then I perceive what you stated is correct. Just a thought, but it might make sense for you to specify -J (man jail) via jail__flags via rc.conf for each of your configured jails. Perhaps this would be easier on _you_ for future and current administration of your firewall. This would allow you to add a tad of logic to your firewall script that grab a specific jail id and use it instead. Also, this allows you to move ip's without much trouble if you ever plan on doing so. Here is an example that I have for a jail that I've got trimmed to hopefully make it easy on the eyes: ############################################### rc.conf -------------------- jail_xxx_flags=3D"-J /var/jail/xxxx" ipfw.conf -------------------------- $cmd=3D"ipfw -q" $pif=3D"bge0" $xxx_id=3D`cut -f1 < /var/jail/xxx` $cmd 506 allow tcp from any to me 22,80,443 in via $pif setup jail $xxx_id limit src-addr 6 ############################################### Hope this gives ya some insight and/or potentially will make things easier for ya. ~Paul One suggestion however would be to use different rule numbers for these rules as it could be a slight pain to modify later. Jack Raats wrote: > Hi Paul, > > I'll understand, but I want to run apache and ssh on both jails using the= ir > standard configs. > (So they listen to every ip address and interface). > > From your answer I learn than ipfw has to run on the host machine like: > $IPF 6000 pass tcp from any to $jail1 22,80 in > $IPF 6000 pass tcp from any to $jail2 22,80 in > > Jack > > ----- Original Message ----- > From: "Paul Procacci" > To: "Jack Raats" > Cc: > Sent: Monday, December 14, 2009 6:33 AM > Subject: Re: Jails and IPFW > > > If you are asking whether the root user of the jail can implement their > own firewall, then no that is not possible. > If you are asking whether you can use ipfw along side jails, then yes > you can. The administration of said firewall doesn't change one bit due > to the introduction of a jail. > So, if it's information pertaining to ipfw that you need then `man ipfw` > is what you seek. > > ~Paul > > > Jack Raats wrote: > >> Hi, >> >> I'm looking for a good manual how to implement ipfw in and with jails. >> Google doesn't give anything usefull >> >> Thanks for your time >> >> Jack >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org= " >> >> > > > This message may contain confidential or privileged information. If you = are > not the intended recipient, please advise us immediately and delete this > message. See http://www.datapipe.com/emaildisclaimer.aspx for further > information on confidentiality and the risks of non-secure electronic > communication. If you cannot access these links, please notify us by repl= y > message and we will send the contents to you. > > This message may contain confidential or privileged information. If you ar= e not the intended recipient, please advise us immediately and delete this = message. See http://www.datapipe.com/emaildisclaimer.aspx for further info= rmation on confidentiality and the risks of non-secure electronic communica= tion. If you cannot access these links, please notify us by reply message a= nd we will send the contents to you. From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 08:28:38 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EC86106566B for ; Mon, 14 Dec 2009 08:28:38 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id A30D18FC12 for ; Mon, 14 Dec 2009 08:28:37 +0000 (UTC) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost [IPv6:::1]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.3/8.14.3) with ESMTP id nBE8SUB5080874; Mon, 14 Dec 2009 08:28:31 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp.infracaninophile.co.uk nBE8SUB5080874 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=infracaninophile.co.uk; s=200708; t=1260779312; bh=8EyNap9oq4yARNFtGP5Er7klLnQxJRVrYSWtZSjMi8c=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Cc:Content-Type:Date:From:In-Reply-To: Message-ID:Mime-Version:References:To; z=Message-ID:=20<4B25F728.9060408@infracaninophile.co.uk>|Date:=20M on,=2014=20Dec=202009=2008:28:24=20+0000|From:=20Matthew=20Seaman= 20|Organization:=20Infracaninophi le|User-Agent:=20Thunderbird=202.0.0.23=20(X11/20091129)|MIME-Vers ion:=201.0|To:=20Jack=20Raats=20|CC:=20freebsd- stable@freebsd.org|Subject:=20Re:=20Jails=20and=20IPFW|References: =20<07A054B7DD6A4672AC48684DEAB31697@jarasc430>|In-Reply-To:=20<07 A054B7DD6A4672AC48684DEAB31697@jarasc430>|X-Enigmail-Version:=200. 95.6|Content-Type:=20multipart/signed=3B=20micalg=3Dpgp-sha256=3B= 0D=0A=20protocol=3D"application/pgp-signature"=3B=0D=0A=20boundary =3D"------------enigE5E7525D312A42EF6E4824EA"; b=UAI0awrEtFs/ZCECF2Bi9SbIukhJK++IsLpb+hoqcBLn4JbzF2sI5tK6AlhLKTl+E KN20PP0nINaeKqFqSjJZ5fk80rpxw5YLdcEZJgvwRoTYJrQOXDX8I47AGDuTRo8o12 HW4Z56oi6QlPji1G6ZiGuqIoQ8R/Mckc1ZST+UcQ= X-Authentication-Warning: happy-idiot-talk.infracaninophile.co.uk: Host localhost [IPv6:::1] claimed to be happy-idiot-talk.infracaninophile.co.uk Message-ID: <4B25F728.9060408@infracaninophile.co.uk> Date: Mon, 14 Dec 2009 08:28:24 +0000 From: Matthew Seaman Organization: Infracaninophile User-Agent: Thunderbird 2.0.0.23 (X11/20091129) MIME-Version: 1.0 To: Jack Raats References: <07A054B7DD6A4672AC48684DEAB31697@jarasc430> In-Reply-To: <07A054B7DD6A4672AC48684DEAB31697@jarasc430> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigE5E7525D312A42EF6E4824EA" X-Virus-Scanned: clamav-milter 0.95.3 at happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VERIFIED,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on happy-idiot-talk.infracaninophile.co.uk Cc: freebsd-stable@freebsd.org Subject: Re: Jails and IPFW X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 08:28:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE5E7525D312A42EF6E4824EA Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Jack Raats wrote: > Hi, >=20 > I'm looking for a good manual how to implement ipfw in and with jails. > Google doesn't give anything usefull >=20 > Thanks for your time By default, the only way you can implement firewalling (either ipfw, ipf or pf) is within the host system -- it simply has not been possible to control firewalls from within a jail. Until now, that is. You will need to be running 8.0-RELEASE or a more recent version. You wil= l also need to compile yourself a custom kernel with options VIMAGE This is /experimental/[*] code that allows each jail to have its own virtualised network stack aka "vnet", which includes being able to run a per-jail instance of firewalling software. According to=20 http://www.freebsd.org/releases/8.0R/relnotes-detailed.html#KERNEL You will need a commandline along the lines of the following to create a vnet enabled jail: # jail -c vnet name=3Dvnet1 host.hostname=3Dvnet1.example.net path=3D/= persist There's not much online discussion about this yet, but one key piece of information you will need is how to move a network interface into a jail = -- look for the description of the 'vnet' option in ifconfig(8). You might also be interested in the new epair(4) driver, which is one step more complicated than a loopback interface in that it creates a back-to-back pair of synthetic ethernet interfaces. (The idea being that you move one end of the pair into a jail to give yourself a connection from the jail t= o the outside world.) Cheers, Matthew [*] As in: no refunds will be given. --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW --------------enigE5E7525D312A42EF6E4824EA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAksl9y4ACgkQ8Mjk52CukIz3wwCfTiuSQ38mTHobMo+tjOV95ciY 68EAoIm60LoXI9MZ5h5opoxNDkufsldP =RxJy -----END PGP SIGNATURE----- --------------enigE5E7525D312A42EF6E4824EA-- From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 09:49:39 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91D4C1065670 for ; Mon, 14 Dec 2009 09:49:39 +0000 (UTC) (envelope-from prvs=1599f034ad=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 265FE8FC13 for ; Mon, 14 Dec 2009 09:49:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1260783659; x=1261388459; q=dns/txt; h=Received: Message-ID:From:To:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=4SB2niGKQFWrhi5Snfwm1 9LFqq58oC3HptdTng6BeUA=; b=BJJ/04BSS+sSxbo5LcTjGqJCGc6En2+i/2PJf SAJdGDZJUxaEQIpsWtZ+65Y7g3jlJrIvq+omKLnS8p/59zxk39HHqsl7VDKTigTG up2LpZQM1UhmYHw0Mmqhp8JGo+4xf0FtniHm5ldUZu8ubBZHdm0FY7+IS+cJNdUm a4vfnU= X-MDAV-Processed: mail1.multiplay.co.uk, Mon, 14 Dec 2009 09:40:59 +0000 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50008857813.msg for ; Mon, 14 Dec 2009 09:40:58 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 14 Dec 2009 09:40:58 +0000 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 213.123.247.160 X-Return-Path: prvs=1599f034ad=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: From: "Steven Hartland" To: "Nathan Butcher" , References: <20091214005717.20D6E10657A8@hub.freebsd.org> <4B25CE74.8070700@fusiongol.com> Date: Mon, 14 Dec 2009 09:40:57 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-2022-jp"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Subject: Re: Jails working differently in FreeBSD-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 09:49:39 -0000 Did you make sure you tightly binded sshd on the host. Regards Steve ----- Original Message ----- From: "Nathan Butcher" > Jails appear to be working differently in 8.0 compared with 7.x (due to > the networking changes in 8 most likely). > > Anyway, I've created a jail in 8.0 and given it it's own IPv4 IP > address. Problem is, when I attempt to SSH to this jail IP address, I'm > arriving in the host environment, and not the jailed environment. > > In 7.x I would have landed inside the jail.... so what's going on in 8? > Hopefully someone who has already solved this issue can help me out a bit. ================================================ 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-stable@FreeBSD.ORG Mon Dec 14 09:49:39 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95C3C1065672 for ; Mon, 14 Dec 2009 09:49:39 +0000 (UTC) (envelope-from prvs=1599f034ad=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 2918F8FC14 for ; Mon, 14 Dec 2009 09:49:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1260783567; x=1261388367; q=dns/txt; h=Received: Message-ID:From:To:Cc:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=x5pGjVTQnPhKEUT2tAtd/ XUOxeUp3cdAVBt3c5Vo8PA=; b=jAwwrGi47TOQkWTKRgrloc9NxV92XPTE+u0HU b6Tb0LIH8vo0BOhu37cEGHXlOoYgWiMIRvFMTwLCsXxmECwiE6JGPAHLSMRGHnSk r9Unen8tsgenZZIwNCxHwqnlNt6ofgX6A38zdHuj1KbQs7vRh5nt/uII1wZzCq24 BKWpV4= X-MDAV-Processed: mail1.multiplay.co.uk, Mon, 14 Dec 2009 09:39:27 +0000 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50008857805.msg for ; Mon, 14 Dec 2009 09:39:27 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 14 Dec 2009 09:39:27 +0000 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 213.123.247.160 X-Return-Path: prvs=1599f034ad=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <83E2880869394A5E91B0FB5CFAA72D0B@multiplay.co.uk> From: "Steven Hartland" To: "Adam Jacob Muller" References: <2A3A50FE-13F4-4AA7-976E-37354E5736B5@adam.gs><9D30BF6BFAFC4DA3B9564C822CA53E1A@multiplay.co.uk> <467D65E4-A4F5-4DD5-A447-EF2D6020E405@adam.gs> Date: Mon, 14 Dec 2009 09:39:24 -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.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: freebsd-stable@freebsd.org, Adam Jacob Muller Subject: Re: freebsd / gpt boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 09:49:39 -0000 The following worked for me on 8TB array: Add slices as needed (modify sizes as required): gpart add -s 128K -t freebsd-boot da0 gpart add -s 1G -t freebsd-ufs -l root da0 gpart add -s 10G -t freebsd-swap -l swap da0 gpart add ... Then for installing the bootcode: gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptboot -i 1 da0 >From re-reading you initial post the problem seems to be that its not mounting root correctly is that the case, as you don't explicitly say what the error is your getting? Regards Steve ----- Original Message ----- From: "Adam Jacob Muller" I'm assuming your referring to " FreeBSD 8 GPT install, how?" thread you originated? While that thread covers generically installing on GPT, it does not cover this issue. Also, even after adjusting a few things -- using gpart instead of gpt to make partitions and "gpart bootcode" instead of "gpt boot" which is the only difference between what these faqs suggest and what I was doing -- I am still encountering the same issue. ================================================ 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-stable@FreeBSD.ORG Mon Dec 14 10:01:02 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E54E21065679 for ; Mon, 14 Dec 2009 10:01:02 +0000 (UTC) (envelope-from n-butcher=freebsd-stable=freebsd.org=mmporwnv@fusiongol.com) Received: from smtp11.dentaku.gol.com (smtp11.dentaku.gol.com [203.216.5.73]) by mx1.freebsd.org (Postfix) with ESMTP id B492A8FC25 for ; Mon, 14 Dec 2009 10:01:02 +0000 (UTC) Received: from pat.gol.ad.jp ([203.216.1.191] helo=[172.16.1.151]) by smtp11.dentaku.gol.com with esmtpsa (Dentaku) id 1NK7jh-0004BT-18; Mon, 14 Dec 2009 19:01:01 +0900 Message-ID: <4B260CDC.5090005@fusiongol.com> Date: Mon, 14 Dec 2009 19:01:00 +0900 From: Nathan Butcher User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <20091214005717.20D6E10657A8@hub.freebsd.org> <4B25CE74.8070700@fusiongol.com> <20091214062601.E86040@maildrop.int.zabbadoz.net> In-Reply-To: <20091214062601.E86040@maildrop.int.zabbadoz.net> X-Enigmail-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV GOL (outbound) X-Abuse-Complaints: abuse@gol.com Cc: freebsd-stable@freebsd.org Subject: Re: Jails working differently in FreeBSD-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 10:01:03 -0000 > > It may sound silly but can you confirm that sshd is running inside the > jail? > Er... that was the problem. Not enabled in rc.conf Please allow me to feel embarrassed ;) From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 14:05:40 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43496106568D for ; Mon, 14 Dec 2009 14:05:40 +0000 (UTC) (envelope-from sagara@tomahawk.com.sg) Received: from us1.tomahawkonline.net (us1.tomahawkonline.net [66.98.178.56]) by mx1.freebsd.org (Postfix) with SMTP id E67C48FC2F for ; Mon, 14 Dec 2009 14:05:39 +0000 (UTC) Received: (qmail 17831 invoked from network); 14 Dec 2009 10:41:20 -0000 Received: from 116.15.193.204 (HELO ?192.168.1.64?) (sagara@tomahawk.com.sg@116.15.193.204) by us1.tomahawkonline.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 14 Dec 2009 10:41:20 -0000 Message-ID: <4B2645BB.2090004@tomahawk.com.sg> Date: Mon, 14 Dec 2009 22:03:39 +0800 From: Sagara Wijetunga User-Agent: Thunderbird 2.0.0.23 (X11/20091107) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Tomahawk Desktop 2.0 Beta1 Released X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 14:05:40 -0000 Hi FreeBSD community We are happy to announce the release of Tomahawk Desktop 2.0 Beta1. The Tomahawk Desktop is based on FreeBSD 7.2 sources. The objective of the release is, that we could not get the KDE (ver. 4.3.3) up. When try to run the KDE, the greeter crashes. Appreciate if the FreeBSD developers could help us to diagnose this issue. Tomahawk Desktop download: http://www.tomahawkcomputers.com/download.html Kind regards Sagara Wijetunga From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 14:51:34 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 450B9106566C for ; Mon, 14 Dec 2009 14:51:34 +0000 (UTC) (envelope-from kama@pvp.se) Received: from ms1.as.pvp.se (mail.pvp.se [213.64.187.227]) by mx1.freebsd.org (Postfix) with ESMTP id B8F078FC1F for ; Mon, 14 Dec 2009 14:51:33 +0000 (UTC) Received: by ms1.as.pvp.se (Postfix, from userid 1001) id ED71267; Mon, 14 Dec 2009 15:51:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by ms1.as.pvp.se (Postfix) with ESMTP id E8B6C60; Mon, 14 Dec 2009 15:51:31 +0100 (CET) Date: Mon, 14 Dec 2009 15:51:31 +0100 (CET) From: kama X-X-Sender: kama@ns1.as.pvp.se To: Ganbold In-Reply-To: <4B21159A.8020509@micom.mng.net> Message-ID: <20091214145609.J12941@ns1.as.pvp.se> References: <4B21159A.8020509@micom.mng.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: FreeBSD-STABLE Mailing List , squirrel@isot.com Subject: Re: Hacked - FreeBSD 7.1-Release X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 14:51:34 -0000 Hi! This is (most probably) a php coding issue and not e FreeBSD related issue per se. I would look into what type of application you run on your website and the permissions you have on your files. Check if there is something that can be upgraded. I know that at least phpBB2 had these issues in the past. I have seen this for years... If you take some text in from the hacked site text and search google, you will probably not be alone. You will probably also find out what application and what part of the code that are causing this. Also look into what modules that are loaded by php. If you dont need to write anything to disk or execute programs from php, disable it. You can make the files and directories that should be writable to have the write flag and disable it for the rest. Or have another user owning the files and enable write for that user. php does not use with .htaccess, so you cant rely on that. You will maybe find something in the apache access log that can make you find out what have been done. This is quite easy to do if you know what application is running and how it works. Just an example: (Tested and working) If you have something like: in filename.php. It does not seem too harmful. It will just echo the data from what being executed from a form. like 'ls'. But then you can just add to the URL something similar to: http://www.anything.tld/filename.php?a=echo%20You%20have%20been%20hacked%20%3E%20index.php Which, for clarity, represent: http://www.anything.tld/filename.php?a=echo You have been hacked > index.php This will execute exec("echo You have been hacked > index.php"); and overwrite the file. (That is if its writable and owned by the httpd process) Then if you add a shell script, using 'find . -name index.php -type f' and loop through the results, you end up with a whole site that is "hacked". I believe the script kiddie uses a more sophisticated way of executing the overwriting code. Its too easy to write dangerous code in php and you need to be careful when writing it or else something nasty will hit the fan faster than you say dr. Hfuhruhurr... /Bjorn On Thu, 10 Dec 2009, Ganbold wrote: > Squirrel wrote: > > I do have most of measure you've mentioned implemented. There is one website that is required to have register_global, which I have set on his directory/.htaccess to prevent site-wide. Currently, I'm in process of upgrading all my ports. > > > > Don't forget to check vulnerable php codes for SQL injection, LFI/RFI, > problematic file uploads etc. > > > Ganbold > > > Thanks for info. > > > > > > -----Original message----- > > From: Matthew Seaman m.seaman@infracaninophile.co.uk > > Date: Thu, 10 Dec 2009 02:24:34 -0600 > > To: squirrel@isot.com > > Subject: Re: Hacked - FreeBSD 7.1-Release > > > > > >> Squirrel wrote: > >> > >>> I've just finished the rtld patch. Now in process of regenerating > >>> all the keys and certs. Next will look into php. But far as rtld > >>> vulnerability, doesn't it require at least a local user account? > >>> Looking at all the authentication, there wasn't any authenticated > >>> session during the time frame. So I'm leaning more towards php > >>> 5.2.9, and checking all my ports. > >>> > >> You don't necessarily need to have a login session (ie. recorded in wtmp) > >> to exploit the rtld bug -- just control over some process and the ability > >> to run commands through it. Although the rtld bug is "only" a local root > >> compromise, since it is so simple to exploit it is a lot more dangerous > >> than most, and in combination with just about any form of remote exploit > >> it means your box get rooted. > >> > >> Upgrading PHP and all ports is a good move. portaudit(1) is a good idea > >> but it doesn't necessarily address the direct route your attackers used_ > >> My suspicions (in the absence of any detailed forensic examination of > >> your machine) are that you are running some vulnerable PHP code. This > >> may be part of a well known application, or it may be something locally written. > >> > >> In this case, I'd recommend a number of measures: > >> > >> * Run a security scanner like nikto (ports: security/nikto) > >> against each of the websites on your server. Do this at > >> regular intervals, and take action to fix any problems it > >> discovers. > >> > >> * Make sure that you only grant the minimum necessary permissions > >> on the filesystem to allow apache to run your applications. In > >> general, everything under your doc root should be *readable* by > >> uid www but not *writable* -- don't be seduced by the idea of > >> making the webroot owned by www:www --- root:wheel is a much > >> better idea, and files should be mode 644, directories mode 755 > >> unless there's a good reason to have them otherwise. > >> > >> * Refuse to run any PHP application that requires you to have > >> 'register_globals = YES' or to similarly poke enormous holes > >> in security through php.ini. Any application developer that > >> has not modified their code to use the $GLOBALS array by now > >> is lazy and incompetent and their code is likely to have all > >> sorts of other holes. > >> > >> * Similarly give your web application only the minimum necessary > >> permissions it needs to access any databases. You'll frequently > >> see instructions to do things like: 'GRANT ALL PRIVILEGES ON foo.* > >> TO www@localhost WITH GRANT OPTION;' This is way too much and should > >> be trimmed down. Web apps rarely have any need to make schema > >> changes, and creating other UIDs is right out, so > >> 'GRANT SELECT,INSERT,UPDATE,DELETE ON foo.* TO www@localhost' is a > >> much more reasonable starting point. > >> > >> * Where a web application has a legitimate reason to want to write > >> to the filesystem (eg. uploading files), preferably confine the > >> write access to a separate directory tree outside the web root -- > >> /tmp or /var/tmp aren't bad choices, but it might be better to > >> create a specific location for a particular application. > >> > >> * Where a web application has an administrative mode preferably > >> arrange to run this over HTTPS thus protecting any passwords > >> from snooping. If the administrative mode needs to have generic > >> read/write access to the web tree, then consider running it in a > >> completely separate Apache instance with different user credentials > >> than the generally accessible web server. > >> > >> Making the last point work with some arbitrary web application is > >> frequently challenging, but usually at least possible by a combination > >> of mod_rewrite and mod_proxy functions in the Apache config. > >> > >> Cheers, > >> > >> Matthew > >> > >> -- > >> Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard > >> Flat 3 > >> PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate > >> Kent, CT11 9PW > >> > >> > >> > >> > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > > > > > > > > > -- > I'm glad that I'm an American, I'm glad that I am free, But I wish I > were a little doggy, And McGovern were a tree. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 15:13:25 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4418B1065670 for ; Mon, 14 Dec 2009 15:13:25 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id F355E8FC0A for ; Mon, 14 Dec 2009 15:13:24 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KUN000JREA1NN50@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Mon, 14 Dec 2009 16:13:13 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KUN00GSFEA0WU70@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Mon, 14 Dec 2009 16:13:13 +0100 (CET) Date: Mon, 14 Dec 2009 16:13:12 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20091214161312.005f6e7d.torfinn.ingolfsen@broadpark.no> In-reply-to: <9D30BF6BFAFC4DA3B9564C822CA53E1A@multiplay.co.uk> References: <2A3A50FE-13F4-4AA7-976E-37354E5736B5@adam.gs> <9D30BF6BFAFC4DA3B9564C822CA53E1A@multiplay.co.uk> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.5; amd64-portbld-freebsd7.2) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: freebsd / gpt boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 15:13:25 -0000 On Sun, 13 Dec 2009 22:53:44 +0000 Steven Hartland wrote: > The only thing I'd warn you about is to ensure you use the DVD not > the CD as the CD doesn't have all the things you'll need on it. FWIW, the memstick image worked nicely, too. -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 15:17:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B482106568D for ; Mon, 14 Dec 2009 15:17:27 +0000 (UTC) (envelope-from petros.fraser@gmail.com) Received: from mail-vw0-f173.google.com (mail-vw0-f173.google.com [209.85.212.173]) by mx1.freebsd.org (Postfix) with ESMTP id 042A48FC22 for ; Mon, 14 Dec 2009 15:17:26 +0000 (UTC) Received: by vws3 with SMTP id 3so871344vws.3 for ; Mon, 14 Dec 2009 07:17:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=eg3gDBTGLjp3XCI/7r7BCTMKQfrhIXUX6u97UZzNTuw=; b=jFCPUu1v2qoex2bnB1ljVg5zlzi+Hou2ko5zjDVm28oi1ZFcZjtWt6S/A2ayhz9tNZ mMasb1yjkMVo13zTPWxhXhyX16ns8Eid081Hu0A0TRyrBUokFsOH8pUv1A0HD7D4X06S DPTgQogrJdZEErK13rRIjx1fCViD+9mRGlwwU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=gElALNFz2stJNIbUwEPWwrc7pucaYtt3Hl8aVWMSjBDaIgnv79sitzPEgLe40lireC gMh+7iEIS3DlY7Ne074JWP40zL48kFmdR8NbRiAA0fSjLdtMWcY9+k3kXBvd/3z3y0ET s/uOoZL+akxlKRfeJANKUtXKdCdW/WwkwKvR4= MIME-Version: 1.0 Received: by 10.220.124.223 with SMTP id v31mr897115vcr.89.1260802481260; Mon, 14 Dec 2009 06:54:41 -0800 (PST) Date: Mon, 14 Dec 2009 09:54:41 -0500 Message-ID: From: Peter Fraser To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Jails in FreeBSD 8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 15:17:27 -0000 Hi All I installed FBSD 8 and got some jails up using the instructions in the handbook. My question is this. Do you still have to use the alias IP address on the host that you want the jail to have? Example: I want my jail to have ip address 192.168.2.5 I put these entries in rc.conf on the host #Jail Config jail_enable="YES" jail_set_hostname_allow="NO" jail_list="www" jail_www_hostname="www.mydomain.com" jail_www_ip="192.168.2.5" jail_www_rootdir="/usr/home/jails/www" jail_www_devfs_enable="YES" Do I also need this entry below? ifconfig_vr0_alias0="inet 192.168.2.5 netmask 255.255.255.0" I'm asking because I find that if I do not put the above alias entry in, I cannot ssh in to the box and I wasn't sure if I was doing something wrong. From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 15:25:20 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85AD1106566B for ; Mon, 14 Dec 2009 15:25:20 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by mx1.freebsd.org (Postfix) with ESMTP id 1C3C78FC17 for ; Mon, 14 Dec 2009 15:25:19 +0000 (UTC) Received: by fxm28 with SMTP id 28so1457538fxm.13 for ; Mon, 14 Dec 2009 07:25:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=mAdRStBuZjpDWu0UNNjeEsU7zapKQtzYWUbB2MWiagU=; b=r9Ivytn048S0sSYIzf39/91UCH5Sg/9jC5OeXqaSnths1R0TyaASAV/zhGith5z5G9 KU2H5IFlKEr9ydAMnB8fL9znUNE5lNL5M/2mnUDzmTGpsltbZDoNUFv2iz1sgL7avz/U NoCkz/wqUlQ3r3MshwCi1INfHKsBGEvkpxUus= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=K1croOJe941WbligEIyZiae8bYf7z2VyYSVDd1Hs2ql3eaiMalvgIdo1W9M1VJEtNc Swc+zukp/cYhx/NL/CX0WeLWb4AiNpY/gCkFkwgytc+r8QE3kmELWpKhaUeZfEEqfjr0 KhChPW9t9MLju2rNhamhcaoSr6FUSjlDtbjTo= MIME-Version: 1.0 Received: by 10.223.82.16 with SMTP id z16mr5767039fak.60.1260804318780; Mon, 14 Dec 2009 07:25:18 -0800 (PST) In-Reply-To: References: Date: Mon, 14 Dec 2009 10:25:18 -0500 Message-ID: <4ad871310912140725y77537e6dj386bc05602db5a25@mail.gmail.com> From: Glen Barber To: Peter Fraser Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: Jails in FreeBSD 8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 15:25:20 -0000 Hi On Mon, Dec 14, 2009 at 9:54 AM, Peter Fraser wrote: > Hi All > > I installed FBSD 8 and got some jails up using the instructions in the > handbook. My question is this. Do you still have to use the alias IP > address on the host that you want the jail to have? > > Example: I want my jail to have ip address 192.168.2.5 > > I put these entries in rc.conf on the host > > #Jail Config > jail_enable="YES" > jail_set_hostname_allow="NO" > jail_list="www" > jail_www_hostname="www.mydomain.com" > jail_www_ip="192.168.2.5" > jail_www_rootdir="/usr/home/jails/www" > jail_www_devfs_enable="YES" > > > Do I also need this entry below? > ifconfig_vr0_alias0="inet 192.168.2.5 netmask 255.255.255.0" > No. Alternatively, you can add the following line to rc.conf: jail_www_interface="vr0" That will bind the jail (with the specified IP) to that interface. /etc/defaults/rc.conf has a good listing of all jail(8) options. Regards, -- Glen Barber From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 15:26:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A05F106568B for ; Mon, 14 Dec 2009 15:26:09 +0000 (UTC) (envelope-from prvs=1599f034ad=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 1E8218FC15 for ; Mon, 14 Dec 2009 15:26:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1260804366; x=1261409166; q=dns/txt; h=Received: Message-ID:From:To:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=DYom0zOJhViD0kTkWxxWP 62+YKVA60mHf555Avifplk=; b=VfZEQE4qQW2U/Ps0T+SlFV4R/1M1RB1Ks4x6I 7R9aZhWMYhugeBayI9RfkXujZ/Tt3xDwGdPJo/t7D9uIlHz3KkiDCl5Chtjg9Uo7 5rPbeX2PgudyiJQdo9XJow2rSioqiZE/l2xSP3IXqIUtHdTvT2k2dcVMKtMdEqEy Jz44rI= X-MDAV-Processed: mail1.multiplay.co.uk, Mon, 14 Dec 2009 15:26:06 +0000 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50008860190.msg for ; Mon, 14 Dec 2009 15:26:05 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 14 Dec 2009 15:26:05 +0000 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 213.123.247.160 X-Return-Path: prvs=1599f034ad=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <1E30C7C31AA34D5DA9E5757960A85C22@multiplay.co.uk> From: "Steven Hartland" To: "Peter Fraser" , References: Date: Mon, 14 Dec 2009 15:26:02 -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.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Subject: Re: Jails in FreeBSD 8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 15:26:09 -0000 You shouldn't need the ifconfig entry no. The default config for a jail doesn't start sshd, do you have that configured in your "jails" /etc/rc.conf? Regards Steve ----- Original Message ----- From: "Peter Fraser" ... > Do I also need this entry below? > ifconfig_vr0_alias0="inet 192.168.2.5 netmask 255.255.255.0" > > I'm asking because I find that if I do not put the above alias entry > in, I cannot ssh in to the box and I wasn't sure if I was doing > something wrong. ================================================ 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-stable@FreeBSD.ORG Mon Dec 14 15:28:54 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E715F106568F for ; Mon, 14 Dec 2009 15:28:54 +0000 (UTC) (envelope-from prvs=1599f034ad=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 742868FC0A for ; Mon, 14 Dec 2009 15:28:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1260804531; x=1261409331; q=dns/txt; h=Received: Message-ID:From:To:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=t8BqldNSbces7vbgmlIYI 4c+7opEEOCStCMlnvC44qM=; b=A2swAP4DPhFRmzRS7BL2fKv+bVV8e+9SvWz5k rAt2w1H4tB0SKM6GNbw/IRMCaNafRoiPteIoAsWGJRcZL7T83buhfXPHswGmPgF5 iWnJORlmeiaIoPtH1NdGcEENoAzqqCG10ruVYdhBFlAzX3CbTEzzTvelFIKg3qKu 1ySx/M= X-MDAV-Processed: mail1.multiplay.co.uk, Mon, 14 Dec 2009 15:28:51 +0000 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50008860201.msg for ; Mon, 14 Dec 2009 15:28:51 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 14 Dec 2009 15:28:51 +0000 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 213.123.247.160 X-Return-Path: prvs=1599f034ad=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: From: "Steven Hartland" To: "Torfinn Ingolfsen" , References: <2A3A50FE-13F4-4AA7-976E-37354E5736B5@adam.gs><9D30BF6BFAFC4DA3B9564C822CA53E1A@multiplay.co.uk> <20091214161312.005f6e7d.torfinn.ingolfsen@broadpark.no> Date: Mon, 14 Dec 2009 15:28:50 -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.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Subject: Re: freebsd / gpt boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 15:28:55 -0000 Possibly the issue we had was the live CD doesn't include dist but you cant remove it once your in it so no way to do the actual install. Using a memstick live would presumably get around this issue due to the fact you can have Disk 0 in the CDROM as well :) Regards Steve ----- Original Message ----- From: "Torfinn Ingolfsen" > On Sun, 13 Dec 2009 22:53:44 +0000 > Steven Hartland wrote: > >> The only thing I'd warn you about is to ensure you use the DVD not >> the CD as the CD doesn't have all the things you'll need on it. > > FWIW, the memstick image worked nicely, too. ================================================ 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-stable@FreeBSD.ORG Mon Dec 14 15:45:40 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51E39106566B for ; Mon, 14 Dec 2009 15:45:40 +0000 (UTC) (envelope-from petros.fraser@gmail.com) Received: from mail-vw0-f173.google.com (mail-vw0-f173.google.com [209.85.212.173]) by mx1.freebsd.org (Postfix) with ESMTP id 0776C8FC08 for ; Mon, 14 Dec 2009 15:45:39 +0000 (UTC) Received: by vws3 with SMTP id 3so879886vws.3 for ; Mon, 14 Dec 2009 07:45:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=c6OgGkp1PxJKkxTzwtYPCcIbPAsyLKtnXMRz9hVgplA=; b=Rpov+2NGArS/UHs/Y8GnATsz00gYS5H6Sv2fONYt7vwyVdbJNeeFF5NF0cMdfOE4ZM YSWuMas+LbGVuXLLo/PK5zwOPO0YvzUjQdiANT703pu2MHvqAqVY2THCe6QugCzj+tPw AwfAtQ4zeBaUs1SYcAC6jhC/MVLqSoixBTarA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=wma+Vdq6LW4+nhYE8cFno0P3pH7j+EMQ9LaHx7TOq8LC0d1U0qXZw1VMMEyhpKZR5d 1sbSjSC1tQKGORo5FZ6TWnCGoP+/IwwH8/jzsvQbGo8sMNdzKEQYYsO7nGhEm17QY035 v3S+CLXiM3TyEOmNOagBb+J7BQNufzerNmWIE= MIME-Version: 1.0 Received: by 10.220.124.223 with SMTP id v31mr907809vcr.89.1260805539186; Mon, 14 Dec 2009 07:45:39 -0800 (PST) In-Reply-To: <1E30C7C31AA34D5DA9E5757960A85C22@multiplay.co.uk> References: <1E30C7C31AA34D5DA9E5757960A85C22@multiplay.co.uk> Date: Mon, 14 Dec 2009 10:45:39 -0500 Message-ID: From: Peter Fraser To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: Jails in FreeBSD 8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 15:45:40 -0000 Yes, I do have sshd_enable=3D"YES" in the jail's rc.conf as well as network_interfaces=3D"" I can ssh in if I use the alias entry in the host's rc.conf. I'm trying another entry Glen just mentioned which is jail_www_interface=3D"vr0" to see if that works for me. On Mon, Dec 14, 2009 at 10:26 AM, Steven Hartland wrote: > You shouldn't need the ifconfig entry no. The default config for a > jail doesn't start sshd, do you have that configured in your "jails" > /etc/rc.conf? > > =A0 Regards > =A0 Steve > > ----- Original Message ----- From: "Peter Fraser" > ... >> >> Do I also need this entry below? >> ifconfig_vr0_alias0=3D"inet 192.168.2.5 netmask 255.255.255.0" >> >> I'm asking because I find that if I do not put the above alias entry >> in, I cannot ssh in to the box and I wasn't sure if I was doing >> something wrong. > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This e.mail is private and confidential between Multiplay (UK) Ltd. and t= he > person or entity to whom it is addressed. In the event of misdirection, t= he > 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-stable@FreeBSD.ORG Mon Dec 14 15:46:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6956106566B for ; Mon, 14 Dec 2009 15:46:15 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 9CE508FC13 for ; Mon, 14 Dec 2009 15:46:15 +0000 (UTC) Received: from [192.168.1.4] (adsl-156-16-112.bna.bellsouth.net [70.156.16.112]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nBEFk9Ci081670 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 14 Dec 2009 10:46:10 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Rolf G Nielsen In-Reply-To: <4B256907.4060805@lazlarlyricon.com> References: <2A3A50FE-13F4-4AA7-976E-37354E5736B5@adam.gs> <4B256907.4060805@lazlarlyricon.com> Content-Type: text/plain Organization: FreeBSD Date: Mon, 14 Dec 2009 09:46:04 -0600 Message-Id: <1260805564.2281.86.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-stable@freebsd.org, Adam Jacob Muller Subject: Re: freebsd / gpt boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 15:46:16 -0000 On Sun, 2009-12-13 at 23:21 +0100, Rolf G Nielsen wrote: > Adam Jacob Muller wrote: > > Hi, > > I'm trying to setup a system with a very large RAID array (total ~10TB), I would ideally like to have the system boot directly off that 10TB array, so i'm trying to get the system setup with GPT but running into an issue. > > > > > > The initial pre-loader (boot0 I think? -- i'm not sure what this is called) is unable to find loader at /boot/loader nor can it load /boot/kernel/kernel > > > > Is the partitioning done correctly (have you created a small boot > partition, 15 sectors is enough for booting from ufs, but the tutorials > I've found deal mainly with booting from zfs and they recommend 128 > sectors to make future bootcode changes easier)? You will need to be doing all of this from a current 8-STABLE. One bug in dealing with larger zfs raidz volumes was fixed and made it into 8.0. Another, which deals with GPT/ZFS and large volumes did not make it and only exists in 8-STABLE, iirc. Also, with the gptzfsboot code from -STABLE, it will request to load /boot/zfsloader by default (and LOADER_ZFS_SUPPORT is no longer required). > gpart add -b 34 -s 128 -t freebsd-boot -i 1 da0 > > Have you embedded the correct boot code? > > gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 da0 > (for booting from ufs). > > or > > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 > (for booting from zfs). > > You may also need to set it active by > > gpart set -a active -i 1 da0 The above step is no longer needed on -STABLE, the pmbr will be marked active when you install bootcode. robert. > And of course, substitute your arrays device node for da0 in my examples. > > > Copying /boot/loader to /loader allows me to enter /loader at the "boot:" prompt and the loader will load, however, its unable to load the kernel. > > > > If I do an "ls" at the loader prompt I can see boot listed as a directory (with a "d" before it) > > Trying to do "ls boot" inexplicably it says "boot: not a directory" > > > > re-applying my /boot/loader.conf settings (for some reason vfs.root.mountfrom=ufs:/dev/label/root is required, or else I get a mountroot>) and then: > > load /kernel > > boot > > > > does work, and lets the system boot normally and everything is as expected (/boot is a directory etc). > > > > Anyone have any ideas about either of these things (the vfs.root.mountfrom is minor i guess but i'm curious if they are related?) > > > > Thanks in advance, > > > > -Adam > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > > > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 15:52:19 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82A1F106568B for ; Mon, 14 Dec 2009 15:52:19 +0000 (UTC) (envelope-from petros.fraser@gmail.com) Received: from mail-vw0-f173.google.com (mail-vw0-f173.google.com [209.85.212.173]) by mx1.freebsd.org (Postfix) with ESMTP id 3A4EA8FC0A for ; Mon, 14 Dec 2009 15:52:18 +0000 (UTC) Received: by vws3 with SMTP id 3so881979vws.3 for ; Mon, 14 Dec 2009 07:52:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=A79OhWTxvNeHNWAzmzYQDP1s30G3Byl/WoTgeoZPsYU=; b=eUtrxQw9ZLpXu1Bvkdl5fMuBFSEq6RmqfjJyF+oIHVHVKstvV7/4oOjPdjJ85uxRjH cSynZU0+1oH53tfGEcx/JFMF1NeL0VBLdxpIrJga6kvY/srs5mvhsj9wzROPrEPCGnX9 KTFcYaIUL3i6JVRI3mzrEW7vpvXiIhRvyjQ6o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=veFtLRu/F/spk4aE6lIcXio1lw8fBcyco2tCyHib9Md5H+Keo9GkhnUCcUyLI4KdTb XmdVk8vZfI29fBacWKgu+2aXeJHNAAzhQqH11/BLab0u1yGmhmSMvWLOWdp1K6in4Hgw Ipr8lLVscsr8sGEAY9ApDVClpw9MMbYbnljHo= MIME-Version: 1.0 Received: by 10.220.122.170 with SMTP id l42mr942474vcr.33.1260805938420; Mon, 14 Dec 2009 07:52:18 -0800 (PST) In-Reply-To: References: <1E30C7C31AA34D5DA9E5757960A85C22@multiplay.co.uk> Date: Mon, 14 Dec 2009 10:52:18 -0500 Message-ID: From: Peter Fraser To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: Jails in FreeBSD 8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 15:52:19 -0000 Yes, that jail_www_interface=3D"vr0" entry worked just fine. Thank you. On Mon, Dec 14, 2009 at 10:45 AM, Peter Fraser wr= ote: > Yes, I do have sshd_enable=3D"YES" in the jail's rc.conf as well as > network_interfaces=3D"" > I can ssh in if I use the alias entry in the host's rc.conf. I'm > trying another entry Glen just mentioned which is > jail_www_interface=3D"vr0" to see if that works for me. > > On Mon, Dec 14, 2009 at 10:26 AM, Steven Hartland > wrote: >> You shouldn't need the ifconfig entry no. The default config for a >> jail doesn't start sshd, do you have that configured in your "jails" >> /etc/rc.conf? >> >> =A0 Regards >> =A0 Steve >> >> ----- Original Message ----- From: "Peter Fraser" >> ... >>> >>> Do I also need this entry below? >>> ifconfig_vr0_alias0=3D"inet 192.168.2.5 netmask 255.255.255.0" >>> >>> I'm asking because I find that if I do not put the above alias entry >>> in, I cannot ssh in to the box and I wasn't sure if I was doing >>> something wrong. >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> 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 pleas= e >> telephone +44 845 868 1337 >> or return the E.mail to postmaster@multiplay.co.uk. >> >> > From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 16:05:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 543161065670 for ; Mon, 14 Dec 2009 16:05:09 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 082618FC0C for ; Mon, 14 Dec 2009 16:05:08 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIjwJUuDaFvG/2dsb2JhbADYTIQrBA X-IronPort-AV: E=Sophos;i="4.47,395,1257138000"; d="scan'208";a="57577200" Received: from amazon.cs.uoguelph.ca ([131.104.91.198]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 14 Dec 2009 11:05:07 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id 4E7EB210130; Mon, 14 Dec 2009 11:05:07 -0500 (EST) X-Virus-Scanned: amavisd-new at amazon.cs.uoguelph.ca Received: from amazon.cs.uoguelph.ca ([127.0.0.1]) by localhost (amazon.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CTVRyJMMAwB; Mon, 14 Dec 2009 11:05:06 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id 6D101210108; Mon, 14 Dec 2009 11:05:06 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id nBEGE6h24640; Mon, 14 Dec 2009 11:14:07 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 14 Dec 2009 11:14:06 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Jeremie Le Hen In-Reply-To: <20091213230650.GA45540@felucia.tataz.chchile.org> Message-ID: References: <20091213230650.GA45540@felucia.tataz.chchile.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Cannot list a particular directory through NFS with UDP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 16:05:09 -0000 On Mon, 14 Dec 2009, Jeremie Le Hen wrote: > Hi, > > __ Please Cc: me when replying as I'm not subscribed. Thanks. __ > > My NFS server is running FreeBSD 8.0 from December 6th. The client is a > NetBSD 5.0. The directory exported is /data/repos on the server > (192.168.1.222) and is mounted on /mnt/repos on the client (192.168.1.1). > > The problem exists in /data/repos/netbsd-cvsroot/pkgsrc when using NFS > over UDP: ls(1) stalls. OTOH, for instance, listing another directory > or using NFS over TCP work flawlessly. > I'll take a look and let you know if I can think of anything. A couple of things: - What arch/net interface is the server running? - I haven't seen any issues w.r.t. i386, so I'm thinking it might be some sort of 64bit/alignment problem. (dfr@ replaced the RPC transport code with a new krpc subsystem for FreeBSD8.0 and known issues w.r.t. alignment were fixed, but there may be more) If you wanted to, you could try using the experimental server instead (-e option for mountd and nfsd), just to see if that makes the problem go away. (It handles mbuf lists/alignment somewhat differently.) Good luck with it and I'll let you know if I spot anything, rick From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 16:26:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70BF5106566C for ; Mon, 14 Dec 2009 16:26:35 +0000 (UTC) (envelope-from eugene@donpac.ru) Received: from cops.gladchenko.ru (cops.gladchenko.ru [195.161.106.100]) by mx1.freebsd.org (Postfix) with ESMTP id 6614F8FC0C for ; Mon, 14 Dec 2009 16:26:34 +0000 (UTC) Received: from cerberus.rnd.cbr.ru (cerberus.rnd.cbr.ru [194.84.224.97]) by cops.gladchenko.ru (8.14.3/8.14.3) with ESMTP id nBEFmPgq014071 for ; Mon, 14 Dec 2009 18:48:26 +0300 (MSK) (envelope-from eugene@donpac.ru) Received: from [10.10.10.2] by cerberus.rnd.cbr.ru with ESMTP id nBEFmMph047043; Mon, 14 Dec 2009 18:48:22 +0300 (MSK) (envelope-from eugene@donpac.ru) X-Antivirus: Dr.Web (R) for Mail Servers on cops.gladchenko.ru host X-AntiVirus: Checked by Dr.Web [version: 5.0, engine: 5.00.0.12182, virus records: 842935, updated: 3.12.2009] Date: Mon, 14 Dec 2009 18:48:23 +0300 From: Eugene Gladchenko X-Priority: 3 (Normal) Message-ID: <1346464638.20091214184823@donpac.ru> To: Arnaud Houdelette In-Reply-To: <4B1B8F35.4020506@tzim.net> References: <20091206104419.GA95949@home.opsec.eu> <4B1B8F35.4020506@tzim.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Antivirus-Code: 100000 X-Spam-Status: No, score=-101.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_WHITELIST autolearn=no version=3.2.5 X-Spam-Report: * -100 USER_IN_WHITELIST From: address is in the user's white-list * -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 1.1 AWL AWL: From: address is in the auto white-list X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on cops.gladchenko.ru Cc: freebsd-stable@freebsd.org, Kurt Jaeger Subject: Re: freebsd update for 8.0-REL-p1 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eugene Gladchenko List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 16:26:35 -0000 Arnaud, Sunday, December 6, 2009, 2:02:13 PM, you wrote: >> Now that the rtld patch is available, how do I upgrade using freebsd-update ? >> freebsd-update -r 8.0-RELEASE-p1 upgrade >> says: >> No mirrors remaining, giving up. >> So it does not upgrade 8-( AH> Just do : AH> freebsd-update fetch AH> then : AH> freebsd-update install Mine failed. # freebsd-update fetch Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching metadata signature for 8.0-RELEASE from update5.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. No updates needed to update system to 8.0-RELEASE-p1. # freebsd-update install No updates are available to install. Run '/usr/sbin/freebsd-update fetch' first. # uname -sr FreeBSD 8.0-RELEASE # Any thoughts on this? -- Eugene Gladchenko EVG15-RIPE From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 16:46:58 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 789D51065697 for ; Mon, 14 Dec 2009 16:46:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4A1208FC2D for ; Mon, 14 Dec 2009 16:46:58 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D358446B38; Mon, 14 Dec 2009 11:46:57 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 1A2EE8A028; Mon, 14 Dec 2009 11:46:57 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 14 Dec 2009 10:46:27 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) References: <20091213191905.GA76785@osiris.chen.org.nz> In-Reply-To: <20091213191905.GA76785@osiris.chen.org.nz> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912141046.27194.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 14 Dec 2009 11:46:57 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Subject: Re: Dell D830, nVidia and FreeBSD-8/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 16:46:58 -0000 On Sunday 13 December 2009 2:19:05 pm Jonathan Chen wrote: > Hi, > > This is a general rehash of a problem that I've been having with my > Dell Latitude D830 with an nVidia Quadro NVS 140M internal graphics > card. I've been using the XOrg's "vesa" driver ever since something in the > code rendered the "nvidia" driver inoperable in 7-STABLE sometime mid > last year. With nVidia's new 195.22 (BETA) drivers, I had hoped that I > could bypass the problem. Unfortunately, I seem to be experiencing the same > problem as described in the following thread: > > http://www.nvnews.net/vbulletin/showthread.php?t=142391 > > which appears to be implying that something in the kernel is > interfering with memory allocation. Would it be possible for someone > with deeper kernel-fu be able to take a look at this issue? Do you have a verbose dmesg available? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 16:46:59 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6CB910656B2; Mon, 14 Dec 2009 16:46:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 958398FC17; Mon, 14 Dec 2009 16:46:59 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3448046B39; Mon, 14 Dec 2009 11:46:59 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 4CC2C8A020; Mon, 14 Dec 2009 11:46:58 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 14 Dec 2009 10:50:40 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) References: <20091213230650.GA45540@felucia.tataz.chchile.org> In-Reply-To: <20091213230650.GA45540@felucia.tataz.chchile.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912141050.40340.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 14 Dec 2009 11:46:58 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Rick Macklem , Jeremie Le Hen Subject: Re: Cannot list a particular directory through NFS with UDP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 16:46:59 -0000 On Sunday 13 December 2009 6:06:50 pm Jeremie Le Hen wrote: > Hi, > > __ Please Cc: me when replying as I'm not subscribed. Thanks. __ > > My NFS server is running FreeBSD 8.0 from December 6th. The client is a > NetBSD 5.0. The directory exported is /data/repos on the server > (192.168.1.222) and is mounted on /mnt/repos on the client (192.168.1.1). > > The problem exists in /data/repos/netbsd-cvsroot/pkgsrc when using NFS > over UDP: ls(1) stalls. OTOH, for instance, listing another directory > or using NFS over TCP work flawlessly. > > "ktruss ls" shows the following: > % 26964 1 ls open(".", 0, 0) = 3 > % 26964 1 ls fcntl(0x3, 0x2, 0x1) = 0 > % 26964 1 ls fchdir(0x3) = 0 > % 26964 1 ls open(".", 0, 0) = 5 > % 26964 1 ls open(".", 0x4, 0) = 6 > % 26964 1 ls fcntl(0x6, 0x2, 0x1) = 0 > % 26964 1 ls __fstat30(0x6, 0xbfbfdef0) = 0 > % 26964 1 ls fstatvfs1(0x6, 0xbfbfdf54, 0x2) = 0 > % 26964 1 ls lseek(0x6, 0, 0, 0, 0x1) = 0 > <---------- stalls here > > > Here is a trace from the stalling ls(1). Please ask me if you need more > informations: > > 23:58:37.735792 IP (tos 0x0, ttl 64, id 48150, offset 0, flags [none], proto UDP (17), length 168) 192.168.1.1.3819288088 > 192.168.1.222.2049: 140 lookup [|nfs] > 23:58:37.736635 IP (tos 0x0, ttl 64, id 62453, offset 0, flags [none], proto UDP (17), length 264) 192.168.1.222.2049 > 192.168.1.1.3819288088: reply ok 236 lookup [|nfs] > 23:58:37.736727 IP (tos 0x0, ttl 64, id 48152, offset 0, flags [none], proto UDP (17), length 160) 192.168.1.1.3819288089 > 192.168.1.222.2049: 132 lookup [|nfs] > 23:58:37.737232 IP (tos 0x0, ttl 64, id 18881, offset 0, flags [none], proto UDP (17), length 264) 192.168.1.222.2049 > 192.168.1.1.3819288089: reply ok 236 lookup [|nfs] > 23:58:37.737411 IP (tos 0x0, ttl 64, id 48153, offset 0, flags [none], proto UDP (17), length 152) 192.168.1.1.3819288090 > 192.168.1.222.2049: 124 access [|nfs] > 23:58:37.737783 IP (tos 0x0, ttl 64, id 57308, offset 0, flags [none], proto UDP (17), length 148) 192.168.1.222.2049 > 192.168.1.1.3819288090: reply ok 120 access attr: DIR 755 ids 0/0 [|nfs] > 23:58:37.737927 IP (tos 0x0, ttl 64, id 48154, offset 0, flags [none], proto UDP (17), length 152) 192.168.1.1.3819288091 > 192.168.1.222.2049: 124 access [|nfs] > 23:58:37.738412 IP (tos 0x0, ttl 64, id 21511, offset 0, flags [none], proto UDP (17), length 148) 192.168.1.222.2049 > 192.168.1.1.3819288091: reply ok 120 access attr: DIR 755 ids 0/0 [|nfs] > 23:58:37.738477 IP (tos 0x0, ttl 64, id 48155, offset 0, flags [none], proto UDP (17), length 152) 192.168.1.1.3819288092 > 192.168.1.222.2049: 124 access [|nfs] > 23:58:37.738914 IP (tos 0x0, ttl 64, id 33831, offset 0, flags [none], proto UDP (17), length 148) 192.168.1.222.2049 > 192.168.1.1.3819288092: reply ok 120 access attr: DIR 755 ids 0/0 [|nfs] > 23:58:37.738990 IP (tos 0x0, ttl 64, id 48156, offset 0, flags [none], proto UDP (17), length 148) 192.168.1.1.3819288093 > 192.168.1.222.2049: 120 getattr [|nfs] > 23:58:37.739377 IP (tos 0x0, ttl 64, id 26761, offset 0, flags [none], proto UDP (17), length 140) 192.168.1.222.2049 > 192.168.1.1.3819288093: reply ok 112 getattr DIR 755 ids 0/0 [|nfs] > 23:58:37.740301 IP (tos 0x0, ttl 64, id 48158, offset 0, flags [none], proto UDP (17), length 168) 192.168.1.1.3819288094 > 192.168.1.222.2049: 140 readdir [|nfs] > 23:58:37.764039 IP (tos 0x0, ttl 64, id 46859, offset 0, flags [+], proto UDP (17), length 1500) 192.168.1.222.2049 > 192.168.1.1.3819288094: reply ok 1472 readdir POST: DIR 755 ids 0/0 [|nfs] > 23:58:37.764088 IP (tos 0x0, ttl 64, id 46859, offset 1480, flags [none], proto UDP (17), length 632) 192.168.1.222 > 192.168.1.1: udp > 23:58:43.353108 IP (tos 0x0, ttl 64, id 48242, offset 0, flags [none], proto UDP (17), length 168) 192.168.1.1.3819288094 > 192.168.1.222.2049: 140 readdir [|nfs] > 23:58:43.353640 IP (tos 0x0, ttl 64, id 35118, offset 0, flags [+], proto UDP (17), length 1500) 192.168.1.222.2049 > 192.168.1.1.3819288094: reply ok 1472 readdir POST: DIR 755 ids 0/0 [|nfs] > 23:58:43.353687 IP (tos 0x0, ttl 64, id 35118, offset 1480, flags [none], proto UDP (17), length 632) 192.168.1.222 > 192.168.1.1: udp > 23:58:54.587373 IP (tos 0x0, ttl 64, id 48349, offset 0, flags [none], proto UDP (17), length 168) 192.168.1.1.3819288094 > 192.168.1.222.2049: 140 readdir [|nfs] > 23:58:54.587822 IP (tos 0x0, ttl 64, id 20689, offset 0, flags [+], proto UDP (17), length 1500) 192.168.1.222.2049 > 192.168.1.1.3819288094: reply ok 1472 readdir POST: DIR 755 ids 0/0 [|nfs] > 23:58:54.587875 IP (tos 0x0, ttl 64, id 20689, offset 1480, flags [none], proto UDP (17), length 632) 192.168.1.222 > 192.168.1.1: udp > 23:59:17.045978 IP (tos 0x0, ttl 64, id 48635, offset 0, flags [none], proto UDP (17), length 168) 192.168.1.1.3819288094 > 192.168.1.222.2049: 140 readdir [|nfs] > 23:59:17.046483 IP (tos 0x0, ttl 64, id 53175, offset 0, flags [+], proto UDP (17), length 1500) 192.168.1.222.2049 > 192.168.1.1.3819288094: reply ok 1472 readdir POST: DIR 755 ids 0/0 [|nfs] > 23:59:17.046538 IP (tos 0x0, ttl 64, id 53175, offset 1480, flags [none], proto UDP (17), length 632) 192.168.1.222 > 192.168.1.1: udp > 00:00:01.953196 IP (tos 0x0, ttl 64, id 48966, offset 0, flags [none], proto UDP (17), length 168) 192.168.1.1.3819288094 > 192.168.1.222.2049: 140 readdir [|nfs] > 00:00:01.953665 IP (tos 0x0, ttl 64, id 27028, offset 0, flags [+], proto UDP (17), length 1500) 192.168.1.222.2049 > 192.168.1.1.3819288094: reply ok 1472 readdir POST: DIR 755 ids 0/0 [|nfs] > 00:00:01.953711 IP (tos 0x0, ttl 64, id 27028, offset 1480, flags [none], proto UDP (17), length 632) 192.168.1.222 > 192.168.1.1: udp It looks like the NFS client does not like the replies to the 3819288094 request. Can you grab nfsstat output before and after a retransmit of the request and reply to see which counters are increased? This might indicate why the reply is not being accepted. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 17:11:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA4E2106568B for ; Mon, 14 Dec 2009 17:11:18 +0000 (UTC) (envelope-from mattblists@icritical.com) Received: from mail1.icritical.com (mail1.icritical.com [78.33.47.172]) by mx1.freebsd.org (Postfix) with SMTP id 62B5A8FC0C for ; Mon, 14 Dec 2009 17:11:17 +0000 (UTC) Received: (qmail 18170 invoked from network); 14 Dec 2009 16:45:10 -0000 Received: from localhost (127.0.0.1) by mail1.icritical.com with SMTP; 14 Dec 2009 16:45:10 -0000 Received: (qmail 18161 invoked by uid 599); 14 Dec 2009 16:45:10 -0000 Received: from unknown (HELO icritical.com) (87.127.43.251) by mail1.icritical.com (qpsmtpd/0.28) with ESMTP; Mon, 14 Dec 2009 16:45:10 +0000 Message-ID: <4B266B8E.2090604@icritical.com> Date: Mon, 14 Dec 2009 16:45:02 +0000 From: Matt Burke User-Agent: Thunderbird 2.0.0.23 (X11/20090928) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2009 16:45:02.0579 (UTC) FILETIME=[C821D430:01CA7CDC] X-Virus-Scanned: by iCritical at mail1.icritical.com Subject: 8.0 machine won't boot single user X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 17:11:19 -0000 I have a server (Dell 2950) running 8.0-RELEASE-p1 that won't boot into single user mode - it hangs on "Trying to mount root from ufs:/dev/label/root". It hangs when using the /dev/mfid1s1a device too so it doesn't appear to be a glabel issue. Previously I had this issue booting multi-user too and the only way I could fix it was to reinstall the base distribution from CD, but this time it appears limited to single user mode. Normal boots work fine. I have built a kernel with DDB to get a backtrace, but hitting ctrl-alt-esc causes the USB keyboard to die. The machine has no PS/2 ports. After the kernel initialises the NICs, the IPMI serial-over-lan dies, presumably until rc brings the interfaces up, so I can't fire up DDB over the serial console. Setting hint.bce.N.disabled=1 at the loader prompt doesn't prevent the kernel from initialising the NICs. I don't have another machine with a physical serial port. Is there anything I can do to diagnose+fix this issue short of trying to hack sys/dev/if_bce.c to bring the interfaces up on attach? Thanks The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. Critical Software Ltd. reserves the right to monitor and record e-mail messages sent to and from this address for the purposes of investigating or detecting any unauthorised use of its system and ensuring its effective operation. Critical Software Ltd. registered in England, 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. ------------------------------------------------------------ This message has been scanned for security threats by iCritical. For further information, please visit www.icritical.com ------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 18:55:23 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CABCD1065676; Mon, 14 Dec 2009 18:55:23 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by mx1.freebsd.org (Postfix) with ESMTP id 1B15A8FC18; Mon, 14 Dec 2009 18:55:20 +0000 (UTC) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 393729400CB; Mon, 14 Dec 2009 19:55:15 +0100 (CET) Received: from endor.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp1-g21.free.fr (Postfix) with ESMTP id 50364940189; Mon, 14 Dec 2009 19:55:13 +0100 (CET) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 3BA9033E94; Mon, 14 Dec 2009 18:55:13 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 2BC9CA1280; Mon, 14 Dec 2009 18:55:13 +0000 (UTC) Date: Mon, 14 Dec 2009 19:55:13 +0100 From: Jeremie Le Hen To: John Baldwin Message-ID: <20091214185513.GC45540@felucia.tataz.chchile.org> References: <20091213230650.GA45540@felucia.tataz.chchile.org> <200912141050.40340.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200912141050.40340.jhb@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Rick Macklem , freebsd-stable@freebsd.org Subject: Re: Cannot list a particular directory through NFS with UDP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 18:55:23 -0000 On Mon, Dec 14, 2009 at 10:50:40AM -0500, John Baldwin wrote: > > It looks like the NFS client does not like the replies to the 3819288094 > request. Can you grab nfsstat output before and after a retransmit of > the request and reply to see which counters are increased? This might > indicate why the reply is not being accepted. Premices (replayed each time to have the exact same cache): # umount /mnt/repos # mount -t nfs -o intr,soft obiwan:/data/repos /mnt/repos # cd /mnt/repos/netbsd-cvsroot # ls Running ls(1) on a "good" directory shows the following difference: # ls src Server: Client: - +3 getattr - +3 getattr - +1 lookup - +1 lookup - +1 readdir - +1 readdir - +1 access - +1 access Client cache: - +9 attrcache - +2 lookupcache - +2 readdir - +2 direofcache Running ls(1) on the "bad" directory shows the following difference: # ls pkgsrc Server: Client: - +3 getattr - +3 getattr - +1 lookup - +1 lookup - +1 readdir - +1 readdir - +3 access - +3 access Client cache: - +5 attrcache - +1 lookupcache Both scenarios show no error. Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 18:57:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 419991065697 for ; Mon, 14 Dec 2009 18:57:29 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by mx1.freebsd.org (Postfix) with ESMTP id 01D878FC49 for ; Mon, 14 Dec 2009 18:57:25 +0000 (UTC) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id CB002940135; Mon, 14 Dec 2009 19:57:20 +0100 (CET) Received: from endor.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp1-g21.free.fr (Postfix) with ESMTP id E79309400E6; Mon, 14 Dec 2009 19:57:17 +0100 (CET) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id D9AA333E94; Mon, 14 Dec 2009 18:57:17 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id B223EA1280; Mon, 14 Dec 2009 18:57:17 +0000 (UTC) Date: Mon, 14 Dec 2009 19:57:17 +0100 From: Jeremie Le Hen To: Rick Macklem Message-ID: <20091214185717.GD45540@felucia.tataz.chchile.org> References: <20091213230650.GA45540@felucia.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, Jeremie Le Hen Subject: Re: Cannot list a particular directory through NFS with UDP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 18:57:29 -0000 Hi Rick, On Mon, Dec 14, 2009 at 11:14:06AM -0500, Rick Macklem wrote: > > My NFS server is running FreeBSD 8.0 from December 6th. The client is a > > NetBSD 5.0. The directory exported is /data/repos on the server > > (192.168.1.222) and is mounted on /mnt/repos on the client (192.168.1.1). > > > > The problem exists in /data/repos/netbsd-cvsroot/pkgsrc when using NFS > > over UDP: ls(1) stalls. OTOH, for instance, listing another directory > > or using NFS over TCP work flawlessly. > > > > I'll take a look and let you know if I can think of anything. > A couple of things: > - What arch/net interface is the server running? > - I haven't seen any issues w.r.t. i386, so I'm thinking it might be > some sort of 64bit/alignment problem. (dfr@ replaced the RPC transport > code with a new krpc subsystem for FreeBSD8.0 and known issues w.r.t. > alignment were fixed, but there may be more) Both are i386. > If you wanted to, you could try using the experimental server instead > (-e option for mountd and nfsd), just to see if that makes the problem > go away. (It handles mbuf lists/alignment somewhat differently.) I think I have to recompile my kernel, don't I? I tried to set nfsv4_server_enable=YES in my rc.conf, but it refused to start. Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than the others. Coluche From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 20:50:57 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61B9D1065696 for ; Mon, 14 Dec 2009 20:50:57 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f176.google.com (mail-qy0-f176.google.com [209.85.221.176]) by mx1.freebsd.org (Postfix) with ESMTP id 14E0F8FC19 for ; Mon, 14 Dec 2009 20:50:56 +0000 (UTC) Received: by qyk6 with SMTP id 6so1689522qyk.3 for ; Mon, 14 Dec 2009 12:50:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=U2RISUmH17Iwg/Ug0+4hOjMk70IEwh9mCBYXpi4/L/U=; b=RKvTFgo8hi3rt0HKV3hJg719+aT6EFR0SATHYTjChwVKmarArYVG2xWTtLmY0PU8GN FnNB2py9ysw97J5Hj+ABb5F9KBZfqkGYToPSlAW3KCgqZI2D3uk5AFj2M4gkWCZ9f81e 1uuCU3/eXVt2VtNg1SS8L4a8iVjSgdwXNDRXM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=XiIk5CU6w+iwEMeDiYEv8cdgYXSiB93JP9DGDMs5T99e2glh9eZXIhO26r3LTKr70g zu/kfE1LM58lGNlI3lJgdUx9/fPz2Uc+VXoyZWnD5+aGzRWex9+H4S1KgVeoTZb2DpzL X/l0dVVbbdPeQuLpuLBwGAvTi6dSwFOirW+kQ= Received: by 10.224.24.204 with SMTP id w12mr3287586qab.366.1260823856118; Mon, 14 Dec 2009 12:50:56 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 6sm10535468qwd.26.2009.12.14.12.50.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Dec 2009 12:50:54 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 14 Dec 2009 12:50:44 -0800 From: Pyun YongHyeon Date: Mon, 14 Dec 2009 12:50:44 -0800 To: Yoshiaki Kasahara Message-ID: <20091214205044.GB1122@michelle.cdnetworks.com> References: <20091208180836.GL1366@michelle.cdnetworks.com> <20091210215249.GG10121@michelle.cdnetworks.com> <20091211000848.GK10121@michelle.cdnetworks.com> <20091214.110137.585114676083292120.kasahara@nc.kyushu-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091214.110137.585114676083292120.kasahara@nc.kyushu-u.ac.jp> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: vge problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 20:50:57 -0000 On Mon, Dec 14, 2009 at 11:01:37AM +0900, Yoshiaki Kasahara wrote: > On Thu, 10 Dec 2009 16:08:49 -0800, > Pyun YongHyeon said: > > > While reading the code again I found some suspicious part which > > could be related with your issue. The controller's CMZ field has > > 3bits so it can handle 7 fragments of a TX frame. However, > > controller wants to see number of fragments + 1 in this field which > > means we can't use all 7 fragments in a TX descriptor. I changed > > the patch to reduce number of TX fragments to 6. Does the following > > patch make any difference for you? > > http://people.freebsd.org/~yongari/vge/vge.busdma.diff3 > > I'm sorry I was away from the console during last weekend.... > > Today I booted new kernel with diff3 patch, and did a couple of tests > (massive thumbnail loading and csup). All of them worked as expected > and no Send-Q stack observed, so I believe the problem is fixed by > this patch. > FYI: Patch committed to HEAD. From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 20:56:04 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B72D1065676 for ; Mon, 14 Dec 2009 20:56:04 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 0DB718FC14 for ; Mon, 14 Dec 2009 20:56:03 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KUN0050VU57XZ10@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Mon, 14 Dec 2009 21:55:55 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KUN00MJ5U574D71@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Mon, 14 Dec 2009 21:55:55 +0100 (CET) Date: Mon, 14 Dec 2009 21:55:55 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20091214215555.9da507b8.torfinn.ingolfsen@broadpark.no> In-reply-to: References: <2A3A50FE-13F4-4AA7-976E-37354E5736B5@adam.gs> <9D30BF6BFAFC4DA3B9564C822CA53E1A@multiplay.co.uk> <20091214161312.005f6e7d.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.5; amd64-portbld-freebsd7.2) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: freebsd / gpt boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 20:56:04 -0000 On Mon, 14 Dec 2009 15:28:50 +0000 Steven Hartland wrote: > Using a memstick live would presumably get > around this issue due to the fact you can have Disk 0 in the > CDROM as well :) Err, no. It gets around thia by the very fact that all files required are on the memstick image - no other image required. :) The machine I installed on didn't have an optical drive at all. -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 21:58:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 691771065676 for ; Mon, 14 Dec 2009 21:58:15 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 52E828FC16 for ; Mon, 14 Dec 2009 21:58:15 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBELwCOC026126; Mon, 14 Dec 2009 13:58:12 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Dec 2009 13:58:02 -0800 Message-ID: In-Reply-To: <3E18B7A0-9391-47A2-B52D-24E44DDF1A33@bangj.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 - bad neighbor solicitation messages Thread-Index: Acp6EFTbCvDBRT21S2SWjeSn+ZDmvgC9/3Kw References: <3E18B7A0-9391-47A2-B52D-24E44DDF1A33@bangj.com> From: "Li, Qing" To: "Tom Pusateri" , Cc: Subject: RE: IPv6 - bad neighbor solicitation messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 21:58:15 -0000 Please email me your routing table privately, but I am suspecting the following temporary patch would fix your issue. Please give it a try and report back. http://people.freebsd.org/~qingli/nd6-ns.diff -- Qing > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of Tom Pusateri > Sent: Thursday, December 10, 2009 7:16 PM > To: freebsd-stable@freebsd.org > Subject: IPv6 - bad neighbor solicitation messages >=20 > I'm having intermittent IPv6 issues on one FreeBSD 8-stable box. >=20 > I've tried to ping6 the FreeBSD-8 stable (crag) (as of 12/9/09) from > snow leopard (glow) and from a freebsd 7.2 box (gw). >=20 > I've tried replacing the fxp0 interface in the FreeBSD-8 stable box > with an em0 interface and it works with the FreeBSD 7.2 box but the > same problem from the Snow Leopard box. >=20 > The bad neighbor solicitation messages keep increasing with the IPv6 > pings. >=20 > Any other thing I can collect to troubleshoot? >=20 > Thanks, > Tom >=20 > glow pusateri$ ping6 crag > PING6(56=3D40+8+8 bytes) 2610:28:1800:4001:225:ff:fef1:7305 --> > 2610:28:1800:4001:20e:cff:fe9f:faad > Request timeout for icmp_seq=3D0 > Request timeout for icmp_seq=3D1 > Request timeout for icmp_seq=3D2 > Request timeout for icmp_seq=3D3 > 16 bytes from 2610:28:1800:4001:20e:cff:fe9f:faad, icmp_seq=3D4 = hlim=3D63 > time=3D0.784 ms > Request timeout for icmp_seq=3D5 > Request timeout for icmp_seq=3D6 > Request timeout for icmp_seq=3D7 > Request timeout for icmp_seq=3D8 > 16 bytes from 2610:28:1800:4001:20e:cff:fe9f:faad, icmp_seq=3D9 = hlim=3D63 > time=3D0.633 ms > Request timeout for icmp_seq=3D10 > Request timeout for icmp_seq=3D11 > Request timeout for icmp_seq=3D12 > Request timeout for icmp_seq=3D13 > 16 bytes from 2610:28:1800:4001:20e:cff:fe9f:faad, icmp_seq=3D14 = hlim=3D63 > time=3D0.654 ms > Request timeout for icmp_seq=3D15 > ^C > --- crag.foo.com ping6 statistics --- > 17 packets transmitted, 3 packets received, 82.4% packet loss > round-trip min/avg/max/std-dev =3D 0.633/0.690/0.784/0.067 ms >=20 > tcp: > 153 packets sent > 146 data packets (31776 bytes) > 3 data packets (240 bytes) retransmitted > 1 data packet unnecessarily retransmitted > 0 resends initiated by MTU discovery > 4 ack-only packets (2 delayed) > 0 URG only packets > 0 window probe packets > 0 window update packets > 0 control packets > 196 packets received > 137 acks (for 31777 bytes) > 6 duplicate acks > 0 acks for unsent data > 52 packets (4277 bytes) received in-sequence > 0 completely duplicate packets (0 bytes) > 0 old duplicate packets > 0 packets with some dup. data (0 bytes duped) > 0 out-of-order packets (0 bytes) > 0 packets (0 bytes) of data after window > 0 window probes > 0 window update packets > 0 packets received after close > 0 discarded for bad checksums > 0 discarded for bad header offset fields > 0 discarded because packet too short > 0 discarded due to memory problems > 0 connection requests > 1 connection accept > 0 bad connection attempts > 0 listen queue overflows > 0 ignored RSTs in the windows > 1 connection established (including accepts) > 4 connections closed (including 0 drops) > 0 connections updated cached RTT on close > 0 connections updated cached RTT variance on close > 0 connections updated cached ssthresh on close > 0 embryonic connections dropped > 137 segments updated rtt (of 73 attempts) > 2 retransmit timeouts > 0 connections dropped by rexmit timeout > 0 persist timeouts > 0 connections dropped by persist timeout > 0 Connections (fin_wait_2) dropped because of timeout > 0 keepalive timeouts > 0 keepalive probes sent > 0 connections dropped by keepalive > 0 correct ACK header predictions > 50 correct data packet header predictions > 1 syncache entry added > 0 retransmitted > 1 dupsyn > 0 dropped > 1 completed > 0 bucket overflow > 0 cache overflow > 0 reset > 0 stale > 0 aborted > 0 badack > 0 unreach > 0 zone failures > 1 cookie sent > 0 cookies received > 1 SACK recovery episode > 1 segment rexmit in SACK recovery episodes > 48 byte rexmits in SACK recovery episodes > 7 SACK options (SACK blocks) received > 0 SACK options (SACK blocks) sent > 0 SACK scoreboard overflow > 0 packets with ECN CE bit set > 0 packets with ECN ECT(0) bit set > 0 packets with ECN ECT(1) bit set > 0 successful ECN handshakes > 0 times ECN reduced the congestion window > udp: > 169 datagrams received > 0 with incomplete header > 0 with bad data length field > 0 with bad checksum > 0 with no checksum > 1 dropped due to no socket > 23 broadcast/multicast datagrams undelivered > 0 dropped due to full socket buffers > 0 not for hashed pcb > 145 delivered > 134 datagrams output > 0 times multicast source filter matched > sctp: > 0 input packets > 0 datagrams > 0 packets that had data > 0 input SACK chunks > 0 input DATA chunks > 0 duplicate DATA chunks > 0 input HB chunks > 0 HB-ACK chunks > 0 input ECNE chunks > 0 input AUTH chunks > 0 chunks missing AUTH > 0 invalid HMAC ids received > 0 invalid secret ids received > 0 auth failed > 0 fast path receives all one chunk > 0 fast path multi-part data > 0 output packets > 0 output SACKs > 0 output DATA chunks > 0 retransmitted DATA chunks > 0 fast retransmitted DATA chunks > 0 FR's that happened more than once to same chunk > 0 intput HB chunks > 0 output ECNE chunks > 0 output AUTH chunks > 0 ip_output error counter > Packet drop statistics: > 0 from middle box > 0 from end host > 0 with data > 0 non-data, non-endhost > 0 non-endhost, bandwidth rep only > 0 not enough for chunk header > 0 not enough data to confirm > 0 where process_chunk_drop said break > 0 failed to find TSN > 0 attempt reverse TSN lookup > 0 e-host confirms zero-rwnd > 0 midbox confirms no space > 0 data did not match TSN > 0 TSN's marked for Fast Retran > Timeouts: > 5 iterator timers fired > 0 T3 data time outs > 0 window probe (T3) timers fired > 0 INIT timers fired > 0 sack timers fired > 0 shutdown timers fired > 0 heartbeat timers fired > 0 a cookie timeout fired > 0 an endpoint changed its cookiesecret > 0 PMTU timers fired > 0 shutdown ack timers fired > 0 shutdown guard timers fired > 0 stream reset timers fired > 0 early FR timers fired > 0 an asconf timer fired > 0 auto close timer fired > 0 asoc free timers expired > 0 inp free timers expired > 0 packet shorter than header > 0 checksum error > 0 no endpoint for port > 0 bad v-tag > 0 bad SID > 0 no memory > 0 number of multiple FR in a RTT window > 0 RFC813 allowed sending > 0 RFC813 does not allow sending > 0 times max burst prohibited sending > 0 look ahead tells us no memory in interface > 0 numbers of window probes sent > 0 times an output error to clamp down on next user send > 0 times sctp_senderrors were caused from a user > 0 number of in data drops due to chunk limit reached > 0 number of in data drops due to rwnd limit reached > 0 times a ECN reduced the cwnd > 0 used express lookup via vtag > 0 collision in express lookup > 0 times the sender ran dry of user data on primary > 0 same for above > 0 sacks the slow way > 0 window update only sacks sent > 0 sends with sinfo_flags !=3D0 > 0 unordered sends > 0 sends with EOF flag set > 0 sends with ABORT flag set > 0 times protocol drain called > 0 times we did a protocol drain > 0 times recv was called with peek > 0 cached chunks used > 0 cached stream oq's used > 0 unread messages abandonded by close > 0 send burst avoidance, already max burst inflight to net > 0 send cwnd full avoidance, already max burst inflight to net > 0 number of map array over-runs via fwd-tsn's > ip: > 333 total packets received > 0 bad header checksums > 0 with size smaller than minimum > 0 with data size < data length > 0 with ip length > max ip packet size > 0 with header length < data size > 0 with data length < header length > 0 with bad options > 0 with incorrect version number > 0 fragments received > 0 fragments dropped (dup or out of space) > 0 fragments dropped after timeout > 0 packets reassembled ok > 329 packets for this host > 0 packets for unknown/unsupported protocol > 0 packets forwarded (0 packets fast forwarded) > 4 packets not forwardable > 0 packets received for unknown multicast group > 0 redirects sent > 258 packets sent from this host > 1 packet sent with fabricated ip header > 0 output packets dropped due to no bufs, etc. > 0 output packets discarded due to no route > 0 output datagrams fragmented > 0 fragments created > 0 datagrams that can't be fragmented > 0 tunneling packets that can't find gif > 0 datagrams with bad address in header > icmp: > 1 call to icmp_error > 0 errors not generated in response to an icmp message > Output histogram: > echo reply: 8 > destination unreachable: 1 > 0 messages with bad code fields > 0 messages less than the minimum length > 0 messages with bad checksum > 0 messages with bad length > 0 multicast echo requests ignored > 0 multicast timestamp requests ignored > Input histogram: > echo reply: 2 > echo: 8 > 8 message responses generated > 0 invalid return addresses > 0 no return routes > ICMP address mask responses are disabled > igmp: > 0 messages received > 0 messages received with too few bytes > 0 messages received with wrong TTL > 0 messages received with bad checksum > 0 V1/V2 membership queries received > 0 V3 membership queries received > 0 membership queries received with invalid field(s) > 0 general queries received > 0 group queries received > 0 group-source queries received > 0 group-source queries dropped > 0 membership reports received > 0 membership reports received with invalid field(s) > 0 membership reports received for groups to which we belong > 0 V3 reports received without Router Alert > 2 membership reports sent > ip6: > 185 total packets received > 0 with size smaller than minimum > 0 with data size < data length > 0 with bad options > 0 with incorrect version number > 0 fragments received > 0 fragments dropped (dup or out of space) > 0 fragments dropped after timeout > 0 fragments that exceeded limit > 0 packets reassembled ok > 53 packets for this host > 0 packets forwarded > 0 packets not forwardable > 0 redirects sent > 118 packets sent from this host > 0 packets sent with fabricated ip header > 0 output packets dropped due to no bufs, etc. > 0 output packets discarded due to no route > 0 output datagrams fragmented > 0 fragments created > 0 datagrams that can't be fragmented > 0 packets that violated scope rules > 3 multicast packets which we don't join > Input histogram: > UDP: 46 > ICMP6: 139 > Mbuf statistics: > 29 one mbuf > two or more mbuf: > lo0=3D 24 > 132 one ext mbuf > 0 two or more ext mbuf > 0 packets whose headers are not continuous > 0 tunneling packets that can't find gif > 0 packets discarded because of too many headers > 0 failures of source address selection > Source addresses selection rule applied: > 43 first candidate > 5 same address > 35 appropriate scope > icmp6: > 0 calls to icmp6_error > 0 errors not generated in response to an icmp6 message > 0 errors not generated because of rate limitation > Output histogram: > echo: 4 > echo reply: 21 > router solicitation: 3 > neighbor solicitation: 6 > neighbor advertisement: 30 > MLDv2 listener report: 12 > 0 messages with bad code fields > 0 messages < minimum length > 0 bad checksums > 0 messages with bad length > Input histogram: > echo: 21 > echo reply: 4 > router advertisement: 14 > neighbor solicitation: 69 > neighbor advertisement: 3 > redirect: 25 > Histogram of error messages to be generated: > 0 no route > 0 administratively prohibited > 0 beyond scope > 0 address unreachable > 0 port unreachable > 0 packet too big > 0 time exceed transit > 0 time exceed reassembly > 0 erroneous header field > 0 unrecognized next header > 0 unrecognized option > 0 redirect > 0 unknown > 21 message responses generated > 0 messages with too many ND options > 0 messages with bad ND options > 39 bad neighbor solicitation messages > 0 bad neighbor advertisement messages > 0 bad router solicitation messages > 0 bad router advertisement messages > 0 bad redirect messages > 0 path MTU changes > rip6: > 0 messages received > 0 checksum calculations on inbound > 0 messages with bad checksum > 0 messages dropped due to no socket > 0 multicast messages dropped due to no socket > 0 messages dropped due to full socket buffers > 0 delivered > 0 datagrams output >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable- > unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 22:31:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62BC91065703 for ; Mon, 14 Dec 2009 22:31:29 +0000 (UTC) (envelope-from usselmann.m@icg-online.de) Received: from oslo074.server4you.de (oslo074.server4you.de [62.75.178.74]) by mx1.freebsd.org (Postfix) with ESMTP id AC1A98FC23 for ; Mon, 14 Dec 2009 22:31:28 +0000 (UTC) Received: (qmail 29652 invoked from network); 14 Dec 2009 23:31:29 +0100 Received: from p54b23b42.dip.t-dialin.net (HELO icg-pc209.icg-pc213) (84.178.59.66) by oslo074.server4you.de with SMTP; 14 Dec 2009 23:31:29 +0100 Date: Mon, 14 Dec 2009 23:31:23 +0100 From: Manfred Usselmann To: freebsd-stable@freebsd.org Message-Id: <20091214233123.a5b178c2.usselmann.m@icg-online.de> In-Reply-To: <20091214081716.f6e96b85.usselmann.m@icg-online.de> References: <20091213103237.d01b51f2.usselmann.m@icg-online.de> <25ff90d60912132123x77198b1o6bfad3bffe0d01a0@mail.gmail.com> <20091214081716.f6e96b85.usselmann.m@icg-online.de> Organization: ICG IT Consulting GmbH X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.3; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: David Horn Subject: Re: duplicity ftp backup / ncftp no longer working since 8.0-Release X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 22:31:29 -0000 On Mon, 14 Dec 2009 08:17:16 +0100 Manfred Usselmann wrote: > On Mon, 14 Dec 2009 00:23:17 -0500 > David Horn wrote: > > > I believe that there is something unusual going on with the checking > > on select() return in ncftp3. If you change every instance of > > select() result checking in ftp/ncftp3 from "==1" to ">=1" the problem > > seems to go away. > > > > result = select(sfd + 1, NULL, SELECT_TYPE_ARG234 &ss, NULL, > > SELECT_TYPE_ARG5 &tv); > > -if (result == 1) { > > +if (result >= 1) { > > I will try this. Did work for me! Thanks, Manfred -- Manfred Usselmann ICG IT Consulting GmbH, Kelkheim From owner-freebsd-stable@FreeBSD.ORG Mon Dec 14 22:51:33 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52BD11065676 for ; Mon, 14 Dec 2009 22:51:33 +0000 (UTC) (envelope-from dhorn2000@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id DA97D8FC12 for ; Mon, 14 Dec 2009 22:51:32 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 19so1509941fgg.13 for ; Mon, 14 Dec 2009 14:51:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Vvit+gt3MY+82dSxdyfXpohWb4YOOxNYK+FDg3IrF/Q=; b=Zq8EmSVaNCErdrt4SjBZwNC/Zqg1OSCUJYhvmUrcF0QAYo32zYw3HYlgr4mCejKwSa ZysjO86ac7C40jEcL/g3MinfxWBV8UqwyTmaxcZwDfS7aWh8Xhf8jltXhL4Z0LnKmD0N vEd7K8Q8glhvEXU2sz78uoHO+n8yXhoHB8bEU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BKOgYtfAxKGJW6zQ2+qjOC3/oD3E0DHeOkYej0JQj0sERiLpcR2uST1J7vjhAI0Ak0 fuB+Z6p5nNZZGeVClb0jUchxtaiqyhhnw9cWdpscdHyIiFDJpi9tcNLudJ/hveF5O6m2 eJvo5EKLK0VCs0Mqnr9InKJEvlnZCf4Oyd+Hc= MIME-Version: 1.0 Received: by 10.239.156.14 with SMTP id k14mr543129hbc.181.1260831091812; Mon, 14 Dec 2009 14:51:31 -0800 (PST) In-Reply-To: <20091214233123.a5b178c2.usselmann.m@icg-online.de> References: <20091213103237.d01b51f2.usselmann.m@icg-online.de> <25ff90d60912132123x77198b1o6bfad3bffe0d01a0@mail.gmail.com> <20091214081716.f6e96b85.usselmann.m@icg-online.de> <20091214233123.a5b178c2.usselmann.m@icg-online.de> Date: Mon, 14 Dec 2009 17:51:31 -0500 Message-ID: <25ff90d60912141451y50137b09qa2d5c380093dd8d5@mail.gmail.com> From: David Horn To: Manfred Usselmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: duplicity ftp backup / ncftp no longer working since 8.0-Release X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 22:51:33 -0000 On Mon, Dec 14, 2009 at 5:31 PM, Manfred Usselmann wrote: > On Mon, 14 Dec 2009 08:17:16 +0100 > Manfred Usselmann wrote: > >> On Mon, 14 Dec 2009 00:23:17 -0500 >> David Horn wrote: >> >> > I believe that there is something unusual going on with the checking >> > on select() return in ncftp3. =A0If you change every instance of >> > select() result checking in ftp/ncftp3 from "=3D=3D1" to ">=3D1" the p= roblem >> > seems to go away. >> > >> > result =3D select(sfd + 1, NULL, SELECT_TYPE_ARG234 &ss, NULL, >> > SELECT_TYPE_ARG5 &tv); >> > -if (result =3D=3D 1) { >> > +if (result >=3D 1) { >> >> I will try this. > > Did work for me! > > Thanks, > Manfred OK. I will try to report it to the upstream (ncftp.com/contact), and failing that we could always patch as part of the ncftp 3.2.3 update into freebsd ports, but glad to hear it worked for you. ---Dave From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 00:21:45 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76C0C106566C for ; Tue, 15 Dec 2009 00:21:45 +0000 (UTC) (envelope-from prvs=16008d18ab=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 09C5A8FC1C for ; Tue, 15 Dec 2009 00:21:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1260835842; x=1261440642; q=dns/txt; h=Received: Message-ID:From:To:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=qZD8Db2pdG6t93RJFNjxC z+b9QvOxyvAxPIU0Of6U54=; b=MDYQzOu1MzZAXq49jlJOdf5IkhZbNbT3dNySI ZglFNiTsBlRsb19WjfmtGrnOwe52niWW7/9QnW3hwdYOd2MTfuYJj9QCXjByWk9B FOdeVZRNJMUnkiW7wlBpoVU9qfZT+PqaTYA94uZk0ulFfEiNLLCGCfhdyXvK0sXA PMWSbY= X-MDAV-Processed: mail1.multiplay.co.uk, Tue, 15 Dec 2009 00:10:42 +0000 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50008863818.msg for ; Tue, 15 Dec 2009 00:10:41 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 15 Dec 2009 00:10:41 +0000 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 213.123.247.160 X-Return-Path: prvs=16008d18ab=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: From: "Steven Hartland" To: "Torfinn Ingolfsen" , References: <2A3A50FE-13F4-4AA7-976E-37354E5736B5@adam.gs><9D30BF6BFAFC4DA3B9564C822CA53E1A@multiplay.co.uk><20091214161312.005f6e7d.torfinn.ingolfsen@broadpark.no> <20091214215555.9da507b8.torfinn.ingolfsen@broadpark.no> Date: Tue, 15 Dec 2009 00:10:40 -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.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Subject: Re: freebsd / gpt boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 00:21:45 -0000 ----- Original Message ----- From: "Torfinn Ingolfsen" > Err, no. It gets around thia by the very fact that all files required > are on the memstick image - no other image required. :) > The machine I installed on didn't have an optical drive at all. Noted for future reference, thanks Toffin. Regards 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-stable@FreeBSD.ORG Tue Dec 15 02:37:58 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C37711065670 for ; Tue, 15 Dec 2009 02:37:58 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from chen.org.nz (ip-58-28-152-174.static-xdsl.xnet.co.nz [58.28.152.174]) by mx1.freebsd.org (Postfix) with ESMTP id E862A8FC1A for ; Tue, 15 Dec 2009 02:37:54 +0000 (UTC) Received: by chen.org.nz (Postfix, from userid 1000) id 6D0272840B; Tue, 15 Dec 2009 15:37:51 +1300 (NZDT) Date: Tue, 15 Dec 2009 15:37:51 +1300 From: Jonathan Chen To: John Baldwin Message-ID: <20091215023751.GA6418@osiris.chen.org.nz> References: <20091213191905.GA76785@osiris.chen.org.nz> <200912141046.27194.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200912141046.27194.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Dell D830, nVidia and FreeBSD-8/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 02:37:58 -0000 On Mon, Dec 14, 2009 at 10:46:27AM -0500, John Baldwin wrote: > On Sunday 13 December 2009 2:19:05 pm Jonathan Chen wrote: > > Hi, > > > > This is a general rehash of a problem that I've been having with my > > Dell Latitude D830 with an nVidia Quadro NVS 140M internal graphics > > card. I've been using the XOrg's "vesa" driver ever since something in the > > code rendered the "nvidia" driver inoperable in 7-STABLE sometime mid > > last year. With nVidia's new 195.22 (BETA) drivers, I had hoped that I > > could bypass the problem. Unfortunately, I seem to be experiencing the same > > problem as described in the following thread: > > > > http://www.nvnews.net/vbulletin/showthread.php?t=142391 > > > > which appears to be implying that something in the kernel is > > interfering with memory allocation. Would it be possible for someone > > with deeper kernel-fu be able to take a look at this issue? > > Do you have a verbose dmesg available? I've attached a dmesg with a verbose boot. I hope this is what you're looking for. -- Jonathan Chen ---------------------------------------------------------------------- "A little learning is a dangerous thing but a lot of ignorance is just as bad." - Bob Edwards Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-STABLE #0: Fri Dec 4 08:51:58 NZDT 2009 root@jonathan.chen:/usr/obj/usr/src/sys/GENERIC amd64 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff81c45000. Preloaded elf obj module "/boot/kernel/snd_hda.ko" at 0xffffffff81c45210. Preloaded elf obj module "/boot/kernel/sound.ko" at 0xffffffff81c45838. Preloaded elf obj module "/boot/kernel/atapicam.ko" at 0xffffffff81c45ee0. Preloaded elf obj module "/boot/modules/vboxdrv.ko" at 0xffffffff81c46510. Preloaded elf obj module "/boot/modules/nvidia.ko" at 0xffffffff81c46b00. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2493767975 Hz CPU: Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz (2493.77-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Features=0xbfebfbff Features2=0x8e3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009afff, 630784 bytes (154 pages) 0x0000000001c76000 - 0x00000000d76e2fff, 3584479232 bytes (875117 pages) 0x0000000100002000 - 0x000000011ffeffff, 536797184 bytes (131054 pages) avail memory = 4098859008 (3908 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xfbb00 00024 (v2 DELL ) ACPI: XSDT 0xdfe5d200 00064 (v1 DELL M08 27D8021C ASL 00000061) ACPI: FACP 0xdfe5d09c 000F4 (v4 DELL M08 27D8021C ASL 00000061) ACPI: DSDT 0xdfe5d800 063F7 (v2 INT430 SYSFexxx 00001001 INTL 20050624) ACPI: FACS 0xdfe6c000 00040 ACPI: HPET 0xdfe5d300 00038 (v1 DELL M08 00000001 ASL 00000061) ACPI: APIC 0xdfe5d400 00068 (v1 DELL M08 27D8021C ASL 00000047) ACPI: ASF! 0xdfe5d000 0007E (v32 DELL M08 27D8021C ASL 00000061) ACPI: MCFG 0xdfe5d3c0 0003E (v16 DELL M08 27D8021C ASL 00000061) ACPI: SLIC 0xdfe5d49c 00176 (v1 DELL M08 27D8021C ASL 00000061) ACPI: TCPA 0xdfe5d700 00032 (v1 00000000 ASL 00000000) ACPI: SSDT 0xdfe5b97e 004CC (v1 PmRef CpuPm 00003000 INTL 20050624) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010400 wlan: <802.11 Link Layer> snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: io: null: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xf4000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.VID_.IGDP -> bus 0 dev 2 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.MCHP -> bus 0 dev 0 func 0 ACPI: SSDT 0xdfe6c080 00043 (v1 LMPWR DELLLOM 00001001 INTL 20050624) acpi0: wakeup code va 0xffffff800000e000 pa 0x4000 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.ISAB.PIR1 -> bus 0 dev 31 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.ISAB.PIR2 -> bus 0 dev 31 func 0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 2 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 acpi0: reservation of 0, 9f000 (3) failed acpi0: reservation of 100000, dfd5b800 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 9 10 11 Validation 0 255 N 0 9 10 11 After Disable 0 255 N 0 9 10 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 5 7 Validation 0 255 N 0 5 7 After Disable 0 255 N 0 5 7 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 9 10 11 Validation 0 255 N 0 9 10 11 After Disable 0 255 N 0 9 10 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 5 7 9 10 11 Validation 0 255 N 0 5 7 9 10 11 After Disable 0 255 N 0 5 7 9 10 11 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 9 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x2a00, revid=0x0c domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2a01, revid=0x0c domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x1a (6500 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 3 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x2834, revid=0x02 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type I/O Port, range 32, base 0x6f20, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 20 found-> vendor=0x8086, dev=0x2835, revid=0x02 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0x6f00, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x283a, revid=0x02 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=9 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfed1c400, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 22 unknown: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfed1c400 found-> vendor=0x8086, dev=0x284b, revid=0x02 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfebfc000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 21 found-> vendor=0x8086, dev=0x283f, revid=0x02 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x2841, revid=0x02 domain=0, bus=0, slot=28, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x2845, revid=0x02 domain=0, bus=0, slot=28, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=d, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x2849, revid=0x02 domain=0, bus=0, slot=28, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x2830, revid=0x02 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type I/O Port, range 32, base 0x6f80, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 20 found-> vendor=0x8086, dev=0x2831, revid=0x02 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0x6f60, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x2832, revid=0x02 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=9 map[20]: type I/O Port, range 32, base 0x6f40, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 22 found-> vendor=0x8086, dev=0x2836, revid=0x02 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfed1c000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 20 unknown: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfed1c000 found-> vendor=0x8086, dev=0x2448, revid=0xf2 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2815, revid=0x02 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2850, revid=0x02 domain=0, bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[20]: type I/O Port, range 32, base 0x6fa0, size 4, enabled pcib0: matched entry for 0.31.INTA pcib0: slot 31 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2828, revid=0x02 domain=0, bus=0, slot=31, func=2 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 3 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x6eb0, size 3, enabled map[14]: type I/O Port, range 32, base 0x6eb8, size 2, enabled map[18]: type I/O Port, range 32, base 0x6ec0, size 3, enabled map[1c]: type I/O Port, range 32, base 0x6ec8, size 2, enabled map[20]: type I/O Port, range 32, base 0x6ee0, size 4, enabled map[24]: type I/O Port, range 32, base 0xeff0, size 4, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x283e, revid=0x02 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0103, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[10]: type Memory, range 32, base 0xfebfbf00, size 8, enabled map[20]: type I/O Port, range 32, base 0x10c0, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xd000-0xdfff pcib1: memory decode 0xfa000000-0xfeafffff pcib1: prefetched decode 0xe0000000-0xefffffff pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x10de, dev=0x0429, revid=0xa1 domain=0, bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xfd000000, size 24, enabled pcib1: requested memory range 0xfd000000-0xfdffffff: good map[14]: type Prefetchable Memory, range 64, base 0xe0000000, size 28, enabled pcib1: requested memory range 0xe0000000-0xefffffff: good map[1c]: type Memory, range 64, base 0xfa000000, size 25, enabled pcib1: requested memory range 0xfa000000-0xfbffffff: good map[24]: type I/O Port, range 32, base 0xdf00, size 7, enabled pcib1: requested I/O range 0xdf00-0xdf7f: in range pcib1: matched entry for 1.0.INTA pcib1: slot 0 INTA hardwired to IRQ 16 vgapci0: port 0xdf00-0xdf7f mem 0xfd000000-0xfdffffff,0xfa000000-0xfbffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io vgapci0: Reserved 0x1000000 bytes for rid 0x10 type 3 at 0xfd000000 pcib1: vgapci0 requested memory range 0xe0000000-0xefffffff: good vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff). nvidia0: NVRM: NVIDIA MEM resource alloc failed, BAR1 @ 0x14. nvidia0: NVRM: NVIDIA hardware alloc failed. device_attach: nvidia0 attach returned 6 uhci0: port 0x6f20-0x6f3f irq 20 at device 26.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x6f20 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 49 uhci0: [MPSAFE] uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: on uhci0 uhci1: port 0x6f00-0x6f1f irq 21 at device 26.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x6f00 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 50 uhci1: [MPSAFE] uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1: on uhci1 ehci0: mem 0xfed1c400-0xfed1c7ff irq 22 at device 26.7 on pci0 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 51 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 hdac0: mem 0xfebfc000-0xfebfffff irq 21 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20091113_0138 hdac0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xfebfc000 hdac0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 52 hdac0: using IRQ 256 for MSI hdac0: [MPSAFE] hdac0: [ITHREAD] hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 pcib2: at device 28.0 on pci0 pcib2: domain 0 pcib2: secondary bus 11 pcib2: subordinate bus 11 pcib2: I/O decode 0xf000-0xfff pcib2: no prefetched decode pci11: on pcib2 pci11: domain=0, physical bus=11 pcib3: at device 28.1 on pci0 pcib3: domain 0 pcib3: secondary bus 12 pcib3: subordinate bus 12 pcib3: I/O decode 0xf000-0xfff pcib3: memory decode 0xf9f00000-0xf9ffffff pcib3: no prefetched decode pci12: on pcib3 pci12: domain=0, physical bus=12 found-> vendor=0x8086, dev=0x4229, revid=0x61 domain=0, bus=12, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf9ffe000, size 13, enabled pcib3: requested memory range 0xf9ffe000-0xf9ffffff: good pcib3: matched entry for 12.0.INTA pcib3: slot 0 INTA hardwired to IRQ 17 pci12: at device 0.0 (no driver attached) pcib4: at device 28.3 on pci0 pcib4: domain 0 pcib4: secondary bus 13 pcib4: subordinate bus 14 pcib4: I/O decode 0xc000-0xcfff pcib4: memory decode 0xf9c00000-0xf9efffff pcib4: prefetched decode 0xf0000000-0xf01fffff pci13: on pcib4 pci13: domain=0, physical bus=13 pcib5: at device 28.5 on pci0 pcib5: domain 0 pcib5: secondary bus 9 pcib5: subordinate bus 9 pcib5: I/O decode 0xf000-0xfff pcib5: memory decode 0xf9b00000-0xf9bfffff pcib5: no prefetched decode pci9: on pcib5 pci9: domain=0, physical bus=9 found-> vendor=0x14e4, dev=0x1673, revid=0x02 domain=0, bus=9, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf9bf0000, size 16, enabled pcib5: requested memory range 0xf9bf0000-0xf9bfffff: good pcib5: matched entry for 9.0.INTA pcib5: slot 0 INTA hardwired to IRQ 17 bge0: mem 0xf9bf0000-0xf9bfffff irq 17 at device 0.0 on pci9 bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xf9bf0000 bge0: adjust device control 0x2000 -> 0x5000 bge0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 257 to local APIC 0 vector 53 bge0: using IRQ 257 for MSI bge0: CHIP ID 0xa0020000; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E bge0: Disabling fastboot bge0: Disabling fastboot miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x0050ef, model 0x000c, rev. 0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: bpf attached bge0: Ethernet address: 00:1d:09:d2:d1:9e bge0: [MPSAFE] bge0: [ITHREAD] uhci2: port 0x6f80-0x6f9f irq 20 at device 29.0 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x6f80 uhci2: [MPSAFE] uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus3: on uhci2 uhci3: port 0x6f60-0x6f7f irq 21 at device 29.1 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x6f60 uhci3: [MPSAFE] uhci3: [ITHREAD] uhci3: LegSup = 0x2f00 usbus4: on uhci3 uhci4: port 0x6f40-0x6f5f irq 22 at device 29.2 on pci0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0x6f40 uhci4: [MPSAFE] uhci4: [ITHREAD] uhci4: LegSup = 0x2f00 usbus5: on uhci4 ehci1: mem 0xfed1c000-0xfed1c3ff irq 20 at device 29.7 on pci0 ehci1: [MPSAFE] ehci1: [ITHREAD] usbus6: EHCI version 1.0 usbus6: on ehci1 pcib6: at device 30.0 on pci0 pcib6: domain 0 pcib6: secondary bus 3 pcib6: subordinate bus 4 pcib6: I/O decode 0xf000-0xfff pcib6: memory decode 0xf9a00000-0xf9afffff pcib6: no prefetched decode pcib6: Subtractively decoded bridge. pci3: on pcib6 pci3: domain=0, physical bus=3 found-> vendor=0x1217, dev=0x7135, revid=0x21 domain=0, bus=3, slot=1, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0410, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0, size 12, memory disabled found-> vendor=0x1217, dev=0x00f7, revid=0x02 domain=0, bus=3, slot=1, func=4 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf9aff000, size 12, enabled pcib6: requested memory range 0xf9aff000-0xf9afffff: good map[14]: type Memory, range 32, base 0xf9afe800, size 11, enabled pcib6: requested memory range 0xf9afe800-0xf9afefff: good pcib6: matched entry for 3.1.INTA pcib6: slot 1 INTA hardwired to IRQ 19 cbb0: at device 1.0 on pci3 pcib6: cbb0 requested memory range 0x0-0xffffffffffffffff: good cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xe0700000 cbb0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xe0700000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib6: matched entry for 3.1.INTA pcib6: slot 1 INTA hardwired to IRQ 19 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 54 cbb0: [MPSAFE] cbb0: [FILTER] cbb0: Bad Vcc requested cbb0: PCI Configuration space: 0x00: 0x71351217 0x04100007 0x06070021 0x00824000 0x10: 0xe0700000 0x020000a0 0x20040403 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffd 0x30: 0x00000001 0x0000fffd 0x00000001 0x04c00113 0x40: 0x01fe1028 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x00000000 0x00000000 0x00000000 0x00000000 0x90: 0x00052404 0x00000000 0x00000000 0x00000000 0xa0: 0xfe020001 0x00c04000 0x00000015 0x0000000a 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x09004100 0x80e203ea 0x00000000 0x00400118 0xe0: 0x00820000 0x00000000 0x83000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 fwohci0: vendor=1217, dev=f7 fwohci0: vendor=1217, dev=f7 fwohci0: <1394 Open Host Controller Interface> mem 0xf9aff000-0xf9afffff,0xf9afe800-0xf9afefff irq 19 at device 1.4 on pci3 fwohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xf9aff000 fwohci0: [MPSAFE] fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 31:4f:c0:00:2a:af:68:38 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0xd76c0000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 32:4f:c0:af:68:38 fwe0: bpf attached fwe0: Ethernet address: 32:4f:c0:af:68:38 fwip0: on firewire0 fwip0: bpf attached fwip0: Firewire address: 31:4f:c0:00:2a:af:68:38 @ 0xfffe00000000, S400, maxrec 2048 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x6fa0-0x6faf irq 16 at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x6fa0 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=01 ata0: stat0=0x10 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x01 err=0x04 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=10 stat1=01 devices=0x10000 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 55 ata0: [MPSAFE] ata0: [ITHREAD] atapci1: port 0x6eb0-0x6eb7,0x6eb8-0x6ebb,0x6ec0-0x6ec7,0x6ec8-0x6ecb,0x6ee0-0x6eef,0xeff0-0xefff irq 17 at device 31.2 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x6ee0 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 56 atapci1: [MPSAFE] atapci1: [ITHREAD] atapci1: Reserved 0x10 bytes for rid 0x24 type 4 at 0xeff0 ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x6eb0 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0x6eb8 ata2: reset tp1 mask=03 ostat0=50 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x6ec0 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0x6ec8 ata3: reset tp1 mask=00 ostat0=ff ostat1=ff ata3: [MPSAFE] ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_tz0: on acpi0 psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64,0x62,0x66 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 57 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0065 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 58 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 59 uart0: [FILTER] uart0: fast interrupt cpu0: on acpi0 ACPI: SSDT 0xdfe5c4b4 002C8 (v1 PmRef Cpu0Ist 00003000 INTL 20050624) ACPI: SSDT 0xdfe5be4a 005E5 (v1 PmRef Cpu0Cst 00003001 INTL 20050624) est0: on cpu0 est0: Invalid id16 (set, cur) = (19753, 19490) est0: Can't check freq 2501, it may be invalid est0: Invalid id16 (set, cur) = (34835, 1559) est0: Can't check freq 800, it may be invalid p4tcc0: on cpu0 cpu1: on acpi0 ACPI: SSDT 0xdfe5c77c 000C4 (v1 PmRef Cpu1Ist 00003000 INTL 20050624) ACPI: SSDT 0xdfe5c42f 00085 (v1 PmRef Cpu1Cst 00003000 INTL 20050624) est1: on cpu1 est1: Invalid id16 (set, cur) = (19753, 19490) est1: Can't check freq 2501, it may be invalid est1: Invalid id16 (set, cur) = (34835, 1559) est1: Can't check freq 800, it may be invalid p4tcc1: on cpu1 ahc_isa_probe 0: ioport 0xc00 alloc failed ex_isa_identify() isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcd7ff,0xcd800-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 257745 -> 100000 procfs registered lapic: Divisor 2, Frequency 99750723 hz Timecounter "TSC" frequency 2493767975 Hz quality -100 Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0xe1 offMax=0x20d lo0: bpf attached hptrr: no controller detected. ata0: Identifying devices: 00010000 ata0: New devices: 00010000 firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 480Mbps High Speed USB v2.0 ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acpi_acad0: acline initialization startacd0: setting PIO4 on ICH8M chip acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 timesacd0: setting UDMA33 on ICH8M chip battery0: battery initialization start battery1: battery initialization start ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 acd0: DVDR drive at ata0 as master acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, DVDR, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata2: Identifying devices: 00000001 ata2: New devices: 00000001 ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 190782MB at ata2-master SATA300 ad4: 390721968 sectors [387621C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad4 ad4: Intel check1 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed ata3: Identifying devices: 00000000 ata3: New devices: 00000000 hdac0: Probing codec #0... hdac0: HDA Codec #0: Sigmatel STAC9205X hdac0: HDA Codec ID: 0x838476a0 hdac0: Vendor: 0x8384 hdac0: Device: 0x76a0 hdac0: Revision: 0x02 hdac0: Stepping: 0x04 hdac0: PCI Subvendor: 0x01fe1028 hdac0: Found audio FG nid=1 startnode=10 endnode=38 total=28 hdac0: hdac0: Processing audio FG cad=0 nid=1... hdac0: GPIO: 0xc0000005 NumGPIO=5 NumGPO=0 NumGPI=0 GPIWake=1 GPIUnsol=1 hdac0: nid 10 0x0321101f as 1 seq 15 Headphones Jack jack 1 loc 3 color Black misc 0 hdac0: nid 11 0x0381102e as 2 seq 14 Line-in Jack jack 1 loc 3 color Black misc 0 hdac0: nid 12 0x90a70120 as 2 seq 0 Mic Fixed jack 7 loc 16 color Unknown misc 1 hdac0: nid 13 0x90170110 as 1 seq 0 Speaker Fixed jack 7 loc 16 color Unknown misc 1 hdac0: nid 14 0x40f000f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 0 hdac0: nid 15 0x40f000f1 as 15 seq 1 Other None jack 0 loc 0 color Unknown misc 0 hdac0: nid 20 0x40f000f2 as 15 seq 2 Other None jack 0 loc 0 color Unknown misc 0 hdac0: nid 22 0x40f000f3 as 15 seq 3 Other None jack 0 loc 0 color Unknown misc 0 hdac0: nid 23 0x40f000f4 as 15 seq 4 Other None jack 0 loc 0 color Unknown misc 0 hdac0: nid 24 0x40f000f5 as 15 seq 5 Other None jack 0 loc 0 color Unknown misc 0 hdac0: nid 33 0x40f000f6 as 15 seq 6 Other None jack 0 loc 0 color Unknown misc 0 hdac0: nid 34 0x40f000f7 as 15 seq 7 Other None jack 0 loc 0 color Unknown misc 0 hdac0: Patched pins configuration: hdac0: nid 10 0x0321101f as 1 seq 15 Headphones Jack jack 1 loc 3 color Black misc 0 hdac0: nid 11 0x0381102e as 2 seq 14 Line-in Jack jack 1 loc 3 color Black misc 0 hdac0: nid 12 0x90a70120 as 2 seq 0 Mic Fixed jack 7 loc 16 color Unknown misc 1 hdac0: nid 13 0x90170110 as 1 seq 0 Speaker Fixed jack 7 loc 16 color Unknown misc 1 hdac0: nid 14 0x40f000f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 0 [DISABLED] hdac0: nid 15 0x40f000f1 as 15 seq 1 Other None jack 0 loc 0 color Unknown misc 0 [DISABLED] hdac0: nid 20 0x40f000f2 as 15 seq 2 Other None jack 0 loc 0 color Unknown misc 0 [DISABLED] hdac0: nid 22 0x40f000f3 as 15 seq 3 Other None jack 0 loc 0 color Unknown misc 0 [DISABLED] hdac0: nid 23 0x40f000f4 as 15 seq 4 Other None jack 0 loc 0 color Unknown misc 0 [DISABLED] hdac0: nid 24 0x40f000f5 as 15 seq 5 Other None jack 0 loc 0 color Unknown misc 0 [DISABLED] hdac0: nid 33 0x40f000f6 as 15 seq 6 Other None jack 0 loc 0 color Unknown misc 0 [DISABLED] hdac0: nid 34 0x40f000f7 as 15 seq 7 Other None jack 0 loc 0 color Unknown misc 0 [DISABLED] hdac0: 2 associations found: hdac0: Association 0 (1) out: hdac0: Pin nid=13 seq=0 hdac0: Pin nid=10 seq=15 hdac0: Association 1 (2) in: hdac0: Pin nid=12 seq=0 hdac0: Pin nid=11 seq=14 hdac0: Tracing association 0 (1) hdac0: Pin 13 traced to DAC 16 hdac0: Pin 10 traced to DAC 16 and hpredir 0 hdac0: Association 0 (1) trace succeeded hdac0: Tracing association 1 (2) hdac0: Pin 12 traced to ADC 18 hdac0: Pin 11 traced to ADC 18 hdac0: Association 1 (2) trace succeeded hdac0: Tracing input monitor hdac0: Tracing beeper hdac0: Enabling headphone/speaker audio routing switching: hdac0: as=0 sense nid=10 [UNSOL] hdac0: Pin sense: nid=10 res=0xffffffff hdac0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref hdac0: hdac0: +-------------------+ hdac0: | DUMPING HDA NODES | hdac0: +-------------------+ hdac0: hdac0: Default Parameter hdac0: ----------------- hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e07e0 hdac0: 16 20 24 bits, 44 48 88 96 176 192 KHz hdac0: IN amp: 0x00050f00 hdac0: OUT amp: 0x80027f7f hdac0: hdac0: nid: 10 hdac0: Name: pin: Headphones (Black Jack) hdac0: Widget cap: 0x00400181 hdac0: UNSOL STEREO hdac0: Association: 0 (0x00008000) hdac0: Pin cap: 0x0000173f hdac0: ISC TRQD PDC HP OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x0321101f hdac0: Pin control: 0x000000c0 HP OUT hdac0: connections: 2 hdac0: | hdac0: + <- nid=16 [audio output] (selected) hdac0: + [DISABLED] <- nid=17 [audio output] [DISABLED] hdac0: hdac0: nid: 11 hdac0: Name: pin: Line-in (Black Jack) hdac0: Widget cap: 0x00400181 hdac0: UNSOL STEREO hdac0: Association: 1 (0x00004000) hdac0: OSS: line (line) hdac0: Pin cap: 0x00001737 hdac0: ISC TRQD PDC OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x0381102e hdac0: Pin control: 0x00000024 IN VREFs hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=16 [audio output] (selected) hdac0: + [DISABLED] <- nid=17 [audio output] [DISABLED] hdac0: hdac0: nid: 12 hdac0: Name: pin: Mic (Fixed) hdac0: Widget cap: 0x00400181 hdac0: UNSOL STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: monitor (monitor) hdac0: Pin cap: 0x00001737 hdac0: ISC TRQD PDC OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x90a70120 hdac0: Pin control: 0x00000024 IN VREFs hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=17 [audio output] [DISABLED] hdac0: hdac0: nid: 13 hdac0: Name: pin: Speaker (Fixed) hdac0: Widget cap: 0x00400181 hdac0: UNSOL STEREO hdac0: Association: 0 (0x00000001) hdac0: Pin cap: 0x0000003f hdac0: ISC TRQD PDC HP OUT IN hdac0: Pin config: 0x90170110 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=16 [audio output] hdac0: hdac0: nid: 14 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400181 hdac0: UNSOL STEREO hdac0: Pin cap: 0x00001737 hdac0: ISC TRQD PDC OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x40f000f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=16 [audio output] hdac0: hdac0: nid: 15 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400181 hdac0: UNSOL STEREO hdac0: Pin cap: 0x00001737 hdac0: ISC TRQD PDC OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x40f000f1 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=17 [audio output] [DISABLED] hdac0: hdac0: nid: 16 hdac0: Name: audio output hdac0: Widget cap: 0x000d0c05 hdac0: LRSWAP PWR STEREO hdac0: Association: 0 (0x00008001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e07e0 hdac0: 16 20 24 bits, 44 48 88 96 176 192 KHz hdac0: Output amp: 0x80027f7f hdac0: mute=1 step=127 size=2 offset=127 hdac0: hdac0: nid: 17 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x000d0c05 hdac0: LRSWAP PWR STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e07e0 hdac0: 16 20 24 bits, 44 48 88 96 176 192 KHz hdac0: Output amp: 0x80027f7f hdac0: mute=1 step=127 size=2 offset=127 hdac0: hdac0: nid: 18 hdac0: Name: audio input hdac0: Widget cap: 0x001d0541 hdac0: PWR PROC STEREO hdac0: Association: 1 (0x00004001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e07e0 hdac0: 16 20 24 bits, 44 48 88 96 176 192 KHz hdac0: connections: 1 hdac0: | hdac0: + <- nid=29 [audio selector] hdac0: hdac0: nid: 19 [DISABLED] hdac0: Name: audio input hdac0: Widget cap: 0x001d0541 hdac0: PWR PROC STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e07e0 hdac0: 16 20 24 bits, 44 48 88 96 176 192 KHz hdac0: connections: 1 hdac0: | hdac0: + <- nid=30 [audio selector] [DISABLED] hdac0: hdac0: nid: 20 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x0040010c hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x40f000f2 hdac0: Pin control: 0x00000000 hdac0: Output amp: 0x80051f1f hdac0: mute=1 step=31 size=5 offset=31 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=21 [audio mixer] [DISABLED] hdac0: hdac0: nid: 21 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x00200100 hdac0: connections: 1 hdac0: | hdac0: + <- nid=16 [audio output] hdac0: hdac0: nid: 22 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400001 hdac0: STEREO hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x40f000f3 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 23 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400001 hdac0: STEREO hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x40f000f4 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 24 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400001 hdac0: STEREO hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x40f000f5 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 25 hdac0: Name: audio selector hdac0: Widget cap: 0x0030010d hdac0: STEREO hdac0: Association: 1 (0x00004001) hdac0: OSS: line, monitor hdac0: Output amp: 0x00270400 hdac0: mute=0 step=4 size=39 offset=0 hdac0: connections: 7 hdac0: | hdac0: + [DISABLED] <- nid=14 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=22 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=15 [pin: Other (None)] [DISABLED] hdac0: + <- nid=11 [pin: Line-in (Black Jack)] hdac0: + <- nid=12 [pin: Mic (Fixed)] (selected) hdac0: + [DISABLED] <- nid=13 [pin: Speaker (Fixed)] hdac0: + [DISABLED] <- nid=10 [pin: Headphones (Black Jack)] hdac0: hdac0: nid: 26 [DISABLED] hdac0: Name: audio selector hdac0: Widget cap: 0x0030010d hdac0: STEREO hdac0: Output amp: 0x00270400 hdac0: mute=0 step=4 size=39 offset=0 hdac0: connections: 7 hdac0: | hdac0: + [DISABLED] <- nid=14 [pin: Other (None)] [DISABLED] (selected) hdac0: + [DISABLED] <- nid=22 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=15 [pin: Other (None)] [DISABLED] hdac0: + <- nid=11 [pin: Line-in (Black Jack)] hdac0: + <- nid=12 [pin: Mic (Fixed)] hdac0: + <- nid=13 [pin: Speaker (Fixed)] hdac0: + <- nid=10 [pin: Headphones (Black Jack)] hdac0: hdac0: nid: 27 hdac0: Name: audio selector hdac0: Widget cap: 0x00300103 hdac0: STEREO hdac0: Association: 1 (0x00004001) hdac0: OSS: line, monitor hdac0: Input amp: 0x00050f00 hdac0: mute=0 step=15 size=5 offset=0 hdac0: connections: 1 hdac0: | hdac0: + <- nid=25 [audio selector] hdac0: hdac0: nid: 28 [DISABLED] hdac0: Name: audio selector hdac0: Widget cap: 0x00300103 hdac0: STEREO hdac0: Input amp: 0x00050f00 hdac0: mute=0 step=15 size=5 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=26 [audio selector] [DISABLED] hdac0: hdac0: nid: 29 hdac0: Name: audio selector hdac0: Widget cap: 0x0030090d hdac0: LRSWAP STEREO hdac0: Association: 1 (0x00004001) hdac0: OSS: line, monitor hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 3 hdac0: | hdac0: + <- nid=27 [audio selector] (selected) hdac0: + [DISABLED] <- nid=23 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=24 [pin: Other (None)] [DISABLED] hdac0: hdac0: nid: 30 [DISABLED] hdac0: Name: audio selector hdac0: Widget cap: 0x0030090d hdac0: LRSWAP STEREO hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 3 hdac0: | hdac0: + <- nid=28 [audio selector] [DISABLED] (selected) hdac0: + [DISABLED] <- nid=23 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=24 [pin: Other (None)] [DISABLED] hdac0: hdac0: nid: 31 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00040211 hdac0: DIGITAL STEREO hdac0: Stream cap: 0x00000005 hdac0: AC3 PCM hdac0: PCM cap: 0x000e05e0 hdac0: 16 20 24 bits, 44 48 88 96 192 KHz hdac0: hdac0: nid: 32 [DISABLED] hdac0: Name: audio input hdac0: Widget cap: 0x00140311 hdac0: DIGITAL STEREO hdac0: Stream cap: 0x00000005 hdac0: AC3 PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=34 [pin: Other (None)] [DISABLED] hdac0: hdac0: nid: 33 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400301 hdac0: DIGITAL STEREO hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x40f000f6 hdac0: Pin control: 0x00000000 hdac0: connections: 3 hdac0: | hdac0: + <- nid=31 [audio output] [DISABLED] (selected) hdac0: + <- nid=29 [audio selector] hdac0: + <- nid=30 [audio selector] [DISABLED] hdac0: hdac0: nid: 34 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00430681 hdac0: PWR DIGITAL UNSOL STEREO hdac0: Pin cap: 0x00010024 hdac0: PDC IN EAPD hdac0: Pin config: 0x40f000f7 hdac0: Pin control: 0x00000000 hdac0: EAPD: 0x00000002 hdac0: hdac0: nid: 35 hdac0: Name: beep widget hdac0: Widget cap: 0x0070000c hdac0: Association: -2 (0x00000000) hdac0: OSS: speaker (speaker) hdac0: Output amp: 0x00170303 hdac0: mute=0 step=3 size=23 offset=3 hdac0: hdac0: nid: 36 [DISABLED] hdac0: Name: volume widget hdac0: Widget cap: 0x00600000 hdac0: connections: 2 hdac0: | hdac0: + <- nid=16 [audio output] (selected) hdac0: + <- nid=17 [audio output] [DISABLED] hdac0: hdac0: nid: 37 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00001 hdac0: STEREO hdac0: pcm0: at cad 0 nid 1 on hdac0 pcm0: +--------------------------------------+ pcm0: | DUMPING PCM Playback/Record Channels | pcm0: +--------------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e07e0 pcm0: 16 20 24 bits, 44 48 88 96 176 192 KHz pcm0: DAC: 16 pcm0: pcm0: Record: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e07e0 pcm0: 16 20 24 bits, 44 48 88 96 176 192 KHz pcm0: ADC: 18 pcm0: pcm0: +-------------------------------+ pcm0: | DUMPING Playback/Record Paths | pcm0: +-------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: nid=10 [pin: Headphones (Black Jack)] pcm0: | pcm0: + <- nid=16 [audio output] [src: pcm] pcm0: pcm0: nid=13 [pin: Speaker (Fixed)] pcm0: | pcm0: + <- nid=16 [audio output] [src: pcm] pcm0: pcm0: Record: pcm0: pcm0: nid=18 [audio input] pcm0: | pcm0: + <- nid=29 [audio selector] [src: line, monitor] pcm0: | pcm0: + <- nid=27 [audio selector] [src: line, monitor] pcm0: | pcm0: + <- nid=25 [audio selector] [src: line, monitor] pcm0: | pcm0: + <- nid=11 [pin: Line-in (Black Jack)] [src: line] pcm0: + <- nid=12 [pin: Mic (Fixed)] [src: monitor] pcm0: pcm0: +-------------------------+ pcm0: | DUMPING Volume Controls | pcm0: +-------------------------+ pcm0: pcm0: Master Volume (OSS: vol) pcm0: | pcm0: +- ctl 1 (nid 16 out): -95/0dB (128 steps) + mute pcm0: pcm0: PCM Volume (OSS: pcm) pcm0: | pcm0: +- ctl 1 (nid 16 out): -95/0dB (128 steps) + mute pcm0: pcm0: Speaker/Beep Volume (OSS: speaker) pcm0: | pcm0: +- ctl 10 (nid 35 out): -18/0dB (4 steps) pcm0: pcm0: Recording Level (OSS: rec) pcm0: | pcm0: +- ctl 4 (nid 25 out): 0/40dB (5 steps) pcm0: +- ctl 6 (nid 27 in 0): 0/22dB (16 steps) pcm0: +- ctl 8 (nid 29 out): mute pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "rec": pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap 33e0000, 4000; 0xffffff8075892000 -> 33e0000 pcm0: sndbuf_setmap 33f0000, 4000; 0xffffff80758a2000 -> 33f0000 ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010400 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 1 vector 48 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 1 vector 49 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 1 vector 50 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 1 vector 51 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 1 vector 52 msi: Assigning MSI IRQ 257 to local APIC 1 vector 53 Root mount waiting for: usbus6 usbus5 usbus4 usbus3 usbus2 usbus1 usbus0 uhub1: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered Root mount waiting for: usbus6 usbus2 uhub2: 4 ports with 4 removable, self powered uhub6: 6 ports with 6 removable, self powered Root mount waiting for: usbus6 Root mount waiting for: usbus6 Trying to mount root from ufs:/dev/ad4s3a acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata0:0:0:0): error 22 (probe0:ata0:0:0:0): Unretryable Error (probe0:ata0:0:0:0): Down reving Protocol Version from 2 to 0? ct_to_ts([2009-12-15 02:29:20]) = 1260844160.000000000 start_init: trying /sbin/init (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): CAM Status: SCSI Status Error (probe0:ata0:0:0:0): SCSI Status: Check Condition (probe0:ata0:0:0:0): NOT READY asc:3a,0 (probe0:ata0:0:0:0): Medium not present (probe0:ata0:0:0:0): (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): NOT READY asc:3a,0 (probe0:ata0:0:0:0): Medium not present Unretryable error (probe0:ata0:0:0:0): error 6 (probe0:ata0:0:0:0): Unretryable Error GEOM: new disk cd0pass0 at ata0 bus 0 scbus0 target 0 lun 0 pass0: Removable CD-ROM SCSI-0 device pass0: 33.000MB/s transfers (cd0:ata0:0:0:0): error 6 (cd0:ata0:0:0:0): Unretryable Error cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present (cd0:ata0:0:0:0): error 6 (cd0:ata0:0:0:0): Unretryable Error (cd0:ata0:0:0:0): error 6 (cd0:ata0:0:0:0): Unretryable Error ugen5.2: at usbus5 uhub7: on usbus5 ugen3.2: at usbus3 ukbd0: on usbus3 ugen4.2: at usbus4 ums0: on usbus4 kbd2 at ukbd0 kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 ums0: 3 buttons and [XYZ] coordinates ID=0 uhub7: 4 ports with 3 removable, self powered Linux ELF exec handler installed linprocfs registered ugen5.3: at usbus5 bge0: Disabling fastboot bge0: Disabling fastboot bge0: link UP ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding disabled, default to deny, logging disabled ts_to_ct(1260844173.716578676) = [2009-12-15 02:29:33] fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 04:53:47 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4D3A106568F; Tue, 15 Dec 2009 04:53:47 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 83E428FC1F; Tue, 15 Dec 2009 04:53:47 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBF4rlDj015247; Mon, 14 Dec 2009 20:53:47 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Dec 2009 20:53:41 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: patch: bad ipv6 neighbor solicitation Thread-Index: Acp9CYAEfe0QuEo9RaSvMCfLPriRwAABmAT5AAo0PKA= References: <9223.83.206.131.26.1260781902.squirrel@webmail.esigetel.fr> From: "Li, Qing" To: , Cc: Subject: patch: bad ipv6 neighbor solicitation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 04:53:47 -0000 Please find the more proper fix at http://people.freebsd.org/~qingli/nd6-patch.diff I realized I was slightly off in my previous email after I spent a bit more time looking through the problem.=20 Both prefixes are present but one was marked off-link due to the fact only a single prefix route was installed in the routing table (non RADIX_MPATH system). I evaluated various options to fixing this issue, however,=20 due to the association between NDPRF_ONLINK and the route installation, I decided to go with what I have here for the time being. I have verified the fix in my setup. Please apply the patch and report back. Thanks, -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Li, Qing > Sent: Monday, December 14, 2009 3:00 PM > To: Dennis Glatting; JASSAL Aman > Cc: freebsd-net@freebsd.org > Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) >=20 >=20 > You don't need to perform all that route-foo. I believe the root cause > of > this issue may be due to a bit of regression in the IPv6 prefix > management > code, and I am in the process of putting together a permanent fix. >=20 > The issue as it stands today, is due to how the prefix was inserted in > the first place. Since bce0 was configured first, the interface > associated > with the prefix is bce0. Later the reference count on the prefix is > simply incremented when bce1 configures another IPv6 address of the > same prefix. >=20 > When ND6 NS arrives for bce1, due to the interface mismatch of the > prefix > interface against the input interface, the NS packet was considered > invalid and thus dropped. >=20 > Again, in case you didn't see my earlier reply, try the temporary hack > at > http://people.freebsd.org/~qingli/nd6-ns.diff >=20 > until I commit a permanent patch. The problem was easily reproducible > and > I have verified with limited unit testing the patch works. >=20 > -- Qing >=20 >=20 > -----Original Message----- > From: owner-freebsd-net@freebsd.org on behalf of Dennis Glatting > Sent: Mon 12/14/2009 2:03 PM > To: JASSAL Aman > Cc: freebsd-net@freebsd.org > Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) >=20 >=20 > Thanks. Responses in-line. >=20 >=20 >=20 > On Mon, 14 Dec 2009, JASSAL Aman wrote: >=20 > > Hello Mr.Glatting, > > > > Not that I'm an IPv6 genius, but at first sight your problem seems to > be a > > route-related. I've put comments in-line. > > > > > > Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : > >> > >> > >> Elmer# netstat -rn > >> Routing tables > >> > >> > >> Internet6: > >> Destination Gateway > Flags > >> Netif Expire > >> ::/96 ::1 UGRS > >> lo0 =3D> default fd7c:3f2b:e791:1::1 > >> UGS bce0 > >> ::1 ::1 UH > >> lo0 ::ffff:0.0.0.0/96 ::1 > UGRS > >> lo0 fd7c:3f2b:e791:1::/64 link#1 > U > >> bce0 fd7c:3f2b:e791:1::ac13:a0a link#1 > UHS > >> lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 > UHS > >> lo0 fe80::/10 ::1 > UGRS > >> lo0 fe80::%bce0/64 link#1 > U > >> bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 > UHS > >> lo0 fe80::%bce1/64 link#2 > U > >> bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 > UHS > >> lo0 fe80::%lo0/64 link#3 > U > >> lo0 fe80::1%lo0 link#3 > UHS > >> lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 > U > >> bce0 ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a > U > >> bce1 ff01:3::/32 ::1 > U > >> lo0 ff02::/16 ::1 > UGRS > >> lo0 ff02::%bce0/32 fe80::213:72ff:fe60:ac52%bce0 > U > >> bce0 ff02::%bce1/32 fd7c:3f2b:e791:1:0:1:ac13:a0a > U > >> bce1 ff02::%lo0/32 ::1 > U > >> lo0 > >> > > > > Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was > > expecting bce1 rather than lo0, I suppose you were as well :) If I'm > not > > mistaken, the packets emanating from bce1 go to the loopback > interface, > > thus not really going out. You can try specifying the route manually > > with "route add *your parameters*" or even set it in /etc/rc.conf so > > that it's loaded at boot-time. There's no reason why among 2 physical > > interfaces sharing the same fabric, one can ship packets out and the > > other can't. > > >=20 > I was wondering about the route however I haven't figured out the trick > to > get what I want. For example: >=20 > Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a > delete host fd7c:3f2b:e791:1:0:1:ac13:a0a >=20 > Elmer# route add > -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 > route: writing to routing socket: File exists > add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route already > in table >=20 > I did delete the lo0 route before I exected the above command. Also, I > haven't been able to specify a higher metric (e.g., -metric 2). That is > rejected too. However, I can say: >=20 > Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a > delete host fd7c:3f2b:e791:1:0:1:ac13:a0a >=20 > Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a -iface bce1 > add host fd7c:3f2b:e791:1:0:1:ac13:a0a: gateway bce1 >=20 > Elmer# netstat -rn > (snip) > fd7c:3f2b:e791:1:0:1:ac13:a0a 00:13:72:60:ac:50 UHS > bce1 >=20 > I don't think that is what I want. WHat I think I just said is "host X" > is > out that door, rather than route net. If, however, I say Docs is out > that > door, I get: >=20 > Elmer# route add -inet6 docs.dco.penx.com -iface bce1 > add host docs.dco.penx.com: gateway bce1 >=20 > Elmer# ping6 > docs.penx.com > PING6(56=3D40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> > fd7c:3f2b:e791:1::ac13:a15 > ping6: sendmsg: Operation not permitted > ping6: wrote docs.dco.penx.com 16 chars, ret=3D-1 >=20 >=20 > >> > >> Elmer's rc.config: > >> > >> > >> ipv6_enable=3D"YES" ipv6_network_interfaces=3D"bce0 bce1" > >> ipv6_ifconfig_bce0=3D"FD7C:3F2B:E791:0001::0:172.19.10.10 prefixlen > 64" > >> ipv6_ifconfig_bce1=3D"FD7C:3F2B:E791:0001::1:172.19.10.10 prefixlen 64 > mtu > >> 8192" > >> ipv6_defaultrouter=3D"FD7C:3F2B:E791:0001::1" > >> > > > > Erm... You're using IPv4 addresses encapsulated in IPv6 ? I've never > used > > this myself so I can't really comment, and I can't say if there > aren't any > > sort of "interferences" with what you're trying to do. > > >=20 > I hope what I am specifying is to use the 32 bit IPv4 address as the > last > 32 bits of the IPv6 address, at least that is how it works out > numerically. My numbering scheme for fixed assets is the last 32 bits > of > the 128 bit IPv6 address is the same as its IPv4 address. >=20 >=20 > >> > >> > >> The router (cisco): > >> > >> > >> interface GigabitEthernet0/0 ipv6 address FD7C:3F2B:E791:1::1/64 > ipv6 > >> enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) > >> > > > > Just a side-note, I'm not sure if it will be really useful to you, > but you > > could give it a try if you want to. Have you tried using your Cisco > router > > as a Router Advertisement Daemon ? That way, addresses would be built > > automatically and you could see how both interfaces react to such > > advertisements. > > > > I hope this helps. > > > > ------------ > > Aman Jassal > > > > Wisdom comes from experience. > > Experience comes from a lack of wisdom. > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 10:19:57 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFC8C1065676 for ; Tue, 15 Dec 2009 10:19:57 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id C15178FC0A for ; Tue, 15 Dec 2009 10:19:57 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 1090EC5740; Tue, 15 Dec 2009 05:19:57 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 15 Dec 2009 05:19:57 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=PqfqU0ZhrMhD6g71MJ+Zew5YVj8=; b=sTzOGxYwnRPFYQLZ2VctSfIGKbsi/doVKY7uM//g9+0+eLDDHTIkVnl2n4bDiubImZw/HTNGiw+jtOBMG8GvmL2rCXHo6RokV0tbFY6SYUeedKaZh5b549bCCpmLWuxZLl+xi16rCpOGRi5dYacxfeCLWE5xBl1aM2z2T1SsDgo= X-Sasl-enc: LFpa+MyP0rIWH+0fSMJwzSncg/tzKtZvnFcevJuLe3hD 1260872396 Received: from anglepoise.lon.incunabulum.net (cpc2-dals7-0-0-cust253.hari.cable.virginmedia.com [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 53A3A4AF2F1; Tue, 15 Dec 2009 05:19:56 -0500 (EST) Message-ID: <4B2762CB.4090406@incunabulum.net> Date: Tue, 15 Dec 2009 10:19:55 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.23 (X11/20091210) MIME-Version: 1.0 To: Graham Menhennitt References: <4B246F59.4020206@menhennitt.com.au> In-Reply-To: <4B246F59.4020206@menhennitt.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD stable Subject: Re: HP LJ 1020: "ulpt0: offline" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 10:19:58 -0000 Graham Menhennitt wrote: > Foo2zjs doesn't seem to have changed recently. CUPS has changed but I > doubt that's the problem. Maybe something to do with USB drivers? > In 8.x, CUPS 1.4.x wants libusb support and the ugen driver, rather than ulpt. Once I changed over to that, all was fine. It's a mite irritating that device permissions can't be tied down easily as they can with ulpt(4), because CUPS needs to see the /dev/usb/* device nodes. On my print server, I just have devfs rules for the new device nodes. P.S. uscanner has also gone away. I use a multi-function device (Epson CX3650). The sane-backends can also use libusb now. cheers, BMS From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 14:52:05 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 169CF1065676 for ; Tue, 15 Dec 2009 14:52:05 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id ABBD68FC18 for ; Tue, 15 Dec 2009 14:52:04 +0000 (UTC) Received: from outgoing.leidinger.net (pD954FC88.dip.t-dialin.net [217.84.252.136]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id D9B1A8435 for ; Tue, 15 Dec 2009 15:35:49 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 5F8422C3315 for ; Tue, 15 Dec 2009 15:35:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1260887744; bh=RG1dNowxHMczUtFdW4ZLBKYNd66gBb9tmPcxAMSwRg4=; h=Message-ID:Date:From:To:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=0g91b6cZMraLguuckG67wyDT8wZTWB1bqu2C4zJoILWuSGZ2Vaan5tNiCM9zBnOny mBss0RE2Ry0XKZ6aM8bjDGoug+et861E9KOXWZJhVkKwTNtU9/yHNRB2ee8pVdJSMN 0YFB0c4OfefhXNBjBI++HT/NkbKixngoUfIiEEtouQHm18eIsta7scfsabTUrUmjfu qhAKsC5F7KXlyVHc1lVV5mvsqOtv9PYt/nGiCkJzyyrhT3FYupvbugmEs2UhzZSuqG TWrl1bWE/ERitiFmIOWLAXWnBd7uryHJuqqx840T+8Pl2nGZ4tc8j9VfkJvpJrDpLt ov9Fo6lIkpWNg== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id nBFEZhGR059013 for stable@freebsd.org; Tue, 15 Dec 2009 15:35:43 +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 Framework) with HTTP; Tue, 15 Dec 2009 15:35:43 +0100 Message-ID: <20091215153543.2686145v583um280@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Tue, 15 Dec 2009 15:35:43 +0100 From: Alexander Leidinger To: stable@freebsd.org 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.3.5) / FreeBSD-8.0 X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: D9B1A8435.BF196 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.44, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1261492552.08539@yzNysWo4jAn7cIqu+9EZWw X-EBL-Spam-Status: No Cc: Subject: Stability problems with 7-stable (after 7.1 -> 7.2 -> 7-stable) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 14:52:05 -0000 Hi, please CC me on replies. I have a system which was at 7.1-pX. After the update to 7.2-p5 it started to exhibit deadlocks after some minutes of uptime. With 7.1 (generic kernel) it was running fine, with 7.2 generic the problems started directly. The system is now at 7-stable with a custom kernel (http://www.Leidinger.net/test/ALCATRAZ), basically generic without unneeded drivers plus witness/invariants/sw-watchdog. The system is an AMD Dual Core with NVidia MCP61 chipset (http://www.Leidinger.net/test/dmesg.alcatraz), 2 GB RAM, 2 harddisks and FreeBSD 32bit install. On the system are 3 jails (one postfix+mysql+apache, one mysql+apache+some-perl-service, one apache+mysql+xmpp-server). All of them have a 7-stable world. The 2 disks where configured with 3 partition pairs for root-mirror, swap-mirror, and jail-mirror. I tested with and without SMP, both schedulers, with WITNESS/INVARIANTS, and by removing one part of each mirror (to rule out that the disks are not in sync). In all cases the system was not stable and deadlocked after several minutes (even with only the mail-jail up and running). First no interaction via ssh is possible anymore, then even ping does not work anymore. After configuring the watchdog, I got at least the system back online automatically... :( After reading http://www.mail-archive.com/freebsd-stable@freebsd.org/msg96901.html I decided to switch the FS for the jails to ZFS (currently only on one harddisk, the other partition for it is still with UFS, but not mounted at all) as a test. Now with a little bit of kernel tuning for ZFS (http://www.Leidinger.net/test/loader.conf.alcatraz) I was able to keep the system up for about 3h with all jails activated (I started one jail after another, with waiting 1h between starting each jail). After that no access via ssh, no ping, but also no reboot from the sw-watchdog, I had to do a remote power-off/-on. After that I didn't had any crashdump (in the watchdog cases I had dumps, but since I recompiled the kernel since then, I can not provide useful output). The current gmirror status output is at http://www.Leidinger.net/test/gmirror.alcatraz The system has no serial console. I have no physical access. For such a small setup I would expect that 7.2-GENERIC is more than enough. At least 7.1-GENERIC was running without any problem. Does this problem sound familiar to someone, any ideas what to try, anyone with patches I could test? Bye, Alexander. -- I'm not a real movie star -- I've still got the same wife I started out with twenty-eight years ago. -- Will Rogers http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 15:05:39 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F8BD1065676 for ; Tue, 15 Dec 2009 15:05:39 +0000 (UTC) (envelope-from karl@denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id EDF398FC1C for ; Tue, 15 Dec 2009 15:05:38 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by FS.denninger.net (8.14.3/8.13.1) with SMTP id nBFF5bZ1038457 for ; Tue, 15 Dec 2009 09:05:39 -0600 (CST) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Tue Dec 15 09:05:38 2009 Message-ID: <4B27A539.808@denninger.net> Date: Tue, 15 Dec 2009 09:03:21 -0600 From: Karl Denninger User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Juergen Lock References: <4B100262.6000900@denninger.net> <4B102059.6040003@denninger.net> <20091127190319.GA12437@icarus.home.lan> <4B102C41.6040205@denninger.net> <4B11EDDD.8060108@denninger.net> <20091129205814.GB77530@icarus.home.lan> <200912131646.nBDGkiPX010830@triton8.kn-bremen.de> In-Reply-To: <200912131646.nBDGkiPX010830@triton8.kn-bremen.de> X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------050309090106020203080501" X-Antivirus: avast! (VPS 091215-0, 12/15/2009), Outbound message X-Antivirus-Status: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: marcel@freebsd.org, freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: PUC Serial I/O problem - copy of gnats-filed bug report (as [SB QUAR: Sun Dec 13 10:50:06 2009] discussed previously) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 15:05:39 -0000 This is a multi-part message in MIME format. --------------050309090106020203080501 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Juergen Lock wrote: > Hi! > > In article <4B150D60.5050200@denninger.net> you write: > >> -=-=-=-=-=- >> >> Jeremy Chadwick wrote: >> >>> On Sat, Nov 28, 2009 at 09:43:25PM -0600, Karl Denninger wrote: >>> >>> >>>> Karl Denninger wrote: >>>> >>>> >>>>> Jeremy Chadwick wrote: >>>>> >>>>> >>>>> >>>>>> On Fri, Nov 27, 2009 at 12:54:17PM -0600, Karl Denninger wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> For what its worth, USB-based serial adapters also fail in the same way, >>>>>>> but faster (they have NEVER been reliable in this regard, and this >>>>>>> hasn't improved) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> There must be a regression of some kind, given that some FreeBSD >>>>>> developers have stated in the past that FTDI-based USB serial adapters >>>>>> work great: >>>>>> >>>>>> http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041615.html >>>>>> >>>>>> Original thread: >>>>>> >>>>>> http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041610.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I don't know where "works great" has come from. Certainly not my >>>>> experience in "heavy" use. >>>>> >>>>> For non-modem-control heavy use, it works ok. I use an 8-port fanout on >>>>> 7.x to drive process control and it's stable. >>>>> >>>>> However, for heavy modem use (e.g. Hylafax) it has NEVER been stable - >>>>> although in 8.x it won't even manage to send ONE 10-page fax most of the >>>>> time, where under 7.x it would randomly fail in that use. Then again >>>>> the puc() driver based serial I/O was completely stable under 7.x and >>>>> now, with the "new architecture" it will get one or two jobs through it >>>>> before it blows up. >>>>> >>>>> -- Karl >>>>> >>>>> >>>>> >>>> FYI I downgraded back to 7.2-STABLE (it was a bit hairy but I got it to >>>> work after a small amount of screwing around) via sources >>>> and again the machine and those serial ports are 100% stable with the >>>> old driver infrastructure. >>>> >>>> The uart() infrastructure in 8.x has to be considered broken and >>>> unusable for modems at this point folks. I recognize that nobody >>>> flagged it until just before the release (I hadn't tried it until RC2, >>>> and thus didn't know) but this is a literal dagger in the heart of >>>> anyone who needs to put an actual modem on an 8.x box using the common >>>> cards out there, and I assume it will bite just as hard for things like >>>> a dial-in console as it will for a fax server. >>>> >>>> >>> Karl, >>> >>> I agree with you in this regard. However, I'm not sure what to >>> recommend to you with regards to getting this issue the proper attention >>> it needs. I fully agree with the Severity (serious) and Priority >>> (high) of the PR: >>> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/140947 >>> >>> Ed Schouten appears to be giving this attention, but I'd recommend that >>> Email communication include marcel@FreeBSD.org, "just in case" it turns >>> out that puc(4) needs some changes. I'm certain Ed will do his best to >>> assist tracking this one down. :-) >>> >>> >> Added the suggested forward address to the list..... just in case :) >> >> Yeah, this is pretty serious. It looks to me, at first blush, like an >> interrupt is being dropped on occasion and there is no watchdog timer in >> the driver code to catch it and unwedge the state machine. That's not >> supposed to be possible (dropped interrupts) on PCI (and PCI/Express) >> cards unless something is dramatically wrong in the code somewhere. >> > > It just occured to me that this might be related to a bug I fixed > in qemu's serial hw emulation, > http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=2d6ee8e7e17227d5eb8c6e9a054dd88d5b37c5ae > which also caused tx irqs to get lost and which the old sio(4) driver had > no problem with, only output on uart(4) then hung as a result. On that > occasion I also learned that there is a priority list for irqs, for example > rx irqs take precedence over tx ones, so maybe that explains why some irqs > can get lost during `heavy use'? (And which the old driver recovered from > I guess by checking status registers at least in the tx path too in > addition to just accounting for irqs.) > > HTH, > Juergen > This is now marked fixed and it appears (after limited testing thus far) that it indeed is. Thank you. -- Karl --------------050309090106020203080501-- From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 15:09:59 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A87F51065695 for ; Tue, 15 Dec 2009 15:09:59 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 63C158FC1D for ; Tue, 15 Dec 2009 15:09:59 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NKZ26-0001DZ-PT for freebsd-stable@freebsd.org; Tue, 15 Dec 2009 16:09:50 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Dec 2009 16:09:50 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Dec 2009 16:09:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Tue, 15 Dec 2009 16:09:27 +0100 Lines: 32 Message-ID: References: <20091215153543.2686145v583um280@webmail.leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.23 (X11/20091210) In-Reply-To: <20091215153543.2686145v583um280@webmail.leidinger.net> Sender: news Subject: Re: Stability problems with 7-stable (after 7.1 -> 7.2 -> 7-stable) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 15:09:59 -0000 Alexander Leidinger wrote: > Hi, > > please CC me on replies. > > I have a system which was at 7.1-pX. After the update to 7.2-p5 it > started to exhibit deadlocks after some minutes of uptime. > > With 7.1 (generic kernel) it was running fine, with 7.2 generic the > problems started directly. > > The system is now at 7-stable with a custom kernel > (http://www.Leidinger.net/test/ALCATRAZ), basically generic without > unneeded drivers plus witness/invariants/sw-watchdog. > > The system is an AMD Dual Core with NVidia MCP61 chipset > (http://www.Leidinger.net/test/dmesg.alcatraz), 2 GB RAM, 2 harddisks > and FreeBSD 32bit install. Some generic things to try: - did you monitor the system with something (top or systat -vm) to see if there is something unusual, like interrupt storms? - no physical access is a problem; If you do manage it, I'd say try running single user for some time with systat -vm just to see what happens. I would not trust ZFS in 7-stable since it lags a bit behind patches done to 8 but 7.2 should be fine - at least I don't have any such problems with it (though no AMD boxes to test them with it). If you haven't updated your ZFS pools, I'd suggest reverting back to 7.1, then building or downloading an 8.0 kernel and try it with 7.1 userland (reboot -k ...) simply to see if it helps. From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 16:43:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 028301065695 for ; Tue, 15 Dec 2009 16:43:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C9D238FC26 for ; Tue, 15 Dec 2009 16:43:08 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 84BA046B23; Tue, 15 Dec 2009 11:43:08 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 7EA828A01D; Tue, 15 Dec 2009 11:43:07 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 15 Dec 2009 10:18:36 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) References: <20091213191905.GA76785@osiris.chen.org.nz> <200912141046.27194.jhb@freebsd.org> <20091215023751.GA6418@osiris.chen.org.nz> In-Reply-To: <20091215023751.GA6418@osiris.chen.org.nz> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912151018.36607.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 15 Dec 2009 11:43:07 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Subject: Re: Dell D830, nVidia and FreeBSD-8/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 16:43:09 -0000 On Monday 14 December 2009 9:37:51 pm Jonathan Chen wrote: > On Mon, Dec 14, 2009 at 10:46:27AM -0500, John Baldwin wrote: > > On Sunday 13 December 2009 2:19:05 pm Jonathan Chen wrote: > > > Hi, > > > > > > This is a general rehash of a problem that I've been having with my > > > Dell Latitude D830 with an nVidia Quadro NVS 140M internal graphics > > > card. I've been using the XOrg's "vesa" driver ever since something in the > > > code rendered the "nvidia" driver inoperable in 7-STABLE sometime mid > > > last year. With nVidia's new 195.22 (BETA) drivers, I had hoped that I > > > could bypass the problem. Unfortunately, I seem to be experiencing the same > > > problem as described in the following thread: > > > > > > http://www.nvnews.net/vbulletin/showthread.php?t=142391 > > > > > > which appears to be implying that something in the kernel is > > > interfering with memory allocation. Would it be possible for someone > > > with deeper kernel-fu be able to take a look at this issue? > > > > Do you have a verbose dmesg available? > > I've attached a dmesg with a verbose boot. I hope this is what you're > looking for. Ok, can you grab the output of 'devinfo -r' and 'devinfo -ur'? I suspect that when the bridge allocates the prefetch resource range from the parent it is failing somehow. For a quick hack try something like this: Index: subr_rman.c =================================================================== --- subr_rman.c (revision 200359) +++ subr_rman.c (working copy) @@ -284,7 +284,7 @@ count, flags, dev == NULL ? "" : device_get_nameunit(dev))); want_activate = (flags & RF_ACTIVE); - flags &= ~RF_ACTIVE; + flags &= ~(RF_ACTIVE | RF_PREFETCHABLE); mtx_lock(rm->rm_mtx); -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 16:54:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A1181065670 for ; Tue, 15 Dec 2009 16:54:15 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 5576B8FC0A for ; Tue, 15 Dec 2009 16:54:14 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KUP00M33DM6JTB0@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Tue, 15 Dec 2009 17:54:06 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KUP00B6WDM6EI80@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Tue, 15 Dec 2009 17:54:06 +0100 (CET) Date: Tue, 15 Dec 2009 17:54:06 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20091215175406.3fa70ac0.torfinn.ingolfsen@broadpark.no> In-reply-to: <790a9fff0912030103o77614655i3762a67cf3967906@mail.gmail.com> References: <790a9fff0912030103o77614655i3762a67cf3967906@mail.gmail.com> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.5; amd64-portbld-freebsd7.2) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: FreeBSD 8 GPT install, how? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 16:54:15 -0000 On Thu, 03 Dec 2009 03:03:29 -0600 Scot Hetzel wrote: > If you have a look at the Root On ZFS tutorial, it shows how to create > a GPT formated system from the Fixit environment: > > http://wiki.freebsd.org/RootOnZFS Just FYI, this tutorial worked nicely with the memtick image, installing on a amd64 machine. -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 17:03:59 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42ADF10656AC for ; Tue, 15 Dec 2009 17:03:59 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id D8D8C8FC1C for ; Tue, 15 Dec 2009 17:03:58 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KUP00MGGE2MJTC0@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Tue, 15 Dec 2009 18:03:58 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KUP00BYME2LAQ80@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Tue, 15 Dec 2009 18:03:58 +0100 (CET) Date: Tue, 15 Dec 2009 18:03:57 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20091215180357.b4301fe6.torfinn.ingolfsen@broadpark.no> In-reply-to: <20091215175406.3fa70ac0.torfinn.ingolfsen@broadpark.no> References: <790a9fff0912030103o77614655i3762a67cf3967906@mail.gmail.com> <20091215175406.3fa70ac0.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.5; amd64-portbld-freebsd7.2) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: FreeBSD 8 GPT install, how? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 17:03:59 -0000 On Tue, 15 Dec 2009 17:54:06 +0100 Torfinn Ingolfsen wrote: > On Thu, 03 Dec 2009 03:03:29 -0600 > Scot Hetzel wrote: > > > If you have a look at the Root On ZFS tutorial, it shows how to > > create a GPT formated system from the Fixit environment: > > > > http://wiki.freebsd.org/RootOnZFS > > Just FYI, this tutorial worked nicely with the memtick image, s/memtick/memstick/ sigh. -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 17:49:44 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 708AA106566B for ; Tue, 15 Dec 2009 17:49:44 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [78.111.72.186]) by mx1.freebsd.org (Postfix) with SMTP id C221D8FC17 for ; Tue, 15 Dec 2009 17:49:43 +0000 (UTC) Received: (qmail 95669 invoked by uid 89); 15 Dec 2009 17:23:01 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (78.111.72.187) by avocado.salatschuessel.net with SMTP; 15 Dec 2009 17:23:01 -0000 Date: Tue, 15 Dec 2009 18:23:00 +0100 From: Oliver Lehmann To: mav@freebsd.org Message-Id: <20091215182300.929c7a9c.lehmann@ans-netz.de> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: problems with SATA controller after recent RELENG_8 upgrade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 17:49:44 -0000 Hi, I've just upgraded my 8 from around the 6th of december 2 days ago. Now the system won't boot up. When it is going to mount the rootfs, it receives some ICRC error and the harddisk gets accessed massivly. The the error shown on the screenshot is repeating and repeating. Apart from my custom kernel I also compiled and tried the GENERIC kernel with some additional modules (ipfw, dummynet, smb, intpm, pcfclock - nothing which should interfear) The filesystem is labeled with glabel/tunefs. Could you advise me what to do next? Right now I'm using the old kernel... Screenshot (where I tried to reach at least single user): http://pics.pofo.de/gallery/v/misc/P1090111.JPG.html The controller and harddisk in question: atapci1: port 0xec00-0xec7f,0xe800-0xe8ff mem 0xffaff000-0xffafffff,0xffac0000-0xffadffff irq 11 at device 17.0 on pci0 atapci1: [ITHREAD] atapci1: [ITHREAD] ata2: on atapci1 ata2: SIGNATURE: 00000101 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ad4: 238475MB at ata2-master SATA300 GEOM: ad4s1: geometry does not match label (255h,63s != 16h,63s). Trying to mount root from ufs:/dev/ufs/root -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 17:58:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA2AE106566B for ; Tue, 15 Dec 2009 17:58:09 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout027.mac.com (asmtpout027.mac.com [17.148.16.102]) by mx1.freebsd.org (Postfix) with ESMTP id 916D68FC16 for ; Tue, 15 Dec 2009 17:58:09 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp027.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KUP00H7MGKNSS50@asmtp027.mac.com> for freebsd-stable@freebsd.org; Tue, 15 Dec 2009 09:58:01 -0800 (PST) From: Marcel Moolenaar In-reply-to: <4B27A539.808@denninger.net> Date: Tue, 15 Dec 2009 09:57:59 -0800 Message-id: References: <4B100262.6000900@denninger.net> <4B102059.6040003@denninger.net> <20091127190319.GA12437@icarus.home.lan> <4B102C41.6040205@denninger.net> <4B11EDDD.8060108@denninger.net> <20091129205814.GB77530@icarus.home.lan> <200912131646.nBDGkiPX010830@triton8.kn-bremen.de> <4B27A539.808@denninger.net> To: Karl Denninger X-Mailer: Apple Mail (2.1077) Cc: freebsd-stable@freebsd.org, Juergen Lock , Jeremy Chadwick Subject: Re: PUC Serial I/O problem - copy of gnats-filed bug report (as [SB QUAR: Sun Dec 13 10:50:06 2009] discussed previously) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 17:58:09 -0000 On Dec 15, 2009, at 7:03 AM, Karl Denninger wrote: > This is now marked fixed and it appears (after limited testing thus far) > that it indeed is. The bug existed in 7 as well. It's not a regression introduced in 8. The reason why this didn't come up in the 7 time frame is that sio(4) was still the default. Jeremy has been an early adopter of uart(4) and if I'm not mistaken, he always loaded the driver(s) as modules. This, due to a "lucky" bug, avoided the problem for him. In depth: With uart(4) I created the serdev I/F. This is an interface that allows umbrella drivers like puc(4) and scc(4) to obtain pending interrupt status and invoke interrupt source specific handlers. This puts the umbrella driver in control over what gets handled in what order *across* multiple interfaces. As such, with puc(4), you can service all receive interrupts for all ports before you service, say, the transmit interrupt across the ports. When a serial device does not implement the serdev I/F, then puc(4) won't be involved in interrupt handling at all. This is why puc(4)+sio(4) had no problem. Since uart(4) does implement the serdev I/F, the interrupt handler of puc(4) would be in control and since it was this interrupt handler that was broken, exhibit the stalls. But, when puc(4) and/or uart(4) were loaded as modules, puc(4) would not see uart(4) as implementing the serdev I/F. This is to do with linker sets, etc. Consequently, uart(4) would handle its own interrupts and puc(4) would not be involved (just as with the sio(4) setup). In that scenario puc(4)+uart(4) also just worked. In any case: puc(4) has been fixed and I'll deal with the linker set bug later. For best results: compile puc(4) and uart(4) into the kernel and don't load them as modules for now... FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 18:04:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16D29106566C for ; Tue, 15 Dec 2009 18:04:00 +0000 (UTC) (envelope-from karl@denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id B20818FC16 for ; Tue, 15 Dec 2009 18:03:59 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by FS.denninger.net (8.14.3/8.13.1) with SMTP id nBFI3x8N056928 for ; Tue, 15 Dec 2009 12:04:00 -0600 (CST) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Tue Dec 15 12:04:00 2009 Message-ID: <4B27CF06.7070900@denninger.net> Date: Tue, 15 Dec 2009 12:01:42 -0600 From: Karl Denninger User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Marcel Moolenaar References: <4B100262.6000900@denninger.net> <4B102059.6040003@denninger.net> <20091127190319.GA12437@icarus.home.lan> <4B102C41.6040205@denninger.net> <4B11EDDD.8060108@denninger.net> <20091129205814.GB77530@icarus.home.lan> <200912131646.nBDGkiPX010830@triton8.kn-bremen.de> <4B27A539.808@denninger.net> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------060106000505060601040802" X-Antivirus: avast! (VPS 091215-0, 12/15/2009), Outbound message X-Antivirus-Status: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, Juergen Lock , Jeremy Chadwick Subject: Re: PUC Serial I/O problem - copy of gnats-filed bug report (as [SB QUAR: Sun Dec 13 10:50:06 2009] discussed previously) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 18:04:00 -0000 This is a multi-part message in MIME format. --------------060106000505060601040802 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Marcel Moolenaar wrote: > On Dec 15, 2009, at 7:03 AM, Karl Denninger wrote: > > >> This is now marked fixed and it appears (after limited testing thus far) >> that it indeed is. >> > > The bug existed in 7 as well. It's not a regression introduced in 8. > The reason why this didn't come up in the 7 time frame is that sio(4) > was still the default. Jeremy has been an early adopter of uart(4) > and if I'm not mistaken, he always loaded the driver(s) as modules. > This, due to a "lucky" bug, avoided the problem for him. > > In depth: > > With uart(4) I created the serdev I/F. This is an interface that > allows umbrella drivers like puc(4) and scc(4) to obtain pending > interrupt status and invoke interrupt source specific handlers. > This puts the umbrella driver in control over what gets handled > in what order *across* multiple interfaces. As such, with puc(4), > you can service all receive interrupts for all ports before you > service, say, the transmit interrupt across the ports. > > When a serial device does not implement the serdev I/F, then > puc(4) won't be involved in interrupt handling at all. This is > why puc(4)+sio(4) had no problem. Since uart(4) does implement > the serdev I/F, the interrupt handler of puc(4) would be in > control and since it was this interrupt handler that was broken, > exhibit the stalls. > But, when puc(4) and/or uart(4) were loaded as modules, puc(4) > would not see uart(4) as implementing the serdev I/F. This is > to do with linker sets, etc. Consequently, uart(4) would handle > its own interrupts and puc(4) would not be involved (just as > with the sio(4) setup). In that scenario puc(4)+uart(4) also > just worked. > > In any case: puc(4) has been fixed and I'll deal with the linker > set bug later. For best results: compile puc(4) and uart(4) into > the kernel and don't load them as modules for now... > > FYI, > uart(4) is defined in the GENERIC file; I am compiling in puc(4) at present in my kernel. -- Karl --------------060106000505060601040802-- From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 18:36:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB767106568B for ; Tue, 15 Dec 2009 18:36:11 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id BD8118FC21 for ; Tue, 15 Dec 2009 18:36:11 +0000 (UTC) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id HV1S1d00B1HpZEsA9WcC2K; Tue, 15 Dec 2009 18:36:12 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id HWcB1d00A3S48mS8aWcBW3; Tue, 15 Dec 2009 18:36:11 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 136A71E301B; Tue, 15 Dec 2009 10:36:10 -0800 (PST) Date: Tue, 15 Dec 2009 10:36:10 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20091215183610.GA73960@icarus.home.lan> References: <4B100262.6000900@denninger.net> <4B102059.6040003@denninger.net> <20091127190319.GA12437@icarus.home.lan> <4B102C41.6040205@denninger.net> <4B11EDDD.8060108@denninger.net> <20091129205814.GB77530@icarus.home.lan> <200912131646.nBDGkiPX010830@triton8.kn-bremen.de> <4B27A539.808@denninger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: PUC Serial I/O problem - copy of gnats-filed bug report (as [SB QUAR: Sun Dec 13 10:50:06 2009] discussed previously) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 18:36:11 -0000 On Tue, Dec 15, 2009 at 09:57:59AM -0800, Marcel Moolenaar wrote: > > On Dec 15, 2009, at 7:03 AM, Karl Denninger wrote: > > > This is now marked fixed and it appears (after limited testing thus far) > > that it indeed is. > > The bug existed in 7 as well. It's not a regression introduced in 8. > The reason why this didn't come up in the 7 time frame is that sio(4) > was still the default. Jeremy has been an early adopter of uart(4) > and if I'm not mistaken, he always loaded the driver(s) as modules. > This, due to a "lucky" bug, avoided the problem for him. Marcel, Thanks for fixing the problem Karl's reported. As I've stated in the past, I appreciate your efforts and attentiveness to this sort of thing. If there's any way I can repay you (Paypal donations, etc.), just let me know and I'll do what I can. With regards to my early testing of uart(4): I still use sio(4) on our RELENG_7 systems, as I wasn't entirely sure if uart(4) was stable enough or not (we use uart(4) reliably on our RELENG_8 systems though). During my brief testing of uart(4), it was most definitely compiled in to the kernel(**). Chances are I didn't uart(4) long enough (rather: use the serial port enough!) to really give things a good whack. Given that Karl's using them for modems, I'd say his chance of seeing interrupt-related issues are a lot higher than mine. The serial ports on our systems are used solely for serial console (115200bps, 8N1, CTS/RTS flow control), and with uart(4) worked OK for the single-user-based steps of reinstalling world/mergemaster/etc.. I don't think puc(4) was in use, but I'm not 100% certain (I remember including the device line in the kernel config, but I didn't see any mention of anything attached to puc in dmesg; they all showed up as being attached to acpi0). (**): I tend to avoid kernel modules due to habit -- I guess because I'm not sure if the module infrastructure is 100% reliable or not; scarce are the number of times I've heard of someone encountering problems with them, but old habits die hard... -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 18:44:24 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C501106568F; Tue, 15 Dec 2009 18:44:24 +0000 (UTC) (envelope-from matpockuh@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id C2A248FC08; Tue, 15 Dec 2009 18:44:23 +0000 (UTC) Received: by fxm27 with SMTP id 27so188053fxm.3 for ; Tue, 15 Dec 2009 10:44:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=CEXAhLiCyi0iBtpszLvoiNVCEHsobxP+Woi5lnrWBEo=; b=ZFL168ic8mUm0a+9nxCI6KGl5TE1pHckQzYIu7OjOGmWU4pZL7i0wYrFFc4BvXIVmh 7YJxa/qapCJscU509gxF7CCQqEAqZQprkZ5ddnscH0Wz2rIlQiF+xfPCmqozODiSG3uH 3uvzlpshUl+MPLh7O9+4+g0t9jnXHtjL8MgCw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=V5CFql1YWSOVrm8m8YTcRRPAHPhfAY1kf7jCvWFVhM4nbZI2BjiPCgZ+mb025DWBne JAnzLrj7YpsaxeNJQqpI25GhRj/Kd6a1E4o6Lz75e2AN4OufernilgdbEbOGFq7DboIP /LHxOS71LvBOpO8eA1wPQ33JL+kXeCwyZByAY= MIME-Version: 1.0 Received: by 10.223.132.204 with SMTP id c12mr1759105fat.32.1260902662553; Tue, 15 Dec 2009 10:44:22 -0800 (PST) In-Reply-To: <4B23DC8B.8020807@FreeBSD.org> References: <1260638581.00193503.1260625202@10.7.7.3> <4B23DC8B.8020807@FreeBSD.org> Date: Tue, 15 Dec 2009 21:44:22 +0300 Message-ID: <3979a4b0912151044i5c3031ebo41ed0cb482461ea9@mail.gmail.com> From: KOT MATPOCKuH To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: Trouble with drive size detection - 31MB visible size on 1TB drive. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 18:44:24 -0000 2009/12/12 Alexander Motin : > To unlock drive permanently SET MAX ADDRESS ATA command should be used > (probably the same as Linux uses) with Volatile bit set, to make it not > restore on power cycle. I don't know how to send this command with > legacy ata(4), you need some external tool. Who knows this some external tool? :) As I know hdparm is not ported to *BSD. > With new CAM-based ATA > probably it can be send via `camcontrol cmd ...`. On this machine I'm using FreeBSD 7.x and have no ahci(4) support :( I solved the problem by running "hdparm -N p1953525168 sdf" from linux livecd, but this is not the fbsd way... -- MATPOCKuH From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 20:05:20 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 979E6106566B for ; Tue, 15 Dec 2009 20:05:20 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 287658FC18 for ; Tue, 15 Dec 2009 20:05:19 +0000 (UTC) Received: by fxm27 with SMTP id 27so273543fxm.3 for ; Tue, 15 Dec 2009 12:05:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=6qXyPioaQ4wQRRS6O2P6X9JVLTik3ej2upWVedTsxDU=; b=BLfM3SACzXpL8BXlj3cIWbYi2tAvdRRckN9aLe8qY/nq7yrKl8p9ZaQiEme1vYS3/7 KQ4pR/Ey1QhCy6cRt38ZSVUtMWIEeEdFai9wayu5Zc6/pFe9txIq7V3rrJL/ZrkX0rek lpBW8GeVSRbl6ZPTYfdOhGArjbuBr4/TkzRgw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=dR/0W1utSR6DAKMqF8DzpsH4PDyp9pA8/vWCADxqh7LYI9ClP9HGzCtLbLS2dsRvnU udAxJKeKiferffZHLqg35SsP+bBIoL3O5xhBbmamDK4h5rfLDy+LCs+QP5uRnDHlJ3fk dXH5RggddQSy9duA2d6XQ1yvR7csZPbJFCzHw= Received: by 10.223.22.81 with SMTP id m17mr1106052fab.28.1260906066758; Tue, 15 Dec 2009 11:41:06 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 14sm68451fxm.3.2009.12.15.11.41.05 (version=SSLv3 cipher=RC4-MD5); Tue, 15 Dec 2009 11:41:06 -0800 (PST) Sender: Alexander Motin Message-ID: <4B27E64F.2080804@FreeBSD.org> Date: Tue, 15 Dec 2009 21:41:03 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Oliver Lehmann References: <20091215182300.929c7a9c.lehmann@ans-netz.de> In-Reply-To: <20091215182300.929c7a9c.lehmann@ans-netz.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: problems with SATA controller after recent RELENG_8 upgrade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 20:05:20 -0000 Oliver Lehmann wrote: > I've just upgraded my 8 from around the 6th of december 2 days ago. Now > the system won't boot up. When it is going to mount the rootfs, it > receives some ICRC error and the harddisk gets accessed massivly. The the > error shown on the screenshot is repeating and repeating. Apart from my > custom kernel I also compiled and tried the GENERIC kernel with some > additional modules (ipfw, dummynet, smb, intpm, pcfclock - nothing which > should interfear) > The filesystem is labeled with glabel/tunefs. > > Could you advise me what to do next? Right now I'm using the old kernel... > > Screenshot (where I tried to reach at least single user): > > http://pics.pofo.de/gallery/v/misc/P1090111.JPG.html Looks like it was working first, until something happened. I've reread all Promise related changes and don't see problem there. The only idea I have is that it could be larger transfer, which was not used before. Try to apply this patch to get limitation back for these controllers: --- ata-promise.c.prev 2009-12-15 21:35:43.000000000 +0200 +++ ata-promise.c 2009-12-15 21:35:24.000000000 +0200 @@ -957,6 +957,7 @@ ata_promise_mio_dmainit(device_t dev) ata_dmainit(dev); /* note start and stop are not used here */ ch->dma.setprd = ata_promise_mio_setprd; + ch->dma.max_iosize = 65536; } -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 20:16:34 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9528E1065694 for ; Tue, 15 Dec 2009 20:16:34 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id 7D3B08FC0A for ; Tue, 15 Dec 2009 20:16:34 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [172.24.107.154] (natint3.juniper.net [66.129.224.36]) by asmtp026.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KUP007BFMZDI780@asmtp026.mac.com> for freebsd-stable@freebsd.org; Tue, 15 Dec 2009 12:16:25 -0800 (PST) From: Marcel Moolenaar In-reply-to: <20091215183610.GA73960@icarus.home.lan> Date: Tue, 15 Dec 2009 12:16:25 -0800 Message-id: References: <4B100262.6000900@denninger.net> <4B102059.6040003@denninger.net> <20091127190319.GA12437@icarus.home.lan> <4B102C41.6040205@denninger.net> <4B11EDDD.8060108@denninger.net> <20091129205814.GB77530@icarus.home.lan> <200912131646.nBDGkiPX010830@triton8.kn-bremen.de> <4B27A539.808@denninger.net> <20091215183610.GA73960@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1077) Cc: freebsd-stable@freebsd.org Subject: Re: PUC Serial I/O problem - copy of gnats-filed bug report (as [SB QUAR: Sun Dec 13 10:50:06 2009] discussed previously) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 20:16:34 -0000 On Dec 15, 2009, at 10:36 AM, Jeremy Chadwick wrote: > Thanks for fixing the problem Karl's reported. As I've stated in the > past, I appreciate your efforts and attentiveness to this sort of thing. > If there's any way I can repay you (Paypal donations, etc.), just let me > know and I'll do what I can. Don't worry about me. If people like to do something in return for what I did, I would like them to donate towards the ports cluster in general or Mark Linimon (linimon@freebsd.org) in particular. Mark also puts in a lot of effort to get our bug database in a decent state, so he's the guy to reward. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 20:24:48 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 782431065679 for ; Tue, 15 Dec 2009 20:24:48 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id 214BF8FC15 for ; Tue, 15 Dec 2009 20:24:47 +0000 (UTC) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA07.westchester.pa.mail.comcast.net with comcast id HXGV1d0050vyq2s57YQoLL; Tue, 15 Dec 2009 20:24:48 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by OMTA05.westchester.pa.mail.comcast.net with comcast id HYQn1d0083S48mS3RYQnE4; Tue, 15 Dec 2009 20:24:48 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 31A1A1E301B; Tue, 15 Dec 2009 12:24:46 -0800 (PST) Date: Tue, 15 Dec 2009 12:24:46 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20091215202446.GA75896@icarus.home.lan> References: <1260638581.00193503.1260625202@10.7.7.3> <4B23DC8B.8020807@FreeBSD.org> <3979a4b0912151044i5c3031ebo41ed0cb482461ea9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3979a4b0912151044i5c3031ebo41ed0cb482461ea9@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Trouble with drive size detection - 31MB visible size on 1TB drive. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 20:24:48 -0000 On Tue, Dec 15, 2009 at 09:44:22PM +0300, KOT MATPOCKuH wrote: > 2009/12/12 Alexander Motin : > > To unlock drive permanently SET MAX ADDRESS ATA command should be used > > (probably the same as Linux uses) with Volatile bit set, to make it not > > restore on power cycle. I don't know how to send this command with > > legacy ata(4), you need some external tool. > Who knows this some external tool? :) > As I know hdparm is not ported to *BSD. > > > With new CAM-based ATA > > probably it can be send via `camcontrol cmd ...`. > On this machine I'm using FreeBSD 7.x and have no ahci(4) support :( > > I solved the problem by running "hdparm -N p1953525168 sdf" from linux > livecd, but this is not the fbsd way... Hmm... interesting. A couple nights ago I ended up writing some userland code that expands atacontrol(8) to support display of some SMART statistics (e.g. "atacontrol smart ad10")[1]. So what's this got to do with the above? ata(4) layer offers an ioctl (IOCATAREQUEST) which literally allows you to shove raw ATA commands at the disk itself. This means implementing the equivalent, i.e. "atacontrol cmd", is possible. Though like with camcontrol, the implications are risky. If folks are interested, I could try working on such, though honestly the argv[] parser in atacontrol(8) needs to be re-written (IMHO). What I'm saying: folks using straight ata(4) or ataahci(4) would use "atacontrol cmd" while folks using ahci(4) would use "camcontrol cmd". Please let me/list know if either of these things are of interest. [1]: It's hardly done and needs a *lot* of work, but I'll eventually get it into a state where it could be committed and people could hack on it/improve it. It's no where near as defined as smartmontools (re: disk vendor/model one-offs for attribute parsing and so on), but I figured FreeBSD users might want something out-of-the-box which might give them stats which are most commonly focused on (sector reallocation, drive temperature, high spin-up times, CRC errors, etc.). I guess you could say I'm a bit proud of myself given that I was able to figure out how to accomplish it by looking at some smartmontools source (messy, let me tell you...) and ata(4) bits (since the ioctls aren't documented). [2]: Yes, I'm still working on writing that doc that explains how to read SMART data. Going to have to end up doing it for work as well... oh the joys. :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 20:25:34 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47A7C106566C for ; Tue, 15 Dec 2009 20:25:34 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id E0E0D8FC1A for ; Tue, 15 Dec 2009 20:25:33 +0000 (UTC) Received: from OMTA21.westchester.pa.mail.comcast.net ([76.96.62.72]) by QMTA01.westchester.pa.mail.comcast.net with comcast id HQWn1d00B1ZXKqc51YQkQv; Tue, 15 Dec 2009 20:24:44 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by OMTA21.westchester.pa.mail.comcast.net with comcast id HYSD1d00K3S48mS3hYSDYr; Tue, 15 Dec 2009 20:26:14 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 69B361E301B; Tue, 15 Dec 2009 12:25:32 -0800 (PST) Date: Tue, 15 Dec 2009 12:25:32 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20091215202532.GB75896@icarus.home.lan> References: <4B102059.6040003@denninger.net> <20091127190319.GA12437@icarus.home.lan> <4B102C41.6040205@denninger.net> <4B11EDDD.8060108@denninger.net> <20091129205814.GB77530@icarus.home.lan> <200912131646.nBDGkiPX010830@triton8.kn-bremen.de> <4B27A539.808@denninger.net> <20091215183610.GA73960@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: PUC Serial I/O problem - copy of gnats-filed bug report (as [SB QUAR: Sun Dec 13 10:50:06 2009] discussed previously) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 20:25:34 -0000 On Tue, Dec 15, 2009 at 12:16:25PM -0800, Marcel Moolenaar wrote: > On Dec 15, 2009, at 10:36 AM, Jeremy Chadwick wrote: > > > Thanks for fixing the problem Karl's reported. As I've stated in the > > past, I appreciate your efforts and attentiveness to this sort of thing. > > If there's any way I can repay you (Paypal donations, etc.), just let me > > know and I'll do what I can. > > Don't worry about me. If people like to do something in return > for what I did, I would like them to donate towards the ports > cluster in general or Mark Linimon (linimon@freebsd.org) in > particular. Mark also puts in a lot of effort to get our bug > database in a decent state, so he's the guy to reward. Consider it done -- I'll send Mark a mail later tonight. :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 20:57:04 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0676C106566C for ; Tue, 15 Dec 2009 20:57:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id CCCA68FC0C for ; Tue, 15 Dec 2009 20:57:03 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5BAC246B0C; Tue, 15 Dec 2009 15:57:03 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 5C1128A01B; Tue, 15 Dec 2009 15:57:02 -0500 (EST) From: John Baldwin To: Jonathan Chen Date: Tue, 15 Dec 2009 15:51:30 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) References: <20091213191905.GA76785@osiris.chen.org.nz> <200912151018.36607.jhb@freebsd.org> <20091215194703.GA10572@osiris.chen.org.nz> In-Reply-To: <20091215194703.GA10572@osiris.chen.org.nz> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912151551.30550.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 15 Dec 2009 15:57:02 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: Dell D830, nVidia and FreeBSD-8/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 20:57:04 -0000 On Tuesday 15 December 2009 2:47:03 pm Jonathan Chen wrote: > On Tue, Dec 15, 2009 at 10:18:36AM -0500, John Baldwin wrote: > > On Monday 14 December 2009 9:37:51 pm Jonathan Chen wrote: > > > On Mon, Dec 14, 2009 at 10:46:27AM -0500, John Baldwin wrote: > > > > On Sunday 13 December 2009 2:19:05 pm Jonathan Chen wrote: > > > > > Hi, > > > > > > > > > > This is a general rehash of a problem that I've been having with my > > > > > Dell Latitude D830 with an nVidia Quadro NVS 140M internal graphics > > > > > card. I've been using the XOrg's "vesa" driver ever since something in > > the > > > > > code rendered the "nvidia" driver inoperable in 7-STABLE sometime mid > > > > > last year. With nVidia's new 195.22 (BETA) drivers, I had hoped that I > > > > > could bypass the problem. Unfortunately, I seem to be experiencing the > > same > > > > > problem as described in the following thread: > > > > > > > > > > http://www.nvnews.net/vbulletin/showthread.php?t=142391 > > > > > > > > > > which appears to be implying that something in the kernel is > > > > > interfering with memory allocation. Would it be possible for someone > > > > > with deeper kernel-fu be able to take a look at this issue? > > > > > > > > Do you have a verbose dmesg available? > > > > > > I've attached a dmesg with a verbose boot. I hope this is what you're > > > looking for. > > > > Ok, can you grab the output of 'devinfo -r' and 'devinfo -ur'? I suspect that > > when the bridge allocates the prefetch resource range from the parent it is > > failing somehow. For a quick hack try something like this: > [...] > > I've attatched the requested output. Unfortunately, the patch didn't > result in anything different. > > I/O memory addresses: > 0xdff00000-0xe06fffff (acpi0) > 0xe0700000-0xe0700fff (cbb0) > 0xe0701000-0xf3ffffff (root0) The root0 range is ok (it really means free), but the cbb0 and acpi0 ranges here conflict with the prefetch BAR for the video adapter. The cbb0 one I think is because that range is free when cbb0 needs to allocate a fresh range of resources. The real bug is why your BIOS thinks that a system resource is using 0xe0000000-0xe06fffff which conflicts with the nvidia card. You can try disabling ACPI's system-resource handling (set debug.acpi.disabled="sysres" from the loader). -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 21:27:43 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 300481065670 for ; Tue, 15 Dec 2009 21:27:43 +0000 (UTC) (envelope-from pusateri@bangj.com) Received: from jj.bangj.com (jj.bangj.com [198.86.87.199]) by mx1.freebsd.org (Postfix) with ESMTP id CCB6C8FC51 for ; Tue, 15 Dec 2009 21:27:42 +0000 (UTC) Received: from [172.16.10.11] (cpe-066-026-040-218.nc.res.rr.com [66.26.40.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by jj.bangj.com (Postfix) with ESMTPSA id 9818F380; Tue, 15 Dec 2009 16:27:41 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Tom Pusateri In-Reply-To: Date: Tue, 15 Dec 2009 16:27:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5ED6B687-4191-4B11-A2F7-B01F67FB9D16@bangj.com> References: <9223.83.206.131.26.1260781902.squirrel@webmail.esigetel.fr> To: "Li, Qing" X-Mailer: Apple Mail (2.1077) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: patch: bad ipv6 neighbor solicitation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 21:27:43 -0000 I didn't think this routing patch was related to the "bad neighbor = solicitation messages" as suggested in the subject field but I tried it = anyway. It does not fix my IPv6 problem. I still get "bad neighbor = solicitation messages" and freebsd 8 doesn't respond to 4/5 IPv6 pings. Thanks, Tom On Dec 14, 2009, at 11:53 PM, Li, Qing wrote: > Please find the more proper fix at >=20 > http://people.freebsd.org/~qingli/nd6-patch.diff >=20 > I realized I was slightly off in my previous email after > I spent a bit more time looking through the problem.=20 > Both prefixes are present but one was marked off-link due > to the fact only a single prefix route was installed in > the routing table (non RADIX_MPATH system). >=20 > I evaluated various options to fixing this issue, however,=20 > due to the association between NDPRF_ONLINK and the route > installation, I decided to go with what I have here for > the time being. >=20 > I have verified the fix in my setup. Please apply the > patch and report back. >=20 > Thanks, >=20 > -- Qing >=20 >=20 >> -----Original Message----- >> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- >> net@freebsd.org] On Behalf Of Li, Qing >> Sent: Monday, December 14, 2009 3:00 PM >> To: Dennis Glatting; JASSAL Aman >> Cc: freebsd-net@freebsd.org >> Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) >>=20 >>=20 >> You don't need to perform all that route-foo. I believe the root = cause >> of >> this issue may be due to a bit of regression in the IPv6 prefix >> management >> code, and I am in the process of putting together a permanent fix. >>=20 >> The issue as it stands today, is due to how the prefix was inserted = in >> the first place. Since bce0 was configured first, the interface >> associated >> with the prefix is bce0. Later the reference count on the prefix is >> simply incremented when bce1 configures another IPv6 address of the >> same prefix. >>=20 >> When ND6 NS arrives for bce1, due to the interface mismatch of the >> prefix >> interface against the input interface, the NS packet was considered >> invalid and thus dropped. >>=20 >> Again, in case you didn't see my earlier reply, try the temporary = hack >> at >> http://people.freebsd.org/~qingli/nd6-ns.diff >>=20 >> until I commit a permanent patch. The problem was easily reproducible >> and >> I have verified with limited unit testing the patch works. >>=20 >> -- Qing >>=20 >>=20 >> -----Original Message----- >> From: owner-freebsd-net@freebsd.org on behalf of Dennis Glatting >> Sent: Mon 12/14/2009 2:03 PM >> To: JASSAL Aman >> Cc: freebsd-net@freebsd.org >> Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) >>=20 >>=20 >> Thanks. Responses in-line. >>=20 >>=20 >>=20 >> On Mon, 14 Dec 2009, JASSAL Aman wrote: >>=20 >>> Hello Mr.Glatting, >>>=20 >>> Not that I'm an IPv6 genius, but at first sight your problem seems > to >> be a >>> route-related. I've put comments in-line. >>>=20 >>>=20 >>> Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : >>>>=20 >>>>=20 >>>> Elmer# netstat -rn >>>> Routing tables >>>>=20 >>>>=20 >>>> Internet6: >>>> Destination Gateway >> Flags >>>> Netif Expire >>>> ::/96 ::1 > UGRS >>>> lo0 =3D> default fd7c:3f2b:e791:1::1 >>>> UGS bce0 >>>> ::1 ::1 UH >>>> lo0 ::ffff:0.0.0.0/96 ::1 >> UGRS >>>> lo0 fd7c:3f2b:e791:1::/64 link#1 >> U >>>> bce0 fd7c:3f2b:e791:1::ac13:a0a link#1 >> UHS >>>> lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 >> UHS >>>> lo0 fe80::/10 ::1 >> UGRS >>>> lo0 fe80::%bce0/64 link#1 >> U >>>> bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 >> UHS >>>> lo0 fe80::%bce1/64 link#2 >> U >>>> bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 >> UHS >>>> lo0 fe80::%lo0/64 link#3 >> U >>>> lo0 fe80::1%lo0 link#3 >> UHS >>>> lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 >> U >>>> bce0 ff01:2::/32 > fd7c:3f2b:e791:1:0:1:ac13:a0a >> U >>>> bce1 ff01:3::/32 ::1 >> U >>>> lo0 ff02::/16 ::1 >> UGRS >>>> lo0 ff02::%bce0/32 fe80::213:72ff:fe60:ac52%bce0 >> U >>>> bce0 ff02::%bce1/32 > fd7c:3f2b:e791:1:0:1:ac13:a0a >> U >>>> bce1 ff02::%lo0/32 ::1 >> U >>>> lo0 >>>>=20 >>>=20 >>> Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I > was >>> expecting bce1 rather than lo0, I suppose you were as well :) If I'm >> not >>> mistaken, the packets emanating from bce1 go to the loopback >> interface, >>> thus not really going out. You can try specifying the route manually >>> with "route add *your parameters*" or even set it in /etc/rc.conf so >>> that it's loaded at boot-time. There's no reason why among 2 > physical >>> interfaces sharing the same fabric, one can ship packets out and the >>> other can't. >>>=20 >>=20 >> I was wondering about the route however I haven't figured out the > trick >> to >> get what I want. For example: >>=20 >> Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a >> delete host fd7c:3f2b:e791:1:0:1:ac13:a0a >>=20 >> Elmer# route add >> -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 >> route: writing to routing socket: File exists >> add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route already >> in table >>=20 >> I did delete the lo0 route before I exected the above command. Also, = I >> haven't been able to specify a higher metric (e.g., -metric 2). That > is >> rejected too. However, I can say: >>=20 >> Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a >> delete host fd7c:3f2b:e791:1:0:1:ac13:a0a >>=20 >> Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a -iface bce1 >> add host fd7c:3f2b:e791:1:0:1:ac13:a0a: gateway bce1 >>=20 >> Elmer# netstat -rn >> (snip) >> fd7c:3f2b:e791:1:0:1:ac13:a0a 00:13:72:60:ac:50 UHS >> bce1 >>=20 >> I don't think that is what I want. WHat I think I just said is "host > X" >> is >> out that door, rather than route net. If, however, I say Docs is out >> that >> door, I get: >>=20 >> Elmer# route add -inet6 docs.dco.penx.com -iface bce1 >> add host docs.dco.penx.com: gateway bce1 >>=20 >> Elmer# ping6 >> docs.penx.com >> PING6(56=3D40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> >> fd7c:3f2b:e791:1::ac13:a15 >> ping6: sendmsg: Operation not permitted >> ping6: wrote docs.dco.penx.com 16 chars, ret=3D-1 >>=20 >>=20 >>>>=20 >>>> Elmer's rc.config: >>>>=20 >>>>=20 >>>> ipv6_enable=3D"YES" ipv6_network_interfaces=3D"bce0 bce1" >>>> ipv6_ifconfig_bce0=3D"FD7C:3F2B:E791:0001::0:172.19.10.10 prefixlen >> 64" >>>> ipv6_ifconfig_bce1=3D"FD7C:3F2B:E791:0001::1:172.19.10.10 prefixlen > 64 >> mtu >>>> 8192" >>>> ipv6_defaultrouter=3D"FD7C:3F2B:E791:0001::1" >>>>=20 >>>=20 >>> Erm... You're using IPv4 addresses encapsulated in IPv6 ? I've never >> used >>> this myself so I can't really comment, and I can't say if there >> aren't any >>> sort of "interferences" with what you're trying to do. >>>=20 >>=20 >> I hope what I am specifying is to use the 32 bit IPv4 address as the >> last >> 32 bits of the IPv6 address, at least that is how it works out >> numerically. My numbering scheme for fixed assets is the last 32 bits >> of >> the 128 bit IPv6 address is the same as its IPv4 address. >>=20 >>=20 >>>>=20 >>>>=20 >>>> The router (cisco): >>>>=20 >>>>=20 >>>> interface GigabitEthernet0/0 ipv6 address FD7C:3F2B:E791:1::1/64 >> ipv6 >>>> enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) >>>>=20 >>>=20 >>> Just a side-note, I'm not sure if it will be really useful to you, >> but you >>> could give it a try if you want to. Have you tried using your Cisco >> router >>> as a Router Advertisement Daemon ? That way, addresses would be > built >>> automatically and you could see how both interfaces react to such >>> advertisements. >>>=20 >>> I hope this helps. >>>=20 >>> ------------ >>> Aman Jassal >>>=20 >>> Wisdom comes from experience. >>> Experience comes from a lack of wisdom. >>>=20 >>>=20 >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to = "freebsd-net-unsubscribe@freebsd.org" >>=20 >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to = "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 21:45:55 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF8C81065693; Tue, 15 Dec 2009 21:45:55 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id A35E18FC12; Tue, 15 Dec 2009 21:45:55 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBFLjqdS003573; Tue, 15 Dec 2009 13:45:52 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Dec 2009 13:45:40 -0800 Message-ID: In-Reply-To: <5ED6B687-4191-4B11-A2F7-B01F67FB9D16@bangj.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: patch: bad ipv6 neighbor solicitation Thread-Index: Acp9zXC6xmQlJbuwQsG95QYD+62J8QAAkxaA References: <9223.83.206.131.26.1260781902.squirrel@webmail.esigetel.fr> <5ED6B687-4191-4B11-A2F7-B01F67FB9D16@bangj.com> From: "Li, Qing" To: "Tom Pusateri" Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: RE: patch: bad ipv6 neighbor solicitation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 21:45:55 -0000 Thanks for reporting back. I asked you for a routing table dump in my previous email, would you mind emailing it to me privately? -- Qing > -----Original Message----- > From: Tom Pusateri [mailto:pusateri@bangj.com] > Sent: Tuesday, December 15, 2009 1:28 PM > To: Li, Qing > Cc: freebsd-net@freebsd.org; freebsd-stable@freebsd.org > Subject: Re: patch: bad ipv6 neighbor solicitation >=20 > I didn't think this routing patch was related to the "bad neighbor > solicitation messages" as suggested in the subject field but I tried it > anyway. It does not fix my IPv6 problem. I still get "bad neighbor > solicitation messages" and freebsd 8 doesn't respond to 4/5 IPv6 pings. >=20 > Thanks, > Tom >=20 > On Dec 14, 2009, at 11:53 PM, Li, Qing wrote: >=20 > > Please find the more proper fix at > > > > http://people.freebsd.org/~qingli/nd6-patch.diff > > > > I realized I was slightly off in my previous email after > > I spent a bit more time looking through the problem. > > Both prefixes are present but one was marked off-link due > > to the fact only a single prefix route was installed in > > the routing table (non RADIX_MPATH system). > > > > I evaluated various options to fixing this issue, however, > > due to the association between NDPRF_ONLINK and the route > > installation, I decided to go with what I have here for > > the time being. > > > > I have verified the fix in my setup. Please apply the > > patch and report back. > > > > Thanks, > > > > -- Qing > > > > > >> -----Original Message----- > >> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > >> net@freebsd.org] On Behalf Of Li, Qing > >> Sent: Monday, December 14, 2009 3:00 PM > >> To: Dennis Glatting; JASSAL Aman > >> Cc: freebsd-net@freebsd.org > >> Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) > >> > >> > >> You don't need to perform all that route-foo. I believe the root > cause > >> of > >> this issue may be due to a bit of regression in the IPv6 prefix > >> management > >> code, and I am in the process of putting together a permanent fix. > >> > >> The issue as it stands today, is due to how the prefix was inserted > in > >> the first place. Since bce0 was configured first, the interface > >> associated > >> with the prefix is bce0. Later the reference count on the prefix is > >> simply incremented when bce1 configures another IPv6 address of the > >> same prefix. > >> > >> When ND6 NS arrives for bce1, due to the interface mismatch of the > >> prefix > >> interface against the input interface, the NS packet was considered > >> invalid and thus dropped. > >> > >> Again, in case you didn't see my earlier reply, try the temporary > hack > >> at > >> http://people.freebsd.org/~qingli/nd6-ns.diff > >> > >> until I commit a permanent patch. The problem was easily > reproducible > >> and > >> I have verified with limited unit testing the patch works. > >> > >> -- Qing > >> > >> > >> -----Original Message----- > >> From: owner-freebsd-net@freebsd.org on behalf of Dennis Glatting > >> Sent: Mon 12/14/2009 2:03 PM > >> To: JASSAL Aman > >> Cc: freebsd-net@freebsd.org > >> Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) > >> > >> > >> Thanks. Responses in-line. > >> > >> > >> > >> On Mon, 14 Dec 2009, JASSAL Aman wrote: > >> > >>> Hello Mr.Glatting, > >>> > >>> Not that I'm an IPv6 genius, but at first sight your problem seems > > to > >> be a > >>> route-related. I've put comments in-line. > >>> > >>> > >>> Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : > >>>> > >>>> > >>>> Elmer# netstat -rn > >>>> Routing tables > >>>> > >>>> > >>>> Internet6: > >>>> Destination Gateway > >> Flags > >>>> Netif Expire > >>>> ::/96 ::1 > > UGRS > >>>> lo0 =3D> default fd7c:3f2b:e791:1::1 > >>>> UGS bce0 > >>>> ::1 ::1 UH > >>>> lo0 ::ffff:0.0.0.0/96 ::1 > >> UGRS > >>>> lo0 fd7c:3f2b:e791:1::/64 link#1 > >> U > >>>> bce0 fd7c:3f2b:e791:1::ac13:a0a link#1 > >> UHS > >>>> lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 > >> UHS > >>>> lo0 fe80::/10 ::1 > >> UGRS > >>>> lo0 fe80::%bce0/64 link#1 > >> U > >>>> bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 > >> UHS > >>>> lo0 fe80::%bce1/64 link#2 > >> U > >>>> bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 > >> UHS > >>>> lo0 fe80::%lo0/64 link#3 > >> U > >>>> lo0 fe80::1%lo0 link#3 > >> UHS > >>>> lo0 ff01:1::/32 > fe80::213:72ff:fe60:ac52%bce0 > >> U > >>>> bce0 ff01:2::/32 > > fd7c:3f2b:e791:1:0:1:ac13:a0a > >> U > >>>> bce1 ff01:3::/32 ::1 > >> U > >>>> lo0 ff02::/16 ::1 > >> UGRS > >>>> lo0 ff02::%bce0/32 > fe80::213:72ff:fe60:ac52%bce0 > >> U > >>>> bce0 ff02::%bce1/32 > > fd7c:3f2b:e791:1:0:1:ac13:a0a > >> U > >>>> bce1 ff02::%lo0/32 ::1 > >> U > >>>> lo0 > >>>> > >>> > >>> Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I > > was > >>> expecting bce1 rather than lo0, I suppose you were as well :) If > I'm > >> not > >>> mistaken, the packets emanating from bce1 go to the loopback > >> interface, > >>> thus not really going out. You can try specifying the route > manually > >>> with "route add *your parameters*" or even set it in /etc/rc.conf > so > >>> that it's loaded at boot-time. There's no reason why among 2 > > physical > >>> interfaces sharing the same fabric, one can ship packets out and > the > >>> other can't. > >>> > >> > >> I was wondering about the route however I haven't figured out the > > trick > >> to > >> get what I want. For example: > >> > >> Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a > >> delete host fd7c:3f2b:e791:1:0:1:ac13:a0a > >> > >> Elmer# route add > >> -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 > >> route: writing to routing socket: File exists > >> add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route > already > >> in table > >> > >> I did delete the lo0 route before I exected the above command. Also, > I > >> haven't been able to specify a higher metric (e.g., -metric 2). That > > is > >> rejected too. However, I can say: > >> > >> Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a > >> delete host fd7c:3f2b:e791:1:0:1:ac13:a0a > >> > >> Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a -iface bce1 > >> add host fd7c:3f2b:e791:1:0:1:ac13:a0a: gateway bce1 > >> > >> Elmer# netstat -rn > >> (snip) > >> fd7c:3f2b:e791:1:0:1:ac13:a0a 00:13:72:60:ac:50 UHS > >> bce1 > >> > >> I don't think that is what I want. WHat I think I just said is "host > > X" > >> is > >> out that door, rather than route net. If, however, I say Docs is out > >> that > >> door, I get: > >> > >> Elmer# route add -inet6 docs.dco.penx.com -iface bce1 > >> add host docs.dco.penx.com: gateway bce1 > >> > >> Elmer# ping6 > >> docs.penx.com > >> PING6(56=3D40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> > >> fd7c:3f2b:e791:1::ac13:a15 > >> ping6: sendmsg: Operation not permitted > >> ping6: wrote docs.dco.penx.com 16 chars, ret=3D-1 > >> > >> > >>>> > >>>> Elmer's rc.config: > >>>> > >>>> > >>>> ipv6_enable=3D"YES" ipv6_network_interfaces=3D"bce0 bce1" > >>>> ipv6_ifconfig_bce0=3D"FD7C:3F2B:E791:0001::0:172.19.10.10 = prefixlen > >> 64" > >>>> ipv6_ifconfig_bce1=3D"FD7C:3F2B:E791:0001::1:172.19.10.10 = prefixlen > > 64 > >> mtu > >>>> 8192" > >>>> ipv6_defaultrouter=3D"FD7C:3F2B:E791:0001::1" > >>>> > >>> > >>> Erm... You're using IPv4 addresses encapsulated in IPv6 ? I've > never > >> used > >>> this myself so I can't really comment, and I can't say if there > >> aren't any > >>> sort of "interferences" with what you're trying to do. > >>> > >> > >> I hope what I am specifying is to use the 32 bit IPv4 address as the > >> last > >> 32 bits of the IPv6 address, at least that is how it works out > >> numerically. My numbering scheme for fixed assets is the last 32 > bits > >> of > >> the 128 bit IPv6 address is the same as its IPv4 address. > >> > >> > >>>> > >>>> > >>>> The router (cisco): > >>>> > >>>> > >>>> interface GigabitEthernet0/0 ipv6 address FD7C:3F2B:E791:1::1/64 > >> ipv6 > >>>> enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) > >>>> > >>> > >>> Just a side-note, I'm not sure if it will be really useful to you, > >> but you > >>> could give it a try if you want to. Have you tried using your Cisco > >> router > >>> as a Router Advertisement Daemon ? That way, addresses would be > > built > >>> automatically and you could see how both interfaces react to such > >>> advertisements. > >>> > >>> I hope this helps. > >>> > >>> ------------ > >>> Aman Jassal > >>> > >>> Wisdom comes from experience. > >>> Experience comes from a lack of wisdom. > >>> > >>> > >> _______________________________________________ > >> freebsd-net@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> To unsubscribe, send any mail to "freebsd-net- > unsubscribe@freebsd.org" > >> > >> _______________________________________________ > >> freebsd-net@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> To unsubscribe, send any mail to "freebsd-net- > unsubscribe@freebsd.org" > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable- > unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 22:01:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58C1B106566C; Tue, 15 Dec 2009 22:01:14 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 064908FC16; Tue, 15 Dec 2009 22:01:13 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBFM0u2g006018; Tue, 15 Dec 2009 14:01:02 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Dec 2009 14:00:54 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: patch: bad ipv6 neighbor solicitation Thread-Index: Acp9zXC6xmQlJbuwQsG95QYD+62J8QAAkxaAAABuX9A= References: <9223.83.206.131.26.1260781902.squirrel@webmail.esigetel.fr><5ED6B687-4191-4B11-A2F7-B01F67FB9D16@bangj.com> From: "Li, Qing" To: "Tom Pusateri" Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: RE: patch: bad ipv6 neighbor solicitation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 22:01:14 -0000 Thanks for sending me the routing table output. Actually I believe both your problems are indeed related to the=20 prefix route.=20 I was able to reproduce Dennis Glatting's problem, which was due to one of the prefix entry being off-link. In your case the prefix route for 2610:28:1800:4001:20e:cff:fe9f:faad disappeared and is not in the routing table. If you add the route by hand the problem should go away. I guess the question is what triggered the prefix route deletion. -- Qing > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of Li, Qing > Sent: Tuesday, December 15, 2009 1:46 PM > To: Tom Pusateri > Cc: freebsd-net@freebsd.org; freebsd-stable@freebsd.org > Subject: RE: patch: bad ipv6 neighbor solicitation >=20 > Thanks for reporting back. I asked you for a routing table dump > in my previous email, would you mind emailing it to me privately? >=20 > -- Qing >=20 >=20 > > -----Original Message----- > > From: Tom Pusateri [mailto:pusateri@bangj.com] > > Sent: Tuesday, December 15, 2009 1:28 PM > > To: Li, Qing > > Cc: freebsd-net@freebsd.org; freebsd-stable@freebsd.org > > Subject: Re: patch: bad ipv6 neighbor solicitation > > > > I didn't think this routing patch was related to the "bad neighbor > > solicitation messages" as suggested in the subject field but I tried > it > > anyway. It does not fix my IPv6 problem. I still get "bad neighbor > > solicitation messages" and freebsd 8 doesn't respond to 4/5 IPv6 > pings. > > > > Thanks, > > Tom > > > > On Dec 14, 2009, at 11:53 PM, Li, Qing wrote: > > > > > Please find the more proper fix at > > > > > > http://people.freebsd.org/~qingli/nd6-patch.diff > > > > > > I realized I was slightly off in my previous email after > > > I spent a bit more time looking through the problem. > > > Both prefixes are present but one was marked off-link due > > > to the fact only a single prefix route was installed in > > > the routing table (non RADIX_MPATH system). > > > > > > I evaluated various options to fixing this issue, however, > > > due to the association between NDPRF_ONLINK and the route > > > installation, I decided to go with what I have here for > > > the time being. > > > > > > I have verified the fix in my setup. Please apply the > > > patch and report back. > > > > > > Thanks, > > > > > > -- Qing > > > > > > > > >> -----Original Message----- > > >> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > > >> net@freebsd.org] On Behalf Of Li, Qing > > >> Sent: Monday, December 14, 2009 3:00 PM > > >> To: Dennis Glatting; JASSAL Aman > > >> Cc: freebsd-net@freebsd.org > > >> Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) > > >> > > >> > > >> You don't need to perform all that route-foo. I believe the root > > cause > > >> of > > >> this issue may be due to a bit of regression in the IPv6 prefix > > >> management > > >> code, and I am in the process of putting together a permanent fix. > > >> > > >> The issue as it stands today, is due to how the prefix was > inserted > > in > > >> the first place. Since bce0 was configured first, the interface > > >> associated > > >> with the prefix is bce0. Later the reference count on the prefix > is > > >> simply incremented when bce1 configures another IPv6 address of > the > > >> same prefix. > > >> > > >> When ND6 NS arrives for bce1, due to the interface mismatch of the > > >> prefix > > >> interface against the input interface, the NS packet was > considered > > >> invalid and thus dropped. > > >> > > >> Again, in case you didn't see my earlier reply, try the temporary > > hack > > >> at > > >> http://people.freebsd.org/~qingli/nd6-ns.diff > > >> > > >> until I commit a permanent patch. The problem was easily > > reproducible > > >> and > > >> I have verified with limited unit testing the patch works. > > >> > > >> -- Qing > > >> > > >> > > >> -----Original Message----- > > >> From: owner-freebsd-net@freebsd.org on behalf of Dennis Glatting > > >> Sent: Mon 12/14/2009 2:03 PM > > >> To: JASSAL Aman > > >> Cc: freebsd-net@freebsd.org > > >> Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) > > >> > > >> > > >> Thanks. Responses in-line. > > >> > > >> > > >> > > >> On Mon, 14 Dec 2009, JASSAL Aman wrote: > > >> > > >>> Hello Mr.Glatting, > > >>> > > >>> Not that I'm an IPv6 genius, but at first sight your problem > seems > > > to > > >> be a > > >>> route-related. I've put comments in-line. > > >>> > > >>> > > >>> Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : > > >>>> > > >>>> > > >>>> Elmer# netstat -rn > > >>>> Routing tables > > >>>> > > >>>> > > >>>> Internet6: > > >>>> Destination Gateway > > >> Flags > > >>>> Netif Expire > > >>>> ::/96 ::1 > > > UGRS > > >>>> lo0 =3D> default fd7c:3f2b:e791:1::1 > > >>>> UGS bce0 > > >>>> ::1 ::1 > UH > > >>>> lo0 ::ffff:0.0.0.0/96 ::1 > > >> UGRS > > >>>> lo0 fd7c:3f2b:e791:1::/64 link#1 > > >> U > > >>>> bce0 fd7c:3f2b:e791:1::ac13:a0a link#1 > > >> UHS > > >>>> lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 > > >> UHS > > >>>> lo0 fe80::/10 ::1 > > >> UGRS > > >>>> lo0 fe80::%bce0/64 link#1 > > >> U > > >>>> bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 > > >> UHS > > >>>> lo0 fe80::%bce1/64 link#2 > > >> U > > >>>> bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 > > >> UHS > > >>>> lo0 fe80::%lo0/64 link#3 > > >> U > > >>>> lo0 fe80::1%lo0 link#3 > > >> UHS > > >>>> lo0 ff01:1::/32 > > fe80::213:72ff:fe60:ac52%bce0 > > >> U > > >>>> bce0 ff01:2::/32 > > > fd7c:3f2b:e791:1:0:1:ac13:a0a > > >> U > > >>>> bce1 ff01:3::/32 ::1 > > >> U > > >>>> lo0 ff02::/16 ::1 > > >> UGRS > > >>>> lo0 ff02::%bce0/32 > > fe80::213:72ff:fe60:ac52%bce0 > > >> U > > >>>> bce0 ff02::%bce1/32 > > > fd7c:3f2b:e791:1:0:1:ac13:a0a > > >> U > > >>>> bce1 ff02::%lo0/32 ::1 > > >> U > > >>>> lo0 > > >>>> > > >>> > > >>> Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I > > > was > > >>> expecting bce1 rather than lo0, I suppose you were as well :) If > > I'm > > >> not > > >>> mistaken, the packets emanating from bce1 go to the loopback > > >> interface, > > >>> thus not really going out. You can try specifying the route > > manually > > >>> with "route add *your parameters*" or even set it in /etc/rc.conf > > so > > >>> that it's loaded at boot-time. There's no reason why among 2 > > > physical > > >>> interfaces sharing the same fabric, one can ship packets out and > > the > > >>> other can't. > > >>> > > >> > > >> I was wondering about the route however I haven't figured out the > > > trick > > >> to > > >> get what I want. For example: > > >> > > >> Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a > > >> delete host fd7c:3f2b:e791:1:0:1:ac13:a0a > > >> > > >> Elmer# route add > > >> -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 > > >> route: writing to routing socket: File exists > > >> add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route > > already > > >> in table > > >> > > >> I did delete the lo0 route before I exected the above command. > Also, > > I > > >> haven't been able to specify a higher metric (e.g., -metric 2). > That > > > is > > >> rejected too. However, I can say: > > >> > > >> Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a > > >> delete host fd7c:3f2b:e791:1:0:1:ac13:a0a > > >> > > >> Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a -iface bce1 > > >> add host fd7c:3f2b:e791:1:0:1:ac13:a0a: gateway bce1 > > >> > > >> Elmer# netstat -rn > > >> (snip) > > >> fd7c:3f2b:e791:1:0:1:ac13:a0a 00:13:72:60:ac:50 > UHS > > >> bce1 > > >> > > >> I don't think that is what I want. WHat I think I just said is > "host > > > X" > > >> is > > >> out that door, rather than route net. If, however, I say Docs is > out > > >> that > > >> door, I get: > > >> > > >> Elmer# route add -inet6 docs.dco.penx.com -iface bce1 > > >> add host docs.dco.penx.com: gateway bce1 > > >> > > >> Elmer# ping6 > > >> docs.penx.com > > >> PING6(56=3D40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> > > >> fd7c:3f2b:e791:1::ac13:a15 > > >> ping6: sendmsg: Operation not permitted > > >> ping6: wrote docs.dco.penx.com 16 chars, ret=3D-1 > > >> > > >> > > >>>> > > >>>> Elmer's rc.config: > > >>>> > > >>>> > > >>>> ipv6_enable=3D"YES" ipv6_network_interfaces=3D"bce0 bce1" > > >>>> ipv6_ifconfig_bce0=3D"FD7C:3F2B:E791:0001::0:172.19.10.10 > prefixlen > > >> 64" > > >>>> ipv6_ifconfig_bce1=3D"FD7C:3F2B:E791:0001::1:172.19.10.10 > prefixlen > > > 64 > > >> mtu > > >>>> 8192" > > >>>> ipv6_defaultrouter=3D"FD7C:3F2B:E791:0001::1" > > >>>> > > >>> > > >>> Erm... You're using IPv4 addresses encapsulated in IPv6 ? I've > > never > > >> used > > >>> this myself so I can't really comment, and I can't say if there > > >> aren't any > > >>> sort of "interferences" with what you're trying to do. > > >>> > > >> > > >> I hope what I am specifying is to use the 32 bit IPv4 address as > the > > >> last > > >> 32 bits of the IPv6 address, at least that is how it works out > > >> numerically. My numbering scheme for fixed assets is the last 32 > > bits > > >> of > > >> the 128 bit IPv6 address is the same as its IPv4 address. > > >> > > >> > > >>>> > > >>>> > > >>>> The router (cisco): > > >>>> > > >>>> > > >>>> interface GigabitEthernet0/0 ipv6 address FD7C:3F2B:E791:1::1/64 > > >> ipv6 > > >>>> enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) > > >>>> > > >>> > > >>> Just a side-note, I'm not sure if it will be really useful to you, > > >> but you > > >>> could give it a try if you want to. Have you tried using your > Cisco > > >> router > > >>> as a Router Advertisement Daemon ? That way, addresses would be > > > built > > >>> automatically and you could see how both interfaces react to such > > >>> advertisements. > > >>> > > >>> I hope this helps. > > >>> > > >>> ------------ > > >>> Aman Jassal > > >>> > > >>> Wisdom comes from experience. > > >>> Experience comes from a lack of wisdom. > > >>> > > >>> > > >> _______________________________________________ > > >> freebsd-net@freebsd.org mailing list > > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > > >> To unsubscribe, send any mail to "freebsd-net- > > unsubscribe@freebsd.org" > > >> > > >> _______________________________________________ > > >> freebsd-net@freebsd.org mailing list > > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > > >> To unsubscribe, send any mail to "freebsd-net- > > unsubscribe@freebsd.org" > > > _______________________________________________ > > > freebsd-stable@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > > To unsubscribe, send any mail to "freebsd-stable- > > unsubscribe@freebsd.org" >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable- > unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 22:01:30 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8450B1065746 for ; Tue, 15 Dec 2009 22:01:30 +0000 (UTC) (envelope-from MH@kernel32.de) Received: from crivens.kernel32.de (crivens.asm68k.org [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id 457C48FC14 for ; Tue, 15 Dec 2009 22:01:29 +0000 (UTC) Received: from MotorBookMKII.local (91-64-178-220-dynip.superkabel.de [91.64.178.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by crivens.kernel32.de (Postfix) with ESMTPSA id 94474B039A for ; Tue, 15 Dec 2009 22:42:03 +0100 (CET) Message-ID: <4B2802AE.9090107@kernel32.de> Date: Tue, 15 Dec 2009 22:42:06 +0100 From: Marian Hettwer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: update to 8.0-RELEASE --> partition gone X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 22:01:30 -0000 Hi Folks, today I did an update from 7.2-RELEASE-p4 to 8.0-RELEASE using freebsd-update. Everything went smooth, apart from the fact that I can't mount my second disk. It's all a bit puzzling... Here are the facts: [root@talisker ~]# cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/ad4s2b none swap sw O O /dev/ad4s1a / ufs rw 1 1 /dev/ad4s2a /tmp ufs rw 2 2 /dev/ad4s2d /var ufs rw 2 2 /dev/ad4s2e /usr ufs rw 2 2 /dev/ad8s1a /BACKUP ufs rw 2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 linproc /compat/linux/proc linprocfs rw 0 0 The offending entry which isn't mountable anymore is ad8s1. [root@talisker ~]# sysctl kern.disks kern.disks: ad8 ad4 fdisk and bsdlabel are showing my s1a partition/slice: [root@talisker ~]# fdisk ad8 ******* Working on device /dev/ad8 ******* parameters extracted from in-core disklabel are: cylinders=775221 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=775221 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 781422705 (381554 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 52/ head 15/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: [root@talisker ~]# bsdlabel ad8 # /dev/ad8: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 781422752 16 unused 0 0 c: 781422768 0 unused 0 0 # "raw" part, don't edit but: [root@talisker ~]# mount /dev/ad8s1a /BACKUP/ mount: /dev/ad8s1a : No such file or directory And in fact: [root@talisker ~]# ls -l /dev/ad8* crw-r----- 1 root operator 0, 91 Dec 15 17:58 /dev/ad8 crw-r----- 1 root operator 0, 96 Dec 15 17:58 /dev/ad8a Huu? What's going on here? Where is s1? Never seen that before... (and I'm using FreeBSD since 4.0-RELEASE). and this mount obviously won't work either: [root@talisker ~]# mount /dev/ad8a /BACKUP/ mount: /dev/ad8a : Invalid argument Anybody any idea how to recover here? The server is unluckily remote and in production. A downgrade back to 7.2 would be kinda difficult. I'd like to avoid that. Ideas anyone? Thanks in advance, Marian PS.: dmesg: http://crivens.terrorteam.de/~rabauke/FreeBSD/dmesg-8.0-release.txt [root@talisker ~]# uname -rms FreeBSD 8.0-RELEASE i386 From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 22:11:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 364D2106568D for ; Tue, 15 Dec 2009 22:11:11 +0000 (UTC) (envelope-from freebsd-stable@adam.gs) Received: from mail.adam.gs (mail.adam.gs [76.9.2.116]) by mx1.freebsd.org (Postfix) with ESMTP id 0FA408FC20 for ; Tue, 15 Dec 2009 22:11:10 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.adam.gs (Postfix) with ESMTP id E2FAC3E3B39 for ; Tue, 15 Dec 2009 17:11:09 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Adam Jacob Muller In-Reply-To: <1260805564.2281.86.camel@balrog.2hip.net> Date: Tue, 15 Dec 2009 17:11:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <42F3C226-766E-45BA-AB2E-74643B3E8724@adam.gs> References: <2A3A50FE-13F4-4AA7-976E-37354E5736B5@adam.gs> <4B256907.4060805@lazlarlyricon.com> <1260805564.2281.86.camel@balrog.2hip.net> To: Robert Noland X-Authentication: 7ONxL3Xv++PBILH0qQg4bwAZcYbRJ4be+KVtSstgqdLQbsx9kEG+7EKoYMcZ9CdBhwI11VX1Co14cIBEAP77YHVOlWwfzUTORF/ussFFvVNrG6N/MSShTd3Eu4IdflEmJ4V/D025/IaLFQ8+qQ5LQiizvpewDg3r59FQBA58ocQPxWFeMFNvbqf1NQ== Cc: freebsd-stable@freebsd.org, Adam Jacob Muller , Rolf G Nielsen Subject: Re: freebsd / gpt boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 22:11:11 -0000 On Dec 14, 2009, at 10:46 AM, Robert Noland wrote: > On Sun, 2009-12-13 at 23:21 +0100, Rolf G Nielsen wrote: >> Adam Jacob Muller wrote: >>> Hi, >>> I'm trying to setup a system with a very large RAID array (total = ~10TB), I would ideally like to have the system boot directly off that = 10TB array, so i'm trying to get the system setup with GPT but running = into an issue. >>>=20 >>>=20 >>> The initial pre-loader (boot0 I think? -- i'm not sure what this is = called) is unable to find loader at /boot/loader nor can it load = /boot/kernel/kernel >>>=20 >>=20 >> Is the partitioning done correctly (have you created a small boot=20 >> partition, 15 sectors is enough for booting from ufs, but the = tutorials=20 >> I've found deal mainly with booting from zfs and they recommend 128=20= >> sectors to make future bootcode changes easier)? >=20 > You will need to be doing all of this from a current 8-STABLE. One = bug > in dealing with larger zfs raidz volumes was fixed and made it into = 8.0. > Another, which deals with GPT/ZFS and large volumes did not make it = and > only exists in 8-STABLE, iirc. Also, with the gptzfsboot code from > -STABLE, it will request to load /boot/zfsloader by default (and > LOADER_ZFS_SUPPORT is no longer required). >=20 >> gpart add -b 34 -s 128 -t freebsd-boot -i 1 da0 >>=20 >> Have you embedded the correct boot code? >>=20 >> gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 da0 >> (for booting from ufs). >>=20 >> or >>=20 >> gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 >> (for booting from zfs). >>=20 >> You may also need to set it active by >>=20 >> gpart set -a active -i 1 da0 >=20 > The above step is no longer needed on -STABLE, the pmbr will be marked > active when you install bootcode. Robert, Do either of these bugs affect GPT/UFS, which is what I am using here. These bugs are affecting the actual older versions of the tools (IE = using the gpart from an 8.0-pre or earlier could cause issues like = this)? Also, perhaps not coincidentally, booting the FreeBSD memstick image = produces the same error (boot0 can't find loader). -Adam >=20 > robert. >=20 >> And of course, substitute your arrays device node for da0 in my = examples. >>=20 >>> Copying /boot/loader to /loader allows me to enter /loader at the = "boot:" prompt and the loader will load, however, its unable to load the = kernel. >>>=20 >>> If I do an "ls" at the loader prompt I can see boot listed as a = directory (with a "d" before it) >>> Trying to do "ls boot" inexplicably it says "boot: not a directory" >>>=20 >>> re-applying my /boot/loader.conf settings (for some reason = vfs.root.mountfrom=3Dufs:/dev/label/root is required, or else I get a = mountroot>) and then: >>> load /kernel >>> boot >>>=20 >>> does work, and lets the system boot normally and everything is as = expected (/boot is a directory etc). >>>=20 >>> Anyone have any ideas about either of these things (the = vfs.root.mountfrom is minor i guess but i'm curious if they are = related?) >>>=20 >>> Thanks in advance, >>>=20 >>> -Adam >>>=20 >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" > --=20 > Robert Noland > FreeBSD >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 22:49:34 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6C04106566B for ; Tue, 15 Dec 2009 22:49:34 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3F1838FC17 for ; Tue, 15 Dec 2009 22:49:34 +0000 (UTC) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 26F6319E046 for ; Tue, 15 Dec 2009 23:49:32 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id A6A4719E044 for ; Tue, 15 Dec 2009 23:49:29 +0100 (CET) Message-ID: <4B281279.6060706@quip.cz> Date: Tue, 15 Dec 2009 23:49:29 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0 MIME-Version: 1.0 To: freebsd-stable Stable Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: iSCSI initiator and Dell PowerVault MD3000i X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 22:49:34 -0000 Hi all, I am playing with iscsi_initiator on FreeBSD 7-STABLE and Dell PowerVault MD3000i. This is the first time I am testing iSCSI... Does anyone have FreeBSD's iSCSI initiator in production / heavy load? Or does somebody have experiences with Dell MD3000i? One thing is "poor performance" ~ 60 - 70MB/s depending on RAID level used. (poor performance compared to plain SATA disk which have 110MB/s - both tested for reading as it is our planned load - multimedia streaming and downloads) The other thing is some problem with compatibility of initiator and Dell MD3000i. If I setup RAID 5 'Disk Group' consisted of 4x 1TB SATA drives (in MD3000i) and then created for example 2 'Virtual Disks', both are detected by iscontrol and added to /dev/ as da0 and da1, but da1 spams log with messages like this: Dec 15 04:00:38 dust kernel: da0 at iscsi0 bus 0 target 0 lun 0 Dec 15 04:00:38 dust kernel: da0: Fixed Direct Access SCSI-5 device Dec 15 04:00:38 dust kernel: da1 at iscsi0 bus 0 target 0 lun 1 Dec 15 04:00:38 dust kernel: da1: Fixed Direct Access SCSI-5 device Dec 15 04:00:38 dust iscontrol[48576]: cam_open_btl: no passthrough device found at 0:0:2 Dec 15 04:00:38 dust iscontrol[48576]: cam_open_btl: no passthrough device found at 0:0:3 Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): READ(6)/WRITE(6) not supported, increasing minimum_cmd_size to 10. Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): CAM Status: SCSI Status Error Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): SCSI Status: Check Condition Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): ILLEGAL REQUEST asc:94,1 Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): Vendor Specific ASC Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): Unretryable error Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): READ(10). CDB: 28 0 c 7f df ff 0 0 1 0 Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): CAM Status: SCSI Status Error Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): SCSI Status: Check Condition Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): ILLEGAL REQUEST asc:94,1 Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): Vendor Specific ASC Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): Unretryable error Dec 15 04:00:41 dust kernel: (da1:iscsi0:0:0:1): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 The message repeated many times. If I created more 'Virtual Disks' (7 for example), 3 of them are producing same errors (da1, da3, da5) If there is only one 'Virtual Disk', it seems fine... until I configured second path to the virtual disk as I want to try gmultipath or geom_fox (MD3000i is dual controller with 4 NICs), then second session produces same errors. First path - OK: Dec 15 22:47:57 dust kernel: da0 at iscsi0 bus 0 target 0 lun 0 Dec 15 22:47:57 dust kernel: da0: Fixed Direct Access SCSI-5 device Dec 15 22:47:57 dust iscontrol[52226]: cam_open_btl: no passthrough device found at 0:0:1 Dec 15 22:47:57 dust iscontrol[52226]: cam_open_btl: no passthrough device found at 0:0:2 Dec 15 22:47:57 dust iscontrol[52226]: cam_open_btl: no passthrough device found at 0:0:3 Second path - error: Dec 15 22:48:04 dust kernel: da1 at iscsi0 bus 0 target 1 lun 0 Dec 15 22:48:04 dust kernel: da1: Fixed Direct Access SCSI-5 device Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): READ(6)/WRITE(6) not supported, increasing minimum_cmd_size to 10. Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): CAM Status: SCSI Status Error Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): SCSI Status: Check Condition Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): ILLEGAL REQUEST asc:94,1 Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): Vendor Specific ASC Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): Unretryable error Dec 15 22:48:05 dust iscontrol[52230]: cam_open_btl: no passthrough device found at 0:1:1 Dec 15 22:48:05 dust iscontrol[52230]: cam_open_btl: no passthrough device found at 0:1:2 Dec 15 22:48:05 dust iscontrol[52230]: cam_open_btl: no passthrough device found at 0:1:3 Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): READ(16). CDB: 88 0 0 0 0 1 5d 21 1f ff 0 0 0 1 0 0 Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): CAM Status: SCSI Status Error Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): SCSI Status: Check Condition Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): ILLEGAL REQUEST asc:94,1 Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): Vendor Specific ASC Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): Unretryable error Dec 15 22:48:07 dust kernel: (da1:iscsi0:0:1:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 Dec 15 22:48:07 dust kernel: (da1:iscsi0:0:1:0): CAM Status: SCSI Status Error Dec 15 22:48:07 dust kernel: (da1:iscsi0:0:1:0): SCSI Status: Check Condition Dec 15 22:48:07 dust kernel: (da1:iscsi0:0:1:0): ILLEGAL REQUEST asc:94,1 Dec 15 22:48:07 dust kernel: (da1:iscsi0:0:1:0): Vendor Specific ASC Dec 15 22:48:07 dust kernel: (da1:iscsi0:0:1:0): Unretryable error Dec 15 22:48:09 dust kernel: (da1:iscsi0:0:1:0): READ(10). CDB: 28 0 0 0 0 1 0 0 1 0 # main path storage_1 { initiatorname = iqn.2005-01.il.ac.huji.cs::dust.example.com TargetName = iqn.1984-05.com.dell:powervault.md3000i.60026b900042587b000000004ae58efc TargetAddress = 192.168.130.101:3260,1 tags = 64 } # second path storage_2 { initiatorname = iqn.2005-01.il.ac.huji.cs::dust.example.com TargetName = iqn.1984-05.com.dell:powervault.md3000i.60026b900042587b000000004ae58efc TargetAddress = 192.168.132.102:3260,2 tags = 64 } Can somebody advice some tweaks to get better performance and solution of the errors above? Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 22:49:45 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9323C106568D for ; Tue, 15 Dec 2009 22:49:45 +0000 (UTC) (envelope-from freebsd@insightbb.com) Received: from mxsf03.insightbb.com (mxsf03.insightbb.com [74.128.0.64]) by mx1.freebsd.org (Postfix) with ESMTP id 5F49D8FC1E for ; Tue, 15 Dec 2009 22:49:45 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwEAOaZJ0vQLicL/2dsb2JhbACBS9ZxhCsEgWKEAQ X-IronPort-AV: E=Sophos;i="4.47,402,1257138000"; d="scan'208";a="770709347" Received: from unknown (HELO asav03.insightbb.com) ([172.31.249.123]) by mxsf03.insightbb.com with ESMTP; 15 Dec 2009 17:20:43 -0500 X-IronPort-AV: E=Sophos;i="4.47,402,1257138000"; d="scan'208";a="117460808" Received: from 208-46-39-11.dia.static.qwest.net (HELO laptop2.stevenfriedrich.org) ([208.46.39.11]) by asavout03.insightbb.com with ESMTP; 15 Dec 2009 17:20:43 -0500 From: Steven Friedrich To: freebsd-stable@freebsd.org Date: Tue, 15 Dec 2009 17:20:37 -0500 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; i386; ; ) References: <4B2802AE.9090107@kernel32.de> In-Reply-To: <4B2802AE.9090107@kernel32.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200912151720.37709.freebsd@insightbb.com> Cc: Marian Hettwer Subject: Re: update to 8.0-RELEASE --> partition gone X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 22:49:45 -0000 On Tuesday 15 December 2009 04:42:06 pm Marian Hettwer wrote: > Hi Folks, > > today I did an update from 7.2-RELEASE-p4 to 8.0-RELEASE using > freebsd-update. > Everything went smooth, apart from the fact that I can't mount my second > disk. > It's all a bit puzzling... > Here are the facts: > > [root@talisker ~]# cat /etc/fstab > # Device Mountpoint FStype Options Dump Pass# > /dev/ad4s2b none swap sw O O > /dev/ad4s1a / ufs rw 1 1 > /dev/ad4s2a /tmp ufs rw 2 2 > /dev/ad4s2d /var ufs rw 2 2 > /dev/ad4s2e /usr ufs rw 2 2 > /dev/ad8s1a /BACKUP ufs rw 2 2 > /dev/acd0 /cdrom cd9660 ro,noauto 0 0 > linproc /compat/linux/proc linprocfs rw 0 0 > > The offending entry which isn't mountable anymore is ad8s1. > [root@talisker ~]# sysctl kern.disks > kern.disks: ad8 ad4 > > fdisk and bsdlabel are showing my s1a partition/slice: > [root@talisker ~]# fdisk ad8 > ******* Working on device /dev/ad8 ******* > parameters extracted from in-core disklabel are: > cylinders=775221 heads=16 sectors/track=63 (1008 blks/cyl) > > Figures below won't work with BIOS for partitions not in cyl 1 > parameters to be used for BIOS calculations are: > cylinders=775221 heads=16 sectors/track=63 (1008 blks/cyl) > > Media sector size is 512 > Warning: BIOS sector numbering starts with sector 1 > Information from DOS bootblock is: > The data for partition 1 is: > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > start 63, size 781422705 (381554 Meg), flag 80 (active) > beg: cyl 0/ head 1/ sector 1; > end: cyl 52/ head 15/ sector 63 > The data for partition 2 is: > > The data for partition 3 is: > > The data for partition 4 is: > > [root@talisker ~]# bsdlabel ad8 > # /dev/ad8: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > a: 781422752 16 unused 0 0 > c: 781422768 0 unused 0 0 # "raw" part, > don't edit > > but: > [root@talisker ~]# mount /dev/ad8s1a /BACKUP/ > mount: /dev/ad8s1a : No such file or directory > > And in fact: > [root@talisker ~]# ls -l /dev/ad8* > crw-r----- 1 root operator 0, 91 Dec 15 17:58 /dev/ad8 > crw-r----- 1 root operator 0, 96 Dec 15 17:58 /dev/ad8a > > Huu? What's going on here? Where is s1? > Never seen that before... (and I'm using FreeBSD since 4.0-RELEASE). > and this mount obviously won't work either: > [root@talisker ~]# mount /dev/ad8a /BACKUP/ > mount: /dev/ad8a : Invalid argument > > Anybody any idea how to recover here? > The server is unluckily remote and in production. A downgrade back to > 7.2 would be kinda difficult. I'd like to avoid that. > > Ideas anyone? > > Thanks in advance, > Marian > > PS.: > dmesg: http://crivens.terrorteam.de/~rabauke/FreeBSD/dmesg-8.0-release.txt > [root@talisker ~]# uname -rms > FreeBSD 8.0-RELEASE i386 > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > FreeBSD 8.0 no longer supports "dangerously dedicated" disks. Is this your issue? fdisk output appears to indicate that your disk has a partition table, but I never looked at one with fdisk that was "dedicated"... From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 22:58:33 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86FA5106566C; Tue, 15 Dec 2009 22:58:33 +0000 (UTC) (envelope-from pusateri@bangj.com) Received: from jj.bangj.com (jj.bangj.com [198.86.87.199]) by mx1.freebsd.org (Postfix) with ESMTP id 2845B8FC15; Tue, 15 Dec 2009 22:58:33 +0000 (UTC) Received: from [172.16.10.11] (cpe-066-026-040-218.nc.res.rr.com [66.26.40.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by jj.bangj.com (Postfix) with ESMTPSA id 4D2383A1; Tue, 15 Dec 2009 17:58:30 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Tom Pusateri In-Reply-To: Date: Tue, 15 Dec 2009 17:58:31 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <9223.83.206.131.26.1260781902.squirrel@webmail.esigetel.fr><5ED6B687-4191-4B11-A2F7-B01F67FB9D16@bangj.com> To: "Li, Qing" X-Mailer: Apple Mail (2.1077) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: patch: bad ipv6 neighbor solicitation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 22:58:33 -0000 You are correct. I added the route and it works fine. route add -inet6 2610:28:1800:4001::/64 -iface em0 Thanks, Tom On Dec 15, 2009, at 5:00 PM, Li, Qing wrote: > Thanks for sending me the routing table output. > > Actually I believe both your problems are indeed related to the > prefix route. > > I was able to reproduce Dennis Glatting's problem, which was due > to one of the prefix entry being off-link. > > In your case the prefix route for 2610:28:1800:4001:20e:cff:fe9f:faad > disappeared and is not in the routing table. If you add the route > by hand the problem should go away. > > I guess the question is what triggered the prefix route deletion. > > -- Qing > > >> -----Original Message----- >> From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- >> stable@freebsd.org] On Behalf Of Li, Qing >> Sent: Tuesday, December 15, 2009 1:46 PM >> To: Tom Pusateri >> Cc: freebsd-net@freebsd.org; freebsd-stable@freebsd.org >> Subject: RE: patch: bad ipv6 neighbor solicitation >> >> Thanks for reporting back. I asked you for a routing table dump >> in my previous email, would you mind emailing it to me privately? >> >> -- Qing >> >> >>> -----Original Message----- >>> From: Tom Pusateri [mailto:pusateri@bangj.com] >>> Sent: Tuesday, December 15, 2009 1:28 PM >>> To: Li, Qing >>> Cc: freebsd-net@freebsd.org; freebsd-stable@freebsd.org >>> Subject: Re: patch: bad ipv6 neighbor solicitation >>> >>> I didn't think this routing patch was related to the "bad neighbor >>> solicitation messages" as suggested in the subject field but I tried >> it >>> anyway. It does not fix my IPv6 problem. I still get "bad neighbor >>> solicitation messages" and freebsd 8 doesn't respond to 4/5 IPv6 >> pings. >>> >>> Thanks, >>> Tom >>> >>> On Dec 14, 2009, at 11:53 PM, Li, Qing wrote: >>> >>>> Please find the more proper fix at >>>> >>>> http://people.freebsd.org/~qingli/nd6-patch.diff >>>> >>>> I realized I was slightly off in my previous email after >>>> I spent a bit more time looking through the problem. >>>> Both prefixes are present but one was marked off-link due >>>> to the fact only a single prefix route was installed in >>>> the routing table (non RADIX_MPATH system). >>>> >>>> I evaluated various options to fixing this issue, however, >>>> due to the association between NDPRF_ONLINK and the route >>>> installation, I decided to go with what I have here for >>>> the time being. >>>> >>>> I have verified the fix in my setup. Please apply the >>>> patch and report back. >>>> >>>> Thanks, >>>> >>>> -- Qing >>>> >>>> >>>>> -----Original Message----- >>>>> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- >>>>> net@freebsd.org] On Behalf Of Li, Qing >>>>> Sent: Monday, December 14, 2009 3:00 PM >>>>> To: Dennis Glatting; JASSAL Aman >>>>> Cc: freebsd-net@freebsd.org >>>>> Subject: RE: Understanding multiple IPv6 interfaces under 8.0 > (fwd) >>>>> >>>>> >>>>> You don't need to perform all that route-foo. I believe the root >>> cause >>>>> of >>>>> this issue may be due to a bit of regression in the IPv6 prefix >>>>> management >>>>> code, and I am in the process of putting together a permanent > fix. >>>>> >>>>> The issue as it stands today, is due to how the prefix was >> inserted >>> in >>>>> the first place. Since bce0 was configured first, the interface >>>>> associated >>>>> with the prefix is bce0. Later the reference count on the prefix >> is >>>>> simply incremented when bce1 configures another IPv6 address of >> the >>>>> same prefix. >>>>> >>>>> When ND6 NS arrives for bce1, due to the interface mismatch of > the >>>>> prefix >>>>> interface against the input interface, the NS packet was >> considered >>>>> invalid and thus dropped. >>>>> >>>>> Again, in case you didn't see my earlier reply, try the temporary >>> hack >>>>> at >>>>> http://people.freebsd.org/~qingli/nd6-ns.diff >>>>> >>>>> until I commit a permanent patch. The problem was easily >>> reproducible >>>>> and >>>>> I have verified with limited unit testing the patch works. >>>>> >>>>> -- Qing >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: owner-freebsd-net@freebsd.org on behalf of Dennis Glatting >>>>> Sent: Mon 12/14/2009 2:03 PM >>>>> To: JASSAL Aman >>>>> Cc: freebsd-net@freebsd.org >>>>> Subject: Re: Understanding multiple IPv6 interfaces under 8.0 > (fwd) >>>>> >>>>> >>>>> Thanks. Responses in-line. >>>>> >>>>> >>>>> >>>>> On Mon, 14 Dec 2009, JASSAL Aman wrote: >>>>> >>>>>> Hello Mr.Glatting, >>>>>> >>>>>> Not that I'm an IPv6 genius, but at first sight your problem >> seems >>>> to >>>>> be a >>>>>> route-related. I've put comments in-line. >>>>>> >>>>>> >>>>>> Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : >>>>>>> >>>>>>> >>>>>>> Elmer# netstat -rn >>>>>>> Routing tables >>>>>>> >>>>>>> >>>>>>> Internet6: >>>>>>> Destination Gateway >>>>> Flags >>>>>>> Netif Expire >>>>>>> ::/96 ::1 >>>> UGRS >>>>>>> lo0 => default fd7c:3f2b:e791:1::1 >>>>>>> UGS bce0 >>>>>>> ::1 ::1 >> UH >>>>>>> lo0 ::ffff:0.0.0.0/96 ::1 >>>>> UGRS >>>>>>> lo0 fd7c:3f2b:e791:1::/64 link#1 >>>>> U >>>>>>> bce0 fd7c:3f2b:e791:1::ac13:a0a link#1 >>>>> UHS >>>>>>> lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 >>>>> UHS >>>>>>> lo0 fe80::/10 ::1 >>>>> UGRS >>>>>>> lo0 fe80::%bce0/64 link#1 >>>>> U >>>>>>> bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 >>>>> UHS >>>>>>> lo0 fe80::%bce1/64 link#2 >>>>> U >>>>>>> bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 >>>>> UHS >>>>>>> lo0 fe80::%lo0/64 link#3 >>>>> U >>>>>>> lo0 fe80::1%lo0 link#3 >>>>> UHS >>>>>>> lo0 ff01:1::/32 >>> fe80::213:72ff:fe60:ac52%bce0 >>>>> U >>>>>>> bce0 ff01:2::/32 >>>> fd7c:3f2b:e791:1:0:1:ac13:a0a >>>>> U >>>>>>> bce1 ff01:3::/32 ::1 >>>>> U >>>>>>> lo0 ff02::/16 ::1 >>>>> UGRS >>>>>>> lo0 ff02::%bce0/32 >>> fe80::213:72ff:fe60:ac52%bce0 >>>>> U >>>>>>> bce0 ff02::%bce1/32 >>>> fd7c:3f2b:e791:1:0:1:ac13:a0a >>>>> U >>>>>>> bce1 ff02::%lo0/32 ::1 >>>>> U >>>>>>> lo0 >>>>>>> >>>>>> >>>>>> Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. > I >>>> was >>>>>> expecting bce1 rather than lo0, I suppose you were as well :) If >>> I'm >>>>> not >>>>>> mistaken, the packets emanating from bce1 go to the loopback >>>>> interface, >>>>>> thus not really going out. You can try specifying the route >>> manually >>>>>> with "route add *your parameters*" or even set it in > /etc/rc.conf >>> so >>>>>> that it's loaded at boot-time. There's no reason why among 2 >>>> physical >>>>>> interfaces sharing the same fabric, one can ship packets out and >>> the >>>>>> other can't. >>>>>> >>>>> >>>>> I was wondering about the route however I haven't figured out the >>>> trick >>>>> to >>>>> get what I want. For example: >>>>> >>>>> Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a >>>>> delete host fd7c:3f2b:e791:1:0:1:ac13:a0a >>>>> >>>>> Elmer# route add >>>>> -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 >>>>> route: writing to routing socket: File exists >>>>> add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route >>> already >>>>> in table >>>>> >>>>> I did delete the lo0 route before I exected the above command. >> Also, >>> I >>>>> haven't been able to specify a higher metric (e.g., -metric 2). >> That >>>> is >>>>> rejected too. However, I can say: >>>>> >>>>> Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a >>>>> delete host fd7c:3f2b:e791:1:0:1:ac13:a0a >>>>> >>>>> Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a -iface bce1 >>>>> add host fd7c:3f2b:e791:1:0:1:ac13:a0a: gateway bce1 >>>>> >>>>> Elmer# netstat -rn >>>>> (snip) >>>>> fd7c:3f2b:e791:1:0:1:ac13:a0a 00:13:72:60:ac:50 >> UHS >>>>> bce1 >>>>> >>>>> I don't think that is what I want. WHat I think I just said is >> "host >>>> X" >>>>> is >>>>> out that door, rather than route net. If, however, I say Docs is >> out >>>>> that >>>>> door, I get: >>>>> >>>>> Elmer# route add -inet6 docs.dco.penx.com -iface bce1 >>>>> add host docs.dco.penx.com: gateway bce1 >>>>> >>>>> Elmer# ping6 >>>>> docs.penx.com >>>>> PING6(56=40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> >>>>> fd7c:3f2b:e791:1::ac13:a15 >>>>> ping6: sendmsg: Operation not permitted >>>>> ping6: wrote docs.dco.penx.com 16 chars, ret=-1 >>>>> >>>>> >>>>>>> >>>>>>> Elmer's rc.config: >>>>>>> >>>>>>> >>>>>>> ipv6_enable="YES" ipv6_network_interfaces="bce0 bce1" >>>>>>> ipv6_ifconfig_bce0="FD7C:3F2B:E791:0001::0:172.19.10.10 >> prefixlen >>>>> 64" >>>>>>> ipv6_ifconfig_bce1="FD7C:3F2B:E791:0001::1:172.19.10.10 >> prefixlen >>>> 64 >>>>> mtu >>>>>>> 8192" >>>>>>> ipv6_defaultrouter="FD7C:3F2B:E791:0001::1" >>>>>>> >>>>>> >>>>>> Erm... You're using IPv4 addresses encapsulated in IPv6 ? I've >>> never >>>>> used >>>>>> this myself so I can't really comment, and I can't say if there >>>>> aren't any >>>>>> sort of "interferences" with what you're trying to do. >>>>>> >>>>> >>>>> I hope what I am specifying is to use the 32 bit IPv4 address as >> the >>>>> last >>>>> 32 bits of the IPv6 address, at least that is how it works out >>>>> numerically. My numbering scheme for fixed assets is the last 32 >>> bits >>>>> of >>>>> the 128 bit IPv6 address is the same as its IPv4 address. >>>>> >>>>> >>>>>>> >>>>>>> >>>>>>> The router (cisco): >>>>>>> >>>>>>> >>>>>>> interface GigabitEthernet0/0 ipv6 address > FD7C:3F2B:E791:1::1/64 >>>>> ipv6 >>>>>>> enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) >>>>>>> >>>>>> >>>>>> Just a side-note, I'm not sure if it will be really useful to > you, >>>>> but you >>>>>> could give it a try if you want to. Have you tried using your >> Cisco >>>>> router >>>>>> as a Router Advertisement Daemon ? That way, addresses would be >>>> built >>>>>> automatically and you could see how both interfaces react to > such >>>>>> advertisements. >>>>>> >>>>>> I hope this helps. >>>>>> >>>>>> ------------ >>>>>> Aman Jassal >>>>>> >>>>>> Wisdom comes from experience. >>>>>> Experience comes from a lack of wisdom. >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> freebsd-net@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>> To unsubscribe, send any mail to "freebsd-net- >>> unsubscribe@freebsd.org" >>>>> >>>>> _______________________________________________ >>>>> freebsd-net@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>> To unsubscribe, send any mail to "freebsd-net- >>> unsubscribe@freebsd.org" >>>> _______________________________________________ >>>> freebsd-stable@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>> To unsubscribe, send any mail to "freebsd-stable- >>> unsubscribe@freebsd.org" >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable- >> unsubscribe@freebsd.org" > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 23:21:32 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FD7B1065693 for ; Tue, 15 Dec 2009 23:21:32 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id F039C8FC08 for ; Tue, 15 Dec 2009 23:21:31 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp023.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KUP00EYOVJDHT40@asmtp023.mac.com> for freebsd-stable@freebsd.org; Tue, 15 Dec 2009 15:21:17 -0800 (PST) From: Marcel Moolenaar In-reply-to: <200912151720.37709.freebsd@insightbb.com> Date: Tue, 15 Dec 2009 15:21:13 -0800 Message-id: <4678E8AE-B873-460A-B126-420B9A06B875@mac.com> References: <4B2802AE.9090107@kernel32.de> <200912151720.37709.freebsd@insightbb.com> To: Steven Friedrich X-Mailer: Apple Mail (2.1077) Cc: freebsd-stable@freebsd.org, Marian Hettwer Subject: Re: update to 8.0-RELEASE --> partition gone X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 23:21:32 -0000 On Dec 15, 2009, at 2:20 PM, Steven Friedrich wrote: >> > FreeBSD 8.0 no longer supports "dangerously dedicated" disks. This is not true. The problem is that sysinstall creates an invalid "dangerously dedicated" disk, as demonstrated by doing: # fdisk ad8 (shows FreeBSD slice information) # bsdlabel ad8 (shows valid but empty disk label) Marian just needs to wipe out the second sector on the disk to remove the BSD disklabel that prevents the kernel from using the master boot record in the 1st sector. This exposes ad8s1. This then will pick up the BSD disklabel in sector 65 (i.e. the second sector in slice 1) to give ad8s1a... > fdisk output appears to indicate that your disk has a partition table, but I > never looked at one with fdisk that was "dedicated"... fdisk may or may not show partitions. Typically there should not be any, because it's the disklabel in sector 2 that holds the partition information. The "MBR" in the first sector is there only for the BIOS: you can't boot without one. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-stable@FreeBSD.ORG Tue Dec 15 23:37:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34FA6106566C; Tue, 15 Dec 2009 23:37:18 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 19CFC8FC13; Tue, 15 Dec 2009 23:37:18 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBFNbHq6020534; Tue, 15 Dec 2009 15:37:17 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Dec 2009 15:37:06 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: net/mpd5, ppp, proxy-arp issues Thread-Index: Acp934LhgJ2LhcpOScatB1tE2Gb5UQ== From: "Li, Qing" To: , Cc: Qing Li , freebsd-current@freebsd.org Subject: net/mpd5, ppp, proxy-arp issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 23:37:18 -0000 Hi, Recently there have been several reports regarding issues with ppp, mpd5 and proxy-arp configuration over the ppp links. I read through the various postings and the problems seem to be: 1. Unable to add proxy-arp entries for the remote ppp clients. 2. Log showing "ifa_add_loopback_route: insertion failed" causing=20 some userland applications to fail. May I ask that you try applying patch http://people.freebsd.org/~qingli/ppp-proxy-arp-patch-121515.diff and report back if the patch fixes your problems. And if not,=20 please describe what additional issues you are having. Thanks, -- Qing From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 00:08:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11161106566B for ; Wed, 16 Dec 2009 00:08:11 +0000 (UTC) (envelope-from ben@morrow.me.uk) Received: from relay.pcl-ipout01.plus.net (relay.pcl-ipout01.plus.net [212.159.7.99]) by mx1.freebsd.org (Postfix) with ESMTP id A25C98FC16 for ; Wed, 16 Dec 2009 00:08:09 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwEAK+zJ0vUOFPl/2dsb2JhbACBS9ZIhCsE Received: from plesk-mail01.plus.net ([212.56.83.229]) by relay.pcl-ipout01.plus.net with ESMTP; 16 Dec 2009 00:08:08 +0000 Received: (qmail 31913 invoked from network); 16 Dec 2009 00:08:06 +0000 Received: from host86-146-192-188.range86-146.btcentralplus.com (HELO osiris.mauzo.dyndns.org) (86.146.192.188) by plesk-mail01.plus.net with SMTP; 16 Dec 2009 00:08:04 +0000 Received: (qmail 39700 invoked by uid 1001); 16 Dec 2009 00:08:03 -0000 Date: Wed, 16 Dec 2009 00:08:03 +0000 From: Ben Morrow To: xcllnt@mac.com, freebsd-stable@freebsd.org Message-ID: <20091216000803.GA39686@osiris.mauzo.dyndns.org> Mail-Followup-To: xcllnt@mac.com, freebsd-stable@freebsd.org References: <4B2802AE.9090107@kernel32.de> <200912151720.37709.freebsd@insightbb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4678E8AE-B873-460A-B126-420B9A06B875@mac.com> X-Newsgroups: gmane.os.freebsd.stable Organization: Who, me? User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: update to 8.0-RELEASE --> partition gone X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 00:08:11 -0000 Quoth Marcel Moolenaar : > On Dec 15, 2009, at 2:20 PM, Steven Friedrich wrote: > >> > > FreeBSD 8.0 no longer supports "dangerously dedicated" disks. > > This is not true. The problem is that sysinstall creates an invalid > "dangerously dedicated" disk, as demonstrated by doing: > # fdisk ad8 > (shows FreeBSD slice information) > > # bsdlabel ad8 > (shows valid but empty disk label) > > Marian just needs to wipe out the second sector on the disk to > remove the BSD disklabel that prevents the kernel from using > the master boot record in the 1st sector. This exposes ad8s1. > This then will pick up the BSD disklabel in sector 65 (i.e. > the second sector in slice 1) to give ad8s1a... Are you able to clarify exactly what is no longer working in 8? I've read things here and there about dangerously dedicated disks no longer being supported, but no detail about what exactly had changed. You seem to be implying here that there is only a problem if there are invalid and/or overlapping labels on the disk; elsewhere I have read that disks without an MBR aren't supported at all (I presume the faked-up MBR on a GPT disk counts). If I currently have a working ad2{b,c,d,e}, will they be picked up by 8, or would I have to repartition slightly smaller with a useless MBR slice in front? Ben From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 00:42:39 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FAC8106566C for ; Wed, 16 Dec 2009 00:42:39 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0340C8FC13 for ; Wed, 16 Dec 2009 00:42:38 +0000 (UTC) Received: by pxi12 with SMTP id 12so315924pxi.3 for ; Tue, 15 Dec 2009 16:42:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=38x5ewdf8x57M6cW9FKZ0jlJj0v4pOXBwoGlGXC2NIE=; b=WTrG0t7UTmIAsRyXWO8ThoFkJEHRTGf47DpYi4BAqCtvJ/tLjJZpY68dWwcehdUWcW 0qw6IGCrZOF9E33lJq8d4FBe18yapnfppglta0otigEDpFH+iQQuij7d1Ji0jYB++hoX h/KX4Km1Psx/alc0ToYHpMgycf2htdAIM8UZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=M+2WtML70Q64fUNQDqJ9AEJJnZUHSdINNO6J0IjoYfRjcPQPVU0CqkDQp+4xPo2dKg 0ksvjU84s3DQCOuWUfz+cNlaEP62URpXsGwiKAAFlYhBvpccRDUqkuxHxSWqVZ60xqw2 aMC9Loh6n/q4AZ9GBX2b0JxMUak02H3LNlUn8= MIME-Version: 1.0 Received: by 10.115.101.18 with SMTP id d18mr174552wam.191.1260924158567; Tue, 15 Dec 2009 16:42:38 -0800 (PST) In-Reply-To: <20091216000803.GA39686@osiris.mauzo.dyndns.org> References: <4B2802AE.9090107@kernel32.de> <200912151720.37709.freebsd@insightbb.com> <4678E8AE-B873-460A-B126-420B9A06B875@mac.com> <20091216000803.GA39686@osiris.mauzo.dyndns.org> Date: Tue, 15 Dec 2009 16:42:38 -0800 Message-ID: From: Xin LI To: xcllnt@mac.com, freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: update to 8.0-RELEASE --> partition gone X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 00:42:39 -0000 On Tue, Dec 15, 2009 at 4:08 PM, Ben Morrow wrote: > Quoth Marcel Moolenaar : >> On Dec 15, 2009, at 2:20 PM, Steven Friedrich wrote: >> >> >> > FreeBSD 8.0 no longer supports "dangerously dedicated" disks. >> >> This is not true. The problem is that sysinstall creates an invalid >> "dangerously dedicated" disk, as demonstrated by doing: >> =C2=A0 =C2=A0 =C2=A0 # fdisk ad8 >> =C2=A0 =C2=A0 =C2=A0 (shows FreeBSD slice information) >> >> =C2=A0 =C2=A0 =C2=A0 # bsdlabel ad8 >> =C2=A0 =C2=A0 =C2=A0 (shows valid but empty disk label) >> >> Marian just needs to wipe out the second sector on the disk to >> remove the BSD disklabel that prevents the kernel from using >> the master boot record in the 1st sector. This exposes ad8s1. >> This then will pick up the BSD disklabel in sector 65 (i.e. >> the second sector in slice 1) to give ad8s1a... > > Are you able to clarify exactly what is no longer working in 8? I've > read things here and there about dangerously dedicated disks no longer > being supported, but no detail about what exactly had changed. You seem > to be implying here that there is only a problem if there are invalid > and/or overlapping labels on the disk; elsewhere I have read that disks > without an MBR aren't supported at all (I presume the faked-up MBR on a > GPT disk counts). If I currently have a working ad2{b,c,d,e}, will they > be picked up by 8, or would I have to repartition slightly smaller with > a useless MBR slice in front? My $0.02: what about labelling them, say, tunefs -L on UFS partitions, and glabel for swap, then change corresponding entry in fstab. Say: - Start into single user - tunefs -L root / - reboot into single user <--- reboot required after tuning / - mount -u /; mount -a - vi /etc/fstab and change "/dev/ad0a" to "/dev/ufs/root" - umount -a - tunefs -L other partitions - mount -a - vi /etc/fstab and change the rest - reboot Cheers, --=20 Xin LI http://www.delphij.net From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 00:47:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFEA11065672 for ; Wed, 16 Dec 2009 00:47:12 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout030.mac.com (asmtpout030.mac.com [17.148.16.105]) by mx1.freebsd.org (Postfix) with ESMTP id AAE488FC15 for ; Wed, 16 Dec 2009 00:47:12 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [172.24.241.130] (natint3.juniper.net [66.129.224.36]) by asmtp030.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KUP005EHZHFNY20@asmtp030.mac.com> for freebsd-stable@freebsd.org; Tue, 15 Dec 2009 16:46:30 -0800 (PST) From: Marcel Moolenaar In-reply-to: <20091216000803.GA39686@osiris.mauzo.dyndns.org> Date: Tue, 15 Dec 2009 16:46:27 -0800 Message-id: <7BA0C6CC-A1D9-49C2-942D-D46C19E9B3CB@mac.com> References: <4B2802AE.9090107@kernel32.de> <200912151720.37709.freebsd@insightbb.com> <20091216000803.GA39686@osiris.mauzo.dyndns.org> To: Ben Morrow X-Mailer: Apple Mail (2.1077) Cc: freebsd-stable@freebsd.org Subject: Re: update to 8.0-RELEASE --> partition gone X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 00:47:12 -0000 On Dec 15, 2009, at 4:08 PM, Ben Morrow wrote: > Quoth Marcel Moolenaar : >> On Dec 15, 2009, at 2:20 PM, Steven Friedrich wrote: >>>> >>> FreeBSD 8.0 no longer supports "dangerously dedicated" disks. >> >> This is not true. The problem is that sysinstall creates an invalid >> "dangerously dedicated" disk, as demonstrated by doing: >> # fdisk ad8 >> (shows FreeBSD slice information) >> >> # bsdlabel ad8 >> (shows valid but empty disk label) >> >> Marian just needs to wipe out the second sector on the disk to >> remove the BSD disklabel that prevents the kernel from using >> the master boot record in the 1st sector. This exposes ad8s1. >> This then will pick up the BSD disklabel in sector 65 (i.e. >> the second sector in slice 1) to give ad8s1a... > > Are you able to clarify exactly what is no longer working in 8? Everything is working, but behaviour has changed for invalid disks. Invalid disks are disks with conflicting partitioning information. In FreeBSD 8.x the behaviour is deterministic and for the broken dangerously dedicated disks that sysinstall creates this means that we use the partition information in the BSD disklabel. In FreeBSD 7.x this could come from either the MBR or the BSD disklabel, with the MBR the more common scenario. > You seem > to be implying here that there is only a problem if there are invalid > and/or overlapping labels on the disk; elsewhere I have read that disks > without an MBR aren't supported at all (I presume the faked-up MBR on a > GPT disk counts). Disks without an MBR are supported. > If I currently have a working ad2{b,c,d,e}, will they > be picked up by 8, or would I have to repartition slightly smaller with > a useless MBR slice in front? Yes, if you have ad2a and not ad2s1a, then you have a proper dangerously dedicated disk and FreeBSD 8.x will work correctly with your disk. If you installed "dangerously dedicated" and ended up with ad0s1a (note the "s1"), then you have an invalid partitioning and FreeBSD 8.x will not give you what you've been getting on FreeBSD 7.x. Most of the time you only need to wipe out the second sector on the disk to clean it up and have FreeBSD 8.x also give you ad0s1a. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 01:25:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8D97106566B for ; Wed, 16 Dec 2009 01:25:27 +0000 (UTC) (envelope-from ben@morrow.me.uk) Received: from relay.pcl-ipout02.plus.net (relay.pcl-ipout02.plus.net [212.159.7.100]) by mx1.freebsd.org (Postfix) with ESMTP id 532348FC23 for ; Wed, 16 Dec 2009 01:25:27 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwEAG7GJ0vUOFPl/2dsb2JhbACBS9VNhCsE Received: from plesk-mail01.plus.net ([212.56.83.229]) by relay.pcl-ipout02.plus.net with ESMTP; 16 Dec 2009 01:25:24 +0000 Received: (qmail 28634 invoked from network); 16 Dec 2009 01:25:24 +0000 Received: from host86-146-192-188.range86-146.btcentralplus.com (HELO osiris.mauzo.dyndns.org) (86.146.192.188) by plesk-mail01.plus.net with SMTP; 16 Dec 2009 01:25:24 +0000 Received: (qmail 39978 invoked by uid 1001); 16 Dec 2009 01:25:23 -0000 Date: Wed, 16 Dec 2009 01:25:23 +0000 From: Ben Morrow To: delphij@gmail.com, freebsd-stable@freebsd.org Message-ID: <20091216012523.GA39968@osiris.mauzo.dyndns.org> Mail-Followup-To: delphij@gmail.com, freebsd-stable@freebsd.org References: <4B2802AE.9090107@kernel32.de> <200912151720.37709.freebsd@insightbb.com> <4678E8AE-B873-460A-B126-420B9A06B875@mac.com> <20091216000803.GA39686@osiris.mauzo.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Newsgroups: gmane.os.freebsd.stable Organization: Who, me? User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: update to 8.0-RELEASE --> partition gone X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 01:25:27 -0000 Quoth Xin LI : > On Tue, Dec 15, 2009 at 4:08 PM, Ben Morrow wrote: > > > > Are you able to clarify exactly what is no longer working in 8? I've > > read things here and there about dangerously dedicated disks no longer > > being supported, but no detail about what exactly had changed. You seem > > to be implying here that there is only a problem if there are invalid > > and/or overlapping labels on the disk; elsewhere I have read that disks > > without an MBR aren't supported at all (I presume the faked-up MBR on a > > GPT disk counts). If I currently have a working ad2{b,c,d,e}, will they > > be picked up by 8, or would I have to repartition slightly smaller with > > a useless MBR slice in front? > > My $0.02: what about labelling them, say, tunefs -L on UFS partitions, > and glabel for swap, then change corresponding entry in fstab. Say: Yes, I've already done that. However, if gpart doesn't pick up the underlying ad2d partition glabel won't know to look for a label, so the entry in /dev/ufs won't show up either. Ben From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 01:31:21 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60A33106566B for ; Wed, 16 Dec 2009 01:31:21 +0000 (UTC) (envelope-from ben@morrow.me.uk) Received: from relay.ptn-ipout02.plus.net (relay.ptn-ipout02.plus.net [212.159.7.36]) by mx1.freebsd.org (Postfix) with ESMTP id F05748FC1A for ; Wed, 16 Dec 2009 01:31:20 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwEAF7HJ0vUOFPl/2dsb2JhbACBS9VmhCsE Received: from plesk-mail01.plus.net ([212.56.83.229]) by relay.ptn-ipout02.plus.net with ESMTP; 16 Dec 2009 01:31:19 +0000 Received: (qmail 29957 invoked from network); 16 Dec 2009 01:31:18 +0000 Received: from host86-146-192-188.range86-146.btcentralplus.com (HELO osiris.mauzo.dyndns.org) (86.146.192.188) by plesk-mail01.plus.net with SMTP; 16 Dec 2009 01:31:18 +0000 Received: (qmail 39999 invoked by uid 1001); 16 Dec 2009 01:31:18 -0000 Date: Wed, 16 Dec 2009 01:31:18 +0000 From: Ben Morrow To: xcllnt@mac.com, freebsd-stable@freebsd.org Message-ID: <20091216013118.GA39982@osiris.mauzo.dyndns.org> Mail-Followup-To: xcllnt@mac.com, freebsd-stable@freebsd.org References: <4B2802AE.9090107@kernel32.de> <200912151720.37709.freebsd@insightbb.com> <20091216000803.GA39686@osiris.mauzo.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7BA0C6CC-A1D9-49C2-942D-D46C19E9B3CB@mac.com> X-Newsgroups: gmane.os.freebsd.stable Organization: Who, me? User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: update to 8.0-RELEASE --> partition gone X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 01:31:21 -0000 Quoth Marcel Moolenaar : > On Dec 15, 2009, at 4:08 PM, Ben Morrow wrote: > > Quoth Marcel Moolenaar : > >> On Dec 15, 2009, at 2:20 PM, Steven Friedrich wrote: > >>>> > >>> FreeBSD 8.0 no longer supports "dangerously dedicated" disks. > >> > >> This is not true. The problem is that sysinstall creates an invalid > >> "dangerously dedicated" disk, as demonstrated by doing: > > > > Are you able to clarify exactly what is no longer working in 8? > > Everything is working, but behaviour has changed for invalid > disks. Right. However, if I were to take a system that worked with 7.x and upgrade, and found that the disks were no longer detected, I would consider that to be 'not working' :). > Invalid disks are disks with conflicting partitioning > information. In FreeBSD 8.x the behaviour is deterministic > and for the broken dangerously dedicated disks that sysinstall > creates this means that we use the partition information in > the BSD disklabel. In FreeBSD 7.x this could come from either > the MBR or the BSD disklabel, with the MBR the more common > scenario. OK, so this is all actually about a bug in sysinstall. It might be nice if the UPDATING entry mentioned this: as it stands it is not clear this doesn't affect people who created proper disklabels by hand (including the obligatory dd to wipe out old MBR labels before starting). > > If I currently have a working ad2{b,c,d,e}, will they > > be picked up by 8, or would I have to repartition slightly smaller with > > a useless MBR slice in front? > > Yes, if you have ad2a and not ad2s1a, then you have a > proper dangerously dedicated disk and FreeBSD 8.x will > work correctly with your disk. Thank you for explaining. Ben From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 02:21:55 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 747E8106566B for ; Wed, 16 Dec 2009 02:21:55 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id CEA7B8FC19 for ; Wed, 16 Dec 2009 02:21:54 +0000 (UTC) Received: from inchoate.gsoft.com.au ([203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id nBG2LqOv009107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 16 Dec 2009 12:51:52 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Wed, 16 Dec 2009 12:51:49 +1030 User-Agent: KMail/1.9.10 References: <4B2802AE.9090107@kernel32.de> <20091216000803.GA39686@osiris.mauzo.dyndns.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart54825586.urIJEOToG2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200912161251.50660.doconnor@gsoft.com.au> X-Spam-Score: -3.228 () ALL_TRUSTED,BAYES_00,SUBJECT_FUZZY_TION X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: xcllnt@mac.com Subject: Re: update to 8.0-RELEASE --> partition gone X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 02:21:55 -0000 --nextPart54825586.urIJEOToG2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 16 Dec 2009, Xin LI wrote: > My $0.02: what about labelling them, say, tunefs -L on UFS > partitions, and glabel for swap, then change corresponding entry in > fstab. =C2=A0Say: > > =C2=A0- Start into single user > =C2=A0- tunefs -L root / > =C2=A0- reboot into single user <--- reboot required after tuning / > =C2=A0- mount -u /; mount -a > =C2=A0- vi /etc/fstab and change "/dev/ad0a" to "/dev/ufs/root" > =C2=A0- umount -a > =C2=A0- tunefs -L other partitions > =C2=A0- mount -a > =C2=A0- vi /etc/fstab and change the rest > =C2=A0- reboot If you use the UFS ID label instead you don't need to reboot because you=20 don't modify the superblock :) You can find the ID with.. line=3D`dumpfs 2> /dev/null $1 | head | grep superblock\ location` # dumpfs doesn't print leading 0s echo $line | sed -nEe 's/superblock location.*id.*\[ (.*)(.*)\ ]/printf %0x= $((0x\1 << 32 | 0x\2))/p' (in an sh like shell) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart54825586.urIJEOToG2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLKEQ+5ZPcIHs/zowRAloIAKClIxPMFso1vdD2gHRur2aguelQrwCeKgcp yOQcTGJ357WdGPvy2Bi0Ge0= =xykH -----END PGP SIGNATURE----- --nextPart54825586.urIJEOToG2-- From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 02:31:33 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E8DA1065697 for ; Wed, 16 Dec 2009 02:31:33 +0000 (UTC) (envelope-from askjuise@gmail.com) Received: from mail-vw0-f173.google.com (mail-vw0-f173.google.com [209.85.212.173]) by mx1.freebsd.org (Postfix) with ESMTP id 560298FC1D for ; Wed, 16 Dec 2009 02:31:33 +0000 (UTC) Received: by vws3 with SMTP id 3so158061vws.3 for ; Tue, 15 Dec 2009 18:31:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=5qLYfgLnzI1IGtJc/hKwGLQn+JkXUZyiDkP9jnw05f4=; b=DyerQuBR1zqgnzq0eTTKrrSwAiXN/tI5C6WPV277R62LuCu3UK0NuUIV5eP6ruIi1Z TMp2/6LsaA6v0QakmVsvdGE8t3ZMOYmWwStPV7GpM5TuJHowyUb8Zp3IPHFeoyn7jp4N s2bR5JXHQaYCmoqZQUuKcmY/dT9rJRdhlMwiM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=nG+tMel7q9FbJ6z5SunXNHvTMLR2/w5K+Xo8xuWVsbt5U3T4ruWXdAwlD1m7u7Bvgl m/HkKjro/j961uoISAUS/sJRytk68MbI1+6DtYZ6iqNtTNfSkyb0l0qlYkco4EMth/sp nI3dZisSLbQ7bBg/79sZ7Sy9RRheonRBeGAUg= MIME-Version: 1.0 Received: by 10.220.68.39 with SMTP id t39mr64320vci.58.1260928917169; Tue, 15 Dec 2009 18:01:57 -0800 (PST) Date: Wed, 16 Dec 2009 10:01:57 +0800 Message-ID: <2ec071a80912151801r532ed93fx84db26ba9acf9615@mail.gmail.com> From: Alexander Petrovsky To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problem with kern.icp.shmseg X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 02:31:33 -0000 Hello! I have problem with kern.icp.shmseg, when a change value from 128 to 256, 512.... in /boot/loader.conf. When system loading the value kern.icp.shmseg doesn't change. # cat /boot/loader.conf # Number of shared memory identifiers kern.ipc.shmmni=3D2048 # Number of segments per process #2048 kern.icp.shmseg=3D256 # Number of semaphore identifiers. 256 kern.ipc.semmni=3D512 # Maximum number of semaphores in the system. 512 kern.ipc.semmns=3D1024 # Maximum number of undo structures in the system. 256 kern.ipc.semmnu=3D512 # Size of TCP control-block hashtable. Default 512 net.inet.tcp.tcbhashsize=3D4096 # sysctl kern.ipc | grep ipc.s kern.ipc.semmnu: 512 kern.ipc.semmns: 1024 kern.ipc.semmni: 512 kern.ipc.shmseg: 128 kern.ipc.shmmni: 2048 # uname -a FreeBSD troll.golodnyj.ru 8.0-STABLE FreeBSD 8.0-STABLE #0 r199880: Thu Dec 3 13:35:21 IRKT 2009 alexander@troll.golodnyj.ru:/usr/obj/usr/src/sys/WEBKERNEL i386 --=20 =D0=9F=D0=B5=D1=82=D1=80=D0=BE=D0=B2=D1=81=D0=BA=D0=B8=D0=B9 =D0=90=D0=BB= =D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80 / Alexander Petrovsky, ICQ: 350342118 Jabber: juise@jabber.ru Phone: +7 914 8 820 815 From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 03:42:51 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EBC2106568D for ; Wed, 16 Dec 2009 03:42:51 +0000 (UTC) (envelope-from freebsd@penx.com) Received: from Elmer.dco.penx.com (elmer-sprint.dco.penx.com [65.173.215.114]) by mx1.freebsd.org (Postfix) with ESMTP id EA9528FC13 for ; Wed, 16 Dec 2009 03:42:50 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) by Elmer.dco.penx.com (8.14.3/8.14.3) with ESMTP id nBG2jIKb001477; Tue, 15 Dec 2009 19:45:18 -0700 (MST) (envelope-from freebsd@penx.com) Date: Tue, 15 Dec 2009 19:45:18 -0700 (MST) From: Dennis Glatting X-X-Sender: dennisg@Elmer.dco.penx.com To: "Li, Qing" In-Reply-To: Message-ID: References: <9223.83.206.131.26.1260781902.squirrel@webmail.esigetel.fr> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: patch: bad ipv6 neighbor solicitation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 03:42:51 -0000 This patch works for me. On Mon, 14 Dec 2009, Li, Qing wrote: > Please find the more proper fix at > > http://people.freebsd.org/~qingli/nd6-patch.diff > > I realized I was slightly off in my previous email after > I spent a bit more time looking through the problem. > Both prefixes are present but one was marked off-link due > to the fact only a single prefix route was installed in > the routing table (non RADIX_MPATH system). > > I evaluated various options to fixing this issue, however, > due to the association between NDPRF_ONLINK and the route > installation, I decided to go with what I have here for > the time being. > > I have verified the fix in my setup. Please apply the > patch and report back. > > Thanks, > > -- Qing > > >> -----Original Message----- >> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- >> net@freebsd.org] On Behalf Of Li, Qing >> Sent: Monday, December 14, 2009 3:00 PM >> To: Dennis Glatting; JASSAL Aman >> Cc: freebsd-net@freebsd.org >> Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) >> >> >> You don't need to perform all that route-foo. I believe the root cause >> of >> this issue may be due to a bit of regression in the IPv6 prefix >> management >> code, and I am in the process of putting together a permanent fix. >> >> The issue as it stands today, is due to how the prefix was inserted in >> the first place. Since bce0 was configured first, the interface >> associated >> with the prefix is bce0. Later the reference count on the prefix is >> simply incremented when bce1 configures another IPv6 address of the >> same prefix. >> >> When ND6 NS arrives for bce1, due to the interface mismatch of the >> prefix >> interface against the input interface, the NS packet was considered >> invalid and thus dropped. >> >> Again, in case you didn't see my earlier reply, try the temporary hack >> at >> http://people.freebsd.org/~qingli/nd6-ns.diff >> >> until I commit a permanent patch. The problem was easily reproducible >> and >> I have verified with limited unit testing the patch works. >> >> -- Qing >> >> >> -----Original Message----- >> From: owner-freebsd-net@freebsd.org on behalf of Dennis Glatting >> Sent: Mon 12/14/2009 2:03 PM >> To: JASSAL Aman >> Cc: freebsd-net@freebsd.org >> Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) >> >> >> Thanks. Responses in-line. >> >> >> >> On Mon, 14 Dec 2009, JASSAL Aman wrote: >> >>> Hello Mr.Glatting, >>> >>> Not that I'm an IPv6 genius, but at first sight your problem seems > to >> be a >>> route-related. I've put comments in-line. >>> >>> >>> Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : >>>> >>>> >>>> Elmer# netstat -rn >>>> Routing tables >>>> >>>> >>>> Internet6: >>>> Destination Gateway >> Flags >>>> Netif Expire >>>> ::/96 ::1 > UGRS >>>> lo0 => default fd7c:3f2b:e791:1::1 >>>> UGS bce0 >>>> ::1 ::1 UH >>>> lo0 ::ffff:0.0.0.0/96 ::1 >> UGRS >>>> lo0 fd7c:3f2b:e791:1::/64 link#1 >> U >>>> bce0 fd7c:3f2b:e791:1::ac13:a0a link#1 >> UHS >>>> lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 >> UHS >>>> lo0 fe80::/10 ::1 >> UGRS >>>> lo0 fe80::%bce0/64 link#1 >> U >>>> bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 >> UHS >>>> lo0 fe80::%bce1/64 link#2 >> U >>>> bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 >> UHS >>>> lo0 fe80::%lo0/64 link#3 >> U >>>> lo0 fe80::1%lo0 link#3 >> UHS >>>> lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 >> U >>>> bce0 ff01:2::/32 > fd7c:3f2b:e791:1:0:1:ac13:a0a >> U >>>> bce1 ff01:3::/32 ::1 >> U >>>> lo0 ff02::/16 ::1 >> UGRS >>>> lo0 ff02::%bce0/32 fe80::213:72ff:fe60:ac52%bce0 >> U >>>> bce0 ff02::%bce1/32 > fd7c:3f2b:e791:1:0:1:ac13:a0a >> U >>>> bce1 ff02::%lo0/32 ::1 >> U >>>> lo0 >>>> >>> >>> Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I > was >>> expecting bce1 rather than lo0, I suppose you were as well :) If I'm >> not >>> mistaken, the packets emanating from bce1 go to the loopback >> interface, >>> thus not really going out. You can try specifying the route manually >>> with "route add *your parameters*" or even set it in /etc/rc.conf so >>> that it's loaded at boot-time. There's no reason why among 2 > physical >>> interfaces sharing the same fabric, one can ship packets out and the >>> other can't. >>> >> >> I was wondering about the route however I haven't figured out the > trick >> to >> get what I want. For example: >> >> Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a >> delete host fd7c:3f2b:e791:1:0:1:ac13:a0a >> >> Elmer# route add >> -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 >> route: writing to routing socket: File exists >> add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route already >> in table >> >> I did delete the lo0 route before I exected the above command. Also, I >> haven't been able to specify a higher metric (e.g., -metric 2). That > is >> rejected too. However, I can say: >> >> Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a >> delete host fd7c:3f2b:e791:1:0:1:ac13:a0a >> >> Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a -iface bce1 >> add host fd7c:3f2b:e791:1:0:1:ac13:a0a: gateway bce1 >> >> Elmer# netstat -rn >> (snip) >> fd7c:3f2b:e791:1:0:1:ac13:a0a 00:13:72:60:ac:50 UHS >> bce1 >> >> I don't think that is what I want. WHat I think I just said is "host > X" >> is >> out that door, rather than route net. If, however, I say Docs is out >> that >> door, I get: >> >> Elmer# route add -inet6 docs.dco.penx.com -iface bce1 >> add host docs.dco.penx.com: gateway bce1 >> >> Elmer# ping6 >> docs.penx.com >> PING6(56=40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> >> fd7c:3f2b:e791:1::ac13:a15 >> ping6: sendmsg: Operation not permitted >> ping6: wrote docs.dco.penx.com 16 chars, ret=-1 >> >> >>>> >>>> Elmer's rc.config: >>>> >>>> >>>> ipv6_enable="YES" ipv6_network_interfaces="bce0 bce1" >>>> ipv6_ifconfig_bce0="FD7C:3F2B:E791:0001::0:172.19.10.10 prefixlen >> 64" >>>> ipv6_ifconfig_bce1="FD7C:3F2B:E791:0001::1:172.19.10.10 prefixlen > 64 >> mtu >>>> 8192" >>>> ipv6_defaultrouter="FD7C:3F2B:E791:0001::1" >>>> >>> >>> Erm... You're using IPv4 addresses encapsulated in IPv6 ? I've never >> used >>> this myself so I can't really comment, and I can't say if there >> aren't any >>> sort of "interferences" with what you're trying to do. >>> >> >> I hope what I am specifying is to use the 32 bit IPv4 address as the >> last >> 32 bits of the IPv6 address, at least that is how it works out >> numerically. My numbering scheme for fixed assets is the last 32 bits >> of >> the 128 bit IPv6 address is the same as its IPv4 address. >> >> >>>> >>>> >>>> The router (cisco): >>>> >>>> >>>> interface GigabitEthernet0/0 ipv6 address FD7C:3F2B:E791:1::1/64 >> ipv6 >>>> enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) >>>> >>> >>> Just a side-note, I'm not sure if it will be really useful to you, >> but you >>> could give it a try if you want to. Have you tried using your Cisco >> router >>> as a Router Advertisement Daemon ? That way, addresses would be > built >>> automatically and you could see how both interfaces react to such >>> advertisements. >>> >>> I hope this helps. >>> >>> ------------ >>> Aman Jassal >>> >>> Wisdom comes from experience. >>> Experience comes from a lack of wisdom. >>> >>> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 07:20:12 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 094E0106566B; Wed, 16 Dec 2009 07:20:12 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 895748FC0A; Wed, 16 Dec 2009 07:20:11 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1NKoB6-000CQP-Ko; Wed, 16 Dec 2009 09:20:08 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Miroslav Lachman <000.fbsd@quip.cz> In-reply-to: <4B281279.6060706@quip.cz> References: <4B281279.6060706@quip.cz> Comments: In-reply-to Miroslav Lachman <000.fbsd@quip.cz> message dated "Tue, 15 Dec 2009 23:49:29 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Dec 2009 09:20:08 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-scsi@freebsd.org, freebsd-stable Stable Subject: Re: iSCSI initiator and Dell PowerVault MD3000i X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 07:20:12 -0000 > Hi all, > I am playing with iscsi_initiator on FreeBSD 7-STABLE and Dell > PowerVault MD3000i. This is the first time I am testing iSCSI... > > Does anyone have FreeBSD's iSCSI initiator in production / heavy load? > Or does somebody have experiences with Dell MD3000i? > > One thing is "poor performance" ~ 60 - 70MB/s depending on RAID level > used. (poor performance compared to plain SATA disk which have 110MB/s - > both tested for reading as it is our planned load - multimedia streaming > and downloads) > > > The other thing is some problem with compatibility of initiator and Dell > MD3000i. > > If I setup RAID 5 'Disk Group' consisted of 4x 1TB SATA drives (in > MD3000i) and then created for example 2 'Virtual Disks', both are > detected by iscontrol and added to /dev/ as da0 and da1, but da1 spams > log with messages like this: > > Dec 15 04:00:38 dust kernel: da0 at iscsi0 bus 0 target 0 lun 0 > Dec 15 04:00:38 dust kernel: da0: Fixed Direct > Access SCSI-5 device > Dec 15 04:00:38 dust kernel: da1 at iscsi0 bus 0 target 0 lun 1 > Dec 15 04:00:38 dust kernel: da1: Fixed Direct > Access SCSI-5 device > Dec 15 04:00:38 dust iscontrol[48576]: cam_open_btl: no passthrough > device found at 0:0:2 > Dec 15 04:00:38 dust iscontrol[48576]: cam_open_btl: no passthrough > device found at 0:0:3 > Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): READ(6)/WRITE(6) not > supported, increasing minimum_cmd_size to 10. > Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): READ(10). CDB: 28 0 0 0 > 0 0 0 0 1 0 > Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): CAM Status: SCSI Status > Error > Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): SCSI Status: Check > Condition > Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): ILLEGAL REQUEST asc:94,1 > Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): Vendor Specific ASC > Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): Unretryable error > Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): READ(10). CDB: 28 0 c > 7f df ff 0 0 1 0 > Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): CAM Status: SCSI Status > Error > Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): SCSI Status: Check > Condition > Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): ILLEGAL REQUEST asc:94,1 > Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): Vendor Specific ASC > Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): Unretryable error > Dec 15 04:00:41 dust kernel: (da1:iscsi0:0:0:1): READ(10). CDB: 28 0 0 0 > 0 0 0 0 1 0 > > The message repeated many times. > > If I created more 'Virtual Disks' (7 for example), 3 of them are > producing same errors (da1, da3, da5) > > If there is only one 'Virtual Disk', it seems fine... until I configured > second path to the virtual disk as I want to try gmultipath or geom_fox > (MD3000i is dual controller with 4 NICs), then second session produces > same errors. > > First path - OK: > > Dec 15 22:47:57 dust kernel: da0 at iscsi0 bus 0 target 0 lun 0 > Dec 15 22:47:57 dust kernel: da0: Fixed Direct > Access SCSI-5 device > Dec 15 22:47:57 dust iscontrol[52226]: cam_open_btl: no passthrough > device found at 0:0:1 > Dec 15 22:47:57 dust iscontrol[52226]: cam_open_btl: no passthrough > device found at 0:0:2 > Dec 15 22:47:57 dust iscontrol[52226]: cam_open_btl: no passthrough > device found at 0:0:3 > > > Second path - error: > > Dec 15 22:48:04 dust kernel: da1 at iscsi0 bus 0 target 1 lun 0 > Dec 15 22:48:04 dust kernel: da1: Fixed Direct > Access SCSI-5 device > Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): READ(6)/WRITE(6) not > supported, increasing minimum_cmd_size to 10. > Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): READ(10). CDB: 28 0 0 0 > 0 0 0 0 1 0 > Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): CAM Status: SCSI Status > Error > Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): SCSI Status: Check > Condition > Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): ILLEGAL REQUEST asc:94,1 > Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): Vendor Specific ASC > Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): Unretryable error > Dec 15 22:48:05 dust iscontrol[52230]: cam_open_btl: no passthrough > device found at 0:1:1 > Dec 15 22:48:05 dust iscontrol[52230]: cam_open_btl: no passthrough > device found at 0:1:2 > Dec 15 22:48:05 dust iscontrol[52230]: cam_open_btl: no passthrough > device found at 0:1:3 > Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): READ(16). CDB: 88 0 0 0 > 0 1 5d 21 1f ff 0 0 0 1 0 0 > Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): CAM Status: SCSI Status > Error > Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): SCSI Status: Check > Condition > Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): ILLEGAL REQUEST asc:94,1 > Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): Vendor Specific ASC > Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): Unretryable error > Dec 15 22:48:07 dust kernel: (da1:iscsi0:0:1:0): READ(10). CDB: 28 0 0 0 > 0 0 0 0 1 0 > Dec 15 22:48:07 dust kernel: (da1:iscsi0:0:1:0): CAM Status: SCSI Status > Error > Dec 15 22:48:07 dust kernel: (da1:iscsi0:0:1:0): SCSI Status: Check > Condition > Dec 15 22:48:07 dust kernel: (da1:iscsi0:0:1:0): ILLEGAL REQUEST asc:94,1 > Dec 15 22:48:07 dust kernel: (da1:iscsi0:0:1:0): Vendor Specific ASC > Dec 15 22:48:07 dust kernel: (da1:iscsi0:0:1:0): Unretryable error > Dec 15 22:48:09 dust kernel: (da1:iscsi0:0:1:0): READ(10). CDB: 28 0 0 0 > 0 1 0 0 1 0 > > > # main path > storage_1 { > initiatorname = iqn.2005-01.il.ac.huji.cs::dust.example.com > TargetName = > iqn.1984-05.com.dell:powervault.md3000i.60026b900042587b000000004ae58efc > TargetAddress = 192.168.130.101:3260,1 > tags = 64 > } > > # second path > storage_2 { > initiatorname = iqn.2005-01.il.ac.huji.cs::dust.example.com > TargetName = > iqn.1984-05.com.dell:powervault.md3000i.60026b900042587b000000004ae58efc > TargetAddress = 192.168.132.102:3260,2 > tags = 64 > } > > Can somebody advice some tweaks to get better performance and solution > of the errors above? hi Miroslav, firstly, in case you haven't yet, get the latest from: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.2.3.tar.gz the slowness is probably due to the scsi errors, which I need some scsi expert (hence the cc to scsi@freebsd.org, hint, hint). In the mean time, and if you can/want, you can allow me access to an iscsi partition so that I can better debug the issue. oh, and yes, we use it here. danny From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 08:59:34 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72514106568D; Wed, 16 Dec 2009 08:59:34 +0000 (UTC) (envelope-from alexz@visp.ru) Received: from mail.visp.ru (srv1.visp.ru [91.215.204.2]) by mx1.freebsd.org (Postfix) with ESMTP id 266968FC13; Wed, 16 Dec 2009 08:59:33 +0000 (UTC) Received: from 91-215-205-255.static.visp.ru ([91.215.205.255] helo=zagrebin) by mail.visp.ru with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1NKpjH-0003to-JI; Wed, 16 Dec 2009 11:59:31 +0300 From: "Alexander Zagrebin" To: , Date: Wed, 16 Dec 2009 11:59:31 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp+LhSOCSJqD7TlTcqPTB6QV0uSXQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Cc: Subject: 8.0-RELEASE: disk IO temporarily hangs up (ZFS or ATA related problem) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 08:59:34 -0000 Hi! I use onboard ICH7 SATA controller with two disks attached: atapci1: port 0x30c8-0x30cf,0x30ec-0x30ef,0x30c0-0x30c7,0x30e8-0x30eb,0x30a0-0x30af irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ad4: 1430799MB at ata2-master SATA150 ad6: 1430799MB at ata3-master SATA150 The disks are used for mirrored ZFS pool. I have noticed that the system periodically locks up on disk operations. After approx. 10 min of very slow disk i/o (several KB/s) the speed of disk operations restores to normal. gstat has shown that the problem is in ad6. For example, there is a filtered output of iostat -x 1: extended device statistics device r/s w/s kr/s kw/s wait svc_t %b ad6 818.6 0.0 10840.2 0.0 0 0.4 34 ad6 300.6 642.0 3518.5 24830.3 50 24.8 72 ad6 1.0 639.3 63.7 17118.3 0 62.1 98 ad6 404.5 4.0 6837.7 4.0 0 0.5 18 ad6 504.5 0.0 13667.2 0.0 1 0.7 32 ad6 633.3 0.0 13190.3 0.0 1 0.7 38 ad6 416.3 384.5 8134.7 24606.2 0 16.3 57 ad6 538.9 76.7 9772.8 2982.2 55 2.9 40 ad6 31.9 929.5 801.0 37498.6 0 27.2 82 ad6 635.5 0.0 13087.1 0.0 1 0.6 35 ad6 579.6 0.0 16669.8 0.0 0 0.8 43 ad6 603.6 0.0 11697.4 0.0 1 0.7 40 ad6 538.0 0.0 10438.7 0.0 0 0.9 47 ad6 30.9 898.4 868.6 40585.4 0 36.6 78 ad6 653.3 86.6 8566.6 202.7 1 0.8 40 ad6 737.1 0.0 6429.4 0.0 1 0.6 42 ad6 717.1 0.0 3958.7 0.0 0 0.5 36 ad6 1179.5 0.0 2058.9 0.0 0 0.1 15 ad6 1191.2 0.0 1079.6 0.0 1 0.1 15 ad6 985.1 0.0 5093.9 0.0 0 0.2 23 ad6 761.8 0.0 9801.3 0.0 1 0.4 31 ad6 698.7 0.0 9215.1 0.0 0 0.4 30 ad6 434.2 513.9 5903.1 13658.3 48 10.2 55 ad6 3.0 762.8 191.2 28732.3 0 57.6 99 ad6 10.0 4.0 163.9 4.0 1 1.6 2 Before this line we have a normal operations. Then the behaviour of ad6 changes (pay attention to high average access time and percent of "busy" significantly greater than 100): ad6 0.0 0.0 0.0 0.0 1 0.0 0 ad6 1.0 0.0 0.5 0.0 1 1798.3 179 ad6 1.0 0.0 1.5 0.0 1 1775.4 177 ad6 0.0 0.0 0.0 0.0 1 0.0 0 ad6 10.0 0.0 75.2 0.0 1 180.3 180 ad6 0.0 0.0 0.0 0.0 1 0.0 0 ad6 83.7 0.0 862.9 0.0 1 21.4 179 ad6 0.0 0.0 0.0 0.0 1 0.0 0 ad6 1.0 0.0 63.7 0.0 1 1707.4 170 ad6 1.0 0.0 9.0 0.0 0 1791.0 178 ad6 10.9 0.0 172.2 0.0 2 0.2 0 ad6 24.9 0.0 553.7 0.0 1 143.3 179 ad6 0.0 0.0 0.0 0.0 7 0.0 0 ad6 2.0 23.9 32.4 1529.9 1 336.3 177 ad6 0.0 0.0 0.0 0.0 1 0.0 0 ad6 68.7 0.0 1322.8 0.0 1 26.3 181 ad6 0.0 0.0 0.0 0.0 1 0.0 0 ad6 27.9 0.0 193.7 0.0 1 61.6 172 ad6 1.0 0.0 2.5 0.0 1 1777.4 177 ad6 0.0 0.0 0.0 0.0 1 0.0 0 ad6 1.0 0.0 2.0 0.0 1 1786.9 178 ad6 0.0 0.0 0.0 0.0 1 0.0 0 ad6 2.0 0.0 6.5 0.0 1 899.4 179 ad6 0.0 0.0 0.0 0.0 1 0.0 0 ad6 1.0 0.0 2.0 0.0 1 1786.7 178 ad6 0.0 0.0 0.0 0.0 1 0.0 0 And so on for about 10 minutes. Then the disk i/o is reverted to normal: ad6 139.4 0.0 8860.5 0.0 1 4.4 61 ad6 167.3 0.0 10528.7 0.0 1 3.3 55 ad6 60.8 411.5 3707.6 8574.8 1 19.6 87 ad6 163.4 0.0 10334.9 0.0 1 4.4 72 ad6 157.4 0.0 9770.7 0.0 1 5.0 78 ad6 108.5 0.0 6886.8 0.0 0 3.9 43 ad6 101.6 0.0 6381.4 0.0 0 2.6 27 ad6 109.6 0.0 7013.9 0.0 0 2.0 22 ad6 121.4 0.0 7769.7 0.0 0 2.4 29 ad6 92.5 0.0 5922.6 0.0 1 3.4 31 ad6 122.4 19.9 7833.0 1273.7 0 3.9 54 ad6 83.6 0.0 5349.5 0.0 0 3.9 33 ad6 5.0 0.0 318.4 0.0 0 8.1 4 There are no ata error messages neither in the system log, nor on the console. The manufacture's diagnostic test is passed on ad6 without any errors. The ad6 also contains swap partition. I have tried to run several (10..20) instances of dd, which read and write data from and to the swap partition simultaneously, but it has not called the lockup. So there is a probability that this problem is ZFS related. I have been forced to switch ad6 to the offline state... :( Any suggestions on this problem? -- Alexander Zagrebin From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 09:14:32 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2225D106566B for ; Wed, 16 Dec 2009 09:14:32 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by mx1.freebsd.org (Postfix) with ESMTP id BFD488FC14 for ; Wed, 16 Dec 2009 09:14:31 +0000 (UTC) Received: from OMTA16.westchester.pa.mail.comcast.net ([76.96.62.88]) by QMTA09.westchester.pa.mail.comcast.net with comcast id HlEY1d0021uE5Es59lEYPH; Wed, 16 Dec 2009 09:14:32 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by OMTA16.westchester.pa.mail.comcast.net with comcast id HlRZ1d0013S48mS3clRZ6z; Wed, 16 Dec 2009 09:25:33 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0A4DC1E301B; Wed, 16 Dec 2009 01:14:30 -0800 (PST) Date: Wed, 16 Dec 2009 01:14:30 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20091216091429.GA91359@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: 8.0-RELEASE: disk IO temporarily hangs up (ZFS or ATA related problem) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 09:14:32 -0000 On Wed, Dec 16, 2009 at 11:59:31AM +0300, Alexander Zagrebin wrote: > {snip} > > There are no ata error messages neither in the system log, nor on the > console. The manufacture's diagnostic test is passed on ad6 without > any errors. The ad6 also contains swap partition. I have tried to > run several (10..20) instances of dd, which read and write data from > and to the swap partition simultaneously, but it has not called the > lockup. So there is a probability that this problem is ZFS related. > > I have been forced to switch ad6 to the offline state... :( > > Any suggestions on this problem? My first guess would be that yes, this is a sign of something ZFS is doing, but I'm not positive. It'd be useful to see "zpool status" output from your system (when ad6 is in the ONLINE state). Have you tried doing "zpool scrub " to make sure there's no read, write, or checksum errors causing problems behind the scenes? I don't know how this would manifest itself in that manner, but worth a shot. Otherwise, if you could install sysutils/smartmontools and provide the full output of "smartctl -a /dev/ad6" I'll be happy to perform a brief analysis of the drive itself and if it's performing badly or oddly. Please note that SMART stats don't keep track of anything pertaining to the drive's on-PCB cache (which could be going bad, but you'd almost certainly see that at all times not, occasionally). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 09:15:03 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDB89106568B for ; Wed, 16 Dec 2009 09:15:03 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 752C88FC1A for ; Wed, 16 Dec 2009 09:15:02 +0000 (UTC) Received: by bwz5 with SMTP id 5so549796bwz.3 for ; Wed, 16 Dec 2009 01:15:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=dT7cySu4EXwKXAEJjheaBg/gjOJCroUZuwvQzHXhGmc=; b=Qaua+aFCP7oK39F9miQPQSXLd/fH8+ZQA9iGY1YuwfI+nzuIUdWdz87WQXyz6CpxU0 2w2AM3SRZegjU7b7S1+qElm5mj7+8xftud+vOk5AkCKdOhkMaWFPZW78fHxZQXjMmkgQ Bz4R0rNlQ2FmofdhYZ+/ZacTuOYvhqEFWaFc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Re3M3JAfHQ76yS6vqZRh7GHkDrJSfz9ivCFRUC5icSIUiSaoVtFu0vIA4oUxN8gcOP vYEYs3s5Dnn/wDAbTjSOWhu7v6KUfYm8W8zAvpSriq6cJIKjxkBg0fOwRtYDWbf93C1o /LD4xFJlXTJ1sWQmy4HPxEFAGFBNx1C7UU1J8= MIME-Version: 1.0 Received: by 10.204.27.14 with SMTP id g14mr361610bkc.127.1260954901859; Wed, 16 Dec 2009 01:15:01 -0800 (PST) Date: Wed, 16 Dec 2009 04:15:01 -0500 Message-ID: From: grarpamp To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Using RELENG_8 to compile for older RELENG_x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 09:15:03 -0000 I'm on RELENG_8, works great. I've been bugged to compile some things for RELENG_4 boxes. Due to administrative fiat, I have to compile externally and ship them the results, no login. So in general, how do I use my RELENG_8 boxes to compile apps that will run on RELENG_4? Similarly, how can I make buildworld/buildkernel/release for RELENG_4 on RELENG_8? I have RELENG_4 sources on disk, but of course things don't compile/run right. Going forward is easy, I've just no idea how to go backwards :) From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 09:28:30 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF889106566B for ; Wed, 16 Dec 2009 09:28:30 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from crivens.kernel32.de (crivens.asm68k.org [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id B108F8FC18 for ; Wed, 16 Dec 2009 09:28:29 +0000 (UTC) Received: from www.terrorteam.de (localhost [127.0.0.1]) by crivens.kernel32.de (Postfix) with ESMTP id 45E40B028D; Wed, 16 Dec 2009 10:28:28 +0100 (CET) MIME-Version: 1.0 Date: Wed, 16 Dec 2009 10:28:28 +0100 From: Marian Hettwer To: Marcel Moolenaar In-Reply-To: <7BA0C6CC-A1D9-49C2-942D-D46C19E9B3CB@mac.com> References: <7BA0C6CC-A1D9-49C2-942D-D46C19E9B3CB@mac.com> Message-ID: <5cc508f1797d04d0c64bdba1d4a12ff4@localhost> X-Sender: mh@kernel32.de User-Agent: RoundCube Webmail/0.1-rc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: Ben Morrow , freebsd-stable@freebsd.org Subject: Re: update to 8.0-RELEASE --> partition gone X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 09:28:31 -0000 Hej Marcel, On Tue, 15 Dec 2009 16:46:27 -0800, Marcel Moolenaar wrote: > > Yes, if you have ad2a and not ad2s1a, then you have a > proper dangerously dedicated disk and FreeBSD 8.x will > work correctly with your disk. > > If you installed "dangerously dedicated" and ended up > with ad0s1a (note the "s1"), then you have an invalid > partitioning and FreeBSD 8.x will not give you what > you've been getting on FreeBSD 7.x. Most of the time > you only need to wipe out the second sector on the > disk to clean it up and have FreeBSD 8.x also give > you ad0s1a. > okay... but how do I wipe out the second sector? dd if=/dev/zero of=/dev/ad8 count=1 would wipe out the first 512 bytes. I'm always confused with sectors vs. bytes. hm... since this disk is my second disk and was only used for backups, I might as well bsdlabel and newfs it again. Losing all data then, but well, sounds easier so far to me. And I'd like to avoid reboots, if possible. Again, I'm booting from ad4 and this works fine. I should be able to toy around with ad8 without rebooting or going into single user. Thanks so far, Marian From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 10:28:53 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76CBA106566B for ; Wed, 16 Dec 2009 10:28:53 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by mx1.freebsd.org (Postfix) with ESMTP id 0B6F08FC0A for ; Wed, 16 Dec 2009 10:28:52 +0000 (UTC) Received: from slackbox.xs4all.nl (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id nBGASp0r016056; Wed, 16 Dec 2009 11:28:51 +0100 (CET) (envelope-from rsmith@xs4all.nl) Received: by slackbox.xs4all.nl (Postfix, from userid 1001) id 1629CBA90; Wed, 16 Dec 2009 11:28:51 +0100 (CET) Date: Wed, 16 Dec 2009 11:28:51 +0100 From: Roland Smith To: grarpamp Message-ID: <20091216102850.GA99834@slackbox.xs4all.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: X-GPG-Fingerprint: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 X-GPG-Key: http://www.xs4all.nl/~rsmith/pubkey.txt X-GPG-Notice: If this message is not signed, don't assume I sent it! User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-stable@freebsd.org Subject: Re: Using RELENG_8 to compile for older RELENG_x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 10:28:53 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 16, 2009 at 04:15:01AM -0500, grarpamp wrote: > I'm on RELENG_8, works great. I've been bugged to compile some > things for RELENG_4 boxes. Due to administrative fiat, I have to > compile externally and ship them the results, no login. The best thing to do is to convince the guys running RELENG_4 to join the r= est of us in the 21st century, and switch to 8.0 or at least 7.x. Support for t= he 4.x base system has ended some time ago, and the current ports tree isn't guaranteed to work on it either. > So in general, how do I use my RELENG_8 boxes to compile apps that > will run on RELENG_4? Create a virtual machine with RELENG_4 on it, that is probably the most foolproof way. (If you are running an i386 machine, maybe a jail will work.) Try to compile the software on it. If that software is in ports and the current port doesn't compile or run, either roll back your ports tr= ee to a version that works, or try to patch the port to make it work. =20 > Similarly, how can I make buildworld/buildkernel/release for RELENG_4 > on RELENG_8? Ditto. Roland --=20 R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAksotmIACgkQEnfvsMMhpyUFxQCeNebQxCIywRN87eYHLB1RBPsj KlIAoI4eJbVOoORL/+jzPCvgdE9K7mmu =oNlW -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 10:42:58 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F441106566B for ; Wed, 16 Dec 2009 10:42:58 +0000 (UTC) (envelope-from alexz@visp.ru) Received: from mail.visp.ru (srv1.visp.ru [91.215.204.2]) by mx1.freebsd.org (Postfix) with ESMTP id DD2E88FC13 for ; Wed, 16 Dec 2009 10:42:57 +0000 (UTC) Received: from 91-215-205-255.static.visp.ru ([91.215.205.255] helo=zagrebin) by mail.visp.ru with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1NKrLK-000B8v-Oy; Wed, 16 Dec 2009 13:42:55 +0300 From: "Alexander Zagrebin" To: "'Jeremy Chadwick'" References: <20091216091429.GA91359@icarus.home.lan> Date: Wed, 16 Dec 2009 13:42:54 +0300 Keywords: freebsd-stable Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp+MFtfcL9sjnFqTqOwKpmwkN15OQACXL0A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: <20091216091429.GA91359@icarus.home.lan> Cc: freebsd-stable@freebsd.org Subject: RE: 8.0-RELEASE: disk IO temporarily hangs up (ZFS or ATA related problem) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 10:42:58 -0000 > > There are no ata error messages neither in the system log, > nor on the > > console. The manufacture's diagnostic test is passed on ad6 without > > any errors. The ad6 also contains swap partition. I have tried to > > run several (10..20) instances of dd, which read and write data from > > and to the swap partition simultaneously, but it has not called the > > lockup. So there is a probability that this problem is ZFS related. > > > > I have been forced to switch ad6 to the offline state... :( > > > > Any suggestions on this problem? > > My first guess would be that yes, this is a sign of something ZFS is > doing, but I'm not positive. It'd be useful to see "zpool status" > output from your system (when ad6 is in the ONLINE state). Nothing special: $ zpool status pool: pool state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: resilver completed after 0h1m with 0 errors on Wed Dec 16 13:26:00 2009 config: NAME STATE READ WRITE CKSUM pool ONLINE 0 0 0 mirror ONLINE 0 0 0 gpt/pool0 ONLINE 0 0 0 2,20M resilvered gpt/pool1 ONLINE 0 172K 0 196M resilvered errors: No known data errors Write errors (172K) was accumulated during offline state of the gpt/pool1 aka ad6. > Have you tried doing "zpool scrub " to make sure > there's no read, > write, or checksum errors causing problems behind the scenes? I don't > know how this would manifest itself in that manner, but worth a shot. Yes, I did. zpool scrub doesn't found any errors, but it took lo-o-ong time due to periodic lockups. > Otherwise, if you could install sysutils/smartmontools and provide the > full output of "smartctl -a /dev/ad6" I'll be happy to perform a brief > analysis of the drive itself and if it's performing badly or oddly. > Please note that SMART stats don't keep track of anything > pertaining to > the drive's on-PCB cache (which could be going bad, but you'd almost > certainly see that at all times not, occasionally). Imho, the smart data is fine. It's the new drive. Today I'll try to change disks in places to eliminate faulty south bridge. ===================================================================== $ sudo smartctl -a /dev/ad6 smartctl version 5.38 [amd64-portbld-freebsd8.0] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Device Model: WDC WD15EADS-00P8B0 Serial Number: WD-WCAVU0296075 Firmware Version: 01.00A01 User Capacity: 1 500 301 910 016 bytes Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Wed Dec 16 13:29:36 2009 MSK SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (32700) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 255) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SCT capabilities: (0x303f) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 180 180 021 Pre-fail Always - 5991 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 21 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 109 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 16 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 15 193 Load_Cycle_Count 0x0032 199 199 000 Old_age Always - 3819 194 Temperature_Celsius 0x0022 115 106 000 Old_age Always - 35 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Conveyance offline Completed without error 00% 84 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. ===================================================================== -- Alexander Zagrebin From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 10:55:43 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA634106566B for ; Wed, 16 Dec 2009 10:55:43 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0C5508FC08 for ; Wed, 16 Dec 2009 10:55:42 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA02610; Wed, 16 Dec 2009 12:55:38 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B28BCAA.1010002@icyb.net.ua> Date: Wed, 16 Dec 2009 12:55:38 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Marian Hettwer References: <7BA0C6CC-A1D9-49C2-942D-D46C19E9B3CB@mac.com> <5cc508f1797d04d0c64bdba1d4a12ff4@localhost> In-Reply-To: <5cc508f1797d04d0c64bdba1d4a12ff4@localhost> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: update to 8.0-RELEASE --> partition gone X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 10:55:43 -0000 on 16/12/2009 11:28 Marian Hettwer said the following: > Hej Marcel, > > > On Tue, 15 Dec 2009 16:46:27 -0800, Marcel Moolenaar > wrote: >> Yes, if you have ad2a and not ad2s1a, then you have a >> proper dangerously dedicated disk and FreeBSD 8.x will >> work correctly with your disk. >> >> If you installed "dangerously dedicated" and ended up >> with ad0s1a (note the "s1"), then you have an invalid >> partitioning and FreeBSD 8.x will not give you what >> you've been getting on FreeBSD 7.x. Most of the time >> you only need to wipe out the second sector on the >> disk to clean it up and have FreeBSD 8.x also give >> you ad0s1a. >> > okay... but how do I wipe out the second sector? > dd if=/dev/zero of=/dev/ad8 count=1 > would wipe out the first 512 bytes. You need to add seek=1 (or oseek=1, which is the same but a little bit more obvious) to that command. > I'm always confused with sectors vs. > bytes. You are not confused this time, HDD sector is 512 bytes. This is the default dd block size too. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 10:55:46 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDFB3106566C for ; Wed, 16 Dec 2009 10:55:46 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id 9FF5F8FC12 for ; Wed, 16 Dec 2009 10:55:46 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 22C888C065; Wed, 16 Dec 2009 04:55:46 -0600 (CST) Date: Wed, 16 Dec 2009 04:55:46 -0600 From: Mark Linimon To: Roland Smith Message-ID: <20091216105546.GG14175@lonesome.com> References: <20091216102850.GA99834@slackbox.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091216102850.GA99834@slackbox.xs4all.nl> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org, grarpamp Subject: Re: Using RELENG_8 to compile for older RELENG_x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 10:55:46 -0000 On Wed, Dec 16, 2009 at 11:28:51AM +0100, Roland Smith wrote: > the current ports tree isn't guaranteed to work on [4.x] either. s/isn't guaranteed to/is guaranteed not to/ (sorry) You might want to experiment with checking out a ports tree as of tag RELEASE_4_EOL and trying to pull in newer pieces from there. But basically, you're trying to piece together modern ports with something that was released 01/25/2005 and went EOL on 01/31/2007 (coming up on 3 years ago). mcl From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 10:59:42 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E02B106566C for ; Wed, 16 Dec 2009 10:59:42 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 74ED38FC17 for ; Wed, 16 Dec 2009 10:59:41 +0000 (UTC) Received: (qmail 67715 invoked from network); 16 Dec 2009 10:33:00 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 16 Dec 2009 10:33:00 -0000 Date: Wed, 16 Dec 2009 11:33:00 +0100 (CET) Message-Id: <20091216.113300.74685382.sthaug@nethelp.no> To: xcllnt@mac.com From: sthaug@nethelp.no In-Reply-To: <7BA0C6CC-A1D9-49C2-942D-D46C19E9B3CB@mac.com> References: <200912151720.37709.freebsd@insightbb.com> <20091216000803.GA39686@osiris.mauzo.dyndns.org> <7BA0C6CC-A1D9-49C2-942D-D46C19E9B3CB@mac.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: update to 8.0-RELEASE --> partition gone X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 10:59:42 -0000 > If you installed "dangerously dedicated" and ended up > with ad0s1a (note the "s1"), then you have an invalid > partitioning and FreeBSD 8.x will not give you what > you've been getting on FreeBSD 7.x. Most of the time > you only need to wipe out the second sector on the > disk to clean it up and have FreeBSD 8.x also give > you ad0s1a. So what's an easy recipe we can run on 7.x hosts to see whether we would have problems with 8.x? Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 11:20:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00CF2106566C for ; Wed, 16 Dec 2009 11:20:00 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (takeda-1-pt.tunnel.tserv15.lax1.ipv6.he.net [IPv6:2001:470:c:16b::2]) by mx1.freebsd.org (Postfix) with ESMTP id B636A8FC0A for ; Wed, 16 Dec 2009 11:19:59 +0000 (UTC) Received: from takeda-ws.lan (takeda-ws.lan [10.0.0.3]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.3/8.14.3) with ESMTP id nBGBJwJf082010 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 16 Dec 2009 03:19:58 -0800 (PST) (envelope-from takeda@takeda.tk) Date: Wed, 16 Dec 2009 03:19:52 -0800 From: Derek Kulinski X-Mailer: The Bat! (v3.99.3) Professional X-Priority: 3 (Normal) Message-ID: <110163611.20091216031952@takeda.tk> To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Problems with Atheros card and hostpd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 11:20:00 -0000 Hello, I just upgraded my access point (from 7.1 to 8.0) and can't make hostapd work (looks like wide-dhcp relay also has a problem with ath0): [mayumi]:/root# hostapd -P /var/run/hostapd.pid -dd /etc/hostapd.conf Configuration file: /etc/hostapd.conf Line 2: DEPRECATED: 'debug' configuration variable is not used anymore ctrl_interface_group=0 (from group name 'wheel') pcap_open_live: ifname='ath0' bsd driver initialization failed. ath0: Unable to setup interface. rmdir[ctrl_interface]: No such file or directory Exit 255 Output from dmesg: ath0: mem 0xf4000000-0xf400ffff irq 3 at device 11.0 on pci0 ath0: [ITHREAD] ath0: AR2413 mac 7.9 RF2413 phy 4.5 The interface seems to exist, but seems it lost some of its functionality: [mayumi]:/root# ifconfig ath0 ath0: flags=8843 metric 0 mtu 2290 ether 00:11:95:e5:70:df media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier [mayumi]:/root# ifconfig ath0 list cap ifconfig: Don't know how to list cap for ath0 What's going on? The card worked pretty well with 7.1. I tried to compile kernel just with "device ath_ar5212" but I'm only getting this: ah.o(.text+0x212): In function `ath_hal_rfprobe': /usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__start_set_ah_rfs' ah.o(.text+0x21f):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__stop_set_ah_rfs' ah.o(.text+0x235):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__stop_set_ah_rfs' -- Best regards, Derek mailto:takeda@takeda.tk Wear short sleeves! Support your right to bare arms! From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 11:27:17 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 316E61065670 for ; Wed, 16 Dec 2009 11:27:17 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from crivens.kernel32.de (crivens.asm68k.org [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id E6F458FC0A for ; Wed, 16 Dec 2009 11:27:16 +0000 (UTC) Received: from www.terrorteam.de (localhost [127.0.0.1]) by crivens.kernel32.de (Postfix) with ESMTP id 5C7F6B028D; Wed, 16 Dec 2009 12:27:15 +0100 (CET) MIME-Version: 1.0 Date: Wed, 16 Dec 2009 12:27:15 +0100 From: Marian Hettwer To: Andriy Gapon In-Reply-To: <4B28BCAA.1010002@icyb.net.ua> References: <4B28BCAA.1010002@icyb.net.ua> Message-ID: <21859b54848003a15761f546aed36f1f@localhost> X-Sender: mh@kernel32.de User-Agent: RoundCube Webmail/0.1-rc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: update to 8.0-RELEASE --> partition gone X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 11:27:17 -0000 Hej Ho, On Wed, 16 Dec 2009 12:55:38 +0200, Andriy Gapon wrote: > on 16/12/2009 11:28 Marian Hettwer said the following: >> Hej Marcel, >> >> >> On Tue, 15 Dec 2009 16:46:27 -0800, Marcel Moolenaar >> wrote: >>> Yes, if you have ad2a and not ad2s1a, then you have a >>> proper dangerously dedicated disk and FreeBSD 8.x will >>> work correctly with your disk. >>> >>> If you installed "dangerously dedicated" and ended up >>> with ad0s1a (note the "s1"), then you have an invalid >>> partitioning and FreeBSD 8.x will not give you what >>> you've been getting on FreeBSD 7.x. Most of the time >>> you only need to wipe out the second sector on the >>> disk to clean it up and have FreeBSD 8.x also give >>> you ad0s1a. >>> >> okay... but how do I wipe out the second sector? >> dd if=/dev/zero of=/dev/ad8 count=1 >> would wipe out the first 512 bytes. > > You need to add seek=1 (or oseek=1, which is the same but a little bit > more > obvious) to that command. > gee, thanks! That worked. root@talisker:/root# ls /dev/ad8* /dev/ad8 /dev/ad8s1 /dev/ad8s1a root@talisker:/root# mount /dev/ad8s1a /BACKUP/ root@talisker:/root# umount /BACKUP/ but, hm, whats that? root@talisker:/root# fsck /dev/ad8s1a fsck: Could not determine filesystem type >> I'm always confused with sectors vs. >> bytes. > > You are not confused this time, HDD sector is 512 bytes. This is the > default dd > block size too. > Good to know! Cheers, Marian From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 11:46:58 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF3041065695 for ; Wed, 16 Dec 2009 11:46:58 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from smtp02.cdmon.com (smtp02.cdmon.com [212.36.74.53]) by mx1.freebsd.org (Postfix) with ESMTP id 2D4158FC1B for ; Wed, 16 Dec 2009 11:46:57 +0000 (UTC) Received: from jespasac.cdmon.com (62.Red-217-126-43.staticIP.rima-tde.net [217.126.43.62]) (Authenticated sender: jespasac@noverificar) by smtp02.cdmon.com (Postfix) with ESMTP id BCA0C46893 for ; Wed, 16 Dec 2009 12:46:54 +0100 (CET) Message-ID: <4B28C842.3030704@minibofh.org> Date: Wed, 16 Dec 2009 12:45:06 +0100 From: Jordi Espasa Clofent User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Error upgrading 7.0 to 7.2 (buildword in gnu/usr.bin/binutils/libopcodes setp) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 11:46:58 -0000 Hi all, I get the next nasty error: ===> gnu/usr.bin/binutils/libopcodes (all) cc -O2 -fno-strict-aliasing -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/libopcodes -I/usr/src/gnu/usr.bin/binutils/libopcodes/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/libopcodes/../libbfd -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/include -DARCH_i386 -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/opcodes -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/opcodes/i386-dis.c cc -O2 -fno-strict-aliasing -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/libopcodes -I/usr/src/gnu/usr.bin/binutils/libopcodes/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/libopcodes/../libbfd -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/include -DARCH_i386 -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/opcodes -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/opcodes/dis-buf.c cc -O2 -fno-strict-aliasing -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/libopcodes -I/usr/src/gnu/usr.bin/binutils/libopcodes/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/libopcodes/../libbfd -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/include -DARCH_i386 -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/opcodes -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/opcodes/dis-init.c cc -O2 -fno-strict-aliasing -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/libopcodes -I/usr/src/gnu/usr.bin/binutils/libopcodes/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/libopcodes/../libbfd -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/include -DARCH_i386 -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/opcodes -I/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/opcodes/disassemble.c building static opcodes library ranlib libopcodes.a ===> gnu/usr.bin/binutils/libbinutils (all) cc -O2 -fno-strict-aliasing -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/libbinutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/include -DTARGET=\"x86_64-obrien-freebsd\" -DBFD_VERSION_STRING=\""2.15 [FreeBSD] 2004-05-23"\" -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils/arsup.c cc -O2 -fno-strict-aliasing -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/libbinutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/include -DTARGET=\"x86_64-obrien-freebsd\" -DBFD_VERSION_STRING=\""2.15 [FreeBSD] 2004-05-23"\" -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils/bucomm.c cc -O2 -fno-strict-aliasing -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/libbinutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/include -DTARGET=\"x86_64-obrien-freebsd\" -DBFD_VERSION_STRING=\""2.15 [FreeBSD] 2004-05-23"\" -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils/debug.c cc -O2 -fno-strict-aliasing -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/libbinutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/include -DTARGET=\"x86_64-obrien-freebsd\" -DBFD_VERSION_STRING=\""2.15 [FreeBSD] 2004-05-23"\" -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils/filemode.c cc -O2 -fno-strict-aliasing -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/libbinutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/include -DTARGET=\"x86_64-obrien-freebsd\" -DBFD_VERSION_STRING=\""2.15 [FreeBSD] 2004-05-23"\" -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils/ieee.c cc -O2 -fno-strict-aliasing -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/libbinutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/include -DTARGET=\"x86_64-obrien-freebsd\" -DBFD_VERSION_STRING=\""2.15 [FreeBSD] 2004-05-23"\" -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils/rdcoff.c cc -O2 -fno-strict-aliasing -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/libbinutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/include -DTARGET=\"x86_64-obrien-freebsd\" -DBFD_VERSION_STRING=\""2.15 [FreeBSD] 2004-05-23"\" -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils/rddbg.c cc -O2 -fno-strict-aliasing -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/libbinutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/include -DTARGET=\"x86_64-obrien-freebsd\" -DBFD_VERSION_STRING=\""2.15 [FreeBSD] 2004-05-23"\" -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils/rename.c cc -O2 -fno-strict-aliasing -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/libbinutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/include -DTARGET=\"x86_64-obrien-freebsd\" -DBFD_VERSION_STRING=\""2.15 [FreeBSD] 2004-05-23"\" -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils/stabs.c cc -O2 -fno-strict-aliasing -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/usr/src/gnu/usr.bin/binutils/libbinutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/libbinutils/../libbfd -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/include -DTARGET=\"x86_64-obrien-freebsd\" -DBFD_VERSION_STRING=\""2.15 [FreeBSD] 2004-05-23"\" -D_GNU_SOURCE -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils -I/usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils/unwind-ia64.c /usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils/debug.c: In function 'debug_write_name': /usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils/debug.c:2407: internal compiler error: Bus error: 10 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error after the classical $ chflags -R noschg /usr/obj/usr && cd /usr/src && make cleandir && make cleandir && make -j10 buildworld I've sync the source tree (with 7_2 tag) previously, of course. ¿Any clues? I've never seen this kind ok error in builworld stage. -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 11:54:55 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3164106568B for ; Wed, 16 Dec 2009 11:54:55 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by mx1.freebsd.org (Postfix) with ESMTP id 45AF08FC23 for ; Wed, 16 Dec 2009 11:54:54 +0000 (UTC) Received: from slackbox.xs4all.nl (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id nBGBsqqM092741; Wed, 16 Dec 2009 12:54:53 +0100 (CET) (envelope-from rsmith@xs4all.nl) Received: by slackbox.xs4all.nl (Postfix, from userid 1001) id B47C8BA90; Wed, 16 Dec 2009 12:54:52 +0100 (CET) Date: Wed, 16 Dec 2009 12:54:52 +0100 From: Roland Smith To: Mark Linimon Message-ID: <20091216115452.GA1888@slackbox.xs4all.nl> References: <20091216102850.GA99834@slackbox.xs4all.nl> <20091216105546.GG14175@lonesome.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline In-Reply-To: <20091216105546.GG14175@lonesome.com> X-GPG-Fingerprint: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 X-GPG-Key: http://www.xs4all.nl/~rsmith/pubkey.txt X-GPG-Notice: If this message is not signed, don't assume I sent it! User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-stable@freebsd.org, grarpamp Subject: Re: Using RELENG_8 to compile for older RELENG_x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 11:54:55 -0000 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 16, 2009 at 04:55:46AM -0600, Mark Linimon wrote: > On Wed, Dec 16, 2009 at 11:28:51AM +0100, Roland Smith wrote: > > the current ports tree isn't guaranteed to work on [4.x] either. >=20 > s/isn't guaranteed to/is guaranteed not to/ That's what I thought, but I couldn't quickly locate a reference to that event. I seem to recall a mailing list message to that event, but as I was already running a later version it didn't quite register. In the days before 5.3 or even 6.0 I could understand why people clung to 4.x. But now it seems like inviting trouble. Roland --=20 R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAksoyowACgkQEnfvsMMhpyWLbQCgkCA12L0FqkUh5lx9yTtwmcbF SiwAn0xUkiiDqzFGAzWeQajsp+Eg7/CS =2EU6 -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV-- From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 12:13:30 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9C04106566B for ; Wed, 16 Dec 2009 12:13:30 +0000 (UTC) (envelope-from ben@morrow.me.uk) Received: from relay.ptn-ipout01.plus.net (relay.ptn-ipout01.plus.net [212.159.7.35]) by mx1.freebsd.org (Postfix) with ESMTP id 550448FC1E for ; Wed, 16 Dec 2009 12:13:30 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEANddKEvUOFPl/2dsb2JhbACBS9J7hCsE Received: from plesk-mail01.plus.net ([212.56.83.229]) by relay.ptn-ipout01.plus.net with ESMTP; 16 Dec 2009 12:13:29 +0000 Received: (qmail 8948 invoked from network); 16 Dec 2009 12:13:27 +0000 Received: from host86-146-192-188.range86-146.btcentralplus.com (HELO osiris.mauzo.dyndns.org) (86.146.192.188) by plesk-mail01.plus.net with SMTP; 16 Dec 2009 12:13:27 +0000 Received: (qmail 46732 invoked by uid 1001); 16 Dec 2009 12:13:26 -0000 Date: Wed, 16 Dec 2009 12:13:26 +0000 From: Ben Morrow To: sthaug@nethelp.no, freebsd-stable@freebsd.org Message-ID: <20091216121326.GA46703@osiris.mauzo.dyndns.org> Mail-Followup-To: sthaug@nethelp.no, freebsd-stable@freebsd.org References: <200912151720.37709.freebsd@insightbb.com> <20091216000803.GA39686@osiris.mauzo.dyndns.org> <7BA0C6CC-A1D9-49C2-942D-D46C19E9B3CB@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091216.113300.74685382.sthaug@nethelp.no> X-Newsgroups: gmane.os.freebsd.stable Organization: Who, me? User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: update to 8.0-RELEASE --> partition gone X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 12:13:30 -0000 Quoth sthaug@nethelp.no: > > If you installed "dangerously dedicated" and ended up > > with ad0s1a (note the "s1"), then you have an invalid > > partitioning and FreeBSD 8.x will not give you what > > you've been getting on FreeBSD 7.x. Most of the time > > you only need to wipe out the second sector on the > > disk to clean it up and have FreeBSD 8.x also give > > you ad0s1a. > > So what's an easy recipe we can run on 7.x hosts to see whether we > would have problems with 8.x? >From what's been said so far: If you have adXsY devices in 7, *and* bsdlabel adX finds a valid label (*note*: that is the whole disk, not the slice), then you have conflicting BSD and MBR labels at the start of the disk and you will have a problem in 8. Ben From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 12:29:03 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38C101065672 for ; Wed, 16 Dec 2009 12:29:03 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 034B28FC23 for ; Wed, 16 Dec 2009 12:29:02 +0000 (UTC) Received: (qmail 23870 invoked from network); 16 Dec 2009 12:29:02 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@69.123.45.64) by acm.poly.edu with AES256-SHA encrypted SMTP; 16 Dec 2009 12:29:02 -0000 Message-ID: <4B28D281.80706@acm.poly.edu> Date: Wed, 16 Dec 2009 07:28:49 -0500 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.23 (X11/20090910) MIME-Version: 1.0 To: Derek Kulinski References: <110163611.20091216031952@takeda.tk> In-Reply-To: <110163611.20091216031952@takeda.tk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Problems with Atheros card and hostpd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 12:29:03 -0000 Multi-BSS support in 8.0 means that you first need to create a wlan pseudo-device, and run hostapd with that. The rc.conf lines look like this: wlans_ath0="wlan0" create_args_wlan0="wlanmode hostap" ifconfig_wlan0="ssid networkname media autoselect up" -Boris Derek Kulinski wrote: > Hello, > > I just upgraded my access point (from 7.1 to 8.0) and can't make > hostapd work (looks like wide-dhcp relay also has a problem with ath0): > > [mayumi]:/root# hostapd -P /var/run/hostapd.pid -dd /etc/hostapd.conf > Configuration file: /etc/hostapd.conf > Line 2: DEPRECATED: 'debug' configuration variable is not used anymore > ctrl_interface_group=0 (from group name 'wheel') > pcap_open_live: > ifname='ath0' > bsd driver initialization failed. > ath0: Unable to setup interface. > rmdir[ctrl_interface]: No such file or directory > Exit 255 > > Output from dmesg: > ath0: mem 0xf4000000-0xf400ffff irq 3 at device 11.0 on pci0 > ath0: [ITHREAD] > ath0: AR2413 mac 7.9 RF2413 phy 4.5 > > The interface seems to exist, but seems it lost some of its > functionality: > [mayumi]:/root# ifconfig ath0 > ath0: flags=8843 metric 0 mtu 2290 > ether 00:11:95:e5:70:df > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > [mayumi]:/root# ifconfig ath0 list cap > ifconfig: Don't know how to list cap for ath0 > > What's going on? The card worked pretty well with 7.1. > > I tried to compile kernel just with "device ath_ar5212" > but I'm only getting this: > > ah.o(.text+0x212): In function `ath_hal_rfprobe': > /usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__start_set_ah_rfs' > ah.o(.text+0x21f):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__stop_set_ah_rfs' > ah.o(.text+0x235):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__stop_set_ah_rfs' > > From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 12:32:01 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F43D1065672 for ; Wed, 16 Dec 2009 12:32:01 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id CABEC8FC14 for ; Wed, 16 Dec 2009 12:32:00 +0000 (UTC) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id nBGCVvxO084560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Dec 2009 13:31:58 +0100 (CET) (envelope-from stb@lassitu.de) (authenticated as stb) From: Stefan Bethke To: Derek Kulinski In-Reply-To: <110163611.20091216031952@takeda.tk> X-Priority: 3 (Normal) References: <110163611.20091216031952@takeda.tk> Message-Id: <9B3DF52B-0B54-46E3-A1B9-932358E77789@lassitu.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 16 Dec 2009 13:31:57 +0100 X-Mailer: Apple Mail (2.936) Cc: freebsd-stable@freebsd.org Subject: Re: Problems with Atheros card and hostpd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 12:32:01 -0000 Am 16.12.2009 um 12:19 schrieb Derek Kulinski: > Hello, > > I just upgraded my access point (from 7.1 to 8.0) and can't make > hostapd work (looks like wide-dhcp relay also has a problem with > ath0): Things got a bit more complicated (and more powerful) with 8.0: you now have to configure a virtual wireless interface, attached to the physical one. Unfortunatly, the handbook has not quite caught up with this change. Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 12:32:49 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD0EA1065670 for ; Wed, 16 Dec 2009 12:32:49 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E6D0A8FC19 for ; Wed, 16 Dec 2009 12:32:48 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA04258; Wed, 16 Dec 2009 14:32:45 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B28D36D.8090502@icyb.net.ua> Date: Wed, 16 Dec 2009 14:32:45 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Jordi Espasa Clofent References: <4B28C842.3030704@minibofh.org> In-Reply-To: <4B28C842.3030704@minibofh.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: Error upgrading 7.0 to 7.2 (buildword in gnu/usr.bin/binutils/libopcodes setp) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 12:32:49 -0000 on 16/12/2009 13:45 Jordi Espasa Clofent said the following: [snip] > /usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/binutils/debug.c:2407: > internal compiler error: Bus error: 10 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > *** Error code 1 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > > after the classical > > $ chflags -R noschg /usr/obj/usr && cd /usr/src && make cleandir && make > cleandir && make -j10 buildworld > > I've sync the source tree (with 7_2 tag) previously, of course. > > ¿Any clues? I've never seen this kind ok error in builworld stage. Internal compiler errors during kernel/world build typically[*] point to hardware problems. Especially so on stable branches. [*] 'Typically' is a great under-emphasizing here. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 12:47:36 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31648106566C; Wed, 16 Dec 2009 12:47:36 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id ADF8D8FC0C; Wed, 16 Dec 2009 12:47:35 +0000 (UTC) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id nBGClXCB086788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Dec 2009 13:47:34 +0100 (CET) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <3D5B7272-3FAD-473A-A48A-5775A1BA28CC@lassitu.de> From: Stefan Bethke To: Jeremy Chadwick In-Reply-To: <20091215202446.GA75896@icarus.home.lan> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 16 Dec 2009 13:47:33 +0100 References: <1260638581.00193503.1260625202@10.7.7.3> <4B23DC8B.8020807@FreeBSD.org> <3979a4b0912151044i5c3031ebo41ed0cb482461ea9@mail.gmail.com> <20091215202446.GA75896@icarus.home.lan> X-Mailer: Apple Mail (2.936) Cc: Alexander Motin , freebsd-stable@freebsd.org Subject: Basic SMART info "out of the box" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 12:47:36 -0000 Am 15.12.2009 um 21:24 schrieb Jeremy Chadwick: > [1]: It's hardly done and needs a *lot* of work, but I'll eventually > get it into a state where it could be committed and people could > hack on > it/improve it. It's no where near as defined as smartmontools (re: > disk > vendor/model one-offs for attribute parsing and so on), but I figured > FreeBSD users might want something out-of-the-box which might give > them > stats which are most commonly focused on (sector reallocation, drive > temperature, high spin-up times, CRC errors, etc.). I guess you could > say I'm a bit proud of myself given that I was able to figure out > how to > accomplish it by looking at some smartmontools source (messy, let me > tell you...) and ata(4) bits (since the ioctls aren't documented). > > [2]: Yes, I'm still working on writing that doc that explains how to > read SMART data. Going to have to end up doing it for work as well... > oh the joys. :-) Yes please, I'd like to see basic SMART diagnostics out of the box in the base system! I've looked at doing something similar on and off for a long time, but never really got beyond the basic ioctl proof of concept stage. Since it appears ata and atacontrol might be replaced by CAM, and SCSI devices can also support SMART, would it be possible to add this to camcontrol or a similar utility? Thanks, Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 12:51:59 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96C311065670 for ; Wed, 16 Dec 2009 12:51:59 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.7]) by mx1.freebsd.org (Postfix) with ESMTP id 6CA9A8FC12 for ; Wed, 16 Dec 2009 12:51:59 +0000 (UTC) Received: (qmail 18839 invoked from network); 16 Dec 2009 12:51:58 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 16 Dec 2009 12:51:58 -0000 Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.6]) by be-well.ilk.org (Postfix) with ESMTP id C343D5089F; Wed, 16 Dec 2009 07:51:52 -0500 (EST) Received: by lowell-desk.lan (Postfix, from userid 1147) id 4BF851CC31; Wed, 16 Dec 2009 07:51:52 -0500 (EST) From: Lowell Gilbert To: Jordi Espasa Clofent References: <4B28C842.3030704@minibofh.org> Date: Wed, 16 Dec 2009 07:51:51 -0500 In-Reply-To: <4B28C842.3030704@minibofh.org> (Jordi Espasa Clofent's message of "Wed, 16 Dec 2009 12:45:06 +0100") Message-ID: <448wd39j4o.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Error upgrading 7.0 to 7.2 (buildword in gnu/usr.bin/binutils/libopcodes setp) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 12:51:59 -0000 Jordi Espasa Clofent writes: > /usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/bi= nutils/debug.c: > In function 'debug_write_name': > /usr/src/gnu/usr.bin/binutils/libbinutils/../../../../contrib/binutils/bi= nutils/debug.c:2407: > internal compiler error: Bus error: 10 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > *** Error code 1 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > > after the classical > > $ chflags -R noschg /usr/obj/usr && cd /usr/src && make cleandir && > make cleandir && make -j10 buildworld > > I've sync the source tree (with 7_2 tag) previously, of course. > > =BFAny clues? I've never seen this kind ok error in builworld stage. Does it always happen in the same place (if not, it's a hardware problem)? Does it happen the same way without the '-j' option (that can make the output less useful)? From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 13:01:05 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 438961065672 for ; Wed, 16 Dec 2009 13:01:05 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id 24ABF8FC1A for ; Wed, 16 Dec 2009 13:01:04 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 978A98C07D; Wed, 16 Dec 2009 07:01:04 -0600 (CST) Date: Wed, 16 Dec 2009 07:01:04 -0600 From: Mark Linimon To: Roland Smith Message-ID: <20091216130104.GA18870@lonesome.com> References: <20091216102850.GA99834@slackbox.xs4all.nl> <20091216105546.GG14175@lonesome.com> <20091216115452.GA1888@slackbox.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091216115452.GA1888@slackbox.xs4all.nl> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org, grarpamp Subject: Re: Using RELENG_8 to compile for older RELENG_x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 13:01:05 -0000 On Wed, Dec 16, 2009 at 12:54:52PM +0100, Roland Smith wrote: > In the days before 5.3 or even 6.0 I could understand why people clung to > 4.x. But now it seems like inviting trouble. 5.3 still had a lot of sharp edges (a lot of things were merged into it just prior to release). But at this point, we're even phasing out 6.x. Really, I would hope that everyone except people embedding FreeBSD into their products (and thus have long development cycles) would be on 7.x by now. It has a much better chance of running on modern hardware. mcl From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 13:01:44 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 528E51065679 for ; Wed, 16 Dec 2009 13:01:44 +0000 (UTC) (envelope-from info@martenvijn.nl) Received: from mail.math.leidenuniv.nl (84e5e739.math.leidenuniv.nl [132.229.231.57]) by mx1.freebsd.org (Postfix) with ESMTP id E7C0F8FC0A for ; Wed, 16 Dec 2009 13:01:43 +0000 (UTC) Received: from [132.229.231.13] (polaris.math.leidenuniv.nl [132.229.231.13]) by mail.math.leidenuniv.nl (Postfix) with ESMTP id 9C1556E833; Wed, 16 Dec 2009 13:44:51 +0100 (CET) From: Marten Vijn To: Derek Kulinski In-Reply-To: <110163611.20091216031952@takeda.tk> References: <110163611.20091216031952@takeda.tk> Content-Type: text/plain Date: Wed, 16 Dec 2009 13:44:52 +0100 Message-Id: <1260967492.7721.18.camel@polaris> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Problems with Atheros card and hostpd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 13:01:44 -0000 On Wed, 2009-12-16 at 03:19 -0800, Derek Kulinski wrote: > Hello, > > I just upgraded my access point (from 7.1 to 8.0) and can't make > hostapd work (looks like wide-dhcp relay also has a problem with ath0): > The ifconfig usage changed in 8.0 The Handbook is not correct: http://www.freebsd.org/doc/en/books/handbook/network-wireless.html see: http://forums.freebsd.org/showthread.php?t=8784 and a small tutorial from my hand: http://martenvijn.nl/trac/wiki/ap may show usefull command and config for you. Here: http://www.freebsd.org/doc/en/books/handbook/network-wireless.html the Handbook is not correct... I hope this helps, cheers, Marten > [mayumi]:/root# hostapd -P /var/run/hostapd.pid -dd /etc/hostapd.conf > Configuration file: /etc/hostapd.conf > Line 2: DEPRECATED: 'debug' configuration variable is not used anymore > ctrl_interface_group=0 (from group name 'wheel') > pcap_open_live: > ifname='ath0' > bsd driver initialization failed. > ath0: Unable to setup interface. > rmdir[ctrl_interface]: No such file or directory > Exit 255 > > Output from dmesg: > ath0: mem 0xf4000000-0xf400ffff irq 3 at device 11.0 on pci0 > ath0: [ITHREAD] > ath0: AR2413 mac 7.9 RF2413 phy 4.5 > > The interface seems to exist, but seems it lost some of its > functionality: > [mayumi]:/root# ifconfig ath0 > ath0: flags=8843 metric 0 mtu 2290 > ether 00:11:95:e5:70:df > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > [mayumi]:/root# ifconfig ath0 list cap > ifconfig: Don't know how to list cap for ath0 > > What's going on? The card worked pretty well with 7.1. > > I tried to compile kernel just with "device ath_ar5212" > but I'm only getting this: > > ah.o(.text+0x212): In function `ath_hal_rfprobe': > /usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__start_set_ah_rfs' > ah.o(.text+0x21f):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__stop_set_ah_rfs' > ah.o(.text+0x235):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__stop_set_ah_rfs' > -- Marten Vijn linux 2.0.18 OpenBSD 3.6 FreeBSD 4.6 http://martenvijn.nl http://opencommunitycamp.org http://wifisoft.org From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 13:06:39 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 999E0106566C for ; Wed, 16 Dec 2009 13:06:39 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 5F7A48FC1C for ; Wed, 16 Dec 2009 13:06:39 +0000 (UTC) Received: from [192.168.1.4] (adsl-156-16-112.bna.bellsouth.net [70.156.16.112]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nBGD6XWZ099158 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 08:06:34 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Adam Jacob Muller In-Reply-To: <42F3C226-766E-45BA-AB2E-74643B3E8724@adam.gs> References: <2A3A50FE-13F4-4AA7-976E-37354E5736B5@adam.gs> <4B256907.4060805@lazlarlyricon.com> <1260805564.2281.86.camel@balrog.2hip.net> <42F3C226-766E-45BA-AB2E-74643B3E8724@adam.gs> Content-Type: text/plain Organization: FreeBSD Date: Wed, 16 Dec 2009 06:48:03 -0600 Message-Id: <1260967683.2281.117.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-stable@freebsd.org, Adam Jacob Muller , Rolf G Nielsen Subject: Re: freebsd / gpt boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 13:06:39 -0000 On Tue, 2009-12-15 at 17:11 -0500, Adam Jacob Muller wrote: > On Dec 14, 2009, at 10:46 AM, Robert Noland wrote: > > > On Sun, 2009-12-13 at 23:21 +0100, Rolf G Nielsen wrote: > >> Adam Jacob Muller wrote: > >>> Hi, > >>> I'm trying to setup a system with a very large RAID array (total ~10TB), I would ideally like to have the system boot directly off that 10TB array, so i'm trying to get the system setup with GPT but running into an issue. > >>> > >>> > >>> The initial pre-loader (boot0 I think? -- i'm not sure what this is called) is unable to find loader at /boot/loader nor can it load /boot/kernel/kernel > >>> > >> > >> Is the partitioning done correctly (have you created a small boot > >> partition, 15 sectors is enough for booting from ufs, but the tutorials > >> I've found deal mainly with booting from zfs and they recommend 128 > >> sectors to make future bootcode changes easier)? > > > > You will need to be doing all of this from a current 8-STABLE. One bug > > in dealing with larger zfs raidz volumes was fixed and made it into 8.0. > > Another, which deals with GPT/ZFS and large volumes did not make it and > > only exists in 8-STABLE, iirc. Also, with the gptzfsboot code from > > -STABLE, it will request to load /boot/zfsloader by default (and > > LOADER_ZFS_SUPPORT is no longer required). > > > >> gpart add -b 34 -s 128 -t freebsd-boot -i 1 da0 > >> > >> Have you embedded the correct boot code? > >> > >> gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 da0 > >> (for booting from ufs). > >> > >> or > >> > >> gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 > >> (for booting from zfs). > >> > >> You may also need to set it active by > >> > >> gpart set -a active -i 1 da0 > > > > The above step is no longer needed on -STABLE, the pmbr will be marked > > active when you install bootcode. > > Robert, > Do either of these bugs affect GPT/UFS, which is what I am using here. I thought that one of them was relevant, but looking back at the patch, I believe that it only impacted gpt + zfs. robert. > These bugs are affecting the actual older versions of the tools (IE using the gpart from an 8.0-pre or earlier could cause issues like this)? > > Also, perhaps not coincidentally, booting the FreeBSD memstick image produces the same error (boot0 can't find loader). > > > -Adam > > > > > robert. > > > >> And of course, substitute your arrays device node for da0 in my examples. > >> > >>> Copying /boot/loader to /loader allows me to enter /loader at the "boot:" prompt and the loader will load, however, its unable to load the kernel. > >>> > >>> If I do an "ls" at the loader prompt I can see boot listed as a directory (with a "d" before it) > >>> Trying to do "ls boot" inexplicably it says "boot: not a directory" > >>> > >>> re-applying my /boot/loader.conf settings (for some reason vfs.root.mountfrom=ufs:/dev/label/root is required, or else I get a mountroot>) and then: > >>> load /kernel > >>> boot > >>> > >>> does work, and lets the system boot normally and everything is as expected (/boot is a directory etc). > >>> > >>> Anyone have any ideas about either of these things (the vfs.root.mountfrom is minor i guess but i'm curious if they are related?) > >>> > >>> Thanks in advance, > >>> > >>> -Adam > >>> > >>> _______________________________________________ > >>> freebsd-stable@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > >>> > >>> > >>> > >> > >> _______________________________________________ > >> freebsd-stable@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > -- > > Robert Noland > > FreeBSD > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 13:19:57 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AEE81065693 for ; Wed, 16 Dec 2009 13:19:57 +0000 (UTC) (envelope-from jg@koderize.com) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by mx1.freebsd.org (Postfix) with ESMTP id 1A8B08FC1D for ; Wed, 16 Dec 2009 13:19:56 +0000 (UTC) Received: from [93.93.130.49] (helo=sphinx.mythic-beasts.com) by haggis.mythic-beasts.com with esmtp (Exim 4.69) (envelope-from ) id 1NKtCL-0004cz-2I for freebsd-stable@freebsd.org; Wed, 16 Dec 2009 12:41:45 +0000 Received: from host86-180-142-23.range86-180.btcentralplus.com ([86.180.142.23] helo=bsdbox.koderize.com) by sphinx.mythic-beasts.com with esmtpa (Exim 4.62) (envelope-from ) id 1NKtCI-00062L-Cf for freebsd-stable@freebsd.org; Wed, 16 Dec 2009 12:41:44 +0000 Received: from bsdbox.koderize.com (localhost [127.0.0.1]) by bsdbox.koderize.com (8.14.3/8.14.3) with ESMTP id nBGCfeXl006090 for ; Wed, 16 Dec 2009 12:41:41 GMT (envelope-from jg@bsdbox.koderize.com) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at bsdbox.koderize.com Received: (from jg@localhost) by bsdbox.koderize.com (8.14.3/8.14.3/Submit) id nBGCfeHX006089 for freebsd-stable@freebsd.org; Wed, 16 Dec 2009 12:41:40 GMT (envelope-from jg) Date: Wed, 16 Dec 2009 12:41:40 +0000 From: Jamie Griffin To: freebsd-stable@freebsd.org Message-ID: <20091216124140.GA5954@bsdbox.koderize.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 7.2-RELEASE-p5 X-Organization: Koderize.com X-Web-Site: http://www.koderize.com X-PGP-Key: 0x842DD368 http://www.koderize.com/jpg-gnupg.asc X-PGP-Key-Fingerprint: F850 A09C F877 FBC4 A63C FDDC 7484 4EEF 842D D368 User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bsdbox.koderize.com X-Mythic-Sender-Verify: + host 93.93.131.52 accepted RCPT TO with '250 Accepted' X-Spam-Status: No, score=-0.0 X-BlackCat-Spam-Score: 0 Received-SPF: none (sphinx.mythic-beasts.com: domain of jg@koderize.com does not designate permitted sender hosts) client-ip=86.180.142.23 envelope-from=jg@koderize.com helo=bsdbox.koderize.com Subject: freebsd-questions mailing list X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jg@koderize.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 13:19:57 -0000 Has anyone else noticed a problem with this list, I haven't received a message from the freebsd-questions list for over 24 hours :0/ Jamie From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 13:25:31 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6107106566B for ; Wed, 16 Dec 2009 13:25:30 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 27A618FC18 for ; Wed, 16 Dec 2009 13:25:29 +0000 (UTC) Received: (qmail 98937 invoked from network); 16 Dec 2009 13:25:28 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 16 Dec 2009 13:25:28 -0000 Date: Wed, 16 Dec 2009 14:25:28 +0100 (CET) Message-Id: <20091216.142528.74661073.sthaug@nethelp.no> To: ben@morrow.me.uk From: sthaug@nethelp.no In-Reply-To: <20091216121326.GA46703@osiris.mauzo.dyndns.org> References: <7BA0C6CC-A1D9-49C2-942D-D46C19E9B3CB@mac.com> <20091216.113300.74685382.sthaug@nethelp.no> <20091216121326.GA46703@osiris.mauzo.dyndns.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: update to 8.0-RELEASE --> partition gone X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 13:25:31 -0000 > > > If you installed "dangerously dedicated" and ended up > > > with ad0s1a (note the "s1"), then you have an invalid > > > partitioning and FreeBSD 8.x will not give you what > > > you've been getting on FreeBSD 7.x. Most of the time > > > you only need to wipe out the second sector on the > > > disk to clean it up and have FreeBSD 8.x also give > > > you ad0s1a. > > > > So what's an easy recipe we can run on 7.x hosts to see whether we > > would have problems with 8.x? > > >>From what's been said so far: If you have adXsY devices in 7, *and* > > bsdlabel adX > > finds a valid label (*note*: that is the whole disk, not the slice), > then you have conflicting BSD and MBR labels at the start of the disk > and you will have a problem in 8. So presumably if I have root on ad4s1a today, and bsdlabel shows # bsdlabel ad4 bsdlabel: /dev/ad4: no valid label found then I am ready for FreeBSD 8.x? Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 13:48:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA4D8106568B; Wed, 16 Dec 2009 13:48:10 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id AE4C98FC19; Wed, 16 Dec 2009 13:48:10 +0000 (UTC) Received: from [192.168.1.4] (adsl-156-16-112.bna.bellsouth.net [70.156.16.112]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nBGDm4ph099382 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 08:48:05 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: John Baldwin In-Reply-To: <200912151551.30550.jhb@freebsd.org> References: <20091213191905.GA76785@osiris.chen.org.nz> <200912151018.36607.jhb@freebsd.org> <20091215194703.GA10572@osiris.chen.org.nz> <200912151551.30550.jhb@freebsd.org> Content-Type: text/plain Organization: FreeBSD Date: Wed, 16 Dec 2009 07:47:56 -0600 Message-Id: <1260971276.26065.14.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-stable@freebsd.org Subject: Re: Dell D830, nVidia and FreeBSD-8/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 13:48:11 -0000 On Tue, 2009-12-15 at 15:51 -0500, John Baldwin wrote: > On Tuesday 15 December 2009 2:47:03 pm Jonathan Chen wrote: > > On Tue, Dec 15, 2009 at 10:18:36AM -0500, John Baldwin wrote: > > > On Monday 14 December 2009 9:37:51 pm Jonathan Chen wrote: > > > > On Mon, Dec 14, 2009 at 10:46:27AM -0500, John Baldwin wrote: > > > > > On Sunday 13 December 2009 2:19:05 pm Jonathan Chen wrote: > > > > > > Hi, > > > > > > > > > > > > This is a general rehash of a problem that I've been having with my > > > > > > Dell Latitude D830 with an nVidia Quadro NVS 140M internal graphics > > > > > > card. I've been using the XOrg's "vesa" driver ever since something in > > > the > > > > > > code rendered the "nvidia" driver inoperable in 7-STABLE sometime mid > > > > > > last year. With nVidia's new 195.22 (BETA) drivers, I had hoped that I > > > > > > could bypass the problem. Unfortunately, I seem to be experiencing the > > > same > > > > > > problem as described in the following thread: > > > > > > > > > > > > http://www.nvnews.net/vbulletin/showthread.php?t=142391 > > > > > > > > > > > > which appears to be implying that something in the kernel is > > > > > > interfering with memory allocation. Would it be possible for someone > > > > > > with deeper kernel-fu be able to take a look at this issue? > > > > > > > > > > Do you have a verbose dmesg available? > > > > > > > > I've attached a dmesg with a verbose boot. I hope this is what you're > > > > looking for. > > > > > > Ok, can you grab the output of 'devinfo -r' and 'devinfo -ur'? I suspect that > > > when the bridge allocates the prefetch resource range from the parent it is > > > failing somehow. For a quick hack try something like this: > > [...] > > > > I've attatched the requested output. Unfortunately, the patch didn't > > result in anything different. > > > > I/O memory addresses: > > 0xdff00000-0xe06fffff (acpi0) > > 0xe0700000-0xe0700fff (cbb0) > > 0xe0701000-0xf3ffffff (root0) > > The root0 range is ok (it really means free), but the cbb0 and acpi0 ranges > here conflict with the prefetch BAR for the video adapter. The cbb0 one I > think is because that range is free when cbb0 needs to allocate a fresh range > of resources. The real bug is why your BIOS thinks that a system resource is > using 0xe0000000-0xe06fffff which conflicts with the nvidia card. You can > try disabling ACPI's system-resource handling (set > debug.acpi.disabled="sysres" from the loader). I'm not sure what is the root issue, but we have seen system resource conflicts like this reasonably often with Nvidia graphics. I've never some across this issue with any other display adapter. But I've had at least a handful of reports of noveau not working due to this issue. robert. -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 13:53:45 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B6201065672 for ; Wed, 16 Dec 2009 13:53:45 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 114878FC1B for ; Wed, 16 Dec 2009 13:53:44 +0000 (UTC) Received: by fxm27 with SMTP id 27so921607fxm.3 for ; Wed, 16 Dec 2009 05:53:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=LSbvNoD6gtjs5zlw+ZWid2xLRnjQbzaWv9pk1wxcUI8=; b=Rsh93a1ipHEwP4OtxI2mAqCbgEJVavAG35B5FKeA8v5sjLkKg/UJOIzTFVKTWgeYI4 JUQP8WBg49BwftrpJZh8TuzBsKaQlppRrmIpAP89SUOl6/CVvNiubIJqwRABvQLzKvVj 57FMA2E0EEApimVOkd6m/H6Nk2UEwGTgC4ui4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=s6bo+jvYUbv41w03vr2MZx8IvVUZWMsVGhX7Dxx3LtfE7PDyiS43rrr4wX96NRZ/or GOrHTbH4sSkLhg2JNjfRGSVayHiQNMcbqvr1pBG+ULeJ29Pzd557uJvah9/dyGJGxn3E RFwzgJxp8uEGvcuAWMQ39QCKrSVQZV/yd7Fzg= MIME-Version: 1.0 Received: by 10.223.54.15 with SMTP id o15mr1209635fag.96.1260971623954; Wed, 16 Dec 2009 05:53:43 -0800 (PST) In-Reply-To: <20091216124140.GA5954@bsdbox.koderize.com> References: <20091216124140.GA5954@bsdbox.koderize.com> Date: Wed, 16 Dec 2009 08:53:43 -0500 Message-ID: <4ad871310912160553s2790da5cwa1a0cca65341cb07@mail.gmail.com> From: Glen Barber To: jg@koderize.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: freebsd-questions mailing list X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 13:53:45 -0000 On Wed, Dec 16, 2009 at 7:41 AM, Jamie Griffin wrote: > Has anyone else noticed a problem with this list, I haven't received a > message from the freebsd-questions list for over 24 hours :0/ > Sign me up for a "me too." The last message from that list in my mailbox is the (overly drawn out) Root Exploit thread. -- Glen Barber From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 13:59:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF2081065679 for ; Wed, 16 Dec 2009 13:59:29 +0000 (UTC) (envelope-from jfb@mr-paradox.net) Received: from vexbert.mr-paradox.net (vexbert.mr-paradox.net [IPv6:2001:470:b:28:f::1]) by mx1.freebsd.org (Postfix) with ESMTP id C6A8C8FC1A for ; Wed, 16 Dec 2009 13:59:29 +0000 (UTC) Received: by vexbert.mr-paradox.net (Postfix, from userid 16139) id 6F7B68459F; Wed, 16 Dec 2009 08:59:29 -0500 (EST) Date: Wed, 16 Dec 2009 08:59:28 -0500 From: Jeff Blank To: freebsd-stable@freebsd.org Message-ID: <20091216135928.GB4674@mr-happy.com> References: <4B28BCAA.1010002@icyb.net.ua> <21859b54848003a15761f546aed36f1f@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21859b54848003a15761f546aed36f1f@localhost> X-Face: #0jV*~a}VtKS-&E/!EJpH('H1Va}24dxF0oT&+.R3Gu8C; xhSC+<|+H84&YLbMvphuRT4cp3.|8EN_(2Eix/6{.Up~u`a^}0Ln&b+9Fw|BPig@-{y\pL_46d&ZwA]5%_AU?}DezfE&1!>H?3E$!Yve7.O<+..Jnb4:'6Ey_]FtFzU9=*l$1p/@gA,Ze>^5<]+r(XJ+m7`/vMDc$'wy|`e Subject: Re: update to 8.0-RELEASE --> partition gone X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 13:59:30 -0000 On Wed, Dec 16, 2009 at 12:27:15PM +0100, Marian Hettwer wrote: > but, hm, whats that? > root@talisker:/root# fsck /dev/ad8s1a > fsck: Could not determine filesystem type If you don't have an entry for /dev/ad8s1a in your fstab, you need to specify the filesystem type with -t. Jeff From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 14:08:13 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64D4C1065672 for ; Wed, 16 Dec 2009 14:08:13 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (tunnel490.ipv6.xs4all.nl [IPv6:2001:888:10:1ea::2]) by mx1.freebsd.org (Postfix) with ESMTP id E97458FC08 for ; Wed, 16 Dec 2009 14:08:12 +0000 (UTC) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.14.2/8.14.2) with ESMTP id nBGE79uj088373; Wed, 16 Dec 2009 15:07:09 +0100 (CET) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.14.2/8.14.2/Submit) id nBGE78hq088372; Wed, 16 Dec 2009 15:07:08 +0100 (CET) (envelope-from mail25@bzerk.org) Date: Wed, 16 Dec 2009 15:07:08 +0100 From: Ruben de Groot To: Glen Barber Message-ID: <20091216140708.GA88313@ei.bzerk.org> Mail-Followup-To: Ruben de Groot , Glen Barber , jg@koderize.com, freebsd-stable@freebsd.org References: <20091216124140.GA5954@bsdbox.koderize.com> <4ad871310912160553s2790da5cwa1a0cca65341cb07@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ad871310912160553s2790da5cwa1a0cca65341cb07@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (ei.bzerk.org [127.0.0.1]); Wed, 16 Dec 2009 15:08:11 +0100 (CET) Cc: freebsd-stable@freebsd.org, jg@koderize.com Subject: Re: freebsd-questions mailing list X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 14:08:13 -0000 On Wed, Dec 16, 2009 at 08:53:43AM -0500, Glen Barber typed: > On Wed, Dec 16, 2009 at 7:41 AM, Jamie Griffin wrote: > > Has anyone else noticed a problem with this list, I haven't received a > > message from the freebsd-questions list for over 24 hours :0/ > > > > Sign me up for a "me too." The last message from that list in my > mailbox is the (overly drawn out) Root Exploit thread. Yup, I noticed this too. Last message in the archives is from Sun Dec 13 17:10:40 UTC 2009 From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 14:36:30 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 004C41065679 for ; Wed, 16 Dec 2009 14:36:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id DA2A38FC2B for ; Wed, 16 Dec 2009 14:36:29 +0000 (UTC) Received: from OMTA21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by QMTA13.emeryville.ca.mail.comcast.net with comcast id HqZH1d00A1u4NiLADqcWdY; Wed, 16 Dec 2009 14:36:30 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by OMTA21.emeryville.ca.mail.comcast.net with comcast id HqcV1d0053S48mS8hqcVD2; Wed, 16 Dec 2009 14:36:30 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 393291E301B; Wed, 16 Dec 2009 06:36:28 -0800 (PST) Date: Wed, 16 Dec 2009 06:36:28 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20091216143628.GA98230@icarus.home.lan> References: <1260638581.00193503.1260625202@10.7.7.3> <4B23DC8B.8020807@FreeBSD.org> <3979a4b0912151044i5c3031ebo41ed0cb482461ea9@mail.gmail.com> <20091215202446.GA75896@icarus.home.lan> <3D5B7272-3FAD-473A-A48A-5775A1BA28CC@lassitu.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D5B7272-3FAD-473A-A48A-5775A1BA28CC@lassitu.de> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Basic SMART info "out of the box" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 14:36:30 -0000 On Wed, Dec 16, 2009 at 01:47:33PM +0100, Stefan Bethke wrote: > Am 15.12.2009 um 21:24 schrieb Jeremy Chadwick: > > >[1]: It's hardly done and needs a *lot* of work, but I'll eventually > >get it into a state where it could be committed and people could > >hack on > >it/improve it. It's no where near as defined as smartmontools > >(re: disk > >vendor/model one-offs for attribute parsing and so on), but I figured > >FreeBSD users might want something out-of-the-box which might give > >them > >stats which are most commonly focused on (sector reallocation, drive > >temperature, high spin-up times, CRC errors, etc.). I guess you could > >say I'm a bit proud of myself given that I was able to figure out > >how to > >accomplish it by looking at some smartmontools source (messy, let me > >tell you...) and ata(4) bits (since the ioctls aren't documented). > > > >[2]: Yes, I'm still working on writing that doc that explains how to > >read SMART data. Going to have to end up doing it for work as well... > >oh the joys. :-) > > Yes please, I'd like to see basic SMART diagnostics out of the box > in the base system! I've looked at doing something similar on and > off for a long time, but never really got beyond the basic ioctl > proof of concept stage. > > Since it appears ata and atacontrol might be replaced by CAM, and > SCSI devices can also support SMART, would it be possible to add > this to camcontrol or a similar utility? Highly likely. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 14:57:31 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9F111065692 for ; Wed, 16 Dec 2009 14:57:31 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6449D8FC15 for ; Wed, 16 Dec 2009 14:57:31 +0000 (UTC) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 0547319E044; Wed, 16 Dec 2009 15:57:30 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 65AA319E047; Wed, 16 Dec 2009 15:57:27 +0100 (CET) Message-ID: <4B28F557.6000305@quip.cz> Date: Wed, 16 Dec 2009 15:57:27 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0 MIME-Version: 1.0 To: Daniel Braniss References: <4B281279.6060706@quip.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, freebsd-stable Stable Subject: Re: iSCSI initiator and Dell PowerVault MD3000i X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 14:57:31 -0000 Daniel Braniss wrote: >> Hi all, >> I am playing with iscsi_initiator on FreeBSD 7-STABLE and Dell >> PowerVault MD3000i. This is the first time I am testing iSCSI... >> >> Does anyone have FreeBSD's iSCSI initiator in production / heavy load? >> Or does somebody have experiences with Dell MD3000i? >> >> One thing is "poor performance" ~ 60 - 70MB/s depending on RAID level >> used. (poor performance compared to plain SATA disk which have 110MB/s - >> both tested for reading as it is our planned load - multimedia streaming >> and downloads) >> >> >> The other thing is some problem with compatibility of initiator and Dell >> MD3000i. >> >> If I setup RAID 5 'Disk Group' consisted of 4x 1TB SATA drives (in >> MD3000i) and then created for example 2 'Virtual Disks', both are >> detected by iscontrol and added to /dev/ as da0 and da1, but da1 spams >> log with messages like this: [...] >> Can somebody advice some tweaks to get better performance and solution >> of the errors above? > > hi Miroslav, > firstly, in case you haven't yet, get the latest from: > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.2.3.tar.gz > the slowness is probably due to the scsi errors, which I need some scsi expert > (hence the cc to scsi@freebsd.org, hint, hint). > In the mean time, and if you can/want, you can allow me access to an iscsi > partition > so that I can better debug the issue. > oh, and yes, we use it here. > > danny Hi Danny, thank you for your reply. I will test iSCSI 2.2.3 and if it fails, I will give you an access to the machine to let you debug the errors. Thank you again! Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 15:28:17 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F7D51065694; Wed, 16 Dec 2009 15:28:17 +0000 (UTC) (envelope-from proks@skylinetele.com) Received: from Harpy.sky.od.ua (harpy.sky.od.ua [81.25.224.2]) by mx1.freebsd.org (Postfix) with ESMTP id D9AED8FC0A; Wed, 16 Dec 2009 15:28:16 +0000 (UTC) Received: from logos.sky.od.ua (logos [81.25.224.11]) by Harpy.sky.od.ua (8.12.10/8.12.10) with ESMTP id nBGF9Dwi008553; Wed, 16 Dec 2009 17:09:13 +0200 Message-ID: <4B28F841.1070900@skylinetele.com> Date: Wed, 16 Dec 2009 17:09:53 +0200 From: "Prokofiev S.P." User-Agent: Thunderbird 2.0.0.21 (X11/20090410) MIME-Version: 1.0 To: "Li, Qing" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Qing Li Subject: Re: net/mpd5, ppp, proxy-arp issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 15:28:17 -0000 Thank you ! The problem with proxy-arp has disappeared (FreeBSD 8-STABLE amd64 with mpd5). Please, somebody fix the bug kern/141285... Li, Qing wrote: > Hi, > > Recently there have been several reports regarding issues with ppp, mpd5 > and proxy-arp configuration over the ppp links. I read through the > various postings and the problems seem to be: > > 1. Unable to add proxy-arp entries for the remote ppp clients. > > 2. Log showing "ifa_add_loopback_route: insertion failed" causing > some userland applications to fail. > > May I ask that you try applying patch > > http://people.freebsd.org/~qingli/ppp-proxy-arp-patch-121515.diff > > and report back if the patch fixes your problems. And if not, > please describe what additional issues you are having. > > Thanks, > > -- Qing > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 15:46:16 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FEF8106566C for ; Wed, 16 Dec 2009 15:46:16 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.3]) by mx1.freebsd.org (Postfix) with ESMTP id 315728FC14 for ; Wed, 16 Dec 2009 15:46:15 +0000 (UTC) Received: (qmail 25230 invoked from network); 16 Dec 2009 15:46:15 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 16 Dec 2009 15:46:15 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id 1415F508A2; Wed, 16 Dec 2009 10:46:14 -0500 (EST) From: Lowell Gilbert To: stable@freebsd.org References: <20091216124140.GA5954@bsdbox.koderize.com> Date: Wed, 16 Dec 2009 10:46:13 -0500 In-Reply-To: <20091216124140.GA5954@bsdbox.koderize.com> (Jamie Griffin's message of "Wed, 16 Dec 2009 12:41:40 +0000") Message-ID: <44hbrqgbwa.fsf@be-well.ilk.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: freebsd-questions mailing list X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 15:46:16 -0000 Jamie Griffin writes: > Has anyone else noticed a problem with this list, I haven't received a > message from the freebsd-questions list for over 24 hours :0/ I asked the postmaster, and got a reply that the reply isn't really well understood yet. I don't know mailman that well, or I'd've volunteered to help out. From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 16:04:36 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46BD11065693 for ; Wed, 16 Dec 2009 16:04:36 +0000 (UTC) (envelope-from arnaud.houdelette@tzim.net) Received: from golanth.tzim.net (unknown [IPv6:2001:41d0:1:d91f:21c:c0ff:fe4b:cf32]) by mx1.freebsd.org (Postfix) with ESMTP id DBDBA8FC12 for ; Wed, 16 Dec 2009 16:04:35 +0000 (UTC) Received: from 12rf.tzim.net ([82.232.60.244] helo=[192.168.0.14]) by golanth.tzim.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NKwMc-000Fnr-Pd for freebsd-stable@freebsd.org; Wed, 16 Dec 2009 17:04:34 +0100 Message-ID: <4B290515.5080909@tzim.net> Date: Wed, 16 Dec 2009 17:04:37 +0100 From: Arnaud Houdelette User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: tzim@tzim.net X-Authenticator: plain Subject: Possible ZFS livelock or SCHED_ULE bug ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 16:04:36 -0000 Hi all ! I got a UniProcessor AMD64 box, with 512 MB ram with 2 ZFS pools as a home-NAS. I got some IO issues since I moved from 7.2 to 8.0. With a GENERIC kernel (or a stripped down one), during high IO activity (as a make buildword can cause), I encounter random hangs or deadlocks. top show system CPU usage at 99%, the most CPU using process being [zfskern] ( {txg_thread_enter} if I switch to thread view). The box still respond to ping. Current processes can still run, but I can't run new ones. Sometimes, I can return to normal by Ctrl-C-ing the buildworld (or other operation), sometimes I can't, I got to reboot the box. The Issue seemed to become less frequent with 8.0-stable instead of 8.0-RELEASE, but still present (I get approximately 75% chance of hang with a buildworld). I got the hang with Prefetch enabled or disabled. Idem for ZIL. I tried to enable kernel dumps, but the box hangs saving the dump (root is on ZFS) or when starting kdbg on it. I recompiled kernel with SCHED_4BSD, and it seems I can't reproduce the hang. What do you think ? Did I misconfigured something ? cat /boot/loader.conf zfs_load="YES" vfs.root.mountfrom="zfs:unsafe/root" vm.kmem_size="512M" vm.kmem_size_max="512M" vfs.zfs.arc_max="100M" vfs.zfs.vdev.cache.size="10M" vfs.zfs.prefetch_disable="0" vfs.zfs.zil_disable="1" [carenath] ~> zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad6p1 ONLINE 0 0 0 ad10p1 ONLINE 0 0 0 ad8p1 ONLINE 0 0 0 ad4p1 ONLINE 0 0 0 errors: No known data errors pool: unsafe state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM unsafe ONLINE 0 0 0 ad0p3 ONLINE 0 0 0 errors: No known data errors From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 16:23:23 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 098281065670 for ; Wed, 16 Dec 2009 16:23:23 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from smtp02.cdmon.com (smtp02.cdmon.com [212.36.74.55]) by mx1.freebsd.org (Postfix) with ESMTP id BE91C8FC0A for ; Wed, 16 Dec 2009 16:23:22 +0000 (UTC) Received: from jespasac.cdmon.com (62.Red-217-126-43.staticIP.rima-tde.net [217.126.43.62]) (Authenticated sender: jespasac@noverificar) by smtp02.cdmon.com (Postfix) with ESMTP id AEA2A4685C for ; Wed, 16 Dec 2009 17:23:20 +0100 (CET) Message-ID: <4B29090E.8060507@minibofh.org> Date: Wed, 16 Dec 2009 17:21:34 +0100 From: Jordi Espasa Clofent User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B28C842.3030704@minibofh.org> <448wd39j4o.fsf@lowell-desk.lan> In-Reply-To: <448wd39j4o.fsf@lowell-desk.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: Error upgrading 7.0 to 7.2 (buildword in gnu/usr.bin/binutils/libopcodes setp) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 16:23:23 -0000 Lowell Gilbert escribió: > Does it always happen in the same place (if not, it's a hardware > problem)? Hi Lowel, Yes, always at same point. > Does it happen the same way without the '-j' option (that can make the > output less useful)? Wonderful. I've used times the same command (1) without -j flag and... it works perfectly! It's curious, because of I always use the -j flag in buildworld with successs. It has been the first time that I've experienced this problem.... (1) chflags -R noschg /usr/obj/usr && cd /usr/src && make cleandir && make cleandir && make -j10 buildworld Thanks for all. ;) -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 16:32:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 406AA10656AE for ; Wed, 16 Dec 2009 16:32:27 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by mx1.freebsd.org (Postfix) with ESMTP id 18BDA8FC27 for ; Wed, 16 Dec 2009 16:32:26 +0000 (UTC) Received: (qmail 18714 invoked from network); 16 Dec 2009 16:32:26 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 16 Dec 2009 16:32:26 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id 2E18E508A2; Wed, 16 Dec 2009 11:32:25 -0500 (EST) From: Lowell Gilbert To: Jordi Espasa Clofent References: <4B28C842.3030704@minibofh.org> <448wd39j4o.fsf@lowell-desk.lan> <4B29090E.8060507@minibofh.org> Date: Wed, 16 Dec 2009 11:32:23 -0500 In-Reply-To: <4B29090E.8060507@minibofh.org> (Jordi Espasa Clofent's message of "Wed, 16 Dec 2009 17:21:34 +0100") Message-ID: <44d42eg9rc.fsf@be-well.ilk.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Error upgrading 7.0 to 7.2 (buildword in gnu/usr.bin/binutils/libopcodes setp) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 16:32:27 -0000 Jordi Espasa Clofent writes: > Lowell Gilbert escribi=F3: > >> Does it always happen in the same place (if not, it's a hardware >> problem)? > > Hi Lowel, > > Yes, always at same point. Good. Based on the information you gave, I was expecting a hardware problem. >> Does it happen the same way without the '-j' option (that can make the >> output less useful)? > > Wonderful. I've used times the same command (1) without -j flag > and... it works perfectly! > It's curious, because of I always use the -j flag in buildworld with > successs. It has been the first time that I've experienced this > problem.... buildworld is supposed to work with -j, but I've never used a value that large. Unless you have 8 or more CPU cores available, I would expect builds to be faster if you reduced that value. > (1) chflags -R noschg /usr/obj/usr && cd /usr/src && make cleandir && > make cleandir && make -j10 buildworld I don't think chflags should be needed any more. The cleandir isn't supposed to be necessary either; I only do that when I have a problem.=20 Glad to hear you're making progress. From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 16:41:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 869FF106566C for ; Wed, 16 Dec 2009 16:41:07 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id 2CE768FC0A for ; Wed, 16 Dec 2009 16:41:06 +0000 (UTC) Received: from xykon.in.wanderview.com (xykon.in.wanderview.com [10.76.10.152]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id nBGGf5Ea087023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Dec 2009 16:41:05 GMT (envelope-from ben@wanderview.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ben Kelly In-Reply-To: <4B290515.5080909@tzim.net> Date: Wed, 16 Dec 2009 11:41:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B290515.5080909@tzim.net> To: Arnaud Houdelette X-Mailer: Apple Mail (2.1077) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.67 on 10.76.20.1 Cc: freebsd-stable@freebsd.org Subject: Re: Possible ZFS livelock or SCHED_ULE bug ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 16:41:07 -0000 On Dec 16, 2009, at 11:04 AM, Arnaud Houdelette wrote: > Hi all ! > I got a UniProcessor AMD64 box, with 512 MB ram with 2 ZFS pools as a = home-NAS. >=20 > I got some IO issues since I moved from 7.2 to 8.0. > With a GENERIC kernel (or a stripped down one), during high IO = activity (as a make buildword can cause), I encounter random hangs or = deadlocks. > top show system CPU usage at 99%, the most CPU using process being = [zfskern] ( {txg_thread_enter} if I switch to thread view). > The box still respond to ping. Current processes can still run, but I = can't run new ones. > Sometimes, I can return to normal by Ctrl-C-ing the buildworld (or = other operation), sometimes I can't, I got to reboot the box. >=20 > The Issue seemed to become less frequent with 8.0-stable instead of = 8.0-RELEASE, but still present (I get approximately 75% chance of hang = with a buildworld). > I got the hang with Prefetch enabled or disabled. Idem for ZIL. >=20 > I tried to enable kernel dumps, but the box hangs saving the dump = (root is on ZFS) or when starting kdbg on it. > I recompiled kernel with SCHED_4BSD, and it seems I can't reproduce = the hang. >=20 > What do you think ? > Did I misconfigured something ? This sounds similar to something I ran into on CURRENT last year: = http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D832196+0+archive/2009/freeb= sd-current/20090322.freebsd-current The immediate problem was a priority inversion problem between the = txg_thread_enter threads and the spa_zio threads. This should be solved = (or at least mitigated) on 8.0 now that these threads have explicit = priorities set. Can you check to see what priorities these threads are = at on your machine? They should have priorities something like -8 for = txg_thread_enter and -16 for spa_zio. - Ben From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 17:09:48 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E84E1065679 for ; Wed, 16 Dec 2009 17:09:48 +0000 (UTC) (envelope-from arnaud.houdelette@tzim.net) Received: from golanth.tzim.net (unknown [IPv6:2001:41d0:1:d91f:21c:c0ff:fe4b:cf32]) by mx1.freebsd.org (Postfix) with ESMTP id 3CEA08FC13 for ; Wed, 16 Dec 2009 17:09:48 +0000 (UTC) Received: from 12rf.tzim.net ([82.232.60.244] helo=[192.168.0.14]) by golanth.tzim.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NKxNi-000GDv-PK; Wed, 16 Dec 2009 18:09:47 +0100 Message-ID: <4B29145A.4080601@tzim.net> Date: Wed, 16 Dec 2009 18:09:46 +0100 From: Arnaud Houdelette User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ben Kelly References: <4B290515.5080909@tzim.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: tzim@tzim.net X-Authenticator: plain Cc: freebsd-stable@freebsd.org Subject: Re: Possible ZFS livelock or SCHED_ULE bug ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 17:09:48 -0000 Ben Kelly wrote: > On Dec 16, 2009, at 11:04 AM, Arnaud Houdelette wrote: > > >> Hi all ! >> I got a UniProcessor AMD64 box, with 512 MB ram with 2 ZFS pools as a home-NAS. >> >> I got some IO issues since I moved from 7.2 to 8.0. >> With a GENERIC kernel (or a stripped down one), during high IO activity (as a make buildword can cause), I encounter random hangs or deadlocks. >> top show system CPU usage at 99%, the most CPU using process being [zfskern] ( {txg_thread_enter} if I switch to thread view). >> The box still respond to ping. Current processes can still run, but I can't run new ones. >> Sometimes, I can return to normal by Ctrl-C-ing the buildworld (or other operation), sometimes I can't, I got to reboot the box. >> >> The Issue seemed to become less frequent with 8.0-stable instead of 8.0-RELEASE, but still present (I get approximately 75% chance of hang with a buildworld). >> I got the hang with Prefetch enabled or disabled. Idem for ZIL. >> >> I tried to enable kernel dumps, but the box hangs saving the dump (root is on ZFS) or when starting kdbg on it. >> I recompiled kernel with SCHED_4BSD, and it seems I can't reproduce the hang. >> >> What do you think ? >> Did I misconfigured something ? >> > > This sounds similar to something I ran into on CURRENT last year: > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=832196+0+archive/2009/freebsd-current/20090322.freebsd-current > > The immediate problem was a priority inversion problem between the txg_thread_enter threads and the spa_zio threads. This should be solved (or at least mitigated) on 8.0 now that these threads have explicit priorities set. Can you check to see what priorities these threads are at on your machine? They should have priorities something like -8 for txg_thread_enter and -16 for spa_zio. > > - Ben > As far as I can tell, this is the priorities that I see on my machine. I'm doing another test. This once with ULE but without options SMP set. I'm currently building world, and so far, I did not encountered any hang. (and the system seems more responsive that with 4BSD). I'll keep testing and report... Arnaud From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 17:17:54 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3BB8106568F for ; Wed, 16 Dec 2009 17:17:53 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [78.111.72.186]) by mx1.freebsd.org (Postfix) with SMTP id 4DEF38FC16 for ; Wed, 16 Dec 2009 17:17:52 +0000 (UTC) Received: (qmail 53933 invoked by uid 89); 16 Dec 2009 17:17:51 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (78.111.72.187) by avocado.salatschuessel.net with SMTP; 16 Dec 2009 17:17:51 -0000 Date: Wed, 16 Dec 2009 18:17:49 +0100 From: Oliver Lehmann To: Alexander Motin Message-Id: <20091216181749.2eb27426.lehmann@ans-netz.de> In-Reply-To: <4B27E64F.2080804@FreeBSD.org> References: <20091215182300.929c7a9c.lehmann@ans-netz.de> <4B27E64F.2080804@FreeBSD.org> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: problems with SATA controller after recent RELENG_8 upgrade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 17:17:54 -0000 Hi Alexander, Alexander Motin wrote: > --- ata-promise.c.prev 2009-12-15 21:35:43.000000000 +0200 > +++ ata-promise.c 2009-12-15 21:35:24.000000000 +0200 > @@ -957,6 +957,7 @@ ata_promise_mio_dmainit(device_t dev) > ata_dmainit(dev); > /* note start and stop are not used here */ > ch->dma.setprd = ata_promise_mio_setprd; > + ch->dma.max_iosize = 65536; > } I applied the patch and then the error went away and the system boots up successfully. To be sure it was no other (build related) problem I removed the line again, did a make kernel again and then I got the same error as before. So - this line definitly makes my system work again. If you want to add a comment (so none else removes it in the future again ;)) - my exactl model is "Promise SATA300 TX2+" atapci1@pci0:0:17:0: class=0x018000 card=0x3d73105a chip=0x3d73105a rev=0x02 hdr=0x00 vendor = 'Promise Technology Inc' device = 'SATAII 300 TX2+ (PDC40775)' class = mass storage -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 17:18:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A93E106595F for ; Wed, 16 Dec 2009 17:18:15 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout025.mac.com (asmtpout025.mac.com [17.148.16.100]) by mx1.freebsd.org (Postfix) with ESMTP id EB7128FC15 for ; Wed, 16 Dec 2009 17:18:14 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp025.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KUR00JKS9EDVG60@asmtp025.mac.com> for freebsd-stable@freebsd.org; Wed, 16 Dec 2009 09:18:14 -0800 (PST) From: Marcel Moolenaar In-reply-to: <21859b54848003a15761f546aed36f1f@localhost> Date: Wed, 16 Dec 2009 09:18:13 -0800 Message-id: <411FD26C-82CD-4FBA-A5C2-866D1C76CE42@mac.com> References: <4B28BCAA.1010002@icyb.net.ua> <21859b54848003a15761f546aed36f1f@localhost> To: Marian Hettwer X-Mailer: Apple Mail (2.1077) Cc: freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: update to 8.0-RELEASE --> partition gone X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 17:18:15 -0000 On Dec 16, 2009, at 3:27 AM, Marian Hettwer wrote: >> > gee, thanks! > That worked. > root@talisker:/root# ls /dev/ad8* > /dev/ad8 /dev/ad8s1 /dev/ad8s1a > root@talisker:/root# mount /dev/ad8s1a /BACKUP/ > root@talisker:/root# umount /BACKUP/ > > but, hm, whats that? > root@talisker:/root# fsck /dev/ad8s1a > fsck: Could not determine filesystem type I minor inconvenience for the time being. fsck hasn't been thought about getting partition types from gpart, so that it can do a best-effort attempt at guessing which variant to run. For now, you need to be explicit: fsck -t ufs /dev/ad0s1a Alternatively, add an entry to /etc/fstab. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 17:29:22 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3AD31065695 for ; Wed, 16 Dec 2009 17:29:22 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by mx1.freebsd.org (Postfix) with ESMTP id AF5E28FC19 for ; Wed, 16 Dec 2009 17:29:22 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp029.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KUR00KKC9WC8C80@asmtp029.mac.com> for freebsd-stable@freebsd.org; Wed, 16 Dec 2009 09:29:00 -0800 (PST) From: Marcel Moolenaar In-reply-to: <20091216.113300.74685382.sthaug@nethelp.no> Date: Wed, 16 Dec 2009 09:29:00 -0800 Message-id: <55FA4159-2AEE-4E2A-BAE9-E9699C6C7537@mac.com> References: <200912151720.37709.freebsd@insightbb.com> <20091216000803.GA39686@osiris.mauzo.dyndns.org> <7BA0C6CC-A1D9-49C2-942D-D46C19E9B3CB@mac.com> <20091216.113300.74685382.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.1077) Cc: freebsd-stable@freebsd.org Subject: Re: update to 8.0-RELEASE --> partition gone X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 17:29:22 -0000 On Dec 16, 2009, at 2:33 AM, sthaug@nethelp.no wrote: >> If you installed "dangerously dedicated" and ended up >> with ad0s1a (note the "s1"), then you have an invalid >> partitioning and FreeBSD 8.x will not give you what >> you've been getting on FreeBSD 7.x. Most of the time >> you only need to wipe out the second sector on the >> disk to clean it up and have FreeBSD 8.x also give >> you ad0s1a. > > So what's an easy recipe we can run on 7.x hosts to see whether we > would have problems with 8.x? If 1. fdisk ${D} shows FreeBSD slices, and 2. your mount points are within these slices (i.e your device name has a prefix of ${D}s1, ${D}s2, ${D}s3, etc *OR* they have a prefix of ${D}cs1 ${D}cs2 ${D}cs3, etc), and 3. bsdlabel ${D} shows that there's a (possibly empty) BSD disklabel then you have an invalidly created danerously dedicated disk. You can wipe out the second sector on the disk to clear the bogus BSD disklabel. The most important thing to look at is how you currently mount. If fdisk ${D} and bsdlabel ${D} show valid information and you mount from ${D}a, ${D}d, etc -- then your disk is not necessarily invalid in the same sense that having a PMBR with slices in front of a GPT is not considered invalid. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 17:40:04 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6F441065670 for ; Wed, 16 Dec 2009 17:40:04 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 7A43A8FC1A for ; Wed, 16 Dec 2009 17:40:04 +0000 (UTC) Received: by ewy26 with SMTP id 26so290043ewy.3 for ; Wed, 16 Dec 2009 09:40:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=TZnn3aMGM0SsXhAMxxsbFiB9OQNOrQV5KjS3sIi51E8=; b=B2TVxfGRjvolRjdDCjrTPQxbOY6pdPYKQSExdfAh8n+wSOa3tppqu68znfgd+FwsSn j+1IsDH0xOQ0DjH1UPFKg0QjsjbJlXSfnWAy2ggsdNSZS4IYG9IF7+AE9HTPuxOqmD5d NE4RqNNNvcgqm+6kqRB4GKxtSh20OlYPHgO6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=NTQ/FZCwDqS+9CVUoQFIM509QK/aIeSyxnjDIyCKwKzWK+ZteHu/OEFVs37y8Y1fcm smc9Gn02hPAIWnAasHYyfYebsULmmIqreoCavyRirtN1uPf6hBUy8EH1aMxHrB6Ak2iS DOUOeIGRgYFJ81JFLsX0CZ4lm5Ly8NsEydcyk= MIME-Version: 1.0 Received: by 10.213.40.206 with SMTP id l14mr1475796ebe.60.1260985202878; Wed, 16 Dec 2009 09:40:02 -0800 (PST) In-Reply-To: <44d42eg9rc.fsf@be-well.ilk.org> References: <4B28C842.3030704@minibofh.org> <448wd39j4o.fsf@lowell-desk.lan> <4B29090E.8060507@minibofh.org> <44d42eg9rc.fsf@be-well.ilk.org> Date: Wed, 16 Dec 2009 17:40:02 +0000 Message-ID: <2e027be00912160940g27e31caco757da6ed8f919c19@mail.gmail.com> From: Tom Evans To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Error upgrading 7.0 to 7.2 (buildword in gnu/usr.bin/binutils/libopcodes setp) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 17:40:05 -0000 On Wed, Dec 16, 2009 at 4:32 PM, Lowell Gilbert wrote: > Jordi Espasa Clofent writes: >> Lowell Gilbert escribi=C3=B3: >> Wonderful. I've used times the same command (1) without -j flag >> and... it works perfectly! >> It's curious, because of I always use the -j flag in buildworld with >> successs. It has been the first time that I've experienced this >> problem.... > > buildworld is supposed to work with -j, but I've never used a value that > large. =C2=A0Unless you have 8 or more CPU cores available, I would expec= t > builds to be faster if you reduced that value. > Running more concurrent processes will use more CPU and more memory (you'd hope, anyways). This could lead it to use bits of hardware with -j 8 that it wouldn't use without it, potentially exposing hardware flaws. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 18:36:55 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DF71106566B for ; Wed, 16 Dec 2009 18:36:55 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (tunnel490.ipv6.xs4all.nl [IPv6:2001:888:10:1ea::2]) by mx1.freebsd.org (Postfix) with ESMTP id F415C8FC14 for ; Wed, 16 Dec 2009 18:36:54 +0000 (UTC) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.14.2/8.14.2) with ESMTP id nBGIamff089740; Wed, 16 Dec 2009 19:36:49 +0100 (CET) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.14.2/8.14.2/Submit) id nBGIamYD089739; Wed, 16 Dec 2009 19:36:48 +0100 (CET) (envelope-from mail25@bzerk.org) Date: Wed, 16 Dec 2009 19:36:48 +0100 From: Ruben de Groot To: Lowell Gilbert Message-ID: <20091216183648.GA89682@ei.bzerk.org> Mail-Followup-To: Ruben de Groot , Lowell Gilbert , stable@freebsd.org References: <20091216124140.GA5954@bsdbox.koderize.com> <44hbrqgbwa.fsf@be-well.ilk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44hbrqgbwa.fsf@be-well.ilk.org> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (ei.bzerk.org [127.0.0.1]); Wed, 16 Dec 2009 19:36:52 +0100 (CET) Cc: stable@freebsd.org Subject: Re: freebsd-questions mailing list X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 18:36:55 -0000 On Wed, Dec 16, 2009 at 10:46:13AM -0500, Lowell Gilbert typed: > Jamie Griffin writes: > > > Has anyone else noticed a problem with this list, I haven't received a > > message from the freebsd-questions list for over 24 hours :0/ > > I asked the postmaster, and got a reply that the reply isn't really well > understood yet. I don't know mailman that well, or I'd've volunteered > to help out. Mailman's not rocket science. And the list is offline now for 3 days! I volunteer! From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 18:45:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 003CA1065672 for ; Wed, 16 Dec 2009 18:45:07 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (takeda-1-pt.tunnel.tserv15.lax1.ipv6.he.net [IPv6:2001:470:c:16b::2]) by mx1.freebsd.org (Postfix) with ESMTP id BF24D8FC17 for ; Wed, 16 Dec 2009 18:45:07 +0000 (UTC) Received: from takeda-ws.lan (takeda-ws.lan [10.0.0.3]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.3/8.14.3) with ESMTP id nBGIj43w092580 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 10:45:05 -0800 (PST) (envelope-from takeda@takeda.tk) Date: Wed, 16 Dec 2009 10:39:25 -0800 From: Derek Kulinski X-Mailer: The Bat! (v3.99.3) Professional X-Priority: 3 (Normal) Message-ID: <1952441862.20091216103925@takeda.tk> To: Boris Kochergin In-Reply-To: <4B28D281.80706@acm.poly.edu> References: <110163611.20091216031952@takeda.tk> <4B28D281.80706@acm.poly.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Problems with Atheros card and hostpd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 18:45:08 -0000 Hello Boris, I checked the handbook, UPDATING, and nothing mentioned this thing, why? I would think I'm not the only one with this problem, or am I? Anyway it seems to work, I'm getting: Starting hostapd. Configuration file: /etc/hostapd.conf wlan0: IEEE 802.11 Fetching hardware channel/rate support not supported. Using interface wlan0 with hwaddr 00:11:95:e5:70:df and ssid 'mayumi-ap' Is it something I should worry about? Also how to create wlan device by hand? "ifconfig ath0 wlandev wlan0" doesn't seem to work. What initially was worrying me was this: >> ath0: mem 0xf4000000-0xf400ffff irq 3 at device 11.0 on pci0 >> ath0: [ITHREAD] >> ath0: AR2413 mac 7.9 RF2413 phy 4.5 I thought that ath0 was using a different driver than it supposed to. There's one more question, though not related to this problem. I have an android phone, and it doesn't seem to work with my FreeBSD AP, while it works on others. After sniffing the traffic, it looks like it is a power management issue: https://supportforums.motorola.com/message/87903#87903 Someone traced the problem to WME/WMM in his case. I don't know if that's the case for me yet, I tried to disable/enable wme on the AP but it doesn't seem to do anything. Is it possible that I might fix it by enabling some option? Anyway, thanks for everyone who helped me fix the initial issue. Derek Wednesday, December 16, 2009, 4:28:49 AM, you wrote: > Multi-BSS support in 8.0 means that you first need to create a wlan > pseudo-device, and run hostapd with that. The rc.conf lines look like this: > wlans_ath0="wlan0" > create_args_wlan0="wlanmode hostap" > ifconfig_wlan0="ssid networkname media autoselect up" > -Boris > Derek Kulinski wrote: >> Hello, >> >> I just upgraded my access point (from 7.1 to 8.0) and can't make >> hostapd work (looks like wide-dhcp relay also has a problem with ath0): >> >> [mayumi]:/root# hostapd -P /var/run/hostapd.pid -dd /etc/hostapd.conf >> Configuration file: /etc/hostapd.conf >> Line 2: DEPRECATED: 'debug' configuration variable is not used anymore >> ctrl_interface_group=0 (from group name 'wheel') >> pcap_open_live: >> ifname='ath0' >> bsd driver initialization failed. >> ath0: Unable to setup interface. >> rmdir[ctrl_interface]: No such file or directory >> Exit 255 >> >> Output from dmesg: >> ath0: mem 0xf4000000-0xf400ffff irq 3 at device 11.0 on pci0 >> ath0: [ITHREAD] >> ath0: AR2413 mac 7.9 RF2413 phy 4.5 >> >> The interface seems to exist, but seems it lost some of its >> functionality: >> [mayumi]:/root# ifconfig ath0 >> ath0: flags=8843 metric 0 mtu 2290 >> ether 00:11:95:e5:70:df >> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) >> status: no carrier >> [mayumi]:/root# ifconfig ath0 list cap >> ifconfig: Don't know how to list cap for ath0 >> >> What's going on? The card worked pretty well with 7.1. >> >> I tried to compile kernel just with "device ath_ar5212" >> but I'm only getting this: >> >> ah.o(.text+0x212): In function `ath_hal_rfprobe': >> /usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__start_set_ah_rfs' >> ah.o(.text+0x21f):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__stop_set_ah_rfs' >> ah.o(.text+0x235):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__stop_set_ah_rfs' >> >> -- Best regards, Derek mailto:takeda@takeda.tk -- I can see clearly now, the brain is gone... From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 18:58:10 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80C4E106566C for ; Wed, 16 Dec 2009 18:58:10 +0000 (UTC) (envelope-from freebsd@insightbb.com) Received: from mxsf00.insightbb.com (mxsf00.insightbb.com [74.128.0.70]) by mx1.freebsd.org (Postfix) with ESMTP id 486338FC08 for ; Wed, 16 Dec 2009 18:58:10 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.47,407,1257138000"; d="scan'208";a="725412013" Received: from unknown (HELO mxsf10.insightbb.com) ([172.31.249.60]) by mxsf00.insightbb.com with ESMTP; 16 Dec 2009 13:58:09 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMEAEu8KEvQLicL/2dsb2JhbACBS9UghCsEgWM X-IronPort-AV: E=Sophos;i="4.47,407,1257138000"; d="scan'208";a="11396608" Received: from unknown (HELO asav01.insightbb.com) ([172.31.249.123]) by mxsf10.insightbb.com with ESMTP; 16 Dec 2009 13:58:09 -0500 X-IronPort-AV: E=Sophos;i="4.47,407,1257138000"; d="scan'208";a="238431745" Received: from 208-46-39-11.dia.static.qwest.net (HELO laptop2.stevenfriedrich.org) ([208.46.39.11]) by asavout01.insightbb.com with ESMTP; 16 Dec 2009 13:58:07 -0500 From: Steven Friedrich To: freebsd-stable@freebsd.org Date: Wed, 16 Dec 2009 13:58:05 -0500 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; i386; ; ) References: <110163611.20091216031952@takeda.tk> <4B28D281.80706@acm.poly.edu> <1952441862.20091216103925@takeda.tk> In-Reply-To: <1952441862.20091216103925@takeda.tk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912161358.05277.freebsd@insightbb.com> Cc: Derek Kulinski , Boris Kochergin Subject: Re: Problems with Atheros card and hostpd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 18:58:10 -0000 On Wednesday 16 December 2009 01:39:25 pm Derek Kulinski wrote: > Also how to create wlan device by hand? "ifconfig ath0 wlandev wlan0" > doesn't seem to work. You have it backwards. It should be: ifconfig wlan0 create wlandev ath0 From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 20:00:12 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5A6A1065670 for ; Wed, 16 Dec 2009 20:00:12 +0000 (UTC) (envelope-from asossi@dotcom.ts.it) Received: from mail.dotcom.ts.it (89-96-242-204.ip14.fastwebnet.it [89.96.242.204]) by mx1.freebsd.org (Postfix) with SMTP id B432C8FC18 for ; Wed, 16 Dec 2009 20:00:11 +0000 (UTC) Received: (qmail 36847 invoked by uid 89); 16 Dec 2009 19:33:30 -0000 Received: by simscan 1.4.0 ppid: 36824, pid: 36845, t: 0.0139s scanners: clamav: 0.95.3/m:51/d:10128 Received: from unknown (HELO ?192.168.0.2?) (asossi@dotcom.ts.it@192.168.254.3) by mail.dotcom.ts.it with SMTP; 16 Dec 2009 19:33:30 -0000 Message-ID: <4B293627.7050000@dotcom.ts.it> Date: Wed, 16 Dec 2009 20:33:59 +0100 From: Sossi Andrej Organization: DotCom Information technology User-Agent: Mozilla/5.0 (X11; U; Linux i686; sl-SL; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz> References: <4B281279.6060706@quip.cz> <4B28F557.6000305@quip.cz> In-Reply-To: <4B28F557.6000305@quip.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, freebsd-stable Stable Subject: Re: iSCSI initiator and Dell PowerVault MD3000i X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 20:00:12 -0000 On 16. 12. 2009 15:57, Miroslav Lachman wrote: > Daniel Braniss wrote: >>> Hi all, >>> I am playing with iscsi_initiator on FreeBSD 7-STABLE and Dell >>> PowerVault MD3000i. This is the first time I am testing iSCSI... >>> >>> [...] >>> >>> If I setup RAID 5 'Disk Group' consisted of 4x 1TB SATA drives (in >>> MD3000i) and then created for example 2 'Virtual Disks', both are >>> detected by iscontrol and added to /dev/ as da0 and da1, but da1 spams >>> log with messages like this: > > [...] I use MD300i with FreeBSD 7.0 and 7.1 with iscsi-2.2.2. It work fine. But be careful to configure MD3000i. MD3000i assign by default first disk to preferred controller 0, second disk to preferred controller 1, third disk to preferred controller 0, and so on. First, third, fifth... disks is usable from FreeBSD, but second, fourth,... disks result unusable. Work around: manually assign all disks to controller 0. I'm talking with Dell's technical support, but Dell not support FreeBSD! In any case, technical support tell me, the problem (maybe) is the multipath. FreeBSD use only one path (only one IP) to communicate to MD3000i. Second net interface in unused. I hope that I have been helpful. By -- Sossi Andrej ------------------------- DotCom Information technology Via Trento, 16 34132 - Trieste (TS) Italy tel: +39 040 2158191 fax: +39 040 0641954 E-mail: asossi@dotcom.ts.it ---------------------------- Ai sensi del D.lgs n. 196 del 30.06.03 (Codice Privacy) si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie This message, for the D.lgs n. 196 / 30.06.03 (Privacy Code), may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 20:18:19 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D9D7106566C for ; Wed, 16 Dec 2009 20:18:19 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 109CF8FC18 for ; Wed, 16 Dec 2009 20:18:18 +0000 (UTC) Received: by bwz5 with SMTP id 5so1056893bwz.3 for ; Wed, 16 Dec 2009 12:18:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=zM9fTv2uj1TMfyjUwe/wmFsp/2VvoIfC6hkANG7qGR8=; b=uGvs2YWy3fBjPFrNHeoj6YC4Gp6icMRnWiSbC0gHxx5vYWY/hjZrlHCGXOTirBMmfj Q8degVjn/t7RiBaAHvdvtUqSQdrSt9B3MNFAI25ZY8yfQtub3OVARqveGn1BQV4cwqSJ mWUCIIGN4lGIo2fGuKHdrjU6dItVNkWixsZL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=xtaacrnpbT4J3OOEBK0uNb0kECugamxu8jMCI3cDFSEGjl76hnjH1+2VrkEscKxUfe +nh65+FjdsuakJTodQbdwsZUT/gW4tixLlXy+rMXnCfse16miHcZesNVhD5Bv7rMEYrL QISMKn4A2t/qGb56I1j3UhHDlzinvS29iMBTI= MIME-Version: 1.0 Received: by 10.204.155.92 with SMTP id r28mr800571bkw.121.1260994697766; Wed, 16 Dec 2009 12:18:17 -0800 (PST) In-Reply-To: <20091216105546.GG14175@lonesome.com> References: <20091216102850.GA99834@slackbox.xs4all.nl> <20091216105546.GG14175@lonesome.com> Date: Wed, 16 Dec 2009 15:18:17 -0500 Message-ID: From: grarpamp To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Using RELENG_8 to compile for older RELENG_x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 20:18:19 -0000 This would simply involve downloading some canonical tarball, say bind, and compiling it... perhaps even statically. Ports and it's issues related to this would certainly not be considered. I'd thought about the jails, emulation, installing 4.11 on spare boxes [a] and whatnot. Seemed there might be a more elegant way to cross compile and do everything on the RELENG_8 box natively. Maybe by pointing the toolchain at a copy of /lib /include from RELENG_4 or whatever. Then expand that method to back compile for RELENG_x. I think I'll try unpacking 4.11's release tarballs into an empty jail, doing whatever else the install does and launching that. I'm guessing I should be able to compile/install world/kernel/release/apps in there. Assuming the running RELENG_8 parent kernel services don't cause issues. If it doesn't work I can always fall back to [a]. Yeah, you could consider it 'embedded' all right. Like deep in a dusty corner, driving some critical legacy shims that they forgot about in the migration plan, oops. As a side note, it would be nice if freebsd-archive containted packages-x-stable too, copied over as part of the rm process from the regular ftp.freebsd.org when it happens. And all the distfiles ever used too, I don't think they're currently rm'ed though. From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 20:22:25 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 805DC1065672; Wed, 16 Dec 2009 20:22:25 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from chen.org.nz (ip-58-28-152-174.static-xdsl.xnet.co.nz [58.28.152.174]) by mx1.freebsd.org (Postfix) with ESMTP id 27B228FC16; Wed, 16 Dec 2009 20:22:24 +0000 (UTC) Received: by chen.org.nz (Postfix, from userid 1000) id BAF692840A; Thu, 17 Dec 2009 09:22:21 +1300 (NZDT) Date: Thu, 17 Dec 2009 09:22:21 +1300 From: Jonathan Chen To: John Baldwin Message-ID: <20091216202221.GA32938@osiris.chen.org.nz> References: <20091213191905.GA76785@osiris.chen.org.nz> <200912151018.36607.jhb@freebsd.org> <20091215194703.GA10572@osiris.chen.org.nz> <200912151551.30550.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200912151551.30550.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Dell D830, nVidia and FreeBSD-8/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 20:22:25 -0000 On Tue, Dec 15, 2009 at 03:51:30PM -0500, John Baldwin wrote: > On Tuesday 15 December 2009 2:47:03 pm Jonathan Chen wrote: [...] > > I/O memory addresses: > > 0xdff00000-0xe06fffff (acpi0) > > 0xe0700000-0xe0700fff (cbb0) > > 0xe0701000-0xf3ffffff (root0) > > The root0 range is ok (it really means free), but the cbb0 and acpi0 ranges > here conflict with the prefetch BAR for the video adapter. The cbb0 one I > think is because that range is free when cbb0 needs to allocate a fresh range > of resources. The real bug is why your BIOS thinks that a system resource is > using 0xe0000000-0xe06fffff which conflicts with the nvidia card. You can > try disabling ACPI's system-resource handling (set > debug.acpi.disabled="sysres" from the loader). The debug.acpi.disabled setting allows me to load up the driver and displays a usable X screen on the internal monitor - however, my xorg.conf was configured to use the *external* monitor. When X quits on the internal monitor, the console display reverts back to the external monitor with a "scratchy" display. I've also just updated the BIOS in the hope that it would resolve the conflict, but that didn't appear to do anything. I've also noticed that cbb0 complains about "Bad Vcc requested" on boot and shutdown. Thanks for looking into this, btw. -- Jonathan Chen ---------------------------------------------------------------------- "Beer. Now there's a temporary solution." - Homer Simpson From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 20:36:45 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAFD6106568B for ; Wed, 16 Dec 2009 20:36:45 +0000 (UTC) (envelope-from jbozza@mindsites.com) Received: from mail.thinkburst.com (mail.thinkburst.com [204.49.104.46]) by mx1.freebsd.org (Postfix) with ESMTP id 860D38FC08 for ; Wed, 16 Dec 2009 20:36:45 +0000 (UTC) Received: from mailgate.mindsites.net (gateway.mindsites.net [204.49.104.36]) by mail.thinkburst.com (Postfix) with ESMTP id 9BC751CC27; Wed, 16 Dec 2009 14:36:44 -0600 (CST) Received: from remote.mindsites.com (unknown [10.1.1.5]) by mailgate.mindsites.net (Postfix) with ESMTP id 7F20017062; Wed, 16 Dec 2009 14:36:44 -0600 (CST) Received: from ATLAS.msg.local ([fe80::48f5:88b0:6093:4f67]) by ATLAS.msg.local ([fe80::48f5:88b0:6093:4f67%10]) with mapi; Wed, 16 Dec 2009 14:36:44 -0600 From: Jaime Bozza To: Jacob Myers Date: Wed, 16 Dec 2009 14:36:43 -0600 Thread-Topic: Possible scheduler (SCHED_ULE) bug? Thread-Index: AcpdWwXx6b071GXPT8egWGy+yZPFQwhNEuZQ Message-ID: References: <4AE2232E.10406@whotookspaz.org> <4AE59FBE.6060904@tzim.net> <4AF18F3A.50804@whotookspaz.org> In-Reply-To: <4AF18F3A.50804@whotookspaz.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-stable@freebsd.org" , Arnaud Houdelette Subject: RE: Possible scheduler (SCHED_ULE) bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 20:36:45 -0000 > From: Jacob Myers [mailto:jacob@whotookspaz.org] > Jaime Bozza wrote: > > From: Arnaud Houdelette [mailto:arnaud.houdelette@tzim.net] > >> I haven't tried larger files - Maybe the boundary is different on amd6= 4? Doing some quick tests > >> right now, I was able to upload a 100MB file without a problem, but th= is is an AMD64 system with > SMP, > >> plus the filesystem is all ZFS, so there are too many things different= . I'll have to setup a > system > >> that closely mirrors the rest of my tests (UFS, ULE, no SMP, etc) befo= re I can say I'm not having a > >> problem there. > >>> Jaime > >>> > >> I had the same issue using 7.1 amd64, with ZFS, no SMP. > >> Not really sure what is the size boundary. I can't really test either, > >> as the machine is remote. > >> But I confirm that each tentative upload of certain relatively 'big' > >> files (around 1MB) with wordpress hanged the system before I switched > >> from sendfile to writev. > >> > >> I might do some test on amd64 7.2 with no SMP if it can be of any use = ? > >> > >> Arnaud > > > > I was able to duplicate the problem on 7.2-STABLE amd64 no SMP - Proble= m didn't seem to happen with > SMP on. While I wasn't able to get a crash dump, the crash looked simila= r. > > > > Jaime > > >=20 > FWIW, there was a fix committed for this: > http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D198853 > See if it helps. Sorry for the delay in testing this - Everything seems to be working fine n= ow. I'm not able to force a lockup anymore under the same conditions. T= hanks for the fix! Jaime From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 20:37:44 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BA3C1065693 for ; Wed, 16 Dec 2009 20:37:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5F2A28FC1F for ; Wed, 16 Dec 2009 20:37:44 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1517446B37; Wed, 16 Dec 2009 15:37:44 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 383328A020; Wed, 16 Dec 2009 15:37:43 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 16 Dec 2009 08:32:53 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) References: <2ec071a80912151801r532ed93fx84db26ba9acf9615@mail.gmail.com> In-Reply-To: <2ec071a80912151801r532ed93fx84db26ba9acf9615@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200912160832.53121.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 16 Dec 2009 15:37:43 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.0 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_06_12,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Alexander Petrovsky Subject: Re: Problem with kern.icp.shmseg X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 20:37:44 -0000 On Tuesday 15 December 2009 9:01:57 pm Alexander Petrovsky wrote: > Hello! > I have problem with kern.icp.shmseg, when a change value from 128 to 256, > 512.... in /boot/loader.conf. When system loading the value kern.icp.shmseg > doesn't change. > > # cat /boot/loader.conf > # Number of shared memory identifiers > kern.ipc.shmmni=2048 > # Number of segments per process #2048 > kern.icp.shmseg=256 s/icp/ipc/. :) -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 20:37:47 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21206106568F; Wed, 16 Dec 2009 20:37:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D38EA8FC15; Wed, 16 Dec 2009 20:37:46 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 6DF6A46B2E; Wed, 16 Dec 2009 15:37:46 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 972E18A01D; Wed, 16 Dec 2009 15:37:45 -0500 (EST) From: John Baldwin To: Robert Noland Date: Wed, 16 Dec 2009 10:06:57 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) References: <20091213191905.GA76785@osiris.chen.org.nz> <200912151551.30550.jhb@freebsd.org> <1260971276.26065.14.camel@balrog.2hip.net> In-Reply-To: <1260971276.26065.14.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200912161006.57856.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 16 Dec 2009 15:37:45 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: Dell D830, nVidia and FreeBSD-8/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 20:37:47 -0000 On Wednesday 16 December 2009 8:47:56 am Robert Noland wrote: > On Tue, 2009-12-15 at 15:51 -0500, John Baldwin wrote: > > On Tuesday 15 December 2009 2:47:03 pm Jonathan Chen wrote: > > > On Tue, Dec 15, 2009 at 10:18:36AM -0500, John Baldwin wrote: > > > > On Monday 14 December 2009 9:37:51 pm Jonathan Chen wrote: > > > > > On Mon, Dec 14, 2009 at 10:46:27AM -0500, John Baldwin wrote: > > > > > > On Sunday 13 December 2009 2:19:05 pm Jonathan Chen wrote: > > > > > > > Hi, > > > > > > > > > > > > > > This is a general rehash of a problem that I've been having with my > > > > > > > Dell Latitude D830 with an nVidia Quadro NVS 140M internal graphics > > > > > > > card. I've been using the XOrg's "vesa" driver ever since something in > > > > the > > > > > > > code rendered the "nvidia" driver inoperable in 7-STABLE sometime mid > > > > > > > last year. With nVidia's new 195.22 (BETA) drivers, I had hoped that I > > > > > > > could bypass the problem. Unfortunately, I seem to be experiencing the > > > > same > > > > > > > problem as described in the following thread: > > > > > > > > > > > > > > http://www.nvnews.net/vbulletin/showthread.php?t=142391 > > > > > > > > > > > > > > which appears to be implying that something in the kernel is > > > > > > > interfering with memory allocation. Would it be possible for someone > > > > > > > with deeper kernel-fu be able to take a look at this issue? > > > > > > > > > > > > Do you have a verbose dmesg available? > > > > > > > > > > I've attached a dmesg with a verbose boot. I hope this is what you're > > > > > looking for. > > > > > > > > Ok, can you grab the output of 'devinfo -r' and 'devinfo -ur'? I suspect that > > > > when the bridge allocates the prefetch resource range from the parent it is > > > > failing somehow. For a quick hack try something like this: > > > [...] > > > > > > I've attatched the requested output. Unfortunately, the patch didn't > > > result in anything different. > > > > > > I/O memory addresses: > > > 0xdff00000-0xe06fffff (acpi0) > > > 0xe0700000-0xe0700fff (cbb0) > > > 0xe0701000-0xf3ffffff (root0) > > > > The root0 range is ok (it really means free), but the cbb0 and acpi0 ranges > > here conflict with the prefetch BAR for the video adapter. The cbb0 one I > > think is because that range is free when cbb0 needs to allocate a fresh range > > of resources. The real bug is why your BIOS thinks that a system resource is > > using 0xe0000000-0xe06fffff which conflicts with the nvidia card. You can > > try disabling ACPI's system-resource handling (set > > debug.acpi.disabled="sysres" from the loader). > > I'm not sure what is the root issue, but we have seen system resource > conflicts like this reasonably often with Nvidia graphics. I've never > some across this issue with any other display adapter. But I've had at > least a handful of reports of noveau not working due to this issue. This is not specific to Nvidia adapters. These are just incompetent BIOS writers. We should probably trust any BARs set by the BIOS over what is listed in the ACPI system resources. This it not super easy to fix now, but I can see how to handle that as part of the multipass device resource stuff. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 23:09:28 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FEBC106566C for ; Wed, 16 Dec 2009 23:09:28 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id CFF338FC0A for ; Wed, 16 Dec 2009 23:09:27 +0000 (UTC) Received: by fxm27 with SMTP id 27so1468884fxm.3 for ; Wed, 16 Dec 2009 15:09:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=fVbmdsPZzyQ7y39CWOcM6YV6ENGJQiF42C2o9w89lDE=; b=v5YAVhP7jbQBzvkobi9AHmb3NcfLEGlGSYF8Kx67ssYDD7HLwL2Dp4jW99uI8axGot nBqtQ3H7SFx7IZW3kXfeftrakwzb0jJUPvnuRETyuMIiPmft3/w/Cjg4qdi+9YjC3M85 zp2H6frQv4saYLA1wqW6nHt38WecWUDEsRrqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BC4vDNJhXTwScfJxveFF9nlc9NQnBdDn/Zh3PO2fCqVZaXitz0m13sTx4dk968Z+Iu iZHt861V36qBkRg5k7qEjkiWpRdesHRksngbV36PCfc4b0xWhH9o6UoPkTg706vvQ/dw HdQqqs2l0HZKbt7OpVYUrUfkrgbHajG0f3tSY= MIME-Version: 1.0 Received: by 10.102.197.8 with SMTP id u8mr830666muf.37.1261004966751; Wed, 16 Dec 2009 15:09:26 -0800 (PST) In-Reply-To: <6101e8c40912061417r4f4dd301lcd254a379e4bbe44@mail.gmail.com> References: <20091206104419.GA95949@home.opsec.eu> <4B1B8F35.4020506@tzim.net> <6101e8c40912061417r4f4dd301lcd254a379e4bbe44@mail.gmail.com> Date: Wed, 16 Dec 2009 23:09:26 +0000 Message-ID: <6101e8c40912161509o6b83925eg1bd26be0e42aa0b8@mail.gmail.com> From: Oliver Pinter To: Arnaud Houdelette Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, Kurt Jaeger Subject: Re: freebsd update for 8.0-REL-p1 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 23:09:28 -0000 hmm, the answer is: freebsd-update binarys availalble only for i386 and amd64, for sparc not... On 12/6/09, Oliver Pinter wrote: > [root@argos /home/op]# uname -a > FreeBSD argos 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 22:40:34 > UTC 2009 root@araz.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > sparc64 > [root@argos /home/op]# freebsd-update fetch > Looking up update.FreeBSD.org mirrors... 3 mirrors found. > Fetching public key from update5.FreeBSD.org... failed. > Fetching public key from update4.FreeBSD.org... failed. > Fetching public key from update2.FreeBSD.org... failed. > No mirrors remaining, giving up. > > when manualy fetch pub.ssl and place its dir, then become this error > message: > > Fetching metadata signature for 8.0-RELEASE-p1 from > update4.FreeBSD.org... failed. > Fetching metadata signature for 8.0-RELEASE-p1 from > update5.FreeBSD.org... failed. > Fetching metadata signature for 8.0-RELEASE-p1 from > update2.FreeBSD.org... failed. > > > On 12/6/09, Arnaud Houdelette wrote: >> Kurt Jaeger wrote: >>> Hi! >>> >>> Now that the rtld patch is available, how do I upgrade using >>> freebsd-update ? >>> >>> freebsd-update -r 8.0-RELEASE-p1 upgrade >>> >>> says: >>> >>> [...] >>> Fetching metadata signature for 8.0-RELEASE-p1 from >>> update4.FreeBSD.org... >>> failed. >>> Fetching metadata signature for 8.0-RELEASE-p1 from >>> update5.FreeBSD.org... >>> failed. >>> Fetching metadata signature for 8.0-RELEASE-p1 from >>> update2.FreeBSD.org... >>> failed. >>> No mirrors remaining, giving up. >>> >>> So it does not upgrade 8-( >>> >> Hi. >> Just do : >> freebsd-update fetch >> then : >> freebsd-update install >> >> Arnaud >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 23:12:49 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1FEB106566B for ; Wed, 16 Dec 2009 23:12:49 +0000 (UTC) (envelope-from ben@morrow.me.uk) Received: from relay.pcl-ipout02.plus.net (relay.pcl-ipout02.plus.net [212.159.7.100]) by mx1.freebsd.org (Postfix) with ESMTP id 8FD438FC13 for ; Wed, 16 Dec 2009 23:12:49 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAA/4KEvUOFPl/2dsb2JhbACBS9NthCsE Received: from plesk-mail01.plus.net ([212.56.83.229]) by relay.pcl-ipout02.plus.net with ESMTP; 16 Dec 2009 23:12:48 +0000 Received: (qmail 25809 invoked from network); 16 Dec 2009 23:12:48 +0000 Received: from host86-146-192-188.range86-146.btcentralplus.com (HELO osiris.mauzo.dyndns.org) (86.146.192.188) by plesk-mail01.plus.net with SMTP; 16 Dec 2009 23:12:47 +0000 Received: (qmail 50360 invoked by uid 1001); 16 Dec 2009 23:12:47 -0000 Date: Wed, 16 Dec 2009 23:12:47 +0000 From: Ben Morrow To: xcllnt@mac.com, freebsd-stable@freebsd.org Message-ID: <20091216231247.GA50353@osiris.mauzo.dyndns.org> Mail-Followup-To: xcllnt@mac.com, freebsd-stable@freebsd.org References: <4B28BCAA.1010002@icyb.net.ua> <21859b54848003a15761f546aed36f1f@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <411FD26C-82CD-4FBA-A5C2-866D1C76CE42@mac.com> X-Newsgroups: gmane.os.freebsd.stable Organization: Who, me? User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: update to 8.0-RELEASE --> partition gone X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 23:12:50 -0000 Quoth Marcel Moolenaar : > > On Dec 16, 2009, at 3:27 AM, Marian Hettwer wrote: > >> > > gee, thanks! > > That worked. > > root@talisker:/root# ls /dev/ad8* > > /dev/ad8 /dev/ad8s1 /dev/ad8s1a > > root@talisker:/root# mount /dev/ad8s1a /BACKUP/ > > root@talisker:/root# umount /BACKUP/ > > > > but, hm, whats that? > > root@talisker:/root# fsck /dev/ad8s1a > > fsck: Could not determine filesystem type > > I minor inconvenience for the time being. fsck hasn't > been thought about getting partition types from gpart, > so that it can do a best-effort attempt at guessing > which variant to run. For now, you need to be explicit: I for one would rather *not* see fsck extended in this way. The whole point of fsck is that you're running it on a potentially-broken disk; guessing is not helpful at that point :). Ben From owner-freebsd-stable@FreeBSD.ORG Wed Dec 16 23:16:51 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F004106566B for ; Wed, 16 Dec 2009 23:16:51 +0000 (UTC) (envelope-from ben@morrow.me.uk) Received: from relay.pcl-ipout02.plus.net (relay.pcl-ipout02.plus.net [212.159.7.100]) by mx1.freebsd.org (Postfix) with ESMTP id 3C6158FC1A for ; Wed, 16 Dec 2009 23:16:50 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAHf5KEvUOFPl/2dsb2JhbACBS9NthCsE Received: from plesk-mail01.plus.net ([212.56.83.229]) by relay.pcl-ipout02.plus.net with ESMTP; 16 Dec 2009 23:16:50 +0000 Received: (qmail 27006 invoked from network); 16 Dec 2009 23:16:49 +0000 Received: from host86-146-192-188.range86-146.btcentralplus.com (HELO osiris.mauzo.dyndns.org) (86.146.192.188) by plesk-mail01.plus.net with SMTP; 16 Dec 2009 23:16:49 +0000 Received: (qmail 50387 invoked by uid 1001); 16 Dec 2009 23:16:49 -0000 Date: Wed, 16 Dec 2009 23:16:49 +0000 From: Ben Morrow To: sthaug@nethelp.no, freebsd-stable@freebsd.org Message-ID: <20091216231649.GA50373@osiris.mauzo.dyndns.org> Mail-Followup-To: sthaug@nethelp.no, freebsd-stable@freebsd.org References: <7BA0C6CC-A1D9-49C2-942D-D46C19E9B3CB@mac.com> <20091216.113300.74685382.sthaug@nethelp.no> <20091216121326.GA46703@osiris.mauzo.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091216.142528.74661073.sthaug@nethelp.no> X-Newsgroups: gmane.os.freebsd.stable Organization: Who, me? User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: update to 8.0-RELEASE --> partition gone X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 23:16:51 -0000 Quoth sthaug@nethelp.no: > > > > > > So what's an easy recipe we can run on 7.x hosts to see whether we > > > would have problems with 8.x? > > > > >>From what's been said so far: If you have adXsY devices in 7, *and* > > > > bsdlabel adX > > > > finds a valid label (*note*: that is the whole disk, not the slice), > > then you have conflicting BSD and MBR labels at the start of the disk > > and you will have a problem in 8. > > So presumably if I have root on ad4s1a today, and bsdlabel shows > > # bsdlabel ad4 > bsdlabel: /dev/ad4: no valid label found > > then I am ready for FreeBSD 8.x? I think so (but I'm no expert). This setup isn't in any way 'dangerously dedicated', though, so there's no reason to think it wouldn't work. My question was whether mounting from ad2d (with no MBR on ad2 at all) would work; apparently it will, as long as there isn't an invalid BSD disklabel in sector 2 of the first track. Ben From owner-freebsd-stable@FreeBSD.ORG Thu Dec 17 00:51:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E87BC106566C for ; Thu, 17 Dec 2009 00:51:56 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by mx1.freebsd.org (Postfix) with ESMTP id 633288FC16 for ; Thu, 17 Dec 2009 00:51:56 +0000 (UTC) Received: from slackbox.xs4all.nl (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id nBH0psmN006673; Thu, 17 Dec 2009 01:51:54 +0100 (CET) (envelope-from rsmith@xs4all.nl) Received: by slackbox.xs4all.nl (Postfix, from userid 1001) id AAB7CBAAA; Thu, 17 Dec 2009 01:51:54 +0100 (CET) Date: Thu, 17 Dec 2009 01:51:54 +0100 From: Roland Smith To: grarpamp Message-ID: <20091217005154.GB71135@slackbox.xs4all.nl> References: <20091216102850.GA99834@slackbox.xs4all.nl> <20091216105546.GG14175@lonesome.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i0/AhcQY5QxfSsSZ" Content-Disposition: inline In-Reply-To: X-GPG-Fingerprint: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 X-GPG-Key: http://www.xs4all.nl/~rsmith/pubkey.txt X-GPG-Notice: If this message is not signed, don't assume I sent it! User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-stable@freebsd.org Subject: Re: Using RELENG_8 to compile for older RELENG_x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 00:51:57 -0000 --i0/AhcQY5QxfSsSZ Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 16, 2009 at 03:18:17PM -0500, grarpamp wrote: > I think I'll try unpacking 4.11's release tarballs into an empty > jail, doing whatever else the install does and launching that. I'm > guessing I should be able to compile/install world/kernel/release/apps > in there. Assuming the running RELENG_8 parent kernel services don't > cause issues. If it doesn't work I can always fall back to [a]. If I understand correctly, you want to use the jail to run a 4.11 userland = on an 8.x kernel? If you are not running GENERIC on the host, remember to incl= ude the COMPAT_FREEBSD4..COMPAT_FREEBSD7 options in your kernel. You'll need th= at to run 4.x binaries. Running older binaries is possible. But on the other hand running a userland that is not in sync with the kernel not supported a= nd known to be able to cause trouble. See e.g. =A724.7 of the Handbook. It will be an interesting experiment at least. :-) I'd probably try installing 4.11 on a old spare machine first. > Yeah, you could consider it 'embedded' all right. Like deep in a > dusty corner, driving some critical legacy shims that they forgot > about in the migration plan, oops. Oops indeed. Old+'dusty corner'+'critical' is not a good combination in my experience. If the scenario also contains the element 'no backups', its time to run for the hills. :-/ Roland --=20 R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) --i0/AhcQY5QxfSsSZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkspgKoACgkQEnfvsMMhpyWgcgCcCyvJQ3vhd67EYiSEAZLQ1sRk CucAni5XRuWIYXF4JkoCzdkLvewGfeUd =t+DH -----END PGP SIGNATURE----- --i0/AhcQY5QxfSsSZ-- From owner-freebsd-stable@FreeBSD.ORG Thu Dec 17 01:09:26 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7D411065670 for ; Thu, 17 Dec 2009 01:09:26 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 51BF98FC08 for ; Thu, 17 Dec 2009 01:09:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id nBH19OgK093356 for ; Thu, 17 Dec 2009 04:09:24 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Thu, 17 Dec 2009 04:09:24 +0300 (MSK) From: Dmitry Morozovsky To: freebsd-stable@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (woozle.rinet.ru [0.0.0.0]); Thu, 17 Dec 2009 04:09:24 +0300 (MSK) Cc: Subject: RELENG_7: gdm after portupgrade does not allow logins X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 01:09:26 -0000 Dear colleagues, after portupgrade'ing on last gnome update I have very strange situation: gdm does not show neither login list not username text field; after pressing space, some unlabelled text field opens (symbols are echoed, so I suppose it's like login name field); however, entering anything there does not lead anywhere. portupgrade -f gdm does not help; portupgrade -f ${direct gdm dependencies} does not help, either. And, of course, I even rebooted the machine without a bit of success. Any hints? Thanks in advance! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Thu Dec 17 01:19:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF501106568B for ; Thu, 17 Dec 2009 01:19:15 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 8D0938FC19 for ; Thu, 17 Dec 2009 01:19:15 +0000 (UTC) Received: (qmail 42162 invoked from network); 17 Dec 2009 01:19:13 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@69.123.45.64) by acm.poly.edu with AES256-SHA encrypted SMTP; 17 Dec 2009 01:19:13 -0000 Message-ID: <4B298701.6030502@acm.poly.edu> Date: Wed, 16 Dec 2009 20:18:57 -0500 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.23 (X11/20090910) MIME-Version: 1.0 To: Derek Kulinski References: <110163611.20091216031952@takeda.tk> <4B28D281.80706@acm.poly.edu> <1952441862.20091216103925@takeda.tk> In-Reply-To: <1952441862.20091216103925@takeda.tk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Problems with Atheros card and hostpd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 01:19:16 -0000 Derek Kulinski wrote: > Hello Boris, > > I checked the handbook, UPDATING, and nothing mentioned this thing, > why? I would think I'm not the only one with this problem, or am I? > Well, I learned about it because I follow the -current@ and -net@ mailing lists, but there is at least some mention of it in /usr/src/UPDATING: 20080420: The 802.11 wireless support was redone to enable multi-bss operation on devices that are capable. The underlying device is no longer used directly but instead wlanX devices are cloned with ifconfig. This requires changes to rc.conf files. For example, change: ifconfig_ath0="WPA DHCP" to wlans_ath0=wlan0 ifconfig_wlan0="WPA DHCP" see rc.conf(5) for more details. In addition, mergemaster of /etc/rc.d is highly recommended. Simultaneous update of userland and kernel wouldn't hurt either. As part of the multi-bss changes the wlan_scan_ap and wlan_scan_sta modules were merged into the base wlan module. All references to these modules (e.g. in kernel config files) must be removed. > Anyway it seems to work, I'm getting: > Starting hostapd. > Configuration file: /etc/hostapd.conf > wlan0: IEEE 802.11 Fetching hardware channel/rate support not supported. > Using interface wlan0 with hwaddr 00:11:95:e5:70:df and ssid 'mayumi-ap' > > Is it something I should worry about? > I don't think so. The same thing happens on my access points. It looks like the channel and rate remain properties of the underlying device, which makes sense, since all wlan pseudo-devices use the same channel and rate. > Also how to create wlan device by hand? "ifconfig ath0 wlandev wlan0" > doesn't seem to work. > > What initially was worrying me was this: > >>> ath0: mem 0xf4000000-0xf400ffff irq 3 at device 11.0 on pci0 >>> ath0: [ITHREAD] >>> ath0: AR2413 mac 7.9 RF2413 phy 4.5 >>> > > I thought that ath0 was using a different driver than it supposed to. > > There's one more question, though not related to this problem. > I have an android phone, and it doesn't seem to work with my FreeBSD > AP, while it works on others. After sniffing the traffic, it looks > like it is a power management issue: > https://supportforums.motorola.com/message/87903#87903 > > Someone traced the problem to WME/WMM in his case. I don't know if > that's the case for me yet, I tried to disable/enable wme on the AP > but it doesn't seem to do anything. Is it possible that I might fix it > by enabling some option? > Don't know anything about this, I'm afraid. > Anyway, thanks for everyone who helped me fix the initial issue. > > Derek > > > Wednesday, December 16, 2009, 4:28:49 AM, you wrote: > > >> Multi-BSS support in 8.0 means that you first need to create a wlan >> pseudo-device, and run hostapd with that. The rc.conf lines look like this: >> > > >> wlans_ath0="wlan0" >> create_args_wlan0="wlanmode hostap" >> ifconfig_wlan0="ssid networkname media autoselect up" >> > > >> -Boris >> > > >> Derek Kulinski wrote: >> >>> Hello, >>> >>> I just upgraded my access point (from 7.1 to 8.0) and can't make >>> hostapd work (looks like wide-dhcp relay also has a problem with ath0): >>> >>> [mayumi]:/root# hostapd -P /var/run/hostapd.pid -dd /etc/hostapd.conf >>> Configuration file: /etc/hostapd.conf >>> Line 2: DEPRECATED: 'debug' configuration variable is not used anymore >>> ctrl_interface_group=0 (from group name 'wheel') >>> pcap_open_live: >>> ifname='ath0' >>> bsd driver initialization failed. >>> ath0: Unable to setup interface. >>> rmdir[ctrl_interface]: No such file or directory >>> Exit 255 >>> >>> Output from dmesg: >>> ath0: mem 0xf4000000-0xf400ffff irq 3 at device 11.0 on pci0 >>> ath0: [ITHREAD] >>> ath0: AR2413 mac 7.9 RF2413 phy 4.5 >>> >>> The interface seems to exist, but seems it lost some of its >>> functionality: >>> [mayumi]:/root# ifconfig ath0 >>> ath0: flags=8843 metric 0 mtu 2290 >>> ether 00:11:95:e5:70:df >>> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) >>> status: no carrier >>> [mayumi]:/root# ifconfig ath0 list cap >>> ifconfig: Don't know how to list cap for ath0 >>> >>> What's going on? The card worked pretty well with 7.1. >>> >>> I tried to compile kernel just with "device ath_ar5212" >>> but I'm only getting this: >>> >>> ah.o(.text+0x212): In function `ath_hal_rfprobe': >>> /usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__start_set_ah_rfs' >>> ah.o(.text+0x21f):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__stop_set_ah_rfs' >>> ah.o(.text+0x235):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__stop_set_ah_rfs' >>> >>> >>> > > > > From owner-freebsd-stable@FreeBSD.ORG Thu Dec 17 03:27:06 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94DFB1065670 for ; Thu, 17 Dec 2009 03:27:06 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (takeda-1-pt.tunnel.tserv15.lax1.ipv6.he.net [IPv6:2001:470:c:16b::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6EC288FC1F for ; Thu, 17 Dec 2009 03:27:06 +0000 (UTC) Received: from takeda-ws.lan (takeda-ws.lan [10.0.0.3]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.3/8.14.3) with ESMTP id nBH3R3V7000299 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 19:27:03 -0800 (PST) (envelope-from takeda@takeda.tk) Date: Wed, 16 Dec 2009 19:16:12 -0800 From: Derek Kulinski X-Mailer: The Bat! (v3.99.3) Professional X-Priority: 3 (Normal) Message-ID: <1503995551.20091216191612@takeda.tk> To: Boris Kochergin In-Reply-To: <4B298701.6030502@acm.poly.edu> References: <110163611.20091216031952@takeda.tk> <4B28D281.80706@acm.poly.edu> <1952441862.20091216103925@takeda.tk> <4B298701.6030502@acm.poly.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Problems with Atheros card and hostpd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 03:27:06 -0000 Hello Boris, Wednesday, December 16, 2009, 5:18:57 PM, you wrote: > 20080420: > The 802.11 wireless support was redone to enable multi-bss > operation on devices that are capable. The underlying device > is no longer used directly but instead wlanX devices are > cloned with ifconfig. This requires changes to rc.conf files. > For example, change: > ifconfig_ath0="WPA DHCP" > to > wlans_ath0=wlan0 > ifconfig_wlan0="WPA DHCP" > see rc.conf(5) for more details. In addition, mergemaster of > /etc/rc.d is highly recommended. Simultaneous update of userland > and kernel wouldn't hurt either. > As part of the multi-bss changes the wlan_scan_ap and wlan_scan_sta > modules were merged into the base wlan module. All references > to these modules (e.g. in kernel config files) must be removed. Ok, now I'm quite embarrassed =) Anyway, thanks for your help. -- Best regards, Derek mailto:takeda@takeda.tk The great thing about Object Oriented code is that it can make small, simple problems look like large, complex ones. From owner-freebsd-stable@FreeBSD.ORG Thu Dec 17 08:04:09 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 095731065670; Thu, 17 Dec 2009 08:04:09 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 9F62F8FC17; Thu, 17 Dec 2009 08:04:07 +0000 (UTC) Received: from outgoing.leidinger.net (pD954FBD2.dip.t-dialin.net [217.84.251.210]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 1FD72884E; Thu, 17 Dec 2009 09:03:59 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 9A51711EC24; Thu, 17 Dec 2009 09:03:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1261037035; bh=6mjg9AXWbipvRGShCPYYImLgQ0M6UOhye7vF+wIwxUw=; h=Message-ID:Date:From:To:Cc:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=CQN5MyQP6fTas6dzX4GHyXM09P3/bxgtnfCmCLPkN1zy5DHYHew8HUc8cFzEy92YU 1CkBLIUqoEIlm0STjbO6hJitBp8A+k/ZoSWDcFvkwLVo894gSfcOXCREv14fmqoGxT X9rpXb2Urg6YCDImXeaLSw+DE8KCDEQhFnkN0EzhrBXNJEWKw4zXLGCpisUSX6cz/l cjx+XM/czbXVBWlsgLq7qCPhtpFBWDUWfSO5oitbA6vN+yuU26GC+esRUagEbR9Xrb +s+SxX/54QMSHNETjrKxK7r3yiasO0pUjQ9J9da2DhDKW6luzfa+4I4Ia9qsuIVNrc peycrxL5WP20w== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id nBH83sUY039599; Thu, 17 Dec 2009 09:03:55 +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 Framework) with HTTP; Thu, 17 Dec 2009 09:03:54 +0100 Message-ID: <20091217090354.98634ouizsftffk0@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 17 Dec 2009 09:03:54 +0100 From: Alexander Leidinger To: fs@freebsd.org, stable@freebsd.org 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.3.5) / FreeBSD-8.0 X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 1FD72884E.25875 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.686, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, J_CHICKENPOX_32 0.60, TW_SK 0.08, TW_ZF 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1261641841.04359@m+d8F2zJLCpQBCOxo5+bdw X-EBL-Spam-Status: No Cc: pjd@freebsd.org Subject: 57 ZFS patches not merged to RELENG_7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 08:04:09 -0000 Hi, I identified at least 57 patches which are in 8-stable, but not in 7-stable. Does someone know the status of those patches (listed below)? Maybe not all are applicable, but some of them should really get merged. I also have seen some things which I think are mismerges to 7-stable, but I do not have a list/diff of them at hand (I diffed 7-stable and 8-stable and those things where "in the noise" of the stuff which is not merged yet, one of the things I find directly now is two times the same line with kmem_cache_create of the zio_cache in cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c). If those people (ok, mostly pjd) which handle ZFS stuff normally do not have time to take care about this, are there people interested in helping me merge those things? Basically this means trying to apply the patches listed below on 7-stable, and testing them (or patches from other people, in case you are not able to merge a patch yourself) on a scratch box (I do not have a scratch-box with 7-stable around). It also means reviewing the patches regarding possible issues (I already identified some which need investigation, see below). Suggestions where those things should be coordinated in this case (on fs@ or stable@ or in the FreeBSD Wiki)? Below is the list of patches which I identified. I didn't had a look which one depends on which one, but there are for sure dependencies. The format is URL of the patch in head committer which committed it - my comment about the patch commit log Bye, Alexander. http://svn.freebsd.org/viewvc/base?view=revision&revision=185310 ganbold - very easy merge ---snip--- Remove unused variable. Found with: Coverity Prevent(tm) CID: 3669,3671 ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=185319 pjd - applicable to RELENG_7? ---snip--- Fix locking (file descriptor table and Giant around VFS). ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=192689 trasz - very easy merge ---snip--- Fix comment. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=193110 kmacy - easy merge ---snip--- work around snapshot shutdown race reported by Henri Hennebert ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=193128 kmacy - first probably, second and 3rd to check ---snip--- fix xdrmem_control to be safe in an if statement fix zfs to depend on krpc remove xdr from zfs makefile ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=193440 ps - shared vnode locks available in RELENG_7? vn_lock same syntax? ---snip--- Support shared vnode locks for write operations when the offset is provided on filesystems that support it. This really improves mysql + innodb performance on ZFS. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=194043 kmacy - sysctl API change? ---snip--- pjd has requested that I keep the tunable as zfs_prefetch_disable to minimize gratuitous differences with Opensolaris' ZFS ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=195627 marcel - easy merge ---snip--- In nvpair_native_embedded_array(), meaningless pointers are zeroed. The programmer was aware that alignment was not guaranteed in the packed structure and used bzero() to NULL out the pointers. However, on ia64, the compiler is quite agressive in finding ILP and calls to bzero() are often replaced by simple assignments (i.e. stores). Especially when the width or size in question corresponds with a store instruction (i.e. st1, st2, st4 or st8). The problem here is not a compiler bug. The address of the memory to zero-out was given by '&packed->nvl_priv' and given the type of the 'packed' pointer the compiler could assume proper alignment for the replacement of bzero() with an 8-byte wide store to be valid. The problem is with the programmer. The programmer knew that the address did not have the alignment guarantees needed for a regular assignment, but failed to inform the compiler of that fact. In fact, the programmer told the compiler the opposite: alignment is guaranteed. The fix is to avoid using a pointer of type "nvlist_t *" and instead use a "char *" pointer as the basis for calculating the address. This tells the compiler that only 1-byte alignment can be assumed and the compiler will either keep the bzero() call or instead replace it with a sequence of byte-wise stores. Both are valid. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=195785 trasz - extattr_check_cred same sytax in RELENG_7? Necessary? ---snip--- Fix permission handling for extended attributes in ZFS. Without this change, ZFS uses SunOS Alternate Data Streams semantics - each EA has its own permissions, which are set at EA creation time and - unlike SunOS - invisible to the user and impossible to change. From the user point of view, it's just broken: sometimes access is granted when it shouldn't be, sometimes it's denied when it shouldn't be. This patch makes it behave just like UFS, i.e. depend on current file permissions. Also, it fixes returned error codes (ENOATTR instead of ENOENT) and makes listextattr(2) return 0 instead of EPERM where there is no EA directory (i.e. the file never had any EA). ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=195822 trasz - easy merge ---snip--- Fix extattr_list_file(2) on ZFS in case the attribute directory doesn't exist and user doesn't have write access to the file. Without this fix, it returns bogus value instead of 0. For some reason this didn't manifest on my kernel compiled with -O0. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=195909 pjd - very easy merge ---snip--- We don't support ephemeral IDs in FreeBSD and without this fix ZFS can panic when in zfs_fuid_create_cred() when userid is negative. It is converted to unsigned value which makes IS_EPHEMERAL() macro to incorrectly report that this is ephemeral ID. The most reasonable solution for now is to always report that the given ID is not ephemeral. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196291 pjd - probably easy merge ---snip--- - Fix a race where /dev/zfs control device is created before ZFS is fully initialized. Also destroy /dev/zfs before doing other deinitializations. - Initialization through taskq is no longer needed and there is a race where one of the zpool/zfs command loads zfs.ko and tries to do some work immediately, but /dev/zfs is not there yet. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196269 marcel - easy merge ---snip--- Fix misalignment in nvpair_native_embedded() caused by the compiler replacing the bzero(). See also revision 195627, which fixed the misalignment in nvpair_native_embedded_array(). ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196295 pjd - the added stuff needs to be reviewed, taskqueue available & same syntax? ---snip--- Remove OpenSolaris taskq port (it performs very poorly in our kernel) and replace it with wrappers around our taskqueue(9). To make it possible implement taskqueue_member() function which returns 1 if the given thread was created by the given taskqueue. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196297 pjd - easy merge ---snip--- Fix panic in zfs recv code. The last vnode (mountpoint's vnode) can have 0 usecount. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196299 pjd - VI_UNLOCK same syntax in RELENG_7? ---snip--- - We need to recycle vnode instead of freeing znode. Submitted by: avg - Add missing vnode interlock unlock. - Remove redundant znode locking. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196301 pjd - probably easy merge ---snip--- If z_buf is NULL, we should free znode immediately. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196307 pjd - to be reviewed ---snip--- Manage asynchronous vnode release just like Solaris. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196309 pjd - vhold/VN_RELE/zfsctl_root_lookup/vop_vptocnp same syntax in RELENG_7? ---snip--- getcwd() (when __getcwd() fails) works by stating current directory, going up (..), calling readdir and looking for previous directory inode. In case of .zfs/ directory this doesn't work, because .zfs/ is hidden by default, so it won't be visible in readdir output. Fix this by implementing VPTOCNP for snapshot directories, so __getcwd() doesn't fail and getcwd() doesn't have to use readdir method. This fixes /bin/pwd from within .zfs/snapshot//. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196395 pjd - applicable to RELENG_7 (same XDR code?)? ---snip--- Our libc doesn't implement control method for XDR (only kernel does) and it will always return failure. Fix this by bringing userland implementation of xdrmem_control() back. This allow 'zpool import' to work again. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196456 pjd - kproc_create the same syntax on RELENG_7? ---snip--- - Give minclsyspri and maxclsyspri real values (consulted with kmacy). - Honour 'pri' argument for thread_create(). ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196457 pjd - easy merge, probably depends upon 196457 ---snip--- Set priority of vdev_geom threads and zvol threads to PRIBIO. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196458 pjd - kproc_kthread_add available in RELENG_7? same syntax? ---snip--- - Hide ZFS kernel threads under zfskern process. - Use better (shorter) threads names: 'zvol:worker zvol/tank/vol00' -> 'zvol tank/vol00' 'vdev:worker da0' -> 'vdev da0' ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196662 pjd - vn_lock/VOP_UNLOCK syntax the same in RELENG_7 (add curthread?)? ---snip--- Add missing mountpoint vnode locking. This fixes panic on assertion with DEBUG_VFS_LOCKS and vfs.usermount=1 when regular user tries to mount dataset owned by him. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196703 pjd - probably easy merge, KBI change (dnode)? ---snip--- Backport the 'dirtying dbuf' panic fix from newer ZFS version. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196919 pjd - very easy merge ---snip--- bzero() on-stack argument, so mutex_init() won't misinterpret that the lock is already initialized if we have some garbage on the stack. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196927 pjd - easy merge ---snip--- Changing provider size is not really supported by GEOM, but doing so when provider is closed should be ok. When administrator requests to change ZVOL size do it immediately if ZVOL is closed or do it on last ZVOL close. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196943 pjd - MNT_* same syntax in RELENG_7? ---snip--- - Avoid holding mutex around M_WAITOK allocations. - Add locking for mnt_opt field. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196944 pjd - easy merge ---snip--- Don't recheck ownership on update mount. This will eliminate LOR between vfs_busy() and mount mutex. We check ownership in vfs_domount() anyway. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196954 pjd - easy merge ---snip--- If we have to use avl_find(), optimize a bit and use avl_insert() instead of avl_add() (the latter is actually a wrapper around avl_find() + avl_insert()). Fix similar case in the code that is currently commented out. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196965 pjd - easy merge ---snip--- Fix reference count leak for a case where snapshot's mount point is updated. Such situation is not supported. This problem was triggered by something like this: # zpool create tank da0 # zfs snapshot tank@snap # cd /tank/.zfs/snapshot/snap (this will mount the snapshot) # cd # mount -u nosuid /tank/.zfs/snapshot/snap (refcount leak) # zpool export tank cannot export 'tank': pool is busy ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196980 pjd - VFS_ROOT/VN_RELE same syntax in RELENG_7? ---snip--- When we automatically mount snapshot we want to return vnode of the mount point from the lookup and not covered vnode. This is one of the fixes for using .zfs/ over NFS. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196982 pjd - vfs_checkexp/vfs_stdcheckexp same syntax in RELENG_7? ---snip--- We don't export individual snapshots, so mnt_export field in snapshot's mount point is NULL. That's why when we try to access snapshots over NFS use mnt_export field from the parent file system. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=196985 pjd - easy merge ---snip--- Only log successful commands! Without this fix we log even unsuccessful commands executed by unprivileged users. Action is not really taken, but it is logged to pool history, which might be confusing. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=197133 pjd - do we have rw-locks in RELENG_7? ---snip--- - Protect reclaim with z_teardown_inactive_lock. - Be prepared for dbuf to disappear in zfs_reclaim_complete() and check if z_dbuf field is NULL - this might happen in case of rollback or forced unmount between zfs_freebsd_reclaim() and zfs_reclaim_complete(). - On forced unmount wait for all znodes to be destroyed - destruction can be done asynchronously via zfs_reclaim_complete(). ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=197151 pjd - easy merge ---snip--- Be sure not to overflow struct fid. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=197152 pjd - easy merge ---snip--- Extend scope of the z_teardown_lock lock for consistency and "just in case". ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=197153 pjd - easy merge ---snip--- When zfs.ko is compiled with debug, make sure that znode and vnode point at each other. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=197167 pjd - easy merge ---snip--- Work-around READDIRPLUS problem with .zfs/ and .zfs/snapshot/ directories by just returning EOPNOTSUPP. This will allow NFS server to fall back to regular READDIR. Note that converting inode number to snapshot's vnode is expensive operation. Snapshots are stored in AVL tree, but based on their names, not inode numbers, so to convert inode to snapshot vnode we have to interate over all snalshots. This is not a problem in OpenSolaris, because in their READDIRPLUS implementation they use VOP_LOOKUP() on d_name, instead of VFS_VGET() on d_fileno as we do. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=197177 pjd - easy merge ---snip--- Support both case: when snapshot is already mounted and when it is not yet mounted. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=197201 pjd - VOP_UNLOCK/VI_LOCK/VI_UNLOCK same syntax in RELENG_7 (add curthread?)? ---snip--- - Mount ZFS snapshots with MNT_IGNORE flag, so they are not visible in regular df(1) and mount(8) output. This is a bit smilar to OpenSolaris and follows ZFS route of not listing snapshots by default with 'zfs list' command. - Add UPDATING entry to note that ZFS snapshots are no longer visible in mount(8) and df(1) output by default. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=197351 pjd - easy merge ---snip--- Purge namecache in the same place OpenSolaris does. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=197458 pjd - probably easy merge ---snip--- Close race in zfs_zget(). We have to increase usecount first and then check for VI_DOOMED flag. Before this change vnode could be reclaimed between checking for the flag and increasing usecount. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=197459 pjd - probably easy merge ---snip--- Before calling vflush(FORCECLOSE) mark file system as unmounted so the following vnops will fail. This is very important, because without this change vnode could be reclaimed at any point, even if we increased usecount. The only way to ensure that vnode won't be reclaimed was to lock it, which would be very hard to do in ZFS without changing a lot of code. With this change simply increasing usecount is enough to be sure vnode won't be reclaimed from under us. To be precise it can still be reclaimed but we won't be able to see it, because every try to enter ZFS through VFS will result in EIO. The only function that cannot return EIO, because it is needed for vflush() is zfs_root(). Introduce ZFS_ENTER_NOERROR() macro that only locks z_teardown_lock and never returns EIO. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=197497 pjd - easy merge, implications for existing pools/data? ---snip--- Switch to fletcher4 as the default checksum algorithm. Fletcher2 was proven to be a bit weak and OpenSolaris also switched to fletcher4. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=197512 pjd - VI_UNLOCK same syntax in RELENG_8? ---snip--- - Don't depend on value returned by gfs_*_inactive(), it doesn't work well with forced unmounts when GFS vnodes are referenced. - Make other preparations to GFS for forced unmounts. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=197513 pjd - traverse/VN_RELE same syntax in RELENG_7? ---snip--- Use traverse() function to find and return mount point's vnode instead of covered vnode when snapshot is already mounted. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=197515 pjd - probably easy merge ---snip--- Handle cases where virtual (GFS) vnodes are referenced when doing forced unmount. In that case we cannot depend on the proper order of invalidating vnodes, so we have to free resources when we have a chance. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=197683 delphij - easy merge ---snip--- Return EOPNOTSUPP instead of EINVAL when doing chflags(2) over an old format ZFS, as defined in the manual page. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=197831 pjd - does the added variable cause a KBI change? ---snip--- Fix situation where Mac OS X NFS client creates a file and when it tries to set ownership and mode in the same setattr operation, the mode was overwritten by secpolicy_vnode_setattr(). ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=197861 pjd - priv_check available / VOP_ACCESS same syntax in RELENG_7? ---snip--- Allow file system owner to modify system flags if securelevel permits. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=198703 pjd - vaccess same syntax on RELENG_7? ---snip--- - zfs_zaccess() can handle VAPPEND too, so map V_APPEND to VAPPEND and call zfs_access() instead of vaccess() in this case as well. - If VADMIN is specified with another V* flag (unlikely) call both zfs_access() and vaccess() after spliting V* flags. This fixes "dirtying snapshot!" panic. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=199156 pjd - probably easy merge (struct change, KBI implications?) ---snip--- Avoid passing invalid mountpoint to getnewvnode(). ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=199157 pjd - important, maybe security, probably easy merge ---snip--- Be careful which vattr fields are set during setattr replay. Without this fix strange things can appear after unclean shutdown like files with mode set to 07777. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=200124 pjd - very easy merge ---snip--- Avoid using additional variable for storing an error if we are not going to do anything with it. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=200126 pjd - easy merge, prevents ZFS pools on ZVOLs ---snip--- Fix deadlock when ZVOLs are present and we are replacing dead component or calling scrub when pool is in a degraded state. It will try to taste ZVOLs, which will lead to deadlock, as ZVOL will try to acquire the same locks as replace/scrub is holding already. We can't simply skip provider based on their GEOM class, because ZVOL can have providers build on top of it and we need to skip those as well. We do it by asking for ZFS::iszvol attribute. Any ZVOL-based provider will give us positive answer and we have to skip those providers. This way we remove possibility to create ZFS pools on top of ZVOLs, but it is not very useful anyway. I believe deadlock is still possible in some very complex situations like when we have MD provider on top of UFS file on top of ZVOL. When we try to replace dead component in the pool mentioned ZVOL is based on, there might be a deadlock when ZFS will try to taste MD provider. There is no easy way to detect that, but it isn't very common. ---snip--- http://svn.freebsd.org/viewvc/base?view=revision&revision=200158 pjd - easy merge ---snip--- We have to eventually look for provider without checking guid as this is need for attaching when there is no metadata yet. Before r200125 the order of looking for providers was wrong. It was: 1. Find provider by name. 2. Find provider by guid. 3. Find provider by name and guid. Where it should have been: 1. Find provider by name and guid. 2. Find provider by guid. 3. Find provider by name. ---snip--- -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Thu Dec 17 09:27:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66AE61065670 for ; Thu, 17 Dec 2009 09:27:09 +0000 (UTC) (envelope-from sean@gothic.net.au) Received: from visi.gothic.net.au (visi.gothic.net.au [115.64.131.102]) by mx1.freebsd.org (Postfix) with ESMTP id 13A098FC08 for ; Thu, 17 Dec 2009 09:27:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by visi.gothic.net.au (Postfix) with SMTP id 15BA48A70 for ; Thu, 17 Dec 2009 20:11:27 +1100 (EST) Received: from [10.168.1.191] (dhcp191.gothic.net.au [10.168.1.191]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sean) by visi.gothic.net.au (Postfix) with ESMTPSA id 8F7928A6E for ; Thu, 17 Dec 2009 20:11:27 +1100 (EST) Message-ID: <4B29F5B3.3070000@gothic.net.au> Date: Thu, 17 Dec 2009 20:11:15 +1100 From: Sean User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20091217090354.98634ouizsftffk0@webmail.leidinger.net> In-Reply-To: <20091217090354.98634ouizsftffk0@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 57 ZFS patches not merged to RELENG_7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 09:27:09 -0000 On 17/12/2009 7:03 PM, Alexander Leidinger wrote: > Hi, > > I identified at least 57 patches which are in 8-stable, but not in > 7-stable. > [snip lots of updates] one more... http://www.freebsd.org/cgi/query-pr.cgi?pr=139076 From owner-freebsd-stable@FreeBSD.ORG Thu Dec 17 11:23:06 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAEAF1065670; Thu, 17 Dec 2009 11:23:06 +0000 (UTC) (envelope-from prvs=1602d8d4d9=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 28FFD8FC0A; Thu, 17 Dec 2009 11:23:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1261048331; x=1261653131; q=dns/txt; h=Received: Message-ID:From:To:Subject:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; bh=+CLZAIp2e+Fxhf1rD1frFN4/32vYmcVbN4 QDXKJIiKQ=; b=hM9Y87KGoRJDiEk1Hwl6luLV+AbH6AQFE5mHQ/kb3r8Bt3zHRz lxx8u9eJAsKmRAQ6VZhJG8tlom2YrZTf6CEouJ9rlcKrfqBZtvTfkB9CNu1aD+7a dbtO+tkuJGLei/WoxBnk5AwXi+zIF+JDnMF8hBbqSR3LlZ8+3wzbID7pc= X-MDAV-Processed: mail1.multiplay.co.uk, Thu, 17 Dec 2009 11:12:11 +0000 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50008877441.msg; Thu, 17 Dec 2009 11:12:11 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 17 Dec 2009 11:12:11 +0000 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 213.123.247.160 X-Return-Path: prvs=1602d8d4d9=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: , Date: Thu, 17 Dec 2009 11:12:07 -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.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Subject: Passenger hangs on live and SEGV on tests possible threading / kernel bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 11:23:06 -0000 We're having an issue with Passenger on FreeBSD where it will hang and stop processing any more requests the details are attach to the following bug report: http://code.google.com/p/phusion-passenger/issues/detail?id=318#c14 In addition the test suite crashes in what seems to be a very basic test, which I'm at a loss with. http://code.google.com/p/phusion-passenger/issues/detail?id=441 I'm thinking this may be a bugs in the FreeBSD either kernel or thread library as the crashes don't make any sense from the application side. Any advise on debugging or feedback on the stack traces would be much appreciated. Regards 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-stable@FreeBSD.ORG Thu Dec 17 13:53:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 008EE1065676; Thu, 17 Dec 2009 13:53:56 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id AE7028FC23; Thu, 17 Dec 2009 13:53:55 +0000 (UTC) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id BA78B19E044; Thu, 17 Dec 2009 14:53:54 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 6AE3519E045; Thu, 17 Dec 2009 14:53:52 +0100 (CET) Message-ID: <4B2A37EF.10709@quip.cz> Date: Thu, 17 Dec 2009 14:53:51 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.6) Gecko/20091206 SeaMonkey/2.0.1 MIME-Version: 1.0 To: Ivan Voras References: 4B293627.7050000@dotcom.ts.it Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, asossi@dotcom.ts.it, FreeBSD Stable Subject: iSCSI initiator and Dell PowerVault MD3000i X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 13:53:56 -0000 please Cc: me, I am not subscribed to freebsd-scsi Sossi Andrej wrote: >> On 16. 12. 2009 15:57, Miroslav Lachman wrote: >> [...] >> I use MD300i with FreeBSD 7.0 and 7.1 with iscsi-2.2.2. It work fine. >> But be careful to configure MD3000i. MD3000i assign by default first >> disk to preferred controller 0, second disk to preferred controller 1, >> third disk to preferred controller 0, and so on. First, third, fifth... >> disks is usable from FreeBSD, but second, fourth,... disks result unusable. >> Work around: manually assign all disks to controller 0. > > When you say "unusable" do you mean you can't access it at all / it > errors even if it's the only path (drive) used? It would be normal if > you have for example two paths to each drive and can't mount the other > path if one path to the drive is mounted - this is not a usable > combination. You can use geom_multipath to get multipath failover. I got errors even in unmounted state. I tried iscsi-2.2.3 and got same errors. I tried second path first (device da0) and it produces same errors, then I run iscontrol for the first path (device da1) and everything is fine. ---- path throught second controller: ERROR ---- # diskinfo -t /dev/da0 /dev/da0 512 # sectorsize 2998998663168 # mediasize in bytes (2.7T) 5857419264 # mediasize in sectors 364607 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. Seek times: Full stroke: diskinfo: read error or disk too small for test.: Invalid argument ---- path throught first controller: OK ---- # diskinfo -t /dev/da1 /dev/da1 512 # sectorsize 2998998663168 # mediasize in bytes (2.7T) 5857419264 # mediasize in sectors 364607 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. Seek times: Full stroke: 250 iter in 2.483517 sec = 9.934 msec Half stroke: 250 iter in 2.575778 sec = 10.303 msec Quarter stroke: 500 iter in 2.926170 sec = 5.852 msec Short forward: 400 iter in 0.916901 sec = 2.292 msec Short backward: 400 iter in 2.181790 sec = 5.454 msec Seq outer: 2048 iter in 0.520920 sec = 0.254 msec Seq inner: 2048 iter in 0.545300 sec = 0.266 msec Transfer rates: outside: 102400 kbytes in 1.414997 sec = 72368 kbytes/sec middle: 102400 kbytes in 1.454444 sec = 70405 kbytes/sec inside: 102400 kbytes in 1.422527 sec = 71985 kbytes/sec Do you have experiences with iSCSI multipath? I read about geom_fox and gmultipath... Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Thu Dec 17 14:06:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C411F106566C for ; Thu, 17 Dec 2009 14:06:27 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 508918FC18 for ; Thu, 17 Dec 2009 14:06:26 +0000 (UTC) Received: by ewy26 with SMTP id 26so1265031ewy.3 for ; Thu, 17 Dec 2009 06:06:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=TO452ETE8bA+0kzNdOsHFZI367TYYDHfbBx/zXJGZCY=; b=BOKorcbdiD1EDIVhrVfhbNEs4LedwsF6sz6/wATteFPRfMKSUsCiGTjbkcvy8X5tlF 3cGUDHJJ0HTNs8lNvTtVxkHZ3bHUyhwuB78f9CnuaKlCGaX8Um3rzdzSo/ku0il1DJgo QwrNKcU5szbTPR5E32c7nM45Mxcf94jFVPeqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=ExWcdHJosTrnl1uaKgokh7xFf1+Wlh0KtJe682KWMwcy/pJLvYsrWVRaHUIKwZPwP7 jnwTu6huVTQm8yQXEIfxY2jv8Qgkv4mbuIHHFVnXR6q8YBGeUrDwPv8CrhnivXTf+B9m z6uY1+RTDVpC2eUK/vSkgCXI7JIq5Xr8uJqLI= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.216.90.212 with SMTP id e62mr962350wef.26.1261058786118; Thu, 17 Dec 2009 06:06:26 -0800 (PST) In-Reply-To: <4B2A37EF.10709@quip.cz> References: <4B2A37EF.10709@quip.cz> From: Ivan Voras Date: Thu, 17 Dec 2009 15:06:06 +0100 X-Google-Sender-Auth: e78d351ae839c7a7 Message-ID: <9bbcef730912170606j2af0d46br87a3db91ef0c4cd5@mail.gmail.com> To: Miroslav Lachman <000.fbsd@quip.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-scsi@freebsd.org, asossi@dotcom.ts.it, FreeBSD Stable Subject: Re: iSCSI initiator and Dell PowerVault MD3000i X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 14:06:27 -0000 2009/12/17 Miroslav Lachman <000.fbsd@quip.cz>: > please Cc: me, I am not subscribed to freebsd-scsi > > Sossi Andrej wrote: >>> On 16. 12. 2009 15:57, Miroslav Lachman wrote: >>> [...] >>> I use MD300i with FreeBSD 7.0 and 7.1 with iscsi-2.2.2. It work fine. >>> But be careful to configure MD3000i. MD3000i assign by default first >>> disk to preferred controller 0, second disk to preferred controller 1, >>> third disk to preferred controller 0, and so on. First, third, fifth... >>> disks is usable from FreeBSD, but second, fourth,... disks result >>> unusable. >>> Work around: manually assign all disks to controller 0. >> >> When you say "unusable" do you mean you can't access it at all / it >> errors even if it's the only path (drive) used? It would be normal if >> you have for example two paths to each drive and can't mount the other >> path if one path to the drive is mounted - this is not a usable >> combination. You can use geom_multipath to get multipath failover. > > I got errors even in unmounted state. > I tried iscsi-2.2.3 and got same errors. I tried second path first (devic= e > da0) and it produces same errors, then I run iscontrol for the first path > (device da1) and everything is fine. > > =C2=A0---- path throught second controller: ERROR ---- > # diskinfo -t /dev/da0 > /dev/da0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0512 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = # sectorsize > =C2=A0 =C2=A0 =C2=A0 =C2=A02998998663168 =C2=A0 # mediasize in bytes (2.7= T) > =C2=A0 =C2=A0 =C2=A0 =C2=A05857419264 =C2=A0 =C2=A0 =C2=A0# mediasize in = sectors > =C2=A0 =C2=A0 =C2=A0 =C2=A0364607 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# Cyl= inders according to firmware. > =C2=A0 =C2=A0 =C2=A0 =C2=A0255 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = # Heads according to firmware. > =C2=A0 =C2=A0 =C2=A0 =C2=A063 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0# Sectors according to firmware. > > Seek times: > =C2=A0 =C2=A0 =C2=A0 =C2=A0Full stroke: =C2=A0 =C2=A0diskinfo: read error= or disk too small for test.: > Invalid argument > > > =C2=A0---- path throught first controller: OK ---- > # diskinfo -t /dev/da1 > /dev/da1 > =C2=A0 =C2=A0 =C2=A0 =C2=A0512 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = # sectorsize > =C2=A0 =C2=A0 =C2=A0 =C2=A02998998663168 =C2=A0 # mediasize in bytes (2.7= T) > =C2=A0 =C2=A0 =C2=A0 =C2=A05857419264 =C2=A0 =C2=A0 =C2=A0# mediasize in = sectors > =C2=A0 =C2=A0 =C2=A0 =C2=A0364607 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# Cyl= inders according to firmware. > =C2=A0 =C2=A0 =C2=A0 =C2=A0255 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = # Heads according to firmware. > =C2=A0 =C2=A0 =C2=A0 =C2=A063 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0# Sectors according to firmware. > > Seek times: > =C2=A0 =C2=A0 =C2=A0 =C2=A0Full stroke: =C2=A0 =C2=A0 =C2=A0250 iter in = =C2=A0 2.483517 sec =3D =C2=A0 =C2=A09.934 msec > =C2=A0 =C2=A0 =C2=A0 =C2=A0Half stroke: =C2=A0 =C2=A0 =C2=A0250 iter in = =C2=A0 2.575778 sec =3D =C2=A0 10.303 msec > =C2=A0 =C2=A0 =C2=A0 =C2=A0Quarter stroke: =C2=A0 500 iter in =C2=A0 2.92= 6170 sec =3D =C2=A0 =C2=A05.852 msec > =C2=A0 =C2=A0 =C2=A0 =C2=A0Short forward: =C2=A0 =C2=A0400 iter in =C2=A0= 0.916901 sec =3D =C2=A0 =C2=A02.292 msec > =C2=A0 =C2=A0 =C2=A0 =C2=A0Short backward: =C2=A0 400 iter in =C2=A0 2.18= 1790 sec =3D =C2=A0 =C2=A05.454 msec > =C2=A0 =C2=A0 =C2=A0 =C2=A0Seq outer: =C2=A0 =C2=A0 =C2=A0 2048 iter in = =C2=A0 0.520920 sec =3D =C2=A0 =C2=A00.254 msec > =C2=A0 =C2=A0 =C2=A0 =C2=A0Seq inner: =C2=A0 =C2=A0 =C2=A0 2048 iter in = =C2=A0 0.545300 sec =3D =C2=A0 =C2=A00.266 msec > Transfer rates: > =C2=A0 =C2=A0 =C2=A0 =C2=A0outside: =C2=A0 =C2=A0 =C2=A0 102400 kbytes in= =C2=A0 1.414997 sec =3D =C2=A0 =C2=A072368 kbytes/sec > =C2=A0 =C2=A0 =C2=A0 =C2=A0middle: =C2=A0 =C2=A0 =C2=A0 =C2=A0102400 kbyt= es in =C2=A0 1.454444 sec =3D =C2=A0 =C2=A070405 kbytes/sec > =C2=A0 =C2=A0 =C2=A0 =C2=A0inside: =C2=A0 =C2=A0 =C2=A0 =C2=A0102400 kbyt= es in =C2=A0 1.422527 sec =3D =C2=A0 =C2=A071985 kbytes/sec This is strange and probably indicates a bug somewhere. Can you check your SAN configuration for example, wrong access permissions assigned to the problematic port? > Do you have experiences with iSCSI multipath? I read about geom_fox and > gmultipath... You should probably skip geom_fox and just use gmultipath. It works as advertised, nothing fancy to report. From owner-freebsd-stable@FreeBSD.ORG Thu Dec 17 15:45:42 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FDC3106568F; Thu, 17 Dec 2009 15:45:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D47FA8FC08; Thu, 17 Dec 2009 15:45:41 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7006A46B2A; Thu, 17 Dec 2009 10:45:41 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id C967D8A01D; Thu, 17 Dec 2009 10:45:40 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 17 Dec 2009 09:08:49 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912170908.49119.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 17 Dec 2009 10:45:40 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable@freebsd.org, Steven Hartland Subject: Re: Passenger hangs on live and SEGV on tests possible threading / kernel bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 15:45:42 -0000 On Thursday 17 December 2009 6:12:07 am Steven Hartland wrote: > We're having an issue with Passenger on FreeBSD where it will hang > and stop processing any more requests the details are attach to > the following bug report: > http://code.google.com/p/phusion-passenger/issues/detail?id=318#c14 > > In addition the test suite crashes in what seems to be a very > basic test, which I'm at a loss with. > http://code.google.com/p/phusion-passenger/issues/detail?id=441 > > I'm thinking this may be a bugs in the FreeBSD either kernel or > thread library as the crashes don't make any sense from the > application side. > > Any advise on debugging or feedback on the stack traces would > be much appreciated. For the hang it seems you have a thread waiting in a blocking read(), a thread waiting in a blocking accept(), and lots of threads creating condition variables. However, the pthread_cond_init() in libpthread (libthr on FreeBSD) doesn't call pthread_cleanup_push(), so your stack trace doesn't make sense to me. However, that may be gdb getting confused. The pthread_cleanup_push() frame may be cond_init(). However, it doesn't call umtx_op() (the _thr_umutex_init() call it makes just initializes the structure, it doesn't make a _umtx_op() system call). You might try posting on threads@ to try to get more info on this, but your pthread_cond_init() stack traces don't really make sense. Can you rebuild libc and libthr with debug symbols? For example: # cd /usr/src/lib/libc # make clean # make DEBUG_FLAGS=-g # make DEBUG_FLAGS=-g install However, if you are hanging in read(), that usually means you have a socket that just doesn't have data. That might be an application bug of some sort. The segv trace doesn't include the first part of GDB messages which show which thread actually had a seg fault. It looks like it was the thread that was throwing an exception. However, nanosleep() doesn't throw exceptions, so that stack trace doesn't really make sense either. Perhaps that stack is hosed by the exception handling code? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Dec 17 15:46:49 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31DD5106568F; Thu, 17 Dec 2009 15:46:49 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id DEB698FC33; Thu, 17 Dec 2009 15:46:48 +0000 (UTC) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 280F419E046; Thu, 17 Dec 2009 16:46:47 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id B9BD019E045; Thu, 17 Dec 2009 16:46:44 +0100 (CET) Message-ID: <4B2A5264.5090302@quip.cz> Date: Thu, 17 Dec 2009 16:46:44 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.6) Gecko/20091206 SeaMonkey/2.0.1 MIME-Version: 1.0 To: Sossi Andrej References: <4B281279.6060706@quip.cz> <4B28F557.6000305@quip.cz> <4B293627.7050000@dotcom.ts.it> In-Reply-To: <4B293627.7050000@dotcom.ts.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, freebsd-stable Stable , Ivan Voras Subject: Re: iSCSI initiator and Dell PowerVault MD3000i X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 15:46:49 -0000 Sossi Andrej wrote: > [...] > I use MD300i with FreeBSD 7.0 and 7.1 with iscsi-2.2.2. It work fine. > But be careful to configure MD3000i. MD3000i assign by default first > disk to preferred controller 0, second disk to preferred controller 1, > third disk to preferred controller 0, and so on. First, third, fifth... > disks is usable from FreeBSD, but second, fourth,... disks result unusable. > Work around: manually assign all disks to controller 0. > I'm talking with Dell's technical support, but Dell not support FreeBSD! > In any case, technical support tell me, the problem (maybe) is the > multipath. FreeBSD use only one path (only one IP) to communicate to > MD3000i. Second net interface in unused. > > I hope that I have been helpful. It was helpful! You are right, that MD Storage Manager set preferred controller path to 0 for odd Virtual Disks and 1 to even Virtual Disks. (I don't know why) And if I manually changed it to controller 0, I can access it by this preferred path, but can't access it by the other path. Does it mean I can't use multipath feature? Or what is the right behavior of this "preferred path" settings? Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Thu Dec 17 15:52:37 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A2DA106566B; Thu, 17 Dec 2009 15:52:37 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 34B838FC1A; Thu, 17 Dec 2009 15:52:36 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id nBHFqZqM001350; Thu, 17 Dec 2009 10:52:35 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Thu, 17 Dec 2009 10:52:35 -0500 (EST) Date: Thu, 17 Dec 2009 10:52:35 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Baldwin In-Reply-To: <200912170908.49119.jhb@freebsd.org> Message-ID: References: <200912170908.49119.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org, Steven Hartland Subject: Re: Passenger hangs on live and SEGV on tests possible threading / kernel bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 15:52:37 -0000 On Thu, 17 Dec 2009, John Baldwin wrote: > On Thursday 17 December 2009 6:12:07 am Steven Hartland wrote: >> We're having an issue with Passenger on FreeBSD where it will hang >> and stop processing any more requests the details are attach to >> the following bug report: >> http://code.google.com/p/phusion-passenger/issues/detail?id=318#c14 >> >> In addition the test suite crashes in what seems to be a very >> basic test, which I'm at a loss with. >> http://code.google.com/p/phusion-passenger/issues/detail?id=441 >> >> I'm thinking this may be a bugs in the FreeBSD either kernel or >> thread library as the crashes don't make any sense from the >> application side. >> >> Any advise on debugging or feedback on the stack traces would >> be much appreciated. > > For the hang it seems you have a thread waiting in a blocking read(), a thread > waiting in a blocking accept(), and lots of threads creating condition > variables. However, the pthread_cond_init() in libpthread (libthr on FreeBSD) > doesn't call pthread_cleanup_push(), so your stack trace doesn't make sense to > me. However, that may be gdb getting confused. The pthread_cleanup_push() > frame may be cond_init(). However, it doesn't call umtx_op() (the > _thr_umutex_init() call it makes just initializes the structure, it doesn't > make a _umtx_op() system call). You might try posting on threads@ to try to > get more info on this, but your pthread_cond_init() stack traces don't really > make sense. Can you rebuild libc and libthr with debug symbols? Yes, good advice, I have noticed that you can't trust GDB stack traces unless libc and libthr have been built with debug (-g) enabled. -- DE From owner-freebsd-stable@FreeBSD.ORG Thu Dec 17 15:54:17 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35ECF1065693; Thu, 17 Dec 2009 15:54:17 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id DC0768FC28; Thu, 17 Dec 2009 15:54:16 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1NLIgB-0006pY-0E; Thu, 17 Dec 2009 17:54:15 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Miroslav Lachman <000.fbsd@quip.cz> In-reply-to: <4B2A37EF.10709@quip.cz> References: 4B293627.7050000@dotcom.ts.it <4B2A37EF.10709@quip.cz> Comments: In-reply-to Miroslav Lachman <000.fbsd@quip.cz> message dated "Thu, 17 Dec 2009 14:53:51 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Dec 2009 17:54:14 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-scsi@freebsd.org, asossi@dotcom.ts.it, FreeBSD Stable , Ivan Voras Subject: Re: iSCSI initiator and Dell PowerVault MD3000i X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 15:54:17 -0000 > please Cc: me, I am not subscribed to freebsd-scsi > > Sossi Andrej wrote: > >> On 16. 12. 2009 15:57, Miroslav Lachman wrote: > >> [...] > >> I use MD300i with FreeBSD 7.0 and 7.1 with iscsi-2.2.2. It work fine. > >> But be careful to configure MD3000i. MD3000i assign by default first > >> disk to preferred controller 0, second disk to preferred controller 1, > >> third disk to preferred controller 0, and so on. First, third, fifth... > >> disks is usable from FreeBSD, but second, fourth,... disks result > unusable. > >> Work around: manually assign all disks to controller 0. > > > > When you say "unusable" do you mean you can't access it at all / it > > errors even if it's the only path (drive) used? It would be normal if > > you have for example two paths to each drive and can't mount the other > > path if one path to the drive is mounted - this is not a usable > > combination. You can use geom_multipath to get multipath failover. > > I got errors even in unmounted state. > I tried iscsi-2.2.3 and got same errors. I tried second path first > (device da0) and it produces same errors, then I run iscontrol for the > first path (device da1) and everything is fine. > > ---- path throught second controller: ERROR ---- > # diskinfo -t /dev/da0 > /dev/da0 > 512 # sectorsize > 2998998663168 # mediasize in bytes (2.7T) > 5857419264 # mediasize in sectors > 364607 # Cylinders according to firmware. > 255 # Heads according to firmware. > 63 # Sectors according to firmware. > > Seek times: > Full stroke: diskinfo: read error or disk too small for > test.: Invalid argument > > > ---- path throught first controller: OK ---- > # diskinfo -t /dev/da1 > /dev/da1 > 512 # sectorsize > 2998998663168 # mediasize in bytes (2.7T) > 5857419264 # mediasize in sectors > 364607 # Cylinders according to firmware. > 255 # Heads according to firmware. > 63 # Sectors according to firmware. > > Seek times: > Full stroke: 250 iter in 2.483517 sec = 9.934 msec > Half stroke: 250 iter in 2.575778 sec = 10.303 msec > Quarter stroke: 500 iter in 2.926170 sec = 5.852 msec > Short forward: 400 iter in 0.916901 sec = 2.292 msec > Short backward: 400 iter in 2.181790 sec = 5.454 msec > Seq outer: 2048 iter in 0.520920 sec = 0.254 msec > Seq inner: 2048 iter in 0.545300 sec = 0.266 msec > Transfer rates: > outside: 102400 kbytes in 1.414997 sec = 72368 > kbytes/sec > middle: 102400 kbytes in 1.454444 sec = 70405 > kbytes/sec > inside: 102400 kbytes in 1.422527 sec = 71985 > kbytes/sec > the numbers seem ok to me, concidering that the net is 1Gb. can you configure the target virtual disk to have luns? in any case the errors seem to be in the md3000i, can you see/check its error log? > > Do you have experiences with iSCSI multipath? I read about geom_fox and > gmultipath... i have no experience with it, and personaly see no benefit in it (but then others might disagree :-) danny From owner-freebsd-stable@FreeBSD.ORG Thu Dec 17 17:27:23 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31483106568F; Thu, 17 Dec 2009 17:27:23 +0000 (UTC) (envelope-from prvs=1602d8d4d9=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 24FDB8FC0A; Thu, 17 Dec 2009 17:27:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1261070842; x=1261675642; q=dns/txt; h=Received: Message-ID:From:To:Cc:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=snWfwQUl0zIE3KIw6t8wO YMnSFn/Pa1QaX6QoeZpkug=; b=HHB7nXQlzzSsrcCvOJIZpM+o7wbC5Zst04gix i2ekluhHO+DesU70MbnRYCBXEdh0qTUEUELU62btxaV9ue73VuCymGFkgwlfYzUr 99So9q/1FWdrV+vglbwWsm6Fstno+ZeZol5M5AaOn+kTsoGeOH/XfDgOub3JJZWI J1n0Mk= X-MDAV-Processed: mail1.multiplay.co.uk, Thu, 17 Dec 2009 17:27:22 +0000 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50008880113.msg; Thu, 17 Dec 2009 17:27:20 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 17 Dec 2009 17:27:20 +0000 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 213.123.247.160 X-Return-Path: prvs=1602d8d4d9=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <28F90357192743E085ABEE7CD4C9FDF9@multiplay.co.uk> From: "Steven Hartland" To: "John Baldwin" , References: <200912170908.49119.jhb@freebsd.org> Date: Thu, 17 Dec 2009 17:27:17 -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.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: freebsd-stable@freebsd.org Subject: Re: Passenger hangs on live and SEGV on tests possible threading / kernel bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 17:27:23 -0000 ----- Original Message ----- From: "John Baldwin" > For the hang it seems you have a thread waiting in a blocking read(), a thread > waiting in a blocking accept(), and lots of threads creating condition > variables. However, the pthread_cond_init() in libpthread (libthr on FreeBSD) > doesn't call pthread_cleanup_push(), so your stack trace doesn't make sense to > me. However, that may be gdb getting confused. The pthread_cleanup_push() > frame may be cond_init(). However, it doesn't call umtx_op() (the > _thr_umutex_init() call it makes just initializes the structure, it doesn't > make a _umtx_op() system call). You might try posting on threads@ to try to > get more info on this, but your pthread_cond_init() stack traces don't really > make sense. Can you rebuild libc and libthr with debug symbols? > > For example: > > # cd /usr/src/lib/libc > # make clean > # make DEBUG_FLAGS=-g > # make DEBUG_FLAGS=-g install > > However, if you are hanging in read(), that usually means you have a socket > that just doesn't have data. That might be an application bug of some sort. > > The segv trace doesn't include the first part of GDB messages which show which > thread actually had a seg fault. It looks like it was the thread that was > throwing an exception. However, nanosleep() doesn't throw exceptions, so that > stack trace doesn't really make sense either. Perhaps that stack is hosed by > the exception handling code? I've uploaded a two more traces for the oxt test failure / segv. http://code.google.com/p/phusion-passenger/issues/detail?id=441#c1 >From looking at the test case it testing the capture of failures and its ability to create a stack trace output so that may give others some indication where the issue may be? I will look to do the same on for the hang issue but that's on a live site so will need to schedule some downtime before I can get those rebuilt and then wait for it to hang again, which could be quite some time :( Regards 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-stable@FreeBSD.ORG Thu Dec 17 17:28:00 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70716106568B; Thu, 17 Dec 2009 17:28:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 34A578FC17; Thu, 17 Dec 2009 17:27:59 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id nBHHRxX6009562; Thu, 17 Dec 2009 12:27:59 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id nBHHRxNC009546; Thu, 17 Dec 2009 17:27:59 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Dec 2009 17:27:59 GMT Message-Id: <200912171727.nBHHRxNC009546@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 17:28:00 -0000 TB --- 2009-12-17 16:08:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-12-17 16:08:01 - starting RELENG_8_0 tinderbox run for i386/i386 TB --- 2009-12-17 16:08:01 - cleaning the object tree TB --- 2009-12-17 16:08:25 - cvsupping the source tree TB --- 2009-12-17 16:08:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/i386/i386/supfile TB --- 2009-12-17 16:08:57 - building world TB --- 2009-12-17 16:08:57 - MAKEOBJDIRPREFIX=/obj TB --- 2009-12-17 16:08:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-12-17 16:08:57 - TARGET=i386 TB --- 2009-12-17 16:08:57 - TARGET_ARCH=i386 TB --- 2009-12-17 16:08:57 - TZ=UTC TB --- 2009-12-17 16:08:57 - __MAKE_CONF=/dev/null TB --- 2009-12-17 16:08:57 - cd /src TB --- 2009-12-17 16:08:57 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 17 16:08:58 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Dec 17 17:08:01 UTC 2009 TB --- 2009-12-17 17:08:01 - generating LINT kernel config TB --- 2009-12-17 17:08:01 - cd /src/sys/i386/conf TB --- 2009-12-17 17:08:01 - /usr/bin/make -B LINT TB --- 2009-12-17 17:08:01 - building LINT kernel TB --- 2009-12-17 17:08:01 - MAKEOBJDIRPREFIX=/obj TB --- 2009-12-17 17:08:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-12-17 17:08:01 - TARGET=i386 TB --- 2009-12-17 17:08:01 - TARGET_ARCH=i386 TB --- 2009-12-17 17:08:01 - TZ=UTC TB --- 2009-12-17 17:08:01 - __MAKE_CONF=/dev/null TB --- 2009-12-17 17:08:01 - cd /src TB --- 2009-12-17 17:08:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Dec 17 17:08:01 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdsocket.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdstate.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdsubs.c /src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdsubs.c: In function 'nfsrv_fillattr': /src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdsubs.c:1351: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /src/sys/modules/nfsd. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-12-17 17:27:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-12-17 17:27:59 - ERROR: failed to build lint kernel TB --- 2009-12-17 17:27:59 - 3641.49 user 738.09 system 4797.41 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Thu Dec 17 17:41:49 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A382B1065670 for ; Thu, 17 Dec 2009 17:41:48 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 5B4C78FC0A for ; Thu, 17 Dec 2009 17:41:48 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NLKME-0006XM-B8 for freebsd-stable@freebsd.org; Thu, 17 Dec 2009 18:41:46 +0100 Received: from 78-1-170-225.adsl.net.t-com.hr ([78.1.170.225]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Dec 2009 18:41:46 +0100 Received: from ivoras by 78-1-170-225.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Dec 2009 18:41:46 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 17 Dec 2009 18:41:21 +0100 Lines: 16 Message-ID: References: <200912170908.49119.jhb@freebsd.org> <28F90357192743E085ABEE7CD4C9FDF9@multiplay.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-170-225.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090612) In-Reply-To: <28F90357192743E085ABEE7CD4C9FDF9@multiplay.co.uk> Sender: news Cc: freebsd-hackers@freebsd.org Subject: Re: Passenger hangs on live and SEGV on tests possible threading / kernel bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 17:41:49 -0000 Steven Hartland wrote: > > I will look to do the same on for the hang issue but that's on a live > site so > will need to schedule some downtime before I can get those rebuilt and then > wait for it to hang again, which could be quite some time :( Actually, you can rebuild it *and* reinstall libc and libthr on a live system, if it's the same version of course. Already running processes will run off a "deleted" file (inode will still be there) and new processes will, since it's the same version, not notice anything is different. The only downtime you will have is the time required to restart your application. From owner-freebsd-stable@FreeBSD.ORG Thu Dec 17 18:07:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12424106568F for ; Thu, 17 Dec 2009 18:07:08 +0000 (UTC) (envelope-from ma@dt.e-technik.tu-dortmund.de) Received: from krusty.dt.e-technik.tu-dortmund.de (krusty.dt.E-Technik.Uni-Dortmund.DE [129.217.163.1]) by mx1.freebsd.org (Postfix) with ESMTP id C737C8FC1D for ; Thu, 17 Dec 2009 18:07:07 +0000 (UTC) Received: from mandree.no-ip.org (f055098049.adsl.alicedsl.de [78.55.98.49]) by mail.dt.e-technik.tu-dortmund.de (Postfix) with ESMTPSA id 3FEAD4770D; Thu, 17 Dec 2009 18:47:57 +0100 (CET) Received: from merlin.emma.line.org (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 0A25B945F3; Thu, 17 Dec 2009 18:47:55 +0100 (CET) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Dmitry Morozovsky" , freebsd-stable@freebsd.org References: Date: Thu, 17 Dec 2009 18:47:55 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Matthias Andree" Organization: Message-ID: In-Reply-To: User-Agent: Opera Mail/10.10 (Linux) Cc: Subject: Re: RELENG_7: gdm after portupgrade does not allow logins X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 18:07:08 -0000 Am 17.12.2009, 02:09 Uhr, schrieb Dmitry Morozovsky : > Dear colleagues, > > after portupgrade'ing on last gnome update I have very strange situation: > > gdm does not show neither login list not username text field; after > pressing > space, some unlabelled text field opens (symbols are echoed, so I > suppose it's > like login name field); however, entering anything there does not lead > anywhere. > > portupgrade -f gdm does not help; portupgrade -f ${direct gdm > dependencies} > does not help, either. > > And, of course, I even rebooted the machine without a bit of success. > > Any hints? Thanks in advance! Make sure that /proc is mounted, see the GNOME FAQ for details on how to set /etc/fstab to make that happen automatically on boot. -- Matthias Andree From owner-freebsd-stable@FreeBSD.ORG Fri Dec 18 08:41:59 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2117F106566C; Fri, 18 Dec 2009 08:41:59 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id A076C8FC27; Fri, 18 Dec 2009 08:41:58 +0000 (UTC) Received: from outgoing.leidinger.net (pD954F3E8.dip.t-dialin.net [217.84.243.232]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 0067084B3; Fri, 18 Dec 2009 09:41:52 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 62E812C3C47; Fri, 18 Dec 2009 09:41:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1261125709; bh=7Kipapgy3rweeTfUUAQOKrhXCQloAUE2qdwHXgHuMYg=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=3SsbuwRoWjDZf4oS8QfJagFvp2JGsjctzRHSdE/QbYkd7vkKU7FYACdT+2n4rNdTh /UQ5RFjERECkCPFQIDICx1vDsn+A2x8Endj1pPP09pYuYgkMWoSZeicpZkFzhaFxIs gc8OlAyg2TpQTgwbnitEfCnnY1uWUd6MkojxQhSyj2dhIz+qqwk0MaJEnzZ5093XWb gCmrP4qQGWk/NGHDxrgGzwAm8WQzrCJi1k/Q3aefDdNAWHezoFxlcbrfo8/tMyGzQH 8ZXLfI2oppfWX2NPlgvq7EbCTofFcrQ4eaP30oBj5LHBZh/LCWVPXJxuZMXz9Udbn0 C0TyREbDmDATw== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id nBI8fmuN080401; Fri, 18 Dec 2009 09:41:48 +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 Framework) with HTTP; Fri, 18 Dec 2009 09:41:48 +0100 Message-ID: <20091218094148.201530v5i6vmlrgg@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 18 Dec 2009 09:41:48 +0100 From: Alexander Leidinger To: Boris Samorodov References: <20091215153543.2686145v583um280@webmail.leidinger.net> <55734559@ipt.ru> In-Reply-To: <55734559@ipt.ru> 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.3.5) / FreeBSD-8.0 X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 0067084B3.2A63B X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.86, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, MANGLED_SEX 2.30) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1261730514.35433@ha/rK0+ivgtF+xuNay5rLg X-EBL-Spam-Status: No Cc: stable@freebsd.org, ivoras@freebsd.org Subject: Re: Stability problems with 7-stable (after 7.1 -> 7.2 -> 7-stable) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 08:41:59 -0000 Quoting Boris Samorodov (from Thu, 17 Dec 2009 20:55:44 +0300): > Ivan Voras writes: >> Alexander Leidinger wrote: >>> Hi, >>> >>> please CC me on replies. > > Seems you were not CCed... I'm now subscribed to stable@, thanks for forwarding this. >>> I have a system which was at 7.1-pX. After the update to 7.2-p5 it >>> started to exhibit deadlocks after some minutes of uptime. >>> >>> With 7.1 (generic kernel) it was running fine, with 7.2 generic the >>> problems started directly. >>> >>> The system is now at 7-stable with a custom kernel >>> (http://www.Leidinger.net/test/ALCATRAZ), basically generic without >>> unneeded drivers plus witness/invariants/sw-watchdog. >>> >>> The system is an AMD Dual Core with NVidia MCP61 chipset >>> (http://www.Leidinger.net/test/dmesg.alcatraz), 2 GB RAM, 2 >>> harddisks and FreeBSD 32bit install. >> >> Some generic things to try: >> - did you monitor the system with something (top or systat >> -vm) to see if there is something unusual, like interrupt storms? When I had the initial problems, I asked for a KVM-switch to be connected to the system (not a free service). In SU mode I didn't see any problem. When starting the system but not the jails, I didn't see any problem (cvsup/buildworld/...). When I started the jails, I started to see the problems. >> - no physical access is a problem; If you do manage it, I'd >> say try running single user for some time with systat -vm just to see >> what happens. This is not an option now. >> I would not trust ZFS in 7-stable since it lags a bit behind patches >> done to 8 but 7.2 should be fine - at least I don't have any such >> problems with it (though no AMD boxes to test them with it). Ivan, the system started out to be without ZFS, just after I started to see deadlocks I switched to ZFS. This _improved_ the situation. Now the system survives between 3h and about 11h without a deadlock. If I run every 5 minutes a script which logs 4 text lines to the root (UFS) and runs 3x sync + sleep 5 + 3x sync the frequency of deadlocks increases. >> If you haven't updated your ZFS pools, I'd suggest reverting back to >> 7.1, then building or downloading an 8.0 kernel and try it with 7.1 >> userland (reboot -k ...) simply to see if it helps. IIRC there where KBI changes (ifconfig?) which prevents me to go back to 7.1 without access to the console. As this is a production machine (it hosts not only my blog/website/mails, but stuff from other persons too), the goal is to stabilize this system now. Kib analyzed 2 crashdumps I had (watchdog triggered) and he thinks they are because of ZFS deadlocks. So the initial problem (without ZFS) is not know yet, but this info will hopefully allow to stabilize the system further (see also my mail about at least 57 unmerged ZFS patches). Bye, Alexander. -- Universities are places of knowledge. The freshman each bring a little in with them, and the seniors take none away, so knowledge accumulates. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Fri Dec 18 20:14:37 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92A1E106568D; Fri, 18 Dec 2009 20:14:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 334168FC0C; Fri, 18 Dec 2009 20:14:36 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABtxK0uDaFvH/2dsb2JhbADIFQmOBYJKgWQE X-IronPort-AV: E=Sophos;i="4.47,420,1257138000"; d="scan'208";a="59736052" Received: from danube.cs.uoguelph.ca ([131.104.91.199]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 18 Dec 2009 15:14:36 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id DC7D61085DDB; Fri, 18 Dec 2009 15:14:35 -0500 (EST) X-Virus-Scanned: amavisd-new at danube.cs.uoguelph.ca Received: from danube.cs.uoguelph.ca ([127.0.0.1]) by localhost (danube.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wy+enAQ0cbn3; Fri, 18 Dec 2009 15:14:35 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id F003810843DA; Fri, 18 Dec 2009 15:14:34 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id nBIKNim11435; Fri, 18 Dec 2009 15:23:44 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 18 Dec 2009 15:23:44 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Jeremie Le Hen In-Reply-To: <20091213230650.GA45540@felucia.tataz.chchile.org> Message-ID: References: <20091213230650.GA45540@felucia.tataz.chchile.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Rick Macklem , freebsd-stable@FreeBSD.org Subject: Re: Cannot list a particular directory through NFS with UDP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 20:14:37 -0000 On Mon, 14 Dec 2009, Jeremie Le Hen wrote: > 00:00:01.953196 IP (tos 0x0, ttl 64, id 48966, offset 0, flags [none], proto UDP (17), length 168) 192.168.1.1.3819288094 > 192.168.1.222.2049: 140 readdir [|nfs] > 00:00:01.953665 IP (tos 0x0, ttl 64, id 27028, offset 0, flags [+], proto UDP (17), length 1500) 192.168.1.222.2049 > 192.168.1.1.3819288094: reply ok 1472 readdir POST: DIR 755 ids 0/0 [|nfs] > 00:00:01.953711 IP (tos 0x0, ttl 64, id 27028, offset 1480, flags [none], proto UDP (17), length 632) 192.168.1.222 > 192.168.1.1: udp > This appears to be the reply to the nfs readdir request, which is what would be expected. It could be a problem with the content or the reply or a NetBSD client issue. If you were to email me the raw tcpdump capture for the above, I could take a look at it in wireshark (which knows how to interpret nfs) and see if there is anything bogus looking in the reply. ("tcpdump -s 0 -w host 192.168.1.1" and then email me as an attachment, should do it) rick From owner-freebsd-stable@FreeBSD.ORG Fri Dec 18 22:38:20 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0987C106566B; Fri, 18 Dec 2009 22:38:20 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id B6FD78FC14; Fri, 18 Dec 2009 22:38:19 +0000 (UTC) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 673B119E044; Fri, 18 Dec 2009 23:38:18 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 081E419E045; Fri, 18 Dec 2009 23:38:16 +0100 (CET) Message-ID: <4B2C0457.7050205@quip.cz> Date: Fri, 18 Dec 2009 23:38:15 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.6) Gecko/20091206 SeaMonkey/2.0.1 MIME-Version: 1.0 To: Daniel Braniss References: 4B293627.7050000@dotcom.ts.it <4B2A37EF.10709@quip.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, asossi@dotcom.ts.it, FreeBSD Stable , Ivan Voras Subject: Re: iSCSI initiator and Dell PowerVault MD3000i X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 22:38:20 -0000 Daniel Braniss wrote: [...] Hi Daniel > the numbers seem ok to me, concidering that the net is 1Gb. > can you configure the target virtual disk to have luns? Each virtual disk is automatically on its LUN (started from 0) > in any case the errors seem to be in the md3000i, can you see/check its > error log? No warnings or errors in log, just notices without anything meaningfull to me - I can send you whole log if you are interested >> Do you have experiences with iSCSI multipath? I read about geom_fox and >> gmultipath... > i have no experience with it, and personaly see no benefit in it (but then > others might disagree :-) I tried 'ifconfig bce1 down' to simulate broken preferred path (hoping that second path become preferred and virtual disks will be available by the second path... but it failed) and then "all hangs". I tried to access /dev/da0 in the meantime by diskinfo and diskinfo became unresponsive and unkillable by kill -9. Then I sent SIGHUP to iscontrol but again - process is hang and unkillable. I put bce1 up again, but no change. The machine was livelocked - responding to ping, allows new SSH login, but any commands hang. I couldn't 'su - root', or run 'top' etc. I waited about 20 hours, but no change. "Graceful shutdown" from remote console (Dell DRAC6) also failed. Everything is fine after powercycle so I did it again to check if it was coincidence... same result - unkillable processes. So instead of iSCSI connected storage with multipath failover, I got singlepath storage causing system freeze in case of network disconnection :( Please let me know if you are interested in this and if you want some more details or access to this machine. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 01:32:44 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8034F10656C8 for ; Sat, 19 Dec 2009 01:32:44 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (dsl081-172-045.sea1.dsl.speakeasy.net [64.81.172.45]) by mx1.freebsd.org (Postfix) with ESMTP id 806078FC15 for ; Sat, 19 Dec 2009 01:32:43 +0000 (UTC) Received: from webmail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id nBJ1WZSB068253 for ; Fri, 18 Dec 2009 17:32:41 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([64.81.172.214]) (Local authenticated user inf0s) by webmail.1command.com with HTTP; Fri, 18 Dec 2009 17:32:41 -0800 (PST) Message-ID: Date: Fri, 18 Dec 2009 17:32:41 -0800 (PST) From: "Chris H" To: freebsd-stable@freebsd.org User-Agent: HRC Internet Messaging/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit Subject: SSL appears to be broken in 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 01:32:44 -0000 Greetings, A recent (cvs checkout of src/ports on 2009-12-09) install of 8 seems to indicate that changes in SSL have made it virtually unusable. I've spent the past 3 days attempting to (re)create an SSL enabled virtual host that serves web based access to local mail. Since it's local, I'm using self-signed certs following a scheme that has always worked flawlessly for the past 9 yrs. However, now having installed 8, it isn't working. The browser(s) throw "ssl_error_handshake_failure_alert" (ff-3.56). Other gecko based, and non-gecko based UA's throw similar, as well as openssl's s_client. After immense research, the only thing I can find that might best explain it is a recent SA patch applied to FreeBSD's src (SA-09:15). After reading what the patch provides. I am able to better understand the error messages thrown to /var/messages when attempting to negotiate a secure session in a UA: kernel: TCP: [web.server.host.IP]:59735 to [web.server.host.IP]:443 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 37 bytes of data after socket was closed, sending RST and removing tcpcb kernel: TCP: [web.server.host.IP]:59735 to [web.server.host.IP]:443 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) kernel: TCP: [web.server.host.IP]:52153 to [web.server.host.IP]:443 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 37 bytes of data after socket was closed, sending RST and removing tcpcb kernel: TCP: [web.server.host.IP]:52153 to [web.server.host.IP]:443 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) kernel: TCP: [web.server.host.IP]:60382 to [web.server.host.IP]:443 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 37 bytes of data after socket was closed, sending RST and removing tcpcb kernel: TCP: [web.server.host.IP]:60382 to [web.server.host.IP]:443 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) So, if I understand things correctly. The patch prevents (re)negotiation. Making the likelihood of a successful "handshake" near null (as the log messages above show). I'm sure that some may be quick to point the finger at the self-signed cert being more likely the cause, I should add that while in fact quite unlikely, I too didn't completely rule that out. So I purchased one from startssl - money wasted. The results were the same. So it would appear that until something else is done to overcome the hole in current openssl, my only recourse is to back the patch out, and rebuild openssl && all affected ports - no? Thank you for all your time and consideration in this matter. --Chris H From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 04:43:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 633C31065697 for ; Sat, 19 Dec 2009 04:43:56 +0000 (UTC) (envelope-from peter@simons-rock.edu) Received: from hedwig.simons-rock.edu (hedwig.simons-rock.edu [208.81.88.14]) by mx1.freebsd.org (Postfix) with ESMTP id 2967E8FC17 for ; Sat, 19 Dec 2009 04:43:55 +0000 (UTC) Received: from cesium.hyperfine.info (c2.8d.5646.static.theplanet.com [70.86.141.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hedwig.simons-rock.edu (Postfix) with ESMTP id A40512BB36A; Fri, 18 Dec 2009 23:43:54 -0500 (EST) Date: Fri, 18 Dec 2009 23:43:53 -0500 From: "Peter C. Lai" To: Chris H Message-ID: <20091219044352.GO88081@cesium.hyperfine.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: SSL appears to be broken in 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 04:43:56 -0000 This might have something to do with a libthr discussion I was CCed on. Someone mentioned something about removing a link to libthr in openssl but I can't remember if this was in the port or base openssl... On 2009-12-18 05:32:41PM -0800, Chris H wrote: > Greetings, > A recent (cvs checkout of src/ports on 2009-12-09) install of 8 seems to indicate > that changes in SSL have made it virtually unusable. I've spent the past 3 days > attempting to (re)create an SSL enabled virtual host that serves web based access > to local mail. Since it's local, I'm using self-signed certs following a scheme > that > has always worked flawlessly for the past 9 yrs. However, now having installed 8, > it isn't working. The browser(s) throw "ssl_error_handshake_failure_alert" > (ff-3.56). > Other gecko based, and non-gecko based UA's throw similar, as well as openssl's > s_client. After immense research, the only thing I can find that might best explain > it is a recent SA patch applied to FreeBSD's src (SA-09:15). After reading what the > patch provides. I am able to better understand the error messages thrown to > /var/messages when attempting to negotiate a secure session in a UA: > > kernel: TCP: [web.server.host.IP]:59735 to [web.server.host.IP]:443 tcpflags > 0x18; tcp_do_segment: FIN_WAIT_2: Received 37 bytes of data after > socket was closed, sending RST and removing tcpcb > kernel: TCP: [web.server.host.IP]:59735 to [web.server.host.IP]:443 tcpflags > 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment > rejected (probably spoofed) > kernel: TCP: [web.server.host.IP]:52153 to [web.server.host.IP]:443 tcpflags > 0x18; tcp_do_segment: FIN_WAIT_2: Received 37 bytes of data after > socket was closed, sending RST and removing tcpcb > kernel: TCP: [web.server.host.IP]:52153 to [web.server.host.IP]:443 tcpflags > 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment > rejected (probably spoofed) > kernel: TCP: [web.server.host.IP]:60382 to [web.server.host.IP]:443 tcpflags > 0x18; tcp_do_segment: FIN_WAIT_2: Received 37 bytes of data after > socket was closed, sending RST and removing tcpcb > kernel: TCP: [web.server.host.IP]:60382 to [web.server.host.IP]:443 tcpflags > 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment > rejected (probably spoofed) > > So, if I understand things correctly. The patch prevents (re)negotiation. Making > the likelihood of a successful "handshake" near null (as the log messages above > show). I'm sure that some may be quick to point the finger at the self-signed > cert being more likely the cause, I should add that while in fact quite unlikely, > I too didn't completely rule that out. So I purchased one from startssl - money > wasted. The results were the same. So it would appear that until something else > is done to overcome the hole in current openssl, my only recourse is to back the > patch out, and rebuild openssl && all affected ports - no? > > Thank you for all your time and consideration in this matter. > > --Chris H > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- =========================================================== Peter C. Lai | Bard College at Simon's Rock Systems Administrator | 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 =========================================================== From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 07:48:26 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EBBF106566C for ; Sat, 19 Dec 2009 07:48:26 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (dsl081-172-045.sea1.dsl.speakeasy.net [64.81.172.45]) by mx1.freebsd.org (Postfix) with ESMTP id D58488FC28 for ; Sat, 19 Dec 2009 07:48:25 +0000 (UTC) Received: from webmail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id nBJ7lqXL069494; Fri, 18 Dec 2009 23:47:59 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([64.81.172.214]) (Local authenticated user inf0s) by webmail.1command.com with HTTP; Fri, 18 Dec 2009 23:48:22 -0800 (PST) Message-ID: <33656a3f4df6ab58b59883a55124ca11.HRCIM@webmail.1command.com> In-Reply-To: <20091219044352.GO88081@cesium.hyperfine.info> References: <20091219044352.GO88081@cesium.hyperfine.info> Date: Fri, 18 Dec 2009 23:48:22 -0800 (PST) From: "Chris H" To: freebsd-stable@freebsd.org User-Agent: HRC Internet Messaging/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit Cc: "Peter C. Lai" Subject: Re: SSL appears to be broken in 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 07:48:26 -0000 Hello Peter, and thank you for the reply. > On 2009-12-18 05:32:41PM -0800, Chris H wrote: > >> Greetings, >> A recent (cvs checkout of src/ports on 2009-12-09) install of 8 seems to >> indicate that changes in SSL have made it virtually unusable. I've spent the >> past 3 days attempting to (re)create an SSL enabled virtual host that serves >> web based access to local mail. Since it's local, I'm using self-signed certs >> following a scheme that has always worked flawlessly for the past 9 yrs. >> However, now having installed 8, >> it isn't working. The browser(s) throw "ssl_error_handshake_failure_alert" >> (ff-3.56). >> Other gecko based, and non-gecko based UA's throw similar, as well as >> openssl's s_client. After immense research, the only thing I can find that >> might best explain it is a recent SA patch applied to FreeBSD's src >> (SA-09:15). After reading what the >> patch provides. I am able to better understand the error messages thrown to >> /var/messages when attempting to negotiate a secure session in a UA: >> >> >> kernel: TCP: [web.server.host.IP]:59735 to [web.server.host.IP]:443 tcpflags >> 0x18; tcp_do_segment: FIN_WAIT_2: Received 37 bytes of data after >> socket was closed, sending RST and removing tcpcb kernel: TCP: >> [web.server.host.IP]:59735 to [web.server.host.IP]:443 tcpflags >> 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, >> segment rejected (probably spoofed) kernel: TCP: [web.server.host.IP]:52153 to >> [web.server.host.IP]:443 tcpflags >> 0x18; tcp_do_segment: FIN_WAIT_2: Received 37 bytes of data after >> socket was closed, sending RST and removing tcpcb kernel: TCP: >> [web.server.host.IP]:52153 to [web.server.host.IP]:443 tcpflags >> 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, >> segment rejected (probably spoofed) kernel: TCP: [web.server.host.IP]:60382 to >> [web.server.host.IP]:443 tcpflags >> 0x18; tcp_do_segment: FIN_WAIT_2: Received 37 bytes of data after >> socket was closed, sending RST and removing tcpcb kernel: TCP: >> [web.server.host.IP]:60382 to [web.server.host.IP]:443 tcpflags >> 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, >> segment rejected (probably spoofed) >> >> So, if I understand things correctly. The patch prevents (re)negotiation. >> Making >> the likelihood of a successful "handshake" near null (as the log messages >> above show). I'm sure that some may be quick to point the finger at the >> self-signed cert being more likely the cause, I should add that while in fact >> quite unlikely, I too didn't completely rule that out. So I purchased one from >> startssl - money wasted. The results were the same. So it would appear that >> until something else is done to overcome the hole in current openssl, my only >> recourse is to back the patch out, and rebuild openssl && all affected ports - >> no? On Fri, December 18, 2009 8:43 pm, Peter C. Lai wrote: > This might have something to do with a libthr discussion I was CCed on. > Someone mentioned something about removing a link to libthr in openssl > but I can't remember if this was in the port or base openssl... > Please pardon the pun; but was that /thread/ on _this_ list? Or, did you mean that you were CC's from a different list? If a different list, which one? Thank you again for taking the time to respond. --Chris H >> >> Thank you for all your time and consideration in this matter. >> >> >> --Chris H >> >> >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > -- > =========================================================== > Peter C. Lai | Bard College at Simon's Rock > Systems Administrator | 84 Alford Rd. > Information Technology Svcs. | Gt. Barrington, MA 01230 USA > peter AT simons-rock.edu | (413) 528-7428 > =========================================================== > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 08:16:10 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6679F1065672 for ; Sat, 19 Dec 2009 08:16:10 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing03.lava.net (outgoing03.lava.net [IPv6:2001:1888:0:1:202:b3ff:fe1d:6b98]) by mx1.freebsd.org (Postfix) with ESMTP id 156528FC12 for ; Sat, 19 Dec 2009 08:16:10 +0000 (UTC) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing03.lava.net (Postfix) with ESMTP id 5055F101D6; Fri, 18 Dec 2009 22:16:07 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id AA42F153882; Fri, 18 Dec 2009 22:16:06 -1000 (HST) Date: Fri, 18 Dec 2009 22:16:06 -1000 From: Clifton Royston To: Chris H Message-ID: <20091219081605.GA23586@lava.net> Mail-Followup-To: Chris H , freebsd-stable@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: SSL appears to be broken in 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 08:16:10 -0000 On Fri, Dec 18, 2009 at 05:32:41PM -0800, Chris H wrote: > Greetings, > A recent (cvs checkout of src/ports on 2009-12-09) install of 8 > seems to indicate that changes in SSL have made it virtually > unusable. I've spent the past 3 days attempting to (re)create an SSL > enabled virtual host that serves web based access to local mail. > Since it's local, I'm using self-signed certs following a scheme that > has always worked flawlessly for the past 9 yrs. However, now having > installed 8, it isn't working. The browser(s) throw > "ssl_error_handshake_failure_alert" (ff-3.56). Other gecko based, and > non-gecko based UA's throw similar, as well as openssl's s_client. > After immense research, the only thing I can find that might best > explain it is a recent SA patch applied to FreeBSD's src (SA-09:15). > After reading what the patch provides. I am able to better understand > the error messages thrown to > /var/messages when attempting to negotiate a secure session in a UA: ... > So, if I understand things correctly. The patch prevents > (re)negotiation. Making the likelihood of a successful "handshake" > near null (as the log messages above show). I'm sure that some may be > quick to point the finger at the self-signed cert being more likely > the cause, I should add that while in fact quite unlikely, I too > didn't completely rule that out. So I purchased one from startssl - > money wasted. The results were the same. So it would appear that > until something else is done to overcome the hole in current openssl, > my only recourse is to back the patch out, and rebuild openssl && all > affected ports - no? You might want to check up on a security list to get a full understanding of the issue, and indeed depending on your application and network you may conclude that the best solution for your environment is to reverse out the patch. However, it's unlikely that the patch will be removed from circulation - most OSes and applications using TLS/SSL are undergoing a similar experience - because the security problem it prevents is both genuine and, as I understand it, an inherent design error in the protocol specification. If you allow renegotiation during the session, you also allow a man-in-the-middle attack to inject arbitrary data into the session. Depending on your app, the likelihood of this could be anywhere from small to huge, and the impact could be anywhere from negligible to disastrous. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 08:33:37 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1125106566C for ; Sat, 19 Dec 2009 08:33:37 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 432CA8FC08 for ; Sat, 19 Dec 2009 08:33:37 +0000 (UTC) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost [IPv6:::1]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.3/8.14.3) with ESMTP id nBJ8XJKH051545; Sat, 19 Dec 2009 08:33:20 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp.infracaninophile.co.uk nBJ8XJKH051545 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=infracaninophile.co.uk; s=200708; t=1261211600; bh=EOr/XwfXnOJZsqNTty/Tnwm+k6O5cI3qWJ6EKkGELVM=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Cc:Content-Type:Date:From:In-Reply-To: Message-ID:Mime-Version:References:To; z=Message-ID:=20<4B2C8FCA.9000105@infracaninophile.co.uk>|Date:=20S at,=2019=20Dec=202009=2008:33:14=20+0000|From:=20Matthew=20Seaman= 20|Organization:=20Infracaninophi le|User-Agent:=20Thunderbird=202.0.0.23=20(X11/20091129)|MIME-Vers ion:=201.0|To:=20Chris=20H=20|CC:=20freebsd-s table@freebsd.org|Subject:=20Re:=20SSL=20appears=20to=20be=20broke n=20in=208-STABLE/RELEASE|References:=20|In-Reply-To:=20|X-Enigmail-Version: =200.95.6|Content-Type:=20multipart/signed=3B=20micalg=3Dpgp-sha25 6=3B=0D=0A=20protocol=3D"application/pgp-signature"=3B=0D=0A=20bou ndary=3D"------------enigE343BE4905A8666D985C072F"; b=YSloiS6QJcDKUGNo0hkfONH6du1LeubdzsMVAqMRoLcSKr9TRgjobYbZHlwmHAhGR nscgrxSie4jEZDPe4B8vWKqv4nYeM4vIqGQ6KyaD3+7NJ1zG8WXQWIfyF+lEWbjO39 NVqrbv1S+yoV57afvpmXV5eiWmIk6j3lr9/LyANg= X-Authentication-Warning: happy-idiot-talk.infracaninophile.co.uk: Host localhost [IPv6:::1] claimed to be happy-idiot-talk.infracaninophile.co.uk Message-ID: <4B2C8FCA.9000105@infracaninophile.co.uk> Date: Sat, 19 Dec 2009 08:33:14 +0000 From: Matthew Seaman Organization: Infracaninophile User-Agent: Thunderbird 2.0.0.23 (X11/20091129) MIME-Version: 1.0 To: Chris H References: In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigE343BE4905A8666D985C072F" X-Virus-Scanned: clamav-milter 0.95.3 at happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VERIFIED,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on happy-idiot-talk.infracaninophile.co.uk Cc: freebsd-stable@freebsd.org Subject: Re: SSL appears to be broken in 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 08:33:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE343BE4905A8666D985C072F Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Chris H wrote: > Greetings, > A recent (cvs checkout of src/ports on 2009-12-09) install of 8 seems = to indicate > that changes in SSL have made it virtually unusable. I've spent the pas= t 3 days > attempting to (re)create an SSL enabled virtual host that serves web ba= sed access > to local mail. Since it's local, I'm using self-signed certs following = a scheme > that > has always worked flawlessly for the past 9 yrs. However, now having in= stalled 8, > it isn't working. The browser(s) throw "ssl_error_handshake_failure_ale= rt" > (ff-3.56). > Other gecko based, and non-gecko based UA's throw similar, as well as o= penssl's > s_client. After immense research, the only thing I can find that might = best explain > it is a recent SA patch applied to FreeBSD's src (SA-09:15). After read= ing what the > patch provides. I am able to better understand the error messages throw= n to > /var/messages when attempting to negotiate a secure session in a UA: Your analysis is correct. You've hit the exact problem used as the test = case in all the investigations into the SSL injection attach mitigated in SA-0= 9:15. Essentially what happens is that your clients make an initial anonymous (= on the=20 client side) connection to the SSL site. Then (as a consequence perhaps = of user actions), the SSL site requires the user side to authenticate itself by p= resenting a certificate. This authentication process entails renegotiating the who= le client -> server SSL connection, and that is precisely what was diked out of openssl-0.9.6m as it is the route to exploiting the security flaw. There is an update to the SSL protocol in the works that will properly cl= ose the vulnerability and still allow useful things like renegotiation -- see=20 https://datatracker.ietf.org/idtracker/draft-ietf-tls-renegotiation/ This has taken what seems like a veritable age for the IETF to process, b= ut in reality it is moving with all dispatch to get the fix in place. So, at the moment, we have a band-aid that fixes the vulnerability, but t= hat breaks some sites. In the future we will have a correct fix that restores the d= esirable functionality. Between now and then, your site is going to have difficul= ties. Options: * Just wait. Leave the site broken (but invulnerable to the attack= ) until the proper fix comes out. I somehow doubt that this will be acc= eptable. * Temporarily (or permanently) switch to some other form of authen= tication than using SSL client certificates. Likely to require significa= nt=20 re-engineering of your site, and probably quite a lot of user re= -education and other chores. * Accept the risk of the SSL injection attack, downrev to openssl-= 0.8.6l and put in place whatever other mitigation you can think of to p= rotect the site. For instance, fire-walling off all access except to k= nown good IP numbers. To find out more about the attack, see Marsh Ray's blog at http://extende= dsubset.com/ which has links to many useful resources. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW --------------enigE343BE4905A8666D985C072F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkssj88ACgkQ8Mjk52CukIwfCwCeIWTQxuxOFOK9yE92ttwNifJO 4ukAn3zBpsJogDrFLD+anNHatkco4T3V =FomH -----END PGP SIGNATURE----- --------------enigE343BE4905A8666D985C072F-- From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 09:29:48 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B3FA1065672 for ; Sat, 19 Dec 2009 09:29:48 +0000 (UTC) (envelope-from hingow@googlemail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id BE7238FC08 for ; Sat, 19 Dec 2009 09:29:47 +0000 (UTC) Received: by fxm27 with SMTP id 27so3493016fxm.3 for ; Sat, 19 Dec 2009 01:29:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=7X9uVjpyU5mRwmI/tLEUbE4fsT0KqyHL/GpApcz91f4=; b=lzY3q5Rrkw8xeEOvEKTjus1P5ZY8B4VHa3VhaE41ZJTF2hUV7IgfJkHjb5Ro4JQ+6j Mpa0RrNTqW+tLnB3D3xCUT0dsBHT3Tx2Mb19ye/fN0xJIoN5740Ewc2nlehFwNYlU68O ui60TigYB/u4hMnapLPSvNCfzuvAwFdph51Hk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HXaVA+Ola3umrujRyXXa4MzZKoAvmEtD63XDO62yEZqJYJe5sKb4UtP7j6b96lXrOB Qldw8UqI7t3ISxatZCCc6RAd6SNuxj8A7iAomII8HpE2Xd8D4j6qy42QiF5ZUVaPRQli 15qUoOaq7/STTOgLpzlf7ABgcq1vrpncQYU5E= MIME-Version: 1.0 Received: by 10.103.76.40 with SMTP id d40mr792475mul.117.1261213129783; Sat, 19 Dec 2009 00:58:49 -0800 (PST) Date: Sat, 19 Dec 2009 09:58:49 +0100 Message-ID: From: "H. Ingow" To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: SSL appears to be broken in 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 09:29:48 -0000 First my apologies for breaking the thread. We also had this issue and tried to find an acceptable solution. To make a long story short: Please try to compile your application against the version of openssl available in the ports tree. As you already mentioned (SA-09:15) breaks renegotiation with base system's openssl by fixing a security issue ( it actually does). Prerequisite for the following is, of course, to install /usr/ports/security/openssl which will give you openssl 0.9.8l . (You do not necessarily have to remove the base openssl) You may then set 'WITH_OPENSSL_PORT=YES' to /etc/make.conf and rebuild your application(s) with via the ports, they should then be compiled correctly against the ports-version. Or, but this will only work if if your application's configure script has a switch to set the path to ssl or openssl to the ports-openssl's location, something like # setenv LD_LIBRARY_PATH /usr/local/lib ## this actually may be removed after build and configure with the appropriate option maybe alike # ./configure --openssl-path=/usr/local/lib Just make sure it compiled properly. The output of ldd should show (apart from other): # ldd application /app/li/cation ...... libssl.so.5 => /usr/local/lib/libssl.so.5 (0x881bc000) libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x88200000) . ........ For the applications we use, this works with both versions of openssl on the same box, without any i interference. Considerations about this ? HTH From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 10:14:10 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC7C8106568B for ; Sat, 19 Dec 2009 10:14:10 +0000 (UTC) (envelope-from mdounin@mdounin.ru) Received: from mdounin.cust.ramtel.ru (mdounin.cust.ramtel.ru [81.19.69.81]) by mx1.freebsd.org (Postfix) with ESMTP id 7DCD68FC0C for ; Sat, 19 Dec 2009 10:14:10 +0000 (UTC) Received: from mdounin.ru (mdounin.cust.ramtel.ru [81.19.69.81]) by mdounin.cust.ramtel.ru (Postfix) with ESMTP id E5D851702A; Sat, 19 Dec 2009 13:14:08 +0300 (MSK) Date: Sat, 19 Dec 2009 13:14:08 +0300 From: Maxim Dounin To: Chris H Message-ID: <20091219101408.GG43547@mdounin.ru> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: SSL appears to be broken in 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 10:14:10 -0000 Hello! On Fri, Dec 18, 2009 at 05:32:41PM -0800, Chris H wrote: > Greetings, > A recent (cvs checkout of src/ports on 2009-12-09) install of 8 seems to indicate > that changes in SSL have made it virtually unusable. I've spent the past 3 days > attempting to (re)create an SSL enabled virtual host that serves web based access > to local mail. Since it's local, I'm using self-signed certs following a scheme > that > has always worked flawlessly for the past 9 yrs. However, now having installed 8, > it isn't working. The browser(s) throw "ssl_error_handshake_failure_alert" > (ff-3.56). > Other gecko based, and non-gecko based UA's throw similar, as well as openssl's > s_client. After immense research, the only thing I can find that might best explain > it is a recent SA patch applied to FreeBSD's src (SA-09:15). After reading what the > patch provides. I am able to better understand the error messages thrown to > /var/messages when attempting to negotiate a secure session in a UA: [...] > So, if I understand things correctly. The patch prevents (re)negotiation. Making > the likelihood of a successful "handshake" near null (as the log messages above > show). I'm sure that some may be quick to point the finger at the self-signed > cert being more likely the cause, I should add that while in fact quite unlikely, > I too didn't completely rule that out. So I purchased one from startssl - money > wasted. The results were the same. So it would appear that until something else > is done to overcome the hole in current openssl, my only recourse is to back the > patch out, and rebuild openssl && all affected ports - no? If you are using Apache as server, you may consider using server-wide SSLVerifyClient (instead of per-location ones which require renegotiation). Maxim Dounin From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 10:31:26 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AECC8106566B for ; Sat, 19 Dec 2009 10:31:26 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (dsl081-172-045.sea1.dsl.speakeasy.net [64.81.172.45]) by mx1.freebsd.org (Postfix) with ESMTP id 60B4C8FC08 for ; Sat, 19 Dec 2009 10:31:26 +0000 (UTC) Received: from webmail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id nBJAUs4O070223 for ; Sat, 19 Dec 2009 02:31:00 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([64.81.172.214]) (Local authenticated user inf0s) by webmail.1command.com with HTTP; Sat, 19 Dec 2009 02:31:24 -0800 (PST) Message-ID: <4633ce386bdc08fa31018598b2457bda.HRCIM@webmail.1command.com> In-Reply-To: <20091219081605.GA23586@lava.net> References: <20091219081605.GA23586@lava.net> Date: Sat, 19 Dec 2009 02:31:24 -0800 (PST) From: "Chris H" To: freebsd-stable@freebsd.org User-Agent: HRC Internet Messaging/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: SSL appears to be broken in 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 10:31:26 -0000 Greetings Clifton, and thank you for your reply. On Sat, December 19, 2009 12:16 am, Clifton Royston wrote: > On Fri, Dec 18, 2009 at 05:32:41PM -0800, Chris H wrote: > >> Greetings, >> A recent (cvs checkout of src/ports on 2009-12-09) install of 8 >> seems to indicate that changes in SSL have made it virtually unusable. I've >> spent the past 3 days attempting to (re)create an SSL enabled virtual host >> that serves web based access to local mail. Since it's local, I'm using >> self-signed certs following a scheme that has always worked flawlessly for the >> past 9 yrs. However, now having installed 8, it isn't working. The browser(s) >> throw "ssl_error_handshake_failure_alert" (ff-3.56). Other gecko based, and >> non-gecko based UA's throw similar, as well as openssl's s_client. After >> immense research, the only thing I can find that might best explain it is a >> recent SA patch applied to FreeBSD's src (SA-09:15). After reading what the >> patch provides. I am able to better understand the error messages thrown to >> /var/messages when attempting to negotiate a secure session in a UA: >> > ... > >> So, if I understand things correctly. The patch prevents >> (re)negotiation. Making the likelihood of a successful "handshake" >> near null (as the log messages above show). I'm sure that some may be quick to >> point the finger at the self-signed cert being more likely the cause, I should >> add that while in fact quite unlikely, I too didn't completely rule that out. >> So I purchased one from startssl - >> money wasted. The results were the same. So it would appear that until >> something else is done to overcome the hole in current openssl, my only >> recourse is to back the patch out, and rebuild openssl && all affected ports - >> no? > > You might want to check up on a security list to get a full > understanding of the issue, and indeed depending on your application and network > you may conclude that the best solution for your environment is to reverse out > the patch. > > However, it's unlikely that the patch will be removed from > circulation - most OSes and applications using TLS/SSL are undergoing a similar > experience - because the security problem it prevents is both genuine and, as I > understand it, an inherent design error in the protocol specification. If you > allow renegotiation during the session, you also allow a man-in-the-middle > attack to inject arbitrary data into the session. Depending on your app, the > likelihood of this could be anywhere from small to huge, and the impact could be > anywhere from negligible to disastrous. Indeed. I /do/ understand that the patch was an effort to thwart a potential "hole" in current openssl's implementation. I also took some time comparing the patch against the code's /former/ state. While the patch /does/ "plug" the hole. It also /nearly/ closes the intended entry point for it's intended target - the client initiating communication. As it is, it /won't/ permit communication as it was intended to. So it can't be used as a reliable protocol for secure communication. I fully realize that the hole needed to be plugged ASAP. But until the source has been "re-worked", it's of nearly no value. I discovered I'm not the only one w/o the ability to use SSL after the "patch". I spent quite some time trying to track down the reason communication shut down immediately after accepting the cert in my UA. Searching the web, and newsgroups indicates that /many/ others are w/o the ability to use SSL for their needs either - unless, reverting to a "pre-patchd" state. Given an extremely reliable DNS, and well secured network, the only immediate solution seems to be to check out the pre-2009-12-03 source, and re-build it, and all affected. Then, of course monitor openssl for a "new improved" version. So as to be able to lift a HOLD on the back-patched version in my current tree. Thank you again Clifton, for taking the time to respond. --Chris H > > -- Clifton > > > -- > Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net > President - I and I Computing * http://www.iandicomputing.com/ > Custom programming, network design, systems and network consulting services > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 10:47:19 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98232106568B for ; Sat, 19 Dec 2009 10:47:19 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (dsl081-172-045.sea1.dsl.speakeasy.net [64.81.172.45]) by mx1.freebsd.org (Postfix) with ESMTP id 4CB028FC17 for ; Sat, 19 Dec 2009 10:47:19 +0000 (UTC) Received: from webmail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id nBJAkkSf070301; Sat, 19 Dec 2009 02:46:52 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([64.81.172.214]) (Local authenticated user inf0s) by webmail.1command.com with HTTP; Sat, 19 Dec 2009 02:47:17 -0800 (PST) Message-ID: <4ed595bc5648ccc655891c275dc2dba8.HRCIM@webmail.1command.com> In-Reply-To: <4B2C8FCA.9000105@infracaninophile.co.uk> References: <4B2C8FCA.9000105@infracaninophile.co.uk> Date: Sat, 19 Dec 2009 02:47:17 -0800 (PST) From: "Chris H" To: freebsd-stable@freebsd.org User-Agent: HRC Internet Messaging/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Subject: Re: SSL appears to be broken in 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 10:47:19 -0000 Greetings Matthew, and thank you very much for your reply. On Sat, December 19, 2009 12:33 am, Matthew Seaman wrote: > Chris H wrote: > >> Greetings, >> A recent (cvs checkout of src/ports on 2009-12-09) install of 8 seems to >> indicate that changes in SSL have made it virtually unusable. I've spent the >> past 3 days attempting to (re)create an SSL enabled virtual host that serves >> web based access to local mail. Since it's local, I'm using self-signed certs >> following a scheme that has always worked flawlessly for the past 9 yrs. >> However, now having installed 8, >> it isn't working. The browser(s) throw "ssl_error_handshake_failure_alert" >> (ff-3.56). >> Other gecko based, and non-gecko based UA's throw similar, as well as >> openssl's s_client. After immense research, the only thing I can find that >> might best explain it is a recent SA patch applied to FreeBSD's src >> (SA-09:15). After reading what the >> patch provides. I am able to better understand the error messages thrown to >> /var/messages when attempting to negotiate a secure session in a UA: >> > > Your analysis is correct. You've hit the exact problem used as the test case > in all the investigations into the SSL injection attach mitigated in SA-09:15. > Essentially what happens is that your clients make an initial anonymous (on the > client side) connection to the SSL site. Then (as a consequence perhaps of > user actions), the SSL site requires the user side to authenticate itself by > presenting a certificate. This authentication process entails renegotiating the > whole client -> server SSL connection, and that is precisely what was diked out > of openssl-0.9.6m as it is the route to exploiting the security flaw. > > There is an update to the SSL protocol in the works that will properly close > the vulnerability and still allow useful things like renegotiation -- see > > https://datatracker.ietf.org/idtracker/draft-ietf-tls-renegotiation/ > > > This has taken what seems like a veritable age for the IETF to process, but in > reality it is moving with all dispatch to get the fix in place. > > So, at the moment, we have a band-aid that fixes the vulnerability, but that > breaks some sites. In the future we will have a correct fix that restores the > desirable functionality. Between now and then, your site is going to have > difficulties. > > Options: > > > * Just wait. Leave the site broken (but invulnerable to the attack) until > the proper fix comes out. I somehow doubt that this will be acceptable. > > * Temporarily (or permanently) switch to some other form of authentication > than using SSL client certificates. Likely to require significant re-engineering > of your site, and probably quite a lot of user re-education and other chores. > > * Accept the risk of the SSL injection attack, downrev to openssl-0.8.6l > and put in place whatever other mitigation you can think of to protect the site. > For instance, fire-walling off all access except to known > good IP numbers. > > To find out more about the attack, see Marsh Ray's blog at > http://extendedsubset.com/ > which has links to many useful resources. > > Cheers, > > > Matthew WOW. I am /extremely/ grateful for your thoughtful, and very informative reply. All points well taken. Given an already well secured network. I'll opt for "door number 3" - back-patch openssl, and flag that section of the tree as HOLD. While closely monitoring openssl for the "new and improved" version. :) In all honesty, I'm quite impressed with openssl - that it took /so/ long for this "hole" to be found. Just wish a better "plug" could have been found during the interim. :) Thank you again Matthew, for taking the time to provide such an informative, and thoughtful response. --Chris H > > > -- > Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard > Flat 3 > PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate > Kent, CT11 9PW > > > From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 10:55:59 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4BE610656ED for ; Sat, 19 Dec 2009 10:55:59 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (dsl081-172-045.sea1.dsl.speakeasy.net [64.81.172.45]) by mx1.freebsd.org (Postfix) with ESMTP id 90F1C8FC0A for ; Sat, 19 Dec 2009 10:55:59 +0000 (UTC) Received: from webmail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id nBJAtRgc070347; Sat, 19 Dec 2009 02:55:33 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([64.81.172.214]) (Local authenticated user inf0s) by webmail.1command.com with HTTP; Sat, 19 Dec 2009 02:55:57 -0800 (PST) Message-ID: <556cc9475b9060a5f228a845dcb54df8.HRCIM@webmail.1command.com> In-Reply-To: References: Date: Sat, 19 Dec 2009 02:55:57 -0800 (PST) From: "Chris H" To: freebsd-stable@freebsd.org User-Agent: HRC Internet Messaging/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit Cc: "H. Ingow" Subject: Re: SSL appears to be broken in 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 10:56:00 -0000 Greetings, and thank you for taking the time to respond. On Sat, December 19, 2009 12:58 am, H. Ingow wrote: > First my apologies for breaking the thread. > We also had this issue and tried to find an acceptable solution. > To make a long story short: > > > Please try to compile your application against the version of openssl > available in the ports tree. > > As you already mentioned (SA-09:15) breaks renegotiation with base system's > openssl by fixing a security issue ( it actually does). > > Prerequisite for the following is, of course, to install > /usr/ports/security/openssl which will give you > openssl 0.9.8l . (You do not necessarily have to remove the base openssl) > > You may then set 'WITH_OPENSSL_PORT=YES' to /etc/make.conf > and rebuild your application(s) with via the ports, they should then be compiled > correctly against the ports-version. > > Or, but this will only work if if your application's configure script has a > switch to set the path to ssl or openssl to the ports-openssl's location, > something like > > # setenv LD_LIBRARY_PATH /usr/local/lib ## this actually may be > removed after build > > and configure with the appropriate option maybe alike > > # ./configure --openssl-path=/usr/local/lib > > > Just make sure it compiled properly. > The output of ldd should show (apart from other): > # ldd application > /app/li/cation > ...... > libssl.so.5 => /usr/local/lib/libssl.so.5 (0x881bc000) libcrypto.so.5 => > /usr/local/lib/libcrypto.so.5 (0x88200000) > . ........ > > > For the applications we use, this works with both versions of openssl on the > same box, without any i interference. Excellent suggestion! I hadn't /yet/ compared the ports version against base. Your suggestion has a great deal less overhead than my initial thoughts to "back-patch" to pre-2009-12-03-openssl, and flagging that portion of the tree as HOLD. I like your suggestion /much/ better. Thank you very much for taking the time to share it. :) Best wishes. --Chris H > > Considerations about this ? > > > HTH > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 11:13:41 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D78901065692 for ; Sat, 19 Dec 2009 11:13:41 +0000 (UTC) (envelope-from mdounin@mdounin.ru) Received: from mdounin.cust.ramtel.ru (mdounin.cust.ramtel.ru [81.19.69.81]) by mx1.freebsd.org (Postfix) with ESMTP id 971328FC14 for ; Sat, 19 Dec 2009 11:13:41 +0000 (UTC) Received: from mdounin.ru (mdounin.cust.ramtel.ru [81.19.69.81]) by mdounin.cust.ramtel.ru (Postfix) with ESMTP id 699CD1702A; Sat, 19 Dec 2009 14:13:40 +0300 (MSK) Date: Sat, 19 Dec 2009 14:13:40 +0300 From: Maxim Dounin To: "H. Ingow" Message-ID: <20091219111339.GH43547@mdounin.ru> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: SSL appears to be broken in 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 11:13:41 -0000 Hello! On Sat, Dec 19, 2009 at 09:58:49AM +0100, H. Ingow wrote: [...] > Please try to compile your application against the version of openssl > available in the ports tree. > > As you already mentioned (SA-09:15) breaks renegotiation with base system's > openssl by fixing > a security issue ( it actually does). > > Prerequisite for the following is, of course, to install > /usr/ports/security/openssl which will give you > openssl 0.9.8l . (You do not necessarily have to remove the base openssl) OpenSSL 0.9.8l has renegotiation disabled too, this won't help. The only difference is that 0.9.8l has some means to re-enable legacy renegotiation which may be utilized by applications which are aware of the problem. Maxim Dounin From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 11:18:24 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E8E51065672 for ; Sat, 19 Dec 2009 11:18:24 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (dsl081-172-045.sea1.dsl.speakeasy.net [64.81.172.45]) by mx1.freebsd.org (Postfix) with ESMTP id 48ED88FC16 for ; Sat, 19 Dec 2009 11:18:23 +0000 (UTC) Received: from webmail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id nBJBHqSZ078232 for ; Sat, 19 Dec 2009 03:17:58 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([64.81.172.214]) (Local authenticated user inf0s) by webmail.1command.com with HTTP; Sat, 19 Dec 2009 03:18:21 -0800 (PST) Message-ID: In-Reply-To: <20091219101408.GG43547@mdounin.ru> References: <20091219101408.GG43547@mdounin.ru> Date: Sat, 19 Dec 2009 03:18:21 -0800 (PST) From: "Chris H" To: freebsd-stable@freebsd.org User-Agent: HRC Internet Messaging/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: SSL appears to be broken in 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 11:18:24 -0000 Hello Maxim, and thank you for taking the time to reply. On Sat, December 19, 2009 2:14 am, Maxim Dounin wrote: > Hello! > > > On Fri, Dec 18, 2009 at 05:32:41PM -0800, Chris H wrote: > > >> Greetings, >> A recent (cvs checkout of src/ports on 2009-12-09) install of 8 seems to >> indicate that changes in SSL have made it virtually unusable. I've spent the >> past 3 days attempting to (re)create an SSL enabled virtual host that serves >> web based access to local mail. Since it's local, I'm using self-signed certs >> following a scheme that has always worked flawlessly for the past 9 yrs. >> However, now having installed 8, >> it isn't working. The browser(s) throw "ssl_error_handshake_failure_alert" >> (ff-3.56). >> Other gecko based, and non-gecko based UA's throw similar, as well as >> openssl's s_client. After immense research, the only thing I can find that >> might best explain it is a recent SA patch applied to FreeBSD's src >> (SA-09:15). After reading what the >> patch provides. I am able to better understand the error messages thrown to >> /var/messages when attempting to negotiate a secure session in a UA: >> > > [...] > > >> So, if I understand things correctly. The patch prevents (re)negotiation. >> Making >> the likelihood of a successful "handshake" near null (as the log messages >> above show). I'm sure that some may be quick to point the finger at the >> self-signed cert being more likely the cause, I should add that while in fact >> quite unlikely, I too didn't completely rule that out. So I purchased one from >> startssl - money wasted. The results were the same. So it would appear that >> until something else is done to overcome the hole in current openssl, my only >> recourse is to back the patch out, and rebuild openssl && all affected ports - >> no? > > If you are using Apache as server, you may consider using > server-wide SSLVerifyClient (instead of per-location ones which require > renegotiation). Indeed. I tried that on an Apache server, but "no joy". :( SSLVerifyClient provides the following options: 0 - Verify the client:no 1 - Verify the client:optional 2 - Verify the client:required 3 - Verify the client:required - but CA is optional However, none of the options worked - even with the purchased cert. The problem appears (after examining the patch), is that it is not possible to be presented with the option to accept the cert, and /then/ continue with the session. As it is, you are permitted to initiate communication, but /any/ "decision making" may /only/ be made to determine a mutually acceptable crypt - eg; AES;DES;ETC... So Apache (or any other cryptographically aware server) using /current/ openssl, has no say in the matter - period. Thanks again Maxim, for your thoughtful reply. --Chris H > > Maxim Dounin > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 11:24:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F239106566C for ; Sat, 19 Dec 2009 11:24:00 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (dsl081-172-045.sea1.dsl.speakeasy.net [64.81.172.45]) by mx1.freebsd.org (Postfix) with ESMTP id 0B5658FC18 for ; Sat, 19 Dec 2009 11:23:59 +0000 (UTC) Received: from webmail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id nBJBNoWl078270 for ; Sat, 19 Dec 2009 03:23:57 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([64.81.172.214]) (Local authenticated user inf0s) by webmail.1command.com with HTTP; Sat, 19 Dec 2009 03:23:57 -0800 (PST) Message-ID: <0edc3b334fc301f51193354f7a0da61b.HRCIM@webmail.1command.com> In-Reply-To: <20091219111339.GH43547@mdounin.ru> References: <20091219111339.GH43547@mdounin.ru> Date: Sat, 19 Dec 2009 03:23:57 -0800 (PST) From: "Chris H" To: freebsd-stable@freebsd.org User-Agent: HRC Internet Messaging/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: SSL appears to be broken in 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 11:24:00 -0000 On Sat, December 19, 2009 3:13 am, Maxim Dounin wrote: > Hello! > > > On Sat, Dec 19, 2009 at 09:58:49AM +0100, H. Ingow wrote: > > > [...] > > >> Please try to compile your application against the version of openssl >> available in the ports tree. >> >> As you already mentioned (SA-09:15) breaks renegotiation with base system's >> openssl by fixing a security issue ( it actually does). >> >> Prerequisite for the following is, of course, to install >> /usr/ports/security/openssl which will give you >> openssl 0.9.8l . (You do not necessarily have to remove the base openssl) > > OpenSSL 0.9.8l has renegotiation disabled too, this won't help. > > > The only difference is that 0.9.8l has some means to re-enable > legacy renegotiation which may be utilized by applications which are aware of the > problem. Which is exactly what's required to implement your previous suggestion. :) --Chris H > > Maxim Dounin > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 11:54:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E54C5106566B for ; Sat, 19 Dec 2009 11:54:26 +0000 (UTC) (envelope-from mdounin@mdounin.ru) Received: from mdounin.cust.ramtel.ru (mdounin.cust.ramtel.ru [81.19.69.81]) by mx1.freebsd.org (Postfix) with ESMTP id A29858FC19 for ; Sat, 19 Dec 2009 11:54:26 +0000 (UTC) Received: from mdounin.ru (mdounin.cust.ramtel.ru [81.19.69.81]) by mdounin.cust.ramtel.ru (Postfix) with ESMTP id 29E821702A; Sat, 19 Dec 2009 14:54:24 +0300 (MSK) Date: Sat, 19 Dec 2009 14:54:24 +0300 From: Maxim Dounin To: Chris H Message-ID: <20091219115424.GI43547@mdounin.ru> References: <20091219101408.GG43547@mdounin.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: SSL appears to be broken in 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 11:54:27 -0000 Hello! On Sat, Dec 19, 2009 at 03:18:21AM -0800, Chris H wrote: > Hello Maxim, and thank you for taking the time to reply. > On Sat, December 19, 2009 2:14 am, Maxim Dounin wrote: > > Hello! > > > > > > On Fri, Dec 18, 2009 at 05:32:41PM -0800, Chris H wrote: > > > > > >> Greetings, > >> A recent (cvs checkout of src/ports on 2009-12-09) install of 8 seems to > >> indicate that changes in SSL have made it virtually unusable. I've spent the > >> past 3 days attempting to (re)create an SSL enabled virtual host that serves > >> web based access to local mail. Since it's local, I'm using self-signed certs > >> following a scheme that has always worked flawlessly for the past 9 yrs. > >> However, now having installed 8, > >> it isn't working. The browser(s) throw "ssl_error_handshake_failure_alert" > >> (ff-3.56). > >> Other gecko based, and non-gecko based UA's throw similar, as well as > >> openssl's s_client. After immense research, the only thing I can find that > >> might best explain it is a recent SA patch applied to FreeBSD's src > >> (SA-09:15). After reading what the > >> patch provides. I am able to better understand the error messages thrown to > >> /var/messages when attempting to negotiate a secure session in a UA: > >> > > > > [...] > > > > > >> So, if I understand things correctly. The patch prevents (re)negotiation. > >> Making > >> the likelihood of a successful "handshake" near null (as the log messages > >> above show). I'm sure that some may be quick to point the finger at the > >> self-signed cert being more likely the cause, I should add that while in fact > >> quite unlikely, I too didn't completely rule that out. So I purchased one from > >> startssl - money wasted. The results were the same. So it would appear that > >> until something else is done to overcome the hole in current openssl, my only > >> recourse is to back the patch out, and rebuild openssl && all affected ports - > >> no? > > > > If you are using Apache as server, you may consider using > > server-wide SSLVerifyClient (instead of per-location ones which require > > renegotiation). > Indeed. I tried that on an Apache server, but "no joy". :( > > SSLVerifyClient provides the following options: > 0 - Verify the client:no > 1 - Verify the client:optional > 2 - Verify the client:required > 3 - Verify the client:required - but CA is optional > > However, none of the options worked - even with the purchased cert. It doesn't matter what you specify in option. The thing that matters is where you specify option itself. The following won't work: ... SSLVerifyClient required as SSLVerifyClient in Location context requires renegotiation. But moving it to VirtualHost level should resolve the issue, as certificate exchange will happen in initial handshake. The following should work: ... SSLVerifyClient required [...] Maxim Dounin From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 12:29:16 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2FAE1065694 for ; Sat, 19 Dec 2009 12:29:16 +0000 (UTC) (envelope-from mdounin@mdounin.ru) Received: from mdounin.cust.ramtel.ru (mdounin.cust.ramtel.ru [81.19.69.81]) by mx1.freebsd.org (Postfix) with ESMTP id B0D438FC0C for ; Sat, 19 Dec 2009 12:29:16 +0000 (UTC) Received: from mdounin.ru (mdounin.cust.ramtel.ru [81.19.69.81]) by mdounin.cust.ramtel.ru (Postfix) with ESMTP id 9453E1702A; Sat, 19 Dec 2009 15:29:14 +0300 (MSK) Date: Sat, 19 Dec 2009 15:29:14 +0300 From: Maxim Dounin To: Chris H Message-ID: <20091219122914.GJ43547@mdounin.ru> References: <20091219111339.GH43547@mdounin.ru> <0edc3b334fc301f51193354f7a0da61b.HRCIM@webmail.1command.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0edc3b334fc301f51193354f7a0da61b.HRCIM@webmail.1command.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: SSL appears to be broken in 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 12:29:17 -0000 Hello! On Sat, Dec 19, 2009 at 03:23:57AM -0800, Chris H wrote: > On Sat, December 19, 2009 3:13 am, Maxim Dounin wrote: > > Hello! > > > > > > On Sat, Dec 19, 2009 at 09:58:49AM +0100, H. Ingow wrote: > > > > > > [...] > > > > > >> Please try to compile your application against the version of openssl > >> available in the ports tree. > >> > >> As you already mentioned (SA-09:15) breaks renegotiation with base system's > >> openssl by fixing a security issue ( it actually does). > >> > >> Prerequisite for the following is, of course, to install > >> /usr/ports/security/openssl which will give you > >> openssl 0.9.8l . (You do not necessarily have to remove the base openssl) > > > > OpenSSL 0.9.8l has renegotiation disabled too, this won't help. > > > > > > The only difference is that 0.9.8l has some means to re-enable > > legacy renegotiation which may be utilized by applications which are aware of the > > problem. > Which is exactly what's required to implement your previous suggestion. :) No, my previous suggestion is unrelated. Additionally, to re-enable renegotiation in openssl 0.9.8l you need an application which is able to set SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION in s->s3->flags. I haven't seen any yet, and google codesearch is able to find only one such app (proftpd). Maxim Dounin From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 13:13:47 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E21F61065692 for ; Sat, 19 Dec 2009 13:13:46 +0000 (UTC) (envelope-from hingow@googlemail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 6D3B58FC1E for ; Sat, 19 Dec 2009 13:13:45 +0000 (UTC) Received: by fxm27 with SMTP id 27so3577586fxm.3 for ; Sat, 19 Dec 2009 05:13:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=xatjy+Z8Sq3wio8w7kbzIZiox8kDZGRag7FulRoV2nk=; b=Bq3SQN4Iw7ZuU/qf95/dJn/AqtpvRqqUUOVVaB+wV53IY2CKIBussX7mc8FE4Ysezu cVWbW57YRhN9ci92u5XSw7KzpgrHzRAyF4mzm5ooVUbrAzS+ybI095eVMO9bzrgSsulR a2AaOVr2EKoRgSVozl5qh132sYgjValV+P2iY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TH7BkDwwxXuM8kA+f2SiVs+OGfwg+xrRpgIlNtpdkfAgR6+q3NgYhinhm4D4z0NMGh i3HHie+8cvNSdtcCt6CPonz6/DBMLoMwUbcwi/qSuKvLKaYgcVMNv+ovtPd75e7zhHWV IAZNfL9Xa20twYm48nQa2GRFjjlqjgu7MvDNI= MIME-Version: 1.0 Received: by 10.103.76.40 with SMTP id d40mr879488mul.117.1261228425070; Sat, 19 Dec 2009 05:13:45 -0800 (PST) In-Reply-To: <20091219122914.GJ43547@mdounin.ru> References: <20091219111339.GH43547@mdounin.ru> <0edc3b334fc301f51193354f7a0da61b.HRCIM@webmail.1command.com> <20091219122914.GJ43547@mdounin.ru> Date: Sat, 19 Dec 2009 14:13:45 +0100 Message-ID: From: "H. Ingow" To: Maxim Dounin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, Chris H Subject: Re: SSL appears to be broken in 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 13:13:47 -0000 Sorry if my proposal won't fit in this case and thanks, Maxim for clearing out what exactly to be aware of to have applications run with openssl .0.9.8l But for the sake of completeness /usr/ports/security/tor-devel is very well capable of handling re-negotiation. see src/common/tortls.c and grep for ALLOW_UNSAFE_LEGACY_RENEGOTIATION you'll get [......] #ifdef SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION /* Yes, we know what we are doing here. No, we do not treat a renegotiation * as authenticating any earlier-received data. */ tls->ssl->s3->flags |= SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION; #else (void)tls; #endif [.....] and#ifdef SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION tls->ssl->s3->flags&=~SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION; #else (void)tls; #endif [.....] So that' the second one . Hopefully more to come . Sorry for the confusion I may have caused, but it was tempting to believe it was easy dealing with hat matter. On 12/19/09, Maxim Dounin wrote: > Hello! > > On Sat, Dec 19, 2009 at 03:23:57AM -0800, Chris H wrote: > >> On Sat, December 19, 2009 3:13 am, Maxim Dounin wrote: >> > Hello! >> > >> > >> > On Sat, Dec 19, 2009 at 09:58:49AM +0100, H. Ingow wrote: >> > >> > >> > [...] >> > >> > >> >> Please try to compile your application against the version of openssl >> >> available in the ports tree. >> >> >> >> As you already mentioned (SA-09:15) breaks renegotiation with base >> >> system's >> >> openssl by fixing a security issue ( it actually does). >> >> >> >> Prerequisite for the following is, of course, to install >> >> /usr/ports/security/openssl which will give you >> >> openssl 0.9.8l . (You do not necessarily have to remove the base >> >> openssl) >> > >> > OpenSSL 0.9.8l has renegotiation disabled too, this won't help. >> > >> > >> > The only difference is that 0.9.8l has some means to re-enable >> > legacy renegotiation which may be utilized by applications which are >> > aware of the >> > problem. >> Which is exactly what's required to implement your previous suggestion. :) > > No, my previous suggestion is unrelated. > > Additionally, to re-enable renegotiation in openssl 0.9.8l you > need an application which is able to set > SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION in s->s3->flags. I > haven't seen any yet, and google codesearch is able > to find only one such app (proftpd). > > Maxim Dounin > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 13:21:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E08F106568F for ; Sat, 19 Dec 2009 13:21:00 +0000 (UTC) (envelope-from sean@gothic.net.au) Received: from visi.gothic.net.au (visi.gothic.net.au [115.64.131.102]) by mx1.freebsd.org (Postfix) with ESMTP id C59A38FC0A for ; Sat, 19 Dec 2009 13:20:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by visi.gothic.net.au (Postfix) with SMTP id 084BEE4B2; Sun, 20 Dec 2009 00:20:57 +1100 (EST) Received: from sean-macbook.gothic.net.au (sean-macbook.gothic.net.au [10.168.1.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sean) by visi.gothic.net.au (Postfix) with ESMTPSA id 73E5AE4B0; Sun, 20 Dec 2009 00:20:57 +1100 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Sean In-Reply-To: <20091219122914.GJ43547@mdounin.ru> Date: Sun, 20 Dec 2009 00:20:56 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <843DDCC0-9A02-40BD-BCD2-931F9A874C15@gothic.net.au> References: <20091219111339.GH43547@mdounin.ru> <0edc3b334fc301f51193354f7a0da61b.HRCIM@webmail.1command.com> <20091219122914.GJ43547@mdounin.ru> To: Maxim Dounin X-Mailer: Apple Mail (2.1077) Cc: freebsd-stable@freebsd.org Subject: Re: SSL appears to be broken in 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 13:21:00 -0000 On 19/12/2009, at 11:29 PM, Maxim Dounin wrote: >=20 > No, my previous suggestion is unrelated. >=20 > Additionally, to re-enable renegotiation in openssl 0.9.8l you=20 > need an application which is able to set=20 > SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION in s->s3->flags. I=20 > haven't seen any yet, and google codesearch is able=20 > to find only one such app (proftpd). >=20 Unrelated to the issue at hand with Apache, but tor is also broken by = it, as it renegotiates the connection. tor-devel using openssl 0.9.8l sets the flag, and always used = renegotiate safely (ie. by disregarding anything which occured prior to = the renegotiation) which Apache doesn't. > Maxim Dounin > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 13:23:55 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25F2B106566C for ; Sat, 19 Dec 2009 13:23:55 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (dsl081-172-045.sea1.dsl.speakeasy.net [64.81.172.45]) by mx1.freebsd.org (Postfix) with ESMTP id CD7EB8FC18 for ; Sat, 19 Dec 2009 13:23:54 +0000 (UTC) Received: from webmail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id nBJDNOUU078867 for ; Sat, 19 Dec 2009 05:23:30 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([64.81.172.214]) (Local authenticated user inf0s) by webmail.1command.com with HTTP; Sat, 19 Dec 2009 05:23:53 -0800 (PST) Message-ID: In-Reply-To: <20091219115424.GI43547@mdounin.ru> References: <20091219101408.GG43547@mdounin.ru> <20091219115424.GI43547@mdounin.ru> Date: Sat, 19 Dec 2009 05:23:53 -0800 (PST) From: "Chris H" To: freebsd-stable@freebsd.org User-Agent: HRC Internet Messaging/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: SSL appears to be broken in 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 13:23:55 -0000 Hello Maxim, and thank you again for your reply. On Sat, December 19, 2009 3:54 am, Maxim Dounin wrote: > Hello! > > > On Sat, Dec 19, 2009 at 03:18:21AM -0800, Chris H wrote: > > >> Hello Maxim, and thank you for taking the time to reply. >> On Sat, December 19, 2009 2:14 am, Maxim Dounin wrote: >> >>> Hello! >>> >>> >>> >>> On Fri, Dec 18, 2009 at 05:32:41PM -0800, Chris H wrote: >>> >>> >>> >>>> Greetings, >>>> A recent (cvs checkout of src/ports on 2009-12-09) install of 8 seems to >>>> indicate that changes in SSL have made it virtually unusable. I've spent >>>> the past 3 days attempting to (re)create an SSL enabled virtual host that >>>> serves web based access to local mail. Since it's local, I'm using >>>> self-signed certs following a scheme that has always worked flawlessly for >>>> the past 9 yrs. However, now having installed 8, >>>> it isn't working. The browser(s) throw "ssl_error_handshake_failure_alert" >>>> (ff-3.56). >>>> Other gecko based, and non-gecko based UA's throw similar, as well as >>>> openssl's s_client. After immense research, the only thing I can find that >>>> might best explain it is a recent SA patch applied to FreeBSD's src >>>> (SA-09:15). After reading what the >>>> patch provides. I am able to better understand the error messages thrown >>>> to /var/messages when attempting to negotiate a secure session in a UA: >>>> >>>> >>> >>> [...] >>> >>> >>> >>>> So, if I understand things correctly. The patch prevents (re)negotiation. >>>> Making >>>> the likelihood of a successful "handshake" near null (as the log messages >>>> above show). I'm sure that some may be quick to point the finger at the >>>> self-signed cert being more likely the cause, I should add that while in >>>> fact quite unlikely, I too didn't completely rule that out. So I purchased >>>> one from startssl - money wasted. The results were the same. So it would >>>> appear that until something else is done to overcome the hole in current >>>> openssl, my only recourse is to back the patch out, and rebuild openssl && >>>> all affected ports - no? >>> >>> If you are using Apache as server, you may consider using >>> server-wide SSLVerifyClient (instead of per-location ones which require >>> renegotiation). >> Indeed. I tried that on an Apache server, but "no joy". :( >> >> >> SSLVerifyClient provides the following options: >> 0 - Verify the client:no 1 - Verify the client:optional >> 2 - Verify the client:required >> 3 - Verify the client:required - but CA is optional >> >> >> However, none of the options worked - even with the purchased cert. >> > > It doesn't matter what you specify in option. The thing that > matters is where you specify option itself. > > The following won't work: > > > > ... > > SSLVerifyClient required > > > > > as SSLVerifyClient in Location context requires renegotiation. But moving it to > VirtualHost level should resolve the issue, as > certificate exchange will happen in initial handshake. The following should > work: > > > > ... > SSLVerifyClient required > > > > [...] Indeed. I understand that. In fact my OP (original post) indicated my use was in a "vhost" - eg; NameVirtualHost host.ip.add.ress:443 SSLEnable SSLVerifyClient (options 0-3;none work) SSLRequireSSL SSLNoV2 SSLCACertificatePath /path/to/ca-file SSLCertificateFile /path/to/cert-file SSLCertificateKeyFile /path/to/key-file [...] Thank you again Maxim, for taking the time to respond. --Chris H > > > Maxim Dounin > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 13:35:12 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46775106566C for ; Sat, 19 Dec 2009 13:35:12 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 05B018FC14 for ; Sat, 19 Dec 2009 13:35:11 +0000 (UTC) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id nBJDZBGr005687 for ; Sat, 19 Dec 2009 05:35:11 -0800 (PST) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id nBJDZBoY005686 for stable@freebsd.org; Sat, 19 Dec 2009 05:35:11 -0800 (PST) (envelope-from david) Date: Sat, 19 Dec 2009 05:35:11 -0800 From: David Wolfskill To: stable@freebsd.org Message-ID: <20091219133511.GI470@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , stable@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l06SQqiZYCi8rTKz" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Failure during GENERIC (i386) kernel build at r200721 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 13:35:12 -0000 --l06SQqiZYCi8rTKz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Attempted clean kernel build, running FreeBSD freebeast.catwhisker.org 7.2-STABLE FreeBSD 7.2-STABLE #11 r200664:= Fri Dec 18 05:18:46 PST 2009 root@freebeast.catwhisker.org:/common/S2/= obj/usr/src/sys/GENERIC i386 [Immediately following a "make buldworld"...] >>> Kernel build for GENERIC started on Sat Dec 19 05:05:56 PST 2009 =2E.. >>> stage 3.2: building everything =2E.. cc -c -O -pipe -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs -Wst= rict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual = -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sy= s -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inclu= de opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growt= h=3D100 --param large-function-growth=3D1000 -mno-align-long-strings -mpre= ferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3= -ffreestanding -Werror /usr/src/sys/i386/i386/machdep.c cc -c -O -pipe -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs -Wst= rict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual = -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sy= s -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inclu= de opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growt= h=3D100 --param large-function-growth=3D1000 -mno-align-long-strings -mpre= ferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3= -ffreestanding -Werror /usr/src/sys/i386/i386/mca.c cc1: warnings being treated as errors /usr/src/sys/i386/i386/mca.c: In function 'mca_init': /usr/src/sys/i386/i386/mca.c:510: warning: implicit declaration of function= 'CPUID_TO_FAMILY' /usr/src/sys/i386/i386/mca.c:510: warning: nested extern declaration of 'CP= UID_TO_FAMILY' /usr/src/sys/i386/i386/mca.c:511: warning: implicit declaration of function= 'CPUID_TO_MODEL' /usr/src/sys/i386/i386/mca.c:511: warning: nested extern declaration of 'CP= UID_TO_MODEL' *** Error code 1 Stop in /common/S2/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. As a reality check: freebeast(7.2-S)[8] cd /usr/src freebeast(7.2-S)[9] grep -wnr CPUID_TO_FAMILY . =2E/sys/i386/i386/.svn/text-base/mca.c.svn-base:510: = if (i =3D=3D 0 && CPUID_TO_FAMILY(cpu_id) =3D=3D 0x6 =2E/sys/i386/i386/.svn/text-base/mca.c.svn-base:515: = if (i =3D=3D 4 && CPUID_TO_FAMILY(cpu_id) >=3D 0xf) =2E/sys/i386/i386/mca.c:510: if (i =3D=3D 0 &&= CPUID_TO_FAMILY(cpu_id) =3D=3D 0x6 =2E/sys/i386/i386/mca.c:515: if (i =3D=3D 4 &&= CPUID_TO_FAMILY(cpu_id) >=3D 0xf) =2E/sys/amd64/amd64/.svn/text-base/mca.c.svn-base:510: = if (i =3D=3D 0 && CPUID_TO_FAMILY(cpu_id) =3D=3D 0x6 =2E/sys/amd64/amd64/.svn/text-base/mca.c.svn-base:515: = if (i =3D=3D 4 && CPUID_TO_FAMILY(cpu_id) >=3D 0xf) =2E/sys/amd64/amd64/mca.c:510: if (i =3D=3D 0 &&= CPUID_TO_FAMILY(cpu_id) =3D=3D 0x6 =2E/sys/amd64/amd64/mca.c:515: if (i =3D=3D 4 &&= CPUID_TO_FAMILY(cpu_id) >=3D 0xf) freebeast(7.2-S)[10]=20 [cut/pasted, so whitespace may not match]. Was a definition or two overlooked? Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --l06SQqiZYCi8rTKz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkss1o4ACgkQmprOCmdXAD3YkACeMU0FSamBrgLzNZZzVQ9nhGzE ujMAn3j6M/pbIS6GaGe70tWbCt/hclyo =az/6 -----END PGP SIGNATURE----- --l06SQqiZYCi8rTKz-- From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 13:50:12 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB56A1065670 for ; Sat, 19 Dec 2009 13:50:12 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 8FFE18FC0C for ; Sat, 19 Dec 2009 13:50:12 +0000 (UTC) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id nBJDoCUb005736 for ; Sat, 19 Dec 2009 05:50:12 -0800 (PST) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id nBJDoCbY005735 for stable@freebsd.org; Sat, 19 Dec 2009 05:50:12 -0800 (PST) (envelope-from david) Date: Sat, 19 Dec 2009 05:50:12 -0800 From: David Wolfskill To: stable@freebsd.org Message-ID: <20091219135012.GJ470@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , stable@freebsd.org References: <20091219133511.GI470@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vs0rQTeTompTJjtd" Content-Disposition: inline In-Reply-To: <20091219133511.GI470@bunrab.catwhisker.org> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: Failure during GENERIC (i386) kernel build at r200721 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 13:50:12 -0000 --vs0rQTeTompTJjtd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I looked in my stbale/8 sources for comparison and found the definition of CPUID_TO_FAMILY in sys/i386/include/specialreg.h. Here's a diff comparing the stable/7 vs. the stable/8 versions of that file: --- /usr/src/sys/i386/include/specialreg.h 2009-12-09 04:36:55.000000000 -0= 800 +++ sys/i386/include/specialreg.h 2009-12-09 05:39:17.000000000 -0800 @@ -27,7 +27,7 @@ * SUCH DAMAGE. * * from: @(#)specialreg.h 7.1 (Berkeley) 5/9/91 - * $FreeBSD: stable/7/sys/i386/include/specialreg.h 200263 2009-12-08 15:2= 9:12Z avg $ + * $FreeBSD: stable/8/sys/i386/include/specialreg.h 200262 2009-12-08 15:2= 7:06Z avg $ */ =20 #ifndef _MACHINE_SPECIALREG_H_ @@ -166,11 +166,11 @@ #define CPUID_FAMILY 0x00000f00 #define CPUID_EXT_MODEL 0x000f0000 #define CPUID_EXT_FAMILY 0x0ff00000 -#define I386_CPU_MODEL(id) \ +#define CPUID_TO_MODEL(id) \ ((((id) & CPUID_MODEL) >> 4) | \ ((((id) & CPUID_FAMILY) >=3D 0x600) ? \ (((id) & CPUID_EXT_MODEL) >> 12) : 0)) -#define I386_CPU_FAMILY(id) \ +#define CPUID_TO_FAMILY(id) \ ((((id) & CPUID_FAMILY) >> 8) + \ ((((id) & CPUID_FAMILY) =3D=3D 0xf00) ? \ (((id) & CPUID_EXT_FAMILY) >> 20) : 0)) @@ -183,6 +183,13 @@ #define CPUID_HTT_CORES 0x00ff0000 #define CPUID_LOCAL_APIC_ID 0xff000000 =20 +/*=20 + * CPUID instruction 0xb ebx info. + */ +#define CPUID_TYPE_INVAL 0 +#define CPUID_TYPE_SMT 1 +#define CPUID_TYPE_CORE 2 + /* * AMD extended function 8000_0007h edx info */ Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --vs0rQTeTompTJjtd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkss2hMACgkQmprOCmdXAD3S+QCcD7abM2rJWSKnCUYfNrawjh/M cNsAn0nl/U0lPOnBxBCDzVO6xpKztKpH =ge/w -----END PGP SIGNATURE----- --vs0rQTeTompTJjtd-- From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 13:54:44 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4BD61065670 for ; Sat, 19 Dec 2009 13:54:44 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (dsl081-172-045.sea1.dsl.speakeasy.net [64.81.172.45]) by mx1.freebsd.org (Postfix) with ESMTP id 819398FC18 for ; Sat, 19 Dec 2009 13:54:44 +0000 (UTC) Received: from webmail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id nBJDsalX078993 for ; Sat, 19 Dec 2009 05:54:42 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([64.81.172.214]) (Local authenticated user inf0s) by webmail.1command.com with HTTP; Sat, 19 Dec 2009 05:54:42 -0800 (PST) Message-ID: <89caec87156a8a9f169aced430d2883a.HRCIM@webmail.1command.com> In-Reply-To: <20091219133511.GI470@bunrab.catwhisker.org> References: <20091219133511.GI470@bunrab.catwhisker.org> Date: Sat, 19 Dec 2009 05:54:42 -0800 (PST) From: "Chris H" To: freebsd-stable@freebsd.org User-Agent: HRC Internet Messaging/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: Failure during GENERIC (i386) kernel build at r200721 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 13:54:44 -0000 On Sat, December 19, 2009 5:35 am, David Wolfskill wrote: > Attempted clean kernel build, running > > > FreeBSD freebeast.catwhisker.org 7.2-STABLE FreeBSD 7.2-STABLE #11 r200664: Fri > Dec 18 05:18:46 PST 2009 > root@freebeast.catwhisker.org:/common/S2/obj/usr/src/sys/GENERIC i386 > > > [Immediately following a "make buldworld"...] > >>>> Kernel build for GENERIC started on Sat Dec 19 05:05:56 PST 2009 >>>> > ... > >>>> stage 3.2: building everything > ... > cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual ---8<---8<---[big snip]---8<---8<--- Greetings, What are the chances you made no declaration as to your CPU type in your KERNCONF? eg; 1386 HTH --Chris H > > > Was a definition or two overlooked? > > > Peace, > david -- > David H. Wolfskill david@catwhisker.org > Depriving a girl or boy of an opportunity for education is evil. > > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > > From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 14:05:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 888A81065679 for ; Sat, 19 Dec 2009 14:05:35 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (dsl081-172-045.sea1.dsl.speakeasy.net [64.81.172.45]) by mx1.freebsd.org (Postfix) with ESMTP id 4FCF88FC08 for ; Sat, 19 Dec 2009 14:05:35 +0000 (UTC) Received: from webmail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id nBJE5RPG079080 for ; Sat, 19 Dec 2009 06:05:33 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([64.81.172.214]) (Local authenticated user inf0s) by webmail.1command.com with HTTP; Sat, 19 Dec 2009 06:05:33 -0800 (PST) Message-ID: <3348649efcb82ef4d7e26b74b8621a42.HRCIM@webmail.1command.com> In-Reply-To: <89caec87156a8a9f169aced430d2883a.HRCIM@webmail.1command.com> References: <20091219133511.GI470@bunrab.catwhisker.org> <89caec87156a8a9f169aced430d2883a.HRCIM@webmail.1command.com> Date: Sat, 19 Dec 2009 06:05:33 -0800 (PST) From: "Chris H" To: freebsd-stable@freebsd.org User-Agent: HRC Internet Messaging/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: Failure during GENERIC (i386) kernel build at r200721 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 14:05:35 -0000 On Sat, December 19, 2009 5:54 am, Chris H wrote: > On Sat, December 19, 2009 5:35 am, David Wolfskill wrote: > >> Attempted clean kernel build, running >> >> >> >> FreeBSD freebeast.catwhisker.org 7.2-STABLE FreeBSD 7.2-STABLE #11 r200664: >> Fri >> Dec 18 05:18:46 PST 2009 >> root@freebeast.catwhisker.org:/common/S2/obj/usr/src/sys/GENERIC i386 >> >> >> >> [Immediately following a "make buldworld"...] >> >> >>>>> Kernel build for GENERIC started on Sat Dec 19 05:05:56 PST 2009 >>>>> >>>>> >> ... >> >> >>>>> stage 3.2: building everything >> ... >> cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs >> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline >> -Wcast-qual >> > ---8<---8<---[big snip]---8<---8<--- > > > Greetings, > What are the chances you made no declaration as to your CPU type in your > KERNCONF? > > > eg; 1386 Just for clarity; from /usr/src/sys/i386/conf/GENERIC: machine i386 #cpu I486_CPU #cpu I586_CPU cpu I686_CPU in the example above I've chosen i386 as machine type, and I686_CPU as cpu type. If you did /not/ make similar choices in /your/ KERNCONF, the error you reported will insue. HTH --Chris H > > > HTH > > > --Chris H > >> >> >> Was a definition or two overlooked? >> >> >> >> Peace, >> david -- David H. Wolfskill david@catwhisker.org >> Depriving a girl or boy of an opportunity for education is evil. >> >> >> >> See http://www.catwhisker.org/~david/publickey.gpg for my public key. >> >> >> > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 15:11:37 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C566B106566B for ; Sat, 19 Dec 2009 15:11:37 +0000 (UTC) (envelope-from jeronimocalvop@googlemail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 29A068FC0C for ; Sat, 19 Dec 2009 15:11:36 +0000 (UTC) Received: by fxm27 with SMTP id 27so3628886fxm.3 for ; Sat, 19 Dec 2009 07:11:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=57bATyQfA8F9Oau2YjmTC8U7E7HeER69R7BZJ6C3i1g=; b=AjCrWX92ZIfQy6UJvlG0Pil0dTycstleJVBeLXh9qg/FBQ/ylOgK/Jd9DtrQ3KxIEe DlU3JM081pmMWKccgCp1nsWo8BICUJNSDbIbkoDPXQ3IkZkOCpyU9GhL7+d5mt7E7dvy uXgXgdU4/uuWmLIWKeZEGcR73+YHAZRQcGzm0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=itOHLTAvYLLcoS/MPm4ISCVFelZEZgokCO8crTlo1UVs3yGPL1RJfPd0jRaJ8RBuNE E7l4x2tE3+0v7BD0Lg0IrtobqUOnXKGnlvACuSu3zwd0+FHpQNMskeSepEF99+QUAgCJ e8fF07IMxSlqjQpoCN+mVRUEwQrf90wOKGGhM= MIME-Version: 1.0 Received: by 10.239.191.145 with SMTP id b17mr586380hbi.72.1261233737309; Sat, 19 Dec 2009 06:42:17 -0800 (PST) Date: Sat, 19 Dec 2009 14:42:17 +0000 Message-ID: From: Jeronimo Calvo To: FreeBSD Questions Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: ET.UTF-8.out: Inappropriate ioctl for device (buildworld RELENG8) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 15:11:37 -0000 Hi folks, Im getting the following error when building world for RELENG_8 using GENERIC. Any ideas on how to skip that? ===> share/mklocale (all) mklocale -o UTF-8.out /usr/src/share/mklocale/UTF-8.src mklocale -o am_ET.UTF-8.out /usr/src/share/mklocale/am_ET.UTF-8.src am_ET.UTF-8.out: Inappropriate ioctl for device *** Error code 1 -- () ASCII Ribbon Campaign | Against HTML e-mail /\ www.asciiribbon.org | Against proprietary extensions From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 17:31:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74A581065672 for ; Sat, 19 Dec 2009 17:31:29 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 26B038FC08 for ; Sat, 19 Dec 2009 17:31:28 +0000 (UTC) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id nBJHVAT1007304; Sat, 19 Dec 2009 09:31:10 -0800 (PST) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id nBJHV9sT007303; Sat, 19 Dec 2009 09:31:09 -0800 (PST) (envelope-from david) Date: Sat, 19 Dec 2009 09:31:09 -0800 From: David Wolfskill To: Chris H Message-ID: <20091219173109.GK470@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , Chris H , freebsd-stable@freebsd.org References: <20091219133511.GI470@bunrab.catwhisker.org> <89caec87156a8a9f169aced430d2883a.HRCIM@webmail.1command.com> <3348649efcb82ef4d7e26b74b8621a42.HRCIM@webmail.1command.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qD3brAgIG4LbUq6d" Content-Disposition: inline In-Reply-To: <3348649efcb82ef4d7e26b74b8621a42.HRCIM@webmail.1command.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org Subject: Re: Failure during GENERIC (i386) kernel build at r200721 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 17:31:29 -0000 --qD3brAgIG4LbUq6d Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 19, 2009 at 06:05:33AM -0800, Chris H wrote: > ... > > Greetings, > > What are the chances you made no declaration as to your CPU type in your > > KERNCONF? > > > > > > eg; 1386 >=20 > Just for clarity; from /usr/src/sys/i386/conf/GENERIC: >=20 > machine i386 With respect, that is not correct, at least for stable/7 as of r200721. Rather, the line in question is in /sys/i386/conf/DEFAULTS: g1-119(7.2-S)[2] cd /sys/i386/conf/ g1-119(7.2-S)[3] grep '^machine' * DEFAULTS:machine i386 g1-119(7.2-S)[4]=20 Indeed; that appears to have gone into DEFAULTS as of r152865: ------------------------------------------------------------------------ r152865 | ru | 2005-11-27 15:17:00 -0800 (Sun, 27 Nov 2005) | 3 lines - Allow duplicate "machine" directives with the same arguments. - Move existing "machine" directives to DEFAULTS. ------------------------------------------------------------------------ I note, too, that stable/6, stable/8 and head each built and ran successfully on this machine this morning -- each using an unmodified GENERIC kernel, as is the kernel I was unable to build for stable/7. And I had another occurrence of the "make buildkernel" failure on my laptop (as a reality check) -- though that was not a GENERIC kerenl. > ... Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --qD3brAgIG4LbUq6d Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkstDd0ACgkQmprOCmdXAD1ZsACfUYPr2y/uf6NV33ePORmrMkHC TZwAmgLuCVbT+lJsXp00yjHnC42ARtEH =0tZL -----END PGP SIGNATURE----- --qD3brAgIG4LbUq6d-- From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 18:08:38 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95A9D1065676 for ; Sat, 19 Dec 2009 18:08:38 +0000 (UTC) (envelope-from mdounin@mdounin.ru) Received: from mdounin.cust.ramtel.ru (mdounin.cust.ramtel.ru [81.19.69.81]) by mx1.freebsd.org (Postfix) with ESMTP id 52F068FC08 for ; Sat, 19 Dec 2009 18:08:38 +0000 (UTC) Received: from mdounin.ru (mdounin.cust.ramtel.ru [81.19.69.81]) by mdounin.cust.ramtel.ru (Postfix) with ESMTP id D4A2E1702A; Sat, 19 Dec 2009 21:08:36 +0300 (MSK) Date: Sat, 19 Dec 2009 21:08:36 +0300 From: Maxim Dounin To: Chris H Message-ID: <20091219180836.GK43547@mdounin.ru> References: <20091219101408.GG43547@mdounin.ru> <20091219115424.GI43547@mdounin.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: SSL appears to be broken in 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 18:08:38 -0000 Hello! On Sat, Dec 19, 2009 at 05:23:53AM -0800, Chris H wrote: [...] > Indeed. I understand that. In fact my OP (original post) indicated my use was > in a "vhost" - eg; > NameVirtualHost host.ip.add.ress:443 > > SSLEnable > SSLVerifyClient (options 0-3;none work) > SSLRequireSSL > SSLNoV2 > > SSLCACertificatePath /path/to/ca-file > SSLCertificateFile /path/to/cert-file > SSLCertificateKeyFile /path/to/key-file > > [...] > Ah, ok, I've missed syntax you claimed for SSLVerifyClient, but with this config snipped it's much more clear. You are using apache-ssl, as in ports/www/apache13-ssl, right? It indeed seems to require renegotiation even with per-vhost SSLVerifyClient. No luck, only reverting patch will do the trick. Apache 2.2 with official mod_ssl works fine with per-vhost SSLVerifyClient, as well as Apache 1.3 with rse@'s mod_ssl (ports/www/apache22 and ports/www/apache13-modssl). Maxim Dounin From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 18:16:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D179E1065672; Sat, 19 Dec 2009 18:16:00 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 987498FC08; Sat, 19 Dec 2009 18:16:00 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:ad5e:cff1:ab2:f9b3] (unknown [IPv6:2001:7b8:3a7:0:ad5e:cff1:ab2:f9b3]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 4D0105C43; Sat, 19 Dec 2009 19:15:59 +0100 (CET) Message-ID: <4B2D1861.6000201@andric.com> Date: Sat, 19 Dec 2009 19:16:01 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.5) Gecko/20091217 Shredder/3.0.1pre MIME-Version: 1.0 To: Jeronimo Calvo References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, FreeBSD Questions Subject: Re: ET.UTF-8.out: Inappropriate ioctl for device (buildworld RELENG8) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 18:16:00 -0000 On 2009-12-19 15:42, Jeronimo Calvo wrote: > Hi folks, Im getting the following error when building world for > RELENG_8 using GENERIC. > Any ideas on how to skip that? > > ===> share/mklocale (all) > mklocale -o UTF-8.out /usr/src/share/mklocale/UTF-8.src > mklocale -o am_ET.UTF-8.out /usr/src/share/mklocale/am_ET.UTF-8.src > am_ET.UTF-8.out: Inappropriate ioctl for device > *** Error code 1 This problem should only hit you if you have a mklocale binary from after 8.0-BETA1, and before 8.0-BETA2. See these threads from some time ago: http://lists.freebsd.org/pipermail/freebsd-current/2009-July/thread.html#9871 http://lists.freebsd.org/pipermail/freebsd-current/2009-July/thread.html#9406 In short, rebuild mklocale before buildworld: cd /usr/src/usr.bin/mklocale make make install clean From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 20:38:31 2009 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFBA91065670 for ; Sat, 19 Dec 2009 20:38:31 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id EE9428FC0C for ; Sat, 19 Dec 2009 20:38:30 +0000 (UTC) Received: from delta.allbsd.org (p3177-ipbf416funabasi.chiba.ocn.ne.jp [123.225.92.177]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id nBJKc6nM017909; Sun, 20 Dec 2009 05:38:16 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id nBJKc1fn078137; Sun, 20 Dec 2009 05:38:04 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 20 Dec 2009 05:37:57 +0900 (JST) Message-Id: <20091220.053757.230970486.hrs@allbsd.org> To: jfvogel@gmail.com From: Hiroki Sato In-Reply-To: <2a41acea0912052327t7830f85aw5b4b581ab3f09be9@mail.gmail.com> References: <1E3C66EA-A6D3-44D7-B28E-BF068FFF16A6@jnielsen.net> <20091206.142720.79407994.hrs@allbsd.org> <2a41acea0912052327t7830f85aw5b4b581ab3f09be9@mail.gmail.com> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3rc1 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sun_Dec_20_05_37_57_2009_112)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Sun, 20 Dec 2009 05:38:23 +0900 (JST) X-Spam-Status: No, score=-5.7 required=13.0 tests=AWL,BAYES_00, CONTENT_TYPE_PRESENT, SPF_SOFTFAIL, X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: stable@FreeBSD.org, john@jnielsen.net Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 20:38:31 -0000 ----Security_Multipart(Sun_Dec_20_05_37_57_2009_112)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jack Vogel wrote in <2a41acea0912052327t7830f85aw5b4b581ab3f09be9@mail.gmail.com>: jf> The 82573, when onboard (LOM) is usually special, it is used by system jf> management jf> firmware. Go to the system BIOS and turn off management, see if that jf> eliminates the jf> periodic hang. Well, I am using them without enabling such a BIOS feature on the two boxes. I was monitoring for 1 week after replacing the kernel of 8.0-STABLE with 8.0R. Frequency of the symptom was reduced, but occurred once in 2-3 days. So it is reproducible on 8.0R, too. Just after the symptom occurred, dev.em.[01].debug showed the following: Dec 17 16:50:03 pool kernel: em0: Std mbuf failed = 0 Dec 17 16:50:03 pool kernel: em0: Std mbuf cluster failed = 9612 Dec 17 16:50:12 pool kernel: em1: Std mbuf failed = 0 Dec 17 16:50:12 pool kernel: em1: Std mbuf cluster failed = 15183 The other numbers look normal to me. dev.em.[01].stats reported almost all of the counters other than "Good Packets" are zero. Doing ifconfig down/up could make it work again, sending/receiving 10 packets or so it stopped. -- Hiroki ----Security_Multipart(Sun_Dec_20_05_37_57_2009_112)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkstOaUACgkQTyzT2CeTzy1OdwCfYdEoBvNvgm0taCnV4ay0ehDC rqcAmwVN1wIt6XP5i1FtFQ4W8BnA+XTq =i5jb -----END PGP SIGNATURE----- ----Security_Multipart(Sun_Dec_20_05_37_57_2009_112)---- From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 20:49:54 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A2801065672; Sat, 19 Dec 2009 20:49:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id DB7438FC1A; Sat, 19 Dec 2009 20:49:53 +0000 (UTC) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id nBJKnpKG035006; Sat, 19 Dec 2009 15:49:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id nBJKnpPh031387; Sat, 19 Dec 2009 15:49:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id F39471B5078; Sat, 19 Dec 2009 15:49:50 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20091219204950.F39471B5078@freebsd-stable.sentex.ca> Date: Sat, 19 Dec 2009 15:49:50 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 20:49:54 -0000 TB --- 2009-12-19 19:03:58 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-12-19 19:03:58 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2009-12-19 19:03:58 - cleaning the object tree TB --- 2009-12-19 19:04:35 - cvsupping the source tree TB --- 2009-12-19 19:04:35 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2009-12-19 19:04:45 - building world TB --- 2009-12-19 19:04:45 - MAKEOBJDIRPREFIX=/obj TB --- 2009-12-19 19:04:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-12-19 19:04:45 - TARGET=amd64 TB --- 2009-12-19 19:04:45 - TARGET_ARCH=amd64 TB --- 2009-12-19 19:04:45 - TZ=UTC TB --- 2009-12-19 19:04:45 - __MAKE_CONF=/dev/null TB --- 2009-12-19 19:04:45 - cd /src TB --- 2009-12-19 19:04:45 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 19 19:04:46 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Dec 19 20:35:41 UTC 2009 TB --- 2009-12-19 20:35:41 - generating LINT kernel config TB --- 2009-12-19 20:35:41 - cd /src/sys/amd64/conf TB --- 2009-12-19 20:35:41 - /usr/bin/make -B LINT TB --- 2009-12-19 20:35:41 - building LINT kernel TB --- 2009-12-19 20:35:41 - MAKEOBJDIRPREFIX=/obj TB --- 2009-12-19 20:35:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-12-19 20:35:41 - TARGET=amd64 TB --- 2009-12-19 20:35:41 - TARGET_ARCH=amd64 TB --- 2009-12-19 20:35:41 - TZ=UTC TB --- 2009-12-19 20:35:41 - __MAKE_CONF=/dev/null TB --- 2009-12-19 20:35:41 - cd /src TB --- 2009-12-19 20:35:41 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Dec 19 20:35:41 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/amd64/amd64/machdep.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/amd64/amd64/mca.c cc1: warnings being treated as errors /src/sys/amd64/amd64/mca.c: In function 'mca_init': /src/sys/amd64/amd64/mca.c:510: warning: implicit declaration of function 'CPUID_TO_FAMILY' /src/sys/amd64/amd64/mca.c:510: warning: nested extern declaration of 'CPUID_TO_FAMILY' /src/sys/amd64/amd64/mca.c:511: warning: implicit declaration of function 'CPUID_TO_MODEL' /src/sys/amd64/amd64/mca.c:511: warning: nested extern declaration of 'CPUID_TO_MODEL' *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-12-19 20:49:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-12-19 20:49:50 - ERROR: failed to build lint kernel TB --- 2009-12-19 20:49:50 - 5298.50 user 567.43 system 6352.01 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 21:28:14 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FBE71065679; Sat, 19 Dec 2009 21:28:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 657138FC0C; Sat, 19 Dec 2009 21:28:14 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id nBJLSCqw036164; Sat, 19 Dec 2009 16:28:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id nBJLSCGt067686; Sat, 19 Dec 2009 16:28:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 398521B5078; Sat, 19 Dec 2009 16:28:12 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20091219212812.398521B5078@freebsd-stable.sentex.ca> Date: Sat, 19 Dec 2009 16:28:12 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 21:28:14 -0000 TB --- 2009-12-19 20:07:19 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-12-19 20:07:19 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2009-12-19 20:07:19 - cleaning the object tree TB --- 2009-12-19 20:07:49 - cvsupping the source tree TB --- 2009-12-19 20:07:49 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2009-12-19 20:08:00 - building world TB --- 2009-12-19 20:08:00 - MAKEOBJDIRPREFIX=/obj TB --- 2009-12-19 20:08:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-12-19 20:08:00 - TARGET=i386 TB --- 2009-12-19 20:08:00 - TARGET_ARCH=i386 TB --- 2009-12-19 20:08:00 - TZ=UTC TB --- 2009-12-19 20:08:00 - __MAKE_CONF=/dev/null TB --- 2009-12-19 20:08:00 - cd /src TB --- 2009-12-19 20:08:00 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 19 20:08:01 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Dec 19 21:11:45 UTC 2009 TB --- 2009-12-19 21:11:45 - generating LINT kernel config TB --- 2009-12-19 21:11:45 - cd /src/sys/i386/conf TB --- 2009-12-19 21:11:45 - /usr/bin/make -B LINT TB --- 2009-12-19 21:11:45 - building LINT kernel TB --- 2009-12-19 21:11:45 - MAKEOBJDIRPREFIX=/obj TB --- 2009-12-19 21:11:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-12-19 21:11:45 - TARGET=i386 TB --- 2009-12-19 21:11:45 - TARGET_ARCH=i386 TB --- 2009-12-19 21:11:45 - TZ=UTC TB --- 2009-12-19 21:11:45 - __MAKE_CONF=/dev/null TB --- 2009-12-19 21:11:45 - cd /src TB --- 2009-12-19 21:11:45 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Dec 19 21:11:45 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/i386/i386/machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/i386/i386/mca.c cc1: warnings being treated as errors /src/sys/i386/i386/mca.c: In function 'mca_init': /src/sys/i386/i386/mca.c:510: warning: implicit declaration of function 'CPUID_TO_FAMILY' /src/sys/i386/i386/mca.c:510: warning: nested extern declaration of 'CPUID_TO_FAMILY' /src/sys/i386/i386/mca.c:511: warning: implicit declaration of function 'CPUID_TO_MODEL' /src/sys/i386/i386/mca.c:511: warning: nested extern declaration of 'CPUID_TO_MODEL' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-12-19 21:28:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-12-19 21:28:12 - ERROR: failed to build lint kernel TB --- 2009-12-19 21:28:12 - 4097.00 user 405.26 system 4852.18 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 22:07:45 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FC63106566B; Sat, 19 Dec 2009 22:07:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 578318FC12; Sat, 19 Dec 2009 22:07:45 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id nBJM7hBA038836; Sat, 19 Dec 2009 17:07:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id nBJM7hTj090788; Sat, 19 Dec 2009 17:07:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 24DF71B5078; Sat, 19 Dec 2009 17:07:42 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20091219220743.24DF71B5078@freebsd-stable.sentex.ca> Date: Sat, 19 Dec 2009 17:07:42 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [releng_7 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 22:07:45 -0000 TB --- 2009-12-19 20:49:50 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-12-19 20:49:50 - starting RELENG_7 tinderbox run for i386/pc98 TB --- 2009-12-19 20:49:51 - cleaning the object tree TB --- 2009-12-19 20:50:09 - cvsupping the source tree TB --- 2009-12-19 20:50:09 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile TB --- 2009-12-19 20:50:19 - building world TB --- 2009-12-19 20:50:19 - MAKEOBJDIRPREFIX=/obj TB --- 2009-12-19 20:50:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-12-19 20:50:19 - TARGET=pc98 TB --- 2009-12-19 20:50:19 - TARGET_ARCH=i386 TB --- 2009-12-19 20:50:19 - TZ=UTC TB --- 2009-12-19 20:50:19 - __MAKE_CONF=/dev/null TB --- 2009-12-19 20:50:19 - cd /src TB --- 2009-12-19 20:50:19 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 19 20:50:21 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Dec 19 21:53:52 UTC 2009 TB --- 2009-12-19 21:53:52 - generating LINT kernel config TB --- 2009-12-19 21:53:52 - cd /src/sys/pc98/conf TB --- 2009-12-19 21:53:52 - /usr/bin/make -B LINT TB --- 2009-12-19 21:53:52 - building LINT kernel TB --- 2009-12-19 21:53:52 - MAKEOBJDIRPREFIX=/obj TB --- 2009-12-19 21:53:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-12-19 21:53:52 - TARGET=pc98 TB --- 2009-12-19 21:53:52 - TARGET_ARCH=i386 TB --- 2009-12-19 21:53:52 - TZ=UTC TB --- 2009-12-19 21:53:52 - __MAKE_CONF=/dev/null TB --- 2009-12-19 21:53:52 - cd /src TB --- 2009-12-19 21:53:52 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Dec 19 21:53:52 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue vers.c linking kernel mca.o(.text+0xd79): In function `mca_init': : undefined reference to `CPUID_TO_FAMILY' mca.o(.text+0xd8b): In function `mca_init': : undefined reference to `CPUID_TO_MODEL' mca.o(.text+0xdce): In function `mca_init': : undefined reference to `CPUID_TO_FAMILY' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-12-19 22:07:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-12-19 22:07:42 - ERROR: failed to build lint kernel TB --- 2009-12-19 22:07:42 - 3958.14 user 403.70 system 4671.70 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-i386-pc98.full