From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 00:40:35 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A207EA1E for ; Sun, 14 Sep 2014 00:40:35 +0000 (UTC) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3947DD33 for ; Sun, 14 Sep 2014 00:40:34 +0000 (UTC) X-AuditID: 1209190d-f79c06d000006f95-f1-5414e2ce8e13 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 0D.DD.28565.EC2E4145; Sat, 13 Sep 2014 20:35:26 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s8E0ZPei017894; Sat, 13 Sep 2014 20:35:26 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s8E0ZNF3019875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 Sep 2014 20:35:25 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s8E0ZNb2011191; Sat, 13 Sep 2014 20:35:23 -0400 (EDT) Date: Sat, 13 Sep 2014 20:35:23 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: Marcin Cieslak Subject: Re: Teach vidcontrol(1) and vt(4) to restore default font In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleLIzCtJLcpLzFFi42IRYrdT0T33SCTE4MssVYs5bz4wWXx/dYzd gcljxqf5LB4zGpsYA5iiuGxSUnMyy1KL9O0SuDKeLmtjLGhjrZi87DhzA+NH5i5GDg4JAROJ vv+JXYycQKaYxIV769m6GLk4hARmM0mcu3iSFcLZyCixY8lWRgjnEJPE1r3r2EFahAQaGCWm LssBmcQioC1x64ACSJhNQE1i/YprzBBTFSU2n5oEZosIqEq8ed8AZjMLyEtsWT2ZDcQWFnCS mLVhDZjNKWAv0Xz+IZjNK+Aose9mK9QqO4mGDVfAekUFdCRW75/CAlEjKHFy5hMWiJlaEsun b2OZwCg0C0lqFpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbpGermZJXqpKaWbGEHhyynJ u4Px3UGlQ4wCHIxKPLwrLgqHCLEmlhVX5h5ilORgUhLlZbwuEiLEl5SfUpmRWJwRX1Sak1p8 iFGCg1lJhHfxdqAcb0piZVVqUT5MSpqDRUmcd9MPvhAhgfTEktTs1NSC1CKYrAwHh5IE79aH QI2CRanpqRVpmTklCGkmDk6Q4TxAw91BaniLCxJzizPTIfKnGI05Wpre9jJxrOv81s8kxJKX n5cqJc7bB1IqAFKaUZoHNw2Wgl4xigM9J8y78R5QFQ8wfcHNewW0iglo1bs5QiCrShIRUlIN jEsvCKkc9nHmNnodylBUdijUc/dPOa61//uVp5/9GL4qtDVqzxnFk5XrHp269shq/VejdRnz 4/4VsQYs52oqzb7iYh78ddK3zzL/I7cu5TjQJ6fh2KGw/Fr0Pv2Y0o0WFpapikfqN/ipfPr7 sSj2eqvEtzK5fs33Z0RlVs5LubLy06cbe+vrnJRYijMSDbWYi4oTAS4UkKYcAwAA Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 00:40:35 -0000 On Sat, 13 Sep 2014, Marcin Cieslak wrote: > Hello, > > I tried loading gallant.fnt which I did not > like and I was wondering how to come back to > the nice default font. > > There does not seem to be the way to do this, > so please find below a simple patch to add > this functionality. > > It adds a new ioctl PIO_VDFFONT to the vt(4) > driver. I hope I got the reference counting > on the vt_font_default structure right. > > With this patch applied, "vidcontrol -f" restores > the built-in font. Can you please submit this to our bug tracker so it doesn't get lost? https://bugs.freebsd.org/submit Thanks, Ben From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 03:40:14 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F45F146 for ; Sun, 14 Sep 2014 03:40:14 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F74BDBC for ; Sun, 14 Sep 2014 03:40:13 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-224-76.lns20.per1.internode.on.net [121.45.224.76]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s8E3e62P066557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 13 Sep 2014 20:40:11 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <54150E10.5040306@freebsd.org> Date: Sun, 14 Sep 2014 11:40:00 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? References: <541367D1.8090002@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 03:40:14 -0000 On 9/14/14, 2:32 AM, Craig Rodrigues wrote: > Technically, I agree with you that people should write portable shell > scripts, > and use #!/usr/bin/env bash rather than #!/bin/bash. > > Pushing that behavior upstream is not always practical these days, where > FreeBSD is in the minority, while Linux and MacOS X are in the vast > majority of where > people are doing development and learning how to write shell scripts these > days. > > I agree with Craig here. we can keep our code "pure" but the standard shell these days for everyone except us is /bin/bash. There is nothing wrong with FreeSBD deciding that an industry standard should be adopted.. While I don't like it when people code stuff at work in bash instead of sh, I have to admit it has a lot of advantages, and I can't really stop them.. It's getting more and more common so to some extent we should probably hide our pride a bit and look at bash (and maybe vim) and giving them better standard support. mailing the symlink is a really small thing. From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 03:56:50 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43F9330C for ; Sun, 14 Sep 2014 03:56:50 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B139AF21 for ; Sun, 14 Sep 2014 03:56:48 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-224-76.lns20.per1.internode.on.net [121.45.224.76]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s8E3uj0R066622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 13 Sep 2014 20:56:47 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <541511F7.6020003@freebsd.org> Date: Sun, 14 Sep 2014 11:56:39 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? References: <541367D1.8090002@FreeBSD.org> <54150E10.5040306@freebsd.org> In-Reply-To: <54150E10.5040306@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 03:56:50 -0000 On 9/14/14, 11:40 AM, Julian Elischer wrote: > On 9/14/14, 2:32 AM, Craig Rodrigues wrote: >> Technically, I agree with you that people should write portable shell >> scripts, >> and use #!/usr/bin/env bash rather than #!/bin/bash. >> >> Pushing that behavior upstream is not always practical these days, >> where >> FreeBSD is in the minority, while Linux and MacOS X are in the vast >> majority of where >> people are doing development and learning how to write shell >> scripts these >> days. >> >> > I agree with Craig here. > we can keep our code "pure" but the standard shell these days for > everyone except us is /bin/bash. > There is nothing wrong with FreeSBD deciding that an industry > standard should be adopted.. > > While I don't like it when people code stuff at work in bash instead > of sh, I have to admit it has a lot of > advantages, and I can't really stop them.. It's getting more and > more common so to some extent we should > probably hide our pride a bit and look at bash (and maybe vim) and > giving them better standard support. > > mailing the symlink is a really small thing. err.. making also I would like to RE-propose some suggestions that I've been making now for nearly 15 years. That we probably should have (at least) two classes of ports. in the current system we have "base" and "ports" I think we need more granularity than that. at a minimum we should have Base, Base ports, and extended ports. where "base ports" Must work, and a failure would be enough to hold up a release. "base" might contain extra hooks for "base ports" stuff. Stuff in base-ports would include sendmail, bind, Xorg, maybe appache, openldap, sasl, possibly even the compilers. Base ports get special priviledges, and responsibilities. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 17:43:49 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7257D4 for ; Sun, 14 Sep 2014 17:43:49 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id C2A0AF7 for ; Sun, 14 Sep 2014 17:43:49 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 2D663346DE17 for ; Sun, 14 Sep 2014 10:43:49 -0700 (PDT) Message-ID: <5415D3FC.4090509@mu.org> Date: Sun, 14 Sep 2014 10:44:28 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? References: <541367D1.8090002@FreeBSD.org> <54148F47.4030000@freebsd.org> In-Reply-To: <54148F47.4030000@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 17:43:49 -0000 On 9/13/14, 11:39 AM, Nathan Whitehorn wrote: > On 09/13/14 11:32, Craig Rodrigues wrote: >> >> If adding an optional knob to the bash port which is OFF by default >> to do >> this is a no-go, >> would having an optional port like what Brooks Davis mentioned be >> allowed >> which creates >> the symlink and updates /etc/shells? >> >> -- > > I'd point out that the perl ports have exactly such an option already > (putting links in /usr/bin, in this case). The CUPS port does too. > -Nathan Should really be a standalone package. -Alfred From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 22:22:10 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB0CED04 for ; Sun, 14 Sep 2014 22:22:10 +0000 (UTC) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3096FE50 for ; Sun, 14 Sep 2014 22:22:10 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id w7so3475048lbi.17 for ; Sun, 14 Sep 2014 15:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=B9ukPm4ahZyQ3v3F74NAeJC+1LJjeAB0EiSR5Di/TAA=; b=KZLbWo3U5SEsZ2HoexULotluFo/uM7t3QwdtklqhSAJNPJAQ5fypEw51Acl+wrLoWA 7rgW+B/pYCONzZO1Br5NRov5az6RCuRjrv4KC4+gKWlmsmMyrCHOQ6G5oyg09mNVl4n1 yMb9qlhQ9TesoghDXMrwXZSnpf1YUNysIhpvTsInvFBN7JQ15Ndmuo04qZJ1ILggN3zJ 2mJoxwqvrzB4gNWy5jxekI1Gt1q1A+6tSlX7H+A8QOcsSIRYfXPqwPgNTMxk9eKXEe+7 mZ6CSHD0p/fTdNVJVZbmiqBKqEx89DhzdsGoUXdslydxOAC/Q5BZUmSGE1rN/TZ0SR6Q 18kg== MIME-Version: 1.0 X-Received: by 10.112.156.164 with SMTP id wf4mr22978244lbb.7.1410733327931; Sun, 14 Sep 2014 15:22:07 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.22.72 with HTTP; Sun, 14 Sep 2014 15:22:07 -0700 (PDT) In-Reply-To: <5415D3FC.4090509@mu.org> References: <541367D1.8090002@FreeBSD.org> <54148F47.4030000@freebsd.org> <5415D3FC.4090509@mu.org> Date: Sun, 14 Sep 2014 15:22:07 -0700 X-Google-Sender-Auth: DEJTKqphGcLKhqGCJ1RTTaqmuLY Message-ID: Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? From: Craig Rodrigues To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 22:22:10 -0000 On Sun, Sep 14, 2014 at 10:44 AM, Alfred Perlstein wrote: > > On 9/13/14, 11:39 AM, Nathan Whitehorn wrote: > > Should really be a standalone package. It's not exactly the same, but the lang/python2 port for example is a meta-port which creates symlinks such as /usr/local/bin/python2 -> python2.7. So the precedent of having a metaport which creates symlinks is there. What folks have been complaining about in this thread is having symlinks in the "base system directories" such as /bin. My personal feeling is that we should look at this on a case-by-case basis and allow these types of ports, such as for /bin/bash but I'm sure others will disagree. -- Craig From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 22:32:11 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52427F7C; Sun, 14 Sep 2014 22:32:11 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 308FFF2A; Sun, 14 Sep 2014 22:32:11 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 6C78C346DE1C; Sun, 14 Sep 2014 15:32:10 -0700 (PDT) Message-ID: <54161791.508@mu.org> Date: Sun, 14 Sep 2014 15:32:49 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Craig Rodrigues Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? References: <541367D1.8090002@FreeBSD.org> <54148F47.4030000@freebsd.org> <5415D3FC.4090509@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 22:32:11 -0000 On 9/14/14, 3:22 PM, Craig Rodrigues wrote: > > > On Sun, Sep 14, 2014 at 10:44 AM, Alfred Perlstein > wrote: > > > On 9/13/14, 11:39 AM, Nathan Whitehorn wrote: > > Should really be a standalone package. > > > It's not exactly the same, but the lang/python2 port for example is a > meta-port which creates > symlinks such as /usr/local/bin/python2 -> python2.7. > > So the precedent of having a metaport which creates symlinks is there. > What folks have been complaining about in this thread is having symlinks > in the "base system directories" such as /bin. Why do you care what people are complaining about? Just make the port. :) > > My personal feeling is that we should look at this on a case-by-case > basis and allow these types > of ports, such as for /bin/bash but I'm sure others will disagree. We already allow such ports, for example a bunch of kmods install into /boot/kernel or /boot/modules. There are always exceptions to rules and for good reasons! find . -name pkg-plist | xargs grep -A 3 '^@cwd /$' > -- > Craig From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 22:50:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1EB3F4CA; Sun, 14 Sep 2014 22:50:13 +0000 (UTC) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB667E4; Sun, 14 Sep 2014 22:50:12 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id kq14so5122209pab.39 for ; Sun, 14 Sep 2014 15:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=BaDtI1QgZxw2WQ/uTXDOex7f0vZglHkU/bTBwSdS1PA=; b=tBsZWKZ1m+DDm8wJZTQ5V12nWsfrS4GDPhOYEftC7+u6/dE04mH8CZgWgnv8IT7iaO yhySkjktDH7Qw+zG2/aBE2XjxAGsGv89fVcrwbn5s3czZ+DPZWqHOTWBqhuOT/f6G73Y 8neS86KgX2+mHFVEdlEgAt+typYnYBsPy9tr1AZM190i9TfQHt2SsTUI22ROv289N7fJ e/7xxnMya2FRgwyqgZiNbD+XMUN9roBwQzUIYSGNl0kMR668FQqQYYrnwPyrJCM5cAqB 8XLnu4DobDQZt7ceM8wjcIlTIfcx0q5o6hBz9/g89PNmuy8vyhtK1QSX5OsY89HndeDx 1FtA== X-Received: by 10.70.134.98 with SMTP id pj2mr6696072pdb.65.1410735012455; Sun, 14 Sep 2014 15:50:12 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:809f:4f41:54cc:4ede? ([2601:8:ab80:7d6:809f:4f41:54cc:4ede]) by mx.google.com with ESMTPSA id c3sm9661553pdk.3.2014.09.14.15.50.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Sep 2014 15:50:11 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_192EBD2A-700B-41B6-B1A2-13D2C7891F52"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? From: Garrett Cooper In-Reply-To: <541367D1.8090002@FreeBSD.org> Date: Sun, 14 Sep 2014 15:50:10 -0700 Message-Id: References: <541367D1.8090002@FreeBSD.org> To: Bryan Drewery X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , freebsd-current Current , Emanuel Haupt , ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 22:50:13 -0000 --Apple-Mail=_192EBD2A-700B-41B6-B1A2-13D2C7891F52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 12, 2014, at 14:38, Bryan Drewery wrote: > "No" (as portmgr). >=20 > Ports should not be touching the base system like this. Let's NOT go > backwards and add a /bin/bash. In fact the /usr/bin/perl one will be > removed soon as well. >=20 > If we can actually eliminate ports touching /usr and / (not including > /usr/local and /var) then we gain a very large memory optimization for > package building by being able to ro null-mount these to the build = jails. >=20 > There's no reason for bash (and perl) to be exceptions to the 24000 > other ports that install to /usr/local/bin. I can think of dozens of > other ports that will fall into the same arguments being made here, = but > it does not mean it is the right thing for FreeBSD. >=20 > If you want to install the symlink on your system feel free to do it. = I > install a static bash to /bin/bash on mine and only because I prefer > bash shell and want it in / for single-user mode. That's my personal > choice though. >=20 > The proper fix is to fix scripts to be portable and use #! = /usr/bin/env > bash rather than /bin/bash. >=20 > We install all packages to PREFIX=3D/usr/local by default. Why should = a > bin symlink be an exception? There's no suggestion for symlinking > includes or libraries which also hit users often. Hi Bryan, I understand portmgr=92s reasoning for removing these knobs as = it improves =93portability=94 (builds and runtime won=92t depend on = broken code), but I see the merits of making a separate package for = Linux =93compatibility=94 for the various items that people have brought = up (mostly the LDAP issue and the vendor/legacy script portability = issue). Plus it makes the barrier for entry lower, and less of a reason = for Linux users to complain about how FreeBSD is different from Linux. = Adding these as options to the port(s) won=92t work for various reasons, = two of which came to mind are: 1. People should be able to install packages from FreeBSD.org = instead of having to roll their own ports with custom options. 2. It=92s best not to build other packages on unportable = (/bin/bash) behavior. Thanks! -Garrett PS I don=92t agree with Fedora/FreeDesktop=92s push to move everything = to /usr (I think it=92s a wee bit radical, to say the least, and seems = like it=92s optimizing the wrong thing), but it=92s something to keep in = mind as this non-portable decision may start working its way into = upstream ports: https://fedoraproject.org/wiki/Features/UsrMove . --Apple-Mail=_192EBD2A-700B-41B6-B1A2-13D2C7891F52 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUFhuiAAoJEMZr5QU6S73eBQwIAKQtl1/sj9eHok+1UIFaySx6 7KEyvzG8VZ+ApqV/SCURzVu832b/Qr+oh+GvEiekvlOdjbMJb6aVGYf4Efe7Nm+D 97ijaSA4f+Evvau4fzH1qOS4n+WTeOJloq5sQk4cD++CZWnGmfqpYHeiUHN03mI+ sv0TE+ArEI06Yt2IsMcl7wNTFeRZ9ieNrN1a9bdErhlkJTstBP4JVWt5qXDUYkxx m4a9guKmpUy2DozZFvTyi/UY1WFoBVtJLyk8MrpRtQ3zzKIEhmHbBrKAlBvP7Y0Y LdmNign9w3xyx3J52EofpPfiBYEr+NL85djpfOrDejreo7WeoCEgEVk3xWB0TJw= =GMEd -----END PGP SIGNATURE----- --Apple-Mail=_192EBD2A-700B-41B6-B1A2-13D2C7891F52-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 22:50:24 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF61764D; Sun, 14 Sep 2014 22:50:24 +0000 (UTC) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AE583EA; Sun, 14 Sep 2014 22:50:23 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id x12so3086616wgg.14 for ; Sun, 14 Sep 2014 15:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=vqjNtTCl5jDR+bBjL5VHM2KMB4PvkJXVC94peDvqyLA=; b=WBylKDbU3c0pAPqZzXZPpDUPODUyc/M58Bnnp6p41Ca58VKm1GpOPvO1pelomRyyRt /jETHVzDy2IIPE0moLcQJxa+iXYipCW2YueFHwjAZsziM3BLjjk9AxwvsEa0cX3PUR4F j84RfyRQXxTpjqh6z7qcJ086rb53jKsHuNuoqyyCXidIBsCOEe8MywrBAeMDWQbMvdj3 DFtzVaoIeDGVEb2IRNjB3RQxB9QToNU2nQ4/s6m7OaHgk+Qlp3O6KsyYf3mGIaHWAGFe L6bSvlZ6RSlLlSIdfuDq9cGOzHdmpzn6BBH14KXZPRbNLdaXxUCnyn7Eou6ivdP+Ea/E N3Qw== X-Received: by 10.194.236.234 with SMTP id ux10mr10494276wjc.0.1410735021899; Sun, 14 Sep 2014 15:50:21 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id ba3sm9674475wib.10.2014.09.14.15.50.20 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Sep 2014 15:50:20 -0700 (PDT) Sender: Baptiste Daroussin Date: Mon, 15 Sep 2014 00:50:18 +0200 From: Baptiste Daroussin To: Dreamcat4 Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? Message-ID: <20140914225018.GV6096@ivaldir.etoilebsd.net> References: <541367D1.8090002@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="c1qHkdEbEbCG94PZ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Craig Rodrigues , freebsd-current Current , Emanuel Haupt , ports , Bryan Drewery X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 22:50:24 -0000 --c1qHkdEbEbCG94PZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 13, 2014 at 08:39:17PM +0100, Dreamcat4 wrote: > Right, well here is another one: >=20 > The missing symlink for /etc/ssl/cert.pem >=20 > There is no reason it should not be in >=20 > ${prefix}/etc/ssl/cert.pem >=20 > Except that the folder etc/ssl/ only exists in base. >=20 > Without this symlink, then SSL certs aren't found by the 'fetch' > command and many significant websites these days can't work without > SSL. For example github.com (there are others). >=20 fetch has been fixed to read the one from localbase first. regards, bapt --c1qHkdEbEbCG94PZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlQWG6oACgkQ8kTtMUmk6EyLfgCfQvXwuDMm7h9caGqrPIX+FvVA ABsAoJdnAk9s/AC+egu8pZlKRsCaiWz6 =odPp -----END PGP SIGNATURE----- --c1qHkdEbEbCG94PZ-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 01:08:59 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A6CED83 for ; Mon, 15 Sep 2014 01:08:59 +0000 (UTC) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CBB28EF9 for ; Mon, 15 Sep 2014 01:08:57 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id bs8so3301492wib.14 for ; Sun, 14 Sep 2014 18:08:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=3/N3+96RSMHJ06UoTdLSxnVPkqdbn6gE8A+9LhRXkW0=; b=FIwaLPsMIOudhUTrgRI1rESeATqGalwmcH+22aZdc0lkYJ5/B/V8BqS82hlgoUwwiu 6EASfLTzpryJ+P3bYOjtQqPbHXZNH0D/XTjQordBk5t/SBVnpEfSRR2lEBLpOoG5yoeN QYEFA96DHLehJgAh02ESjgC+5v/9u9nnU5AbK4TwWBH9B1TbZQQfbfYMgQrYg31K6OES TdvpcL8DqnvadK0PIRmjFJg3Znz+LoXymhADInyahsui5wzqsGydrVMzi8Ni/eEowOd5 b9wVXWYMIqq5fjzvsFyFY5Jaq2BMQT10+QvTsUBiLE9NbNmji0hvT5tShZ7elujg7tsP Kzjw== X-Gm-Message-State: ALoCoQkCJ9gcLvyk5ihNbSDmnJ6ixGYEkh2ub2Cjpq8E7/j+ltqHZeyziEIWPLTVFUU8bBmvRhOF MIME-Version: 1.0 X-Received: by 10.180.20.148 with SMTP id n20mr19798253wie.22.1410742954725; Sun, 14 Sep 2014 18:02:34 -0700 (PDT) Received: by 10.217.70.69 with HTTP; Sun, 14 Sep 2014 18:02:34 -0700 (PDT) Date: Sun, 14 Sep 2014 19:02:34 -0600 Message-ID: Subject: SOEKRIS kernel crash From: Tom Everett To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 01:08:59 -0000 I've compiled a SOEKRIS kernel which I'm booting with Crochet-BSD. It's reliably crashing on boot, with the below message. The kernel revision is 271600, and the kernel config is here: https://github.com/kientzle/crochet-freebsd/blob/master/board/Soekris/conf/SOEKRIS11 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: at port 0x40 on isa0 Timecounter "i8254" frequency 1189161 Hz quality 0 Event timer "i8254" frequency 1189161 Hz quality 100 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 Timecounters tick every 1.000 msec interrupt storm detected on "irq5:"; throttling interrupt source Elan-mmcr driver: MMCR at 0xc37ff000. Elan-mmcr Soekris net45xx comBIOS ver. 1.33 20080103 Copyright (C) 2000-2007 random: unblocking device. ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: CFA-0 device ada0: Serial Number AJZ061813191928 ada0: 16.700MB/s transfers (PIO4, PIO 512bytes) ada0: 15259MB (31250432 512 byte sectors: 16H 63S/T 31002C) ada0: Previously was known as ad0 panic: Bio not on queue bp=0xc2ab74c0 target 0xc0c0f43c KDB: stack backtrace: db_trace_self_wrapper(c0b3e6fa,c2a01800,c2689be4,c061fdf1,c2a01830,...) at db_trace_self_wrapper+0x2d/frame 0xc2689bb8 kdb_backtrace(c0b39cc6,c0c11408,c0b26e7a,c2689c70,c0b26e7a,...) at kdb_backtrace+0x30/frame 0xc2689c1c vpanic(c0c112a8,100,c0b26e7a,c2689c70,c2689c70,...) at vpanic+0x80/frame 0xc2689c40 kassert_panic(c0b26e7a,c2ab74c0,c0c0f43c,0,c28d9c40,...) at kassert_panic+0xe9/frame 0xc2689c64 g_bioq_first(c0c0f454,0,c0b26c3c,5c,0,...) at g_bioq_first+0x63/frame 0xc2689c80 g_io_schedule_up(c28d9c40,0,c0b27089,60,c2689cf4,...) at g_io_schedule_up+0x94/frame 0xc2689cb4 g_up_procbody(0,c2689d08,c0b3335e,3c9,0,...) at g_up_procbody+0x9d/frame 0xc2689ccc fork_exit(c0703210,0,c2689d08) at fork_exit+0x7f/frame 0xc2689cf4 fork_trampoline() at fork_trampoline+0x8/frame 0xc2689cf4 --- trap 0, eip = 0, esp = 0xc2689d40, ebp = 0 --- KDB: enter: panic [ thread pid 13 tid 100009 ] Stopped at kdb_enter+0x3d: movl $0,kdb_why db> bt Tracing pid 13 tid 100009 td 0xc28d9c40 kdb_enter(c0b39f64,c0b39f64,c0b26e7a,c2689c70,c0b26e7a,...) at kdb_enter+0x3d/frame 0xc2689c1c vpanic(c0c112a8,100,c0b26e7a,c2689c70,c2689c70,...) at vpanic+0xcb/frame 0xc2689c40 kassert_panic(c0b26e7a,c2ab74c0,c0c0f43c,0,c28d9c40,...) at kassert_panic+0xe9/frame 0xc2689c64 g_bioq_first(c0c0f454,0,c0b26c3c,5c,0,...) at g_bioq_first+0x63/frame 0xc2689c80 g_io_schedule_up(c28d9c40,0,c0b27089,60,c2689cf4,...) at g_io_schedule_up+0x94/frame 0xc2689cb4 g_up_procbody(0,c2689d08,c0b3335e,3c9,0,...) at g_up_procbody+0x9d/frame 0xc2689ccc fork_exit(c0703210,0,c2689d08) at fork_exit+0x7f/frame 0xc2689cf4 fork_trampoline() at fork_trampoline+0x8/frame 0xc2689cf4 --- trap 0, eip = 0, esp = 0xc2689d40, ebp = 0 --- db> -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 02:58:57 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9510512 for ; Mon, 15 Sep 2014 02:58:57 +0000 (UTC) Received: from nm21-vm10.access.bullet.mail.bf1.yahoo.com (nm21-vm10.access.bullet.mail.bf1.yahoo.com [216.109.115.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7F475AF6 for ; Mon, 15 Sep 2014 02:58:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1410749776; bh=jliR+MPNk1Q2LvNvjZ8+HCU8j9Lbla4KBW5/FxjXGEQ=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:Message-ID:Date:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:From:To:Subject; b=uOXH0BgxJDoSJ8HVyWpFBkBEFpknBWCDdU1iZn3ZMn0Mopdz/YBWzFdY0OgUbdTTFsBofU3j30X3maZa2rZBpBHLsE4koOykENvYH0AyL7pWSqXAnVERm2oTjuc6DOexySaWLF2oX+mtmZjomw7T5WkrEFHz/sMvHXDl/vQTliY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=bellsouth.net; b=Hhivaxw6HcNputEUY5SM+60QX1ncE6a+sX/RUU7MfgHB/klpGe3ZRDRXEZwlbNpp5Q5ORnx45O9bBJ+iUzBM1IBwffMSApgl+InENvHL8Y145b8jDUkfLcRRZZ8C9P2AkbgOWmFxPF2IeKYXb/fJ+35eNx0uv/ul8iC8yipDMh4=; Received: from [66.196.81.165] by nm21.access.bullet.mail.bf1.yahoo.com with NNFMP; 15 Sep 2014 02:56:16 -0000 Received: from [98.139.244.50] by tm11.access.bullet.mail.bf1.yahoo.com with NNFMP; 15 Sep 2014 02:56:16 -0000 Received: from [127.0.0.1] by smtp112.sbc.mail.bf1.yahoo.com with NNFMP; 15 Sep 2014 02:56:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1410749776; bh=jliR+MPNk1Q2LvNvjZ8+HCU8j9Lbla4KBW5/FxjXGEQ=; h=X-Yahoo-Newman-Id:Message-ID:Date:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:From:To:Subject; b=DGiCmvaJveMsYOyEBm07BpnhY/L5PWotmYiLRFXXw6QQbsFJLb6+m+L1tsC+/tArdsjwwWyM2smylsUoTfsI172dI3kA3qSCELJiWpmw62b6AO95aDp2TgUHnUEqB6bBSwVSG95/+N0hku9vHCO0mXlscB5sqb1YGrqvsyZ6vDw= X-Yahoo-Newman-Id: 516095.49108.bm@smtp112.sbc.mail.bf1.yahoo.com Message-ID: <516095.49108.bm@smtp112.sbc.mail.bf1.yahoo.com> Date: Sun, 14 Sep 2014 19:56:16 -0700 (PDT) X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Fa1VaqkVM1lyoG0onUj.L2yda9w0iNce1gD6YeX_caLR300 6uQcDpIGFj8kU5woAkPELsrTEUnxCQgmLQiIQ0dECki8KBKGd9uutDfwUll1 EjLxdX2gi0fLqGbqPPa.gDWCfN5BtK92CaBB00CRoV4UaLLgOFVo_p.u1qJ_ km0iEnI6zVxI0SKMm6mMvwtufKwuv4KdAzn8ZnCTeq.jCtL4z6_JIOJFF1Xn 4.DX0U2NRBMPaTBwYl7B_tLZv0tUssziGel4fweC_LY_89_r0PhjxEWB4DVp 9On9O4P2NsKJ1LcCdsYTtD.PDnAgOdQUXAg4CbJm0_5EwtgoaO53KRXElkEK 2RKhCiPprV3TWA_1.HXX99YOwachtTw9u0RtipD_TDLfnqOfIQzmk.AnD1hr ndOcgwqm1r2Y..tmW8BIjFvErKe1V8Vtw4vr_mEU7LFPM3gey_4kchSPeiop 8GGHuDRPO53VgfZH9NpGkAiFAwI31tOnVsPxwMnZlCDNN1cro.XzfIHX2W2A 1VH5luyXHJwa2MTXjmDH3jZhIBbynG_NW0W11AneSA4YgAP791EMs X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Driver-specific debugging in buildkernel? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 02:58:57 -0000 I want to build a kernel with debugging for a specific device, rather than for everything. Device of interest is re (Ethernet driver), also rsu (USB wlan adapter). I looked in Makefiles, also NOTES files, found some xxxxDEBUG options but nothing really general that could be applied to any desired device in kernel or module. Then I would need to know how to find this debugging information. Tom From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 15:27:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B7EE456 for ; Mon, 15 Sep 2014 15:27:18 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7211A183 for ; Mon, 15 Sep 2014 15:27:18 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A3581B95D; Mon, 15 Sep 2014 11:27:16 -0400 (EDT) From: John Baldwin To: dt71@gmx.com Subject: Re: Xorg causes panics with "multiple" drivers (Was: panic: resource_list_alloc: resource entry is busy) Date: Mon, 15 Sep 2014 11:25:47 -0400 Message-ID: <282186928.pUbQA97aum@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: <54140711.7020001@gmx.com> References: <3819796.R7BYA2qqa8@ralph.baldwin.cx> <54140711.7020001@gmx.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 15 Sep 2014 11:27:16 -0400 (EDT) Cc: freebsd-current@freebsd.org, Marcin Cieslak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 15:27:18 -0000 On Saturday, September 13, 2014 10:57:53 AM dt71@gmx.com wrote: > John Baldwin wrote on 09/12/2014 23:06: > > X loaded i915kms automatically and > > i915 and i915kms do not get along. i915 had already allocated the IRQ > > when i915kms tried to alloc the same IRQ causing the issue. > > Who is to blame? The user who tried to manually load an unsupported > combination of modules, or the system, which should have handled things > gracefully (whether by automatically unloading the first driver, or > producing a soft-error upon loading the 2nd driver)? > > On a side-note, I also had a "resource_list_alloc: resource entry is busy" > panic right after switching from the 10.0-supported Xorg to the "new" Xorg; > I exited Xorg, enabled "FreeBSD_new_Xorg", ran "pkg upgrade", then ran > "startx", and got the panic. Surely this wasn't my fault! I can turn the panic into a resource allocation failure, but specifically with KMS I am unsure if it will actually be better. It depends on when the driver does this IRQ allocation. You may very well end up with a black screen and a seemingly "hung" system (though it would not actually be hung). I do think we should fix i915kms to fail fast if i915 is loaded, or more likely I think we should probably look at removing the old i915 driver from HEAD entirely so that 11 doesn't ship with it. It won't work with the Xorg we are shipping with 11, so it's really dead code at this point. The proposed diff would be: Index: subr_bus.c =================================================================== --- subr_bus.c (revision 271627) +++ subr_bus.c (working copy) @@ -3301,7 +3301,10 @@ resource_list_alloc(struct resource_list *rl, devi rle->flags |= RLE_ALLOCATED; return (rle->res); } - panic("resource_list_alloc: resource entry is busy"); + device_printf(bus, + "resource entry %#x type %d for child %s is busy\n", *rid, + type, device_get_nameunit(child)); + return (NULL); } if (isdefault) { -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 15:27:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4700457 for ; Mon, 15 Sep 2014 15:27:18 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7C166184 for ; Mon, 15 Sep 2014 15:27:18 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3A0FAB941; Mon, 15 Sep 2014 11:27:17 -0400 (EDT) From: John Baldwin To: Marcin Cieslak Subject: Re: panic: resource_list_alloc: resource entry is busy Date: Mon, 15 Sep 2014 11:22:35 -0400 Message-ID: <7492500.WNyRbPK6xq@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: References: <3819796.R7BYA2qqa8@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 15 Sep 2014 11:27:17 -0400 (EDT) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 15:27:18 -0000 On Friday, September 12, 2014 10:03:26 PM Marcin Cieslak wrote: > On Fri, 12 Sep 2014, John Baldwin wrote: > >> Please note I originally loaded "i915.ko", not "i915kms.ko" > > > > Oh, that is probably your problem. X loaded i915kms automatically and > > i915 and i915kms do not get along. i915 had already allocated the IRQ > > when i915kms tried to alloc the same IRQ causing the issue. > > Would that be possible to fail with EBUSY or something instead of panic? Yes, though in this case you probably will end up with a black screen and an apparent hang due to how KMS works which wouldn't be a lot better. :( -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 15:27:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E007F53B for ; Mon, 15 Sep 2014 15:27:20 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B8186187 for ; Mon, 15 Sep 2014 15:27:20 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A7EE6B97E; Mon, 15 Sep 2014 11:27:19 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Driver-specific debugging in buildkernel? Date: Mon, 15 Sep 2014 10:55:04 -0400 Message-ID: <2511769.1PR7xqNJql@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: <516095.49108.bm@smtp112.sbc.mail.bf1.yahoo.com> References: <516095.49108.bm@smtp112.sbc.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 15 Sep 2014 11:27:19 -0400 (EDT) Cc: Thomas Mueller X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 15:27:21 -0000 On Sunday, September 14, 2014 07:56:16 PM Thomas Mueller wrote: > I want to build a kernel with debugging for a specific device, rather than > for everything. > > Device of interest is re (Ethernet driver), also rsu (USB wlan adapter). > > I looked in Makefiles, also NOTES files, found some xxxxDEBUG options but > nothing really general that could be applied to any desired device in > kernel or module. > > Then I would need to know how to find this debugging information. There isn't a generic "debugging for driver X" knob. You can enable global debugging (e.g. INVARIANTS). Some drivers may have their own internal knobs, but most drivers depend on the global knobs. If you are debugging a driver as a module, you can build the kernel with INVARIANT_SUPPORT and just the driver with INVARIANTS. However, drivers invariably make calls into other subsystems in the kernel and that setup will not include checking for driver misbehavior in its interfacing with those subsystems, so I would generally recommend just enabling INVARIANTS globally. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 21:38:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AA7CA73; Mon, 15 Sep 2014 21:38:48 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A31C2FD; Mon, 15 Sep 2014 21:38:47 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XTdyp-003PW2-JB>; Mon, 15 Sep 2014 23:38:39 +0200 Received: from g225156093.adsl.alicedsl.de ([92.225.156.93] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XTdyp-002qEl-FH>; Mon, 15 Sep 2014 23:38:39 +0200 Date: Mon, 15 Sep 2014 23:38:33 +0200 From: "O. Hartmann" To: FreeBSD CURRENT , FreeBSD Questions Subject: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI Message-ID: <20140915233833.5bdd0725.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/g=4P0.97jFvESnuZ38v==ax"; protocol="application/pgp-signature" X-Originating-IP: 92.225.156.93 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 21:38:48 -0000 --Sig_/g=4P0.97jFvESnuZ38v==ax Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Trying to install and run FreeBSD 11.0-CURRENT (FreeBSD-11.0-CURRENT-amd64-20140903-r270990-memstick.img) on a new Lenovo = E540 notebook fails in activating the NIC (Realtek RTL8111/8168B, driver re[0]). The NIC = shows up as active and with carrier when issuing "ifconfig re0". =46rom a desktop machine, I tried to ping the system in question and I get a = result with missing packets: ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down 64 bytes from 192.168.0.130: icmp_seq=3D26 ttl=3D64 time=3D0.114 ms 64 bytes from 192.168.0.130: icmp_seq=3D41 ttl=3D64 time=3D0.130 ms 64 bytes from 192.168.0.130: icmp_seq=3D60 ttl=3D64 time=3D0.119 ms 64 bytes from 192.168.0.130: icmp_seq=3D80 ttl=3D64 time=3D0.119 ms 64 bytes from 192.168.0.130: icmp_seq=3D100 ttl=3D64 time=3D0.105 ms 64 bytes from 192.168.0.130: icmp_seq=3D116 ttl=3D64 time=3D0.135 ms 64 bytes from 192.168.0.130: icmp_seq=3D136 ttl=3D64 time=3D0.091 ms DHCP configuration fails, since no DHCP offer is discovered. I swapped the switches, the cabling and I had always the same results. I us= ed another Laptop, Dell Latitude E6510 with the same configuration (/etc/rc.conf) and = that system gets DHCP offer and is online. Since the notebook is brandnew, the last thing I'll "suspect" is a defectiv= e NIC, so I'll ask whether this phenomenon is known - or, if not, the results definititely= would indicate a broken NIC.=20 Another point is the WiFI adaptor. This notebook is supposed to have a WiFi= NIC, but it doesn't get revealed by FreeBSD (I tried iwn/iwi without success).=20 pciconf output below, sorry for the messy shape, it is a copy-and-paste fro= m that immature vt() terminal. Has anyone successfully installed that type of Notebook with FreeBSD CURREN= T using NIC and Wifi? Please CC me. Regards oh [...] none1@pci0:3:0:0: class=3D0xff0000 card=3D0x502817aa chip=3D0x522710e= c rev=3D0x01 hdr=3D0x00 vendor =3D 'Realtek Semiconductor Co., Ltd.' bar [10] =3D type Memory, range 32, base 0xf1e00000, size 4096, enabl= ed cap 01[40] =3D powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] =3D MSI supports 1 message, 64 bit cap 10[70] =3D PCI-Express 2 endpoint max data 128(128) link x1(x1) speed 2.5(2.5) ASPM L0s/L1(L0s/L1) ecap 0001[100] =3D AER 2 0 fatal 0 non-fatal 0 corrected ecap 0003[140] =3D Serial 1 00000001004ce000 re0@pci0:4:0:0: class=3D0x020000 card=3D0x502817aa chip=3D0x816810ec rev=3D= 0x10 hdr=3D0x00 subclass =3D ethernet cap 01[40] =3D powerspec 3 supports D0 D1 D2 D3 current D0 di sabled(L0s/L1) cap 11[b0] =3D MSI-X supports 4 messages, enabled ecap 0001[100] =3D AER 2 0 fatal 0 non-fatal 4 corrected ecap 001e[178] =3D unknown 1 class =3D network cap 05[d0] =3D MSI supports 1 message, 64 bit ecap 0003[140] =3D Serial 1 ac7ba1ffffa06fd6 --Sig_/g=4P0.97jFvESnuZ38v==ax Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUF1xeAAoJEOgBcD7A/5N8OtYH/3cx5wUeiG67EjkTWH5e/pD9 Z3gdVlgXgx7I878Q6WsTPm7XKCizJAFu3bQgq6PUnLRZDkix29d7jOIBz1z/lf9K t8n8JpgOYmGc7ny86o/04C/zlvut/dIV50LCFYaYuL1gF16PWZfrIJicFgofH+k/ L4TrMIYfl3zKo9NXvaZAUp1Kn7WCDd9lO1XU0X2gfhQyv3xUTPaFh+pzMWPxOJ4Z ErFRzqjGidCVGv9bZMf+dSTFEuJszL1yDJk0YdBObX8yhWqC6GUFlDeEpTRowv5c O0m1xi5KGRpkzB6k0GTEI4XxaEFye+XNp0Jbd0PHxaPatyq5Q04umFJnsZwzl94= =R61u -----END PGP SIGNATURE----- --Sig_/g=4P0.97jFvESnuZ38v==ax-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 21:47:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FE50D31 for ; Mon, 15 Sep 2014 21:47:51 +0000 (UTC) Received: from aslan.scsiguy.com (aslan.scsiguy.com [70.89.174.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 64AF7603 for ; Mon, 15 Sep 2014 21:47:50 +0000 (UTC) Received: from jt-mbp.sldomain.com (slboulder.spectralogic.com [192.30.190.3] (may be forged)) (authenticated bits=0) by aslan.scsiguy.com (8.14.9/8.14.9) with ESMTP id s8FLlkYJ025228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Sep 2014 15:47:48 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Content-Type: multipart/signed; boundary="Apple-Mail=_C996192D-E526-48C8-9DF4-B628178C8EE2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: libthr and main thread stack size From: "Justin T. Gibbs" In-Reply-To: <20140808112201.GC93733@kib.kiev.ua> Date: Mon, 15 Sep 2014 15:47:41 -0600 Message-Id: References: <53E36E84.4060806@ivan-labs.com> <20140808052807.GB93733@kib.kiev.ua> <53E48B38.9010607@ivan-labs.com> <20140808112201.GC93733@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1878.6) X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Ivan A. Kosarev" , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 21:47:51 -0000 --Apple-Mail=_C996192D-E526-48C8-9DF4-B628178C8EE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 8, 2014, at 5:22 AM, Konstantin Belousov = wrote: =85 > Below is the patch which adds environment variable = LIBPTHREAD_BIGSTACK_MAIN. > Setting it to any value results in the main thread stack left as is, = and > other threads allocate stack below the area of RLIMIT_STACK. Try it. > I do not want to set this behaviour as default. Is there a reason this should not be the default? Looking at the = getrlimit() page on the OpenGroup=92s site they say: RLIMIT_STACK This is the maximum size of the initial thread's stack, in bytes. The = implementation does not automatically grow the stack beyond this limit. = If this limit is exceeded, SIGSEGV shall be generated for the thread. If = the thread is blocking SIGSEGV, or the process is ignoring or catching = SIGSEGV and has not made arrangements to use an alternate stack, the = disposition of SIGSEGV shall be set to SIG_DFL before it is generated. Does posix say something different? I ran into this issue when debugging a segfault on Postgres when running = an (arguably quite bogus) query that should have fit within both the = configured stack rlimit and Postgres=92 configured stack limit. The = Postgres backend is really just single threaded, but happens to pull in = libpthread due to the threading support in some of the libraries it = uses. The segfault definitely violates POLA. =97 Justin --Apple-Mail=_C996192D-E526-48C8-9DF4-B628178C8EE2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJUF159AAoJED9n8CuvaSf4rikIAId5wOQQ2j3/kP6ilnInpmNp PH8YkuKrB2aWt7FFJkIw12VKMq75asmUPYz/Vxud/VAC73QMurrkWsxRowouHVO0 XLkJfcOwFtHOja0MmD5sGEgkShetv3yI2ZgjEQa0MXjI/rzxBCJQOviSNuVyH723 t3qtjnN72hj6QTSK39c0aoN9beXgjICDZkE+7PVuGO6m13dsJcqu2CqAfA9ycFKq qXo0G7iOFzM2QChXMO51Z9xz2hOnaqXmFY6iS3E0fVNlKNgzd8QMB0sLQvEajHbu 96N7QKp+JPMGObd+1pCzXqWuX3OCESMIqbNWKfolbgVV8qKMsGegws4CEPJ0ns4= =gypO -----END PGP SIGNATURE----- --Apple-Mail=_C996192D-E526-48C8-9DF4-B628178C8EE2-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 00:05:50 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47AC7602 for ; Tue, 16 Sep 2014 00:05:50 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 026653D4 for ; Tue, 16 Sep 2014 00:05:49 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1XTgHD-003rTO-9T>; Tue, 16 Sep 2014 02:05:47 +0200 Received: from f052164062.adsl.alicedsl.de ([78.52.164.62] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1XTgHD-0033th-7Y>; Tue, 16 Sep 2014 02:05:47 +0200 Date: Tue, 16 Sep 2014 02:05:41 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: CURRENT: EFI boot failure Message-ID: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/xsPl9QIEUDILGDBu9.FFLK/"; protocol="application/pgp-signature" X-Originating-IP: 78.52.164.62 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 00:05:50 -0000 --Sig_/xsPl9QIEUDILGDBu9.FFLK/ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop works fo= r UEFI fine. After I updated the sources to r271649, recompiled world and kernel (as we= ll as installed), now I get stuck with the screen message: >> FreeBSD EFI boot block Loader path: /boot/loader.efi and nothing happens. After a couple of minutes, the system reboots. What happened and how can this problem be solved? --Sig_/xsPl9QIEUDILGDBu9.FFLK/ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUF37aAAoJEOgBcD7A/5N8DPsIAJAkkYkgJmrT131VVUFqSjtH RWgPb4aYIPTz15bg7U98fcJvStZ/iqflV3kox8ddq10NS2RJS5oC+mYIUilR5WaB 9vj/EGVdkt4N+cJGtQ/S8KZXcyoidQKWG/dQ/sgEXQqgN2Ntn5taNk3oGqR+Issb L8vt3+R/aEN6zzzxFYMUEm74pOndw74xK/E9PuULIJOW/4eZBkSnOlgdPyJmN9y/ Zmbz0gpIwqSpgU7oXehKukhu8ijZrJm6S3qPFPaTZAqMIL/Qe2D6uqUUcVgSoJCY pf5fwwPmb7PTH6mfV3rA0g8dRlzZ9eJ/jGTu1wWFuz+jthMcL14b4gZPUsZ5RQk= =wtic -----END PGP SIGNATURE----- --Sig_/xsPl9QIEUDILGDBu9.FFLK/-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 00:36:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85EFBAEB for ; Tue, 16 Sep 2014 00:36:19 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 5E93489B for ; Tue, 16 Sep 2014 00:36:18 +0000 (UTC) Received: from [192.168.1.2] (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 931774D085 for ; Tue, 16 Sep 2014 00:36:17 +0000 (UTC) Message-ID: <54178607.1060305@freebsd.org> Date: Mon, 15 Sep 2014 20:36:23 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: CURRENT: EFI boot failure References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> In-Reply-To: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lDoBlXNXwIvcoIXPNjJasqH00lhtuggRW" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 00:36:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lDoBlXNXwIvcoIXPNjJasqH00lhtuggRW Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-09-15 20:05, O. Hartmann wrote: >=20 > Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop work= s for UEFI fine. > After I updated the sources to r271649, recompiled world and kernel (a= s well as > installed), now I get stuck with the screen message: >=20 >>> FreeBSD EFI boot block > Loader path: /boot/loader.efi >=20 > and nothing happens. After a couple of minutes, the system reboots. >=20 > What happened and how can this problem be solved? >=20 You might need to update the boot1.efi file on the UEFI partition (small FAT partition on the disk) I am not sure how 'in sync' boot1.efi (on the fat partiton) and loader.efi have to be. https://wiki.freebsd.org/UEFI --=20 Allan Jude --lDoBlXNXwIvcoIXPNjJasqH00lhtuggRW 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.22 (MingW32) iQIcBAEBAgAGBQJUF4YKAAoJEJrBFpNRJZKfTbIQAJO5I5UFxQNs1klvptvN6S8g WkylrMW7p5TkgXyjj8F9Jnj7yoSZoVwUJoKEQnlkzkWGi/ZDCw9t0DkCdnDHmml0 PaQYajrq5xQzcrpPpYBAfW7a5Dd8dRODUmXD4ZHZd6JoFENK/kRVg/43wC3N/3SB 5aFFGyYc0pe6oJ/5b12GqNOSQ7CbrI3TJOQ8t2jfvI45Q+Tac5jd+RqyUR0YKTyQ CAB+Op9qTcg1/TvkLEZqf0mcxmMsLu74VlTFFKWHtV8dlY4E+LARCq2dgUFEww7J ujI5rns13UFEkYiT75z7wGbCtQo7L0iTXkKKdhyAzJM1jnyYhjRdisOw/Oj1hWGV 6vHLHB8EfpLduJ8cqTQs1JJJHDvyyQwg6bBGL6nPv4qasF9GwurwM0oGp6jTvPME nfbrZquRwXAT0Eyminv3oS/+6krhK0zmaYoRh0eh6GFnIvZLVj28hY0OWirXopCv nG0dtIVyTxRQa36T1D2aVvW13kXGvM0Ck/4U2YmTVS4Jl8q3ECCJiEpWk9ckrJIL DTF6RiigxR45+WwoCCQ8S5Gn5IERQqvWHp/HVtZetQh9X1yaS+YvG/gIqNbWLYtF MYLQu+omXNc0lputcZoP8IZyor+xdRjz9L0eWWsbPUiJCuMStf+CFRLGs3YxMYJM LHtva4rHsiIrQhLm78Nn =41hF -----END PGP SIGNATURE----- --lDoBlXNXwIvcoIXPNjJasqH00lhtuggRW-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 00:39:34 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95FD8C18; Tue, 16 Sep 2014 00:39:34 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7BAAA8BE; Tue, 16 Sep 2014 00:39:34 +0000 (UTC) Received: from aurora.physics.berkeley.edu (aurora.Physics.Berkeley.EDU [128.32.117.67]) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s8G0dQvK015687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 15 Sep 2014 17:39:27 -0700 Message-ID: <541786BE.6010105@freebsd.org> Date: Mon, 15 Sep 2014 17:39:26 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Allan Jude , freebsd-current@freebsd.org Subject: Re: CURRENT: EFI boot failure References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> In-Reply-To: <54178607.1060305@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVZPhSMYC8dIW4hbOBNSJR602XCdydZPE4zgNhRrLWeATP8mEnvrXiig2Y3rN/DYpBufHCwhHj/jateA+yUGWqzC7zKf3dpu9q8= X-Sonic-ID: C;hqiP6Tk95BGEXwDu5Qupew== M;Ss3x6Tk95BGEXwDu5Qupew== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 00:39:34 -0000 On 09/15/14 17:36, Allan Jude wrote: > On 2014-09-15 20:05, O. Hartmann wrote: >> Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop works for UEFI fine. >> After I updated the sources to r271649, recompiled world and kernel (as well as >> installed), now I get stuck with the screen message: >> >>>> FreeBSD EFI boot block >> Loader path: /boot/loader.efi >> >> and nothing happens. After a couple of minutes, the system reboots. >> >> What happened and how can this problem be solved? >> > You might need to update the boot1.efi file on the UEFI partition (small > FAT partition on the disk) > > I am not sure how 'in sync' boot1.efi (on the fat partiton) and > loader.efi have to be. > > https://wiki.freebsd.org/UEFI > boot1.efi is designed never to need updating. (It also hasn't changed since April) -Nathan From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 01:19:36 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD2DD4E1; Tue, 16 Sep 2014 01:19:35 +0000 (UTC) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 24B67C14; Tue, 16 Sep 2014 01:19:34 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id w7so5597281lbi.31 for ; Mon, 15 Sep 2014 18:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=douMW4nGqc4rgzbNjApMiPdnu2ax3Uiy0iPMMnVAaLg=; b=R3lsrW48nrdFwF7MjD8FuZQfmk/EnsL29CrMQM1kDMZsrABIag/sTf7rZO3z5OprbC 5r4S0oNmo1n+3mJvKVC5kLjQQtE5TlfP1lsF69KUaFtmQFzmrkBd4lJNs7miWpwpaaGO vcuzzBOb9Yo0LA3W1CoQngsiOLCzdlZV4olS0x3bdJtiLLax/QhvWV8d3yJdqtJU7a7r z639OXwK933BHFnhD57i7G/WmBAskdTXYslWJ1nwDSYCbKuL77fg1a0CkU2j2mmRxDBI 0XjELFOZcdwSLckRm3UzqEvf9JU9TbwzPHt2lggecuWyMxjYAUbHW62gITrE/tiV+h18 os6w== MIME-Version: 1.0 X-Received: by 10.112.75.233 with SMTP id f9mr6919505lbw.102.1410830373049; Mon, 15 Sep 2014 18:19:33 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.112.64.97 with HTTP; Mon, 15 Sep 2014 18:19:32 -0700 (PDT) In-Reply-To: <20140915233833.5bdd0725.ohartman@zedat.fu-berlin.de> References: <20140915233833.5bdd0725.ohartman@zedat.fu-berlin.de> Date: Mon, 15 Sep 2014 18:19:32 -0700 X-Google-Sender-Auth: G9S-0R3CG3fF8Ufzw74t386hKD0 Message-ID: Subject: Re: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI From: Kevin Oberman To: "O. Hartmann" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD CURRENT , FreeBSD Questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 01:19:36 -0000 On Mon, Sep 15, 2014 at 2:38 PM, O. Hartmann wrote: > > Trying to install and run FreeBSD 11.0-CURRENT > (FreeBSD-11.0-CURRENT-amd64-20140903-r270990-memstick.img) on a new Lenovo > E540 notebook > fails in activating the NIC (Realtek RTL8111/8168B, driver re[0]). The NIC > shows up as > active and with carrier when issuing "ifconfig re0". > > From a desktop machine, I tried to ping the system in question and I get a > result with > missing packets: > > ping: sendto: Host is down > ping: sendto: Host is down > ping: sendto: Host is down > 64 bytes from 192.168.0.130: icmp_seq=26 ttl=64 time=0.114 ms > 64 bytes from 192.168.0.130: icmp_seq=41 ttl=64 time=0.130 ms > 64 bytes from 192.168.0.130: icmp_seq=60 ttl=64 time=0.119 ms > 64 bytes from 192.168.0.130: icmp_seq=80 ttl=64 time=0.119 ms > 64 bytes from 192.168.0.130: icmp_seq=100 ttl=64 time=0.105 ms > 64 bytes from 192.168.0.130: icmp_seq=116 ttl=64 time=0.135 ms > 64 bytes from 192.168.0.130: icmp_seq=136 ttl=64 time=0.091 ms > > DHCP configuration fails, since no DHCP offer is discovered. > > I swapped the switches, the cabling and I had always the same results. I > used another > Laptop, Dell Latitude E6510 with the same configuration (/etc/rc.conf) and > that system > gets DHCP offer and is online. > > Since the notebook is brandnew, the last thing I'll "suspect" is a > defective NIC, so I'll > ask whether this phenomenon is known - or, if not, the results > definititely would > indicate a broken NIC. > > Another point is the WiFI adaptor. This notebook is supposed to have a > WiFi NIC, but it > doesn't get revealed by FreeBSD (I tried iwn/iwi without success). > > pciconf output below, sorry for the messy shape, it is a copy-and-paste > from that immature > vt() terminal. > > Has anyone successfully installed that type of Notebook with FreeBSD > CURRENT using NIC > and Wifi? > > Please CC me. > > > Regards > oh > > > [...] > > none1@pci0:3:0:0: class=0xff0000 card=0x502817aa chip=0x522710ec > rev=0x01 hdr=0x00 > > > vendor = 'Realtek Semiconductor Co., Ltd.' > > > bar [10] = type Memory, range 32, base 0xf1e00000, size 4096, enabled > > > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > > > cap 05[50] = MSI supports 1 message, 64 bit > > > cap 10[70] = PCI-Express 2 endpoint max data 128(128) link x1(x1) > > > speed 2.5(2.5) ASPM L0s/L1(L0s/L1) > > > ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected > > > ecap 0003[140] = Serial 1 00000001004ce000 > > > re0@pci0:4:0:0: class=0x020000 card=0x502817aa chip=0x816810ec rev=0x10 > hdr=0x00 > > > subclass = ethernet > > > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current > D0 > di sabled(L0s/L1) > > > cap 11[b0] = MSI-X supports 4 messages, enabled > > ecap 0001[100] = AER 2 0 fatal 0 non-fatal 4 corrected > > > > ecap 001e[178] = unknown 1 > > > class = network > > > cap 05[d0] = MSI supports 1 message, 64 bit > > > ecap 0003[140] = Serial 1 ac7ba1ffffa06fd6 > I can't comment on the WiFi, I have little Asus box using an 8111/8168B and it works fine with the driver in 10.1-BETA. The driver in 10.0 recognizes the device, but did not work. I do notice that your NIC has a rev of 0x10 while mine is 0x0c. -- Kevin Oberman, Network Engineer, Retired From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 01:25:35 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0EA28B6; Tue, 16 Sep 2014 01:25:35 +0000 (UTC) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4EE77CDA; Tue, 16 Sep 2014 01:25:35 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id o8so4886401qcw.22 for ; Mon, 15 Sep 2014 18:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oujqBQwzJlHcZY5HsqIOEU+QdS6Oks60BLEwx4+IZEg=; b=ZR0cLc2vkMvP9jRdz6ja+wRvrK4/ocjJEEmj4TisEcEdon98IxYTB5ASiwGOBNl8xZ d3gdMCI5KHs0a/AmNfpz8PDRCR7wg88QazXx4Kgz0ox/WAHQGJv0WKhS9fXothBkzEYm AfZyA/fXbtjjzBGxhYC3Y1eftuio7pC9p24PWBFZ7pCEOSbATjQ6W5L9jbKNpW/s8HuX 4Ulu82PpAVObWFvI3tDyF2h2ZUnFQOTnFiFKRBe9PvHGvpN+E/frzbO0iXffhBtWpggk aNGku4N9o3S6hOK8LYVBAHFQfnlEuoYEg86i4oLDRzYzhqR/85+cLKBkJ2prjumhaxUo yzBg== MIME-Version: 1.0 X-Received: by 10.224.75.73 with SMTP id x9mr42446587qaj.63.1410830734355; Mon, 15 Sep 2014 18:25:34 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Mon, 15 Sep 2014 18:25:34 -0700 (PDT) In-Reply-To: References: <20140915233833.5bdd0725.ohartman@zedat.fu-berlin.de> Date: Mon, 15 Sep 2014 18:25:34 -0700 X-Google-Sender-Auth: 4EMQrS9B241qXw7eLfx8kt3CJpg Message-ID: Subject: Re: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI From: Adrian Chadd To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD CURRENT , "O. Hartmann" , FreeBSD Questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 01:25:35 -0000 Hi, Try updating to the latest -HEAD. It at least makes dhclient behave better. -a On 15 September 2014 18:19, Kevin Oberman wrote: > On Mon, Sep 15, 2014 at 2:38 PM, O. Hartmann > wrote: > >> >> Trying to install and run FreeBSD 11.0-CURRENT >> (FreeBSD-11.0-CURRENT-amd64-20140903-r270990-memstick.img) on a new Lenovo >> E540 notebook >> fails in activating the NIC (Realtek RTL8111/8168B, driver re[0]). The NIC >> shows up as >> active and with carrier when issuing "ifconfig re0". >> >> From a desktop machine, I tried to ping the system in question and I get a >> result with >> missing packets: >> >> ping: sendto: Host is down >> ping: sendto: Host is down >> ping: sendto: Host is down >> 64 bytes from 192.168.0.130: icmp_seq=26 ttl=64 time=0.114 ms >> 64 bytes from 192.168.0.130: icmp_seq=41 ttl=64 time=0.130 ms >> 64 bytes from 192.168.0.130: icmp_seq=60 ttl=64 time=0.119 ms >> 64 bytes from 192.168.0.130: icmp_seq=80 ttl=64 time=0.119 ms >> 64 bytes from 192.168.0.130: icmp_seq=100 ttl=64 time=0.105 ms >> 64 bytes from 192.168.0.130: icmp_seq=116 ttl=64 time=0.135 ms >> 64 bytes from 192.168.0.130: icmp_seq=136 ttl=64 time=0.091 ms >> >> DHCP configuration fails, since no DHCP offer is discovered. >> >> I swapped the switches, the cabling and I had always the same results. I >> used another >> Laptop, Dell Latitude E6510 with the same configuration (/etc/rc.conf) and >> that system >> gets DHCP offer and is online. >> >> Since the notebook is brandnew, the last thing I'll "suspect" is a >> defective NIC, so I'll >> ask whether this phenomenon is known - or, if not, the results >> definititely would >> indicate a broken NIC. >> >> Another point is the WiFI adaptor. This notebook is supposed to have a >> WiFi NIC, but it >> doesn't get revealed by FreeBSD (I tried iwn/iwi without success). >> >> pciconf output below, sorry for the messy shape, it is a copy-and-paste >> from that immature >> vt() terminal. >> >> Has anyone successfully installed that type of Notebook with FreeBSD >> CURRENT using NIC >> and Wifi? >> >> Please CC me. >> >> >> Regards >> oh >> >> >> [...] >> >> none1@pci0:3:0:0: class=0xff0000 card=0x502817aa chip=0x522710ec >> rev=0x01 hdr=0x00 >> >> >> vendor = 'Realtek Semiconductor Co., Ltd.' >> >> >> bar [10] = type Memory, range 32, base 0xf1e00000, size 4096, enabled >> >> >> cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 >> >> >> cap 05[50] = MSI supports 1 message, 64 bit >> >> >> cap 10[70] = PCI-Express 2 endpoint max data 128(128) link x1(x1) >> >> >> speed 2.5(2.5) ASPM L0s/L1(L0s/L1) >> >> >> ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected >> >> >> ecap 0003[140] = Serial 1 00000001004ce000 >> >> >> re0@pci0:4:0:0: class=0x020000 card=0x502817aa chip=0x816810ec rev=0x10 >> hdr=0x00 >> >> >> subclass = ethernet >> >> >> cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current >> D0 >> di sabled(L0s/L1) >> >> >> cap 11[b0] = MSI-X supports 4 messages, enabled >> >> ecap 0001[100] = AER 2 0 fatal 0 non-fatal 4 corrected >> >> >> >> ecap 001e[178] = unknown 1 >> >> >> class = network >> >> >> cap 05[d0] = MSI supports 1 message, 64 bit >> >> >> ecap 0003[140] = Serial 1 ac7ba1ffffa06fd6 >> > > I can't comment on the WiFi, I have little Asus box using an 8111/8168B and > it works fine with the driver in 10.1-BETA. The driver in 10.0 recognizes > the device, but did not work. I do notice that your NIC has a rev of 0x10 > while mine is 0x0c. > -- > Kevin Oberman, Network Engineer, Retired > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 05:51:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D93CE37; Tue, 16 Sep 2014 05:51:31 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA75080B; Tue, 16 Sep 2014 05:51:30 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XTlfk-000e9f-6s>; Tue, 16 Sep 2014 07:51:28 +0200 Received: from g225112153.adsl.alicedsl.de ([92.225.112.153] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XTlfk-003c9K-3G>; Tue, 16 Sep 2014 07:51:28 +0200 Date: Tue, 16 Sep 2014 07:51:21 +0200 From: "O. Hartmann" To: Nathan Whitehorn Subject: Re: CURRENT: EFI boot failure Message-ID: <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> In-Reply-To: <541786BE.6010105@freebsd.org> References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/4zyOP_wCrHe_XZ=mPTwCBPl"; protocol="application/pgp-signature" X-Originating-IP: 92.225.112.153 X-ZEDAT-Hint: A Cc: freebsd-current@freebsd.org, Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 05:51:31 -0000 --Sig_/4zyOP_wCrHe_XZ=mPTwCBPl Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Mon, 15 Sep 2014 17:39:26 -0700 Nathan Whitehorn schrieb: >=20 > On 09/15/14 17:36, Allan Jude wrote: > > On 2014-09-15 20:05, O. Hartmann wrote: > >> Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop wor= ks for UEFI > >> fine. After I updated the sources to r271649, recompiled world and ke= rnel (as well > >> as installed), now I get stuck with the screen message: > >> > >>>> FreeBSD EFI boot block > >> Loader path: /boot/loader.efi > >> > >> and nothing happens. After a couple of minutes, the system reboots. > >> > >> What happened and how can this problem be solved? > >> > > You might need to update the boot1.efi file on the UEFI partition (small > > FAT partition on the disk) > > > > I am not sure how 'in sync' boot1.efi (on the fat partiton) and > > loader.efi have to be. > > > > https://wiki.freebsd.org/UEFI > > >=20 > boot1.efi is designed never to need updating. (It also hasn't changed=20 > since April) > -Nathan But it has changed bytesize when I recompiled world with recent sources com= pared to the boot.efi size from the USB image I installed from (revision see above). How to update bootcode on UEFI layout? I created a GPT partition with type = efi (1 GB) as well as a 512KB partition typed freebsd-boot. I'm new to EFI and the way the notebook now behaves is really strange. Whil= e the USB drive image used to boot with new console enabled, it now boots again with = the old console and 800x640 resolution. This might indicate some minor but very eff= ective mistake I made. Oliver --Sig_/4zyOP_wCrHe_XZ=mPTwCBPl Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUF8/fAAoJEOgBcD7A/5N8tmgH/1j2uaTJkwa8wognvF2yake9 mCG8Dg8YRD99yd0aue4oUZAxdkPas4Z6Nzyd0VMFbhZx4eXaU2cAfwKq1afj8tL/ 41gozRDIU+nskQuIP4xO6QXnPU/4TjBuZINGuD99FHhmaWnv4Ow5wzXVw6dF5B1K LyOXHeRQvlzuXkk/s2WVwK0YZeVacWE2v/H3zOMvJ3FIedS3iDV5mGCXJHoEVggz N5Bqowvtxilq+I/BOXCrnA1A8fAlP9k1RXNBZaX5SshWmbjoCwE8VowFYwG53gRw diBY7mxyM2zhLvMkHmhBASmK1dfT2O374cfsrPXTsRGo2Z/YrsKbdN51c9j/3W8= =7pEr -----END PGP SIGNATURE----- --Sig_/4zyOP_wCrHe_XZ=mPTwCBPl-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 07:09:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A6FECDC; Tue, 16 Sep 2014 07:09:05 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0E13BE4C; Tue, 16 Sep 2014 07:09:04 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s8G7918M008574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 Sep 2014 00:09:02 -0700 Message-ID: <5417E20D.8070607@freebsd.org> Date: Tue, 16 Sep 2014 00:09:01 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: "O. Hartmann" Subject: Re: CURRENT: EFI boot failure References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> In-Reply-To: <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYsUThMiSvR6Bir7qXtYsuE9uBkg8fRop1TGzY5d4z5InvjJm8yOHJO7o4OFOQNwntAMCfXD/ofZ9Ubg//U1s+Ts3ZLjou3+Pc= X-Sonic-ID: C;MrsZVnA95BGPzgDu5Qupew== M;rntzVnA95BGPzgDu5Qupew== X-Spam-Flag: No X-Sonic-Spam-Details: 2.4/5.0 by cerberusd Cc: freebsd-current@freebsd.org, Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 07:09:05 -0000 On 09/15/14 22:51, O. Hartmann wrote: > Am Mon, 15 Sep 2014 17:39:26 -0700 > Nathan Whitehorn schrieb: > >> On 09/15/14 17:36, Allan Jude wrote: >>> On 2014-09-15 20:05, O. Hartmann wrote: >>>> Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop works for UEFI >>>> fine. After I updated the sources to r271649, recompiled world and kernel (as well >>>> as installed), now I get stuck with the screen message: >>>> >>>>>> FreeBSD EFI boot block >>>> Loader path: /boot/loader.efi >>>> >>>> and nothing happens. After a couple of minutes, the system reboots. >>>> >>>> What happened and how can this problem be solved? >>>> >>> You might need to update the boot1.efi file on the UEFI partition (small >>> FAT partition on the disk) >>> >>> I am not sure how 'in sync' boot1.efi (on the fat partiton) and >>> loader.efi have to be. >>> >>> https://wiki.freebsd.org/UEFI >>> >> boot1.efi is designed never to need updating. (It also hasn't changed >> since April) >> -Nathan > > But it has changed bytesize when I recompiled world with recent sources compared to the > boot.efi size from the USB image I installed from (revision see above). Probably compiler updates or something? I really wouldn't worry about it too much. I'd worry more about loader, since we know boot1 could use the console but loader doesn't show up. > How to update bootcode on UEFI layout? I created a GPT partition with type efi (1 GB) as > well as a 512KB partition typed freebsd-boot. How did you set it up in the first place? If you have a FreeBSD-only system partition (like the installer sets up), you just dd /boot/boot1.efifat to the EFI partition. Otherwise, it's FAT and you copy /boot/boot1.efi to somewhere your boot manager can find it. > I'm new to EFI and the way the notebook now behaves is really strange. While the USB > drive image used to boot with new console enabled, it now boots again with the old > console and 800x640 resolution. This might indicate some minor but very effective mistake > I made. > The EFI boot block finds the first UFS partition -- on any disk -- and tries to boot from it. If you have multiple FreeBSD disks connected, that will very likely result in madness. -Nathan From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 07:40:49 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72F411A0 for ; Tue, 16 Sep 2014 07:40:49 +0000 (UTC) Received: from valery.hibma.org (valery.hibma.org [IPv6:2a02:2308::216:3eff:fe79:3a6c]) by mx1.freebsd.org (Postfix) with ESMTP id 39F4A1FF for ; Tue, 16 Sep 2014 07:40:48 +0000 (UTC) Received: from hitske.fritz.box (thuis.van-laarhoven.org [80.100.41.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by valery.hibma.org (Postfix) with ESMTPSA id 66B126927A6 for ; Tue, 16 Sep 2014 09:40:46 +0200 (CEST) From: Nick Hibma Subject: Huawei E3272 tester needed Message-Id: Date: Tue, 16 Sep 2014 09:40:45 +0200 To: FreeBSD Current Mailing List Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 07:40:49 -0000 Hi, Is there someone who is able to test support for the Huawei E3272 card = with CURRENT after 269584? I have not been able to confirm that it = works. Thanks in advance. Nick The change: Author: n_hibma Date: Tue Aug 5 12:08:50 2014 New Revision: 269584 URL: http://svnweb.freebsd.org/changeset/base/269584 Log: Add support for Huawei E3272 modems which are supported by the CDC ethernet class. Note: This is untested as I do not have a device like this. That is reflected in the MFC timeout. PR: 192345 Submitted by: rozhuk.im gmail.com MFC after: 4 weeks Modified: head/sys/dev/usb/net/if_cdce.c head/sys/dev/usb/usbdevs= From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 08:13:34 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8835566E for ; Tue, 16 Sep 2014 08:13:34 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2AF77754 for ; Tue, 16 Sep 2014 08:13:33 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s8G8DPY0038549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Sep 2014 11:13:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s8G8DPY0038549 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s8G8DOcN038548; Tue, 16 Sep 2014 11:13:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 16 Sep 2014 11:13:24 +0300 From: Konstantin Belousov To: "Justin T. Gibbs" Subject: Re: libthr and main thread stack size Message-ID: <20140916081324.GQ2737@kib.kiev.ua> References: <53E36E84.4060806@ivan-labs.com> <20140808052807.GB93733@kib.kiev.ua> <53E48B38.9010607@ivan-labs.com> <20140808112201.GC93733@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="byChrBWZKGwyiGYd" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "Ivan A. Kosarev" , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 08:13:34 -0000 --byChrBWZKGwyiGYd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 15, 2014 at 03:47:41PM -0600, Justin T. Gibbs wrote: > On Aug 8, 2014, at 5:22 AM, Konstantin Belousov wro= te: >=20 > ? >=20 > > Below is the patch which adds environment variable > > LIBPTHREAD_BIGSTACK_MAIN. Setting it to any value results in the > > main thread stack left as is, and other threads allocate stack > > below the area of RLIMIT_STACK. Try it. I do not want to set this > > behaviour as default. > > Is there a reason this should not be the default? Looking at the > getrlimit() page on the OpenGroup?s site they say: > > RLIMIT_STACK This is the maximum size of the initial thread's stack, > in bytes. The implementation does not automatically grow the stack > beyond this limit. If this limit is exceeded, SIGSEGV shall be > generated for the thread. If the thread is blocking SIGSEGV, or the > process is ignoring or catching SIGSEGV and has not made arrangements > to use an alternate stack, the disposition of SIGSEGV shall be set to > SIG_DFL before it is generated. > > Does posix say something different? > > I ran into this issue when debugging a segfault on Postgres when > running an (arguably quite bogus) query that should have fit within > both the configured stack rlimit and Postgres? configured stack limit. > The Postgres backend is really just single threaded, but happens > to pull in libpthread due to the threading support in some of the > libraries it uses. The segfault definitely violates POLA. > > ? Justin I am conservative to not disturb the address space layout in single go. If enough people test this setting, I can consider flipping the default to the reverse. I am still curious why the things were done in this way, but nobody replied. --byChrBWZKGwyiGYd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUF/EjAAoJEJDCuSvBvK1BNYwP/AiJi6bhBH/vZ+cvfiYY/FgZ zAKdMk8vTpdwTWImNwDoRocs5GeEd4TrplqFf9m74LvYzM22G/2/kHsoq0PytL32 rf0GJ1s8bA2hoVK81k0KTK1hUOylvxZK2UtS8glFnNBUQh1MAk//2cdy8QMBNFiH jnByR7zZ3opKbuNo3+ii2uFuqDZZyU+mjUqIhcDPqLCHCjBXj3jpoIgtn6XpLISA J83kIFeeXX+VWufw084mIlomu+Q4m45KDOdKIwTPXSsBTuKJcBfSo7g46NQRvbL4 dyUAKfrbq7mvaftKi8hOYvwYG88CX5fn7RwRoyXBUSMVDvo/tbvl8faWTKym4NC/ 5g2ZJ3uqaCU9eJU/+nMglAYryhpjJXiDBK9wpfEuc9luXJ1oIRCPsMADjFgbgcBR TujOabues6eLDS62BdohLK0tb7eDfjdHxz8b+TILOt9KmWIklkCSktDL8vWO2Z2B 2lvgJcieHLCj/RwMAwTPibUhqtclI77W/ET48s2kl7Lw9zHU40O5SnZzjih+jE1o Sq5B3/1bb/Wqu2WrF4R/Wta3msV2UAU2OEe8wJMf3YUCJyxFfU2IchFB+AwD1224 jjdOGdJ+EIaCXW0Z1LJO42l5elSlnOyCAcbdOyVEpVjXLTF2DlHedlORd/sb/GZN 8raPLokhNq0F7Ulue6ay =0Iaa -----END PGP SIGNATURE----- --byChrBWZKGwyiGYd-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 09:49:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 561F2394 for ; Tue, 16 Sep 2014 09:49:39 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E2FAF6F for ; Tue, 16 Sep 2014 09:49:38 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 2A6D625D3A97; Tue, 16 Sep 2014 09:49:35 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 4DE79C770C5; Tue, 16 Sep 2014 09:49:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 8nBmnipstfhc; Tue, 16 Sep 2014 09:49:32 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 5C465C770C4; Tue, 16 Sep 2014 09:49:32 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: CURRENT: EFI boot failure From: "Bjoern A. Zeeb" In-Reply-To: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> Date: Tue, 16 Sep 2014 09:49:30 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 09:49:39 -0000 On 16 Sep 2014, at 00:05 , O. Hartmann = wrote: >=20 > Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop = works for UEFI fine. > After I updated the sources to r271649, recompiled world and kernel = (as well as > installed), now I get stuck with the screen message: >=20 >>> FreeBSD EFI boot block > Loader path: /boot/loader.efi >=20 > and nothing happens. After a couple of minutes, the system reboots. The reboot comes from the EFI watchdog. > What happened and how can this problem be solved? One important thing for the people looking into this will be to know = what hardware and if possible firmware revision you have. =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 10:42:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0FB769C9; Tue, 16 Sep 2014 10:42:43 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 72529997; Tue, 16 Sep 2014 10:42:42 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id cc10so5930147wib.2 for ; Tue, 16 Sep 2014 03:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=XZg7t4ZfYBKVeLBB3IY7QY+f159w6slsIZQs247M0uI=; b=Au1pAeNKIbM88AF7yUfF+RKDMAXeh3iChrRErD0fdKtzsVS94S8J+ActBCEtUeHjDu OEZtg6pRGLJqDx/d2I4ZM/a6XEwmthCa5m4PyXroiCTralrslWcTqd6362CN6HJwpmlU WnRzQNyiS6fOpWp73B7TUZHnVCID7EXJ1PUt2rNCdXYjjnOSQxenU2qrI0mUH0/XTxfl zFfXnKu4wBO3seEeGhSEHKRAVnIy73ynDf3EFcAheaNWsfiwPrIyR06SkV9vTv0wEWM3 UFx/uKdbUhKUUrOCHanipA637Ux3YRERB1KuRrxq3m4V3qmdA88QStMfCQtEncHp/jH4 QwRQ== X-Received: by 10.180.212.50 with SMTP id nh18mr25771240wic.81.1410864160504; Tue, 16 Sep 2014 03:42:40 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id cz3sm17929742wjb.23.2014.09.16.03.42.38 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 16 Sep 2014 03:42:39 -0700 (PDT) Date: Tue, 16 Sep 2014 12:42:36 +0200 From: Mateusz Guzik To: Peter Wemm Subject: Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient Message-ID: <20140916104236.GA21560@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Peter Wemm , freebsd-current@freebsd.org, Patrick Kelsey , George Neville-Neil References: <540FF706.2050400@freebsd.org> <4252906.DAHIEnKpIF@overcee.wemm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4252906.DAHIEnKpIF@overcee.wemm.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Patrick Kelsey , George Neville-Neil , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 10:42:43 -0000 On Fri, Sep 12, 2014 at 09:29:56PM -0700, Peter Wemm wrote: > On Thursday, September 11, 2014 12:38:02 PM Patrick Kelsey wrote: > > On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov wrote: > > > On 09.09.2014 21:53, Patrick Kelsey wrote: > > > > I don't think it is worth the trouble, as given the larger pattern of > > > > libc routines requiring multiple capsicum rights, it seems one will in > > > > general have to have libc implementation knowledge when using it in > > > > concert with capsicum. For example, consider the limitfd() routine in > > > > kdump.c, which provides rights for the TIOCGETA ioctl to be used on > > > > stdout so the eventual call to isatty() via printf() will work as > > > > > > intended. > > > > > > > I think the above kdump example is a good one for the subtle issues that > > > > can arise when using capsicum with libc. That call to isatty() is via a > > > > widely-used internal libc routine __smakebuf(). __smakebuf() also calls > > > > __swhatbuf(), which in turn calls _fstat(), all to make sure that output > > > > to a tty is line buffered by default. It would appear that programs > > > > that restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT > > > > could be disabling the normally default line buffering when stdout is a > > > > tty. kdump goes the distance, but dhclient does not (restricting stdout > > > > to CAP_WRITE only). > > > > > > > > In any event, the patch attached to my first message is seeming like the > > > > way to go. > > > > > > Well, then commit it (if capsicum team agrees). > > > > Will do - thanks for the feedback. > > > > -Patrick > > Is there any possibility that this is related to the problem we've recently > hit in the freebsd.org cluster with this month's refresh? > > After running for a while: > Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 0: validator > Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 1: iterator > Sep 10 11:44:29 ns2 unbound: [65258:3] fatal error: event_dispatch returned > error -1, errno is Capabilities insufficient > > Sep 10 16:21:16 ns2 unbound: [28212:0] warning: did not exit gracefully last > time (65258) > Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 0: validator > Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 1: iterator > Sep 11 10:23:49 ns2 unbound: [28213:5] fatal error: event_dispatch returned > error -1, errno is Capabilities insufficient > > Sep 11 13:48:46 ns2 unbound: [79419:0] warning: did not exit gracefully last > time (28213) > Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 0: validator > Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 1: iterator > Sep 11 18:42:56 ns2 unbound: [79420:6] fatal error: event_dispatch returned > error -1, errno is Capabilities insufficient > > I believe this jail was started from the boot process. If I restart the jail > by hand from a ssh session the problem goes away. > > This is unbound from ports and I don't have any more details than this. This > is new this month. > Is this thingy multithreaded? Currently there is a race in the kernel where fd is visible before relevant capabilities are installed. This can result in an error like this one for weird processes. I got a patch for this: http://lists.freebsd.org/pipermail/freebsd-arch/2014-August/015788.html but it got stalled on 'memory barrier' discussion. I'll try to ping people to move it forward. IIRC there was a report of unbound failing this way, apparently fixed with aforementioned patch. -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 11:19:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DBA1754; Tue, 16 Sep 2014 11:19:03 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0AF03CAE; Tue, 16 Sep 2014 11:19:02 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XTqmi-002gHT-CP>; Tue, 16 Sep 2014 13:19:00 +0200 Received: from g225112153.adsl.alicedsl.de ([92.225.112.153] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XTqmi-000JIM-8u>; Tue, 16 Sep 2014 13:19:00 +0200 Date: Tue, 16 Sep 2014 13:18:54 +0200 From: "O. Hartmann" To: Adrian Chadd Subject: Re: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI Message-ID: <20140916131854.46acc5fb.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20140915233833.5bdd0725.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/6ZEYqHBKuQ_nyeKEg4PHtpN"; protocol="application/pgp-signature" X-Originating-IP: 92.225.112.153 X-ZEDAT-Hint: A Cc: Kevin Oberman , FreeBSD CURRENT , FreeBSD Questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 11:19:03 -0000 --Sig_/6ZEYqHBKuQ_nyeKEg4PHtpN Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Mon, 15 Sep 2014 18:25:34 -0700 Adrian Chadd schrieb: > Hi, >=20 > Try updating to the latest -HEAD. It at least makes dhclient behave bette= r. >=20 >=20 > -a >=20 >=20 > On 15 September 2014 18:19, Kevin Oberman wrote: > > On Mon, Sep 15, 2014 at 2:38 PM, O. Hartmann > > wrote: > > > >> > >> Trying to install and run FreeBSD 11.0-CURRENT > >> (FreeBSD-11.0-CURRENT-amd64-20140903-r270990-memstick.img) on a new Le= novo > >> E540 notebook > >> fails in activating the NIC (Realtek RTL8111/8168B, driver re[0]). The= NIC > >> shows up as > >> active and with carrier when issuing "ifconfig re0". > >> > >> From a desktop machine, I tried to ping the system in question and I g= et a > >> result with > >> missing packets: > >> > >> ping: sendto: Host is down > >> ping: sendto: Host is down > >> ping: sendto: Host is down > >> 64 bytes from 192.168.0.130: icmp_seq=3D26 ttl=3D64 time=3D0.114 ms > >> 64 bytes from 192.168.0.130: icmp_seq=3D41 ttl=3D64 time=3D0.130 ms > >> 64 bytes from 192.168.0.130: icmp_seq=3D60 ttl=3D64 time=3D0.119 ms > >> 64 bytes from 192.168.0.130: icmp_seq=3D80 ttl=3D64 time=3D0.119 ms > >> 64 bytes from 192.168.0.130: icmp_seq=3D100 ttl=3D64 time=3D0.105 ms > >> 64 bytes from 192.168.0.130: icmp_seq=3D116 ttl=3D64 time=3D0.135 ms > >> 64 bytes from 192.168.0.130: icmp_seq=3D136 ttl=3D64 time=3D0.091 ms > >> > >> DHCP configuration fails, since no DHCP offer is discovered. > >> > >> I swapped the switches, the cabling and I had always the same results.= I > >> used another > >> Laptop, Dell Latitude E6510 with the same configuration (/etc/rc.conf)= and > >> that system > >> gets DHCP offer and is online. > >> > >> Since the notebook is brandnew, the last thing I'll "suspect" is a > >> defective NIC, so I'll > >> ask whether this phenomenon is known - or, if not, the results > >> definititely would > >> indicate a broken NIC. > >> > >> Another point is the WiFI adaptor. This notebook is supposed to have a > >> WiFi NIC, but it > >> doesn't get revealed by FreeBSD (I tried iwn/iwi without success). > >> > >> pciconf output below, sorry for the messy shape, it is a copy-and-paste > >> from that immature > >> vt() terminal. > >> > >> Has anyone successfully installed that type of Notebook with FreeBSD > >> CURRENT using NIC > >> and Wifi? > >> > >> Please CC me. > >> > >> > >> Regards > >> oh > >> > >> > >> [...] > >> > >> none1@pci0:3:0:0: class=3D0xff0000 card=3D0x502817aa chip=3D0x52= 2710ec > >> rev=3D0x01 hdr=3D0x00 > >> > >> > >> vendor =3D 'Realtek Semiconductor Co., Ltd.' > >> > >> > >> bar [10] =3D type Memory, range 32, base 0xf1e00000, size 4096, = enabled > >> > >> > >> cap 01[40] =3D powerspec 3 supports D0 D1 D2 D3 current D0 > >> > >> > >> cap 05[50] =3D MSI supports 1 message, 64 bit > >> > >> > >> cap 10[70] =3D PCI-Express 2 endpoint max data 128(128) link x1(x1) > >> > >> > >> speed 2.5(2.5) ASPM L0s/L1(L0s/L1) > >> > >> > >> ecap 0001[100] =3D AER 2 0 fatal 0 non-fatal 0 corrected > >> > >> > >> ecap 0003[140] =3D Serial 1 00000001004ce000 > >> > >> > >> re0@pci0:4:0:0: class=3D0x020000 card=3D0x502817aa chip=3D0x816810ec r= ev=3D0x10 > >> hdr=3D0x00 > >> > >> > >> subclass =3D ethernet > >> > >> > >> cap 01[40] =3D powerspec 3 supports D0 D1 D2 D3 current > >> D0 > >> di sabled(L0s/L1) > >> > >> > >> cap 11[b0] =3D MSI-X supports 4 messages, enabled > >> > >> ecap 0001[100] =3D AER 2 0 fatal 0 non-fatal 4 corrected > >> > >> > >> > >> ecap 001e[178] =3D unknown 1 > >> > >> > >> class =3D network > >> > >> > >> cap 05[d0] =3D MSI supports 1 message, 64 bit > >> > >> > >> ecap 0003[140] =3D Serial 1 ac7ba1ffffa06fd6 > >> > > > > I can't comment on the WiFi, I have little Asus box using an 8111/8168B= and > > it works fine with the driver in 10.1-BETA. The driver in 10.0 recogniz= es > > the device, but did not work. I do notice that your NIC has a rev of 0x= 10 > > while mine is 0x0c. > > -- > > Kevin Oberman, Network Engineer, Retired In my local network (the laptop is working/getting installed in) I use jumb= o frames on several server system including the gateway (also FBSD CURRENT). After I manually set mtu > 1500 (in my case: mtu 6121) the NIC worked as ex= pected. My lab's Dell Latitude E6510 laptop (em0) works without setting explicit jumbo= frames. This is a kind of weird ... Thanks for your patience. Oliver --Sig_/6ZEYqHBKuQ_nyeKEg4PHtpN Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUGByjAAoJEOgBcD7A/5N8PVoH/1vTtuJ/DSZIuJQycl5jAIR5 Qgvc+pzXQUZvqxhX/lRVO3PC8Tv/AMa1cRBzgYbKWJ/0kJMzBSUlwRCuO1S2KDp8 YI+nIx6uycxKwQK6Y6Qn6wjsB0BhhccByJz6BtMaeEDmMcMQtuaLDMZTKTC07rdp kpVlYLQyiNyrav1Z9ysZw1BpbqutSkjrdCQS+gA/Qy6Bxp8NsCcxjNnpWGZFvww3 lw8Mt6xSRzBzIccoZN6HTuBZaegvKGQ9/thiW2CWwk3HIbtY32gIUoaBcbf7uyvc pIvVJoyGYJ3LgTN/c/lIBmJwLfb7DZ/IRS3NiiwWSGrcK37Ke1nRmkavaKJiHpI= =nBey -----END PGP SIGNATURE----- --Sig_/6ZEYqHBKuQ_nyeKEg4PHtpN-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 14:53:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 228B9390 for ; Tue, 16 Sep 2014 14:53:08 +0000 (UTC) Received: from mailhost.netlab.sk (mailhost.netlab.sk [84.245.65.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AC1039DF for ; Tue, 16 Sep 2014 14:53:07 +0000 (UTC) Received: from zeta.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan) by mailhost.netlab.sk with ESMTPA; Tue, 16 Sep 2014 16:53:00 +0200 id 00DD60F7.54184ECC.00014FA3 Date: Tue, 16 Sep 2014 16:52:57 +0200 From: Milan Obuch To: Nick Hibma Subject: Re: Huawei E3272 tester needed Message-ID: <20140916165257.3a0cee9b@zeta.dino.sk> In-Reply-To: References: X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; i386-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@FreeBSD.ORG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 14:53:08 -0000 On Tue, 16 Sep 2014 09:40:45 +0200 Nick Hibma wrote: > Hi, >=20 > Is there someone who is able to test support for the Huawei E3272 > card with CURRENT after 269584? I have not been able to confirm that > it works. >=20 > Thanks in advance. >=20 > Nick > Hi, I did fresh svn update, rebuilt world+kernel, but it does not work for me... =46rom log: ugen1.3: at usbus1 umass1: = on usbus1 cd2 at umass-sim1 bus 1 scbus7 target 0 lun 0 cd2: Removable CD-ROM SCSI-2 device cd2: 40.000MB/s transfers cd2: cd present [65536 x 2048 byte records] cd2: quirks=3D0x10<10_BYTE_ONLY> (cd2:umass-sim1:1:0:0): READ(10). CDB: 28 00 00 00 ff ff 00 00 01 00 (cd2:umass-sim1:1:0:0): CAM status: SCSI Status Error (cd2:umass-sim1:1:0:0): SCSI status: Check Condition (cd2:umass-sim1:1:0:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read= error) (cd2:umass-sim1:1:0:0): Info: 0xffff (cd2:umass-sim1:1:0:0): Error 5, Unretryable error (cd2:umass-sim1:1:0:0): cddone: got error 0x5 back ugen1.3: at usbus1 (disconnected) umass1: at uhub1, port 6, addr 3 (disconnected) cd2 at umass-sim1 bus 1 scbus7 target 0 lun 0 cd2: detached (cd2:umass-sim1:1:0:0): Periph destroyed I tried attach/detach device beore and after loading u3g (just in case...) and if_cdce kernel modules, but I saw no changes. =46rom 'usbconfig dump_device_desc': ugen1.3: at usbus1, cfg=3D0 md=3DHOST spd= =3DHIGH (480Mbps) pwr=3DON (500mA) bLength =3D 0x0012 bDescriptorType =3D 0x0001 bcdUSB =3D 0x0200 bDeviceClass =3D 0x0000 bDeviceSubClass =3D 0x0000 bDeviceProtocol =3D 0x0000 bMaxPacketSize0 =3D 0x0040 idVendor =3D 0x12d1 idProduct =3D 0x1f01 bcdDevice =3D 0x0102 iManufacturer =3D 0x0002 iProduct =3D 0x0001 iSerialNumber =3D 0x0004 bNumConfigurations =3D 0x0001 If anything else is important, let me know. Regards, Milan > The change: >=20 > Author: n_hibma > Date: Tue Aug 5 12:08:50 2014 > New Revision: 269584 > URL: http://svnweb.freebsd.org/changeset/base/269584 >=20 > Log: > Add support for Huawei E3272 modems which are supported by the CDC > ethernet class. >=20 > Note: This is untested as I do not have a device like this. That is > reflected in the MFC timeout. >=20 > PR: 192345 > Submitted by: rozhuk.im gmail.com > MFC after: 4 weeks >=20 > Modified: > head/sys/dev/usb/net/if_cdce.c > head/sys/dev/usb/usbdevs > From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 15:40:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44094403; Tue, 16 Sep 2014 15:40:27 +0000 (UTC) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E559DF29; Tue, 16 Sep 2014 15:40:26 +0000 (UTC) Received: by mail-qg0-f44.google.com with SMTP id f51so41251qge.3 for ; Tue, 16 Sep 2014 08:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=U1XDrNVguDwH6SxN8KclAlMO3SVkeWVFnfNWaCJkvSs=; b=qpQxyGSsQQPVVWefHP6garZ63qKitkth2D3ikc3SR6ntW9ZkT9+2BhHBM193w2obPZ 3wiMVFEtB5zBJvsyV7crD6NPuITbMESXGid9lB4zZYZlyfIH+E4ON5Zx1IxRrSOZ4ANh xVDj0Y+9tpkYNASxt92Naq7BEkYv6cf8Q6ZrUARE8pwWP5ue0+ByGqHVydWKR+v76F7z kM4W23bqsr/d+mCkQsWmydDNqWytSn7qeO0+YFASUDKBvW5e9LbR07pRT3NV8sGWK9p0 emKlYl73E1Aw96o6vyz7oFHrOX0TCMCHejqzW8+6+dV4PmPCrgPzBoAojy1u3O5x1vux fbIw== MIME-Version: 1.0 X-Received: by 10.224.88.198 with SMTP id b6mr20551437qam.37.1410882025998; Tue, 16 Sep 2014 08:40:25 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Tue, 16 Sep 2014 08:40:25 -0700 (PDT) In-Reply-To: <20140916131854.46acc5fb.ohartman@zedat.fu-berlin.de> References: <20140915233833.5bdd0725.ohartman@zedat.fu-berlin.de> <20140916131854.46acc5fb.ohartman@zedat.fu-berlin.de> Date: Tue, 16 Sep 2014 08:40:25 -0700 X-Google-Sender-Auth: WpLqu7o79FwLKvA-wgo4Zn3o3Ls Message-ID: Subject: Re: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI From: Adrian Chadd To: "O. Hartmann" Content-Type: text/plain; charset=UTF-8 Cc: Kevin Oberman , FreeBSD CURRENT , FreeBSD Questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 15:40:27 -0000 Ah, jumbo frames. Maybe you got lucky and some ethernet drivers default to accepting larger frames even if the MTU is 1500. -a From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 18:01:07 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A3554F0 for ; Tue, 16 Sep 2014 18:01:07 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 12F693EA for ; Tue, 16 Sep 2014 18:01:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s8GI168d026187 for ; Tue, 16 Sep 2014 18:01:06 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s8GI169L026186 for freebsd-current@freebsd.org; Tue, 16 Sep 2014 18:01:06 GMT (envelope-from bdrewery) Received: (qmail 99465 invoked from network); 16 Sep 2014 13:01:02 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 16 Sep 2014 13:01:02 -0500 Message-ID: <54187AD8.2040800@FreeBSD.org> Date: Tue, 16 Sep 2014 13:00:56 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: FreeBSD Current Subject: Daily head port building regression logs OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8VQkALjxBNBRjRSjWU8PQm28gKUJnJjL8" Cc: FreeBSD Ports Management Team X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 18:01:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8VQkALjxBNBRjRSjWU8PQm28gKUJnJjL8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I am planning to enable daily head build logs of ports to current@. The idea is that only new regressions will generate 1 mail with a list of failures. This list will only include *new* failures. It will not nag every day if some port is still broken. This will only work well if the ports tree used is stable and not causing the failures due to updates. We have a quarterly tree that is similar to a stable branch that we update less often. I will use this branch for the builds. I will not enable the actual mails until it has been tested to ensure it is not noisy and full of false-positives. This should help capture userland build regressions that are missed due to not exp-running changes in src. The caveat here is that the host kernel these builds are going on will remain on the normal monthly update cycle. This hopefully won't cause too many false-positives. I can always disable them temporarily or permanently should there be noise. It may be that this system will need to have its host auto updated daily as well. I'd rather not get into a constant brick-and-fix cycle though. --=20 Regards, Bryan Drewery on behalf of portmgr@ --8VQkALjxBNBRjRSjWU8PQm28gKUJnJjL8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUGHrcAAoJEDXXcbtuRpfPu+IH/iuskig57Pp3UM3ak676OAgV dxUnn0ZX3jbMPxTBwrOz7JqMy7p0YTddFL2UKN+dDFaqzB/g2h4yvkULxwrCsWu4 iM79l81u686yYbKZh/XvZ9JAz64g4Jxpvr6iYNTvB8hOU8vXq2qe5FQ/7vdkxUVD /uxscYCMGvMusJkpp+ohZhcmpNkTgdMeLJInXwiN5u+MY3os0yaqoSrFZaE5jXzR az7aKzFPpZyFahxR4OWsFgZQPna0EQ4p8uoQYheWq3CvW2ej7HVzsJiSSnoiMcV7 b8dT0d+E237zYKjUN810htlOylHPuVbFrOTxgO7tXXEFEqIv8Bu14UuQTM/biOE= =WM13 -----END PGP SIGNATURE----- --8VQkALjxBNBRjRSjWU8PQm28gKUJnJjL8-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 18:40:17 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3257E45 for ; Tue, 16 Sep 2014 18:40:17 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B418C9F9 for ; Tue, 16 Sep 2014 18:40:17 +0000 (UTC) Received: from [192.168.200.200] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 9077E1946DA for ; Tue, 16 Sep 2014 18:40:15 +0000 (UTC) Subject: New spam on all my current machine consoles From: Sean Bruno Reply-To: sbruno@freebsd.org To: freebsd-current Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Sep 2014 11:40:15 -0700 Message-ID: <1410892815.1106.0.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 18:40:17 -0000 HV_KVP: open /dev/hv_kvp_dev failed; error: 2 No such file or directory I assume that there is missing error handling in or logic here somewhere as every one of my machines is spamming my consoles on startup with this new message. sean From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 18:45:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 56A6814A; Tue, 16 Sep 2014 18:45:31 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2711CAE9; Tue, 16 Sep 2014 18:45:31 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id lf10so350976pab.8 for ; Tue, 16 Sep 2014 11:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=pzWvhSSo8/pJhyk6a6mYCuboJ1i+7aSQTgSGKiv3jaE=; b=eHylYeTRLVEQyH5og36cPi2JdqDXBjnWQ/6VuHCzloC7BTIrqa6+sPgyVHLUIsEqm6 zXMEPy/z2nbn2VCD1fQ9loBUOziWBkTx+EhXfW0OgS8ecyJnpTBUWWGxfNjD7nNlNXQ8 jnuZIKVkzgWf3ZRFBLv0GY2eqk1YLLYi8vohdubKFd226/xhhrcVMj4//Drwu9/9Pq+J 4h31IOSAqrQHcvD3SORTzKldbxQ4C8qlZYKwyqZWqtL6T3tLHsNEr+DQCCwuYh6YLOz5 tacIhWSMTAYiznmRkeqERT1UiR+SVwPhoKOCFEcCynpFSKpDPEw4NiI4b9Dye5dntJ3/ Yvdg== X-Received: by 10.70.34.104 with SMTP id y8mr24020791pdi.7.1410893130667; Tue, 16 Sep 2014 11:45:30 -0700 (PDT) Received: from [10.56.27.255] (mobile-166-137-213-106.mycingular.net. [166.137.213.106]) by mx.google.com with ESMTPSA id rg1sm14856422pdb.14.2014.09.16.11.45.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Sep 2014 11:45:29 -0700 (PDT) References: <1410892815.1106.0.camel@bruno> Mime-Version: 1.0 (1.0) In-Reply-To: <1410892815.1106.0.camel@bruno> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D257) From: Garrett Cooper Subject: Re: New spam on all my current machine consoles Date: Tue, 16 Sep 2014 11:45:27 -0700 To: "sbruno@freebsd.org" Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 18:45:31 -0000 > On Sep 16, 2014, at 11:40, Sean Bruno wrote: > > HV_KVP: open /dev/hv_kvp_dev failed; error: 2 No such file or directory > > I assume that there is missing error handling in or logic here somewhere > as every one of my machines is spamming my consoles on startup with this > new message. uname -a? From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 18:47:46 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03745278 for ; Tue, 16 Sep 2014 18:47:46 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D67B3B0D for ; Tue, 16 Sep 2014 18:47:45 +0000 (UTC) Received: from [192.168.200.200] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 494A91946CE; Tue, 16 Sep 2014 18:47:44 +0000 (UTC) Subject: Re: New spam on all my current machine consoles From: Sean Bruno Reply-To: sbruno@freebsd.org To: Garrett Cooper In-Reply-To: References: <1410892815.1106.0.camel@bruno> Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Sep 2014 11:47:44 -0700 Message-ID: <1410893264.1106.1.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 18:47:46 -0000 On Tue, 2014-09-16 at 11:45 -0700, Garrett Cooper wrote: > > On Sep 16, 2014, at 11:40, Sean Bruno wrote: > > > > HV_KVP: open /dev/hv_kvp_dev failed; error: 2 No such file or directory > > > > I assume that there is missing error handling in or logic here somewhere > > as every one of my machines is spamming my consoles on startup with this > > new message. > > uname -a? FreeBSD redbuild01.nyi.freebsd.org 11.0-CURRENT FreeBSD 11.0-CURRENT #9 r271631: Mon Sep 15 16:38:04 UTC 2014 sbruno@redbuild01.nyi.freebsd.org:/usr/obj/usr/src/sys/REDBUILD amd64 sean From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 18:58:05 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42E77456; Tue, 16 Sep 2014 18:58:05 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A93E5C0F; Tue, 16 Sep 2014 18:58:04 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s8GIvwf5052221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Sep 2014 21:57:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s8GIvwf5052221 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s8GIvwdn052220; Tue, 16 Sep 2014 21:57:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 16 Sep 2014 21:57:58 +0300 From: Konstantin Belousov To: sbruno@freebsd.org Subject: Re: New spam on all my current machine consoles Message-ID: <20140916185758.GZ2737@kib.kiev.ua> References: <1410892815.1106.0.camel@bruno> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DVQ8A37yL26ZH/UD" Content-Disposition: inline In-Reply-To: <1410892815.1106.0.camel@bruno> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 18:58:05 -0000 --DVQ8A37yL26ZH/UD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 16, 2014 at 11:40:15AM -0700, Sean Bruno wrote: > HV_KVP: open /dev/hv_kvp_dev failed; error: 2 No such file or directory >=20 > I assume that there is missing error handling in or logic here somewhere > as every one of my machines is spamming my consoles on startup with this > new message. This is after r271493. The hv_kvpd lacks 'NO' entry in the /etc/defaults/rc.conf. --DVQ8A37yL26ZH/UD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUGIg2AAoJEJDCuSvBvK1Bz48P/RlDrUjyvi0/Fc50AzCTbe9A TqwkyXTwDbPP2M9NoYt573z0s8x1McIjD7pmItcUp+3J5uvsUJd8IBvIKaxp+E46 uM9iLwhGMQtQU1WwzY6fKCoSTj9urCyUt3GRTR8njKbgoPwErEM+kVf2LdYKkizr rOKGI+JaXjKU8aKs0kW8EigPbYX3x66QJgY3DGO597AjwOk/623zkt3ZrTFInONz 7k+L9pR1LMAU0fQGuNmg/53KLXFS3aQgVhdqLiO0FwzfphFFC0fbNx98tWeTptqu sVEO9fvh0xdJ26qq8g04LT0qMZzQCER8XsloG41J8Bzw0Qkjr5sWmAJvd4atL9+e 1dEumLLq59Vm7V4MXkzKatN2rQW0VYO4+rGqXVzbOV99pI3GtlWnQJuShwMew2QL hs8cgSJ+/NybqifpxuqYo2AAnQtvbYp0ciRYegXrtO3K/vFmOyJsqbSpu+Cj6INR CJ20ZBWsIijpaphsw0VQiaG0dYBVZnKxnhdhfQOMwW+Izw6crpgZjhbliavPzM/I k9vFPfrxGS8Ne5vH4RwsfzDwHkSy4xwDxZyDY9v1Evicw3weVpcATNP24C0WlQ2y Q03GI/EX5nzorcCK8BYIhlWXeAp0FiD4FSmlX0IsVpY6NShnqJzlp5SBwEhmnaqN KLwI51lPZACUg276dTs0 =/EtC -----END PGP SIGNATURE----- --DVQ8A37yL26ZH/UD-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 19:08:56 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47A20C37 for ; Tue, 16 Sep 2014 19:08:56 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 26095D7F for ; Tue, 16 Sep 2014 19:08:55 +0000 (UTC) Received: from [192.168.200.200] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id E38801946CD; Tue, 16 Sep 2014 19:08:54 +0000 (UTC) Subject: Re: New spam on all my current machine consoles From: Sean Bruno Reply-To: sbruno@freebsd.org To: Konstantin Belousov In-Reply-To: <20140916185758.GZ2737@kib.kiev.ua> References: <1410892815.1106.0.camel@bruno> <20140916185758.GZ2737@kib.kiev.ua> Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Sep 2014 12:08:54 -0700 Message-ID: <1410894534.1166.3.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 19:08:56 -0000 On Tue, 2014-09-16 at 21:57 +0300, Konstantin Belousov wrote: > On Tue, Sep 16, 2014 at 11:40:15AM -0700, Sean Bruno wrote: > > HV_KVP: open /dev/hv_kvp_dev failed; error: 2 No such file or directory > > > > I assume that there is missing error handling in or logic here somewhere > > as every one of my machines is spamming my consoles on startup with this > > new message. > > This is after r271493. The hv_kvpd lacks 'NO' entry > in the /etc/defaults/rc.conf. Right, something like this should be added? Index: rc.conf =================================================================== --- rc.conf (revision 271679) +++ rc.conf (working copy) @@ -684,6 +684,8 @@ jail_parallel_start="NO" # Start jails in the background jail_list="" # Space separated list of names of jails +hv_kvpd_enable="NO" # Start the Hyper-V key-value Pair Driver hv_kvp(4) + ############################################################## ### Define source_rc_confs, the mechanism used by /etc/rc.* ## ### scripts to source rc_conf_files overrides safely. ## From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 19:27:51 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 863D08BF; Tue, 16 Sep 2014 19:27:51 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 27C9AF80; Tue, 16 Sep 2014 19:27:50 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s8GJRjI8059006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Sep 2014 22:27:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s8GJRjI8059006 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s8GJRjKK059005; Tue, 16 Sep 2014 22:27:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 16 Sep 2014 22:27:45 +0300 From: Konstantin Belousov To: sbruno@freebsd.org Subject: Re: New spam on all my current machine consoles Message-ID: <20140916192745.GA2737@kib.kiev.ua> References: <1410892815.1106.0.camel@bruno> <20140916185758.GZ2737@kib.kiev.ua> <1410894534.1166.3.camel@bruno> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U6cyWEHvdUv52/jb" Content-Disposition: inline In-Reply-To: <1410894534.1166.3.camel@bruno> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 19:27:51 -0000 --U6cyWEHvdUv52/jb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 16, 2014 at 12:08:54PM -0700, Sean Bruno wrote: > On Tue, 2014-09-16 at 21:57 +0300, Konstantin Belousov wrote: > > On Tue, Sep 16, 2014 at 11:40:15AM -0700, Sean Bruno wrote: > > > HV_KVP: open /dev/hv_kvp_dev failed; error: 2 No such file or directo= ry > > >=20 > > > I assume that there is missing error handling in or logic here somewh= ere > > > as every one of my machines is spamming my consoles on startup with t= his > > > new message. > >=20 > > This is after r271493. The hv_kvpd lacks 'NO' entry > > in the /etc/defaults/rc.conf. >=20 > Right, something like this should be added? Yes, assuming it indeed solves the issue. >=20 > Index: rc.conf > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- rc.conf (revision 271679) > +++ rc.conf (working copy) > @@ -684,6 +684,8 @@ > jail_parallel_start=3D"NO" # Start jails in the background > jail_list=3D"" # Space separated list of names of jails > =20 > +hv_kvpd_enable=3D"NO" # Start the Hyper-V key-value Pair Driver hv_kvp(4) > + > ############################################################## > ### Define source_rc_confs, the mechanism used by /etc/rc.* ## > ### scripts to source rc_conf_files overrides safely. ## >=20 --U6cyWEHvdUv52/jb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUGI8xAAoJEJDCuSvBvK1BBrAP/imFtz6cHYzZwwcnEWJNTCCl hZXrgCL67/pklR5BYQayfiKyjcPnazFE5Nja73RyUPRsu7zs9rMVfSMpWPYNvRuC WEe4bkANLHXojkCOwAKSKntoz7JEYdgNl0uRKYwrrwsYeuzdKaYDaZUvDvd7qgWu USoE2BZV3WdPQNeYcPh43I1NTCZyGEOEZm+kxRwe5UjOZWLiTW5ewJqv7z4Z6j5g zSvPSZJFEK+aUESR/u7+MSpA0nWUxa7kJeKa4GI2DbNMte2U4/FrfsGW9pRHgHQZ YaW0qOG6oHirG3mIYCeK33ARcPPwAny7Wwwv1bznXmLzESaH7v9sU5tTDpIMMB6f YKQkN04aO/21w8Y5C5mV/ZvP1wUzEuc86Mixk0NKcH+J8toXVcWVv4rDyJ4OZpPo jwN8GUYNkAmqBXJIEabxhgJGUNBDdSO1Gg4Y8BK8zeCkqDCO2SJk+v/pJbjufYAL eMZoMFKg2887JFgtYCrTZxf5pZu+DU9VX501X0nVRvXSPefQDbxKdEz9l60Xzi71 EpKvjhQ0YNWDb6EmGFjSwPWK7evy5kLYdGM1CpM6risz0j9Bm1PrhEnp1axDFheL qjVJwtZ8bv+N6ZvkBBkqS9dQUitW8Es2zFPAPnNyEONQA0x8YHRCRam5wuLUpaYn 8jZDG4KaBkn5va35ms4m =sTkW -----END PGP SIGNATURE----- --U6cyWEHvdUv52/jb-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 20:03:02 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD4EF484 for ; Tue, 16 Sep 2014 20:03:02 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB2C83FD for ; Tue, 16 Sep 2014 20:03:02 +0000 (UTC) Received: from [192.168.200.200] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id E14EF19413C; Tue, 16 Sep 2014 20:03:00 +0000 (UTC) Subject: Re: New spam on all my current machine consoles From: Sean Bruno Reply-To: sbruno@freebsd.org To: Konstantin Belousov In-Reply-To: <20140916192745.GA2737@kib.kiev.ua> References: <1410892815.1106.0.camel@bruno> <20140916185758.GZ2737@kib.kiev.ua> <1410894534.1166.3.camel@bruno> <20140916192745.GA2737@kib.kiev.ua> Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Sep 2014 13:03:00 -0700 Message-ID: <1410897780.1166.4.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 20:03:02 -0000 On Tue, 2014-09-16 at 22:27 +0300, Konstantin Belousov wrote: > On Tue, Sep 16, 2014 at 12:08:54PM -0700, Sean Bruno wrote: > > On Tue, 2014-09-16 at 21:57 +0300, Konstantin Belousov wrote: > > > On Tue, Sep 16, 2014 at 11:40:15AM -0700, Sean Bruno wrote: > > > > HV_KVP: open /dev/hv_kvp_dev failed; error: 2 No such file or directory > > > > > > > > I assume that there is missing error handling in or logic here somewhere > > > > as every one of my machines is spamming my consoles on startup with this > > > > new message. > > > > > > This is after r271493. The hv_kvpd lacks 'NO' entry > > > in the /etc/defaults/rc.conf. > > > > Right, something like this should be added? > Yes, assuming it indeed solves the issue. > > > > > > Index: rc.conf > > =================================================================== > > --- rc.conf (revision 271679) > > +++ rc.conf (working copy) > > @@ -684,6 +684,8 @@ > > jail_parallel_start="NO" # Start jails in the background > > jail_list="" # Space separated list of names of jails > > > > +hv_kvpd_enable="NO" # Start the Hyper-V key-value Pair Driver hv_kvp(4) > > + > > ############################################################## > > ### Define source_rc_confs, the mechanism used by /etc/rc.* ## > > ### scripts to source rc_conf_files overrides safely. ## > > Hopefully, I didn't make things worse? https://svnweb.freebsd.org/base?view=revision&revision=271688 sean From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 20:03:39 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69F265BB for ; Tue, 16 Sep 2014 20:03:39 +0000 (UTC) Received: from man.dat.pl (dat.pl [80.51.155.34]) by mx1.freebsd.org (Postfix) with ESMTP id 2662A5E9 for ; Tue, 16 Sep 2014 20:03:38 +0000 (UTC) Received: from man.dat.pl (localhost [127.0.0.1]) by man.dat.pl (Postfix) with ESMTP id 50EC2D16A4C; Tue, 16 Sep 2014 21:55:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at dat.pl Received: from man.dat.pl ([127.0.0.1]) by man.dat.pl (man.dat.pl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KVFI1RhkT3j1; Tue, 16 Sep 2014 21:55:51 +0200 (CEST) Message-ID: <541895C6.3030304@dat.pl> Date: Tue, 16 Sep 2014 21:55:50 +0200 From: Maciej Milewski MIME-Version: 1.0 To: Milan Obuch , Nick Hibma Subject: Re: Huawei E3272 tester needed References: <20140916165257.3a0cee9b@zeta.dino.sk> In-Reply-To: <20140916165257.3a0cee9b@zeta.dino.sk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 20:03:39 -0000 On 16.09.2014 16:52, Milan Obuch wrote: > On Tue, 16 Sep 2014 09:40:45 +0200 > Nick Hibma wrote: > >> Hi, >> >> Is there someone who is able to test support for the Huawei E3272 >> card with CURRENT after 269584? I have not been able to confirm that >> it works. >> >> Thanks in advance. >> >> Nick >> > Hi, > > I did fresh svn update, rebuilt world+kernel, but it does not work for > me... > > From log: > > ugen1.3: at usbus1 > umass1: on usbus1 > cd2 at umass-sim1 bus 1 scbus7 target 0 lun 0 > cd2: Removable CD-ROM SCSI-2 device > cd2: 40.000MB/s transfers > cd2: cd present [65536 x 2048 byte records] > cd2: quirks=0x10<10_BYTE_ONLY> > (cd2:umass-sim1:1:0:0): READ(10). CDB: 28 00 00 00 ff ff 00 00 01 00 > (cd2:umass-sim1:1:0:0): CAM status: SCSI Status Error > (cd2:umass-sim1:1:0:0): SCSI status: Check Condition > (cd2:umass-sim1:1:0:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read error) > (cd2:umass-sim1:1:0:0): Info: 0xffff > (cd2:umass-sim1:1:0:0): Error 5, Unretryable error > (cd2:umass-sim1:1:0:0): cddone: got error 0x5 back > > ugen1.3: at usbus1 (disconnected) > umass1: at uhub1, port 6, addr 3 (disconnected) > cd2 at umass-sim1 bus 1 scbus7 target 0 lun 0 > cd2: detached > (cd2:umass-sim1:1:0:0): Periph destroyed > > I tried attach/detach device beore and after loading u3g (just in > case...) and if_cdce kernel modules, but I saw no changes. > > From 'usbconfig dump_device_desc': > > ugen1.3: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) > > bLength = 0x0012 > bDescriptorType = 0x0001 > bcdUSB = 0x0200 > bDeviceClass = 0x0000 > bDeviceSubClass = 0x0000 > bDeviceProtocol = 0x0000 > bMaxPacketSize0 = 0x0040 > idVendor = 0x12d1 > idProduct = 0x1f01 > bcdDevice = 0x0102 > iManufacturer = 0x0002 > iProduct = 0x0001 > iSerialNumber = 0x0004 > bNumConfigurations = 0x0001 > > If anything else is important, let me know. > > Regards, > Milan Try ejecting first this cd2 drive by cdcontrol eject or camcontrol eject. I had such scenario with other usb device and that helped. -- Pozdrawiam, Maciej Milewski From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 20:18:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1CC6A84D for ; Tue, 16 Sep 2014 20:18:17 +0000 (UTC) Received: from mailhost.netlab.sk (mailhost.netlab.sk [84.245.65.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E49375E for ; Tue, 16 Sep 2014 20:18:16 +0000 (UTC) Received: from zeta.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan) by mailhost.netlab.sk with ESMTPA; Tue, 16 Sep 2014 22:18:17 +0200 id 00DD6020.54189B09.00016E49 Date: Tue, 16 Sep 2014 22:18:12 +0200 From: Milan Obuch To: milu@dat.pl Subject: Re: Huawei E3272 tester needed Message-ID: <20140916221812.649a1756@zeta.dino.sk> In-Reply-To: <541895C6.3030304@dat.pl> References: <20140916165257.3a0cee9b@zeta.dino.sk> <541895C6.3030304@dat.pl> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; i386-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@FreeBSD.ORG, nick@van-laarhoven.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 20:18:17 -0000 On Tue, 16 Sep 2014 21:55:50 +0200 Maciej Milewski wrote: > On 16.09.2014 16:52, Milan Obuch wrote: > > On Tue, 16 Sep 2014 09:40:45 +0200 > > Nick Hibma wrote: > > > >> Hi, > >> > >> Is there someone who is able to test support for the Huawei E3272 > >> card with CURRENT after 269584? I have not been able to confirm > >> that it works. > >> > >> Thanks in advance. > >> > >> Nick > >> > > Hi, > > > > I did fresh svn update, rebuilt world+kernel, but it does not work > > for me... [ snip ] > > I tried attach/detach device beore and after loading u3g (just in > > case...) and if_cdce kernel modules, but I saw no changes. > > > > From 'usbconfig dump_device_desc': > > > > ugen1.3: at usbus1, cfg=3D0 md=3DHOST > > spd=3DHIGH (480Mbps) pwr=3DON (500mA) > > > > bLength =3D 0x0012 > > bDescriptorType =3D 0x0001 > > bcdUSB =3D 0x0200 > > bDeviceClass =3D 0x0000 > > bDeviceSubClass =3D 0x0000 > > bDeviceProtocol =3D 0x0000 > > bMaxPacketSize0 =3D 0x0040 > > idVendor =3D 0x12d1 > > idProduct =3D 0x1f01 > > bcdDevice =3D 0x0102 > > iManufacturer =3D 0x0002 > > iProduct =3D 0x0001 > > iSerialNumber =3D 0x0004 > > bNumConfigurations =3D 0x0001 > > > > If anything else is important, let me know. > > > > Regards, > > Milan > > Try ejecting first this cd2 drive by cdcontrol eject or camcontrol > eject. I had such scenario with other usb device and that helped. >=20 Nothing. # camcontrol eject cd2 Unit stopped successfully, Media ejected That's all. No new device created, neither in /dev directory nor in ifconfig listing. Nothing in console log. =46rom 'usbconfig dump_all_config_desc': ugen1.3: at usbus1, cfg=3D0 md=3DHOST spd= =3DHIGH (480Mbps) pwr=3DON (500mA) Configuration index 0 bLength =3D 0x0009=20 bDescriptorType =3D 0x0002=20 wTotalLength =3D 0x0020=20 bNumInterfaces =3D 0x0001=20 bConfigurationValue =3D 0x0001=20 iConfiguration =3D 0x0003 bmAttributes =3D 0x0080=20 bMaxPower =3D 0x00fa=20 Interface 0 bLength =3D 0x0009=20 bDescriptorType =3D 0x0004=20 bInterfaceNumber =3D 0x0000=20 bAlternateSetting =3D 0x0000=20 bNumEndpoints =3D 0x0002=20 bInterfaceClass =3D 0x0008=20 bInterfaceSubClass =3D 0x0006=20 bInterfaceProtocol =3D 0x0050=20 iInterface =3D 0x0000 Endpoint 0 bLength =3D 0x0007=20 bDescriptorType =3D 0x0005=20 bEndpointAddress =3D 0x0001 bmAttributes =3D 0x0002 wMaxPacketSize =3D 0x0200=20 bInterval =3D 0x0000=20 bRefresh =3D 0x0000=20 bSynchAddress =3D 0x0000=20 Endpoint 1 bLength =3D 0x0007=20 bDescriptorType =3D 0x0005=20 bEndpointAddress =3D 0x0081 bmAttributes =3D 0x0002 wMaxPacketSize =3D 0x0200=20 bInterval =3D 0x0000=20 bRefresh =3D 0x0000=20 bSynchAddress =3D 0x0000=20 Regards, Milan From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 20:35:34 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B136CE16 for ; Tue, 16 Sep 2014 20:35:34 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6E36B93D for ; Tue, 16 Sep 2014 20:35:34 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id DA98D24800B; Tue, 16 Sep 2014 22:35:30 +0200 (CEST) Message-ID: <54189F07.7010301@selasky.org> Date: Tue, 16 Sep 2014 22:35:19 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Milan Obuch , milu@dat.pl Subject: Re: Huawei E3272 tester needed References: <20140916165257.3a0cee9b@zeta.dino.sk> <541895C6.3030304@dat.pl> <20140916221812.649a1756@zeta.dino.sk> In-Reply-To: <20140916221812.649a1756@zeta.dino.sk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG, nick@van-laarhoven.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 20:35:34 -0000 On 09/16/14 22:18, Milan Obuch wrote: > On Tue, 16 Sep 2014 21:55:50 +0200 > Maciej Milewski wrote: > >> On 16.09.2014 16:52, Milan Obuch wrote: >>> On Tue, 16 Sep 2014 09:40:45 +0200 >>> Nick Hibma wrote: >>> >>>> Hi, >>>> >>>> Is there someone who is able to test support for the Huawei E3272 >>>> card with CURRENT after 269584? I have not been able to confirm >>>> that it works. >>>> >>>> Thanks in advance. >>>> >>>> Nick >>>> >>> Hi, >>> >>> I did fresh svn update, rebuilt world+kernel, but it does not work >>> for me... > > [ snip ] > Hi, According to the modeswitch: usbconfig -d X.Y add_quirk UQ_MSC_EJECT_HUAWEISCSI2 Then re-plug the device. --HPS From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 20:43:38 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02FFE1BA for ; Tue, 16 Sep 2014 20:43:38 +0000 (UTC) Received: from man.dat.pl (dat.pl [80.51.155.34]) by mx1.freebsd.org (Postfix) with ESMTP id 7A1C3A2D for ; Tue, 16 Sep 2014 20:43:37 +0000 (UTC) Received: from man.dat.pl (localhost [127.0.0.1]) by man.dat.pl (Postfix) with ESMTP id 9A1CED16A4C; Tue, 16 Sep 2014 22:43:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at dat.pl Received: from man.dat.pl ([127.0.0.1]) by man.dat.pl (man.dat.pl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DiEr6ZncIMV2; Tue, 16 Sep 2014 22:43:34 +0200 (CEST) Message-ID: <5418A0F6.6020207@dat.pl> Date: Tue, 16 Sep 2014 22:43:34 +0200 From: Maciej Milewski MIME-Version: 1.0 To: Milan Obuch Subject: Re: Huawei E3272 tester needed References: <20140916165257.3a0cee9b@zeta.dino.sk> <541895C6.3030304@dat.pl> <20140916221812.649a1756@zeta.dino.sk> In-Reply-To: <20140916221812.649a1756@zeta.dino.sk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@FreeBSD.ORG, nick@van-laarhoven.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 20:43:38 -0000 On 16.09.2014 22:18, Milan Obuch wrote: > On Tue, 16 Sep 2014 21:55:50 +0200 > Maciej Milewski wrote: > >> On 16.09.2014 16:52, Milan Obuch wrote: >>> On Tue, 16 Sep 2014 09:40:45 +0200 >>> Nick Hibma wrote: >>> >>>> Hi, >>>> >>>> Is there someone who is able to test support for the Huawei E3272 >>>> card with CURRENT after 269584? I have not been able to confirm >>>> that it works. >>>> >>>> Thanks in advance. >>>> >>>> Nick >>>> >>> Hi, >>> >>> I did fresh svn update, rebuilt world+kernel, but it does not work >>> for me... > [ snip ] > >>> I tried attach/detach device beore and after loading u3g (just in >>> case...) and if_cdce kernel modules, but I saw no changes. >>> >>> From 'usbconfig dump_device_desc': >>> >>> ugen1.3: at usbus1, cfg=3D0 md=3DHO= ST >>> spd=3DHIGH (480Mbps) pwr=3DON (500mA) >>> >>> bLength =3D 0x0012 >>> bDescriptorType =3D 0x0001 >>> bcdUSB =3D 0x0200 >>> bDeviceClass =3D 0x0000 >>> bDeviceSubClass =3D 0x0000 >>> bDeviceProtocol =3D 0x0000 >>> bMaxPacketSize0 =3D 0x0040 >>> idVendor =3D 0x12d1 >>> idProduct =3D 0x1f01 >>> bcdDevice =3D 0x0102 >>> iManufacturer =3D 0x0002 >>> iProduct =3D 0x0001 >>> iSerialNumber =3D 0x0004 >>> bNumConfigurations =3D 0x0001 >>> >>> If anything else is important, let me know. >>> >>> Regards, >>> Milan >> Try ejecting first this cd2 drive by cdcontrol eject or camcontrol >> eject. I had such scenario with other usb device and that helped. >> > Nothing. > > # camcontrol eject cd2 > Unit stopped successfully, Media ejected > > That's all. No new device created, neither in /dev directory nor in > ifconfig listing. Nothing in console log. > > From 'usbconfig dump_all_config_desc': > > ugen1.3: at usbus1, cfg=3D0 md=3DHOST= spd=3DHIGH (480Mbps) pwr=3DON (500mA) > > Configuration index 0 > > bLength =3D 0x0009=20 > bDescriptorType =3D 0x0002=20 > wTotalLength =3D 0x0020=20 > bNumInterfaces =3D 0x0001=20 > bConfigurationValue =3D 0x0001=20 > iConfiguration =3D 0x0003 > bmAttributes =3D 0x0080=20 > bMaxPower =3D 0x00fa=20 > > Interface 0 > bLength =3D 0x0009=20 > bDescriptorType =3D 0x0004=20 > bInterfaceNumber =3D 0x0000=20 > bAlternateSetting =3D 0x0000=20 > bNumEndpoints =3D 0x0002=20 > bInterfaceClass =3D 0x0008=20 > bInterfaceSubClass =3D 0x0006=20 > bInterfaceProtocol =3D 0x0050=20 > iInterface =3D 0x0000 > > Endpoint 0 > bLength =3D 0x0007=20 > bDescriptorType =3D 0x0005=20 > bEndpointAddress =3D 0x0001 > bmAttributes =3D 0x0002 > wMaxPacketSize =3D 0x0200=20 > bInterval =3D 0x0000=20 > bRefresh =3D 0x0000=20 > bSynchAddress =3D 0x0000=20 > > Endpoint 1 > bLength =3D 0x0007=20 > bDescriptorType =3D 0x0005=20 > bEndpointAddress =3D 0x0081 > bmAttributes =3D 0x0002 > wMaxPacketSize =3D 0x0200=20 > bInterval =3D 0x0000=20 > bRefresh =3D 0x0000=20 > bSynchAddress =3D 0x0000=20 > > Regards, > Milan Your device has different idProduct than this added in patch. It might be caused by different configuration of the device/different provider who sells devices. I know that some devices might show up as HiLink mode(cdce) or serial mode(u3g). And this might be changed by flashing different firmware or sometimes by using usb_modeswitch(under linux not sure if it works under freebsd). Example is here: https://forum.pfsense.org/index.php?topic=3D48780.20;wap= 2 --=20 Pozdrawiam, Maciej Milewski From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 20:52:09 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B4C2816 for ; Tue, 16 Sep 2014 20:52:09 +0000 (UTC) Received: from mailhost.netlab.sk (mailhost.netlab.sk [84.245.65.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8AD09B14 for ; Tue, 16 Sep 2014 20:52:07 +0000 (UTC) Received: from zeta.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan) by mailhost.netlab.sk with ESMTPA; Tue, 16 Sep 2014 22:52:09 +0200 id 00DD60F4.5418A2F9.000171D6 Date: Tue, 16 Sep 2014 22:52:05 +0200 From: Milan Obuch To: Hans Petter Selasky Subject: Re: Huawei E3272 tester needed Message-ID: <20140916225205.6d7a8bac@zeta.dino.sk> In-Reply-To: <54189F07.7010301@selasky.org> References: <20140916165257.3a0cee9b@zeta.dino.sk> <541895C6.3030304@dat.pl> <20140916221812.649a1756@zeta.dino.sk> <54189F07.7010301@selasky.org> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; i386-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG, milu@dat.pl, nick@van-laarhoven.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 20:52:09 -0000 On Tue, 16 Sep 2014 22:35:19 +0200 Hans Petter Selasky wrote: > On 09/16/14 22:18, Milan Obuch wrote: > > On Tue, 16 Sep 2014 21:55:50 +0200 > > Maciej Milewski wrote: > > > >> On 16.09.2014 16:52, Milan Obuch wrote: > >>> On Tue, 16 Sep 2014 09:40:45 +0200 > >>> Nick Hibma wrote: > >>> > >>>> Hi, > >>>> > >>>> Is there someone who is able to test support for the Huawei E3272 > >>>> card with CURRENT after 269584? I have not been able to confirm > >>>> that it works. > >>>> > >>>> Thanks in advance. > >>>> > >>>> Nick > >>>> > >>> Hi, > >>> > >>> I did fresh svn update, rebuilt world+kernel, but it does not work > >>> for me... > > > > [ snip ] > > > > Hi, > > According to the modeswitch: > > usbconfig -d X.Y add_quirk UQ_MSC_EJECT_HUAWEISCSI2 > > Then re-plug the device. > > --HPS > Well, again, no change: #usbconfig -d 1.3 add_quirk UQ_MSC_EJECT_HUAWEISCSI2 Adding quirk 'UQ_MSC_EJECT_HUAWEISCSI2' failed, continuing. Did I do it right? Something is surely wrong. By the way, from uname: 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271671M The only modified file is modules/drm2/Makefile because for some reason radeonkms does not currently build, so I excluded is as a fast workaround. Milan From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 20:53:54 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0558D98A for ; Tue, 16 Sep 2014 20:53:54 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B4590B50 for ; Tue, 16 Sep 2014 20:53:53 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1XTzl1-0038pk-N9>; Tue, 16 Sep 2014 22:53:51 +0200 Received: from g226063043.adsl.alicedsl.de ([92.226.63.43] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1XTzl1-0020mA-JK>; Tue, 16 Sep 2014 22:53:51 +0200 Date: Tue, 16 Sep 2014 22:53:46 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: zpool: multiple IDs, CURRENT drops all pools after reboot Message-ID: <20140916225346.10e0d4ae.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/i94o0.oCEUMhQ/w=N0rNfrp"; protocol="application/pgp-signature" X-Originating-IP: 92.226.63.43 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 20:53:54 -0000 --Sig_/i94o0.oCEUMhQ/w=N0rNfrp Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On of my backup drives dedicated to a ZPOOL is faulting and showing up mult= iple ID. The only working ID is id: 257822624560506537. FreeBSD CURRENT with three ZFS disks and only 4GB of RAM is very "flaky" re= garding this issue: today, tow times the whole poolset vanishes after a reboot. Giving t= he box 8 GB total and rebooting doens't show the problem, it gets more frequent when re= ducing the RAM to 4GB (FreeBSD 11.0-CURRENT #2 r271684: Tue Sep 16 20:41:47 CEST 2014). Th= is is a bit spooky. Below the faulted harddrive. I guess the drive/pool below shown triggers so= mehow the loss of all other pools (I have to import the other pools, which do not have any= defects, but they they drop out after a reboot and vanish). Is there a way getting rid of the faulty IDs without destroying the pool? Regards, Oliver=20 root@thor: [/etc] zpool import pool: BACKUP00 id: 9337833315545958689 state: FAULTED status: One or more devices contains corrupted data. action: The pool cannot be imported due to damaged devices or data. The pool may be active on another system, but can be imported using the '-f' flag. see: http://illumos.org/msg/ZFS-8000-5E config: BACKUP00 FAULTED corrupted data 8544670861382329237 UNAVAIL corrupted data pool: BACKUP00 id: 257822624560506537 state: ONLINE action: The pool can be imported using its name or numeric identifier. config: BACKUP00 ONLINE ada3p1 ONLINE --Sig_/i94o0.oCEUMhQ/w=N0rNfrp Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUGKNfAAoJEOgBcD7A/5N87joIAM2KLsxVudGsfXgf0gIUAst4 O6ELU8VRuoVoql+xyBNMIx6b5h9LfLe7/j5AB9ODFlX3bgsFCBDS81Fqbhb43ner H+AOpl51+TpUT6U/uSN4rxKAw7ZyL1DZRYZXFVTKhOcKctjwVgzD0BuKCQMEhobH 2NSYXFOxwU6GjzywkE8eiEAliJsyzmX5QNma3qj/ysQ1OU8JXxl1SpiZQBV1/HVQ NmuJ0vtKChdwiFuxnZoFMtozK2W3IZmQccKvSB2NxkFZ2rDpTW2bwdZgGyteI25h 7cjX9RzdEhEYWdTt33CEmYTkAeY0u274Jyxgbd1GcPY2FLjZHymluT19PSOConY= =9dnJ -----END PGP SIGNATURE----- --Sig_/i94o0.oCEUMhQ/w=N0rNfrp-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 21:03:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F4019BDF; Tue, 16 Sep 2014 21:03:50 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AACF3C50; Tue, 16 Sep 2014 21:03:50 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XTzuf-003AnT-2B>; Tue, 16 Sep 2014 23:03:49 +0200 Received: from g226063043.adsl.alicedsl.de ([92.226.63.43] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XTzue-0022bV-UH>; Tue, 16 Sep 2014 23:03:49 +0200 Date: Tue, 16 Sep 2014 23:03:48 +0200 From: "O. Hartmann" To: Nathan Whitehorn Subject: Re: CURRENT: EFI boot failure Message-ID: <20140916230348.189e80cd.ohartman@zedat.fu-berlin.de> In-Reply-To: <5417E20D.8070607@freebsd.org> References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> <5417E20D.8070607@freebsd.org> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/lACDfITHnKiGm8K.pSJ3pYL"; protocol="application/pgp-signature" X-Originating-IP: 92.226.63.43 X-ZEDAT-Hint: A Cc: freebsd-current@freebsd.org, Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 21:03:51 -0000 --Sig_/lACDfITHnKiGm8K.pSJ3pYL Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tue, 16 Sep 2014 00:09:01 -0700 Nathan Whitehorn schrieb: >=20 > On 09/15/14 22:51, O. Hartmann wrote: > > Am Mon, 15 Sep 2014 17:39:26 -0700 > > Nathan Whitehorn schrieb: > > > >> On 09/15/14 17:36, Allan Jude wrote: > >>> On 2014-09-15 20:05, O. Hartmann wrote: > >>>> Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop w= orks for UEFI > >>>> fine. After I updated the sources to r271649, recompiled world and = kernel (as well > >>>> as installed), now I get stuck with the screen message: > >>>> > >>>>>> FreeBSD EFI boot block > >>>> Loader path: /boot/loader.efi > >>>> > >>>> and nothing happens. After a couple of minutes, the system reboots. > >>>> > >>>> What happened and how can this problem be solved? > >>>> > >>> You might need to update the boot1.efi file on the UEFI partition (sm= all > >>> FAT partition on the disk) > >>> > >>> I am not sure how 'in sync' boot1.efi (on the fat partiton) and > >>> loader.efi have to be. > >>> > >>> https://wiki.freebsd.org/UEFI > >>> > >> boot1.efi is designed never to need updating. (It also hasn't changed > >> since April) > >> -Nathan > > > > But it has changed bytesize when I recompiled world with recent sources= compared to > > the boot.efi size from the USB image I installed from (revision see abo= ve). >=20 > Probably compiler updates or something? I really wouldn't worry about it= =20 > too much. I'd worry more about loader, since we know boot1 could use the= =20 > console but loader doesn't show up. Well, I have to worry about because the system is stuck and completely unus= able. I installed the system from the very same USB drive image as mentioned abov= e again. Then, after the newtork issue has been fixed, I was able to update sources and bu= ilt world. As long as I do not attempt to use to use X, everything is fine. >=20 > > How to update bootcode on UEFI layout? I created a GPT partition with t= ype efi (1 GB) > > as well as a 512KB partition typed freebsd-boot. >=20 > How did you set it up in the first place? If you have a FreeBSD-only=20 > system partition (like the installer sets up), you just dd=20 > /boot/boot1.efifat to the EFI partition. Otherwise, it's FAT and you=20 > copy /boot/boot1.efi to somewhere your boot manager can find it. The setup was plain and vanilla. I used the installer of the USB image (see= above). Creating GPT partition scheme and two partitions of type "efi" and "freebsd= -boot", first 1MB, latter 512KB. All other partitions are freebsd-ufs, exept freebsd-swap. In that case, is it still /boot/boot1.efifat or is it /boot/boot1.efi? What= is the difference? Is the efi partition FAT? >=20 > > I'm new to EFI and the way the notebook now behaves is really strange. = While the USB > > drive image used to boot with new console enabled, it now boots again w= ith the old > > console and 800x640 resolution. This might indicate some minor but very= effective > > mistake I made. > > >=20 > The EFI boot block finds the first UFS partition -- on any disk -- and=20 > tries to boot from it. If you have multiple FreeBSD disks connected,=20 > that will very likely result in madness. > -Nathan It is one disk, dedicated to FreeBSD (a laptop disk). Is there any document= ation readable for non-developer for that matter? I'm curious about how EFI works on FreeB= SD. Oliver --Sig_/lACDfITHnKiGm8K.pSJ3pYL Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUGKW0AAoJEOgBcD7A/5N8XMUIAJfbI1Jps3JvtiY6wBjks1m4 4BPB7UU4g29hWTT0da1/z6akJ0dFk/CXQfIpieWGeDBsm9OfQzOJ2N5N1GA89B34 9/CppeByLASK8VMphOEOSO5lv4ijCDGA3Bzs/TvIbVZketqBJmNHZ3mGTt85vfh/ /isZZdx17jZvuMGJyoCE4g0pNjh5ybJGXmoQeYwLIuOMt9COmh3mOVZhLN3tFow7 cmsboAUEluE9YmNteFceV6X3doYSpQwRT7SvdyJUHNQBmMD/6nz+A3yGq78zsCWl OxC7evQnIGUJAaILYosNxmw/q1+MOx5w/uOAk9Gx7KRgY5uaFk2SXEmHbdLjl1o= =efCy -----END PGP SIGNATURE----- --Sig_/lACDfITHnKiGm8K.pSJ3pYL-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 21:04:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58C0ACE6; Tue, 16 Sep 2014 21:04:39 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 12439C5E; Tue, 16 Sep 2014 21:04:39 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XTzvR-003AzM-Gq>; Tue, 16 Sep 2014 23:04:37 +0200 Received: from g226063043.adsl.alicedsl.de ([92.226.63.43] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XTzvR-0022m4-Ek>; Tue, 16 Sep 2014 23:04:37 +0200 Date: Tue, 16 Sep 2014 23:04:36 +0200 From: "O. Hartmann" To: Allan Jude Subject: Re: CURRENT: EFI boot failure Message-ID: <20140916230436.42c1cb12.ohartman@zedat.fu-berlin.de> In-Reply-To: <54178607.1060305@freebsd.org> References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/at1LiMzDcY+kDKQC84ry8mF"; protocol="application/pgp-signature" X-Originating-IP: 92.226.63.43 X-ZEDAT-Hint: A Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 21:04:39 -0000 --Sig_/at1LiMzDcY+kDKQC84ry8mF Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Mon, 15 Sep 2014 20:36:23 -0400 Allan Jude schrieb: > On 2014-09-15 20:05, O. Hartmann wrote: > >=20 > > Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop work= s for UEFI > > fine. After I updated the sources to r271649, recompiled world and ker= nel (as well as > > installed), now I get stuck with the screen message: > >=20 > >>> FreeBSD EFI boot block > > Loader path: /boot/loader.efi > >=20 > > and nothing happens. After a couple of minutes, the system reboots. > >=20 > > What happened and how can this problem be solved? > >=20 >=20 > You might need to update the boot1.efi file on the UEFI partition (small > FAT partition on the disk) >=20 > I am not sure how 'in sync' boot1.efi (on the fat partiton) and > loader.efi have to be. >=20 > https://wiki.freebsd.org/UEFI >=20 Is it boot1.efi or is it boot1.efifat? --Sig_/at1LiMzDcY+kDKQC84ry8mF Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUGKXlAAoJEOgBcD7A/5N8vL8IAIIVIWrqBjUOJiyWNtmUl7DJ aCJoCQN0iilXttpaY338BNUVNUSU0ov6N6wKHDQBmJKbPbNyngsikmoGFxGSez2u 0Dog7aRIPHYZ6TRLEEzbMEHibF1HXU8OhSVdOj8oSRZn/UL5c0eyCPNESvbvDlX0 UUHan4XvPlw1hnZJvqJbTdPxpxeDVJdHu7mdIO5htfef8xIjSwfe478Mo+N55EY6 MjyGnXmg7OUE/0G47VgsYMe2TpB92FH2dnRlp70Slazw6W/Sh1QsGOf75Sw07pNb mhTG0ipKBko32LE3/+ZUk6b1V3aLMBfoIF/s6kWZWS/EvVtz4F0v1f4y/JA8Vuc= =p4V6 -----END PGP SIGNATURE----- --Sig_/at1LiMzDcY+kDKQC84ry8mF-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 21:06:44 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3CC1FE14 for ; Tue, 16 Sep 2014 21:06:44 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id F4095C82 for ; Tue, 16 Sep 2014 21:06:43 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 6B34D20E7088D; Tue, 16 Sep 2014 21:06:41 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id B464F20E70886; Tue, 16 Sep 2014 21:06:39 +0000 (UTC) Message-ID: <27D574A82A374C2DAB8648ED7D2FDCD2@multiplay.co.uk> From: "Steven Hartland" To: "O. Hartmann" , "FreeBSD CURRENT" References: <20140916225346.10e0d4ae.ohartman@zedat.fu-berlin.de> Subject: Re: zpool: multiple IDs, CURRENT drops all pools after reboot Date: Tue, 16 Sep 2014 22:06:36 +0100 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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 21:06:44 -0000 > On of my backup drives dedicated to a ZPOOL is faulting and showing up multiple ID. The > only working ID is id: 257822624560506537. > > FreeBSD CURRENT with three ZFS disks and only 4GB of RAM is very "flaky" regarding this > issue: today, tow times the whole poolset vanishes after a reboot. Giving the box 8 GB > total and rebooting doens't show the problem, it gets more frequent when reducing the RAM > to 4GB (FreeBSD 11.0-CURRENT #2 r271684: Tue Sep 16 20:41:47 CEST 2014). This is a bit > spooky. > > Below the faulted harddrive. I guess the drive/pool below shown triggers somehow the loss > of all other pools (I have to import the other pools, which do not have any defects, but > they they drop out after a reboot and vanish). > > Is there a way getting rid of the faulty IDs without destroying the pool? > > Regards, > > Oliver > > root@thor: [/etc] zpool import > pool: BACKUP00 > id: 9337833315545958689 > state: FAULTED > status: One or more devices contains corrupted data. > action: The pool cannot be imported due to damaged devices or data. > The pool may be active on another system, but can be imported using > the '-f' flag. > see: http://illumos.org/msg/ZFS-8000-5E > config: > > BACKUP00 FAULTED corrupted data > 8544670861382329237 UNAVAIL corrupted data > > pool: BACKUP00 > id: 257822624560506537 > state: ONLINE > action: The pool can be imported using its name or numeric identifier. > config: > > BACKUP00 ONLINE > ada3p1 ONLINE > Might be a long shot but check out the patches on: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 Specifically: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147070 And if that doesn't work: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147286 The second has all the changes from the first with the addition of some changes which dynamically size the max dirty data. These changes are in discussion and its likely the additions in the second patch aren't the right direction but they have been reported to show good improvements under high memory pressure for certain workloads, so would be interesting to see if they help with your problem. All that said you shouldnt end up with corrupt data no matter what. Are there any other symptoms? Has memory been checked for faults etc? Regards Steve From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 21:32:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AABF95CB; Tue, 16 Sep 2014 21:32:33 +0000 (UTC) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 62A34F06; Tue, 16 Sep 2014 21:32:33 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id rp18so521294iec.0 for ; Tue, 16 Sep 2014 14:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=T93BYzNCQLPPKbtySfSXpFfXSBmat0/pWCrie7j18Ns=; b=r41fHI/fecHT9wm6BhSW206IWdVJO9k8m4w3UcWTk3nTTb6yyUpoBM5LY2LoIgcnQA FDvafY3+LUUY+sKRZrULrS4fbnO1rQpWO9yy6CAtdVjHFEZlHtZR6io7L7W7LGNKBkVo PClzSxFu6DGDKPB466tOhpnFHzTakxHAoBA0nXPNr7B1ttPnlZ0c3tAttBWncgqCF3IQ 4AvRuWaeqzOi2roQNbWZ57U0g2bXON8+ng0HuNfJHl7bN9wSNZKaoZZy+m+bGXWaZF7m 7yzCBWx8sDV9yqbIMEmPz6+26KVuCsHBvPwJZpehnlGO6W/r5UsxBSuYXW33W62vjO3z IBaA== X-Received: by 10.50.41.8 with SMTP id b8mr1495913igl.11.1410903152695; Tue, 16 Sep 2014 14:32:32 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.44.196 with HTTP; Tue, 16 Sep 2014 14:32:12 -0700 (PDT) In-Reply-To: <20140916230348.189e80cd.ohartman@zedat.fu-berlin.de> References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> <5417E20D.8070607@freebsd.org> <20140916230348.189e80cd.ohartman@zedat.fu-berlin.de> From: Ed Maste Date: Tue, 16 Sep 2014 17:32:12 -0400 X-Google-Sender-Auth: 0VttDLLXo8dyv-QOgz-FQL2JWGA Message-ID: Subject: Re: CURRENT: EFI boot failure To: "O. Hartmann" Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current , Nathan Whitehorn , Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 21:32:33 -0000 On 16 September 2014 17:03, O. Hartmann wrote: > > In that case, is it still /boot/boot1.efifat or is it /boot/boot1.efi? What is the > difference? Is the efi partition FAT? An EFI system partition (ESP) is a FAT-formatted partition with a specific GPT or MBR identifier and file system hierarchy; EFI firmware will try to load /EFI/BOOT/BOOTX64.EFI from the ESP. boot1.efi is an EFI application - that is, a PECOFF format binary. It searches for a UFS filesystem and loads loader.efi from that. It is intended to simplify the UEFI boot process, so that loader.efi, the .4th files, loader.conf etc. do not all need to be installed in the ESP. boot1.efifat is a FAT filesystem image that contains a copy of boot1.efi as /EFI/BOOT/BOOTX64.EFI. It exists so that the installer can treat it as opaque bootcode, like other boot schemes. It's certainly possible to create a partition, use newfs_msdos to format it, and copy in boot1.efi instead. > It is one disk, dedicated to FreeBSD (a laptop disk). Is there any documentation readable > for non-developer for that matter? I'm curious about how EFI works on FreeBSD. Better user-facing documentation is in progress; for now the best source is probably the wik. From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 21:50:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0EBFBA5; Tue, 16 Sep 2014 21:50:53 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E5ABDE; Tue, 16 Sep 2014 21:50:52 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XU0e5-003LPN-5Z>; Tue, 16 Sep 2014 23:50:45 +0200 Received: from g226063043.adsl.alicedsl.de ([92.226.63.43] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XU0e5-0029QE-0m>; Tue, 16 Sep 2014 23:50:45 +0200 Date: Tue, 16 Sep 2014 23:50:39 +0200 From: "O. Hartmann" To: Nathan Whitehorn Subject: Re: CURRENT: EFI boot failure Message-ID: <20140916235039.34e9284f.ohartman@zedat.fu-berlin.de> In-Reply-To: <5417E20D.8070607@freebsd.org> References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> <5417E20D.8070607@freebsd.org> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/X9hPCQNXUh6s/rALlwF+bTY"; protocol="application/pgp-signature" X-Originating-IP: 92.226.63.43 X-ZEDAT-Hint: A Cc: freebsd-current@freebsd.org, Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 21:50:53 -0000 --Sig_/X9hPCQNXUh6s/rALlwF+bTY Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tue, 16 Sep 2014 00:09:01 -0700 Nathan Whitehorn schrieb: >=20 > On 09/15/14 22:51, O. Hartmann wrote: > > Am Mon, 15 Sep 2014 17:39:26 -0700 > > Nathan Whitehorn schrieb: > > > >> On 09/15/14 17:36, Allan Jude wrote: > >>> On 2014-09-15 20:05, O. Hartmann wrote: > >>>> Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop w= orks for UEFI > >>>> fine. After I updated the sources to r271649, recompiled world and = kernel (as well > >>>> as installed), now I get stuck with the screen message: > >>>> > >>>>>> FreeBSD EFI boot block > >>>> Loader path: /boot/loader.efi > >>>> > >>>> and nothing happens. After a couple of minutes, the system reboots. > >>>> > >>>> What happened and how can this problem be solved? > >>>> > >>> You might need to update the boot1.efi file on the UEFI partition (sm= all > >>> FAT partition on the disk) > >>> > >>> I am not sure how 'in sync' boot1.efi (on the fat partiton) and > >>> loader.efi have to be. > >>> > >>> https://wiki.freebsd.org/UEFI > >>> > >> boot1.efi is designed never to need updating. (It also hasn't changed > >> since April) > >> -Nathan > > > > But it has changed bytesize when I recompiled world with recent sources= compared to > > the boot.efi size from the USB image I installed from (revision see abo= ve). >=20 > Probably compiler updates or something? I really wouldn't worry about it= =20 > too much. I'd worry more about loader, since we know boot1 could use the= =20 > console but loader doesn't show up. >=20 > > How to update bootcode on UEFI layout? I created a GPT partition with t= ype efi (1 GB) > > as well as a 512KB partition typed freebsd-boot. >=20 > How did you set it up in the first place? If you have a FreeBSD-only=20 > system partition (like the installer sets up), you just dd=20 > /boot/boot1.efifat to the EFI partition. Otherwise, it's FAT and you=20 > copy /boot/boot1.efi to somewhere your boot manager can find it. >=20 > > I'm new to EFI and the way the notebook now behaves is really strange. = While the USB > > drive image used to boot with new console enabled, it now boots again w= ith the old > > console and 800x640 resolution. This might indicate some minor but very= effective > > mistake I made. > > >=20 > The EFI boot block finds the first UFS partition -- on any disk -- and=20 > tries to boot from it. If you have multiple FreeBSD disks connected,=20 > that will very likely result in madness. > -Nathan > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" After I managed to install the OS and updated to the most recent world, it = took two days to have all the installations prepared. Now I'm about the configure X11 and= run into another very annoying situation. The Laptop is a Lenovo ThinkPad Edge E540 equipted with the following CPU/i= GPU and dedicated GPU: CPU Intel i5-4200M (Haswell) at 2.5 GHz with iGPU Intel HD Graphics 4600 GPU: nVidia GT 740M mobile GPU. EFI Version 2.31 EFI Firmware: Lenovo (rev. 05648) In the Firmware/EFI/BIOS the primary GPU is selected to be the nVidia GT 74= 0M. Boot is EFI only, no CSM support. With CSM support enabled a VGA screen with 640x40= 0 pixel shows up. Non UEFI options doesn't boot this system at all! Any attempt to bring up the nVidia GPU (starting X for testing) ends up in = a blank screen, stuck mousepointer, no keyboard. I even can not switch to another c= onsole! When X server started the first time on tty9, I can switch to another conso= le. But the moment I switch back to ttyv9 everything is frozen and as described above. When the system boots, I do not see a loader! Where is the loader I'm used = to see when I have the chance to switch to single user mode, console or switch off ACPI? Because I need X11 up (and it should be running on the nVidia GPU for perfo= rmance reasons), I tried to get back to the legacy "sc" console in textmode since = I read about several issues and immature vt() system, so I put those lines in the /boot/= loader.conf: hw.vga.textmode=3D1 hw.vty=3Dsc (tried also hw.vty=3Dvt). But with either of those lines in the loader thing get more annoying and na= sty: The system doesn't show even a console, it is stuck with this sparse EFI boot m= essage, last lines are dimensions xxxx x yyyy stride xxxx masks 0xfffffff [...] and the rest of the screen is blank. System remains unusable, the HDD is wo= rking and obviously booting the system but incapable of presenting a screen. When boo= ting the USB drive image, this initial EFI message gets overwritten (no screen blanking,= the kernel messages starts writing over this message like in the first days of compute= rs ...). In the case described above that doesn't happen at all. After I deleted.commented out the lines=20 hw.vga.textmode=3D1 hw.vty=3Dsc in loader.conf the system is booting again - and clears the initial EFI mes= sages before dumping the screen with kernel messages, as expected. Well, at the end, it seems I sit in front of two days useless labor, new ha= rdware, UEFI and no X11. --Sig_/X9hPCQNXUh6s/rALlwF+bTY Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUGLC0AAoJEOgBcD7A/5N89pQH/isQ2E7N4m24kYZO6xQu+u8G 0DyjtDwnBDjZkWjEwp/fP2cu3pHsyacOcMYu79lVwnP03FRZYjavyMxIPh4y8P6T hGNFqD2K8q4QJRB2jEcTTdQ+/7aorgUNYgc71nJvhhyxMVfhPOBFh9P3J5ql6wIG 0KaHTTUyhJWH/r9PpLw9TfcxZspfQPbr05s7nQTc/y5mFkCteFiiwGV2zjxCehjO 9dj8gdQuicvDK2/tXsjlaGC4iE5piLXva7g5FTVPF9VrFUWxDrCbnGOGfqpHn2gr qVTnurobipQIgQYUioFPh7gm1CbwUpJS2ASoNmk8XdpBws7RcGG7pE1FcEq7t/Y= =dil7 -----END PGP SIGNATURE----- --Sig_/X9hPCQNXUh6s/rALlwF+bTY-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 22:12:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E1F024E; Tue, 16 Sep 2014 22:12:30 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 03DEB38B; Tue, 16 Sep 2014 22:12:29 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XU0z5-003Pe9-P0>; Wed, 17 Sep 2014 00:12:27 +0200 Received: from g226063043.adsl.alicedsl.de ([92.226.63.43] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XU0z5-002CNU-Mn>; Wed, 17 Sep 2014 00:12:27 +0200 Date: Wed, 17 Sep 2014 00:12:23 +0200 From: "O. Hartmann" To: Adrian Chadd Subject: Re: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI Message-ID: <20140917001223.526d9560.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20140915233833.5bdd0725.ohartman@zedat.fu-berlin.de> <20140916131854.46acc5fb.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/V.pz09ODHFWzNpI38HmflqC"; protocol="application/pgp-signature" X-Originating-IP: 92.226.63.43 X-ZEDAT-Hint: A Cc: Kevin Oberman , FreeBSD CURRENT , FreeBSD Questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 22:12:30 -0000 --Sig_/V.pz09ODHFWzNpI38HmflqC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tue, 16 Sep 2014 08:40:25 -0700 Adrian Chadd schrieb: > Ah, jumbo frames. Maybe you got lucky and some ethernet drivers > default to accepting larger frames even if the MTU is 1500. >=20 >=20 > -a It is not the jumbo frame that makes this specific NIC work, I have to set = the mtu explicitely to make it work. To make this notebook work in different departments, I need to use DHCP. At= the moment I have to set the mtu manually, disbaling and reenabling the NIC (ifconfig re= 0 down, ifconfig re0 mtu xxxx, ifconfig re0 up). This seems to be strange. After that, the NIC seems to work as expected and= the Laptop has connection. Oliver --Sig_/V.pz09ODHFWzNpI38HmflqC Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUGLXLAAoJEOgBcD7A/5N8cfwIAIadAZyy0Qu9cMqWG5f2niKU fhEBJoZOiQM3f+mDYYKfnaQW2/yUbD0m6rrMh7WkRrAQu2dLT3mkWQ7PtlIS9E4N pUdwuoDMWgW88BYoyFmwNHD+sJr10H3J09i3wCVyrllYVfzD8SZMhohoOMh9MF2J n8rFn2T0mejD2+kf0fFzjYM4EaIYklO9RqcvkTEbqMPMsbIhC+Q827k/Rt49k5rv h0+BPN8VoIj05jOyioE/dIsz7X2Mw1qu1JsUyirp/OS8LBwdebw/fk+krCvnskc/ aQxcaVBtKvTKK88Bn9s9mEAYiAEGya9CWch/kzDN5qmEVXpOw9itD9+m2lwOVAI= =YJ+d -----END PGP SIGNATURE----- --Sig_/V.pz09ODHFWzNpI38HmflqC-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 22:25:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 539E952E; Tue, 16 Sep 2014 22:25:31 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D2C4C688; Tue, 16 Sep 2014 22:25:30 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XU1Bh-003Rop-1s>; Wed, 17 Sep 2014 00:25:29 +0200 Received: from g226063043.adsl.alicedsl.de ([92.226.63.43] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XU1Bg-002EAG-UG>; Wed, 17 Sep 2014 00:25:29 +0200 Date: Wed, 17 Sep 2014 00:25:24 +0200 From: "O. Hartmann" To: Ed Maste Subject: Re: CURRENT: EFI boot failure Message-ID: <20140917002524.5852fe14.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> <5417E20D.8070607@freebsd.org> <20140916230348.189e80cd.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/NB7nN2b6/TDLSTOTibE4wYr"; protocol="application/pgp-signature" X-Originating-IP: 92.226.63.43 X-ZEDAT-Hint: A Cc: FreeBSD Current , Nathan Whitehorn , Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 22:25:31 -0000 --Sig_/NB7nN2b6/TDLSTOTibE4wYr Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tue, 16 Sep 2014 17:32:12 -0400 Ed Maste schrieb: > On 16 September 2014 17:03, O. Hartmann wro= te: > > > > In that case, is it still /boot/boot1.efifat or is it /boot/boot1.efi? = What is the > > difference? Is the efi partition FAT? >=20 > An EFI system partition (ESP) is a FAT-formatted partition with a > specific GPT or MBR identifier and file system hierarchy; EFI firmware > will try to load /EFI/BOOT/BOOTX64.EFI from the ESP. >=20 > boot1.efi is an EFI application - that is, a PECOFF format binary. It > searches for a UFS filesystem and loads loader.efi from that. It is > intended to simplify the UEFI boot process, so that loader.efi, the > .4th files, loader.conf etc. do not all need to be installed in the > ESP. Thank you very much for the explanation. Well, since I never see the loader= screen as we are used to, were is that gone? There are no boot options anymore (like sin= gle user mode, ACPI off et cetera). Is this intended? Besides, checking both boot1.efi and loader.efi with file() shows something= like loader.efi: PE32+ executable (EFI application) x86-64 (stripped to external= PDB), for MS Windows. So both are PECOFF format files? >=20 > boot1.efifat is a FAT filesystem image that contains a copy of > boot1.efi as /EFI/BOOT/BOOTX64.EFI. It exists so that the installer > can treat it as opaque bootcode, like other boot schemes. It's > certainly possible to create a partition, use newfs_msdos to format > it, and copy in boot1.efi instead. All right, here you lost me ... sorry. The partition created by the install= es with type "efi" is then the /EFI/ partition, which then contains a folder BOOT and in= which the boot1.efi is located?=20 As I understand, I can manually mount this partition as FAT and copy boot1.= efi as BOOTX64.EFI into it? This knowledge could come in handy if something goes v= ery bad. >=20 > > It is one disk, dedicated to FreeBSD (a laptop disk). Is there any docu= mentation > > readable for non-developer for that matter? I'm curious about how EFI w= orks on > > FreeBSD. >=20 > Better user-facing documentation is in progress; for now the best > source is probably the wik. Thank you. --Sig_/NB7nN2b6/TDLSTOTibE4wYr Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUGLjYAAoJEOgBcD7A/5N8iOcH/27MyNe3CXU/KKGJJaEwI3Ul dw8gDL67EGJ3WPDgfPevajjleRYJRSPDLXsfP1iX1y0KSHaChn88gQXqC4NicJpk nOq1IlrkKQAaq5UqyBs6Sx1En6xV1LqyiycBDdxLODCiXcycIMowcGVtham4dzLt HwaUXvn2dPJM3Wp660McIeJ10GlR/xvtRMeFK3+YG8XqJ3UNbOAP7BAUY7J4e/kM NDXlj/bj6YBe6fyDPzJumEK56v70leJHnnzz/IBE5UJQjE8L/zg/87giRcq9xgEM cZ1KX7HKXYcWpNIBfAGY2fiPgTHUfzNY3VE6LjEftCgxKvktFAWCa1NkxYKBM64= =qgGI -----END PGP SIGNATURE----- --Sig_/NB7nN2b6/TDLSTOTibE4wYr-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 22:26:08 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00BA27A9; Tue, 16 Sep 2014 22:26:07 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9894669C; Tue, 16 Sep 2014 22:26:06 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA16697; Wed, 17 Sep 2014 01:26:04 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XU1CF-0005GM-Oz; Wed, 17 Sep 2014 01:26:03 +0300 Message-ID: <5418B8C3.7040406@FreeBSD.org> Date: Wed, 17 Sep 2014 01:25:07 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Ed Maste , "O. Hartmann" Subject: Re: CURRENT: EFI boot failure References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> <5417E20D.8070607@freebsd.org> <20140916230348.189e80cd.ohartman@zedat.fu-berlin.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Nathan Whitehorn , Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 22:26:08 -0000 On 17/09/2014 00:32, Ed Maste wrote: > On 16 September 2014 17:03, O. Hartmann wrote: >> >> In that case, is it still /boot/boot1.efifat or is it /boot/boot1.efi? What is the >> difference? Is the efi partition FAT? > > An EFI system partition (ESP) is a FAT-formatted partition with a > specific GPT or MBR identifier and file system hierarchy; EFI firmware > will try to load /EFI/BOOT/BOOTX64.EFI from the ESP. A very useful read about how EFI boot process works and how different OSes boot on top of it: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html > boot1.efi is an EFI application - that is, a PECOFF format binary. It > searches for a UFS filesystem and loads loader.efi from that. It is > intended to simplify the UEFI boot process, so that loader.efi, the > .4th files, loader.conf etc. do not all need to be installed in the > ESP. > > boot1.efifat is a FAT filesystem image that contains a copy of > boot1.efi as /EFI/BOOT/BOOTX64.EFI. It exists so that the installer > can treat it as opaque bootcode, like other boot schemes. It's > certainly possible to create a partition, use newfs_msdos to format > it, and copy in boot1.efi instead. > >> It is one disk, dedicated to FreeBSD (a laptop disk). Is there any documentation readable >> for non-developer for that matter? I'm curious about how EFI works on FreeBSD. > > Better user-facing documentation is in progress; for now the best > source is probably the wik. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 22:28:16 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 442E58D8; Tue, 16 Sep 2014 22:28:16 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C2C8A6BD; Tue, 16 Sep 2014 22:28:15 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XU1EL-003SQL-GY>; Wed, 17 Sep 2014 00:28:13 +0200 Received: from g226063043.adsl.alicedsl.de ([92.226.63.43] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XU1EL-002EUR-Cb>; Wed, 17 Sep 2014 00:28:13 +0200 Date: Wed, 17 Sep 2014 00:28:12 +0200 From: "O. Hartmann" To: Andriy Gapon Subject: Re: CURRENT: EFI boot failure Message-ID: <20140917002812.64cf7848.ohartman@zedat.fu-berlin.de> In-Reply-To: <5418B8C3.7040406@FreeBSD.org> References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> <5417E20D.8070607@freebsd.org> <20140916230348.189e80cd.ohartman@zedat.fu-berlin.de> <5418B8C3.7040406@FreeBSD.org> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/KQlEit_U9N8rbiJyxS4aZBv"; protocol="application/pgp-signature" X-Originating-IP: 92.226.63.43 X-ZEDAT-Hint: A Cc: FreeBSD Current , Ed Maste , Nathan Whitehorn , Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 22:28:16 -0000 --Sig_/KQlEit_U9N8rbiJyxS4aZBv Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Wed, 17 Sep 2014 01:25:07 +0300 Andriy Gapon schrieb: > On 17/09/2014 00:32, Ed Maste wrote: > > On 16 September 2014 17:03, O. Hartmann w= rote: > >> > >> In that case, is it still /boot/boot1.efifat or is it /boot/boot1.efi?= What is the > >> difference? Is the efi partition FAT? > >=20 > > An EFI system partition (ESP) is a FAT-formatted partition with a > > specific GPT or MBR identifier and file system hierarchy; EFI firmware > > will try to load /EFI/BOOT/BOOTX64.EFI from the ESP. >=20 > A very useful read about how EFI boot process works and how different OSe= s boot > on top of it: > http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process= .html Great! >=20 > > boot1.efi is an EFI application - that is, a PECOFF format binary. It > > searches for a UFS filesystem and loads loader.efi from that. It is > > intended to simplify the UEFI boot process, so that loader.efi, the > > .4th files, loader.conf etc. do not all need to be installed in the > > ESP. > >=20 > > boot1.efifat is a FAT filesystem image that contains a copy of > > boot1.efi as /EFI/BOOT/BOOTX64.EFI. It exists so that the installer > > can treat it as opaque bootcode, like other boot schemes. It's > > certainly possible to create a partition, use newfs_msdos to format > > it, and copy in boot1.efi instead. > >=20 > >> It is one disk, dedicated to FreeBSD (a laptop disk). Is there any doc= umentation > >> readable for non-developer for that matter? I'm curious about how EFI = works on > >> FreeBSD. > >=20 > > Better user-facing documentation is in progress; for now the best > > source is probably the wik. > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" > >=20 >=20 >=20 --Sig_/KQlEit_U9N8rbiJyxS4aZBv Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUGLl9AAoJEOgBcD7A/5N8AVsH/jgnkRNvWvDr3vYglQGFcEQt l/uv0hXzc/308E8ltmTazHEA0g1d6l1CtwImAvMmYrenQVFnxhnAbSa32YLRPtq/ D5dkr+8Ssygup97yD3gkWZbB16YdhH07n8g6JJ70hDvTMUiRVoRN8e6i9XHYEbEq BBTAvaFICv6Q5Sv2kcwqjBAyOZ9vP483bHQU5EvpX6OrOQs/pUANi1Vr8BDE4Arp JLA5wAlXK3+xetMu2IoTGulGnrEIUUnzldIGZ1jd/rLI2YpwXIbmE5Y7XRn9o8Q3 zKHA+GMXuhoMhom3NPMNGiSidGxKDIBh2Y7UEIoEcQ2ozP+h8Sl+QD85TFJoZDE= =k4EI -----END PGP SIGNATURE----- --Sig_/KQlEit_U9N8rbiJyxS4aZBv-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 22:34:36 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1205B0C for ; Tue, 16 Sep 2014 22:34:36 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5987D7E5 for ; Tue, 16 Sep 2014 22:34:36 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XU1KU-003Ta7-Is>; Wed, 17 Sep 2014 00:34:34 +0200 Received: from g226063043.adsl.alicedsl.de ([92.226.63.43] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XU1KU-002F88-ES>; Wed, 17 Sep 2014 00:34:34 +0200 Date: Wed, 17 Sep 2014 00:34:33 +0200 From: "O. Hartmann" To: "Steven Hartland" Subject: Re: zpool: multiple IDs, CURRENT drops all pools after reboot Message-ID: <20140917003433.47f4318b.ohartman@zedat.fu-berlin.de> In-Reply-To: <27D574A82A374C2DAB8648ED7D2FDCD2@multiplay.co.uk> References: <20140916225346.10e0d4ae.ohartman@zedat.fu-berlin.de> <27D574A82A374C2DAB8648ED7D2FDCD2@multiplay.co.uk> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/qVTdNEP8m.EukU1M0zw5wDT"; protocol="application/pgp-signature" X-Originating-IP: 92.226.63.43 X-ZEDAT-Hint: A Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 22:34:36 -0000 --Sig_/qVTdNEP8m.EukU1M0zw5wDT Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tue, 16 Sep 2014 22:06:36 +0100 "Steven Hartland" schrieb: > > On of my backup drives dedicated to a ZPOOL is faulting and showing up = multiple ID. > > The only working ID is id: 257822624560506537. > >=20 > > FreeBSD CURRENT with three ZFS disks and only 4GB of RAM is very "flaky= " regarding > > this issue: today, tow times the whole poolset vanishes after a reboot.= Giving the > > box 8 GB total and rebooting doens't show the problem, it gets more fre= quent when > > reducing the RAM to 4GB (FreeBSD 11.0-CURRENT #2 r271684: Tue Sep 16 20= :41:47 CEST > > 2014). This is a bit spooky. > >=20 > > Below the faulted harddrive. I guess the drive/pool below shown trigger= s somehow the > > loss of all other pools (I have to import the other pools, which do not= have any > > defects, but they they drop out after a reboot and vanish). > >=20 > > Is there a way getting rid of the faulty IDs without destroying the poo= l? > >=20 > > Regards, > >=20 > > Oliver=20 > >=20 > > root@thor: [/etc] zpool import > > pool: BACKUP00 > > id: 9337833315545958689 > > state: FAULTED > > status: One or more devices contains corrupted data. > > action: The pool cannot be imported due to damaged devices or data. > > The pool may be active on another system, but can be imported u= sing > > the '-f' flag. > > see: http://illumos.org/msg/ZFS-8000-5E > > config: > >=20 > > BACKUP00 FAULTED corrupted data > > 8544670861382329237 UNAVAIL corrupted data > >=20 > > pool: BACKUP00 > > id: 257822624560506537 > > state: ONLINE > > action: The pool can be imported using its name or numeric identifier. > > config: > >=20 > > BACKUP00 ONLINE > > ada3p1 ONLINE > >=20 >=20 > Might be a long shot but check out the patches on: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D187594 >=20 > Specifically: > https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D147070 >=20 > And if that doesn't work: > https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D147286 >=20 > The second has all the changes from the first with the addition > of some changes which dynamically size the max dirty data. >=20 > These changes are in discussion and its likely the additions > in the second patch aren't the right direction but they > have been reported to show good improvements under high > memory pressure for certain workloads, so would be interesting > to see if they help with your problem. >=20 > All that said you shouldnt end up with corrupt data no matter > what. >=20 > Are there any other symptoms? Has memory been checked for > faults etc? >=20 > Regards > Steve The reason why my desktop has only 4 GB left is that I discovered memory co= rruption when equipted with 8 GB - there occured a strange bit flip. I can not assure tha= t by ripping off 4 GB (2 times 2GB, it is an old C2D/P45 based box) the problem has gone= . I susepct a dying chipset - when overheated (at the moment BIOS shows 80 degrees Cels= ius), the problem is more frequent. But, besindes data corruption, with 4 GB left and 2 disks put together as a= striped JBOD with another disk as the backup device (the faulty one) is a pain in t= he ass since the box starts swapping immediately when some action on the ZFS drives take= place. The plan is to keep that craveyward alive for the next 2 months until I can aff= ord a new system ;-) But anyway, I'll try the patches. Thanks, Oliver =20 --Sig_/qVTdNEP8m.EukU1M0zw5wDT Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUGLr5AAoJEOgBcD7A/5N8/XgH/RvvvGKmGu+3tWZkd3UiyIQT T6sT2iz62Ukf4to8oEOIsgG0cX2T/wPgixbKN5WXcvfKcxoQHhkesv6Im7ZG3s4I 0fVMgqEeXAC2VViEJiT+U4jMe8XKTyFOQnCIAPf3FMF/qn7XK20MUYIJIxwKs7GX 1HCOKw1eT3fxdoxy6yfU3H/mbwJtL30o+Bz3XzJmgsdPQG5u4fNlhHYNzswT3u0s BIbJ4yNPLJ/HUwxEVZPPsdmG8hihwPsp8c8Kk5zYBfPck9okDwdCG7skqcMfVWrh 1Uo4tgoDCPcqDjIVVP9Lorb1vkmQmJck7qMK1IW2Qv6zL73DokkdmevN68q9slk= =U8I8 -----END PGP SIGNATURE----- --Sig_/qVTdNEP8m.EukU1M0zw5wDT-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 22:44:48 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87E4DCDA for ; Tue, 16 Sep 2014 22:44:48 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 325248D5 for ; Tue, 16 Sep 2014 22:44:48 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id s8GMibax038105; Tue, 16 Sep 2014 15:44:41 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201409162244.s8GMibax038105@gw.catspoiler.org> Date: Tue, 16 Sep 2014 15:44:37 -0700 (PDT) From: Don Lewis Subject: Re: zpool: multiple IDs, CURRENT drops all pools after reboot To: ohartman@zedat.fu-berlin.de In-Reply-To: <20140917003433.47f4318b.ohartman@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org, killing@multiplay.co.uk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 22:44:48 -0000 On 17 Sep, O. Hartmann wrote: > Am Tue, 16 Sep 2014 22:06:36 +0100 > "Steven Hartland" schrieb: >> All that said you shouldnt end up with corrupt data no matter >> what. >> >> Are there any other symptoms? Has memory been checked for >> faults etc? >> >> Regards >> Steve > > The reason why my desktop has only 4 GB left is that I discovered memory corruption when > equipted with 8 GB - there occured a strange bit flip. I can not assure that by ripping > off 4 GB (2 times 2GB, it is an old C2D/P45 based box) the problem has gone. I susepct > a dying chipset - when overheated (at the moment BIOS shows 80 degrees Celsius), the > problem is more frequent. You might want to try relaxing the memory timing in the BIOS. In particular, try adding some cycles to CAS Latency. I've had a couple of systems with ECC RAM that had excessive ECC errors with the default RAM timing that got much better when I increased CAS Latency. You might also want to try rigging an extra fan to blow on the RAM and/or chipset. From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 22:54:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA6A4238; Tue, 16 Sep 2014 22:54:33 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AE2E19BC; Tue, 16 Sep 2014 22:54:33 +0000 (UTC) Received: from zeppelin.tachypleus.net (airbears2-136-152-142-25.AirBears2.Berkeley.EDU [136.152.142.25]) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s8GMsV8m021597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 Sep 2014 15:54:31 -0700 Message-ID: <5418BFA7.40700@freebsd.org> Date: Tue, 16 Sep 2014 15:54:31 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "O. Hartmann" Subject: Re: CURRENT: EFI boot failure References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> <5417E20D.8070607@freebsd.org> <20140916235039.34e9284f.ohartman@zedat.fu-berlin.de> In-Reply-To: <20140916235039.34e9284f.ohartman@zedat.fu-berlin.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVb5ytATdL23uTCeTA++VLHPUeWBPLW4h/ZujeRAFMTMryItV56Fg4CjVgFS7gG5jJYLhb+4P6cs7fXD3TRZZ6FUpTRNNHLC+PA= X-Sonic-ID: C;5GBua/Q95BGBqQDu5Qupew== M;vkbMa/Q95BGBqQDu5Qupew== X-Spam-Flag: No X-Sonic-Spam-Details: 2.4/5.0 by cerberusd Cc: freebsd-current@freebsd.org, Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 22:54:33 -0000 On 09/16/14 14:50, O. Hartmann wrote: > Am Tue, 16 Sep 2014 00:09:01 -0700 > Nathan Whitehorn schrieb: > >> On 09/15/14 22:51, O. Hartmann wrote: >>> Am Mon, 15 Sep 2014 17:39:26 -0700 >>> Nathan Whitehorn schrieb: >>> >>>> On 09/15/14 17:36, Allan Jude wrote: >>>>> On 2014-09-15 20:05, O. Hartmann wrote: >>>>>> Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop works for UEFI >>>>>> fine. After I updated the sources to r271649, recompiled world and kernel (as well >>>>>> as installed), now I get stuck with the screen message: >>>>>> >>>>>>>> FreeBSD EFI boot block >>>>>> Loader path: /boot/loader.efi >>>>>> >>>>>> and nothing happens. After a couple of minutes, the system reboots. >>>>>> >>>>>> What happened and how can this problem be solved? >>>>>> >>>>> You might need to update the boot1.efi file on the UEFI partition (small >>>>> FAT partition on the disk) >>>>> >>>>> I am not sure how 'in sync' boot1.efi (on the fat partiton) and >>>>> loader.efi have to be. >>>>> >>>>> https://wiki.freebsd.org/UEFI >>>>> >>>> boot1.efi is designed never to need updating. (It also hasn't changed >>>> since April) >>>> -Nathan >>> But it has changed bytesize when I recompiled world with recent sources compared to >>> the boot.efi size from the USB image I installed from (revision see above). >> Probably compiler updates or something? I really wouldn't worry about it >> too much. I'd worry more about loader, since we know boot1 could use the >> console but loader doesn't show up. >> >>> How to update bootcode on UEFI layout? I created a GPT partition with type efi (1 GB) >>> as well as a 512KB partition typed freebsd-boot. >> How did you set it up in the first place? If you have a FreeBSD-only >> system partition (like the installer sets up), you just dd >> /boot/boot1.efifat to the EFI partition. Otherwise, it's FAT and you >> copy /boot/boot1.efi to somewhere your boot manager can find it. >> >>> I'm new to EFI and the way the notebook now behaves is really strange. While the USB >>> drive image used to boot with new console enabled, it now boots again with the old >>> console and 800x640 resolution. This might indicate some minor but very effective >>> mistake I made. >>> >> The EFI boot block finds the first UFS partition -- on any disk -- and >> tries to boot from it. If you have multiple FreeBSD disks connected, >> that will very likely result in madness. >> -Nathan >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > After I managed to install the OS and updated to the most recent world, it took two days > to have all the installations prepared. Now I'm about the configure X11 and run into > another very annoying situation. > > The Laptop is a Lenovo ThinkPad Edge E540 equipted with the following CPU/iGPU and > dedicated GPU: > > CPU Intel i5-4200M (Haswell) at 2.5 GHz with iGPU Intel HD Graphics 4600 > > GPU: nVidia GT 740M mobile GPU. > > EFI Version 2.31 > EFI Firmware: Lenovo (rev. 05648) > > In the Firmware/EFI/BIOS the primary GPU is selected to be the nVidia GT 740M. Boot is > EFI only, no CSM support. With CSM support enabled a VGA screen with 640x400 pixel shows > up. Non UEFI options doesn't boot this system at all! > > Any attempt to bring up the nVidia GPU (starting X for testing) ends up in a blank > screen, stuck mousepointer, no keyboard. I even can not switch to another console! > When X server started the first time on tty9, I can switch to another console. But the > moment I switch back to ttyv9 everything is frozen and as described above. Try xf86-video-scfb instead? > When the system boots, I do not see a loader! Where is the loader I'm used to see when I > have the chance to switch to single user mode, console or switch off ACPI? There is no beastie menu for UEFI, and will not be, since it UEFI's terminal emulation does not provide the required features. You can boot single user from the loader command line, however, with boot -s, for example. The interface is identical to what you get if you choose "Loader prompt" in the usual menu. > Because I need X11 up (and it should be running on the nVidia GPU for performance > reasons), I tried to get back to the legacy "sc" console in textmode since I read about > several issues and immature vt() system, so I put those lines in the /boot/loader.conf: > > hw.vga.textmode=1 > hw.vty=sc > > (tried also hw.vty=vt). > > But with either of those lines in the loader thing get more annoying and nasty: The > system doesn't show even a console, it is stuck with this sparse EFI boot message, last > lines are > > dimensions xxxx x yyyy > stride xxxx > masks 0xfffffff [...] > > and the rest of the screen is blank. System remains unusable, the HDD is working and > obviously booting the system but incapable of presenting a screen. When booting the USB > drive image, this initial EFI message gets overwritten (no screen blanking, the kernel > messages starts writing over this message like in the first days of computers ...). In > the case described above that doesn't happen at all. syscons does not support UEFI systems at all. Since it can't initialize the VGA hardware, you get a blank screen. hw.vga.textmode also won't have any effect since EFI systems don't use the vga driver for console, instead using an EFI-provided framebuffer structure through the vt_efifb driver. > After I deleted.commented out the lines > > hw.vga.textmode=1 > hw.vty=sc > > in loader.conf the system is booting again - and clears the initial EFI messages before > dumping the screen with kernel messages, as expected. > > Well, at the end, it seems I sit in front of two days useless labor, new hardware, UEFI > and no X11. One thing you might want to try that got my Haswell laptop up is to use the x11-drivers/xf86-video-scfb driver. This uses the vt framebuffer directly. It's more or less the equivalent of the VESA driver since it is unaccelerated, but it will work. We really need actual Haswell graphics drivers (I suspect they are required to get the multiple GPU handoff to work as well). -Nathan From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 23:19:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E4FD6B4; Tue, 16 Sep 2014 23:19:53 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB362BCC; Tue, 16 Sep 2014 23:19:52 +0000 (UTC) Received: by mail-ig0-f176.google.com with SMTP id hn15so283603igb.9 for ; Tue, 16 Sep 2014 16:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=EJiYDimaY4FbrwOEb52SuYWqRdQUY0gumVmw+6DN8MQ=; b=wMT4U0B+uQLr1xCFiEG+PDWA/pCazlEwmsPnxAfcvLlnosKdQTTcnzliq2lRKNKHQN YTA3dd7aTAeCzPNSrkrBk0y2ZGSp78z+oFgRTWmO4qAAVBP3Vigv1zg3gbkhyoDSDupw 1q1z9V1tWXVIUj2E2smkZarUJF/6bPufyQp0X9yNK2RffiN/P504RdI/decY4rTGTuh8 +A3ilCX2b6oMBQ5Bcg+xsCHrXoFWwNbQ+SL/u5gdFF1Xgk1UI437ZpQuwHwigJpS/uSW TYxKfc/rYe3tcS0fda/vXZ79vYHlBCEJhYfilN154+4HJkv18DkI3fC0OhXXRSaCY/ad SMLw== X-Received: by 10.50.88.98 with SMTP id bf2mr34961731igb.11.1410909592215; Tue, 16 Sep 2014 16:19:52 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.44.196 with HTTP; Tue, 16 Sep 2014 16:19:32 -0700 (PDT) In-Reply-To: <20140917002524.5852fe14.ohartman@zedat.fu-berlin.de> References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> <5417E20D.8070607@freebsd.org> <20140916230348.189e80cd.ohartman@zedat.fu-berlin.de> <20140917002524.5852fe14.ohartman@zedat.fu-berlin.de> From: Ed Maste Date: Tue, 16 Sep 2014 19:19:32 -0400 X-Google-Sender-Auth: 7NMG3rqRwXLUjcSkL-DX5PnDxqk Message-ID: Subject: Re: CURRENT: EFI boot failure To: "O. Hartmann" Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current , Nathan Whitehorn , Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 23:19:53 -0000 On 16 September 2014 18:25, O. Hartmann wrote: > > Besides, checking both boot1.efi and loader.efi with file() shows something like > loader.efi: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS > Windows. So both are PECOFF format files? That is correct. >> >> boot1.efifat is a FAT filesystem image that contains a copy of >> boot1.efi as /EFI/BOOT/BOOTX64.EFI. It exists so that the installer >> can treat it as opaque bootcode, like other boot schemes. It's >> certainly possible to create a partition, use newfs_msdos to format >> it, and copy in boot1.efi instead. > > All right, here you lost me ... sorry. The partition created by the installes with type > "efi" is then the /EFI/ partition, which then contains a folder BOOT and in which the > boot1.efi is located? > As I understand, I can manually mount this partition as FAT and copy boot1.efi as > BOOTX64.EFI into it? This knowledge could come in handy if something goes very bad. Sorry, not quite; an ESP is a separate partition formatted with FAT. The file system in that partition has EFI/ in the root directory, BOOT/ under that, and BOOTX64.EFI in there. We don't (yet) mount the ESP inside of FreeBSD by default. At least some Linuxes do mount the ESP at /boot/efi, so you end up with /boot/efi/EFI/BOOT/BOOTX64.EFI. We might start doing something similar when fleshing out dual-boot configuration support. boot1.efifat is a copy (image) of the ESP, as it exists on the disk. You can see what's inside: # mdconfig -a -f /boot/boot1.efifat md0 # mount_msdosfs /dev/md0 /mnt # ls -l /mnt/efi/boot/BOOTx64.efi -rwxr-xr-x 1 root wheel 65536 Apr 26 20:43 /mnt/efi/boot/BOOTx64.efi # umount /mnt # mdconfig -d -u 0 From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 23:30:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7CBED93A; Tue, 16 Sep 2014 23:30:18 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3723BCD1; Tue, 16 Sep 2014 23:30:18 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id tr6so645359ieb.40 for ; Tue, 16 Sep 2014 16:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Zb5DQuAEwVZW0x5/pga4PPa+4noiCnqXCnVxLNtQX7Q=; b=BADB1zYuN4NiBwG4AXErbb+M7SDyNLZakXT4Pq4Q6z7JFzPXDn68BcDybVNwhJ+POS ccQtNjzUwBvf6LMTBTrEWwhLE6J0a8siQvghW4oyesm5dJ1zbEhZBdACkhR0Mz6XEL2D yhSnn/fSMTQIxG9R70buSlkjNS/w+nmqM4skPFlYl3K1AMZzgKJA0Ql1AZvR0965O5np /43JZ8ShbUakFkLQny1HJVgoKVTaZZ+ELJbNkoUrG5gauPjTJ0eQqeOHSQ05WAd9ir5/ 9Gi11tDCwFYO3XaxhTwq7bQqEIP7VvFhnOOqTdoXrvXfzqldc0oh3JkvsbL0coV/lnkL U+vg== X-Received: by 10.42.83.81 with SMTP id g17mr1753062icl.45.1410910217557; Tue, 16 Sep 2014 16:30:17 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.44.196 with HTTP; Tue, 16 Sep 2014 16:29:57 -0700 (PDT) In-Reply-To: <5418BFA7.40700@freebsd.org> References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> <5417E20D.8070607@freebsd.org> <20140916235039.34e9284f.ohartman@zedat.fu-berlin.de> <5418BFA7.40700@freebsd.org> From: Ed Maste Date: Tue, 16 Sep 2014 19:29:57 -0400 X-Google-Sender-Auth: gBhx1qhwDEwee8Y41Iab61ckrzo Message-ID: Subject: Re: CURRENT: EFI boot failure To: Nathan Whitehorn Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current , "O. Hartmann" , Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 23:30:18 -0000 On 16 September 2014 18:54, Nathan Whitehorn wrote: > > On 09/16/14 14:50, O. Hartmann wrote: >> >> When the system boots, I do not see a loader! Where is the loader I'm used >> to see when I >> have the chance to switch to single user mode, console or switch off ACPI? > > > There is no beastie menu for UEFI, and will not be, since it UEFI's terminal > emulation does not provide the required features. You can boot single user > from the loader command line, however, with boot -s, for example. The > interface is identical to what you get if you choose "Loader prompt" in the > usual menu. As Nathan says there's no beastie menu, but you should still see the loader. If you get a "Hit [Enter] to boot immediately, or any other key for command prompt." message, you're seeing the loader. There is an additional complication that affects some systems, where we do not switch to text mode. In this case you truly won't see the loader. This is described in the link Andriy provided (along with a workaround), and we have a patch in progress for this. So far this mainly known to affect MacBooks. From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 02:28:12 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93276E69 for ; Wed, 17 Sep 2014 02:28:12 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 621B9F0A for ; Wed, 17 Sep 2014 02:28:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s8H2SCxI005134 for ; Wed, 17 Sep 2014 02:28:12 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s8H2SC3l005133 for current@FreeBSD.org; Wed, 17 Sep 2014 02:28:12 GMT (envelope-from bdrewery) Received: (qmail 20057 invoked from network); 16 Sep 2014 21:28:09 -0500 Received: from unknown (HELO blah) (freebsd@shatow.net@10.10.1.90) by sweb.xzibition.com with ESMTPA; 16 Sep 2014 21:28:09 -0500 Message-ID: <5418F1B9.2000903@FreeBSD.org> Date: Tue, 16 Sep 2014 21:28:09 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: current@FreeBSD.org Subject: Cam panic on r271170 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 02:28:12 -0000 I've been getting this quite frequently on head recently. I have dumps if anyone is interested in more information. > Fatal trap 9: general protection fault while in kernel mode > cpuid = 10; Memory modified after free 0xfffff8003e0b0800(2040) val=ffffffff @ 0xfffff8003e0b0808 > apanic: Most recently used by CAM CCB > > cpuid = 6 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe124735b4c0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe124735b570 > vpanic() at vpanic+0x189/frame 0xfffffe124735b5f0 > panic() at panic+0x43/frame 0xfffffe124735b650 > mtrash_ctor() at mtrash_ctor+0x8a/frame 0xfffffe124735b680 > uma_zalloc_arg() at uma_zalloc_arg+0x4f1/frame 0xfffffe124735b6f0 > malloc() at malloc+0x192/frame 0xfffffe124735b740 > xpt_run_allocq() at xpt_run_allocq+0xb5/frame 0xfffffe124735b780 > adastrategy() at adastrategy+0x117/frame 0xfffffe124735b7b0 > g_io_request() at g_io_request+0x3b7/frame 0xfffffe124735b810 > g_part_start() at g_part_start+0x2b7/frame 0xfffffe124735b890 > g_io_request() at g_io_request+0x3b7/frame 0xfffffe124735b8f0 > g_io_request() at g_io_request+0x3b7/frame 0xfffffe124735b950 > vdev_geom_io_start() at vdev_geom_io_start+0x137/frame 0xfffffe124735b970 > zio_vdev_io_start() at zio_vdev_io_start+0x49f/frame 0xfffffe124735b9d0 > zio_execute() at zio_execute+0x204/frame 0xfffffe124735ba30 > vdev_queue_io_done() at vdev_queue_io_done+0x180/frame 0xfffffe124735ba80 > zio_vdev_io_done() at zio_vdev_io_done+0x11d/frame 0xfffffe124735bac0 > zio_execute() at zio_execute+0x204/frame 0xfffffe124735bb20 > taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xfffffe124735bb80 > taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame 0xfffffe124735bbb0 > fork_exit() at fork_exit+0x84/frame 0xfffffe124735bbf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe124735bbf0 > --- trap 0, rip = 0, rsp = 0xfffffe124735bcb0, rbp = 0 --- > KDB: enter: panic > [ thread pid 0 tid 100571 ] > Stopped at kdb_enter+0x3e: movq $0,kdb_why -- Regards, Bryan Drewery From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 05:11:42 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C56EEA1 for ; Wed, 17 Sep 2014 05:11:42 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ECBB73DB for ; Wed, 17 Sep 2014 05:11:41 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id AE02824800B; Wed, 17 Sep 2014 07:11:37 +0200 (CEST) Message-ID: <541917FE.3060801@selasky.org> Date: Wed, 17 Sep 2014 07:11:26 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Milan Obuch Subject: Re: Huawei E3272 tester needed References: <20140916165257.3a0cee9b@zeta.dino.sk> <541895C6.3030304@dat.pl> <20140916221812.649a1756@zeta.dino.sk> <54189F07.7010301@selasky.org> <20140916225205.6d7a8bac@zeta.dino.sk> In-Reply-To: <20140916225205.6d7a8bac@zeta.dino.sk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG, milu@dat.pl, nick@van-laarhoven.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 05:11:42 -0000 On 09/16/14 22:52, Milan Obuch wrote: > On Tue, 16 Sep 2014 22:35:19 +0200 > Hans Petter Selasky wrote: > >> On 09/16/14 22:18, Milan Obuch wrote: >>> On Tue, 16 Sep 2014 21:55:50 +0200 >>> Maciej Milewski wrote: >>> >>>> On 16.09.2014 16:52, Milan Obuch wrote: >>>>> On Tue, 16 Sep 2014 09:40:45 +0200 >>>>> Nick Hibma wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Is there someone who is able to test support for the Huawei E3272 >>>>>> card with CURRENT after 269584? I have not been able to confirm >>>>>> that it works. >>>>>> >>>>>> Thanks in advance. >>>>>> >>>>>> Nick >>>>>> >>>>> Hi, >>>>> >>>>> I did fresh svn update, rebuilt world+kernel, but it does not work >>>>> for me... >>> >>> [ snip ] >>> >> >> Hi, >> >> According to the modeswitch: >> >> usbconfig -d X.Y add_quirk UQ_MSC_EJECT_HUAWEISCSI2 >> >> Then re-plug the device. >> >> --HPS >> > > Well, again, no change: > > #usbconfig -d 1.3 add_quirk UQ_MSC_EJECT_HUAWEISCSI2 > Adding quirk 'UQ_MSC_EJECT_HUAWEISCSI2' failed, continuing. > > Did I do it right? Something is surely wrong. By the way, from uname: > > 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271671M > > The only modified file is modules/drm2/Makefile because for some reason > radeonkms does not currently build, so I excluded is as a fast > workaround. > Hi, Did you kldload usb_quirk And does: usbconfig dump_quirk_names yield something? --HPS From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 06:01:54 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AA96639; Wed, 17 Sep 2014 06:01:54 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 868DBA31; Wed, 17 Sep 2014 06:01:49 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA22736; Wed, 17 Sep 2014 09:01:47 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XU8JH-0008p6-68; Wed, 17 Sep 2014 09:01:47 +0300 Message-ID: <5419238E.8050708@FreeBSD.org> Date: Wed, 17 Sep 2014 09:00:46 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-stable List , FreeBSD Current Subject: Fwd: usb printer vs cups References: <54133325.9070302@FreeBSD.org> In-Reply-To: <54133325.9070302@FreeBSD.org> X-Forwarded-Message-Id: <54133325.9070302@FreeBSD.org> Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: freebsd-desktop@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 06:01:54 -0000 Soliciting help. -------- Forwarded Message -------- >From my experience I think that cupsd executes backend tools with all uids and gids set to cups and no supplementary groups. In the case of USB printers the backends need to access /dev/usbctl and /dev/usb/foobar that corresponds to a printer. That means that the access to those devices must be somehow granted to cups:cups. How do people solve this? What kind of permissions / configuration do you use? P.S. Maybe I over-generalized the issue to all USB printers. My personal experience is with an HP printer handled by hplip / hplip-plugin. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 06:21:32 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27A07C39; Wed, 17 Sep 2014 06:21:32 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D73BCC35; Wed, 17 Sep 2014 06:21:31 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id AC2D524800B; Wed, 17 Sep 2014 08:21:28 +0200 (CEST) Message-ID: <5419285D.8020909@selasky.org> Date: Wed, 17 Sep 2014 08:21:17 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Andriy Gapon , freebsd-stable List , FreeBSD Current Subject: Re: Fwd: usb printer vs cups References: <54133325.9070302@FreeBSD.org> <5419238E.8050708@FreeBSD.org> In-Reply-To: <5419238E.8050708@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------040608000705010201090203" Cc: freebsd-desktop@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 06:21:32 -0000 This is a multi-part message in MIME format. --------------040608000705010201090203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/17/14 08:00, Andriy Gapon wrote: > > Soliciting help. > > -------- Forwarded Message -------- > >>From my experience I think that cupsd executes backend tools with all uids and > gids set to cups and no supplementary groups. In the case of USB printers the > backends need to access /dev/usbctl and /dev/usb/foobar that corresponds to a > printer. That means that the access to those devices must be somehow granted to > cups:cups. > How do people solve this? What kind of permissions / configuration do you use? > > P.S. > Maybe I over-generalized the issue to all USB printers. My personal experience > is with an HP printer handled by hplip / hplip-plugin. > Hi, The /usr/ports/print/cups-base should be updated. The pkg-message should not say that: # FreeBSD 8.x add path 'usb*' mode 0770 group cups add path 'ugen*' mode 0660 group cups add path 'usb/0.2.*' mode 0660 group cups Is needed. This is wrong. Instead make cups-base install the attached devd configuration file in /usr/local/etc/devd/ which does the needed chown for printers only. --HPS --------------040608000705010201090203 Content-Type: text/plain; charset=us-ascii; name="cups.conf.in" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cups.conf.in" # Generic USB printer devices notify 100 { match "system" "USB"; match "subsystem" "INTERFACE"; match "type" "ATTACH"; match "intclass" "0x07"; match "intsubclass" "0x01"; match "intprotocol" "(0x01|0x02|0x03)"; action "chown cups:cups /dev/$cdev"; }; --------------040608000705010201090203-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 06:47:42 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18A3846B; Wed, 17 Sep 2014 06:47:42 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 90D04E6A; Wed, 17 Sep 2014 06:47:41 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XU91f-000gdT-I7>; Wed, 17 Sep 2014 08:47:39 +0200 Received: from g225115150.adsl.alicedsl.de ([92.225.115.150] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XU91f-003Cni-Dr>; Wed, 17 Sep 2014 08:47:39 +0200 Date: Wed, 17 Sep 2014 08:47:34 +0200 From: "O. Hartmann" To: Nathan Whitehorn Subject: Re: CURRENT: EFI boot failure Message-ID: <20140917084734.65246e22.ohartman@zedat.fu-berlin.de> In-Reply-To: <5418BFA7.40700@freebsd.org> References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> <5417E20D.8070607@freebsd.org> <20140916235039.34e9284f.ohartman@zedat.fu-berlin.de> <5418BFA7.40700@freebsd.org> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/5DJVG92CjocLIiN0AuwqYRh"; protocol="application/pgp-signature" X-Originating-IP: 92.225.115.150 X-ZEDAT-Hint: A Cc: freebsd-current@freebsd.org, Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 06:47:42 -0000 --Sig_/5DJVG92CjocLIiN0AuwqYRh Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tue, 16 Sep 2014 15:54:31 -0700 Nathan Whitehorn schrieb: >=20 > On 09/16/14 14:50, O. Hartmann wrote: > > Am Tue, 16 Sep 2014 00:09:01 -0700 > > Nathan Whitehorn schrieb: > > > >> On 09/15/14 22:51, O. Hartmann wrote: > >>> Am Mon, 15 Sep 2014 17:39:26 -0700 > >>> Nathan Whitehorn schrieb: > >>> > >>>> On 09/15/14 17:36, Allan Jude wrote: > >>>>> On 2014-09-15 20:05, O. Hartmann wrote: > >>>>>> Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop= works for UEFI > >>>>>> fine. After I updated the sources to r271649, recompiled world an= d kernel (as > >>>>>> well as installed), now I get stuck with the screen message: > >>>>>> > >>>>>>>> FreeBSD EFI boot block > >>>>>> Loader path: /boot/loader.efi > >>>>>> > >>>>>> and nothing happens. After a couple of minutes, the system reboots. > >>>>>> > >>>>>> What happened and how can this problem be solved? > >>>>>> > >>>>> You might need to update the boot1.efi file on the UEFI partition (= small > >>>>> FAT partition on the disk) > >>>>> > >>>>> I am not sure how 'in sync' boot1.efi (on the fat partiton) and > >>>>> loader.efi have to be. > >>>>> > >>>>> https://wiki.freebsd.org/UEFI > >>>>> > >>>> boot1.efi is designed never to need updating. (It also hasn't changed > >>>> since April) > >>>> -Nathan > >>> But it has changed bytesize when I recompiled world with recent sourc= es compared to > >>> the boot.efi size from the USB image I installed from (revision see a= bove). > >> Probably compiler updates or something? I really wouldn't worry about = it > >> too much. I'd worry more about loader, since we know boot1 could use t= he > >> console but loader doesn't show up. > >> > >>> How to update bootcode on UEFI layout? I created a GPT partition with= type efi (1 > >>> GB) as well as a 512KB partition typed freebsd-boot. > >> How did you set it up in the first place? If you have a FreeBSD-only > >> system partition (like the installer sets up), you just dd > >> /boot/boot1.efifat to the EFI partition. Otherwise, it's FAT and you > >> copy /boot/boot1.efi to somewhere your boot manager can find it. > >> > >>> I'm new to EFI and the way the notebook now behaves is really strange= . While the USB > >>> drive image used to boot with new console enabled, it now boots again= with the old > >>> console and 800x640 resolution. This might indicate some minor but ve= ry effective > >>> mistake I made. > >>> > >> The EFI boot block finds the first UFS partition -- on any disk -- and > >> tries to boot from it. If you have multiple FreeBSD disks connected, > >> that will very likely result in madness. > >> -Nathan > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.= org" > > After I managed to install the OS and updated to the most recent world,= it took two > > days to have all the installations prepared. Now I'm about the configur= e X11 and run > > into another very annoying situation. > > > > The Laptop is a Lenovo ThinkPad Edge E540 equipted with the following C= PU/iGPU and > > dedicated GPU: > > > > CPU Intel i5-4200M (Haswell) at 2.5 GHz with iGPU Intel HD Graphics 4600 > > > > GPU: nVidia GT 740M mobile GPU. > > > > EFI Version 2.31 > > EFI Firmware: Lenovo (rev. 05648) > > > > In the Firmware/EFI/BIOS the primary GPU is selected to be the nVidia G= T 740M. Boot is > > EFI only, no CSM support. With CSM support enabled a VGA screen with 64= 0x400 pixel > > shows up. Non UEFI options doesn't boot this system at all! > > > > Any attempt to bring up the nVidia GPU (starting X for testing) ends up= in a blank > > screen, stuck mousepointer, no keyboard. I even can not switch to anoth= er console! > > When X server started the first time on tty9, I can switch to another c= onsole. But the > > moment I switch back to ttyv9 everything is frozen and as described abo= ve. >=20 > Try xf86-video-scfb instead? >=20 > > When the system boots, I do not see a loader! Where is the loader I'm u= sed to see > > when I have the chance to switch to single user mode, console or switch= off ACPI? >=20 > There is no beastie menu for UEFI, and will not be, since it UEFI's=20 > terminal emulation does not provide the required features. You can boot=20 > single user from the loader command line, however, with boot -s, for=20 > example. The interface is identical to what you get if you choose=20 > "Loader prompt" in the usual menu. Good to know. >=20 > > Because I need X11 up (and it should be running on the nVidia GPU for p= erformance > > reasons), I tried to get back to the legacy "sc" console in textmode si= nce I read > > about several issues and immature vt() system, so I put those lines in > > the /boot/loader.conf: > > > > hw.vga.textmode=3D1 > > hw.vty=3Dsc > > > > (tried also hw.vty=3Dvt). > > > > But with either of those lines in the loader thing get more annoying an= d nasty: The > > system doesn't show even a console, it is stuck with this sparse EFI bo= ot message, > > last lines are > > > > dimensions xxxx x yyyy > > stride xxxx > > masks 0xfffffff [...] > > > > and the rest of the screen is blank. System remains unusable, the HDD i= s working and > > obviously booting the system but incapable of presenting a screen. When= booting the > > USB drive image, this initial EFI message gets overwritten (no screen b= lanking, the > > kernel messages starts writing over this message like in the first days= of > > computers ...). In the case described above that doesn't happen at all. >=20 > syscons does not support UEFI systems at all. Since it can't initialize=20 > the VGA hardware, you get a blank screen. hw.vga.textmode also won't=20 > have any effect since EFI systems don't use the vga driver for console,=20 > instead using an EFI-provided framebuffer structure through the vt_efifb= =20 > driver. Oh, I lack in informations of how this new system is working. So vga is obs= olete then and should be this efifb then. >=20 > > After I deleted.commented out the lines > > > > hw.vga.textmode=3D1 > > hw.vty=3Dsc > > > > in loader.conf the system is booting again - and clears the initial EFI= messages > > before dumping the screen with kernel messages, as expected. > > > > Well, at the end, it seems I sit in front of two days useless labor, ne= w hardware, > > UEFI and no X11. >=20 > One thing you might want to try that got my Haswell laptop up is to use=20 > the x11-drivers/xf86-video-scfb driver. This uses the vt framebuffer=20 > directly. It's more or less the equivalent of the VESA driver since it=20 > is unaccelerated, but it will work. We really need actual Haswell=20 > graphics drivers (I suspect they are required to get the multiple GPU=20 > handoff to work as well). > -Nathan This laptop has, as mentioned, also a dedicated GPU, nVidia GT 740M which i= s supposed to work with a new driver BLOB 343.13 (driver: nvidia). I do not want to use t= he iGPU HD4600, also it could save energy/battery lifetime, but there is no method = to switch between both. I'd like to use this GPU, not the slower HD4600 Haswell iGPU. As far as I know from other notebooks I ran with FreeBSD, this x11-drivers/xf86-video-scfb as well as its VESA counterpart is insanely slo= w and not very usefull for high resolution displays. It might be useful having a display a= nyway. But, anyway thanks for your assistance, very appreciated. Regards, Oliver --Sig_/5DJVG92CjocLIiN0AuwqYRh Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUGS6KAAoJEOgBcD7A/5N8P/AIAKS+QPgjUg7oOOmjbmKmnTV/ DCWwS1A09IHnqy2PBs6DZsAk+h5VepG0iuAN7ugAbhx9o0OQalpF+2PMuspu3W7c TKqKWpzlxHyJMyUr/vBpMutXoWVKswP/C01Ltp32Ja9OX0qV/5eFbhrUYCLJLawa Mrp0R0/GAtkjNpUSMEYUtl7HHKgavE00YML5GoLlMqikGCvtCX5U1uBBNwIGzbxP GjTiZDWl1otbgYTJwZeSd0jqwTvEjVtOjlKUcBjCeDuTH8m/oxqd9xtsQGWjRoN7 LXQ3h7tnAjaqxBWdcZqs5THxq9qOrZphyxWa2uilsFj+RkAz7PPaHhymFiu+Rh0= =Oj7e -----END PGP SIGNATURE----- --Sig_/5DJVG92CjocLIiN0AuwqYRh-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 06:57:21 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1DEF699; Wed, 17 Sep 2014 06:57:21 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 871B3F4B; Wed, 17 Sep 2014 06:57:20 +0000 (UTC) Received: from [192.168.0.7] (cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52]) (authenticated bits=0) by theravensnest.org (8.14.9/8.14.9) with ESMTP id s8H6vFed008803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Sep 2014 06:57:17 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52] claimed to be [192.168.0.7] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: usb printer vs cups From: David Chisnall In-Reply-To: <5419238E.8050708@FreeBSD.org> Date: Wed, 17 Sep 2014 07:57:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54133325.9070302@FreeBSD.org> <5419238E.8050708@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-stable List , FreeBSD Current , freebsd-desktop@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 06:57:21 -0000 There are a couple of similar issues currently. The other one that = comes to mind is that every X11 application that needs to use OpenGL (or = similar) must open /dev/dri/{something}, but the default permissions = only permit root. The correct solution is probably to ship a devfs.conf that puts these = devices in the a sensible group. For USB printers, we should probably = have a printers group and make cupsd run with that group (or set the GUI = of cups and printers to the same number if that's too difficult). =20 David On 17 Sep 2014, at 07:00, Andriy Gapon wrote: >=20 > Soliciting help. >=20 > -------- Forwarded Message -------- >=20 > =46rom my experience I think that cupsd executes backend tools with = all uids and > gids set to cups and no supplementary groups. In the case of USB = printers the > backends need to access /dev/usbctl and /dev/usb/foobar that = corresponds to a > printer. That means that the access to those devices must be somehow = granted to > cups:cups. > How do people solve this? What kind of permissions / configuration do = you use? >=20 > P.S. > Maybe I over-generalized the issue to all USB printers. My personal = experience > is with an HP printer handled by hplip / hplip-plugin. > --=20 > Andriy Gapon >=20 >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 07:02:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19AB5905 for ; Wed, 17 Sep 2014 07:02:27 +0000 (UTC) Received: from mailhost.netlab.sk (mailhost.netlab.sk [84.245.65.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 984BCA4 for ; Wed, 17 Sep 2014 07:02:25 +0000 (UTC) Received: from zeta.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan) by mailhost.netlab.sk with ESMTPA; Wed, 17 Sep 2014 09:02:23 +0200 id 00DD60FA.541931FF.000022B3 Date: Wed, 17 Sep 2014 09:02:16 +0200 From: Milan Obuch To: Maciej Milewski Subject: Re: Huawei E3272 tester needed Message-ID: <20140917090216.108a8b60@zeta.dino.sk> In-Reply-To: <5418A0F6.6020207@dat.pl> References: <20140916165257.3a0cee9b@zeta.dino.sk> <541895C6.3030304@dat.pl> <20140916221812.649a1756@zeta.dino.sk> <5418A0F6.6020207@dat.pl> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; i386-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG, nick@van-laarhoven.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 07:02:27 -0000 On Tue, 16 Sep 2014 22:43:34 +0200 Maciej Milewski wrote: > On 16.09.2014 22:18, Milan Obuch wrote: > > On Tue, 16 Sep 2014 21:55:50 +0200 > > Maciej Milewski wrote: > > > >> On 16.09.2014 16:52, Milan Obuch wrote: > >>> On Tue, 16 Sep 2014 09:40:45 +0200 > >>> Nick Hibma wrote: > >>> > >>>> Hi, > >>>> > >>>> Is there someone who is able to test support for the Huawei E3272 > >>>> card with CURRENT after 269584? I have not been able to confirm > >>>> that it works. > >>>> > >>>> Thanks in advance. > >>>> > >>>> Nick > >>>> > >>> Hi, > >>> > >>> I did fresh svn update, rebuilt world+kernel, but it does not work > >>> for me... > > [ snip ] > > > >>> I tried attach/detach device beore and after loading u3g (just in > >>> case...) and if_cdce kernel modules, but I saw no changes. > >>> > >>> From 'usbconfig dump_device_desc': > >>> > >>> ugen1.3: at usbus1, cfg=0 > >>> md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) > >>> > >>> bLength = 0x0012 > >>> bDescriptorType = 0x0001 > >>> bcdUSB = 0x0200 > >>> bDeviceClass = 0x0000 > >>> bDeviceSubClass = 0x0000 > >>> bDeviceProtocol = 0x0000 > >>> bMaxPacketSize0 = 0x0040 > >>> idVendor = 0x12d1 > >>> idProduct = 0x1f01 > >>> bcdDevice = 0x0102 > >>> iManufacturer = 0x0002 > >>> iProduct = 0x0001 > >>> iSerialNumber = 0x0004 > >>> bNumConfigurations = 0x0001 > >>> > >>> If anything else is important, let me know. > >>> > >>> Regards, > >>> Milan > >> Try ejecting first this cd2 drive by cdcontrol eject or camcontrol > >> eject. I had such scenario with other usb device and that helped. > >> > > Nothing. > > > > # camcontrol eject cd2 > > Unit stopped successfully, Media ejected > > > > That's all. No new device created, neither in /dev directory nor in > > ifconfig listing. Nothing in console log. > > > > From 'usbconfig dump_all_config_desc': > > > > ugen1.3: at usbus1, cfg=0 md=HOST > > spd=HIGH (480Mbps) pwr=ON (500mA) > > > > Configuration index 0 > > > > bLength = 0x0009 > > bDescriptorType = 0x0002 > > wTotalLength = 0x0020 > > bNumInterfaces = 0x0001 > > bConfigurationValue = 0x0001 > > iConfiguration = 0x0003 > > bmAttributes = 0x0080 > > bMaxPower = 0x00fa > > > > Interface 0 > > bLength = 0x0009 > > bDescriptorType = 0x0004 > > bInterfaceNumber = 0x0000 > > bAlternateSetting = 0x0000 > > bNumEndpoints = 0x0002 > > bInterfaceClass = 0x0008 > > bInterfaceSubClass = 0x0006 > > bInterfaceProtocol = 0x0050 > > iInterface = 0x0000 > > > > Endpoint 0 > > bLength = 0x0007 > > bDescriptorType = 0x0005 > > bEndpointAddress = 0x0001 > > bmAttributes = 0x0002 > > wMaxPacketSize = 0x0200 > > bInterval = 0x0000 > > bRefresh = 0x0000 > > bSynchAddress = 0x0000 > > > > Endpoint 1 > > bLength = 0x0007 > > bDescriptorType = 0x0005 > > bEndpointAddress = 0x0081 > > bmAttributes = 0x0002 > > wMaxPacketSize = 0x0200 > > bInterval = 0x0000 > > bRefresh = 0x0000 > > bSynchAddress = 0x0000 > > > > Regards, > > Milan > Your device has different idProduct than this added in patch. It might > be caused by different configuration of the device/different provider > who sells devices. > I know that some devices might show up as HiLink mode(cdce) or serial > mode(u3g). And this might be changed by flashing different firmware or > sometimes by using usb_modeswitch(under linux not sure if it works > under freebsd). > Example is here: > https://forum.pfsense.org/index.php?topic=48780.20;wap2 > Thanks, that's working, verbatim: usb_modeswitch -v 12d1 -p 1f01 -V 012d1 -P 014db -M "55534243123456780000000000000a11062000000000000100000000000000" -W After that, if_cdce and uether kernel modules are automatically loaded and dhclient ue0 successfully acquires IP address. And it is working in 9.2-STABLE, 10.0-STABLE systems I tested with no modification to sources, so this is a good solution for me. Regards, Milan From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 07:05:24 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB2FBA46; Wed, 17 Sep 2014 07:05:24 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C8BE8C2; Wed, 17 Sep 2014 07:05:22 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA23590; Wed, 17 Sep 2014 10:05:21 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XU9Im-0008tO-Ks; Wed, 17 Sep 2014 10:05:20 +0300 Message-ID: <54193273.6080709@FreeBSD.org> Date: Wed, 17 Sep 2014 10:04:19 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Hans Petter Selasky , freebsd-stable List , FreeBSD Current Subject: Re: Fwd: usb printer vs cups References: <54133325.9070302@FreeBSD.org> <5419238E.8050708@FreeBSD.org> <5419285D.8020909@selasky.org> In-Reply-To: <5419285D.8020909@selasky.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: freebsd-desktop@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 07:05:25 -0000 On 17/09/2014 09:21, Hans Petter Selasky wrote: > On 09/17/14 08:00, Andriy Gapon wrote: >> >> Soliciting help. >> >> -------- Forwarded Message -------- >> >>> From my experience I think that cupsd executes backend tools with all uids and >> gids set to cups and no supplementary groups. In the case of USB printers the >> backends need to access /dev/usbctl and /dev/usb/foobar that corresponds to a >> printer. That means that the access to those devices must be somehow granted to >> cups:cups. >> How do people solve this? What kind of permissions / configuration do you use? >> >> P.S. >> Maybe I over-generalized the issue to all USB printers. My personal experience >> is with an HP printer handled by hplip / hplip-plugin. >> > > Hi, > > The /usr/ports/print/cups-base should be updated. > > The pkg-message should not say that: > > > # FreeBSD 8.x > add path 'usb*' mode 0770 group cups > add path 'ugen*' mode 0660 group cups > > add path 'usb/0.2.*' mode 0660 group cups > > Is needed. This is wrong. > > Instead make cups-base install the attached devd configuration file in > /usr/local/etc/devd/ which does the needed chown for printers only. The problem is that my printer does not work if I also do not change permissions on /dev/usbctl. But I do not really want /dev/usbctl to be owned by cups as there can be other services / users that need access to usbctl. Is there anything smarter than mucking with device ownership? In other words, I have no problem granting cups user or group a full access to all USB devices. I have a problem with changing owner or group of USB devices to cups, because that interferes with other accesses to those devices. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 07:07:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F325DB3 for ; Wed, 17 Sep 2014 07:07:02 +0000 (UTC) Received: from mailhost.netlab.sk (mailhost.netlab.sk [84.245.65.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 032ADFD for ; Wed, 17 Sep 2014 07:07:01 +0000 (UTC) Received: from zeta.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan) by mailhost.netlab.sk with ESMTPA; Wed, 17 Sep 2014 09:07:00 +0200 id 00DD60F6.54193314.00002323 Date: Wed, 17 Sep 2014 09:06:59 +0200 From: Milan Obuch To: Hans Petter Selasky Subject: Re: Huawei E3272 tester needed Message-ID: <20140917090659.3228cc27@zeta.dino.sk> In-Reply-To: <541917FE.3060801@selasky.org> References: <20140916165257.3a0cee9b@zeta.dino.sk> <541895C6.3030304@dat.pl> <20140916221812.649a1756@zeta.dino.sk> <54189F07.7010301@selasky.org> <20140916225205.6d7a8bac@zeta.dino.sk> <541917FE.3060801@selasky.org> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; i386-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG, milu@dat.pl, nick@van-laarhoven.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 07:07:02 -0000 On Wed, 17 Sep 2014 07:11:26 +0200 Hans Petter Selasky wrote: > On 09/16/14 22:52, Milan Obuch wrote: > > On Tue, 16 Sep 2014 22:35:19 +0200 > > Hans Petter Selasky wrote: > > > >> On 09/16/14 22:18, Milan Obuch wrote: > >>> On Tue, 16 Sep 2014 21:55:50 +0200 > >>> Maciej Milewski wrote: > >>> > >>>> On 16.09.2014 16:52, Milan Obuch wrote: > >>>>> On Tue, 16 Sep 2014 09:40:45 +0200 > >>>>> Nick Hibma wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> Is there someone who is able to test support for the Huawei > >>>>>> E3272 card with CURRENT after 269584? I have not been able to > >>>>>> confirm that it works. > >>>>>> > >>>>>> Thanks in advance. > >>>>>> > >>>>>> Nick > >>>>>> > >>>>> Hi, > >>>>> > >>>>> I did fresh svn update, rebuilt world+kernel, but it does not > >>>>> work for me... > >>> > >>> [ snip ] > >>> > >> > >> Hi, > >> > >> According to the modeswitch: > >> > >> usbconfig -d X.Y add_quirk UQ_MSC_EJECT_HUAWEISCSI2 > >> > >> Then re-plug the device. > >> > >> --HPS > >> > > > > Well, again, no change: > > > > #usbconfig -d 1.3 add_quirk UQ_MSC_EJECT_HUAWEISCSI2 > > Adding quirk 'UQ_MSC_EJECT_HUAWEISCSI2' failed, continuing. > > > > Did I do it right? Something is surely wrong. By the way, from > > uname: > > > > 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271671M > > > > The only modified file is modules/drm2/Makefile because for some > > reason radeonkms does not currently build, so I excluded is as a > > fast workaround. > > > > Hi, > > Did you kldload usb_quirk > > And does: > > usbconfig dump_quirk_names yield something? > > --HPS > Well, I missed somehow usb_quirk module, but even with this module loaded, no change in behavior was seen. Thanks to other suggestion I verified solution with usb_modeswitch working, even on stock 9.2 and 10.0 systems. Anyway, if you would like me to test something else, just drop me a note. Regards, Milan From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 07:20:57 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8A7A150 for ; Wed, 17 Sep 2014 07:20:57 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 68D94276 for ; Wed, 17 Sep 2014 07:20:57 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id EBC0C24800B; Wed, 17 Sep 2014 09:20:54 +0200 (CEST) Message-ID: <5419364B.3020308@selasky.org> Date: Wed, 17 Sep 2014 09:20:43 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Milan Obuch Subject: Re: Huawei E3272 tester needed References: <20140916165257.3a0cee9b@zeta.dino.sk> <541895C6.3030304@dat.pl> <20140916221812.649a1756@zeta.dino.sk> <54189F07.7010301@selasky.org> <20140916225205.6d7a8bac@zeta.dino.sk> <541917FE.3060801@selasky.org> <20140917090659.3228cc27@zeta.dino.sk> In-Reply-To: <20140917090659.3228cc27@zeta.dino.sk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG, milu@dat.pl, nick@van-laarhoven.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 07:20:57 -0000 On 09/17/14 09:06, Milan Obuch wrote: > On Wed, 17 Sep 2014 07:11:26 +0200 > Hans Petter Selasky wrote: > >> On 09/16/14 22:52, Milan Obuch wrote: >>> On Tue, 16 Sep 2014 22:35:19 +0200 >>> Hans Petter Selasky wrote: >>> >>>> On 09/16/14 22:18, Milan Obuch wrote: >>>>> On Tue, 16 Sep 2014 21:55:50 +0200 >>>>> Maciej Milewski wrote: >>>>> >>>>>> On 16.09.2014 16:52, Milan Obuch wrote: >>>>>>> On Tue, 16 Sep 2014 09:40:45 +0200 >>>>>>> Nick Hibma wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Is there someone who is able to test support for the Huawei >>>>>>>> E3272 card with CURRENT after 269584? I have not been able to >>>>>>>> confirm that it works. >>>>>>>> >>>>>>>> Thanks in advance. >>>>>>>> >>>>>>>> Nick >>>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I did fresh svn update, rebuilt world+kernel, but it does not >>>>>>> work for me... >>>>> >>>>> [ snip ] >>>>> >>>> >>>> Hi, >>>> >>>> According to the modeswitch: >>>> >>>> usbconfig -d X.Y add_quirk UQ_MSC_EJECT_HUAWEISCSI2 >>>> >>>> Then re-plug the device. >>>> >>>> --HPS >>>> >>> >>> Well, again, no change: >>> >>> #usbconfig -d 1.3 add_quirk UQ_MSC_EJECT_HUAWEISCSI2 >>> Adding quirk 'UQ_MSC_EJECT_HUAWEISCSI2' failed, continuing. >>> >>> Did I do it right? Something is surely wrong. By the way, from >>> uname: >>> >>> 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271671M >>> >>> The only modified file is modules/drm2/Makefile because for some >>> reason radeonkms does not currently build, so I excluded is as a >>> fast workaround. >>> >> >> Hi, >> >> Did you kldload usb_quirk >> >> And does: >> >> usbconfig dump_quirk_names yield something? >> >> --HPS >> > > Well, I missed somehow usb_quirk module, but even with this module > loaded, no change in behavior was seen. Thanks to other suggestion I > verified solution with usb_modeswitch working, even on stock 9.2 and > 10.0 systems. > > Anyway, if you would like me to test something else, just drop me a > note. > Hi, This quirk should be done by the u3g module. Can you make a patch for U3G in sys/dev/usb/serial/u3g.c ? See existing quirks. Else we'll add the one from modeswitch. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 07:25:05 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 917CD320; Wed, 17 Sep 2014 07:25:05 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7C5E62DF; Wed, 17 Sep 2014 07:25:04 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA23826; Wed, 17 Sep 2014 10:25:03 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XU9bq-0008ud-M1; Wed, 17 Sep 2014 10:25:02 +0300 Message-ID: <5419372A.2050509@FreeBSD.org> Date: Wed, 17 Sep 2014 10:24:26 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Hans Petter Selasky , freebsd-stable List , FreeBSD Current Subject: Re: Fwd: usb printer vs cups References: <54133325.9070302@FreeBSD.org> <5419238E.8050708@FreeBSD.org> <5419285D.8020909@selasky.org> <54193273.6080709@FreeBSD.org> In-Reply-To: <54193273.6080709@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-desktop@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 07:25:05 -0000 On 17/09/2014 10:04, Andriy Gapon wrote: > On 17/09/2014 09:21, Hans Petter Selasky wrote: >> Instead make cups-base install the attached devd configuration file in >> /usr/local/etc/devd/ which does the needed chown for printers only. > > The problem is that my printer does not work if I also do not change permissions > on /dev/usbctl. But I do not really want /dev/usbctl to be owned by cups as > there can be other services / users that need access to usbctl. Actually I take this back. My /dev/usbctl was not world readable as it should be by default. Not sure why I changed its permissions from 0644 to 0660, probably a litle bit of paranoia. Now that I changed the permissions to 0664 and installed your script printing works without problems. Thanks! > Is there anything smarter than mucking with device ownership? > > In other words, I have no problem granting cups user or group a full access to > all USB devices. I have a problem with changing owner or group of USB devices > to cups, because that interferes with other accesses to those devices. > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 08:27:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0D54361; Wed, 17 Sep 2014 08:27:40 +0000 (UTC) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8EEB1B8A; Wed, 17 Sep 2014 08:27:40 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id i13so1360095qae.10 for ; Wed, 17 Sep 2014 01:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=vH/dz2Jc5qn9K8OwxTiK7TPf3lonjz0KkWOIQmMaFro=; b=KzvJiwald8RwHzMRZjz5lwCdDwSR/gRLrobEX+VrswyvMY9gy+yE2Tvm7cSfN/lUyI Q/+xPlfVPOF7/chp0yVGDwo4cb/q2UrMpQpGrjims3a3q0Q8KmUSlEuxoJ+kEIqQnqFF 7tLmUaF6+TYi12Xuv+QZeMb3CYpdH0YAKpo0tnhKQI1nF8gYQo5V8fXtqinrWQB262Mv KZvJpPpDrapaKGvWdHyTdIjFnkncG6T54+eKJlthR2lcIgBQ/jh/MFOp9PZyhG3sJ4HU 060MFPPi/RHzsP+iv2LTKCioSnZOFo61eLSDAT4T1ScfpJKOt9KHx3d5qNszIF5e8v1e zm6g== MIME-Version: 1.0 X-Received: by 10.229.84.133 with SMTP id j5mr53811723qcl.14.1410942459472; Wed, 17 Sep 2014 01:27:39 -0700 (PDT) Received: by 10.140.104.241 with HTTP; Wed, 17 Sep 2014 01:27:39 -0700 (PDT) Date: Wed, 17 Sep 2014 10:27:39 +0200 Message-ID: Subject: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD From: Stefano Garzarella To: freebsd-current , "freebsd-net@freebsd.org" , gnn@neville-neil.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 08:27:41 -0000 Hi all, I have recently worked, during my master=E2=80=99s thesis with the supervis= ion of Prof. Luigi Rizzo, on a project to add GSO (Generic Segmentation Offload) support in FreeBSD. I will present this project at EuroBSDcon 2014, in Sofia (Bulgaria) on September 28, 2014. Following is a brief description of our project: The use of large frames makes network communication much less demanding for the CPU. Yet, backward compatibility and slow links requires the use of 1500 byte or smaller frames. Modern NICs with hardware TCP segmentation offloading (TSO) address this problem. However, a generic software version (GSO) provided by the OS has reason to exist, for use on paths with no suitable hardware, such as between virtual machines or with older or buggy NICs. Much of the advantage of TSO comes from crossing the network stack only once per (large) segment instead of once per 1500-byte frame. GSO does the same both for segmentation (TCP) and fragmentation (UDP) by doing these operations as late as possible. Ideally, this could be done within the device driver, but that would require modifications to all drivers. A more convenient, similarly effective approach is to segment just before the packet is passed to the driver (in ether_output()). Our preliminary implementation supports TCP and UDP on IPv4/IPv6; it only intercepts packets large than the MTU (others are left unchanged), and only when GSO is marked as enabled for the interface. Segments larger than the MTU are not split in tcp_output(), udp_output(), or ip_output(), but marked with a flag (contained in m_pkthdr.csum_flags), which is processed by ether_output() just before calling the device driver. ether_output(), through gso_dispatch(), splits the large frame as needed, creating headers and possibly doing checksums if not supported by the hardware. In experiments agains an LRO-enabled receiver (otherwise TSO/GSO are ineffective) we have seen the following performance, taken at different clock speeds (because at top speeds the 10G link becomes the bottleneck): Testing enviroment (all with Intel 10Gbit NIC) Sender: FreeBSD 11-CURRENT - CPU i7-870 at 2.93 GHz + Turboboost Receiver: Linux 3.12.8 - CPU i7-3770K at 3.50GHz + Turboboost Benchmark tool: netperf 2.6.0 --- TCP/IPv4 packets (checksum offloading enabled) --- Freq. TSO GSO none Speedup [GHz] [Gbps] [Gbps] [Gbps] GSO-none 2.93 9347 9298 8308 12 % 2.53 9266 9401 6771 39 % 2.00 9408 9294 5499 69 % 1.46 9408 8087 4075 98 % 1.05 9408 5673 2884 97 % 0.45 6760 2206 1244 77 % --- TCP/IPv6 packets (checksum offloading enabled) --- Freq. TSO GSO none Speedup [GHz] [Gbps] [Gbps] [Gbps] GSO-none 2.93 7530 6939 4966 40 % 2.53 5133 7145 4008 78 % 2.00 5965 6331 3152 101 % 1.46 5565 5180 2348 121 % 1.05 8501 3607 1732 108 % 0.45 3665 1505 651 131 % --- UDP/IPv4 packets (9K) --- Freq. GSO none Speedup [GHz] [Gbps] [Gbps] GSO-none 2.93 9440 8084 17 % 2.53 7772 6649 17 % 2.00 6336 5338 19 % 1.46 4748 4014 18 % 1.05 3359 2831 19 % 0.45 1312 1120 17 % --- UDP/IPv6 packets (9K) --- Freq. GSO none Speedup [GHz] [Gbps] [Gbps] GSO-none 2.93 7281 6197 18 % 2.53 5953 5020 19 % 2.00 4804 4048 19 % 1.46 3582 3004 19 % 1.05 2512 2092 20 % 0.45 998 826 21 % We tried to change as little as possible the network stack to add GSO support. To avoid changing API/ABI, we temporarily used spare fields in struct tcpcb (TCP Control Block) and struct ifnet to store some information related to GSO (enabled, max burst size, etc.). The code that performs the segmentation/fragmentation is contained in the file gso.[h|c] in sys/net. We used 4 bit in m_pkthdr.csum_flags (CSUM_GSO_MASK) to encode the packet type (TCP/IPv4, TCP/IPv6, etc) to prevent access to the TCP/IP/Ethernet headers of each packet. In ether_output_frame(), if the packet requires the GSO ((m->m_pkthdr.csum_flags & CSUM_GSO_MASK) !=3D 0), it is segmented or fragmented, and then they are sent to the device driver. At https://github.com/stefano-garzarella/freebsd-gso you can find the kernel patches for FreeBSD-current, FreeBSD 10-stable, FreeBSD 9-stable, a simple application (gso-stats.c) that prints the GSO statistics and picobsd images with GSO support. At https://github.com/stefano-garzarella/freebsd-gso-src you can get the FreeBSD source with GSO patch (various branch for FreeBSD current, 10-stable, 9-stable). Any feedbacks, comments, questions are welcome=E2=80=8B. Thank you very much, Stefano Garzarella ---------------------------------------------------------------------------= --------------------------------- How to use GSO: - Apply the right kernel patch. - To compile the GSO support add =E2=80=98 options GSO ' to your kernel con= fig file and rebuild a kernel. - To manage the GSO parameters there are some sysctls: - net.inet.tcp.gso - GSO enable on TCP communications (!=3D0) - net.inet.udp.gso - GSO enable on UDP communications (!=3D0) - for each interface: - net.gso.dev."ifname=E2=80=9D.max_burst - GSO burst length limit [default: IP_MAXPACKET=3D65535] - net.gso.dev."ifname=E2=80=9D.enable_gso - GSO enable on =E2=80= =9Cifname=E2=80=9D interface (!=3D0) - To show statistics: - make sure that the GSO_STATS macro is defined in sys/net/gso.h - use the simple gso-stats.c application to access the sysctl net.gso.stats that contains the address of the gsostats structure (defined in gso.h) which records the statistics. (compile with -I/path/to/kernel/src/patched/) ---------------------------------------------------------------------------= --------------------------------- --=20 *Stefano Garzarella* stefano.garzarella@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 10:20:19 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 182B42E4 for ; Wed, 17 Sep 2014 10:20:19 +0000 (UTC) Received: from man.dat.pl (dat.pl [80.51.155.34]) by mx1.freebsd.org (Postfix) with ESMTP id C7BA4985 for ; Wed, 17 Sep 2014 10:20:17 +0000 (UTC) Received: from man.dat.pl (localhost [127.0.0.1]) by man.dat.pl (Postfix) with ESMTP id 99969D16A4C; Wed, 17 Sep 2014 12:20:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at dat.pl Received: from man.dat.pl ([127.0.0.1]) by man.dat.pl (man.dat.pl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8qt_POmNN0Cp; Wed, 17 Sep 2014 12:20:15 +0200 (CEST) Message-ID: <5419605E.7010200@dat.pl> Date: Wed, 17 Sep 2014 12:20:14 +0200 From: Maciej Milewski MIME-Version: 1.0 To: Milan Obuch Subject: Re: Huawei E3272 tester needed References: <20140916165257.3a0cee9b@zeta.dino.sk> <541895C6.3030304@dat.pl> <20140916221812.649a1756@zeta.dino.sk> <5418A0F6.6020207@dat.pl> <20140917090216.108a8b60@zeta.dino.sk> In-Reply-To: <20140917090216.108a8b60@zeta.dino.sk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@FreeBSD.ORG, nick@van-laarhoven.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 10:20:19 -0000 On 17.09.2014 09:02, Milan Obuch wrote: > On Tue, 16 Sep 2014 22:43:34 +0200 > Maciej Milewski wrote: > >> On 16.09.2014 22:18, Milan Obuch wrote: >> Your device has different idProduct than this added in patch. It might= >> be caused by different configuration of the device/different provider >> who sells devices. >> I know that some devices might show up as HiLink mode(cdce) or serial >> mode(u3g). And this might be changed by flashing different firmware or= >> sometimes by using usb_modeswitch(under linux not sure if it works >> under freebsd). >> Example is here: >> https://forum.pfsense.org/index.php?topic=3D48780.20;wap2 >> > Thanks, that's working, verbatim: > > usb_modeswitch -v 12d1 -p 1f01 -V 012d1 -P 014db -M "555342431234567800= 00000000000a11062000000000000100000000000000" -W > > After that, if_cdce and uether kernel modules are automatically loaded > and dhclient ue0 successfully acquires IP address. > > And it is working in 9.2-STABLE, 10.0-STABLE systems I tested with no > modification to sources, so this is a good solution for me. > > Regards, > Milan Glad to hear that helped, can you follow Hans suggestion for trying already defined quirks? It's posiible that there is one working. --=20 Pozdrawiam, Maciej Milewski From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 14:16:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A269F91A for ; Wed, 17 Sep 2014 14:16:19 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 617C1303 for ; Wed, 17 Sep 2014 14:16:19 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id tr6so1737318ieb.26 for ; Wed, 17 Sep 2014 07:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=OM276n/GhEJex3kZ1jY6QfuDUP12JXVpVjnJB2xJlR8=; b=va+wnu2UoKvI0dEyBkp2Dy8rBwhNRwi6M/Vnl9Y0vyhcBDkVYpPZz0UHwbYVtQJsEI gcknajDcugDDeIYHdicnyseftLaqaX2IpTrgg3TdFQ+HN6zzwrOQq4asDNXLf1g5+Xbk u5/I9fMEZ58hfoG6ZOEmljqX573JcCma6qtz1ZvfSK/7l1DjEMVx4MHzOlSmmYaDejoI a71CQekaJj7uFN4e8HGlNjEEoVRQSEa5uMmTtTozwMzvKiE+WA7mMMFbgKhijfp8r29H K6s3QDj2t24kv3iHXO99QbLuj7YQO/RRtEH7PKquzUjUejz3ceDWaNiCL1I/HQNwgNAA 143Q== X-Received: by 10.50.43.138 with SMTP id w10mr6229732igl.33.1410963378876; Wed, 17 Sep 2014 07:16:18 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.44.196 with HTTP; Wed, 17 Sep 2014 07:15:57 -0700 (PDT) In-Reply-To: <20140916235039.34e9284f.ohartman@zedat.fu-berlin.de> References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> <5417E20D.8070607@freebsd.org> <20140916235039.34e9284f.ohartman@zedat.fu-berlin.de> From: Ed Maste Date: Wed, 17 Sep 2014 10:15:57 -0400 X-Google-Sender-Auth: Qt9H6pMA17_TvZMIkruC7wk_YXQ Message-ID: Subject: Re: CURRENT: EFI boot failure To: "O. Hartmann" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 14:16:19 -0000 On 16 September 2014 17:50, O. Hartmann wrote= : > ... > > hw.vga.textmode=3D1 > hw.vty=3Dsc > > (tried also hw.vty=3Dvt). > ... One clarification for the archives: there's no tunable "hw.vty", it's "kern.vty". From vt(4): kern.vty When both vt and sc(4) have been compiled into the kernel, the one to use for the system console can be selected by setting t= his value to =E2=80=98vt=E2=80=99 or =E2=80=98sc=E2=80=99. If thi= s value is not set, sc(4) is used. Although I see that needs an update, since the situation is now: If this value is not set, sc(4) is used, unless the system is booted via UEFI. In the UEFI-boot case vt(4) is used. (Tracked in PR 193710) From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 15:39:21 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5600E16 for ; Wed, 17 Sep 2014 15:39:21 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B3C2DD74 for ; Wed, 17 Sep 2014 15:39:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s8HFdLSw071326 for ; Wed, 17 Sep 2014 15:39:21 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s8HFdL8h071325 for current@FreeBSD.org; Wed, 17 Sep 2014 15:39:21 GMT (envelope-from bdrewery) Received: (qmail 50752 invoked from network); 17 Sep 2014 10:39:19 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 17 Sep 2014 10:39:19 -0500 Message-ID: <5419AB24.9050809@FreeBSD.org> Date: Wed, 17 Sep 2014 10:39:16 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: current@FreeBSD.org Subject: Re: Cam panic on r271170 References: <5418F1B9.2000903@FreeBSD.org> In-Reply-To: <5418F1B9.2000903@FreeBSD.org> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9rTkdCP9wLjnifF3vaaugJLCEVSIWbxbh" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 15:39:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9rTkdCP9wLjnifF3vaaugJLCEVSIWbxbh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/16/2014 9:28 PM, Bryan Drewery wrote: > I've been getting this quite frequently on head recently. I have dumps > if anyone is interested in more information. >=20 >> Fatal trap 9: general protection fault while in kernel mode >> cpuid =3D 10; Memory modified after free 0xfffff8003e0b0800(2040) >> val=3Dffffffff @ 0xfffff8003e0b0808 >> apanic: Most recently used by CAM CCB >> >> cpuid =3D 6 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfffffe124735b4c0 >> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe124735b570 >> vpanic() at vpanic+0x189/frame 0xfffffe124735b5f0 >> panic() at panic+0x43/frame 0xfffffe124735b650 >> mtrash_ctor() at mtrash_ctor+0x8a/frame 0xfffffe124735b680 >> uma_zalloc_arg() at uma_zalloc_arg+0x4f1/frame 0xfffffe124735b6f0 >> malloc() at malloc+0x192/frame 0xfffffe124735b740 >> xpt_run_allocq() at xpt_run_allocq+0xb5/frame 0xfffffe124735b780 >> adastrategy() at adastrategy+0x117/frame 0xfffffe124735b7b0 >> g_io_request() at g_io_request+0x3b7/frame 0xfffffe124735b810 >> g_part_start() at g_part_start+0x2b7/frame 0xfffffe124735b890 >> g_io_request() at g_io_request+0x3b7/frame 0xfffffe124735b8f0 >> g_io_request() at g_io_request+0x3b7/frame 0xfffffe124735b950 >> vdev_geom_io_start() at vdev_geom_io_start+0x137/frame 0xfffffe124735b= 970 >> zio_vdev_io_start() at zio_vdev_io_start+0x49f/frame 0xfffffe124735b9d= 0 >> zio_execute() at zio_execute+0x204/frame 0xfffffe124735ba30 >> vdev_queue_io_done() at vdev_queue_io_done+0x180/frame 0xfffffe124735b= a80 >> zio_vdev_io_done() at zio_vdev_io_done+0x11d/frame 0xfffffe124735bac0 >> zio_execute() at zio_execute+0x204/frame 0xfffffe124735bb20 >> taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame >> 0xfffffe124735bb80 >> taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame >> 0xfffffe124735bbb0 >> fork_exit() at fork_exit+0x84/frame 0xfffffe124735bbf0 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe124735bbf0 >> --- trap 0, rip =3D 0, rsp =3D 0xfffffe124735bcb0, rbp =3D 0 --- >> KDB: enter: panic >> [ thread pid 0 tid 100571 ] >> Stopped at kdb_enter+0x3e: movq $0,kdb_why >=20 >=20 I also had this one recently: > #8 0xffffffff80d1a162 in calltrap () at /usr/src/sys/amd64/amd64/excep= tion.S:231 > #9 0xffffffff802e52c4 in xpt_path_periph (path=3D0xdeadc0dedeadc0de) a= t /usr/src/sys/cam/cam_xpt.c:3738 > #10 0xffffffff802dfe62 in cam_periph_error (ccb=3D0xfffff8003e0b6000, c= amflags=3DCAM_FLAG_NONE, sense_flags=3D0, save_ccb=3D0x0) at /usr/src/sys= /cam/cam_periph.c:1602 > #11 0xffffffff803057e4 in adadone (periph=3D0xfffff8003e09b700, done_cc= b=3D0xfffff8003e0b6000) at /usr/src/sys/cam/ata/ata_da.c:1877 > #12 0xffffffff802e6e44 in xpt_done_process (ccb_h=3D0xfffff8003e0b6000)= at /usr/src/sys/cam/cam_xpt.c:5245 > #13 0xffffffff80394d59 in ahci_ch_intr_direct (arg=3D) at /usr/src/sys/dev/ahci/ahci.c:1132 > #14 0xffffffff80390ff1 in ahci_intr (data=3D) at /= usr/src/sys/dev/ahci/ahci.c:417 > #15 0xffffffff808ea5d3 in intr_event_execute_handlers (p=3D, ie=3D0xfffff8000f725d00) at /usr/src/sys/kern/kern_intr.c:1252= > #16 0xffffffff808eafb6 in ithread_loop (arg=3D0xfffff8000f6dea60) at /u= sr/src/sys/kern/kern_intr.c:1265 > #17 0xffffffff808e7fc4 in fork_exit (callout=3D0xffffffff808eaf10 , arg=3D0xfffff8000f6dea60, frame=3D0xfffffe1245083c00) at /usr/= src/sys/kern/kern_fork.c:977 > #18 0xffffffff80d1a69e in fork_trampoline () at /usr/src/sys/amd64/amd6= 4/exception.S:605 --=20 Regards, Bryan Drewery --9rTkdCP9wLjnifF3vaaugJLCEVSIWbxbh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUGaskAAoJEDXXcbtuRpfP8rEIALSvsK3C9sp3CiO86LzXeYqt VWOwKrr623H9KJb3K0XtEwSy5SpTxpWRrXX4pttjU8BN5tD6jyM7zn9ECH6kU4dP cy9NVPRmL+zc/BXiqmLyZITOWZRs1sDGE6wQ2lS94abXmzY9BDMUqgNuOajbq1ZO WJUR65Nrq2Xb93XW10qa6CDLcCbV2p83ii/CoaxDcMxSo/n47pAnfpclXZGlWviW xDyfBS+iixsX10W28vz89Yq5Y1m86GZgVjO1B+QTb8IR0wxfyimKFBw+df0FRDmb MBscfsNTw0szkWG+dVuuuQlkTi2+K0catomtt2VG2DijUqoPZGcESUrhpCrYMBs= =xJBr -----END PGP SIGNATURE----- --9rTkdCP9wLjnifF3vaaugJLCEVSIWbxbh-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 17:27:54 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BEF81AE; Wed, 17 Sep 2014 17:27:54 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A63FCC5E; Wed, 17 Sep 2014 17:27:53 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id q58so1808179wes.7 for ; Wed, 17 Sep 2014 10:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=CqkJj04bKoVkqwNWE/3LPFsCq/iSjXSMkcLUraTOhlY=; b=uK154Uu4VorKdEC2Ewh4+/e97L0+yq3wJFnmXpoEltE6aI/VDQUKCmJajAy7hADKZn EtvxT05XNMMrszslqYZzlpvMWxv7HGWPvRSwNgN3sZaLXYL81o0wsueUxyqcGd+EyUXk owjGsXdNDpeswTR4oshyhwpwZMKoMQDRUXN73POKvbLhFkP4APQ8JiWHGn8xpICBtIRD 05a8SIrBPUMgxFdD0lvackzyxT+HVezXx9s5BeDMx4+BzpGC+j1GLKKhJw0lTnDBa7xK ozMDfBYIylNnA1EiBKAGYGnXxdEnX8aA4TuN0pBvDhD4Kv2oOwD/ZEYGVE5OqYWWDgS3 QGdw== MIME-Version: 1.0 X-Received: by 10.180.107.100 with SMTP id hb4mr6868225wib.59.1410974871879; Wed, 17 Sep 2014 10:27:51 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.199 with HTTP; Wed, 17 Sep 2014 10:27:51 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Sep 2014 10:27:51 -0700 X-Google-Sender-Auth: FjTR5MgoHUE-TJW01cfMvbtYY3Y Message-ID: Subject: Re: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD From: Adrian Chadd To: Stefano Garzarella Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , George Neville-Neil , freebsd-current , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 17:27:54 -0000 Hi! Cool! How many flows were you testing with? Just one or two? It's for outbound, so it's not _as_ big a deal as it is for inbound, but it'd still be nice to know. -a On 17 September 2014 01:27, Stefano Garzarella wrote: > Hi all, > I have recently worked, during my master=E2=80=99s thesis with the superv= ision > of Prof. Luigi Rizzo, on a project to add GSO (Generic Segmentation > Offload) support in FreeBSD. I will present this project at EuroBSDcon > 2014, in Sofia (Bulgaria) on September 28, 2014. > > Following is a brief description of our project: > > The use of large frames makes network communication much less > demanding for the CPU. Yet, backward compatibility and slow links > requires the use of 1500 byte or smaller frames. Modern NICs with > hardware TCP segmentation offloading (TSO) address this problem. > However, a generic software version (GSO) provided by the OS has > reason to exist, for use on paths with no suitable hardware, such > as between virtual machines or with older or buggy NICs. > > Much of the advantage of TSO comes from crossing the network stack only > once per (large) segment instead of once per 1500-byte frame. > GSO does the same both for segmentation (TCP) and fragmentation (UDP) > by doing these operations as late as possible. Ideally, this could be don= e > within the device driver, but that would require modifications to all > drivers. > A more convenient, similarly effective approach is to segment > just before the packet is passed to the driver (in ether_output()). > > Our preliminary implementation supports TCP and UDP on IPv4/IPv6; > it only intercepts packets large than the MTU (others are left unchanged)= , > and only when GSO is marked as enabled for the interface. > > Segments larger than the MTU are not split in tcp_output(), > udp_output(), or ip_output(), but marked with a flag (contained in > m_pkthdr.csum_flags), which is processed by ether_output() just > before calling the device driver. > > ether_output(), through gso_dispatch(), splits the large frame as needed, > creating headers and possibly doing checksums if not supported by > the hardware. > > In experiments agains an LRO-enabled receiver (otherwise TSO/GSO > are ineffective) we have seen the following performance, > taken at different clock speeds (because at top speeds the > 10G link becomes the bottleneck): > > > Testing enviroment (all with Intel 10Gbit NIC) > Sender: FreeBSD 11-CURRENT - CPU i7-870 at 2.93 GHz + Turboboost > Receiver: Linux 3.12.8 - CPU i7-3770K at 3.50GHz + Turboboost > Benchmark tool: netperf 2.6.0 > > --- TCP/IPv4 packets (checksum offloading enabled) --- > Freq. TSO GSO none Speedup > [GHz] [Gbps] [Gbps] [Gbps] GSO-none > 2.93 9347 9298 8308 12 % > 2.53 9266 9401 6771 39 % > 2.00 9408 9294 5499 69 % > 1.46 9408 8087 4075 98 % > 1.05 9408 5673 2884 97 % > 0.45 6760 2206 1244 77 % > > > --- TCP/IPv6 packets (checksum offloading enabled) --- > Freq. TSO GSO none Speedup > [GHz] [Gbps] [Gbps] [Gbps] GSO-none > 2.93 7530 6939 4966 40 % > 2.53 5133 7145 4008 78 % > 2.00 5965 6331 3152 101 % > 1.46 5565 5180 2348 121 % > 1.05 8501 3607 1732 108 % > 0.45 3665 1505 651 131 % > > > --- UDP/IPv4 packets (9K) --- > Freq. GSO none Speedup > [GHz] [Gbps] [Gbps] GSO-none > 2.93 9440 8084 17 % > 2.53 7772 6649 17 % > 2.00 6336 5338 19 % > 1.46 4748 4014 18 % > 1.05 3359 2831 19 % > 0.45 1312 1120 17 % > > > --- UDP/IPv6 packets (9K) --- > Freq. GSO none Speedup > [GHz] [Gbps] [Gbps] GSO-none > 2.93 7281 6197 18 % > 2.53 5953 5020 19 % > 2.00 4804 4048 19 % > 1.46 3582 3004 19 % > 1.05 2512 2092 20 % > 0.45 998 826 21 % > > We tried to change as little as possible the network stack to add > GSO support. To avoid changing API/ABI, we temporarily used spare > fields in struct tcpcb (TCP Control Block) and struct ifnet to store > some information related to GSO (enabled, max burst size, etc.). > The code that performs the segmentation/fragmentation is contained > in the file gso.[h|c] in sys/net. We used 4 bit in m_pkthdr.csum_flags > (CSUM_GSO_MASK) to encode the packet type (TCP/IPv4, TCP/IPv6, etc) > to prevent access to the TCP/IP/Ethernet headers of each packet. > In ether_output_frame(), if the packet requires the GSO > ((m->m_pkthdr.csum_flags & CSUM_GSO_MASK) !=3D 0), it is segmented > or fragmented, and then they are sent to the device driver. > > At https://github.com/stefano-garzarella/freebsd-gso > you can find the kernel patches for FreeBSD-current, FreeBSD > 10-stable, FreeBSD 9-stable, a simple application (gso-stats.c) > that prints the GSO statistics and picobsd images with GSO support. > > At https://github.com/stefano-garzarella/freebsd-gso-src > you can get the FreeBSD source with GSO patch (various branch for > FreeBSD current, 10-stable, 9-stable). > > Any feedbacks, comments, questions are welcome. > > Thank you very much, > Stefano Garzarella > > -------------------------------------------------------------------------= ----------------------------------- > How to use GSO: > > - Apply the right kernel patch. > > - To compile the GSO support add =E2=80=98 options GSO ' to your kernel c= onfig file > and > rebuild a kernel. > > - To manage the GSO parameters there are some sysctls: > - net.inet.tcp.gso - GSO enable on TCP communications (!=3D0) > - net.inet.udp.gso - GSO enable on UDP communications (!=3D0) > > - for each interface: > - net.gso.dev."ifname=E2=80=9D.max_burst - GSO burst length lim= it > [default: IP_MAXPACKET=3D65535] > - net.gso.dev."ifname=E2=80=9D.enable_gso - GSO enable on =E2= =80=9Cifname=E2=80=9D > interface (!=3D0) > > - To show statistics: > - make sure that the GSO_STATS macro is defined in sys/net/gso.h > - use the simple gso-stats.c application to access the sysctl > net.gso.stats > that contains the address of the gsostats structure (defined in > gso.h) > which records the statistics. (compile with > -I/path/to/kernel/src/patched/) > -------------------------------------------------------------------------= ----------------------------------- > > -- > *Stefano Garzarella* > stefano.garzarella@gmail.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 18:18:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1E11A70; Wed, 17 Sep 2014 18:18:45 +0000 (UTC) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5BA4D2E3; Wed, 17 Sep 2014 18:18:45 +0000 (UTC) Received: by mail-qg0-f51.google.com with SMTP id e89so2475738qgf.24 for ; Wed, 17 Sep 2014 11:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tW86HSWxNkMFHRlYJxWkTNooCln+St7+VoNWM8Difu0=; b=nKxisU3PEeTUB01C1+BtJ9upkKS+cNHMVpdKpAkNIRoyAxL2zMWWyOppfb9rlyNsC8 pEmqzhCijGfMbdKVbUI5B3G1uJ9C2b7nDvMci/SREh+IeIP5fUE36TrZJcyGIJkzxAhR Q7QW+fL+WApAUWivnqJIQCBAG4KhICceH/Xr9x1A1sKIq6a/+BTvYW6gA8H61WhiMS6p qk2+JO3Gv0MCjNpLHekw4E/ojGKqduZKFIaw7FZ6iRh02qDLXpHyeFH4Bjdoliq3/h4l fdyVH6g0z2R1TPKy4oAJk3DOCDtHhkKL64dc3RQ/kFDaZAaTGv74OzFfx261blKjZAXM /R0g== MIME-Version: 1.0 X-Received: by 10.224.86.5 with SMTP id q5mr60394777qal.36.1410977924449; Wed, 17 Sep 2014 11:18:44 -0700 (PDT) Received: by 10.140.104.241 with HTTP; Wed, 17 Sep 2014 11:18:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Sep 2014 20:18:44 +0200 Message-ID: Subject: Re: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD From: Stefano Garzarella To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , George Neville-Neil , freebsd-current , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 18:18:45 -0000 Hi Adrian, the results that I sent, regard just one flow, but I can try with two simultaneous flows and I'll send you the results. Thanks, Stefano 2014-09-17 19:27 GMT+02:00 Adrian Chadd : > Hi! > > Cool! > > How many flows were you testing with? Just one or two? > > It's for outbound, so it's not _as_ big a deal as it is for inbound, > but it'd still be nice to know. > > > -a > > > On 17 September 2014 01:27, Stefano Garzarella > wrote: > > Hi all, > > I have recently worked, during my master=E2=80=99s thesis with the supe= rvision > > of Prof. Luigi Rizzo, on a project to add GSO (Generic Segmentation > > Offload) support in FreeBSD. I will present this project at EuroBSDcon > > 2014, in Sofia (Bulgaria) on September 28, 2014. > > > > Following is a brief description of our project: > > > > The use of large frames makes network communication much less > > demanding for the CPU. Yet, backward compatibility and slow links > > requires the use of 1500 byte or smaller frames. Modern NICs with > > hardware TCP segmentation offloading (TSO) address this problem. > > However, a generic software version (GSO) provided by the OS has > > reason to exist, for use on paths with no suitable hardware, such > > as between virtual machines or with older or buggy NICs. > > > > Much of the advantage of TSO comes from crossing the network stack only > > once per (large) segment instead of once per 1500-byte frame. > > GSO does the same both for segmentation (TCP) and fragmentation (UDP) > > by doing these operations as late as possible. Ideally, this could be > done > > within the device driver, but that would require modifications to all > > drivers. > > A more convenient, similarly effective approach is to segment > > just before the packet is passed to the driver (in ether_output()). > > > > Our preliminary implementation supports TCP and UDP on IPv4/IPv6; > > it only intercepts packets large than the MTU (others are left > unchanged), > > and only when GSO is marked as enabled for the interface. > > > > Segments larger than the MTU are not split in tcp_output(), > > udp_output(), or ip_output(), but marked with a flag (contained in > > m_pkthdr.csum_flags), which is processed by ether_output() just > > before calling the device driver. > > > > ether_output(), through gso_dispatch(), splits the large frame as neede= d, > > creating headers and possibly doing checksums if not supported by > > the hardware. > > > > In experiments agains an LRO-enabled receiver (otherwise TSO/GSO > > are ineffective) we have seen the following performance, > > taken at different clock speeds (because at top speeds the > > 10G link becomes the bottleneck): > > > > > > Testing enviroment (all with Intel 10Gbit NIC) > > Sender: FreeBSD 11-CURRENT - CPU i7-870 at 2.93 GHz + Turboboost > > Receiver: Linux 3.12.8 - CPU i7-3770K at 3.50GHz + Turboboost > > Benchmark tool: netperf 2.6.0 > > > > --- TCP/IPv4 packets (checksum offloading enabled) --- > > Freq. TSO GSO none Speedup > > [GHz] [Gbps] [Gbps] [Gbps] GSO-none > > 2.93 9347 9298 8308 12 % > > 2.53 9266 9401 6771 39 % > > 2.00 9408 9294 5499 69 % > > 1.46 9408 8087 4075 98 % > > 1.05 9408 5673 2884 97 % > > 0.45 6760 2206 1244 77 % > > > > > > --- TCP/IPv6 packets (checksum offloading enabled) --- > > Freq. TSO GSO none Speedup > > [GHz] [Gbps] [Gbps] [Gbps] GSO-none > > 2.93 7530 6939 4966 40 % > > 2.53 5133 7145 4008 78 % > > 2.00 5965 6331 3152 101 % > > 1.46 5565 5180 2348 121 % > > 1.05 8501 3607 1732 108 % > > 0.45 3665 1505 651 131 % > > > > > > --- UDP/IPv4 packets (9K) --- > > Freq. GSO none Speedup > > [GHz] [Gbps] [Gbps] GSO-none > > 2.93 9440 8084 17 % > > 2.53 7772 6649 17 % > > 2.00 6336 5338 19 % > > 1.46 4748 4014 18 % > > 1.05 3359 2831 19 % > > 0.45 1312 1120 17 % > > > > > > --- UDP/IPv6 packets (9K) --- > > Freq. GSO none Speedup > > [GHz] [Gbps] [Gbps] GSO-none > > 2.93 7281 6197 18 % > > 2.53 5953 5020 19 % > > 2.00 4804 4048 19 % > > 1.46 3582 3004 19 % > > 1.05 2512 2092 20 % > > 0.45 998 826 21 % > > > > We tried to change as little as possible the network stack to add > > GSO support. To avoid changing API/ABI, we temporarily used spare > > fields in struct tcpcb (TCP Control Block) and struct ifnet to store > > some information related to GSO (enabled, max burst size, etc.). > > The code that performs the segmentation/fragmentation is contained > > in the file gso.[h|c] in sys/net. We used 4 bit in m_pkthdr.csum_flags > > (CSUM_GSO_MASK) to encode the packet type (TCP/IPv4, TCP/IPv6, etc) > > to prevent access to the TCP/IP/Ethernet headers of each packet. > > In ether_output_frame(), if the packet requires the GSO > > ((m->m_pkthdr.csum_flags & CSUM_GSO_MASK) !=3D 0), it is segmented > > or fragmented, and then they are sent to the device driver. > > > > At https://github.com/stefano-garzarella/freebsd-gso > > you can find the kernel patches for FreeBSD-current, FreeBSD > > 10-stable, FreeBSD 9-stable, a simple application (gso-stats.c) > > that prints the GSO statistics and picobsd images with GSO support. > > > > At https://github.com/stefano-garzarella/freebsd-gso-src > > you can get the FreeBSD source with GSO patch (various branch for > > FreeBSD current, 10-stable, 9-stable). > > > > Any feedbacks, comments, questions are welcome. > > > > Thank you very much, > > Stefano Garzarella > > > > > -------------------------------------------------------------------------= ----------------------------------- > > How to use GSO: > > > > - Apply the right kernel patch. > > > > - To compile the GSO support add =E2=80=98 options GSO ' to your kernel= config > file > > and > > rebuild a kernel. > > > > - To manage the GSO parameters there are some sysctls: > > - net.inet.tcp.gso - GSO enable on TCP communications (!=3D0) > > - net.inet.udp.gso - GSO enable on UDP communications (!=3D0) > > > > - for each interface: > > - net.gso.dev."ifname=E2=80=9D.max_burst - GSO burst length l= imit > > [default: IP_MAXPACKET=3D65535] > > - net.gso.dev."ifname=E2=80=9D.enable_gso - GSO enable on =E2= =80=9Cifname=E2=80=9D > > interface (!=3D0) > > > > - To show statistics: > > - make sure that the GSO_STATS macro is defined in sys/net/gso.h > > - use the simple gso-stats.c application to access the sysctl > > net.gso.stats > > that contains the address of the gsostats structure (defined in > > gso.h) > > which records the statistics. (compile with > > -I/path/to/kernel/src/patched/) > > > -------------------------------------------------------------------------= ----------------------------------- > > > > -- > > *Stefano Garzarella* > > stefano.garzarella@gmail.com > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > --=20 *Stefano Garzarella* stefano.garzarella@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 19:03:45 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E8A81BD; Wed, 17 Sep 2014 19:03:45 +0000 (UTC) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C278EA24; Wed, 17 Sep 2014 19:03:44 +0000 (UTC) Received: by mail-lb0-f173.google.com with SMTP id w7so2451967lbi.32 for ; Wed, 17 Sep 2014 12:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p6LDmmmVFM8K7xSWchQtW3CyfXijc2aeQbj1FqHjWpw=; b=GdEZgJumQLE4eUXAFuF4xGGF4Q4+izqzkSG9UPLQv/sLIxVymMDgL0ms/+BcxGyhgF 5UclXkBrPL81agyrazCb1uTX+9Nuv6L0V3LkecvBwAuLH/Ji0B8X9cJ6v+8tuSO+wRcv 8nfilSrEp50O7bWvIqmOHOyo37c89UiOjxocP29bCwMP4Wmk16SePolipJ19WfAgv4Wh 49rv+hnvCfVjBsMQVU31DA84NGDW/Jk1puFmln3PYMBAQa1kkyQzkKG9+NCAa7yobFc5 IprUz1I/RKiQsd9ZWfGBqyxOw8Cy3YuovOBDFSnMIYsVp5yWG49oaa6815alCYA6kE9x aPoQ== MIME-Version: 1.0 X-Received: by 10.152.163.66 with SMTP id yg2mr31252989lab.38.1410980620685; Wed, 17 Sep 2014 12:03:40 -0700 (PDT) Received: by 10.25.21.166 with HTTP; Wed, 17 Sep 2014 12:03:40 -0700 (PDT) In-Reply-To: <5419AB24.9050809@FreeBSD.org> References: <5418F1B9.2000903@FreeBSD.org> <5419AB24.9050809@FreeBSD.org> Date: Wed, 17 Sep 2014 15:03:40 -0400 Message-ID: Subject: Re: Cam panic on r271170 From: Ryan Stone To: Bryan Drewery Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 19:03:45 -0000 Could you try turning on memguard for the CAM CCB malloc area? That should locate the problem quite quickly. From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 20:27:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0812D2; Wed, 17 Sep 2014 20:27:15 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9F255344; Wed, 17 Sep 2014 20:27:15 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 8B43F24800B; Wed, 17 Sep 2014 22:27:12 +0200 (CEST) Message-ID: <5419EE95.40600@selasky.org> Date: Wed, 17 Sep 2014 22:27:01 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Stefano Garzarella , Adrian Chadd Subject: Re: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , George Neville-Neil , freebsd-current , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 20:27:16 -0000 On 09/17/14 20:18, Stefano Garzarella wrote: > Hi Adrian, > the results that I sent, regard just one flow, but I can try with two > simultaneous flows and I'll send you the results. > > Thanks, > Stefano > Hi Stefano, You might have seen the discussion about TSO. Is it so that the proposed GSO feature only looks at the "ifp->if_hw_tsomax" field, and ignores hardware limits regarding maximum segment size and maximum segment count? --HPS From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 20:45:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0DFEA48; Wed, 17 Sep 2014 20:45:26 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [192.203.228.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp2.wemm.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C20067D2; Wed, 17 Sep 2014 20:45:26 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 6029FE0C; Wed, 17 Sep 2014 13:45:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1410986726; bh=fqSHcHdrt5jVuyjlMB7AdQzAA+/MVJwo90D1aTwLmCQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=mXwKuU9x1NoxQBQuNBMw9zF7zQcvV0gzQH8qGcNUXDD3FjBApNeRiiEOW8hWo2skx Dl99Z/gpqLvxwNVFsvZaXjPtuf0oc2tHj6LL7JWEaWmRNvWMJ+NaUe+CpDvjzIwKCq 6EF/0Mwf7xX3W1rIPKoV87FwM4mq2MP0bYeiZpsQ= From: Peter Wemm To: freebsd-current@freebsd.org Subject: Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient Date: Wed, 17 Sep 2014 13:45:25 -0700 Message-ID: <52259934.QGKubh7NGh@overcee.wemm.org> User-Agent: KMail/4.12.5 (FreeBSD/11.0-CURRENT; KDE/4.12.5; amd64; ; ) In-Reply-To: <20140916104236.GA21560@dft-labs.eu> References: <4252906.DAHIEnKpIF@overcee.wemm.org> <20140916104236.GA21560@dft-labs.eu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9799685.Ygpvd2xJnP"; micalg="pgp-sha1"; protocol="application/pgp-signature" Cc: Patrick Kelsey , George Neville-Neil , Mateusz Guzik X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 20:45:27 -0000 --nextPart9799685.Ygpvd2xJnP Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Tuesday, September 16, 2014 12:42:36 PM Mateusz Guzik wrote: > On Fri, Sep 12, 2014 at 09:29:56PM -0700, Peter Wemm wrote: > > On Thursday, September 11, 2014 12:38:02 PM Patrick Kelsey wrote: > > > On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov =20 wrote: > > > > On 09.09.2014 21:53, Patrick Kelsey wrote: > > > > > I don't think it is worth the trouble, as given the larger pa= ttern > > > > > of > > > > > libc routines requiring multiple capsicum rights, it seems on= e will > > > > > in > > > > > general have to have libc implementation knowledge when using= it in > > > > > concert with capsicum. For example, consider the limitfd() r= outine > > > > > in > > > > > kdump.c, which provides rights for the TIOCGETA ioctl to be u= sed on > > > > > stdout so the eventual call to isatty() via printf() will wor= k as > > > >=20 > > > > intended. > > > >=20 > > > > > I think the above kdump example is a good one for the subtle = issues > > > > > that > > > > > can arise when using capsicum with libc. That call to isatty= () is > > > > > via a > > > > > widely-used internal libc routine __smakebuf(). __smakebuf()= also > > > > > calls > > > > > __swhatbuf(), which in turn calls _fstat(), all to make sure = that > > > > > output > > > > > to a tty is line buffered by default. It would appear that p= rograms > > > > > that restrict rights on stdout without allowing CAP_IOCTL and= > > > > > CAP_FSTAT > > > > > could be disabling the normally default line buffering when s= tdout > > > > > is a > > > > > tty. kdump goes the distance, but dhclient does not (restric= ting > > > > > stdout > > > > > to CAP_WRITE only). > > > > >=20 > > > > > In any event, the patch attached to my first message is seemi= ng like > > > > > the > > > > > way to go. > > > >=20 > > > > Well, then commit it (if capsicum team agrees). > > >=20 > > > Will do - thanks for the feedback. > > >=20 > > > -Patrick > >=20 > > Is there any possibility that this is related to the problem we've > > recently > > hit in the freebsd.org cluster with this month's refresh? > >=20 > > After running for a while: > > Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 0: valid= ator > > Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 1: itera= tor > > Sep 10 11:44:29 ns2 unbound: [65258:3] fatal error: event_dispatch > > returned > > error -1, errno is Capabilities insufficient > >=20 > > Sep 10 16:21:16 ns2 unbound: [28212:0] warning: did not exit gracef= ully > > last time (65258) > > Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 0: valid= ator > > Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 1: itera= tor > > Sep 11 10:23:49 ns2 unbound: [28213:5] fatal error: event_dispatch > > returned > > error -1, errno is Capabilities insufficient > >=20 > > Sep 11 13:48:46 ns2 unbound: [79419:0] warning: did not exit gracef= ully > > last time (28213) > > Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 0: valid= ator > > Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 1: itera= tor > > Sep 11 18:42:56 ns2 unbound: [79420:6] fatal error: event_dispatch > > returned > > error -1, errno is Capabilities insufficient > >=20 > > I believe this jail was started from the boot process. If I restart= the > > jail by hand from a ssh session the problem goes away. > >=20 > > This is unbound from ports and I don't have any more details than t= his.=20 > > This is new this month. >=20 > Is this thingy multithreaded? >=20 > Currently there is a race in the kernel where fd is visible before > relevant capabilities are installed. This can result in an error like= > this one for weird processes. >=20 > I got a patch for this: > http://lists.freebsd.org/pipermail/freebsd-arch/2014-August/015788.ht= ml >=20 > but it got stalled on 'memory barrier' discussion. I'll try to ping > people to move it forward. >=20 > IIRC there was a report of unbound failing this way, apparently fixed= > with aforementioned patch. Yes, unbound is multi-threaded and your comment is the first potential=20= explanation that makes sense so far. =2D-=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI= 6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 --nextPart9799685.Ygpvd2xJnP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABAgAGBQJUGfLmAAoJEDXWlwnsgJ4ENUIIAML+6cjn5sDZS/6pgu/Jfo/J c9TRcTPuBhOsG/XhsF2IklOt8NmwUYIMHm6NhzQEjTbdvzaAGlBB4EON+Hw+q0Wt FnhXArUIPhDKOhWIiLKW9Z/lC+qaJFzH1sbKs41demCeaNdtwTiIXZjkLMfeXn10 3UwHldzeWTRrt+P9oy7YIJl0sMUdwPdIgrkpysuf+e3X3YHeZEhZYb7UBHE9O0YT vAxvv+m5i5Zlz5S22JRd+q1hZYvfuHfFK6DNtHldKhtCgqdbY78AnOiEw83ZTZLa uKMqTdE9Zqliipkci8c3Rg/YjmsC6lIlmjMeJNI296R4myhddcja7nb3Q7aQWW0= =Q1vR -----END PGP SIGNATURE----- --nextPart9799685.Ygpvd2xJnP-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 01:30:28 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C61ED8DC; Thu, 18 Sep 2014 01:30:28 +0000 (UTC) Received: from kx.openedu.org (96.247.3.110.ap.yournet.ne.jp [110.3.247.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F1BD38F; Thu, 18 Sep 2014 01:30:27 +0000 (UTC) Received: from kiri.pis.kx.openedu.org (kiri.pis [192.168.1.1] (may be forged)) by kx.openedu.org (8.14.5/8.14.5) with ESMTP id s8I10J1c041678; Thu, 18 Sep 2014 10:00:19 +0900 (JST) (envelope-from kiri@kx.openedu.org) Message-Id: <201409180100.s8I10J1c041678@kx.openedu.org> Date: Thu, 18 Sep 2014 10:00:19 +0900 From: KIRIYAMA Kazuhiko To: Eitan Adler Subject: Re: Leaving the Desktop Market In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.6 MULE XEmacs/21.4 (patch 22) (Instant Classic) (amd64--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Cc: freebsd-advocacy@freebsd.org, hackers@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 01:30:29 -0000 Dear lists, I'm sorry for 2L8 reply though,I have transrated this thread into japanese in [1]. I wonder if every mail transrated correctly so please check it if you understand japanese especially by japanese lists. BTW ML mails should be obeyed by FreeBSD Copyright but it's derivative work would be going to?=20 Regards [1] http://www.openedu.org/dkp/archive/mail/current/20140331-0517/maillist.= html --- Kazuhiko Kiriyama kiri@openedu.org At Mon, 31 Mar 2014 22:46:45 -0700, Eitan Adler wrote: >=20 > Hi all, >=20 > Some of you may have seen my posts entitled "Story of a Laptop User" > and "Story of a Desktop User". For those of you who did not, it can > be a worthwhile read to see what life is like when using FreeBSD as a > desktop. In short, it is an educational experience. While FreeBSD > can be coerced to do the right thing, it is rarely there by default > and often doesn't work as well as we would expect. >=20 > The following are issues I haven't brought up in the past: >=20 > Battery life sucks: it=A2s almost as if powerd wasn't running. Windows > can run for five hours on my laptop while FreeBSD can barely make it > two hours. I wonder what the key differences are? Likely it=A2s that > we focus so much on performance that no one considers power. ChromeOS > can run for 12 hours on some hardware; why can't we make FreeBSD run > for 16? >=20 > Sound configuration lacks key documentation: how can I automatically > change between headphones and external speakers? You can't even do > that in middle of a song at all! Trust me that you never want to be > staring at an HDA pin configuration. I'll bet you couldn't even get > sound streaming to other machines working if you tried. >=20 > FreeBSD lacks vendor credibility: CUDA is unsupported. Dropbox hasn't > released a client for FreeBSD. Nvidia Optimus doesn't function on > FreeBSD. Can you imagine telling someone to purchase a laptop with > the caveat: "but you won't be able to use your graphics card"? >=20 > In any case, half of our desktop support is emulation: flash and opera > only works because of the linuxulator. There really isn't any reason > for vendors to bother supporting FreeBSD if we are just going to ape > Linux anyways. >=20 > That is why on this date I propose that we cease competing on the > desktop market. FreeBSD should declare 2014 to be "year of the Linux > desktop" and start to rip out the pieces of the OS not needed for > server or embedded use. >=20 > Some of you may point to PCBSD and say that we have a chance, but I > must ask you: how does one flavor stand up to the thousands in the > Linux world? >=20 > Eitan Adler > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 07:59:35 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DFCC111A; Thu, 18 Sep 2014 07:59:34 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 692A2BF7; Thu, 18 Sep 2014 07:59:34 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XUWcg-002tfb-E3>; Thu, 18 Sep 2014 09:59:26 +0200 Received: from [141.89.176.137] (helo=hermann.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XUWcg-001v1C-Bf>; Thu, 18 Sep 2014 09:59:26 +0200 Date: Thu, 18 Sep 2014 09:58:51 +0200 From: "O. Hartmann" To: Adrian Chadd Subject: Re: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI Message-ID: <20140918095851.6e743183.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20140915233833.5bdd0725.ohartman@zedat.fu-berlin.de> <20140916131854.46acc5fb.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/i6_ltTCC7X_25xxFW8TX27N"; protocol="application/pgp-signature" X-Originating-IP: 141.89.176.137 X-ZEDAT-Hint: A Cc: Kevin Oberman , FreeBSD CURRENT , FreeBSD Questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 07:59:35 -0000 --Sig_/i6_ltTCC7X_25xxFW8TX27N Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tue, 16 Sep 2014 08:40:25 -0700 Adrian Chadd schrieb: > Ah, jumbo frames. Maybe you got lucky and some ethernet drivers > default to accepting larger frames even if the MTU is 1500. >=20 >=20 > -a After all, I managed to get the NIC up and running. But the culprit is that= I have to take the NIC down and then up to make it working once the system has bootet= . That is annoying. Lucckily, I can provide better informations since the box s now a= ttached to the network. Here we go: LAN: re0@pci0:4:0:0: class=3D0x020000 card=3D0x502817aa chip=3D0x816810ec rev=3D= 0x10 hdr=3D0x00 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class =3D network subclass =3D ethernet bar [10] =3D type I/O Port, range 32, base 0x3000, size 256, enabled bar [18] =3D type Memory, range 64, base 0xf1d04000, size 4096, enabl= ed bar [20] =3D type Memory, range 64, base 0xf1d00000, size 16384, enab= led cap 01[40] =3D powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] =3D MSI supports 1 message, 64 bit=20 cap 10[70] =3D PCI-Express 2 endpoint IRQ 1 max data 128(128) link x1(x= 1) speed 2.5(2.5) ASPM disabled(L0s/L1) cap 11[b0] =3D MSI-X supports 4 messages, enabled Table in map 0x20[0x0], PBA in map 0x20[0x800] cap 03[d0] =3D VPD ecap 0001[100] =3D AER 2 0 fatal 0 non-fatal 1 corrected ecap 0002[140] =3D VC 1 max VC0 ecap 0003[160] =3D Serial 1 01000000684ce000 ecap 0018[170] =3D LTR 1 ecap 001e[178] =3D unknown 1 PCI-e errors =3D Correctable Error Detected Corrected =3D Receiver Error WiFi (supposed to be Intel ): none2@pci0:5:0:0: class=3D0x028000 card=3D0x42628086 chip=3D0x08b2808= 6 rev=3D0x73 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D network bar [10] =3D type Memory, range 64, base 0xf1c00000, size 8192, enabl= ed cap 01[c8] =3D powerspec 3 supports D0 D3 current D0 cap 05[d0] =3D MSI supports 1 message, 64 bit=20 cap 10[40] =3D PCI-Express 2 endpoint max data 128(128) FLR link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) ecap 0001[100] =3D AER 1 0 fatal 0 non-fatal 0 corrected ecap 0003[140] =3D Serial 1 ac7ba1ffffa06fd6 ecap 0018[14c] =3D LTR 1 ecap 000b[154] =3D Vendor 1 ID 51966 The WiFi NIC isn't recognized by any driver in CURRENT (11.0-CURRENT #5 r27= 1728: Thu Sep 18 01:18:25 CEST 2014 amd64) Maybe this is of help. Oliver --Sig_/i6_ltTCC7X_25xxFW8TX27N Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUGpDAAAoJEOgBcD7A/5N8zOQIAMo1pjBg61+Jo8LvYdJMyKrA 4l7D44TYT6SDWLDf9t+MkOqx9ZUu1W5Wth8oJucVykZU03t5ovIE+I327ulnJLEr H+5cwclRXMZWkOq4zpkxOLiyu77y2x1MjdDtKVts4FLhFruT1XJIRgPSYUFFg3v2 XlNUTn/eQ0osbYPm5Ou2F8oziA43qn9cMrLXZX+zBD1sexnj0tqMiBMa/79CX1DQ NlYP7zpxsIlBfP2CudzJUCDEcTugdLRY8vtAYtkNtvhUnMRKIYF4ZSPt5Ke6BGY4 WF9drnd/P+WA3yAtI09v0UXoDGii9stSKZrnG3JzHeAZiUoJwqLyNTmzkW9XPSk= =Gy5u -----END PGP SIGNATURE----- --Sig_/i6_ltTCC7X_25xxFW8TX27N-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 08:17:16 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FE9B7E9; Thu, 18 Sep 2014 08:17:16 +0000 (UTC) Received: from winston.madpilot.net (winston.madpilot.net [78.47.75.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 28CA2DAF; Thu, 18 Sep 2014 08:17:15 +0000 (UTC) Received: from winston.madpilot.net (localhost [127.0.0.1]) by winston.madpilot.net (Postfix) with ESMTP id 3hz9yL25NwzFfCw; Thu, 18 Sep 2014 10:17:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:mime-version:user-agent:from:from :date:date:message-id:received:received; s=mail; t=1411028228; x=1412842629; bh=nKFC8ijVKEtu5LISexfeXu+oQosJtQe16asLi3W8JaY=; b= gtzCNT6WcpGX6VZpg35s7LPRg+yFvvh0HXip7EuK0Qo0KAJrHHjYA/7B2YDUYBks 5NmyGOZb76twKWkwgLohCnDT3EsmMQ/LutwIjvsA0PcrDsVWEs3SJcmPeQw7/v9T /ejDHqyD97z0dNwu3KDEEM6Hl/503w+Rp69anmmFVgI= Received: from winston.madpilot.net ([127.0.0.1]) by winston.madpilot.net (winston.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAUhL4yPWyLh; Thu, 18 Sep 2014 10:17:08 +0200 (CEST) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by winston.madpilot.net (Postfix) with ESMTPSA; Thu, 18 Sep 2014 10:17:08 +0200 (CEST) Message-ID: <541A9504.1010502@madpilot.net> Date: Thu, 18 Sep 2014 10:17:08 +0200 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: "O. Hartmann" , Adrian Chadd Subject: Re: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI References: <20140915233833.5bdd0725.ohartman@zedat.fu-berlin.de> <20140916131854.46acc5fb.ohartman@zedat.fu-berlin.de> <20140918095851.6e743183.ohartman@zedat.fu-berlin.de> In-Reply-To: <20140918095851.6e743183.ohartman@zedat.fu-berlin.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Kevin Oberman , FreeBSD CURRENT , FreeBSD Questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 08:17:16 -0000 On 09/18/14 09:58, O. Hartmann wrote: > Am Tue, 16 Sep 2014 08:40:25 -0700 > Adrian Chadd schrieb: > >> Ah, jumbo frames. Maybe you got lucky and some ethernet drivers >> default to accepting larger frames even if the MTU is 1500. >> >> >> -a > > > After all, I managed to get the NIC up and running. But the culprit is that I have to > take the NIC down and then up to make it working once the system has bootet. That is > annoying. Lucckily, I can provide better informations since the box s now attached to the > network. Here we go: > I have a similar situation with my nick on a tower system. I need to change at least one flag on the card to have it working, I can also just set the flag to the value it already has. I'm using a small startup script which actually does this: start_cmd="ifconfig ${refix_if} tso" > LAN: > re0@pci0:4:0:0: class=0x020000 card=0x502817aa chip=0x816810ec rev=0x10 hdr=0x00 > vendor = 'Realtek Semiconductor Co., Ltd.' > device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' > class = network > subclass = ethernet > bar [10] = type I/O Port, range 32, base 0x3000, size 256, enabled > bar [18] = type Memory, range 64, base 0xf1d04000, size 4096, enabled > bar [20] = type Memory, range 64, base 0xf1d00000, size 16384, enabled > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit > cap 10[70] = PCI-Express 2 endpoint IRQ 1 max data 128(128) link x1(x1) > speed 2.5(2.5) ASPM disabled(L0s/L1) > cap 11[b0] = MSI-X supports 4 messages, enabled > Table in map 0x20[0x0], PBA in map 0x20[0x800] > cap 03[d0] = VPD > ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected > ecap 0002[140] = VC 1 max VC0 > ecap 0003[160] = Serial 1 01000000684ce000 > ecap 0018[170] = LTR 1 > ecap 001e[178] = unknown 1 > PCI-e errors = Correctable Error Detected > Corrected = Receiver Error > re0@pci0:3:0:0: class=0x020000 card=0x11c01734 chip=0x816810ec rev=0x07 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0xd000, size 256, enabled bar [18] = type Prefetchable Memory, range 64, base 0xf2104000, size 4096, enabled bar [20] = type Prefetchable Memory, range 64, base 0xf2100000, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 2 endpoint IRQ 1 max data 128(128) link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) cap 11[b0] = MSI-X supports 4 messages, enabled Table in map 0x20[0x0], PBA in map 0x20[0x800] cap 03[d0] = VPD ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0002[140] = VC 1 max VC0 ecap 0003[160] = Serial 1 0100000004000001 PCI-e errors = Correctable Error Detected Unsupported Request Detected Corrected = Advisory Non-Fatal Error it's similar hardware, same chip, different revision. I already reported this on net@ but no patch could really solve the issue. -- Guido Falsi From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 08:49:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D13C35D; Thu, 18 Sep 2014 08:49:05 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C48BE123; Thu, 18 Sep 2014 08:49:04 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XUXOh-003Hgw-20>; Thu, 18 Sep 2014 10:49:03 +0200 Received: from [141.89.176.137] (helo=hermann.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XUXOh-0021lw-0m>; Thu, 18 Sep 2014 10:49:03 +0200 Date: Thu, 18 Sep 2014 10:48:33 +0200 From: "O. Hartmann" To: Guido Falsi Subject: Re: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI Message-ID: <20140918104833.3a473d7e.ohartman@zedat.fu-berlin.de> In-Reply-To: <541A9504.1010502@madpilot.net> References: <20140915233833.5bdd0725.ohartman@zedat.fu-berlin.de> <20140916131854.46acc5fb.ohartman@zedat.fu-berlin.de> <20140918095851.6e743183.ohartman@zedat.fu-berlin.de> <541A9504.1010502@madpilot.net> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/cMSIMgDXmMySkuIiJUqzZir"; protocol="application/pgp-signature" X-Originating-IP: 141.89.176.137 X-ZEDAT-Hint: A Cc: Kevin Oberman , Adrian Chadd , FreeBSD CURRENT , FreeBSD Questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 08:49:05 -0000 --Sig_/cMSIMgDXmMySkuIiJUqzZir Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Thu, 18 Sep 2014 10:17:08 +0200 Guido Falsi schrieb: > On 09/18/14 09:58, O. Hartmann wrote: > > Am Tue, 16 Sep 2014 08:40:25 -0700 > > Adrian Chadd schrieb: > >=20 > >> Ah, jumbo frames. Maybe you got lucky and some ethernet drivers > >> default to accepting larger frames even if the MTU is 1500. > >> > >> > >> -a > >=20 > >=20 > > After all, I managed to get the NIC up and running. But the culprit is = that I have to > > take the NIC down and then up to make it working once the system has bo= otet. That is > > annoying. Lucckily, I can provide better informations since the box s n= ow attached to > > the network. Here we go: > >=20 >=20 > I have a similar situation with my nick on a tower system. >=20 > I need to change at least one flag on the card to have it working, I can > also just set the flag to the value it already has. >=20 > I'm using a small startup script which actually does this: >=20 > start_cmd=3D"ifconfig ${refix_if} tso" >=20 >=20 > > LAN: > > re0@pci0:4:0:0: class=3D0x020000 card=3D0x502817aa chip=3D0x816810ec re= v=3D0x10 hdr=3D0x00 > > vendor =3D 'Realtek Semiconductor Co., Ltd.' > > device =3D 'RTL8111/8168B PCI Express Gigabit Ethernet controll= er' > > class =3D network > > subclass =3D ethernet > > bar [10] =3D type I/O Port, range 32, base 0x3000, size 256, enab= led > > bar [18] =3D type Memory, range 64, base 0xf1d04000, size 4096, e= nabled > > bar [20] =3D type Memory, range 64, base 0xf1d00000, size 16384, = enabled > > cap 01[40] =3D powerspec 3 supports D0 D1 D2 D3 current D0 > > cap 05[50] =3D MSI supports 1 message, 64 bit=20 > > cap 10[70] =3D PCI-Express 2 endpoint IRQ 1 max data 128(128) link = x1(x1) > > speed 2.5(2.5) ASPM disabled(L0s/L1) > > cap 11[b0] =3D MSI-X supports 4 messages, enabled > > Table in map 0x20[0x0], PBA in map 0x20[0x800] > > cap 03[d0] =3D VPD > > ecap 0001[100] =3D AER 2 0 fatal 0 non-fatal 1 corrected > > ecap 0002[140] =3D VC 1 max VC0 > > ecap 0003[160] =3D Serial 1 01000000684ce000 > > ecap 0018[170] =3D LTR 1 > > ecap 001e[178] =3D unknown 1 > > PCI-e errors =3D Correctable Error Detected > > Corrected =3D Receiver Error > > >=20 > re0@pci0:3:0:0: class=3D0x020000 card=3D0x11c01734 chip=3D0x816810ec rev= =3D0x07 > hdr=3D0x00 > vendor =3D 'Realtek Semiconductor Co., Ltd.' > device =3D 'RTL8111/8168B PCI Express Gigabit Ethernet controller' > class =3D network > subclass =3D ethernet > bar [10] =3D type I/O Port, range 32, base 0xd000, size 256, enabled > bar [18] =3D type Prefetchable Memory, range 64, base 0xf2104000, > size 4096, enabled > bar [20] =3D type Prefetchable Memory, range 64, base 0xf2100000, > size 16384, enabled > cap 01[40] =3D powerspec 3 supports D0 D1 D2 D3 current D0 > cap 05[50] =3D MSI supports 1 message, 64 bit > cap 10[70] =3D PCI-Express 2 endpoint IRQ 1 max data 128(128) link x1= (x1) > speed 2.5(2.5) ASPM disabled(L0s/L1) > cap 11[b0] =3D MSI-X supports 4 messages, enabled > Table in map 0x20[0x0], PBA in map 0x20[0x800] > cap 03[d0] =3D VPD > ecap 0001[100] =3D AER 1 0 fatal 0 non-fatal 1 corrected > ecap 0002[140] =3D VC 1 max VC0 > ecap 0003[160] =3D Serial 1 0100000004000001 > PCI-e errors =3D Correctable Error Detected > Unsupported Request Detected > Corrected =3D Advisory Non-Fatal Error >=20 > it's similar hardware, same chip, different revision. I already reported > this on net@ but no patch could really solve the issue. >=20 Hello. Well, it seems the same here with taht specific NIC. Changing ANYTHING, eve= n already enabled features, or bringing the NIC down and then up seem to solve this p= roblem. I guess, I file a PR to make this issue memorized. Regards, Oliver --Sig_/cMSIMgDXmMySkuIiJUqzZir Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUGpxhAAoJEOgBcD7A/5N8ff4H/2IveS1fSLUXMN5S/ZSos6Jg ZQN3FWd5RShlKSVhutKwDNmqAtQVIIS3ezm2sYnTs2JUjXk9tn6EerQzzHr4ox5v NSI0QWSVRFP+YHBohOqcIn4yZV6CM9stv32ay2SEbpjCuwpBQ8mZA4rTWpb3KtpO JILrbCDuvC93E7Ig1MzWWBD1Uxa20bb7bqoRV4gXAbcfKbNgjIpgR8SmuIwkxvv2 +mlTKQrURYEQUX/IgbK7csx/uG+C0oslFw1uWZTHyexbXFzYPOz9t7STxk2aNDKd /XPdDAvq2/ccQ7R3czDrMRPRoOo4/MP3H3d1cmN0fPBmGTSolGTzCzBCVxfcGgU= =p2V6 -----END PGP SIGNATURE----- --Sig_/cMSIMgDXmMySkuIiJUqzZir-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 11:19:14 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E929F58C for ; Thu, 18 Sep 2014 11:19:13 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A38EF29F for ; Thu, 18 Sep 2014 11:19:13 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1XUZjy-0002GJ-Im>; Thu, 18 Sep 2014 13:19:10 +0200 Received: from [141.89.176.137] (helo=hermann.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1XUZjy-002MOt-GM>; Thu, 18 Sep 2014 13:19:10 +0200 Date: Thu, 18 Sep 2014 13:18:39 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: UEFI/CURRENT: vt() and nVidia BLOB: not working on nVidia GT 740M Message-ID: <20140918131839.09199df7.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/XuT/FohKRPCCcFoyCl0o_zE"; protocol="application/pgp-signature" X-Originating-IP: 141.89.176.137 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 11:19:14 -0000 --Sig_/XuT/FohKRPCCcFoyCl0o_zE Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Running FreeBSD 11.0-CURRENT #5 r271728: Thu Sep 18 01:18:25 CEST 2014 amd6= 4 on a Lenovo ThinkPad Edge E540 laptop with built-in nVidida GT 740M GPU (NV208M) doesn'= t bring up X11 even with most recent nVidia BLOB 343.13. The system has been installed from a most recent FBSD CURRENT USB drive ima= ge and uses UEFI and newcons/vt(). IN UEFI Firmware, the primary GPU selected is the nV= idia GT 740M in favour of the Intel iGPU HD4600 of the Haswell CPU. While the system works well with console only after UEFI boot, I can not st= art X11 having driver "nvidia" enabled, the portion in xorg.conf reflecting this is as fol= lows: Section "Device" Identifier "Card0" VendorName "nVidia" BoardName "GT740M" Driver "nvidia" BusID "PCI:1:0:0" EndSection When starting X, the screen goes blank and black with a stuck mousepointer = showing up and a green (colour defined in my console) carret showing in the left hand uppe= r corner of the screen - and nothing happens anymore. Using driver "nv" from the regular xorg installation from the ports (having= set=20 WITH_NEW_XORG=3D YES WITH_KMS=3D YES WITH_GALLIUM=3D YES in /etc/make.conf) fails with the error, that the driver doesn't recognises= the GPU type. The only working solution is the very slow and unusable x11-drivers/xf86-vi= deo-scfb unaccelerated software framebuffer. I'd like to use the accelerated nVidia GPU with the BLOB as I do on all oth= er FreeBSD boxes I use (systems still without UEFI and graphical vt()). What am I doing wrong here? Has someone successfully bootet FBSD CURRENT via EUFI and nVidia accelerate= d GPU via nVidia's BLOB? Thanks in advance, Oliver --Sig_/XuT/FohKRPCCcFoyCl0o_zE Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUGr+QAAoJEOgBcD7A/5N8pN4IALSA7Lc2iaquaMTz5X9k6hmq f7DNlBt+8nS7iKmUMtiH1R8Ms5RWXOkTLKx/9f8yubfhtVp8WpsjIBto7Bj/ERAt fW8dK+umF1SwKMhn3QQdAR2aJjeG7hWK/Uis1fHzWxekMOHEqEGL8My41lCpXuJj qp2ocB1kR2nSLApaAiGe5IzUNklhwaH2MmWvi/loVq8ix8/eIcyXcF42RgOLftI4 jKMq8VSXMLGb498hcw07rsxQcl3WOoMKX81hiBAHIez2n9JRLcRh4sdnxOJLv968 gSeoWve3m7xgOKz2uC7DqHw9SU63jPkS/+iuKHWFHYdLB2YWKen/ifOmL6mgqpY= =jWpD -----END PGP SIGNATURE----- --Sig_/XuT/FohKRPCCcFoyCl0o_zE-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 11:57:44 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8717EEBF for ; Thu, 18 Sep 2014 11:57:44 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 45A2B878 for ; Thu, 18 Sep 2014 11:57:43 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 8987C24800B for ; Thu, 18 Sep 2014 13:57:35 +0200 (CEST) Message-ID: <541AC8A4.3000306@selasky.org> Date: Thu, 18 Sep 2014 13:57:24 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 CC: FreeBSD Current Subject: Panic - uma_zfree_arg - zone argument is NULL Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 11:57:44 -0000 Hi, Is this a known issue? Happens when invoking a program over and over again in a loop in from a shell. --HPS Â’ From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 12:03:58 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73DCE338 for ; Thu, 18 Sep 2014 12:03:58 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F003A954 for ; Thu, 18 Sep 2014 12:03:57 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 7EA9424800B for ; Thu, 18 Sep 2014 14:03:55 +0200 (CEST) Message-ID: <541ACA20.5030805@selasky.org> Date: Thu, 18 Sep 2014 14:03:44 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 CC: FreeBSD Current Subject: Re: Panic - uma_zfree_arg - zone argument is NULL References: <541AC8A4.3000306@selasky.org> In-Reply-To: <541AC8A4.3000306@selasky.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 12:03:58 -0000 On 09/18/14 13:57, Hans Petter Selasky wrote: > Hi, > > Is this a known issue? > > Happens when invoking a program over and over again in a loop in from a > shell. > > --HPS > > Â’ Backtrace got stripped: FreeBSD 10.0-RELEASE panic: page fault Unread portion of the kernel message buffer: fault virtual address = 0xd8 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80b07863 stack pointer = 0x28:0xfffffe085d63b3b0 frame pointer = 0x28:0xfffffe085d63b420 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 5386 (sh) trap number = 12 panic: page fault cpuid = 21 KDB: stack backtrace: #0 0xffffffff808e7dc0 at kdb_backtrace+0x60 #1 0xffffffff808af8a5 at panic+0x155 #2 0xffffffff80c8e882 at trap_fatal+0x3a2 #3 0xffffffff80c8eb59 at trap_pfault+0x2c9 #4 0xffffffff80c8e2e6 at trap+0x5e6 #5 0xffffffff80c75582 at calltrap+0x8 #6 0xffffffff80898d25 at free+0x75 #7 0xffffffff8085c869 at elf64_load_file+0x379 #8 0xffffffff8085c23e at exec_elf64_imgact+0xa9e #9 0xffffffff80879f50 at kern_execve+0x690 #10 0xffffffff808796a7 at sys_execve+0x37 #11 0xffffffff80c8f177 at amd64_syscall+0x357 #12 0xffffffff80c7586b at Xfast_syscall+0xfb Uptime: 1h51m46s #0 doadump (textdump=) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:219 #1 0xffffffff808af520 in kern_reboot (howto=260) at /10_release/sys/kern/kern_shutdown.c:447 #2 0xffffffff808af8e4 in panic (fmt=) at /10_release/sys/kern/kern_shutdown.c:754 #3 0xffffffff80c8e882 in trap_fatal (frame=, eva=) at /10_release/sys/amd64/amd64/trap.c:882 #4 0xffffffff80c8eb59 in trap_pfault (frame=0xfffffe085d63b300, usermode=0) at /10_release/sys/amd64/amd64/trap.c:699 #5 0xffffffff80c8e2e6 in trap (frame=0xfffffe085d63b300) at /10_release/sys/amd64/amd64/trap.c:463 #6 0xffffffff80c75582 in calltrap () at /10_release/sys/amd64/amd64/exception.S:232 #7 0xffffffff80b07863 in uma_zfree_arg (zone=0x0, item=0xfffff800114ee000, udata=0xffffffff81484760) at /10_release/sys/vm/uma_core.c:2519 #8 0xffffffff80898d25 in free (addr=, mtp=0xffffffff8138df70) at /10_release/sys/kern/kern_malloc.c:596 #9 0xffffffff8085c869 in elf64_load_file (p=, file=, addr=0xfffffe085d63b588, entry=0xfffffe085d63b790, pagesize=4096) at /10_release/sys/kern/imgact_elf.c:709 #10 0xffffffff8085c23e in exec_elf64_imgact (imgp=0xfffffe085d63b760) at /10_release/sys/kern/imgact_elf.c:944 #11 0xffffffff80879f50 in kern_execve (td=0xfffff800114db000, args=0xfffffe085d63b958, mac_p=0x0) at /10_release/sys/kern/kern_exec.c:501 #12 0xffffffff808796a7 in sys_execve (td=, uap=) at /10_release/sys/kern/kern_exec.c:213 #13 0xffffffff80c8f177 in amd64_syscall (td=0xfffff800114db000, traced=0) at subr_syscall.c:134 #14 0xffffffff80c7586b in Xfast_syscall () at /10_release/sys/amd64/amd64/exception.S:391 #15 0x0000000800d38d5a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) --HPS From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 12:06:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDB2E47A; Thu, 18 Sep 2014 12:06:00 +0000 (UTC) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E76D97A; Thu, 18 Sep 2014 12:06:00 +0000 (UTC) Received: by mail-qg0-f44.google.com with SMTP id z107so913139qgd.17 for ; Thu, 18 Sep 2014 05:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=cgfKMscdAemPG7MK0ZDQZ5Cixd+QXY3gDwxvufDOx+8=; b=VPSZ4yCB1UvGKJ63Py30zNj5f7zQ3vhm56oKQECbfqsWsFpGdbl7q0AC+7MPc4RsLx yq+PDjyOnSNYhsI0/9uNkDKrDIcg+vl/oqOgbJosTFcAqlr2IgcK3nv032hSXNiEA225 B3DyM3E8kdWt8JrzWx61KE8lMJ+oh2lBLOR4ZZxi6MIByAyTPOvWVJnkSBYSv8CF4PEy khCPfI6DSalYy2qzbm7lien8hx7m53KlaE8f9tTztdAOVMg4vINSVLAPRDVlan6S7HNh g1Mc8LOpxreXm3K9w4+d3aceru7+lIl0HisEhRX6z33eiqNxXeWJrmOYhfM/m+3A1ThV od3A== MIME-Version: 1.0 X-Received: by 10.236.155.10 with SMTP id i10mr3721830yhk.108.1411041959601; Thu, 18 Sep 2014 05:05:59 -0700 (PDT) Received: by 10.170.156.139 with HTTP; Thu, 18 Sep 2014 05:05:59 -0700 (PDT) Date: Thu, 18 Sep 2014 13:05:59 +0100 Message-ID: Subject: Freebsd 11 usb image zfs on root install on DN2820FYKH From: krad To: FreeBSD Questions , freebsd-current@freebsd.org X-Mailman-Approved-At: Thu, 18 Sep 2014 12:12:01 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 12:06:00 -0000 Has anyone got freebsd booting on an intel NUC DN2820FYKH? It installs fine just wont boot (doesnt see boot loader). I'm doing legacy not efi mode. I'm starting to bang my head against the wall on this one. Time to leave it for a bit i think.... From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 14:16:36 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9261A150; Thu, 18 Sep 2014 14:16:36 +0000 (UTC) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CF67B89; Thu, 18 Sep 2014 14:16:36 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id s7so1143140qap.18 for ; Thu, 18 Sep 2014 07:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9Pvf0pm+/GI60Oo68S0nok3Hq7X+nXfIIFisQBuzJdM=; b=MeTVt9pGNFOvsNHZZ7DFOrFh2N89PG+jqAvtt5r89H52xmZQBkvuj8KzfXugnNtRl4 wvpq4NnrC8L31uZoIN+/vQz9gowvSO+NR2elfQT0TCSeRWO/V4LIIUIA8h4QZskQcytR XtqiZqbJhUi4M4BkEwrhwXbaTm8pdIbyIJsWgDgM+jyrf+1XuRuMhFQ6TKdstwJow+sM Na1sD0E88XZ4xqZ9C+Hn1lPeyx55WnOEOqMnfCpOKXkX7giOc/oyRIxzqSUx9dD+Kzo4 tKHGgMzC57WI5E6tmQ91xqHeE4MQdPVoyoYJcsd/MRvfHaWTKlqfXktj8eJwPE7DGG3U qfog== MIME-Version: 1.0 X-Received: by 10.224.86.5 with SMTP id q5mr9574982qal.36.1411049795051; Thu, 18 Sep 2014 07:16:35 -0700 (PDT) Received: by 10.140.104.241 with HTTP; Thu, 18 Sep 2014 07:16:34 -0700 (PDT) In-Reply-To: <5419EE95.40600@selasky.org> References: <5419EE95.40600@selasky.org> Date: Thu, 18 Sep 2014 16:16:34 +0200 Message-ID: Subject: Re: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD From: Stefano Garzarella To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Adrian Chadd , freebsd-current , Luigi Rizzo , George Neville-Neil X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 14:16:36 -0000 Hi Hans, I saw the discussion about TSO, but the GSO is a software implementation unrelated with the hardware. Furthermore, if the TSO is enabled (and supported by the NIC), the GSO is not executed, because is useless. After the execution of the GSO, the packets, that are passed to the device driver, are smaller (or equal) than MTU, so the TSO is unnecessary. For this reason the GSO doesn't look neither "ifp->if_hw_tsomax" nor hardware segment limits. The GSO is very useful when you can't use the TSO. Cheers, Stefano 2014-09-17 22:27 GMT+02:00 Hans Petter Selasky : > On 09/17/14 20:18, Stefano Garzarella wrote: > >> Hi Adrian, >> the results that I sent, regard just one flow, but I can try with two >> simultaneous flows and I'll send you the results. >> >> Thanks, >> Stefano >> >> > Hi Stefano, > > You might have seen the discussion about TSO. Is it so that the proposed > GSO feature only looks at the "ifp->if_hw_tsomax" field, and ignores > hardware limits regarding maximum segment size and maximum segment count? > > --HPS > -- *Stefano Garzarella* stefano.garzarella@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 14:19:55 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 56A133B6 for ; Thu, 18 Sep 2014 14:19:55 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 21D45BE3 for ; Thu, 18 Sep 2014 14:19:55 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s8IEJjYc027628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 18 Sep 2014 07:19:47 -0700 Message-ID: <541AEA01.4030604@freebsd.org> Date: Thu, 18 Sep 2014 07:19:45 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: "O. Hartmann" , FreeBSD CURRENT Subject: Re: UEFI/CURRENT: vt() and nVidia BLOB: not working on nVidia GT 740M References: <20140918131839.09199df7.ohartman@zedat.fu-berlin.de> In-Reply-To: <20140918131839.09199df7.ohartman@zedat.fu-berlin.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVZtTScbolZbPK3KLwp4ZL2xj3slrhffww7jOT+Kbfxg+3d53cpgwW0nBB1kDwRRHp+oiBdFSZR2iV3yU+UHmvj6gvB/oJQzkkw= X-Sonic-ID: C;nBke1z4/5BG7rjZXoK8kYw== M;XEv01z4/5BG7rjZXoK8kYw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 14:19:55 -0000 On 09/18/14 04:18, O. Hartmann wrote: > Running FreeBSD 11.0-CURRENT #5 r271728: Thu Sep 18 01:18:25 CEST 2014 amd64 on a Lenovo > ThinkPad Edge E540 laptop with built-in nVidida GT 740M GPU (NV208M) doesn't bring up X11 > even with most recent nVidia BLOB 343.13. > > The system has been installed from a most recent FBSD CURRENT USB drive image and uses > UEFI and newcons/vt(). IN UEFI Firmware, the primary GPU selected is the nVidia GT 740M > in favour of the Intel iGPU HD4600 of the Haswell CPU. > > While the system works well with console only after UEFI boot, I can not start X11 having > driver "nvidia" enabled, the portion in xorg.conf reflecting this is as follows: > > Section "Device" > Identifier "Card0" > VendorName "nVidia" > BoardName "GT740M" > Driver "nvidia" > BusID "PCI:1:0:0" > EndSection > > When starting X, the screen goes blank and black with a stuck mousepointer showing up and > a green (colour defined in my console) carret showing in the left hand upper corner of the > screen - and nothing happens anymore. > > Using driver "nv" from the regular xorg installation from the ports (having set > WITH_NEW_XORG= YES > WITH_KMS= YES > WITH_GALLIUM= YES > in /etc/make.conf) fails with the error, that the driver doesn't recognises the GPU type. > > The only working solution is the very slow and unusable x11-drivers/xf86-video-scfb > unaccelerated software framebuffer. > > I'd like to use the accelerated nVidia GPU with the BLOB as I do on all other FreeBSD > boxes I use (systems still without UEFI and graphical vt()). > > What am I doing wrong here? > > Has someone successfully bootet FBSD CURRENT via EUFI and nVidia accelerated GPU via > nVidia's BLOB? > > Thanks in advance, > > Oliver I'm using UEFI and the blob every day without issue. However, that is with an add-in card. It's possible that X11 or the nVidia driver is trying to reinitialize the card through the (potentially non-existant) video BIOS, which fails. Is there any option like "NoInt10" you can turn on in X configuration? -Nathan From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 15:27:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29AF93B0; Thu, 18 Sep 2014 15:27:48 +0000 (UTC) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E42677E2; Thu, 18 Sep 2014 15:27:47 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id v10so1624243pde.17 for ; Thu, 18 Sep 2014 08:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PwOOEuTXCiU40DQ0+jIMK2m+x87Q8Pn4FYuUJkOHEQM=; b=CaWeokpPaew6TbzagIWIgZTj+1zlqYItN0V6kG5z9BFFhSaSGc9bh7kQyviY+/Tyj7 nfzOls9SPeu3uSdOz7bpQk8ZLkOtYgi9WyxnViQgJYOQOiWGVT7p2yCyISBcKwGgNHHO UKQ6OtJaAO9waa3uGCJyvma+be2NzyvZ2mAXYCxoESqcSt5+T78VnbUwBXzfuZXNntrH FnoHwbkFhWLDXKEaPeNGSAmscQFNbBl3z5HxY03g5CPFDRAMVtSeZ5xMCatmwjYDtnqp o5zD1BfgrFFgioD6HSUsudS7eEozf2SpcuYtS/egkFiTt7SbxM3lswq/GAUD1HV0xedH OwCw== MIME-Version: 1.0 X-Received: by 10.70.42.7 with SMTP id j7mr6284590pdl.9.1411054067133; Thu, 18 Sep 2014 08:27:47 -0700 (PDT) Received: by 10.202.104.89 with HTTP; Thu, 18 Sep 2014 08:27:47 -0700 (PDT) In-Reply-To: References: <5419EE95.40600@selasky.org> Date: Thu, 18 Sep 2014 08:27:47 -0700 Message-ID: Subject: Re: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD From: Freddie Cash To: Stefano Garzarella Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Hans Petter Selasky , Adrian Chadd , "freebsd-net@freebsd.org" , George Neville-Neil , freebsd-current , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 15:27:48 -0000 On Thu, Sep 18, 2014 at 7:16 AM, Stefano Garzarella < stefanogarzarella@gmail.com> wrote: > I saw the discussion about TSO, but the GSO is a software > implementation unrelated with the hardware. > Furthermore, if the TSO is enabled (and supported by the NIC), the GSO is > not executed, because is useless. > > After the execution of the GSO, the packets, that are passed to the devic= e > driver, are smaller (or equal) than MTU, so the TSO is unnecessary. For > this reason the GSO doesn't look neither "ifp->if_hw_tsomax" nor hardware > segment limits. > > The GSO is very useful when you can't use the TSO. > =E2=80=8BHow does GSO affect IPFW, specifically the libalias(3)-based, in-k= ernel NAT? The ipfw(8) man page mentions that it doesn't play nicely with hardware-based TSO, and that one should disable TSO when using IPFW NAT. Will the software-based GSO play nicely with IPFW NAT?=E2=80=8B Will it ma= ke any difference to packet throughput through IPFW? Or is it still way too early in development to be worrying about such things? :) --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 17:04:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B00D040E; Thu, 18 Sep 2014 17:04:43 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3E6D2772; Thu, 18 Sep 2014 17:04:42 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XUf8K-001wr1-HX>; Thu, 18 Sep 2014 19:04:40 +0200 Received: from g225156062.adsl.alicedsl.de ([92.225.156.62] helo=hermann.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XUf8K-00328n-DE>; Thu, 18 Sep 2014 19:04:40 +0200 Date: Thu, 18 Sep 2014 19:04:03 +0200 From: "O. Hartmann" To: Nathan Whitehorn Subject: Re: UEFI/CURRENT: vt() and nVidia BLOB: not working on nVidia GT 740M Message-ID: <20140918190403.0faa25de.ohartman@zedat.fu-berlin.de> In-Reply-To: <541AEA01.4030604@freebsd.org> References: <20140918131839.09199df7.ohartman@zedat.fu-berlin.de> <541AEA01.4030604@freebsd.org> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/lPJW20ZHSjkb+ZUwt7Ttg29"; protocol="application/pgp-signature" X-Originating-IP: 92.225.156.62 X-ZEDAT-Hint: A Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 17:04:43 -0000 --Sig_/lPJW20ZHSjkb+ZUwt7Ttg29 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Thu, 18 Sep 2014 07:19:45 -0700 Nathan Whitehorn schrieb: >=20 > On 09/18/14 04:18, O. Hartmann wrote: > > Running FreeBSD 11.0-CURRENT #5 r271728: Thu Sep 18 01:18:25 CEST 2014 = amd64 on a > > Lenovo ThinkPad Edge E540 laptop with built-in nVidida GT 740M GPU (NV2= 08M) doesn't > > bring up X11 even with most recent nVidia BLOB 343.13. > > > > The system has been installed from a most recent FBSD CURRENT USB drive= image and uses > > UEFI and newcons/vt(). IN UEFI Firmware, the primary GPU selected is th= e nVidia GT > > 740M in favour of the Intel iGPU HD4600 of the Haswell CPU. > > > > While the system works well with console only after UEFI boot, I can no= t start X11 > > having driver "nvidia" enabled, the portion in xorg.conf reflecting thi= s is as > > follows: > > > > Section "Device" > > Identifier "Card0" > > VendorName "nVidia" > > BoardName "GT740M" > > Driver "nvidia" > > BusID "PCI:1:0:0" > > EndSection > > > > When starting X, the screen goes blank and black with a stuck mousepoin= ter showing up > > and a green (colour defined in my console) carret showing in the left h= and upper > > corner of the screen - and nothing happens anymore. > > > > Using driver "nv" from the regular xorg installation from the ports (ha= ving set > > WITH_NEW_XORG=3D YES > > WITH_KMS=3D YES > > WITH_GALLIUM=3D YES > > in /etc/make.conf) fails with the error, that the driver doesn't recogn= ises the GPU > > type. > > > > The only working solution is the very slow and unusable x11-drivers/xf8= 6-video-scfb > > unaccelerated software framebuffer. > > > > I'd like to use the accelerated nVidia GPU with the BLOB as I do on all= other FreeBSD > > boxes I use (systems still without UEFI and graphical vt()). > > > > What am I doing wrong here? > > > > Has someone successfully bootet FBSD CURRENT via EUFI and nVidia accele= rated GPU via > > nVidia's BLOB? > > > > Thanks in advance, > > > > Oliver >=20 > I'm using UEFI and the blob every day without issue. However, that is=20 > with an add-in card. It's possible that X11 or the nVidia driver is=20 > trying to reinitialize the card through the (potentially non-existant)=20 > video BIOS, which fails. Is there any option like "NoInt10" you can turn= =20 > on in X configuration? > -Nathan I tried Option "NoInt10" Option "PrimaryInt" both in all combinations possible without any success. It is good to hear t= hat at least one successful run of the BLOB with UEFI/vt can be reported, so the problem= might be of a minor issue - hopefully. The GPU is a dedicated PCIe GPU for the notebook, combined with the HD4600 = which can be used via nVidia's "Optimus" switching - if software supports it. In the UEF= I, I selected the nVidia dedicated GPU as the primary one. The way the "dead" screen shows up reminds me of a dead end screen: the lef= t-hand top carret and the console's mousepointer (at the position it was on the consol= e) look like as the whole output is now delegated towards another output socket. The key= board works surprisingly NOT as expected, since I have to switch this Lenovo FN key for= Ctrl - which then allows me to switch back to the console and terminate the X server or = xdm. I need to figure out what name's the sockets have (on the Dell Latitude I h= ave, they are called DPS-0 to DPS-2 for the internal display, the HDMI and the DisplayPor= t socket and VGA-0 for the VGA socket). Will report back ... Oliver --Sig_/lPJW20ZHSjkb+ZUwt7Ttg29 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUGxCJAAoJEOgBcD7A/5N8dQ4IAIZNaFEy8eTGtuIZCxiocwWC Z4hXNBWTertwHRP6pNfL3EKVgJ1g/Wdl48EoyYGpWq/AP/OIi7c+qb6BWmZtLGfT zSZQiZ5+28hH9w972JXVGhmHm859Ic8oZfKT7nNrR69Bcvj+GPRGALqiBlEsa9P+ 2C0L8nduHDk2+25A4wAV/L7Gdeeq015l8Ki4fJ4iVdoB9mLRbCAwXPhCVrrNDEAf itT+QHQDywwbu/bs0i8ZCGNGVHVSQ7bOuweqpKOlRpOvUaWE3mFEy79oDQvPXGb/ CQkHhvJABHOOvA7AMQXFSjU0MdrqImayhc7+htnwsGLipixVz2KDE7Yi4etjQLw= =WecA -----END PGP SIGNATURE----- --Sig_/lPJW20ZHSjkb+ZUwt7Ttg29-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 18:03:25 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B59871A5; Thu, 18 Sep 2014 18:03:25 +0000 (UTC) Received: from st11p00mm-asmtp002.mac.com (st11p00mm-asmtp002.mac.com [17.172.81.1]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 85F58D46; Thu, 18 Sep 2014 18:03:25 +0000 (UTC) Received: from andersbo-mac.local (ti0025a400-3490.bb.online.no [85.167.24.175]) by st11p00mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NC30013XZHBBK50@st11p00mm-asmtp002.mac.com>; Thu, 18 Sep 2014 18:03:18 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-09-18_07:2014-09-18,2014-09-18,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409180158 Message-id: <541B1E5F.30103@icloud.com> Date: Thu, 18 Sep 2014 20:03:11 +0200 From: Anders Bolt-Evensen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-version: 1.0 To: Nathan Whitehorn Subject: Re: CURRENT: EFI boot failure References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> <5417E20D.8070607@freebsd.org> <20140916235039.34e9284f.ohartman@zedat.fu-berlin.de> <5418BFA7.40700@freebsd.org> In-reply-to: <5418BFA7.40700@freebsd.org> Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 18:03:25 -0000 On 09/17/2014 00:54, Nathan Whitehorn wrote: > > Try xf86-video-scfb instead? > I also had the same problem (mentioned in another thread called "Problems starting X on Mac using vesa, radeon or intel drivers when running FreeBSD-CURRENT in EFI"), and following your suggestion to install the xf86-video-scfb driver is working for me using a Radeon HD 6770M and a built-in Intel HD 3000 graphics card. Neither the Intel or Radeon driver worked for me in EFI mode, but the driver you mentioned seems to work without problems. :) So thank you for that tip. :) Have a good night or day, everyone. :) From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 18:50:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 317FEAAC; Thu, 18 Sep 2014 18:50:15 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7ED762ED; Thu, 18 Sep 2014 18:50:14 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id mc6so1780441lab.34 for ; Thu, 18 Sep 2014 11:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nqutUqgD/dt5ZyXbg3fM7Rvo8N3VThzImDqy2HKmZ1k=; b=n6am/tpaC2gZKPC4ZxXO+X8XC6S1c/g/unAInMqscLNzf8Pe7JQjHT2Banq2W+ebmu KOIJ/30OTAvj+KAsCOBSzLCNFWa2r9MxM0ocHGEHG4IqRs0uPHwijFr8kTm0QSKbNOfJ sGewWbbnrF3rfUmOg4ptgSuii6jr2lNCiVjL/4MQhMwzuwyy3/dF/P66XYKjNGVC/s56 8gNcslMrGAqvqo4GmwerbePWms1ANJkvHRFppH/odQkzdHa1gBYP7L53jijtHxCo4J2Z qudFV1+WzrxWdilf8Kj/60jggIwFujJcnfMq9sBCRslxlPcjEtyf2opXi/HQrTeD9ZHO 9T+g== MIME-Version: 1.0 X-Received: by 10.112.48.100 with SMTP id k4mr1427780lbn.95.1411066212278; Thu, 18 Sep 2014 11:50:12 -0700 (PDT) Received: by 10.25.21.166 with HTTP; Thu, 18 Sep 2014 11:50:12 -0700 (PDT) In-Reply-To: References: Date: Thu, 18 Sep 2014 14:50:12 -0400 Message-ID: Subject: Re: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD From: Ryan Stone To: Stefano Garzarella Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" , George Neville-Neil , freebsd-current , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 18:50:15 -0000 On Wed, Sep 17, 2014 at 4:27 AM, Stefano Garzarella wrote: > Much of the advantage of TSO comes from crossing the network stack only > once per (large) segment instead of once per 1500-byte frame. > GSO does the same both for segmentation (TCP) and fragmentation (UDP) > by doing these operations as late as possible. My initial impression is that this is a layering violation. Code like this gives me pause: + eh = mtod(m, struct ether_vlan_header *); + if (eh->evl_encap_proto == htons(ETHERTYPE_VLAN)) { + eh_len = ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN; + } else { + eh_len = ETHER_HDR_LEN; + } + + return gso_dispatch(ifp, m, eh_len); If someone adds QinQ support, this code must be updated. When vxlan support comes in, we must update this code or else the outer UDP packet gets fragmented instead of the inner TCP payload being segmented. As more tunneling protocols get added to FreeBSD, the dispatch code for GSO gets uglier and uglier. It seems to me that the real problem that we are trying to solve is a lack of batching in the kernel. Currently the network stack operates on the mbuf (packet) boundary. It seems to me that we could introduce a "packet group" concept that is guaranteed to have the same L3 and L2 endpoint. In the transmit path, we would initially have a single (potentially oversized) packet in the group. When TCP segments the packet, it would add each packet to the packet group and pass it down the stack. Because we guarantee that the endpoints are the same for every packet in the group, the L3 code can do a single routing table lookup and the L2 code can do a single l2table lookup for the entire group. The disadvantages of packet groups would be that: a) You have touch a lot more code in a lot more places to take advantage of the concept. b) TSO inherently has the same layering problems. If we're going to solve the problem for tunneling protocols then GSO might well be able to take advantage of them. From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 20:13:21 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0BF4D32E for ; Thu, 18 Sep 2014 20:13:21 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B8ABBD7A for ; Thu, 18 Sep 2014 20:13:20 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1XUi4s-002hAh-8z>; Thu, 18 Sep 2014 22:13:18 +0200 Received: from g225156062.adsl.alicedsl.de ([92.225.156.62] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1XUi4s-003KQK-5X>; Thu, 18 Sep 2014 22:13:18 +0200 Date: Thu, 18 Sep 2014 22:13:12 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: Re: CURRENT: EFI boot failure Message-ID: <20140918221312.3811e382.ohartman@zedat.fu-berlin.de> In-Reply-To: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/WfQo.9SgOOH6_G34tw8wFgv"; protocol="application/pgp-signature" X-Originating-IP: 92.225.156.62 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 20:13:21 -0000 --Sig_/WfQo.9SgOOH6_G34tw8wFgv Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tue, 16 Sep 2014 02:05:41 +0200 "O. Hartmann" schrieb: >=20 > Installing FreeBSD-11.0-CURRENT-amd64-20140903-r270990 on a Laptop works = for UEFI fine. > After I updated the sources to r271649, recompiled world and kernel (as = well as > installed), now I get stuck with the screen message: >=20 > >> FreeBSD EFI boot block > Loader path: /boot/loader.efi >=20 > and nothing happens. After a couple of minutes, the system reboots. >=20 > What happened and how can this problem be solved? after today's "make world" (revision 271800) and two days of normal operati= on, I run into the same situation as described above! This is more than annoying! The scre= en show simply >> FreeBSD EFI boot block Loader path: /boot/loader.efi and nothing happens forever. Usually, the loader/console shows up. This tim= e the system gets stuck as I reported earlier. I can not afford another two days of installing the laptop again. How can I= get rid of this immature EFI and run the system in the traditional way? It seems two i= mmature systems meet each other, vt() and EFI and this ends up in a desaster. What is the fallback procedure? How to save the system and circumvent this = problem? Is there a way to interrupt the boot process and drop out into some kind of em= ergency screen/console? BTW, I temporarily fixed this issu by copying the USB drive image's loader.= efi into boot. This seems to be a bug in the compiler/compiling loader.efi. --Sig_/WfQo.9SgOOH6_G34tw8wFgv Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUGzzdAAoJEOgBcD7A/5N8Fx8H/j1qHObMSIeepXqj3LQHosyn 03kdo2PIEghpkrxir0k11ZO5YUzvzJsFlh2y2jHBdN3B0NAEDubekFBmiUfFu9qc 6RG7gfsKCc9c1Dd9u9fDajdH/nb/7O3wkO9u9JmAL6FokbFX1OTQEHJSsIP5G/0J +Q6lE/MdaVQDtDo9s/yBQEV5B7bihZ43vFUfDaer3OnV/qaBg0A+XMVJtYZ84pvD V/czf7BJBoOA4H8DOAevrL+TgAGUwCZ1Vl89zngC/HhlDHbt668wCZ0dfGEDc1Lv M+U8gTw+ULq4vWmpWkYB2A1djTuLZzA+jknb2xU21LuYHxLjbfwKXNZxfv3A2yk= =WHwy -----END PGP SIGNATURE----- --Sig_/WfQo.9SgOOH6_G34tw8wFgv-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 18:12:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8EA646C; Thu, 18 Sep 2014 18:12:28 +0000 (UTC) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 30FA4E61; Thu, 18 Sep 2014 18:12:28 +0000 (UTC) Received: by mail-yk0-f170.google.com with SMTP id 19so239323ykq.1 for ; Thu, 18 Sep 2014 11:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=x7rBFiOC3c8YIRrvKYoP6e0u4ry+3eKxAVeJPHIcoHk=; b=G9igzekdn4/OyZj4q/CH6CZMgFUtQoIG763k6nZ0UlnG8bz9BM9AGARLFJ9A4Gve8Z e5YQO23msHSjPmHiT9S/M2t4pw9zhClp8O2boEnVfBo40pBBRHD7Gxst2+DyOos4zJoB g4bXp4vo75XqyGFNMgG1cm0egNt6Y4NZ1SQk8cVOBTEFMXy4qi74BHereu1Xh8mPu38h kNxSQ5WRF9Hs+GMfEXgXIsE7IJkO7RGCU5VMrCf6lhU0AAscf5MY55ggvhiwFBXij+6z DbaGFVZdYdK/MAPnaPU5vkKZKMMPktmMyyGm6nhsKQmX/mXG2NcVNw8FFk1RC7ewbMWX dLNQ== MIME-Version: 1.0 X-Received: by 10.236.141.148 with SMTP id g20mr6603387yhj.34.1411063947304; Thu, 18 Sep 2014 11:12:27 -0700 (PDT) Received: by 10.170.156.139 with HTTP; Thu, 18 Sep 2014 11:12:27 -0700 (PDT) In-Reply-To: References: Date: Thu, 18 Sep 2014 19:12:27 +0100 Message-ID: Subject: Re: Freebsd 11 usb image zfs on root install on DN2820FYKH From: krad To: FreeBSD Questions , freebsd-current@freebsd.org X-Mailman-Approved-At: Thu, 18 Sep 2014 20:28:15 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 18:12:28 -0000 hmm, got it working by downgrading to v32 firmware. It seems the is a bug in intels wonderful uefi code, which of course the blame freebsd for 8/ On 18 September 2014 13:05, krad wrote: > Has anyone got freebsd booting on an intel NUC DN2820FYKH? > > It installs fine just wont boot (doesnt see boot loader). I'm doing legacy > not efi mode. > > I'm starting to bang my head against the wall on this one. Time to leave > it for a bit i think.... > From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 20:15:54 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1B1E45C for ; Thu, 18 Sep 2014 20:15:54 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 668BBD98 for ; Thu, 18 Sep 2014 20:15:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s8IKFs4N054470 for ; Thu, 18 Sep 2014 20:15:54 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s8IKFrQe054467 for current@FreeBSD.org; Thu, 18 Sep 2014 20:15:53 GMT (envelope-from bdrewery) Received: (qmail 34598 invoked from network); 18 Sep 2014 15:15:51 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 18 Sep 2014 15:15:51 -0500 Message-ID: <541B3D72.8050502@FreeBSD.org> Date: Thu, 18 Sep 2014 15:15:46 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: "pkg@freebsd.org" Subject: Poudriere code moved to https://github.com/freebsd/poudriere OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0LHHc7J1vB0qN7Vmm1Kj85xVc2Iin52N6" X-Mailman-Approved-At: Thu, 18 Sep 2014 20:37:43 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 20:15:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0LHHc7J1vB0qN7Vmm1Kj85xVc2Iin52N6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Poudriere's code no longer is based in fossil. It has moved to https://github.com/freebsd/poudriere. Fossil will not be kept synced. Please submit patches as pull requests and issues on github going forward (rather than the old fossil site). This conversion is not compatible with the existing repository that I had on github.com/bdrewery/poudriere. The one I had was only a convenience and did not have tickets/commit-hashes converted. The new conversion does have these migrated. There are no hashes in common. Any checkouts you have will need to have customizations rebased onto the new repository. If you have no modifications to your own local repository than you can just recheckout to the new one. Given the old had a 'trunk' head then this should work: # git remote add upstream https://github.com/freebsd/poudriere.git # git remote update upstream # git checkout -b master upstream/master If you have made modifications then you will need to rebase onto the new one. Look in your 'git log' and find the last upstream commit which I will call UPSTREAM_COMMIT. Then rebase all of your work onto the new mast= er: # git remote add upstream https://github.com/freebsd/poudriere.git # git remote update upstream # git rebase --onto upstream/master UPSTREAM_COMMIT Don't forget to git push -f to your own remote if needed. --=20 Regards, Bryan Drewery --0LHHc7J1vB0qN7Vmm1Kj85xVc2Iin52N6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUGz1zAAoJEDXXcbtuRpfPRrIH/2fUts32GLxgAKKlTCno9C0P fno/0e+gRE3r2JkMrTa5TwYCuuFB4VS8aq8zsb7djJSMxQIPepEmip7wz16UBNy7 TMTt5hBlXtq6ViQLJrvMXSu56s+6HU2D9KGRMpO8wK1uDISy54idePqp8pQcV2HZ uWUf0NbZmQW+mZvyNiIQujS2DvyfGqhOFegPzUrxHqXHdtLJBM8lVc4gzwRRcyJz Wh/UTV0VThZHQ75Mr7cW+j3SnTazK0DgQlQ06OJPappxiP7oWCB0dcpXuPaOTQ5f JsNxsThv2PfIzta6jQJWAsIGli/whqdAEpk9M2ZZsAOmiIlXeTNA9uX+RfZqrws= =mBwn -----END PGP SIGNATURE----- --0LHHc7J1vB0qN7Vmm1Kj85xVc2Iin52N6-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 13:01:09 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 413DE284 for ; Fri, 19 Sep 2014 13:01:09 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EE4F9ECD for ; Fri, 19 Sep 2014 13:01:08 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1XUxoA-002Rvf-Pu>; Fri, 19 Sep 2014 15:01:06 +0200 Received: from [141.89.176.137] (helo=hermann.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1XUxoA-000lX5-Op>; Fri, 19 Sep 2014 15:01:06 +0200 Date: Fri, 19 Sep 2014 15:00:29 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: src.conf: CFLAGS/COPTFLAGS inconsistency Message-ID: <20140919150029.1f27e490.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/qF4B2v02Njo+bW=Fa1fxJwS"; protocol="application/pgp-signature" X-Originating-IP: 141.89.176.137 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 13:01:09 -0000 --Sig_/qF4B2v02Njo+bW=Fa1fxJwS Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable man make.conf states, that COPTFLAGS is used for building/compiling the ker= nel (exclusively). The question arises: are kernel modules NOT kernel or are th= ey kernel? The problem I face is that with optimization level -O3 loader.efi gets misc= ompiled and a UEFI laptop stops/reject booting. To avoid other interference, I defined CO= PTFLAGS in /etc/src.conf accordingly, but leave CFLAGS?=3D-O3 in /etc/make.conf for= compilation of regular ports and the rest of the OS. I can observe that with CFLAGS set, either in make.conf, or src.conf or mut= ual exclusive, the CFLAGS is ALWAYS incorporated when kernel stuff like modules and even t= he loader.efi is built! I consider this inconsitent, since loader.efi is definitely kerne= l related stuff as well as modules. It seems to me that it s not possible to separate cleanly CFLAGS and COPTFL= AGS for userland/ports and kernel-only related compilations as described in the man= page.=20 --Sig_/qF4B2v02Njo+bW=Fa1fxJwS Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUHCjyAAoJEOgBcD7A/5N8zhgH/1uOVm8pFq72agSSgfB77Oa2 IzQpCgns2wKNodP+x/VgaY3LF4RlWJwqZE3V0qlBXL7nXUzx47fxQWR+F0IYQvzG rKWV/tgJqr7kn+5KWttgvMedC5m6FyvG+nvfqEwWcId3l4gz8lmp/7GN/+vEYv4Y CNpzfX9Gd3NawGZqrrJFulqbd5wIHBjxNYe2rFLdvh5YUsd/NEO3PEx7bnrl131j uloCKems6IsQMieg6Iiy+duyhTlfzfl2ibNS4y+RStqCIbWa69GClwM2X0THFxl3 Nf0wt1SK1SI0jiJYUkkD06y7FzXDFGbjufaD9Ns5s5POGXxoDO/dDD5q22DNoQg= =T8p0 -----END PGP SIGNATURE----- --Sig_/qF4B2v02Njo+bW=Fa1fxJwS-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 13:22:41 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30DBC67B; Fri, 19 Sep 2014 13:22:41 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D8B331F2; Fri, 19 Sep 2014 13:22:40 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XUy91-002YeH-5p>; Fri, 19 Sep 2014 15:22:39 +0200 Received: from [141.89.176.137] (helo=hermann.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XUy91-000nrr-3M>; Fri, 19 Sep 2014 15:22:39 +0200 Date: Fri, 19 Sep 2014 15:22:07 +0200 From: "O. Hartmann" To: Andriy Gapon Subject: Re: CURRENT: EFI boot failure Message-ID: <20140919152207.0473e213.ohartman@zedat.fu-berlin.de> In-Reply-To: <5418B8C3.7040406@FreeBSD.org> References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> <5417E20D.8070607@freebsd.org> <20140916230348.189e80cd.ohartman@zedat.fu-berlin.de> <5418B8C3.7040406@FreeBSD.org> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/.e/tjG/Ym/n3CLqOLR+iM1N"; protocol="application/pgp-signature" X-Originating-IP: 141.89.176.137 X-ZEDAT-Hint: A Cc: FreeBSD Current , Ed Maste , Nathan Whitehorn , Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 13:22:41 -0000 --Sig_/.e/tjG/Ym/n3CLqOLR+iM1N Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Wed, 17 Sep 2014 01:25:07 +0300 Andriy Gapon schrieb: > On 17/09/2014 00:32, Ed Maste wrote: > > On 16 September 2014 17:03, O. Hartmann w= rote: > >> > >> In that case, is it still /boot/boot1.efifat or is it /boot/boot1.efi?= What is the > >> difference? Is the efi partition FAT? > >=20 > > An EFI system partition (ESP) is a FAT-formatted partition with a > > specific GPT or MBR identifier and file system hierarchy; EFI firmware > > will try to load /EFI/BOOT/BOOTX64.EFI from the ESP. >=20 > A very useful read about how EFI boot process works and how different OSe= s boot > on top of it: > http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process= .html >=20 > > boot1.efi is an EFI application - that is, a PECOFF format binary. It > > searches for a UFS filesystem and loads loader.efi from that. It is > > intended to simplify the UEFI boot process, so that loader.efi, the > > .4th files, loader.conf etc. do not all need to be installed in the > > ESP. > >=20 > > boot1.efifat is a FAT filesystem image that contains a copy of > > boot1.efi as /EFI/BOOT/BOOTX64.EFI. It exists so that the installer > > can treat it as opaque bootcode, like other boot schemes. It's > > certainly possible to create a partition, use newfs_msdos to format > > it, and copy in boot1.efi instead. > >=20 > >> It is one disk, dedicated to FreeBSD (a laptop disk). Is there any doc= umentation > >> readable for non-developer for that matter? I'm curious about how EFI = works on > >> FreeBSD. > >=20 > > Better user-facing documentation is in progress; for now the best > > source is probably the wik. > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" > >=20 >=20 >=20 The problem I reported about in the first place is triggered by a faulty lo= ader.efi that arises, when optimisation level is -O3. -O2 works fine. I also realized that there is a kind of inconsistency in how COPTFLAGS and = CFLAGS are handled in reality compared to that what the manpage of make.conf states. S= etting COPTFLAGS=3D-O2 for compiling kernel stuff only ALWAYS incorporates CFLAGS,= which is set to CFLAGS=3D-O3 in make.conf in my case. loader.efi is, in my opinion, kernel = stuff only as well as kernel modules, which also gets compiled with CFLAGS. --Sig_/.e/tjG/Ym/n3CLqOLR+iM1N Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUHC3/AAoJEOgBcD7A/5N8w5YH/3sLuzZ+GJh1Nd9FpBupdvrZ 3H8t/8m4SFx+HR2oikHIfFPfPfQ5sM9m5iJ960OzDWGDo7Hrc7nebBmFo6NCb8pG 9HLjqVuRh1UJAIgCalzbM8IAL/Qt3NfIzRx++tt3TqY9X7aZjvg7sqHWcaFBPwgB 3IV/DvWvlX5xIQyfa1gtnbRhkKBpObuDRoY56bC5BcyDBqcAFwZFiJMQMvs4lUfX 9ZgSdUNvEjaN7XMuqa1+DPemnYMBec95ScEvAU44sofTW263G1OtSmp+5buBLGb1 4eG5LUKfQqKGFMr3E19w3tfGzhfaFYptPfPoV9EgDOeF/iGyMHeXTty1uudBWXg= =q03c -----END PGP SIGNATURE----- --Sig_/.e/tjG/Ym/n3CLqOLR+iM1N-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 14:57:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F6D016F for ; Fri, 19 Sep 2014 14:57:02 +0000 (UTC) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A04C1E1D for ; Fri, 19 Sep 2014 14:57:01 +0000 (UTC) X-AuditID: 1209190f-f79aa6d000005b45-1d-541c4436a607 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 75.BB.23365.6344C145; Fri, 19 Sep 2014 10:56:54 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s8JEur4l029993; Fri, 19 Sep 2014 10:56:54 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s8JEupR6003091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Sep 2014 10:56:53 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s8JEuo2N002844; Fri, 19 Sep 2014 10:56:50 -0400 (EDT) Date: Fri, 19 Sep 2014 10:56:50 -0400 (EDT) From: Benjamin Kaduk To: "O. Hartmann" Subject: Re: src.conf: CFLAGS/COPTFLAGS inconsistency In-Reply-To: <20140919150029.1f27e490.ohartman@zedat.fu-berlin.de> Message-ID: References: <20140919150029.1f27e490.ohartman@zedat.fu-berlin.de> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixG6nomvmIhNicOadusWcNx+YLP7O+sPk wOQx49N8Fo9T2w8yBjBFcdmkpOZklqUW6dslcGU8aNnLWnCKp6J32U/WBsavnF2MnBwSAiYS f3bMZoWwxSQu3FvP1sXIxSEkMJtJYuXmnVDORkaJF1dusEA4h5gk/k78A5VpYJSYOOsuM0g/ i4C2xKO1Z8FmsQmoSMx8s5ENxBYR0Jc413QazGYWMJSYvHUBWL2wgKlE/9SVLCA2p4CTROuF 50wgNq+Ao8T5O5fB5ggB2fu2LwOrERXQkVi9fwoLRI2gxMmZT1ggZmpJLJ++jWUCo+AsJKlZ SFILGJlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Zro5WaW6KWmlG5iBAUrpyT/DsZvB5UOMQpw MCrx8Bo8lw4RYk0sK67MPcQoycGkJMrb7yQTIsSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEl08M KMebklhZlVqUD5OS5mBREufd9IMvREggPbEkNTs1tSC1CCYrw8GhJMGb7wzUKFiUmp5akZaZ U4KQZuLgBBnOAzR8GkgNb3FBYm5xZjpE/hSjLse6zm/9TEIsefl5qVLivBdBrhMAKcoozYOb A0syrxjFgd4S5p0DMooHmKDgJr0CWsIEtITthhTIkpJEhJRUA+NEu9M+T9lEbG0SRN/y6r/1 qbr/cnJEQ97iG//Zgg9v2vMw4U6H5gmOjf+rNYu47i0zPpLx9Nda3ktzhZeKpbJe9fjA7sZ/ 4NjiTsn8e1LThPiaN8kdlW19M99673LzMwqpnwze9K6M/e3v+avobUZIY9hTAb9XjD/+qGXw Mzw+v3zquUBO3iAlluKMREMt5qLiRAAlN/WzDQMAAA== Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 14:57:02 -0000 On Fri, 19 Sep 2014, O. Hartmann wrote: > man make.conf states, that COPTFLAGS is used for building/compiling the kernel > (exclusively). The question arises: are kernel modules NOT kernel or are they kernel? > > The problem I face is that with optimization level -O3 loader.efi gets miscompiled and a > UEFI laptop stops/reject booting. To avoid other interference, I defined COPTFLAGS > in /etc/src.conf accordingly, but leave CFLAGS?=-O3 in /etc/make.conf for compilation of > regular ports and the rest of the OS. > > I can observe that with CFLAGS set, either in make.conf, or src.conf or mutual exclusive, > the CFLAGS is ALWAYS incorporated when kernel stuff like modules and even the loader.efi > is built! I consider this inconsitent, since loader.efi is definitely kernel related > stuff as well as modules. Sorry, I don't think I understand what you're trying to say in these two pragraphs. What does "defined COPTFLAGS in /etc/src.conf accordingly" mean? Likewise, what does " CFLAGS set, either in make.conf, or src.conf or mutual exclusive" mean? It may be best to give concrete examples of make.conf/src.conf settings pairs, and the observed behavior. > It seems to me that it s not possible to separate cleanly CFLAGS and COPTFLAGS for > userland/ports and kernel-only related compilations as described in the man page. BTW, COPTFLAGS (str) Controls the compiler settings when building the ker- nel. Optimization levels above [-O (-O2, ...)] are not guaranteed to work. Note the last sentence. -Ben From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 18:11:09 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2606F3AA; Fri, 19 Sep 2014 18:11:09 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 58F87803; Fri, 19 Sep 2014 18:11:07 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id D1BD11FE027; Fri, 19 Sep 2014 20:11:04 +0200 (CEST) Message-ID: <541C71AD.8040506@selasky.org> Date: Fri, 19 Sep 2014 20:10:53 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Rick Macklem Subject: Re: [RFC] Patch to improve TSO limitation formula in general References: <1658973011.35255303.1410467352538.JavaMail.root@uoguelph.ca> <541400A3.6060807@selasky.org> In-Reply-To: <541400A3.6060807@selasky.org> Content-Type: multipart/mixed; boundary="------------090208020808030909020008" Cc: George Neville-Neil , FreeBSD Current , Scott Long , Jack F Vogel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 18:11:09 -0000 This is a multi-part message in MIME format. --------------090208020808030909020008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Please find attached an updated TSO patch based on comments from Andrew, Rick and John-Mark Gurney. Review is appreciated. --HPS --------------090208020808030909020008 Content-Type: text/x-diff; name="tso.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tso.diff" === sys/dev/oce/oce_if.c ================================================================== --- sys/dev/oce/oce_if.c (revision 271555) +++ sys/dev/oce/oce_if.c (local) @@ -1731,7 +1731,9 @@ sc->ifp->if_baudrate = IF_Gbps(10); #if __FreeBSD_version >= 1000000 - sc->ifp->if_hw_tsomax = OCE_MAX_TSO_SIZE; + sc->ifp->if_hw_tsomax = 65536 - (ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN); + sc->ifp->if_hw_tsomaxsegcount = OCE_MAX_TX_ELEMENTS; + sc->ifp->if_hw_tsomaxsegsize = 4096; #endif ether_ifattach(sc->ifp, sc->macaddr.mac_addr); === sys/dev/oce/oce_if.h ================================================================== --- sys/dev/oce/oce_if.h (revision 271555) +++ sys/dev/oce/oce_if.h (local) @@ -152,7 +152,6 @@ #define OCE_MAX_TX_ELEMENTS 29 #define OCE_MAX_TX_DESC 1024 #define OCE_MAX_TX_SIZE 65535 -#define OCE_MAX_TSO_SIZE (65535 - ETHER_HDR_LEN) #define OCE_MAX_RX_SIZE 4096 #define OCE_MAX_RQ_POSTS 255 #define OCE_DEFAULT_PROMISCUOUS 0 === sys/dev/vmware/vmxnet3/if_vmx.c ================================================================== --- sys/dev/vmware/vmxnet3/if_vmx.c (revision 271555) +++ sys/dev/vmware/vmxnet3/if_vmx.c (local) @@ -1722,7 +1722,9 @@ ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; ifp->if_init = vmxnet3_init; ifp->if_ioctl = vmxnet3_ioctl; - ifp->if_hw_tsomax = VMXNET3_TSO_MAXSIZE; + ifp->if_hw_tsomax = 65536 - (ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN); + ifp->if_hw_tsomaxsegcount = VMXNET3_TX_MAXSEGS; + ifp->if_hw_tsomaxsegsize = VMXNET3_TX_MAXSEGSIZE; #ifdef VMXNET3_LEGACY_TX ifp->if_start = vmxnet3_start; === sys/dev/vmware/vmxnet3/if_vmxvar.h ================================================================== --- sys/dev/vmware/vmxnet3/if_vmxvar.h (revision 271555) +++ sys/dev/vmware/vmxnet3/if_vmxvar.h (local) @@ -277,8 +277,6 @@ */ #define VMXNET3_TX_MAXSEGS 32 #define VMXNET3_TX_MAXSIZE (VMXNET3_TX_MAXSEGS * MCLBYTES) -#define VMXNET3_TSO_MAXSIZE \ - (VMXNET3_TX_MAXSIZE - sizeof(struct ether_vlan_header)) /* * Maximum support Tx segments size. The length field in the === sys/dev/xen/netfront/netfront.c ================================================================== --- sys/dev/xen/netfront/netfront.c (revision 271555) +++ sys/dev/xen/netfront/netfront.c (local) @@ -134,7 +134,6 @@ * to mirror the Linux MAX_SKB_FRAGS constant. */ #define MAX_TX_REQ_FRAGS (65536 / PAGE_SIZE + 2) -#define NF_TSO_MAXBURST ((IP_MAXPACKET / PAGE_SIZE) * MCLBYTES) #define RX_COPY_THRESHOLD 256 @@ -2102,7 +2101,9 @@ ifp->if_hwassist = XN_CSUM_FEATURES; ifp->if_capabilities = IFCAP_HWCSUM; - ifp->if_hw_tsomax = NF_TSO_MAXBURST; + ifp->if_hw_tsomax = 65536 - (ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN); + ifp->if_hw_tsomaxsegcount = MAX_TX_REQ_FRAGS; + ifp->if_hw_tsomaxsegsize = PAGE_SIZE; ether_ifattach(ifp, np->mac); callout_init(&np->xn_stat_ch, CALLOUT_MPSAFE); === sys/kern/uipc_sockbuf.c ================================================================== --- sys/kern/uipc_sockbuf.c (revision 271555) +++ sys/kern/uipc_sockbuf.c (local) @@ -1015,6 +1015,37 @@ } /* + * Return the first mbuf and the mbuf data offset for the provided + * send offset without changing the "sb_sndptroff" field. + */ +struct mbuf * +sbsndmbuf(struct sockbuf *sb, u_int off, u_int *moff) +{ + struct mbuf *m; + + KASSERT(sb->sb_mb != NULL, ("%s: sb_mb is NULL", __func__)); + + /* + * If the "off" is below the stored offset, which happens on + * retransmits, just use "sb_mb": + */ + if (sb->sb_sndptr == NULL || sb->sb_sndptroff > off) { + m = sb->sb_mb; + } else { + m = sb->sb_sndptr; + off -= sb->sb_sndptroff; + } + while (off > 0 && m != NULL) { + if (off < m->m_len) + break; + off -= m->m_len; + m = m->m_next; + } + *moff = off; + return (m); +} + +/* * Drop a record off the front of a sockbuf and move the next record to the * front. */ === sys/net/if.c ================================================================== --- sys/net/if.c (revision 271555) +++ sys/net/if.c (local) @@ -584,6 +584,57 @@ if_attach_internal(ifp, 0); } +/* + * Compute the least common TSO limit. + */ +void +if_hw_tsomax_common(if_t ifp, struct ifnet_hw_tsomax *pmax) +{ + /* + * 1) If there is no limit currently, take the limit from + * the network adapter. + * + * 2) If the network adapter has a limit below the current + * limit, apply it. + */ + if (pmax->tsomaxbytes == 0 || (ifp->if_hw_tsomax != 0 && + ifp->if_hw_tsomax < pmax->tsomaxbytes)) { + pmax->tsomaxbytes = ifp->if_hw_tsomax; + } + if (pmax->tsomaxsegcount == 0 || (ifp->if_hw_tsomaxsegcount != 0 && + ifp->if_hw_tsomaxsegcount < pmax->tsomaxsegcount)) { + pmax->tsomaxsegcount = ifp->if_hw_tsomaxsegcount; + } + if (pmax->tsomaxsegsize == 0 || (ifp->if_hw_tsomaxsegsize != 0 && + ifp->if_hw_tsomaxsegsize < pmax->tsomaxsegsize)) { + pmax->tsomaxsegsize = ifp->if_hw_tsomaxsegsize; + } +} + +/* + * Update TSO limit of a network adapter. + * + * Returns zero if no change. Else non-zero. + */ +int +if_hw_tsomax_update(if_t ifp, struct ifnet_hw_tsomax *pmax) +{ + int retval = 0; + if (ifp->if_hw_tsomax != pmax->tsomaxbytes) { + ifp->if_hw_tsomax = pmax->tsomaxbytes; + retval++; + } + if (ifp->if_hw_tsomaxsegsize != pmax->tsomaxsegsize) { + ifp->if_hw_tsomaxsegsize = pmax->tsomaxsegsize; + retval++; + } + if (ifp->if_hw_tsomaxsegcount != pmax->tsomaxsegcount) { + ifp->if_hw_tsomaxsegcount = pmax->tsomaxsegcount; + retval++; + } + return (retval); +} + static void if_attach_internal(struct ifnet *ifp, int vmove) { @@ -659,13 +710,36 @@ ifp->if_broadcastaddr = NULL; #if defined(INET) || defined(INET6) - /* Initialize to max value. */ - if (ifp->if_hw_tsomax == 0) - ifp->if_hw_tsomax = min(IP_MAXPACKET, 32 * MCLBYTES - + /* Use defaults for TSO, if nothing is set */ + if (ifp->if_hw_tsomax == 0 && + ifp->if_hw_tsomaxsegcount == 0 && + ifp->if_hw_tsomaxsegsize == 0) { + /* + * The TSO defaults needs to be such that an + * NFS mbuf list of 35 mbufs totalling just + * below 64K works and that a chain of mbufs + * can be defragged into at most 32 segments: + */ + ifp->if_hw_tsomax = min(IP_MAXPACKET, (32 * MCLBYTES) - (ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN)); - KASSERT(ifp->if_hw_tsomax <= IP_MAXPACKET && - ifp->if_hw_tsomax >= IP_MAXPACKET / 8, - ("%s: tsomax outside of range", __func__)); + ifp->if_hw_tsomaxsegcount = 35; + ifp->if_hw_tsomaxsegsize = 2048; /* 2K */ + + /* XXX some drivers set IFCAP_TSO after ethernet attach */ + if (ifp->if_capabilities & IFCAP_TSO) { + if_printf(ifp, "Using defaults for TSO: %u/%u/%u\n", + ifp->if_hw_tsomax, + ifp->if_hw_tsomaxsegcount, + ifp->if_hw_tsomaxsegsize); + } + } + /* + * If the "if_hw_tsomax" limit is set, check if it is + * too small: + */ + KASSERT(ifp->if_hw_tsomax == 0 || + ifp->if_hw_tsomax >= (IP_MAXPACKET / 8), + ("%s: if_hw_tsomax is outside of range", __func__)); #endif } #ifdef VIMAGE === sys/net/if_lagg.c ================================================================== --- sys/net/if_lagg.c (revision 271555) +++ sys/net/if_lagg.c (local) @@ -445,23 +445,18 @@ struct lagg_port *lp; int cap = ~0, ena = ~0; u_long hwa = ~0UL; -#if defined(INET) || defined(INET6) - u_int hw_tsomax = IP_MAXPACKET; /* Initialize to the maximum value. */ -#else - u_int hw_tsomax = ~0; /* if_hw_tsomax is only for INET/INET6, but.. */ -#endif + struct ifnet_hw_tsomax hw_tsomax; LAGG_WLOCK_ASSERT(sc); + memset(&hw_tsomax, 0, sizeof(hw_tsomax)); + /* Get capabilities from the lagg ports */ SLIST_FOREACH(lp, &sc->sc_ports, lp_entries) { cap &= lp->lp_ifp->if_capabilities; ena &= lp->lp_ifp->if_capenable; hwa &= lp->lp_ifp->if_hwassist; - /* Set to the minimum value of the lagg ports. */ - if (lp->lp_ifp->if_hw_tsomax < hw_tsomax && - lp->lp_ifp->if_hw_tsomax > 0) - hw_tsomax = lp->lp_ifp->if_hw_tsomax; + if_hw_tsomax_common(lp->lp_ifp, &hw_tsomax); } cap = (cap == ~0 ? 0 : cap); ena = (ena == ~0 ? 0 : ena); @@ -470,11 +465,10 @@ if (sc->sc_ifp->if_capabilities != cap || sc->sc_ifp->if_capenable != ena || sc->sc_ifp->if_hwassist != hwa || - sc->sc_ifp->if_hw_tsomax != hw_tsomax) { + if_hw_tsomax_update(sc->sc_ifp, &hw_tsomax) != 0) { sc->sc_ifp->if_capabilities = cap; sc->sc_ifp->if_capenable = ena; sc->sc_ifp->if_hwassist = hwa; - sc->sc_ifp->if_hw_tsomax = hw_tsomax; getmicrotime(&sc->sc_ifp->if_lastchange); if (sc->sc_ifflags & IFF_DEBUG) === sys/net/if_var.h ================================================================== --- sys/net/if_var.h (revision 271555) +++ sys/net/if_var.h (local) @@ -119,6 +119,12 @@ typedef int (*if_transmit_fn_t)(if_t, struct mbuf *); typedef uint64_t (*if_get_counter_t)(if_t, ifnet_counter); +struct ifnet_hw_tsomax { + u_int tsomaxbytes; /* TSO total burst length limit in bytes */ + u_int tsomaxsegcount; /* TSO maximum segment count */ + u_int tsomaxsegsize; /* TSO maximum segment size in bytes */ +}; + /* * Structure defining a network interface. * @@ -222,10 +228,11 @@ if_get_counter_t if_get_counter; /* get counter values */ /* Stuff that's only temporary and doesn't belong here. */ - u_int if_hw_tsomax; /* tso burst length limit, the minimum - * is (IP_MAXPACKET / 8). - * XXXAO: Have to find a better place - * for it eventually. */ + u_int if_hw_tsomax; /* TSO total burst length + * limit in bytes. A value of + * zero means no limit. Have + * to find a better place for + * it eventually. */ /* * Old, racy and expensive statistics, should not be used in * new drivers. @@ -243,6 +250,10 @@ uint64_t if_oqdrops; /* dropped on output */ uint64_t if_noproto; /* destined for unsupported protocol */ + /* TSO fields for segment limits. If a field is zero below, there is no limit. */ + u_int if_hw_tsomaxsegcount; /* TSO maximum segment count */ + u_int if_hw_tsomaxsegsize; /* TSO maximum segment size in bytes */ + /* * Spare fields to be added before branching a stable branch, so * that structure can be enhanced without changing the kernel @@ -615,5 +626,9 @@ int drbr_needs_enqueue_drv(if_t ifp, struct buf_ring *br); int drbr_enqueue_drv(if_t ifp, struct buf_ring *br, struct mbuf *m); +/* TSO */ +void if_hw_tsomax_common(if_t ifp, struct ifnet_hw_tsomax *); +int if_hw_tsomax_update(if_t ifp, struct ifnet_hw_tsomax *); + #endif /* _KERNEL */ #endif /* !_NET_IF_VAR_H_ */ === sys/net/if_vlan.c ================================================================== --- sys/net/if_vlan.c (revision 271555) +++ sys/net/if_vlan.c (local) @@ -1531,6 +1531,7 @@ { struct ifnet *p = PARENT(ifv); struct ifnet *ifp = ifv->ifv_ifp; + struct ifnet_hw_tsomax hw_tsomax; TRUNK_LOCK_ASSERT(TRUNK(ifv)); @@ -1557,8 +1558,9 @@ * propagate the hardware-assisted flag. TSO on VLANs * does not necessarily require hardware VLAN tagging. */ - if (p->if_hw_tsomax > 0) - ifp->if_hw_tsomax = p->if_hw_tsomax; + memset(&hw_tsomax, 0, sizeof(hw_tsomax)); + if_hw_tsomax_common(p, &hw_tsomax); + if_hw_tsomax_update(ifp, &hw_tsomax); if (p->if_capabilities & IFCAP_VLAN_HWTSO) ifp->if_capabilities |= p->if_capabilities & IFCAP_TSO; if (p->if_capenable & IFCAP_VLAN_HWTSO) { === sys/netinet/tcp_input.c ================================================================== --- sys/netinet/tcp_input.c (revision 271555) +++ sys/netinet/tcp_input.c (local) @@ -3618,6 +3618,8 @@ if (cap.ifcap & CSUM_TSO) { tp->t_flags |= TF_TSO; tp->t_tsomax = cap.tsomax; + tp->t_tsomaxsegcount = cap.tsomaxsegcount; + tp->t_tsomaxsegsize = cap.tsomaxsegsize; } } === sys/netinet/tcp_output.c ================================================================== --- sys/netinet/tcp_output.c (revision 271555) +++ sys/netinet/tcp_output.c (local) @@ -767,28 +767,113 @@ flags &= ~TH_FIN; if (tso) { + u_int if_hw_tsomax; + u_int if_hw_tsomaxsegcount; + u_int if_hw_tsomaxsegsize; + struct mbuf *mb; + u_int moff; + int max_len; + + /* extract TSO information */ + if_hw_tsomax = tp->t_tsomax; + if_hw_tsomaxsegcount = tp->t_tsomaxsegcount; + if_hw_tsomaxsegsize = tp->t_tsomaxsegsize; + + /* + * Limit a TSO burst to prevent it from + * overflowing or exceeding the maximum length + * allowed by the network interface: + */ KASSERT(ipoptlen == 0, ("%s: TSO can't do IP options", __func__)); /* - * Limit a burst to t_tsomax minus IP, - * TCP and options length to keep ip->ip_len - * from overflowing or exceeding the maximum - * length allowed by the network interface. + * Check if we should limit by maximum payload + * length: */ - if (len > tp->t_tsomax - hdrlen) { - len = tp->t_tsomax - hdrlen; - sendalot = 1; + if (if_hw_tsomax != 0) { + /* compute maximum TSO length */ + max_len = (if_hw_tsomax - hdrlen); + if (max_len <= 0) { + len = 0; + } else if (len > (u_int)max_len) { + sendalot = 1; + len = (u_int)max_len; + } } /* + * Check if we should limit by maximum segment + * size and count: + */ + if (if_hw_tsomaxsegcount != 0 && if_hw_tsomaxsegsize != 0) { + max_len = 0; + mb = sbsndmbuf(&so->so_snd, off, &moff); + + while (mb != NULL && (u_int)max_len < len) { + u_int cur_length; + u_int cur_frags; + + /* + * Get length of mbuf fragment + * and how many hardware + * frags, rounded up, it would + * use: + */ + cur_length = (mb->m_len - moff); + cur_frags = (cur_length + if_hw_tsomaxsegsize - + 1) / if_hw_tsomaxsegsize; + + /* Handle special case: Zero Length Mbuf */ + if (cur_frags == 0) + cur_frags = 1; + + /* + * Check if the fragment limit + * will be reached or + * exceeded: + */ + if (cur_frags >= if_hw_tsomaxsegcount) { + max_len += min(cur_length, + if_hw_tsomaxsegcount * + if_hw_tsomaxsegsize); + break; + } + max_len += cur_length; + if_hw_tsomaxsegcount -= cur_frags; + moff = 0; + mb = mb->m_next; + } + if (max_len <= 0) { + len = 0; + } else if (len > (u_int)max_len) { + sendalot = 1; + len = (u_int)max_len; + } + } + + /* * Prevent the last segment from being - * fractional unless the send sockbuf can - * be emptied. + * fractional unless the send sockbuf can be + * emptied: */ - if (sendalot && off + len < so->so_snd.sb_cc) { - len -= len % (tp->t_maxopd - optlen); + max_len = (tp->t_maxopd - optlen); + if ((off + len) < so->so_snd.sb_cc) { + moff = len % (u_int)max_len; + if (moff != 0) { + len -= moff; + sendalot = 1; + } + } + + /* + * In case there are too many small fragments + * don't use TSO: + */ + if (len <= (u_int)max_len) { + len = (u_int)max_len; sendalot = 1; + tso = 0; } /* === sys/netinet/tcp_subr.c ================================================================== --- sys/netinet/tcp_subr.c (revision 271555) +++ sys/netinet/tcp_subr.c (local) @@ -1819,6 +1819,8 @@ ifp->if_hwassist & CSUM_TSO) { cap->ifcap |= CSUM_TSO; cap->tsomax = ifp->if_hw_tsomax; + cap->tsomaxsegcount = ifp->if_hw_tsomaxsegcount; + cap->tsomaxsegsize = ifp->if_hw_tsomaxsegsize; } } RTFREE(sro.ro_rt); @@ -1858,6 +1860,8 @@ ifp->if_hwassist & CSUM_TSO) { cap->ifcap |= CSUM_TSO; cap->tsomax = ifp->if_hw_tsomax; + cap->tsomaxsegcount = ifp->if_hw_tsomaxsegcount; + cap->tsomaxsegsize = ifp->if_hw_tsomaxsegsize; } } RTFREE(sro6.ro_rt); === sys/netinet/tcp_var.h ================================================================== --- sys/netinet/tcp_var.h (revision 271555) +++ sys/netinet/tcp_var.h (local) @@ -199,9 +199,12 @@ u_int t_keepintvl; /* interval between keepalives */ u_int t_keepcnt; /* number of keepalives before close */ - u_int t_tsomax; /* tso burst length limit */ + u_int t_tsomax; /* TSO total burst length limit in bytes */ - uint32_t t_ispare[8]; /* 5 UTO, 3 TBD */ + uint32_t t_ispare[6]; /* 5 UTO, 1 TBD */ + uint32_t t_tsomaxsegcount; /* TSO maximum segment count */ + uint32_t t_tsomaxsegsize; /* TSO maximum segment size in bytes */ + void *t_pspare2[4]; /* 1 TCP_SIGNATURE, 3 TBD */ uint64_t _pad[6]; /* 6 TBD (1-2 CC/RTT?) */ }; @@ -324,6 +327,8 @@ struct tcp_ifcap { int ifcap; u_int tsomax; + u_int tsomaxsegcount; + u_int tsomaxsegsize; }; #ifndef _NETINET_IN_PCB_H_ === sys/ofed/drivers/net/mlx4/en_netdev.c ================================================================== --- sys/ofed/drivers/net/mlx4/en_netdev.c (revision 271555) +++ sys/ofed/drivers/net/mlx4/en_netdev.c (local) @@ -673,6 +673,11 @@ else priv->rx_csum = 0; + /* set TSO limits so that we don't have to drop TX packets */ + dev->if_hw_tsomax = 65536 - (ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN); + dev->if_hw_tsomaxsegcount = 16; + dev->if_hw_tsomaxsegsize = 65536; /* XXX can do up to 4GByte */ + err = mlx4_wol_read(priv->mdev->dev, &config, priv->port); if (err) { en_err(priv, "Failed to get WoL info, unable to modify\n"); === sys/sys/sockbuf.h ================================================================== --- sys/sys/sockbuf.h (revision 271555) +++ sys/sys/sockbuf.h (local) @@ -158,6 +158,8 @@ struct thread *td); struct mbuf * sbsndptr(struct sockbuf *sb, u_int off, u_int len, u_int *moff); +struct mbuf * + sbsndmbuf(struct sockbuf *sb, u_int off, u_int *moff); void sbtoxsockbuf(struct sockbuf *sb, struct xsockbuf *xsb); int sbwait(struct sockbuf *sb); int sblock(struct sockbuf *sb, int flags); --------------090208020808030909020008-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 18:12:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 510275F8; Fri, 19 Sep 2014 18:12:51 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D42BD829; Fri, 19 Sep 2014 18:12:50 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XV2fo-003ngE-Iv>; Fri, 19 Sep 2014 20:12:48 +0200 Received: from f052162237.adsl.alicedsl.de ([78.52.162.237] helo=hermann.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XV2fo-001I8u-FI>; Fri, 19 Sep 2014 20:12:48 +0200 Date: Fri, 19 Sep 2014 20:12:10 +0200 From: "O. Hartmann" To: freebsd-x11@freebsd.org, FreeBSD CURRENT Subject: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT Message-ID: <20140919201210.72650231.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/B6QkEIf5oqug.T8bKvEs2Hf"; protocol="application/pgp-signature" X-Originating-IP: 78.52.162.237 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 18:12:51 -0000 --Sig_/B6QkEIf5oqug.T8bKvEs2Hf Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable nVidia's BLOB from port x11/nvidia-driver seems to have problems in FreeBSD= 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo ThinkPad Edge E5= 40 laptop with CPU i5-4200M (Haswell) with integrated HD4600 Intel iGPU and dedicated nVid= ia GT 740M (Optimus) working correctly. The systems boots FreeBSD off via UEFI. First of all: I tried versions 340.24, 340.32 and Beta 343.13 all with the = very same results. Symptoms: a) Loading kernel module "nvidia" via /boot/load.conf freezes the system af= ter the UEFI/EFI loader message shows up. Loading the kernel module vi kld_load=3D in /etc/rc.conf[.local] works so far regarding loading and booting the kern= el. b) No display socket is recognized by the nvidia driver resulting in a blan= k vt() screen after X has been started. I tried many different configurations, but at the= end I suspect that nVidia's "Optimus" technology may be the culprit. The documentation of nVidia's driver for FreeBSD states that after the Xser= ver has started it logs in Xorg.0.log (or whatever display number is used) the avai= lable display sockets like (taken from the documents): (--) NVIDIA(0): Valid display device(s) on Quadro 6000 at PCI:10:0:0 (--) NVIDIA(0): CRT-0 (--) NVIDIA(0): CRT-1 (--) NVIDIA(0): DELL U2410 (DFP-0) (connected) (--) NVIDIA(0): NEC LCD1980SXi (DFP-1) (connected) Nothing that similar shows up in my environment, but this: [...] [ 58.656] (--) PCI:*(0:0:2:0) 8086:0416:17aa:502a rev 6, Mem @ 0xf100000= 0/4194304, 0xe0000000/268435456, I/O @ 0x00006000/64, BIOS @ 0x????????/65536 [ 58.659] (--) PCI: (0:1:0:0) 10de:1292:17aa:502a rev 161, Mem @ 0xf0000= 000/16777216, 0xc0000000/268435456, 0xd0000000/33554432, I/O @ 0x00005000/128 [ 58.662] (II) "extmod" will be loaded. This was enabled by default and = also specified in the config file. [ 58.662] (II) "dbe" will be loaded. This was enabled by default and als= o specified in the config file. [...] [ 60.055] (**) NVIDIA(0): Enabling 2D acceleration [ 60.485] (II) NVIDIA(0): NVIDIA GPU GeForce GT 740M (GK208) at PCI:1:0:= 0 (GPU-0) [ 60.486] (--) NVIDIA(0): Memory: 2097152 kBytes [ 60.486] (--) NVIDIA(0): VideoBIOS: 80.28.25.00.27 [ 60.486] (II) NVIDIA(0): Detected PCI Express Link width: 8X [ 60.486] (--) NVIDIA(0): Valid display device(s) on GeForce GT 740M at = PCI:1:0:0 [ 60.487] (--) NVIDIA(0): none [ 60.487] (II) NVIDIA(0): Validated MetaModes: [ 60.487] (II) NVIDIA(0): "NULL" [ 60.487] (II) NVIDIA(0): Virtual screen size determined to be 640 x 480 [ 60.488] (WW) NVIDIA(0): Unable to get display device for DPI computati= on. [ 60.488] (=3D=3D) NVIDIA(0): DPI set to (75, 75); computed from built-i= n default [ 60.488] (--) Depth 24 pixmap format is 32 bpp [ 60.489] (II) NVIDIA: Reserving 3072.00 MB of virtual memory for indire= ct memory [ 60.489] (II) NVIDIA: access. [ 60.492] (II) NVIDIA(0): Setting mode "NULL" [ 60.493] (EE) NVIDIA(0): Failed to initiate mode change. [ 60.493] (EE) NVIDIA(0): Failed to complete mode change [ 60.553] (II) NVIDIA(0): Built-in logo is bigger than the screen. [ 60.573] (II) Loading extension NV-GLX [...] Confusing is that in the lines [ 58.656] (--) PCI:*(0:0:2:0) 8086:0416:17aa:502a rev 6, Mem @ 0xf100000= 0/4194304, 0xe0000000/268435456, I/O @ 0x00006000/64, BIOS @ 0x????????/65536 [ 58.659] (--) PCI: (0:1:0:0) 10de:1292:17aa:502a rev 161, Mem @ 0xf0000= 000/16777216, 0xc0000000/268435456, 0xd0000000/33554432, I/O @ 0x00005000/128 both, the Intel iGPU HD4600 (PCI:*(0:0:2:0)) and the nVidia dedicated GPU G= T=20 740M (PCI: (0:1:0:0)) show up. The more scaring part is then (--) NVIDIA(0): Valid display device(s): No display device is shown although the notebook has a built-in display, a = DisplayPort port as well as a VGA port. On all nVidia dedicated graphics boards I use o= n diffrent other machines with the very same driver EVERY possible connector/socket sh= ows up. The laptop has EFI/UEFI EFI Version: 2.31 EFI Firmware: Lenovo (re. 05648) The problem is present no matter whether the drm2 and i915kms kernel moules= are loaded or not. What is wrong here? Any chance to get the nVidia GPU to work? I use at the = moment xf86-video-scfb which is a pain in the ass and absolutely not usable, even = with a faster CPU. Under average load the whole laptop screen is like a slide show. Please CC me. Thanks in advance, O. Hartmann --Sig_/B6QkEIf5oqug.T8bKvEs2Hf Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUHHIAAAoJEOgBcD7A/5N868AIAKw638uX1D0x+Qyys3sR9ARI gv+yShpQib6wTmn9b3xQpIvUu+f1DVjwEsiIIw5M/YMfwNXg2Dcnzvg6tprjjOVf bTuE8ypdbRN57YrArdy116hxjhu8h9D424a2Tm3bVeOkF2z5FXTu0G1UhM1RbHJT NKPfHJe2CXLq9QCIqjikMo1BoRS8piG0fKq1G6XaLv1gohPYXfnR8CyoayiZMQAw x5aNpTfvwhh092tryCfkIqlkbLtHgG5op6cMiSkyeCUXst8VursedwniHoq70m8l 5L9aMUGop5zXDLpC2h1naia9jNGnwbMi2O8/dSvI9j9DTKyRkY4wj1C448UpWEY= =NlDw -----END PGP SIGNATURE----- --Sig_/B6QkEIf5oqug.T8bKvEs2Hf-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 18:24:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD20BBB2; Fri, 19 Sep 2014 18:24:13 +0000 (UTC) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 56281940; Fri, 19 Sep 2014 18:24:13 +0000 (UTC) Received: by mail-vc0-f169.google.com with SMTP id id10so1189649vcb.0 for ; Fri, 19 Sep 2014 11:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SnZw+mV85guqSx5G4m1eUhhy/TfmIMWrUhe1Eaa9cn4=; b=LAG3tIccVRiRnZuT7V1cE19a5GGosdAbph/e4iHqrdvjfnpTSx5l/sY5iCDkvhoq0D BCvIwnGL1BqrZp3puEGZfHUA2EwHrOno5833SeCk7qVSF+AQPJKEbq/xOU8klfy5sVm2 d9cRDxEN4YF7CCu4eq7NQQ0LCUJVDkulYY/NC5rxMJ7Vy77yzBZsuoOqS2wtiMXki9E1 0GeeoBRgcoMOqpq8aBcHyerkgq+Jf4FVQcqcpKBvYcBQsr2Gt5ygVbWpMn5pYGdyJiYn qezxrzq0NloiNc6lk00JrenmlZKfqaX383k3RTwSrw3vavKRfvJwbbizMvO9JqrTRcRv r4Gg== X-Received: by 10.221.49.133 with SMTP id va5mr939339vcb.37.1411151052331; Fri, 19 Sep 2014 11:24:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.16.7 with HTTP; Fri, 19 Sep 2014 11:23:32 -0700 (PDT) In-Reply-To: <20140919201210.72650231.ohartman@zedat.fu-berlin.de> References: <20140919201210.72650231.ohartman@zedat.fu-berlin.de> From: Henry Hu Date: Fri, 19 Sep 2014 14:23:32 -0400 Message-ID: Subject: Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT To: "O. Hartmann" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-x11@freebsd.org" , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 18:24:13 -0000 On Fri, Sep 19, 2014 at 2:12 PM, O. Hartmann wrote: > nVidia's BLOB from port x11/nvidia-driver seems to have problems in > FreeBSD 11.0-CURRENT > #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo ThinkPad Edge > E540 laptop with > CPU i5-4200M (Haswell) with integrated HD4600 Intel iGPU and dedicated > nVidia GT 740M > (Optimus) working correctly. > > The systems boots FreeBSD off via UEFI. > > First of all: I tried versions 340.24, 340.32 and Beta 343.13 all with the > very same > results. > > Symptoms: > > a) Loading kernel module "nvidia" via /boot/load.conf freezes the system > after the > UEFI/EFI loader message shows up. Loading the kernel module vi kld_load= > in /etc/rc.conf[.local] works so far regarding loading and booting the > kernel. > > b) No display socket is recognized by the nvidia driver resulting in a > blank vt() screen > after X has been started. I tried many different configurations, but at > the end I suspect > that nVidia's "Optimus" technology may be the culprit. > > The documentation of nVidia's driver for FreeBSD states that after the > Xserver has > started it logs in Xorg.0.log (or whatever display number is used) the > available display > sockets like (taken from the documents): > > (--) NVIDIA(0): Valid display device(s) on Quadro 6000 at PCI:10:0:0 > (--) NVIDIA(0): CRT-0 > (--) NVIDIA(0): CRT-1 > (--) NVIDIA(0): DELL U2410 (DFP-0) (connected) > (--) NVIDIA(0): NEC LCD1980SXi (DFP-1) (connected) > > Nothing that similar shows up in my environment, but this: > > [...] > [ 58.656] (--) PCI:*(0:0:2:0) 8086:0416:17aa:502a rev 6, Mem @ > 0xf1000000/4194304, > 0xe0000000/268435456, I/O @ 0x00006000/64, BIOS @ 0x????????/65536 > [ 58.659] (--) PCI: (0:1:0:0) 10de:1292:17aa:502a rev 161, Mem @ > 0xf0000000/16777216, > 0xc0000000/268435456, 0xd0000000/33554432, I/O @ 0x00005000/128 > [ 58.662] (II) "extmod" will be loaded. This was enabled by default and > also specified > in the config file. > [ 58.662] (II) "dbe" will be loaded. This was enabled by default and > also specified in > the config file. > [...] > [ 60.055] (**) NVIDIA(0): Enabling 2D acceleration > [ 60.485] (II) NVIDIA(0): NVIDIA GPU GeForce GT 740M (GK208) at > PCI:1:0:0 (GPU-0) > [ 60.486] (--) NVIDIA(0): Memory: 2097152 kBytes > [ 60.486] (--) NVIDIA(0): VideoBIOS: 80.28.25.00.27 > [ 60.486] (II) NVIDIA(0): Detected PCI Express Link width: 8X > [ 60.486] (--) NVIDIA(0): Valid display device(s) on GeForce GT 740M at > PCI:1:0:0 > [ 60.487] (--) NVIDIA(0): none > [ 60.487] (II) NVIDIA(0): Validated MetaModes: > [ 60.487] (II) NVIDIA(0): "NULL" > [ 60.487] (II) NVIDIA(0): Virtual screen size determined to be 640 x 480 > [ 60.488] (WW) NVIDIA(0): Unable to get display device for DPI > computation. > [ 60.488] (==) NVIDIA(0): DPI set to (75, 75); computed from built-in > default > [ 60.488] (--) Depth 24 pixmap format is 32 bpp > [ 60.489] (II) NVIDIA: Reserving 3072.00 MB of virtual memory for > indirect memory > [ 60.489] (II) NVIDIA: access. > [ 60.492] (II) NVIDIA(0): Setting mode "NULL" > [ 60.493] (EE) NVIDIA(0): Failed to initiate mode change. > [ 60.493] (EE) NVIDIA(0): Failed to complete mode change > [ 60.553] (II) NVIDIA(0): Built-in logo is bigger than the screen. > [ 60.573] (II) Loading extension NV-GLX > [...] > > Confusing is that in the lines > [ 58.656] (--) PCI:*(0:0:2:0) 8086:0416:17aa:502a rev 6, Mem @ > 0xf1000000/4194304, > 0xe0000000/268435456, I/O @ 0x00006000/64, BIOS @ 0x????????/65536 > [ 58.659] (--) PCI: (0:1:0:0) 10de:1292:17aa:502a rev 161, Mem @ > 0xf0000000/16777216, > 0xc0000000/268435456, 0xd0000000/33554432, I/O @ 0x00005000/128 > > both, the Intel iGPU HD4600 (PCI:*(0:0:2:0)) and the nVidia dedicated GPU > GT > 740M (PCI: (0:1:0:0)) show up. > > The more scaring part is then (--) NVIDIA(0): Valid display device(s): > > No display device is shown although the notebook has a built-in display, a > DisplayPort > port as well as a VGA port. On all nVidia dedicated graphics boards I use > on diffrent > other machines with the very same driver EVERY possible connector/socket > shows up. > > The laptop has EFI/UEFI > > EFI Version: 2.31 > EFI Firmware: Lenovo (re. 05648) > > The problem is present no matter whether the drm2 and i915kms kernel > moules are loaded or > not. > > What is wrong here? Any chance to get the nVidia GPU to work? I use at the > moment > xf86-video-scfb which is a pain in the ass and absolutely not usable, even > with a faster > CPU. Under average load the whole laptop screen is like a slide show. > > Please CC me. > My laptop has an integrated graphics (HD4000) and a nvidia GPU (GT650M). It also has optimus. It has a VGA output, a HDMI output, and the internal LCD. Using the intel driver, I can use the internal LCD and VGA. Using the nvidia driver, I can use the HDMI. To use the nvidia driver, I have to use acpi_call to turn on or initialize the nvidia card first. My guess is that my HDMI port is conencted to the nvidia card, and maybe all the ports on your system are connected to the intel card. It's also possible that your nvidia card also need some acpi function calls to start. You may try some linux distro which has the driver for your intel graphics and check Xorg's log. > Thanks in advance, > O. Hartmann > -- Cheers, Henry From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 20:23:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C4169B4 for ; Fri, 19 Sep 2014 20:23:26 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D5492658 for ; Fri, 19 Sep 2014 20:23:25 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 485DEB94F for ; Fri, 19 Sep 2014 16:23:24 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: [PATCH] Convert bluetooth from timeout(9) to callout(9) Date: Fri, 19 Sep 2014 16:18:46 -0400 Message-ID: <25731067.8WGIlPIxa9@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Sep 2014 16:23:24 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 20:23:26 -0000 This patch converts the netgraph bluetooth codee from timeout(9) to callout(9). The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/bluetooth_callout.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 20:23:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89FCF9B5; Fri, 19 Sep 2014 20:23:26 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 57F9E65A; Fri, 19 Sep 2014 20:23:26 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0C3C1B962; Fri, 19 Sep 2014 16:23:25 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: [PATCH] Lock scsi_low, ct(4), ncv(4), nsp(4), stg(4) Date: Fri, 19 Sep 2014 16:14:49 -0400 Message-ID: <3088945.ClF4RnPN3N@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Sep 2014 16:23:25 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 20:23:26 -0000 This patch adds locking to the scsi_low subsystem and the drivers that use it: ct(4), ncv(4), nsp(4), and stg(4). The drivers are all marked MPSAFE. The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/scsi_low_locking.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 20:23:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55B98ACF; Fri, 19 Sep 2014 20:23:28 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 25FAB65D; Fri, 19 Sep 2014 20:23:28 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DB549B97C; Fri, 19 Sep 2014 16:23:26 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: [PATCH] Various fixes to wl(4) Date: Fri, 19 Sep 2014 16:07:25 -0400 Message-ID: <1815820.OytfPhNq3X@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Sep 2014 16:23:26 -0400 (EDT) Cc: imp@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 20:23:28 -0000 This patch fixes various issues in wl(4) including: - Use bus_space instead of inb/outb. - Use device_printf() and if_printf() - Use callout(9) instead of timeout(9) - Don't hold the driver lock across sleeping actions like bus_teardown_intr(), subyte(), etc. - Don't recurse on the driver lock. The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/wl_cleanup.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 20:23:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B07D8A30 for ; Fri, 19 Sep 2014 20:23:27 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 81ACF65C for ; Fri, 19 Sep 2014 20:23:27 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DA72EB976 for ; Fri, 19 Sep 2014 16:23:25 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: [PATCH] Lock spic(4) Date: Fri, 19 Sep 2014 16:08:38 -0400 Message-ID: <2231383.OLv6VGWtvi@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Sep 2014 16:23:25 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 20:23:27 -0000 This patch adds locking to spic(4) and marks it MPSAFE. The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/spic_locking.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 20:23:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E335C65 for ; Fri, 19 Sep 2014 20:23:30 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EBF0665F for ; Fri, 19 Sep 2014 20:23:29 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E55E7B962 for ; Fri, 19 Sep 2014 16:23:28 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: [PATCH] Lock wds(4) Date: Fri, 19 Sep 2014 15:59:45 -0400 Message-ID: <4128699.mglixFdx6C@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Sep 2014 16:23:29 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 20:23:30 -0000 This patch adds locking to wds(4) and marks it MPSAFE. It also includes several other cleanups such as using bus_space instead of inb/outb. The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/wds_locking.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 20:23:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96650C18; Fri, 19 Sep 2014 20:23:29 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 708D465E; Fri, 19 Sep 2014 20:23:29 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EBC33B94F; Fri, 19 Sep 2014 16:23:27 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: [PATCH] Convert tws(4) from timeout(9) to callout(9) Date: Fri, 19 Sep 2014 16:00:59 -0400 Message-ID: <4640501.ntuiclX9yU@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Sep 2014 16:23:28 -0400 (EDT) Cc: delphij@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 20:23:29 -0000 This patch converts tws(4) from timeout(9) to callout(9). It also fixes a few places that were tearing down and setting up in the interrupt handler where it was not safe to do so and adds some missing teardown actions. The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/tws_callout.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 20:23:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03074CDE for ; Fri, 19 Sep 2014 20:23:31 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB345660 for ; Fri, 19 Sep 2014 20:23:30 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id ACEE5B97C for ; Fri, 19 Sep 2014 16:23:29 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: [PATCH] Fix si(4) to use bus_space Date: Fri, 19 Sep 2014 15:52:48 -0400 Message-ID: <1592656.vEZ1VDPFUt@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Sep 2014 16:23:29 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 20:23:31 -0000 This patch fixes the si(4) driver to use the bus_space methods to access memory and I/O resources instead of directly calling inb()/outb() and using rman_get_virtual(). The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/si_bus_space.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 20:23:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2222FED8 for ; Fri, 19 Sep 2014 20:23:33 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F12D4664 for ; Fri, 19 Sep 2014 20:23:32 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CB1F4B962 for ; Fri, 19 Sep 2014 16:23:31 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: [PATCH] Fix callouts in rp(4) Date: Fri, 19 Sep 2014 15:46:07 -0400 Message-ID: <2868019.vH6yQQC2gz@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Sep 2014 16:23:31 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 20:23:33 -0000 This patch converts rp(4) from timeout(9) to callout(9). To do this cleanly, it replaces a single, global timer that walks tables of controllers and ports to a per-controller timer. This works much better with locking (since the locks are per-controller) and removes the need for various global lookup tables in the driver. The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/rp_callout.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 20:23:34 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15F26F80 for ; Fri, 19 Sep 2014 20:23:34 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5B3B665 for ; Fri, 19 Sep 2014 20:23:33 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B3F3AB9CE for ; Fri, 19 Sep 2014 16:23:32 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: [PATCH] Lock mse(4) Date: Fri, 19 Sep 2014 15:42:08 -0400 Message-ID: <2736208.I8bkODsJvN@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Sep 2014 16:23:32 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 20:23:34 -0000 This patch adds locking to mse(4) and marks it MPSAFE. It also adds some other cleanups such as using bus_*() instead of bus_space_*() and consolidating duplicate copies of its detach routine. The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/mse_locking.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 20:23:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 430A2DEA for ; Fri, 19 Sep 2014 20:23:32 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 14991662 for ; Fri, 19 Sep 2014 20:23:32 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DA15CB94F for ; Fri, 19 Sep 2014 16:23:30 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: [PATCH] Lock scd(4) Date: Fri, 19 Sep 2014 15:48:56 -0400 Message-ID: <5673476.ZVmTjCpyXE@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Sep 2014 16:23:30 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 20:23:32 -0000 This patch adds locking to scd(4) and marks it MPSAFE. It also uses bus_*() instead of bus_space_*(). The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/scd_locking.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 20:23:35 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D1759B for ; Fri, 19 Sep 2014 20:23:35 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CD738668 for ; Fri, 19 Sep 2014 20:23:34 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9F2C2B976; Fri, 19 Sep 2014 16:23:33 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: libthr and main thread stack size Date: Fri, 19 Sep 2014 15:27:25 -0400 Message-ID: <5242716.s4iaScq0Bu@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: <20140916081324.GQ2737@kib.kiev.ua> References: <53E36E84.4060806@ivan-labs.com> <20140916081324.GQ2737@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Sep 2014 16:23:33 -0400 (EDT) Cc: Konstantin Belousov , "Ivan A. Kosarev" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 20:23:35 -0000 On Tuesday, September 16, 2014 11:13:24 AM Konstantin Belousov wrote: > On Mon, Sep 15, 2014 at 03:47:41PM -0600, Justin T. Gibbs wrote: > > On Aug 8, 2014, at 5:22 AM, Konstantin Belousov > > wrote: > > > > ? > > > > > Below is the patch which adds environment variable > > > LIBPTHREAD_BIGSTACK_MAIN. Setting it to any value results in the > > > main thread stack left as is, and other threads allocate stack > > > below the area of RLIMIT_STACK. Try it. I do not want to set this > > > behaviour as default. > > > > Is there a reason this should not be the default? Looking at the > > getrlimit() page on the OpenGroup?s site they say: > > > > RLIMIT_STACK This is the maximum size of the initial thread's stack, > > in bytes. The implementation does not automatically grow the stack > > beyond this limit. If this limit is exceeded, SIGSEGV shall be > > generated for the thread. If the thread is blocking SIGSEGV, or the > > process is ignoring or catching SIGSEGV and has not made arrangements > > to use an alternate stack, the disposition of SIGSEGV shall be set to > > SIG_DFL before it is generated. > > > > Does posix say something different? > > > > I ran into this issue when debugging a segfault on Postgres when > > running an (arguably quite bogus) query that should have fit within > > both the configured stack rlimit and Postgres? configured stack limit. > > The Postgres backend is really just single threaded, but happens > > to pull in libpthread due to the threading support in some of the > > libraries it uses. The segfault definitely violates POLA. > > > > ? Justin > > I am conservative to not disturb the address space layout in single go. > If enough people test this setting, I can consider flipping the default > to the reverse. > > I am still curious why the things were done in this way, but nobody > replied. I suspect it was done out of reasons of being overly conservative in interpreting RLIMIT_STACK. I think it is quite surprising behavior though and would rather we make your option the default and implement what the Open Group says above. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 20:29:01 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE1A85D0; Fri, 19 Sep 2014 20:29:01 +0000 (UTC) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E3A4765; Fri, 19 Sep 2014 20:29:01 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id jd19so2207853oac.9 for ; Fri, 19 Sep 2014 13:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2DuVJOuDQ3OgNAvcZwyyKkRrfuWn4OgeJMTVLpB6/qM=; b=tNCmIFa+T9QAq8fQajjAI8eIvxSeYRpFun4WZryjCfQ+Nj8mv+IVIXjA+0YWg2KfeM 5Lz9yLculentXL8reftG2135+5wb+PTl/IbEolFjCeu6bfAsqlt1wP+wsWHB2KTwbZys JDR6MIGnHIFnJca+GqtF00nWHcZ6recbHC7aG9vBJRvn2mFqB6GJCvcgSXEqy3xbIMWC ENHw2gGfaSkEEtY9DvJgcprFoY1fLqk2rdIglpb4GtKX0D40caw2DQ7LOWKYQrVDF333 dPycR5GFIxndoUFAZX6yZ1eIbbd0EHfCFDaq0jR5zYLA6tgkiB0kN/OQpELj6eiqKUdY 8xlw== MIME-Version: 1.0 X-Received: by 10.60.60.131 with SMTP id h3mr3850457oer.17.1411158540727; Fri, 19 Sep 2014 13:29:00 -0700 (PDT) Received: by 10.76.82.74 with HTTP; Fri, 19 Sep 2014 13:29:00 -0700 (PDT) In-Reply-To: <25731067.8WGIlPIxa9@ralph.baldwin.cx> References: <25731067.8WGIlPIxa9@ralph.baldwin.cx> Date: Fri, 19 Sep 2014 13:29:00 -0700 Message-ID: Subject: Re: [PATCH] Convert bluetooth from timeout(9) to callout(9) From: Maksim Yevmenkin To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 20:29:01 -0000 On Fri, Sep 19, 2014 at 1:18 PM, John Baldwin wrote: > This patch converts the netgraph bluetooth codee from timeout(9) to > callout(9). The patch is against HEAD but probably applies to 9 and 10 as > well. > > http://people.freebsd.org/~jhb/patches/bluetooth_callout.patch looks fine to me. thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 21:47:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C90E8F7 for ; Fri, 19 Sep 2014 21:47:27 +0000 (UTC) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B49EE89 for ; Fri, 19 Sep 2014 21:47:27 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id ft15so694868pdb.23 for ; Fri, 19 Sep 2014 14:47:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=4KEmHV9X+q0EPQhgt8m+qXx7xTsX63br+zLLxLtTG8I=; b=kJQNdGGtKhxiYvXNhmIOBWXVl+b04NmJEDWSja37JCWxdEiXKEBgPwHnDHqXBo5iru s2DDTDeg0l2R5XtxbkYU5vLcLfae79v8NxVQ0xZPLvqlcGHxwHUqiHyO8z0EDt05AahT cdqE1NcgsAfN0wRGi3Y8tMU4dudJwsf0L+0clCS/dcMs3vck9ELD3oyU/G0HGxmil/hI jQWO7+y1Kn1rPIVzZcNebzl7Yo/lC90khli3ZDEp3+DT55ZpGMJDAlHE1MLeyKaB3uJ/ RO33GUQsY8O3yZjJ1zVbuXSS2XEIrnA1jBM2snsKHEfxF56OgPkrk+Es+ubdbpZHbTya pSUw== X-Gm-Message-State: ALoCoQl7Ndg/zXkGj+Qy5iLJW0MG4eAwB6wUsRK+0UA47Ob4vHKzNmY8TlmH48yAEjx/myn/oQ2Y X-Received: by 10.70.43.100 with SMTP id v4mr3892083pdl.108.1411163241036; Fri, 19 Sep 2014 14:47:21 -0700 (PDT) Received: from lgmac-tgooch.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id f2sm2748903pdd.25.2014.09.19.14.47.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Sep 2014 14:47:20 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_3E8D7A9E-E717-4A49-B629-228A0B1FA39B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [PATCH] Various fixes to wl(4) From: Warner Losh In-Reply-To: <1815820.OytfPhNq3X@ralph.baldwin.cx> Date: Fri, 19 Sep 2014 15:47:16 -0600 Message-Id: <4D1FD834-2861-4D16-9ABF-21B8B07561F8@bsdimp.com> References: <1815820.OytfPhNq3X@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@freebsd.org, imp@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 21:47:27 -0000 --Apple-Mail=_3E8D7A9E-E717-4A49-B629-228A0B1FA39B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I got rid of my pre-802.11 WaveLAN cards about 8 years go after not = having them in a system at all for 8 years. And they were about 4 years = obsolete when I took them out of service=85 I=92m not even sure I have a = machine with an ISA slot to test the card, even if I still had it. Sorry I can=92t help more :) Warner On Sep 19, 2014, at 2:07 PM, John Baldwin wrote: > This patch fixes various issues in wl(4) including: >=20 > - Use bus_space instead of inb/outb. > - Use device_printf() and if_printf() > - Use callout(9) instead of timeout(9) > - Don't hold the driver lock across sleeping actions like > bus_teardown_intr(), subyte(), etc. > - Don't recurse on the driver lock. >=20 > The patch is against HEAD but probably applies to 9 and 10 as well. >=20 > http://people.freebsd.org/~jhb/patches/wl_cleanup.patch >=20 > --=20 > John Baldwin --Apple-Mail=_3E8D7A9E-E717-4A49-B629-228A0B1FA39B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUHKRkAAoJEGwc0Sh9sBEAuWkP/1I78UGIuXw36ko6iJ3EkoFW /amhi9yjBSWLIukSwXMcVj5c0AmbuBkdSZiwtppGwZ9NEg9+0q5z4troUX/4Cce8 1PeHf/o37PieO9lyMggQnUZF0qSe/L/NxPojMmKLThPcyE15kDLoQE8qU4FIvMoP UQYUvcOuPxwjIZ1lgahRbHAnwE3+vfCHrRYRY8L2wTeTXzXzO4/bcGGrC2TG9rik 6iEsc91b2Hru00HUVyI0WQthScdMw4sifuutmiFpNvj3jdofBPNfqKPT2s3HCb4K WJEUBdoBfcbBITWCGcBqzcoYBplhwhQwhPYgILS4wKXRbzlcbsZkDtUdKHYCVsrw r5An/ejRzHRMAxbh1BQ6vCG6yQfji6cE7hj3pFBLOBYVtNazeDuXOoPO2AWRkmRX f/PHl40NG8dk2615bPYgZtYloMptzO0btg6nds6e6LDFlBhaIcNX8tRJFtWKUrqU +30BnfpJGBnlBlQIjKrD56z4AlGiuQu7DDAHQEOYeVdELZ/qM+KGX1sScFqDPqf+ gXy5AjzXcCeK4wRXXCdgzf7c+CleyqJiEq6ywotTsdzwZDhumKO13ZVrAfDKlzT2 Z0+1nIFfWq2/ZXr68l1uoAsEc8w0DjwU8jyGJojb6sbEWWTy8sX8efsVUOpOQG+S GPGe8IYwVFJKKamAA6+L =FXvs -----END PGP SIGNATURE----- --Apple-Mail=_3E8D7A9E-E717-4A49-B629-228A0B1FA39B-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 04:49:42 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28A6E792 for ; Sat, 20 Sep 2014 04:49:42 +0000 (UTC) Received: from kefka.worrbase.com (unknown [IPv6:2620:8d:8000:e49:34eb:daa3:ee1c:daa0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C30C798E for ; Sat, 20 Sep 2014 04:49:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]); by kefka.worrbase.com (OpenSMTPD) with ESMTP id 976adda3; for ; Fri, 19 Sep 2014 21:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=worrbase.com; h= content-transfer-encoding:content-type:content-type:subject :subject:mime-version:user-agent:from:from:date:date:message-id :received:received; s=mail; t=1411188564; x=1413002965; bh=dy4ew BXnxgSvze6Rsa8NKCTak+pI1qIe5hWUEfGBswI=; b=jqNSHHLUhjt6V1L5RdQJK 64rc81Bw4gTTml9YhYaKCJ+XfOCOlM/NTyO8zhl3JYdwTzg82DhvP5/fDlI1Wj/G Yi7Vob6Ao9U9E+KrlhGwJakE7CkbbC4t+ePo+LRPKjr+LtCpPQVahtFEZ6tLmXj8 tz2rs+Lz4bbocpvy1XwW01tncJC0Xwf4vVcXNCntoJej1DFDhxQjQvt/PEkdQ3eB UXo4sFZq7nWIhvwiecpP/smMfwwbw3Po8f4Yo3ZFaXqfWuZAG15LmRSxpsFL2mZv wSzdQomP9RR+lj3c4nSHVTzarb8einbRlgzPfRZZwvsV7g5C/3v3KS/K5CrO6R9N xxua73kY5cD6AXEKBeh5wuSZuwL6+kHBIcFwTQuKJTOkM5Z5kwTc9yfdevsOiYvv T6YL/ysLToOmMTQhcXNKDIz4Huu5yD44DULdqm08DJedZCDky9isXc5Kx+kEQGW4 DsAMHGGSttdkWo08tInsoPimRq1vbTYaJ06dzRRza9jpBar68Zl7qMTsy9BBVZm4 VF4DhF1Lzu2qGodTsEHkzrvoFw09KtsMjlIClAdzIBOycz7wq8I16+rvKIGwZgQS 4+6FD+zmPTmAKiDgnI1QSp8w3XyLb+g85lbC37UpMpyfldAbe6YpgtAhx50I3EcJ d0Trle+ahjJK7Qq22ObGcM= X-Virus-Scanned: amavisd-new at worrbase.com Received: from kefka.worrbase.com ([IPv6:::1]) by localhost (kefka.worrbase.com [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id JL9ALyh_kkGG for ; Fri, 19 Sep 2014 21:49:24 -0700 (PDT) Received: from [IPv6:2601:9:7e00:71:d9b3:c4f7:7aea:97fd] (2601:9:7e00:71:d9b3:c4f7:7aea:97fd [IPv6:2601:9:7e00:71:d9b3:c4f7:7aea:97fd]); by kefka.worrbase.com (OpenSMTPD) with ESMTPSA id b81d6fb1; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-SHA bits=128 verify=NO; for ; Fri, 19 Sep 2014 21:49:23 -0700 (PDT) Message-ID: <541D69D4.5060104@worrbase.com> Date: Sat, 20 Sep 2014 04:49:40 -0700 From: William Orr User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: [PATCH] Fix integer overflow handling in dd(1) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 04:49:42 -0000 Hey, I've submitted this patch before, and it's gotten comments and fixes, but still hasn't been merged. Any thoughts? Does it need more work? Thanks, William Orr Index: args.c =================================================================== --- args.c (revision 270645) +++ args.c (working copy) @@ -41,6 +41,7 @@ #include +#include #include #include #include @@ -171,8 +172,7 @@ */ if (in.offset > OFF_MAX / (ssize_t)in.dbsz || out.offset > OFF_MAX / (ssize_t)out.dbsz) - errx(1, "seek offsets cannot be larger than %jd", - (intmax_t)OFF_MAX); + errx(1, "seek offsets cannot be larger than %jd", OFF_MAX); } static int @@ -186,37 +186,28 @@ static void f_bs(char *arg) { - uintmax_t res; - res = get_num(arg); - if (res < 1 || res > SSIZE_MAX) - errx(1, "bs must be between 1 and %jd", (intmax_t)SSIZE_MAX); - in.dbsz = out.dbsz = (size_t)res; + in.dbsz = out.dbsz = get_num(arg); + if (out.dbsz < 1 || out.dbsz > SSIZE_MAX) + errx(1, "bs must be between 1 and %jd", SSIZE_MAX); } static void f_cbs(char *arg) { - uintmax_t res; - res = get_num(arg); - if (res < 1 || res > SSIZE_MAX) - errx(1, "cbs must be between 1 and %jd", (intmax_t)SSIZE_MAX); - cbsz = (size_t)res; + cbsz = get_num(arg); + if (cbsz < 1 || cbsz > SSIZE_MAX) + errx(1, "cbs must be between 1 and %jd", SSIZE_MAX); } static void f_count(char *arg) { - intmax_t res; - res = (intmax_t)get_num(arg); - if (res < 0) - errx(1, "count cannot be negative"); - if (res == 0) - cpy_cnt = (uintmax_t)-1; - else - cpy_cnt = (uintmax_t)res; + cpy_cnt = get_num(arg); + if (cpy_cnt == 0) + cpy_cnt = -1; } static void @@ -225,7 +216,7 @@ files_cnt = get_num(arg); if (files_cnt < 1) - errx(1, "files must be between 1 and %jd", (uintmax_t)-1); + errx(1, "files must be between 1 and %ju", SIZE_MAX); } static void @@ -241,14 +232,11 @@ static void f_ibs(char *arg) { - uintmax_t res; if (!(ddflags & C_BS)) { - res = get_num(arg); - if (res < 1 || res > SSIZE_MAX) - errx(1, "ibs must be between 1 and %jd", - (intmax_t)SSIZE_MAX); - in.dbsz = (size_t)res; + in.dbsz = get_num(arg); + if (in.dbsz < 1 || in.dbsz > SSIZE_MAX) + errx(1, "ibs must be between 1 and %ju", SSIZE_MAX); } } @@ -262,14 +250,11 @@ static void f_obs(char *arg) { - uintmax_t res; if (!(ddflags & C_BS)) { - res = get_num(arg); - if (res < 1 || res > SSIZE_MAX) - errx(1, "obs must be between 1 and %jd", - (intmax_t)SSIZE_MAX); - out.dbsz = (size_t)res; + out.dbsz = get_num(arg); + if (out.dbsz < 1 || out.dbsz > SSIZE_MAX) + errx(1, "obs must be between 1 and %jd", SSIZE_MAX); } } @@ -378,11 +363,17 @@ uintmax_t num, mult, prevnum; char *expr; + while (isspace(val[0])) + val++; + + if (val[0] == '-') + errx(1, "%s: cannot be negative", oper); + errno = 0; - num = strtouq(val, &expr, 0); + num = strtoull(val, &expr, 0); if (errno != 0) /* Overflow or underflow. */ err(1, "%s", oper); - + if (expr == val) /* No valid digits. */ errx(1, "%s: illegal numeric value", oper); Index: conv.c =================================================================== --- conv.c (revision 270645) +++ conv.c (working copy) @@ -133,7 +133,7 @@ */ ch = 0; for (inp = in.dbp - in.dbcnt, outp = out.dbp; in.dbcnt;) { - maxlen = MIN(cbsz, in.dbcnt); + maxlen = MIN(cbsz, (size_t)in.dbcnt); if ((t = ctab) != NULL) for (cnt = 0; cnt < maxlen && (ch = *inp++) != '\n'; ++cnt) @@ -146,7 +146,7 @@ * Check for short record without a newline. Reassemble the * input block. */ - if (ch != '\n' && in.dbcnt < cbsz) { + if (ch != '\n' && (size_t)in.dbcnt < cbsz) { (void)memmove(in.db, in.dbp - in.dbcnt, in.dbcnt); break; } @@ -228,7 +228,7 @@ * translation has to already be done or we might not recognize the * spaces. */ - for (inp = in.db; in.dbcnt >= cbsz; inp += cbsz, in.dbcnt -= cbsz) { + for (inp = in.db; (size_t)in.dbcnt >= cbsz; inp += cbsz, in.dbcnt -= cbsz) { for (t = inp + cbsz - 1; t >= inp && *t == ' '; --t) ; if (t >= inp) { Index: dd.c =================================================================== --- dd.c (revision 270645) +++ dd.c (working copy) @@ -168,10 +168,10 @@ * record oriented I/O, only need a single buffer. */ if (!(ddflags & (C_BLOCK | C_UNBLOCK))) { - if ((in.db = malloc(out.dbsz + in.dbsz - 1)) == NULL) + if ((in.db = malloc((size_t)out.dbsz + in.dbsz - 1)) == NULL) err(1, "input buffer"); out.db = in.db; - } else if ((in.db = malloc(MAX(in.dbsz, cbsz) + cbsz)) == NULL || + } else if ((in.db = malloc(MAX((size_t)in.dbsz, cbsz) + cbsz)) == NULL || (out.db = malloc(out.dbsz + cbsz)) == NULL) err(1, "output buffer"); @@ -343,7 +343,7 @@ ++st.in_full; /* Handle full input blocks. */ - } else if ((size_t)n == in.dbsz) { + } else if ((size_t)n == (size_t)in.dbsz) { in.dbcnt += in.dbrcnt = n; ++st.in_full; @@ -493,7 +493,7 @@ outp += nw; st.bytes += nw; - if ((size_t)nw == n && n == out.dbsz) + if ((size_t)nw == n && n == (size_t)out.dbsz) ++st.out_full; else ++st.out_part; Index: dd.h =================================================================== --- dd.h (revision 270645) +++ dd.h (working copy) @@ -38,10 +38,9 @@ typedef struct { u_char *db; /* buffer address */ u_char *dbp; /* current buffer I/O address */ - /* XXX ssize_t? */ - size_t dbcnt; /* current buffer byte count */ - size_t dbrcnt; /* last read byte count */ - size_t dbsz; /* block size */ + ssize_t dbcnt; /* current buffer byte count */ + ssize_t dbrcnt; /* last read byte count */ + ssize_t dbsz; /* block size */ #define ISCHR 0x01 /* character device (warn on short) */ #define ISPIPE 0x02 /* pipe-like (see position.c) */ @@ -57,13 +56,13 @@ } IO; typedef struct { - uintmax_t in_full; /* # of full input blocks */ - uintmax_t in_part; /* # of partial input blocks */ - uintmax_t out_full; /* # of full output blocks */ - uintmax_t out_part; /* # of partial output blocks */ - uintmax_t trunc; /* # of truncated records */ - uintmax_t swab; /* # of odd-length swab blocks */ - uintmax_t bytes; /* # of bytes written */ + size_t in_full; /* # of full input blocks */ + size_t in_part; /* # of partial input blocks */ + size_t out_full; /* # of full output blocks */ + size_t out_part; /* # of partial output blocks */ + size_t trunc; /* # of truncated records */ + size_t swab; /* # of odd-length swab blocks */ + size_t bytes; /* # of bytes written */ struct timespec start; /* start time of dd */ } STAT; Index: position.c =================================================================== --- position.c (revision 270645) +++ position.c (working copy) @@ -178,7 +178,7 @@ n = write(out.fd, out.db, out.dbsz); if (n == -1) err(1, "%s", out.name); - if ((size_t)n != out.dbsz) + if (n != out.dbsz) errx(1, "%s: write failure", out.name); } break; From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 10:45:57 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01F63E62; Sat, 20 Sep 2014 10:45:57 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 81F91BB7; Sat, 20 Sep 2014 10:45:56 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XVIAl-001v4I-SS>; Sat, 20 Sep 2014 12:45:47 +0200 Received: from g225119140.adsl.alicedsl.de ([92.225.119.140] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XVIAl-002jpv-Oh>; Sat, 20 Sep 2014 12:45:47 +0200 Date: Sat, 20 Sep 2014 12:45:40 +0200 From: "O. Hartmann" To: Kevin Oberman Subject: Re: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI Message-ID: <20140920124540.76a9abae.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20140915233833.5bdd0725.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/Y2b9rJzbwFe2mlhYDW_TE95"; protocol="application/pgp-signature" X-Originating-IP: 92.225.119.140 X-ZEDAT-Hint: A Cc: FreeBSD CURRENT , FreeBSD Questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 10:45:57 -0000 --Sig_/Y2b9rJzbwFe2mlhYDW_TE95 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Mon, 15 Sep 2014 18:19:32 -0700 Kevin Oberman schrieb: > On Mon, Sep 15, 2014 at 2:38 PM, O. Hartmann > wrote: >=20 > > > > Trying to install and run FreeBSD 11.0-CURRENT > > (FreeBSD-11.0-CURRENT-amd64-20140903-r270990-memstick.img) on a new Len= ovo > > E540 notebook > > fails in activating the NIC (Realtek RTL8111/8168B, driver re[0]). The = NIC > > shows up as > > active and with carrier when issuing "ifconfig re0". > > > > From a desktop machine, I tried to ping the system in question and I ge= t a > > result with > > missing packets: > > > > ping: sendto: Host is down > > ping: sendto: Host is down > > ping: sendto: Host is down > > 64 bytes from 192.168.0.130: icmp_seq=3D26 ttl=3D64 time=3D0.114 ms > > 64 bytes from 192.168.0.130: icmp_seq=3D41 ttl=3D64 time=3D0.130 ms > > 64 bytes from 192.168.0.130: icmp_seq=3D60 ttl=3D64 time=3D0.119 ms > > 64 bytes from 192.168.0.130: icmp_seq=3D80 ttl=3D64 time=3D0.119 ms > > 64 bytes from 192.168.0.130: icmp_seq=3D100 ttl=3D64 time=3D0.105 ms > > 64 bytes from 192.168.0.130: icmp_seq=3D116 ttl=3D64 time=3D0.135 ms > > 64 bytes from 192.168.0.130: icmp_seq=3D136 ttl=3D64 time=3D0.091 ms > > > > DHCP configuration fails, since no DHCP offer is discovered. > > > > I swapped the switches, the cabling and I had always the same results. I > > used another > > Laptop, Dell Latitude E6510 with the same configuration (/etc/rc.conf) = and > > that system > > gets DHCP offer and is online. > > > > Since the notebook is brandnew, the last thing I'll "suspect" is a > > defective NIC, so I'll > > ask whether this phenomenon is known - or, if not, the results > > definititely would > > indicate a broken NIC. > > > > Another point is the WiFI adaptor. This notebook is supposed to have a > > WiFi NIC, but it > > doesn't get revealed by FreeBSD (I tried iwn/iwi without success). > > > > pciconf output below, sorry for the messy shape, it is a copy-and-paste > > from that immature > > vt() terminal. > > > > Has anyone successfully installed that type of Notebook with FreeBSD > > CURRENT using NIC > > and Wifi? > > > > Please CC me. > > > > > > Regards > > oh > > > > > > [...] > > > > none1@pci0:3:0:0: class=3D0xff0000 card=3D0x502817aa chip=3D0x522= 710ec > > rev=3D0x01 hdr=3D0x00 > > > > > > vendor =3D 'Realtek Semiconductor Co., Ltd.' > > > > > > bar [10] =3D type Memory, range 32, base 0xf1e00000, size 4096, e= nabled > > > > > > cap 01[40] =3D powerspec 3 supports D0 D1 D2 D3 current D0 > > > > > > cap 05[50] =3D MSI supports 1 message, 64 bit > > > > > > cap 10[70] =3D PCI-Express 2 endpoint max data 128(128) link x1(x1) > > > > > > speed 2.5(2.5) ASPM L0s/L1(L0s/L1) > > > > > > ecap 0001[100] =3D AER 2 0 fatal 0 non-fatal 0 corrected > > > > > > ecap 0003[140] =3D Serial 1 00000001004ce000 > > > > > > re0@pci0:4:0:0: class=3D0x020000 card=3D0x502817aa chip=3D0x816810ec re= v=3D0x10 > > hdr=3D0x00 > > > > > > subclass =3D ethernet > > > > > > cap 01[40] =3D powerspec 3 supports D0 D1 D2 D3 current > > D0 > > di sabled(L0s/L1) > > > > > > cap 11[b0] =3D MSI-X supports 4 messages, enabled > > > > ecap 0001[100] =3D AER 2 0 fatal 0 non-fatal 4 corrected > > > > > > > > ecap 001e[178] =3D unknown 1 > > > > > > class =3D network > > > > > > cap 05[d0] =3D MSI supports 1 message, 64 bit > > > > > > ecap 0003[140] =3D Serial 1 ac7ba1ffffa06fd6 > > >=20 > I can't comment on the WiFi, I have little Asus box using an 8111/8168B a= nd > it works fine with the driver in 10.1-BETA. The driver in 10.0 recognizes > the device, but did not work. I do notice that your NIC has a rev of 0x10 > while mine is 0x0c. > -- > Kevin Oberman, Network Engineer, Retired I tried a 10.1-BETA also and it shows the very same symptomes as in 11.0-CU= RRENT. As Guido Falsi stated later in this thread, the device gets recognized but is = inoperable after initialized and setup by the OS until the administrator takes some st= range actions. In Guido's case a setting/resetting of NIC features helps, in my case I hav= e to bring down the device first via "ifconfig re0 down" and then bring it up. After t= hat, the NIC works as expected. This seems clearly to be a bug in the driver code and it= might indeed have to do something with a new revision used, but the NIC is since at leas= t a year on the market and floating around (my laptop was manufactured in April of this= year). Well, I hope this report doesn't get lost, so I filed a PR. Oliver --Sig_/Y2b9rJzbwFe2mlhYDW_TE95 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUHVraAAoJEOgBcD7A/5N8qzUIAJWake6B6rO7uj4FPQa4a7pG +lxP38T26h/+3z6Kc+oc/W4FQv4/eQRRS1DOSGvoS92Fg8lTBP4JrSXXA2wxVLUj QbtKzb1WrdezomA6w1FbsAoYIZB6Kqn9C6uvmLkgstiIDhy8UeSaBoGyy4DHcqH3 mYyFEooaAbpVVHqH3moiiTmfABSiELoLK6Lc3MSKgevwYWINHa2srfK9y7zzZ/TQ Wsy0s1RCRe57711Ca+sHPihhxGgpRQVbEm0FHfa/1sf5uyHwgmf0D+8FdLd0ikAv HQMNigabz+lGN6Oy5qVKizWWxsfTRGT+m2lpByMip3SxnNVqCav0/EPjoij1jwQ= =EIfl -----END PGP SIGNATURE----- --Sig_/Y2b9rJzbwFe2mlhYDW_TE95-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 11:37:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5BC725F6; Sat, 20 Sep 2014 11:37:40 +0000 (UTC) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8FDD3FFA; Sat, 20 Sep 2014 11:37:39 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id b12so4444247lbj.39 for ; Sat, 20 Sep 2014 04:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=tteROCGyQWVnFXSHMUs8XhNi7bupyHMsxSCRiPYT1Jc=; b=IY78tPVCVvzwR2PC2Bf/wnMDBb0WevpkqBoIvZsEj2bJoyG//wm0TY5Yir+JyfS1gk hCcJPn0ltLz+/O9oLbQvhGaRtvsVRMVnFmpBKhajhcRMB85kg2jnJP0FMAMA8esichY3 X7RNfpYN9fcozf2ZIS02JAzX8PPMGQowolwBsADyCyCO61xe5fRVkGzCUMtEfvHfExCJ QKnmcXcYtaEG2gfzaKqsRMF7gB26Hom4Y/XIBNwQI3sw7gEQGbH63fPbxGg/lv4n+y6M QCHwjycpPVGtZs2edzxMuRFW7CuyYyH/ohcI0raoEBe97LogcS72ERV22wP5Q5WRPeoW Ya7A== MIME-Version: 1.0 X-Received: by 10.152.45.8 with SMTP id i8mr12752844lam.31.1411213057060; Sat, 20 Sep 2014 04:37:37 -0700 (PDT) Received: by 10.112.218.101 with HTTP; Sat, 20 Sep 2014 04:37:37 -0700 (PDT) Reply-To: huanghwh@gmail.com In-Reply-To: <53E730E8.9070206@icloud.com> References: <537DFD85.1090903@icloud.com> <53C10945.4020003@icloud.com> <53C16ED0.2000604@freebsd.org> <53E730E8.9070206@icloud.com> Date: Sat, 20 Sep 2014 19:37:37 +0800 Message-ID: Subject: Re: uefi boot on Apple Mac From: Huang Wen Hui To: Anders Bolt Evensen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current , Ed Maste X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 11:37:40 -0000 I finally make MacBookPro 11,3 UEFI boot successfully: 1. copy boot1.efi to /EFI/boot/BOOTx64.efi in EFI partition 2. Create a small UFS partition in internal SSD, and installworld and installkernel. 3. Without USB stick, then system really can boot, although the loader still stop at: Start @ 0xffffffff802d9000... 4. I can ssh log in and found that culprit is XHCI USB controller does not work in UEFI mode. 5. Xorg and nvidia driver also works. 6. verbose boot log can be found at: http://sw.gddsn.org.cn/freebsd/uefi-messages.txt Cheers, Huang Wen Hui 2014-08-10 16:44 GMT+08:00 Anders Bolt Evensen : > If you're interested, you can try out the following ISO: > https://www.dropbox.com/s/srbunx0agrokcs3/freebsd- > current-uefi-bios-amd64.iso > > The image was built on Friday 8th of August for the amd64 platform. > > I tested out the EFI part on VirtualBox (UEFI 2.X) and my MacBook Pro 17 > inch from 2011 (EFI 1.10), and as far as EFI goes, I successfully booted > the image on both my Mac and VirtualBox (however, booting the image from > BIOS using my Mac was a different story). > > So, as I said, as far as (U)EFI goes, the image should work on UEFI 2.X > based PC's and EFI 1.10 based Macs. > > On 12/07/14 19:22, Nathan Whitehorn wrote: > >> I'd point out that, as of last week, the standard -CURRENT ISOs (and >> generate-release.sh script) make EFI-bootable media by default. All the >> snapshots should have this done already, for instance. >> -Nathan >> > I wasn't aware of that, but thanks for the info. :) > > >> On 07/12/14 03:09, Anders Bolt-Evensen wrote: >> >>> I also got a message like that when I booted from a USB stick on a >>> MacBookPro8,3 (17 inch, late 2011). >>> >>> I fixed it by creating a custom ISO image and burned that onto a DVD >>> using an external DVD drive. >>> The UEFI installer boots fine from this external DVD drive. >>> >>> Here is how I did it: >>> >>> Genereste an ISO with the FreeBSD-CURRENT kernel, mount the ISO and cop= y >>> all files from the root directory in the ISO and unmount >>> > cd /usr/src/release >>> > sh ./generate-release.sh # You may have to run =E2=80=9Cmake buil= dworld=E2=80=9D >>> and be connected to the internet to install required ports. >>> > mount -t cd9660 /scratch/R/release/FreeBSD-something-disc1.iso >>> /mnt >>> > mkdir freebsd_generic_installer >>> #Files copied to the directory in the next command will be copied t= o >>> a new ISO in step 3 >>> > cp -R /mnt/ freebsd_generic_installer/ >>> > umount /mnt >>> 2. Create a FAT filesystem image and place the loader in it in the >>> default path that UEFI will look for (the following steps are copied fr= om >>> https://wiki.freebsd.org/UEFI#CD.2FDVD_Boot_under_UEFI): >>> > dd if=3D/dev/zero of=3Defiboot.img bs=3D4k count=3D100 >>> > mdconfig -a -t vnode -f efiboot.img >>> > newfs_msdos -F 12 -m 0xf8 /dev/md0 >>> > mount -t msdosfs /dev/md0 /mnt >>> > mkdir -p /mnt/efi/boot >>> > cp loader.efi /mnt/efi/boot/bootx64.efi >>> > umount /mnt >>> > mdconfig -d -u 0 >>> >>> 3. Create the custom ISO image. Please make sure that the entry in >>> freebsd_generic_installer/etc/fstab matches the label you choose in the >>> command below. >>> > makefs -t cd9660 -o bootimage=3D'i386;efiboot.img' -o no-emul-boo= t >>> -o rockridge -o label=3D=E2=80=9CFREEBSD_UEFI_INSTALL" -o publisher=3D"= test" >>> uefi-test.iso freebsd_generic_installer/ >>> >>> To get the example in the command above to work, please make sure that >>> the entry in freebsd_generic_installer/etc/fstab reads >>> "/dev/iso9660/FREEBSD_UEFI_INSTALL / cd9660 ro 0 0" >>> >>> 4. Burn the image to DVD, reboot your system and choose =E2=80=9CEFI Bo= ot=E2=80=9D. Note >>> that unless you are using a EFI console like rEFIt or rEFInd, you may h= ave >>> to kind of wait a couple of minutes while the kernel is loading before >>> anything appears on the screen. >>> >>> >>> On 04/07/14 16:34, Huang Wen Hui wrote: >>> >>>> Hi, >>>> On my MacbookPro11,3, I got this error message: >>>> >>>> http://sw.gddsn.org.cn/freebsd/uefi.jpg >>>> >>>> cheers, >>>> >>>> Huang WenHui >>>> >>>> 2014-07-04 22:13 GMT+08:00 Ed Maste : >>>> >>>> On 24 May 2014 19:39, Rafael Esp=C3=ADndola >>>>> wrote: >>>>> >>>>>> Yes, I got that in the mac laptops I tried, it worked on a Mac Pro. = It >>>>>> might be the frame buffer corruption that Ed Maste was mentioning. >>>>>> >>>>> I purchased a new MacBook Air yesterday (model identifier >>>>> MacBookAir6,2). UEFI boot and vt(4) worked correctly. (My image >>>>> included Rafael's patch; I haven't tried a boot without.) >>>>> >>>>> I also committed a change to display the framebuffer parameters >>>>> (address, dimensions, etc.) on boot, in order to help identify the >>>>> source of this issue. If you have a moment can you build a new USB >>>>> stick image and give it a try? >>>>> >>>>> -Ed >>>>> >>>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@ >>>> freebsd.org" >>>> >>> >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@ >>> freebsd.org" >>> >>> >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 13:36:25 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93B56690; Sat, 20 Sep 2014 13:36:25 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 405D8BB7; Sat, 20 Sep 2014 13:36:24 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s8KDaNoX011531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 20 Sep 2014 07:36:23 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s8KDaLl5011527; Sat, 20 Sep 2014 07:36:23 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 20 Sep 2014 07:36:21 -0600 (MDT) From: Warren Block To: "O. Hartmann" Subject: Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT In-Reply-To: <20140919201210.72650231.ohartman@zedat.fu-berlin.de> Message-ID: References: <20140919201210.72650231.ohartman@zedat.fu-berlin.de> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sat, 20 Sep 2014 07:36:23 -0600 (MDT) Cc: freebsd-x11@freebsd.org, FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 13:36:25 -0000 On Fri, 19 Sep 2014, O. Hartmann wrote: > nVidia's BLOB from port x11/nvidia-driver seems to have problems in FreeBSD 11.0-CURRENT > #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo ThinkPad Edge E540 laptop with > CPU i5-4200M (Haswell) with integrated HD4600 Intel iGPU and dedicated nVidia GT 740M > (Optimus) working correctly. Optimus is supposed to be full Intel graphics plus an Nvidia GPU. The extra GPU uses the same display memory and can be enabled to speed up the Intel graphics or disabled for power saving. I don't know if versions where the Nvidia section is a full discrete video adapter that can be used alone are still called "Optimus". Some Optimus owners have reported being able to use the Intel drivers after disabling the Nvidia GPU in the BIOS or UEFI. If an option to disable the Nvidia GPU is not present, some people have reported success with an xorg.conf that uses only the intel driver and ignores the Nvidia hardware. From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 14:10:22 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A03A5143; Sat, 20 Sep 2014 14:10:22 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2BDD4E85; Sat, 20 Sep 2014 14:10:21 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XVLMg-002OxF-Nj>; Sat, 20 Sep 2014 16:10:18 +0200 Received: from g225119140.adsl.alicedsl.de ([92.225.119.140] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XVLMg-0034l9-Gk>; Sat, 20 Sep 2014 16:10:18 +0200 Date: Sat, 20 Sep 2014 16:10:12 +0200 From: "O. Hartmann" To: Warren Block Subject: Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT Message-ID: <20140920161012.02844320.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20140919201210.72650231.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/v75vmdC=ghd=hb=W1iAes=f"; protocol="application/pgp-signature" X-Originating-IP: 92.225.119.140 X-ZEDAT-Hint: A Cc: freebsd-x11@freebsd.org, FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 14:10:22 -0000 --Sig_/v75vmdC=ghd=hb=W1iAes=f Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) Warren Block schrieb: > On Fri, 19 Sep 2014, O. Hartmann wrote: >=20 > > nVidia's BLOB from port x11/nvidia-driver seems to have problems in Fre= eBSD > > 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo= ThinkPad Edge > > E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 Intel iG= PU and > > dedicated nVidia GT 740M (Optimus) working correctly. >=20 > Optimus is supposed to be full Intel graphics plus an Nvidia GPU. The=20 > extra GPU uses the same display memory and can be enabled to speed up=20 > the Intel graphics or disabled for power saving. I don't know if=20 > versions where the Nvidia section is a full discrete video adapter that=20 > can be used alone are still called "Optimus". >=20 > Some Optimus owners have reported being able to use the Intel drivers=20 > after disabling the Nvidia GPU in the BIOS or UEFI. If an option to=20 > disable the Nvidia GPU is not present, some people have reported success= =20 > with an xorg.conf that uses only the intel driver and ignores the Nvidia= =20 > hardware. Thanks Warren. But this sounds even more frustrating now. I look around the web even at Le= novo's support forum. Many people report the GT 740M nVidia adaptor as a discrete adaptor = with Optimus technology and everything sounds to me like it can be selected exclusively.= What you describes is that I definitely need to use the HD4600 iGPU on FreeBSD in th= e first place since the nVidia hardware is a kind of "appendix" to the HD4600. Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't work p= roperly: it doesn't even start up and loading the "intel" driver complains about a miss= ing device - preceeded by a lot of /dev/dri errors. This indicates to me, in a naiv mann= er, that this HD4600 isn't recodnized by the kernel, either. I do not see any kind of vga= 0: entry in the kernel log when enabling "Integrated Graphics" only in the laptop's UEF= I/Firmware. When enabling "nVidia Optimus", a recognized vga0: device shows up. =46rom my server, equipted with a IvyBridge i3-class CPU with integrated iGPU= , I even get this message from 11.0-CURRENT: vgapci0@pci0:0:2:0: class=3D0x030000 card=3D0x01521849 chip=3D0x0152808= 6 rev=3D0x09 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon E3-1200 v2/3rd Gen Core processor Graphics Control= ler' class =3D display subclass =3D VGA bar [10] =3D type Memory, range 64, base 0xf7800000, size 4194304, en= abled bar [18] =3D type Prefetchable Memory, range 64, base 0xe0000000, siz= e 268435456, enabled bar [20] =3D type I/O Port, range 32, base 0xf000, size 64, enabl= ed cap 05[90] =3D MSI supports 1 message=20 cap 01[d0] =3D powerspec 2 supports D0 D3 current D0 cap 13[a4] =3D PCI Advanced Features: FLR TP The very same CURRENT (most recent as I built world on all system today) do= esn't recognize the Haswell's HD4600 iGPU (i5-4200M). So, it seems impossible to = me that people can report having this GPU working if even the most recent FreeBSD CURRENT = doesn't recognize it. --Sig_/v75vmdC=ghd=hb=W1iAes=f Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEbBAEBAgAGBQJUHYrIAAoJEOgBcD7A/5N8n/kH+LRs9XQYMpKnzH+8UZgGvnSy LDMTEmnjOqu+Ib45gl6usIgGgmC+ZsyxRsbLm8Cy5Jglh1iA8hp8pgFkNeq1bSCW /Q8LpaZAkEgmRvYFwQgyt7W64y3zdqBzzVaTvP3RP2cn31rK0iUg0DtDVqAGJ+zC zIkAkW/7XX2zse4rnkTDsxWVU4TtaFZSU2mS1Ow1qXKvoovB+V1x6agG8FBGv6f6 dA3FnJo0xovVNtyrtecoB7TZRO/nEinF/99g0pNWv8rI6MX+i+SpBzQqmm8Mlz/k Jv05nPlwMxDkxBm0MLi2/Q43JKAXgUGjGi+RY1iPwbeJF7Mxz2rro32fk2A6YQ== =l8J+ -----END PGP SIGNATURE----- --Sig_/v75vmdC=ghd=hb=W1iAes=f-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 14:21:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B90F564D; Sat, 20 Sep 2014 14:21:40 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 86E1BFFC; Sat, 20 Sep 2014 14:21:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=ZLg02Lw2jncoW6st5L40dY38YQtuHN2IyAMXY4SE6cA=; b=Ye/9N3qbQH9Mez1pmlgROUb7J1NIa2a5VUbNdwqlgKxW78hXAB1XJ9+MIfKhBXa0NMx4qDD1OxYKMzKYGkM3GOFxSVcgm80JGNIaTOiV3SWVUcgnYVUqXj5ArXbq6sFpngPC/wOU0Wcf1PiG8yFzxUqy51J+y+hp02pKxIssTqo=; Received: from localhost.lerctr.org ([127.0.0.1]:61761 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XVLXa-0009h6-6I; Sat, 20 Sep 2014 09:21:35 -0500 Received: from rrcs-50-84-90-98.sw.biz.rr.com ([50.84.90.98]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Sat, 20 Sep 2014 09:21:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 20 Sep 2014 09:21:34 -0500 From: Larry Rosenman To: "O. Hartmann" Subject: Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT In-Reply-To: <20140920161012.02844320.ohartman@zedat.fu-berlin.de> References: <20140919201210.72650231.ohartman@zedat.fu-berlin.de> <20140920161012.02844320.ohartman@zedat.fu-berlin.de> Message-ID: <65cfbb363809ee6e1078c28390d02603@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.2 X-Spam-Score: -3.6 (---) X-LERCTR-Spam-Score: -3.6 (---) X-Spam-Report: SpamScore (-3.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.662 X-LERCTR-Spam-Report: SpamScore (-3.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.662 Cc: Warren Block , freebsd-x11@freebsd.org, FreeBSD CURRENT , owner-freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 14:21:40 -0000 On 2014-09-20 09:10, O. Hartmann wrote: > Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) > Warren Block schrieb: > >> On Fri, 19 Sep 2014, O. Hartmann wrote: >> >> > nVidia's BLOB from port x11/nvidia-driver seems to have problems in FreeBSD >> > 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo ThinkPad Edge >> > E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 Intel iGPU and >> > dedicated nVidia GT 740M (Optimus) working correctly. >> >> Optimus is supposed to be full Intel graphics plus an Nvidia GPU. The >> extra GPU uses the same display memory and can be enabled to speed up >> the Intel graphics or disabled for power saving. I don't know if >> versions where the Nvidia section is a full discrete video adapter >> that >> can be used alone are still called "Optimus". >> >> Some Optimus owners have reported being able to use the Intel drivers >> after disabling the Nvidia GPU in the BIOS or UEFI. If an option to >> disable the Nvidia GPU is not present, some people have reported >> success >> with an xorg.conf that uses only the intel driver and ignores the >> Nvidia >> hardware. > > Thanks Warren. > > But this sounds even more frustrating now. I look around the web even > at Lenovo's support > forum. Many people report the GT 740M nVidia adaptor as a discrete > adaptor with Optimus > technology and everything sounds to me like it can be selected > exclusively. What you > describes is that I definitely need to use the HD4600 iGPU on FreeBSD > in the first place > since the nVidia hardware is a kind of "appendix" to the HD4600. > > Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't > work properly: it > doesn't even start up and loading the "intel" driver complains about a > missing device - > preceeded by a lot of /dev/dri errors. This indicates to me, in a naiv > manner, that this > HD4600 isn't recodnized by the kernel, either. I do not see any kind > of vga0: entry in > the kernel log when enabling "Integrated Graphics" only in the > laptop's UEFI/Firmware. > When enabling "nVidia Optimus", a recognized vga0: device shows up. > > From my server, equipted with a IvyBridge i3-class CPU with integrated > iGPU, I even get > this message from 11.0-CURRENT: > > vgapci0@pci0:0:2:0: class=0x030000 card=0x01521849 chip=0x01528086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Xeon E3-1200 v2/3rd Gen Core processor Graphics > Controller' > class = display > subclass = VGA > bar [10] = type Memory, range 64, base 0xf7800000, size 4194304, > enabled > bar [18] = type Prefetchable Memory, range 64, base 0xe0000000, > size 268435456, > enabled bar [20] = type I/O Port, range 32, base 0xf000, size 64, > enabled > cap 05[90] = MSI supports 1 message > cap 01[d0] = powerspec 2 supports D0 D3 current D0 > cap 13[a4] = PCI Advanced Features: FLR TP > > > The very same CURRENT (most recent as I built world on all system > today) doesn't > recognize the Haswell's HD4600 iGPU (i5-4200M). So, it seems > impossible to me that people > can report having this GPU working if even the most recent FreeBSD > CURRENT doesn't > recognize it. for the record, on my Thinkpad W520+Docking Station, I get two HDMI / DVI outputs off the Nvidia GPU, in addition to the Intel graphics on the local LCD. This is under Windows, but..... -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 14:25:56 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DA699C9; Sat, 20 Sep 2014 14:25:56 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2890DAB; Sat, 20 Sep 2014 14:25:55 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XVLbm-002RUQ-7z>; Sat, 20 Sep 2014 16:25:54 +0200 Received: from g225119140.adsl.alicedsl.de ([92.225.119.140] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XVLbm-00368R-2R>; Sat, 20 Sep 2014 16:25:54 +0200 Date: Sat, 20 Sep 2014 16:25:48 +0200 From: "O. Hartmann" To: Warren Block Subject: Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT Message-ID: <20140920162548.0d793cb8.ohartman@zedat.fu-berlin.de> In-Reply-To: <20140920161012.02844320.ohartman@zedat.fu-berlin.de> References: <20140919201210.72650231.ohartman@zedat.fu-berlin.de> <20140920161012.02844320.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/dPZyvKZ3Fm1acvyRGHnK3NQ"; protocol="application/pgp-signature" X-Originating-IP: 92.225.119.140 X-ZEDAT-Hint: A Cc: freebsd-x11@freebsd.org, FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 14:25:56 -0000 --Sig_/dPZyvKZ3Fm1acvyRGHnK3NQ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sat, 20 Sep 2014 16:10:12 +0200 "O. Hartmann" schrieb: > Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) > Warren Block schrieb: >=20 > > On Fri, 19 Sep 2014, O. Hartmann wrote: > >=20 > > > nVidia's BLOB from port x11/nvidia-driver seems to have problems in F= reeBSD > > > 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Leno= vo ThinkPad > > > Edge E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 I= ntel iGPU and > > > dedicated nVidia GT 740M (Optimus) working correctly. > >=20 > > Optimus is supposed to be full Intel graphics plus an Nvidia GPU. The= =20 > > extra GPU uses the same display memory and can be enabled to speed up=20 > > the Intel graphics or disabled for power saving. I don't know if=20 > > versions where the Nvidia section is a full discrete video adapter that= =20 > > can be used alone are still called "Optimus". > >=20 > > Some Optimus owners have reported being able to use the Intel drivers=20 > > after disabling the Nvidia GPU in the BIOS or UEFI. If an option to=20 > > disable the Nvidia GPU is not present, some people have reported succes= s=20 > > with an xorg.conf that uses only the intel driver and ignores the Nvidi= a=20 > > hardware. >=20 > Thanks Warren. >=20 > But this sounds even more frustrating now. I look around the web even at = Lenovo's > support forum. Many people report the GT 740M nVidia adaptor as a discret= e adaptor with > Optimus technology and everything sounds to me like it can be selected ex= clusively. > What you describes is that I definitely need to use the HD4600 iGPU on Fr= eeBSD in the > first place since the nVidia hardware is a kind of "appendix" to the HD46= 00. >=20 > Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't work= properly: it > doesn't even start up and loading the "intel" driver complains about a mi= ssing device - > preceeded by a lot of /dev/dri errors. This indicates to me, in a naiv ma= nner, that this > HD4600 isn't recodnized by the kernel, either. I do not see any kind of v= ga0: entry in > the kernel log when enabling "Integrated Graphics" only in the laptop's U= EFI/Firmware. > When enabling "nVidia Optimus", a recognized vga0: device shows up. >=20 > From my server, equipted with a IvyBridge i3-class CPU with integrated iG= PU, I even get > this message from 11.0-CURRENT: >=20 > vgapci0@pci0:0:2:0: class=3D0x030000 card=3D0x01521849 chip=3D0x01528= 086 rev=3D0x09 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'Xeon E3-1200 v2/3rd Gen Core processor Graphics Contr= oller' > class =3D display > subclass =3D VGA > bar [10] =3D type Memory, range 64, base 0xf7800000, size 4194304, = enabled > bar [18] =3D type Prefetchable Memory, range 64, base 0xe0000000, s= ize 268435456, > enabled bar [20] =3D type I/O Port, range 32, base 0xf000, size 64, ena= bled > cap 05[90] =3D MSI supports 1 message=20 > cap 01[d0] =3D powerspec 2 supports D0 D3 current D0 > cap 13[a4] =3D PCI Advanced Features: FLR TP >=20 >=20 > The very same CURRENT (most recent as I built world on all system today) = doesn't > recognize the Haswell's HD4600 iGPU (i5-4200M). So, it seems impossible t= o me that > people can report having this GPU working if even the most recent FreeBSD= CURRENT > doesn't recognize it. Sorry, on the laptop in question the integrated HD4600 does show up as a vg= a0: device in the pciconf-listing (it is very early and I stoped looking at the very end = ...). --Sig_/dPZyvKZ3Fm1acvyRGHnK3NQ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUHY5xAAoJEOgBcD7A/5N88jAH/12ebTMRZhuodIUxayzyWSvV S26SVDQjOJnhin7O+bnxCDs5z2B4R8LmNOhDQQtdmABvqIjUzXK26GzcO89sBOC5 D/CpQ3uPdiR3Byiy4wkQanqOBoEfNlQdYaZ8RnOOODI8Kzza786O3FQNpYKvuEbr lASxxLSqzsKFfs60sns5ghoDyYug1lWw79YaoQeIg1VcCPpsZzeFtpE3sbOkYkmN JfIUl2PMQKUG+al0U+5xJqMdns2taQT168G9DUnOBg/3r0JicdM2xJZ8b+NjSKw9 +13NmuPT1nmqw8v7yITs+O7NxkKAP0fFFMG0xoIfigvJgbv0Xe1YlDkInoehZJw= =ysGX -----END PGP SIGNATURE----- --Sig_/dPZyvKZ3Fm1acvyRGHnK3NQ-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 14:27:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD878B4F; Sat, 20 Sep 2014 14:27:29 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 53ED5C8; Sat, 20 Sep 2014 14:27:28 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s8KERRRR024302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 20 Sep 2014 08:27:27 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s8KERRs4024299; Sat, 20 Sep 2014 08:27:27 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 20 Sep 2014 08:27:27 -0600 (MDT) From: Warren Block To: "O. Hartmann" Subject: Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT In-Reply-To: <20140920161012.02844320.ohartman@zedat.fu-berlin.de> Message-ID: References: <20140919201210.72650231.ohartman@zedat.fu-berlin.de> <20140920161012.02844320.ohartman@zedat.fu-berlin.de> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sat, 20 Sep 2014 08:27:27 -0600 (MDT) Cc: freebsd-x11@freebsd.org, FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 14:27:29 -0000 On Sat, 20 Sep 2014, O. Hartmann wrote: > Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) > Warren Block schrieb: > >> On Fri, 19 Sep 2014, O. Hartmann wrote: >> >>> nVidia's BLOB from port x11/nvidia-driver seems to have problems in FreeBSD >>> 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo ThinkPad Edge >>> E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 Intel iGPU and >>> dedicated nVidia GT 740M (Optimus) working correctly. >> >> Optimus is supposed to be full Intel graphics plus an Nvidia GPU. The >> extra GPU uses the same display memory and can be enabled to speed up >> the Intel graphics or disabled for power saving. I don't know if >> versions where the Nvidia section is a full discrete video adapter that >> can be used alone are still called "Optimus". >> >> Some Optimus owners have reported being able to use the Intel drivers >> after disabling the Nvidia GPU in the BIOS or UEFI. If an option to >> disable the Nvidia GPU is not present, some people have reported success >> with an xorg.conf that uses only the intel driver and ignores the Nvidia >> hardware. > > Thanks Warren. > > But this sounds even more frustrating now. I look around the web even at Lenovo's support > forum. Many people report the GT 740M nVidia adaptor as a discrete adaptor with Optimus > technology and everything sounds to me like it can be selected exclusively. What you > describes is that I definitely need to use the HD4600 iGPU on FreeBSD in the first place > since the nVidia hardware is a kind of "appendix" to the HD4600. Optimus started out that way, but they might use the same name now for models where the additional GPU is a full discrete adapter. > Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't work properly: it > doesn't even start up and loading the "intel" driver complains about a missing device - > preceeded by a lot of /dev/dri errors. This indicates to me, in a naiv manner, that this > HD4600 isn't recodnized by the kernel, either. I do not see any kind of vga0: entry in > the kernel log when enabling "Integrated Graphics" only in the laptop's UEFI/Firmware. > When enabling "nVidia Optimus", a recognized vga0: device shows up. Whoops, HD4600 is Haswell. The intel driver on FreeBSD does not support Haswell video yet. From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 14:28:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0ED65C96; Sat, 20 Sep 2014 14:28:45 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AF6FCDF; Sat, 20 Sep 2014 14:28:44 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s8KEShkj024685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 20 Sep 2014 08:28:43 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s8KEShgc024682; Sat, 20 Sep 2014 08:28:43 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 20 Sep 2014 08:28:43 -0600 (MDT) From: Warren Block To: "O. Hartmann" Subject: Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT In-Reply-To: <20140920162548.0d793cb8.ohartman@zedat.fu-berlin.de> Message-ID: References: <20140919201210.72650231.ohartman@zedat.fu-berlin.de> <20140920161012.02844320.ohartman@zedat.fu-berlin.de> <20140920162548.0d793cb8.ohartman@zedat.fu-berlin.de> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sat, 20 Sep 2014 08:28:43 -0600 (MDT) Cc: freebsd-x11@freebsd.org, FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 14:28:45 -0000 On Sat, 20 Sep 2014, O. Hartmann wrote: >> >> The very same CURRENT (most recent as I built world on all system today) doesn't >> recognize the Haswell's HD4600 iGPU (i5-4200M). So, it seems impossible to me that >> people can report having this GPU working if even the most recent FreeBSD CURRENT >> doesn't recognize it. > > Sorry, on the laptop in question the integrated HD4600 does show up as a vga0: device in > the pciconf-listing (it is very early and I stoped looking at the very end ...). At this point, it's worth trying the vesa driver, which should work on Haswell. From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 16:47:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 010854A6; Sat, 20 Sep 2014 16:47:40 +0000 (UTC) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8DA6EEAE; Sat, 20 Sep 2014 16:47:40 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id f12so3852968qad.5 for ; Sat, 20 Sep 2014 09:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FyPxHPmyL73FQT9YYshE4Cwu/ClZkJ674XYdXUrplnU=; b=pYLm4Sn8/zoPPx80iAmfzWdGgiwTJ33s8ogVsWDnEEgWcEad6eg8LvMQkUfjtWDpEU Pd65cEFNAB3zO4ka5LFnfpsIFO9iFcjebS8SboUfA34H47kcfwyzhX33eUR9z3BvnvLP jOimq96BEvbv5lpcaxDqZG813aIeqxVf22zwHCPVHPxl9EJhj01d1tEeX/8uBJ+E4AIY k9BtiFp+AKpELMG90xu1X42uKFzv0SlRNAwN6AY+IeGgsqpCHRKdFq1AGS0KD5MU8c2P yeZpNU/u6R0Ue87luMBcXal3xomlMEvRoFfxINrod3cmkwqtzH0y1S3AIcB8+xSKfWI1 wKVw== MIME-Version: 1.0 X-Received: by 10.140.95.234 with SMTP id i97mr9983143qge.93.1411231659586; Sat, 20 Sep 2014 09:47:39 -0700 (PDT) Received: by 10.140.104.241 with HTTP; Sat, 20 Sep 2014 09:47:39 -0700 (PDT) In-Reply-To: References: <5419EE95.40600@selasky.org> Date: Sat, 20 Sep 2014 18:47:39 +0200 Message-ID: Subject: Re: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD From: Stefano Garzarella To: Freddie Cash Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Hans Petter Selasky , Adrian Chadd , "freebsd-net@freebsd.org" , George Neville-Neil , freebsd-current , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 16:47:41 -0000 Hi Freddie, this is a preliminary version and, for now, we have not analyzed all aspects. Thanks for your suggestion. We will try to analyze how the GSO affects IPFW as soon as possible. Cheers, Stefano 2014-09-18 17:27 GMT+02:00 Freddie Cash : > On Thu, Sep 18, 2014 at 7:16 AM, Stefano Garzarella < > stefanogarzarella@gmail.com> wrote: > >> I saw the discussion about TSO, but the GSO is a software >> implementation unrelated with the hardware. >> Furthermore, if the TSO is enabled (and supported by the NIC), the GSO i= s >> not executed, because is useless. >> >> After the execution of the GSO, the packets, that are passed to the devi= ce >> driver, are smaller (or equal) than MTU, so the TSO is unnecessary. For >> this reason the GSO doesn't look neither "ifp->if_hw_tsomax" nor hardwar= e >> segment limits. >> >> The GSO is very useful when you can't use the TSO. >> > > =E2=80=8BHow does GSO affect IPFW, specifically the libalias(3)-based, in= -kernel > NAT? The ipfw(8) man page mentions that it doesn't play nicely with > hardware-based TSO, and that one should disable TSO when using IPFW NAT. > > Will the software-based GSO play nicely with IPFW NAT?=E2=80=8B Will it = make any > difference to packet throughput through IPFW? > > Or is it still way too early in development to be worrying about such > things? :) > > -- > Freddie Cash > fjwcash@gmail.com > --=20 *Stefano Garzarella* stefano.garzarella@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 17:07:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51998908; Sat, 20 Sep 2014 17:07:06 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CBC8DDE; Sat, 20 Sep 2014 17:07:05 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s8KH6xBo096804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Sep 2014 20:06:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s8KH6xBo096804 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s8KH6wFY096803; Sat, 20 Sep 2014 20:06:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 20 Sep 2014 20:06:58 +0300 From: Konstantin Belousov To: John Baldwin Subject: Re: libthr and main thread stack size Message-ID: <20140920170658.GE2210@kib.kiev.ua> References: <53E36E84.4060806@ivan-labs.com> <20140916081324.GQ2737@kib.kiev.ua> <5242716.s4iaScq0Bu@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pAwQNkOnpTn9IO2O" Content-Disposition: inline In-Reply-To: <5242716.s4iaScq0Bu@ralph.baldwin.cx> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "Ivan A. Kosarev" , freebsd-current@freebsd.org, doc@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 17:07:06 -0000 --pAwQNkOnpTn9IO2O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 19, 2014 at 03:27:25PM -0400, John Baldwin wrote: > I suspect it was done out of reasons of being overly conservative in > interpreting RLIMIT_STACK. I think it is quite surprising behavior > though and would rather we make your option the default and implement > what the Open Group says above. Ok, below is the patch. I felt bad about adding yet another magic and undocumented tunable to our libthr. Since there seems to be no alternative than a tunable to enforce old behaviour, I documented the quirks I am aware of. Doc people, please review the man page in the patch. diff --git a/lib/libthr/thread/thr_init.c b/lib/libthr/thread/thr_init.c index 9bf0e29..72a067a 100644 --- a/lib/libthr/thread/thr_init.c +++ b/lib/libthr/thread/thr_init.c @@ -445,7 +445,7 @@ init_private(void) struct rlimit rlim; size_t len; int mib[2]; - char *env; + char *env, *env_bigstack, *env_splitstack; =20 _thr_umutex_init(&_mutex_static_lock); _thr_umutex_init(&_cond_static_lock); @@ -473,8 +473,9 @@ init_private(void) len =3D sizeof (_usrstack); if (sysctl(mib, 2, &_usrstack, &len, NULL, 0) =3D=3D -1) PANIC("Cannot get kern.usrstack from sysctl"); - env =3D getenv("LIBPTHREAD_BIGSTACK_MAIN"); - if (env !=3D NULL) { + env_bigstack =3D getenv("LIBPTHREAD_BIGSTACK_MAIN"); + env_splitstack =3D getenv("LIBPTHREAD_SPLITSTACK_MAIN"); + if (bigstack !=3D NULL || env_splitstack =3D=3D NULL) { if (getrlimit(RLIMIT_STACK, &rlim) =3D=3D -1) PANIC("Cannot get stack rlimit"); _thr_stack_initial =3D rlim.rlim_cur; diff --git a/share/man/man7/libthr.7 b/share/man/man7/libthr.7 new file mode 100644 index 0000000..16d916f --- /dev/null +++ b/share/man/man7/libthr.7 @@ -0,0 +1,254 @@ +.\" Copyright (c) 2014 The FreeBSD Foundation, Inc. +.\" All rights reserved. +.\" +.\" This documentation was written by Konstantin Belousov +.\" under sponsorship from the FreeBSD Foundation. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PUR= POSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIAB= LE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUEN= TIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, ST= RICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY = WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" $FreeBSD$ +.\" +.Dd September 20, 2014 +.Dt libthr +.Os +.Sh NAME +.Nm libthr +.Nd FreeBSD implementation of the Posix threading library +.Sh LIBRARY +.Lb libpthread +.Sh DESCRIPTION +The man page documents the quirks and tunables of the +.Fx +implementation for the +.Lb libpthread . +When linking with the +.Li -lpthread , +the run-time dependency +.Dv libthr.so.3 +library is recorded in the produced object. +.Pp +The library is tigthly integrated with the Run-time Link-editor +.Xr ld-elf.so.1 1 +and +.Lb libc , +all three components must be built from the same source tree. +Mixing +.Dv libc.so +and +.Nm +libraries from different versions of +.Fx +is not supported. +The run-time linker +.Li ld-elf.so.1 +has some code to ensure backward-compatibility with older +.Nm . +.Sh MUTEX ACQUISITION +The locked mutex (see +.Xr pthread_mutex_lock 3 ) +is represented by a volatile variable of type +.Dv lwpid_t , +which records the global system identifier of the thread +owning the lock. +The +.Nm +performs a congested mutex acquisition in three stages, each of which +is more resource-consuming than the previous. +.Pp +First, the +.Li spin loop +is performed, where the library attempts to acquire the lock by +.Xr atomic 9 +operations. +The loop count is controlled by the +.Ev LIBPTHREAD_SPINLOOPS +environment variable. +.Pp +If the +.Li spin loop +was unable to acquire the mutex, the +.Li yield loop +is executed, performing the same +.Xr atomic 9 +acquisition attempts as +.Li spin loop , +but each attempt is followed by yield of the CPU time of the thread by +.Xr sched_yield 2 +syscall. +By default, the +.Li yield loop +is not executed. +This is controlled by +.Ev LIBPTHREAD_YIELDLOOPS +environment variable. +.Pp +If both +.Li spin +and +.Li yield loops +failed to acquire the lock, the thread is taken off the CPU and +put to sleep in kernel with the +.Xr umtx 2 +syscall. +Kernel wakes up a thread and hands the ownership of the lock to +the woken thread. +.Sh THREADS STACKS +Each thread is provided with the private stack area used by C runtime. +The size of the main (initial) thread stack is set by kernel, and is +controlled by the +.Dv RLIMIT_STACK +process resource limit (see +.Xr getrlimit 2 ) . +.Pp +By default, the main thread size is equal to the value of resource +.Dv RLIMIT_STACK +for the process. +If the +.Dv LIBPTHREAD_SPLITSTACK_MAIN +environment variable is present (its value does not matter), +the main thread size if chomped to 4MB on 64bit architectures, and to +2MB on 32bit architectures, on the threading library initialization. +The rest of the address space area reserved by the kernel for initial +process stack, is used for non-initial threads stack in this case. +The presence of the +.Dv LIBPTHREAD_BIGSTACK_MAIN +environment variable overrides the +.Dv LIBPTHREAD_SPLITSTACK_MAIN , +it is kept for backward-compatibility. +.Pp +The size of the stacks for threads created by the process at run-time +with the +.Xr pthread_create 3 +call, is controlled by thread attributes, see +.Xr pthread_attr 3 , +in particular, the +.Xr pthread_attr_setstacksize 3 , +.Xr pthread_attr_setguardsize 3 +and +.Xr pthread_attr_setstackaddr 3 . +If no attributes for the thread stack size are specified, the default +non-initial thread stack size is 2MB for 64bit architectures, and 1MB +for 32bit architectures. +.Sh RUN-TIME SETTINGS +The following environment variables are recognized by +.Dv libthr +and adjust the operation of the library at run-time: +.Bl -tag -width LIBPTHREAD_SPLITSTACK_MAIN +.It Ev LIBPTHREAD_BIGSTACK_MAIN +Disables the chomp of the initial thread stack, enabled by +.Ev LIBPTHREAD_SPLITSTACK_MAIN . +.It Ev LIBPTHREAD_SPLITSTACK_MAIN +Causes the chomp of the initial thread stack, as described in the +section +.Li THREAD_STACKS . +This was the default behaviour of the +.Nm +before +.Fx 11.0 . +.It Ev LIBPTHREAD_SPINLOOPS +The integer value of the variable overrides the default count of +iterations in the +.Li spin loop +of the mutex acquisition. +The default count is 2000, set by the +.Dv MUTEX_ADAPTIVE_SPINS +define in the +.Nm +sources. +.It Ev LIBPTHREAD_YIELDLOOPS +The non-zero integer value of the variable allows the +.Li yield loop +in the process of the mutex acquisition. +The value is the counter of loop operations. +.It Ev LIBPTHREAD_QUEUE_FIFO +The integer value of the variable specifies how often the blocked +threads are put into the head of the sleep queue, instead of it tail. +The bigger value reduces the frequency of the FIFO discipline. +The value must be between 0 and 255. +.El +.Sh INTERACTION WITH RUN-TIME LINKER. +The +.Nm +library must appear before +.Dv libc +in the global order of depended objects. +.Pp +.Pp +Loading the +.Nm +library with the +.Xr dlopen 3 +call in the process after the program binary is activated, +is not supported, and causes miscellaneous and hard to diagnose misbehavio= ur. +This is due to +.Nm +interposing several important +.Dv libc +symbols to provide thread-safe services. +In particular, +.Dv errno +and locking stubs from +.Dv libc +are affected. +This requirement is currently not enforced. +.Pp +If the program loads the modules at run-time, and modules may require +the threading services, the main program binary must be linked with +.Dv libpthread , +even if it does not require any service from the library. +.Pp +The library cannot be unloaded, the +.Xr dlclose 3 +function does not perform any action when called with a handle for +.Dv libthr . +One of the reason is that interposing of +.Dv libc +functions cannot be undone. +.Sh SIGNALS +The implementation also interposes the user-installed +.Xr signal 3 +handlers. +The interposing is done to postpone signal delivery to threads which +entered the (libthr-internal) critical sections, where the calling +of the signal handler is unsafe. +Example of such situation is owning the internal library lock. +When the signal is delivered while signal handler cannot be safely +called, call is postponed and performed after the critical section +is left. +This should be taken into account when interpreting the +.Xr ktrace 1 +logs. +.Sh SEE ALSO +.Xr atomic 9 , +.Xr dlclose 3 , +.Xr dlopen 3 , +.Xr errno 3 , +.Xr getenv 3 , +.Xr getrlimit 2 , +.Xr ktrace 1 , +.Xr ld-elf.so.1 1 , +.Xr libc 3 , +.Xr pthread_attr 3 , +.Xr pthread_attr_setstacksize 3 , +.Xr pthread_create 3 , +.Xr signal 3 , +.Xr umtx 2 . --pAwQNkOnpTn9IO2O Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUHbQxAAoJEJDCuSvBvK1BJowQAIkGc0gokVCcaGUUXT+WPkuE 2u49WokeTewPizBT0040afss1FKeyeDKI5Gn+mogNl0IIh7XCOLNpL0B3qFtWf44 Ie3hkuuSN+p47e1auaN7KBuRAyWVHCVdJsXsEEO/MiJT8tqVt+fZiLfvSmNAWrse 9hgYupxmQRsNRRTz6m22zdRxAWZVhvM56pt/oFaHbM5DGXw2C9nNqg3EKZjnpqtc A7uXJelz95k5T/mXK0yxr/aoG/rHv4ON57slvp1cRD+6PiSlsOsR3TWYRPmUgFZO KEjBknEhSsuaXlh02fjMbY/Ht0r9VqTdijmYffnwxmF3cn4flCewn86zO+6mGo9B 162AS5XpxNMJsudCK/sP9+4VyxICB5A/V7LXESBNYVt67Et6jJBNBZXu50xbMTU+ l5wrx2mMc4XlDQZZM+KRnynzxF3B8FoAUBOvQV2Rw58hLqooJ1HR5rf1HJIdZ2yw nJr7GH6hIsLYOTDGLHiZpMAYJMwgsAlm++ZPqQAf6a8P3Fqs9A0X40BC07JHS+G5 dCSJgtFd9nzuo75V7qyFpCZVPM4+q9jayWILihcrdjFi6ZuDDpMLjuqaxRHVVP/G dw9FiV/W8u+Gx2cFdwUPcYQTbxgjgb5DFuTnmln9pRqiWTndwqk7hM6foMEG8qT9 f3QBuQLeUJrKqWpNAzfB =z6GS -----END PGP SIGNATURE----- --pAwQNkOnpTn9IO2O-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 17:15:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4A04C36; Sat, 20 Sep 2014 17:15:39 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FD121C4; Sat, 20 Sep 2014 17:15:39 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XVOG1-002qKn-Bn>; Sat, 20 Sep 2014 19:15:37 +0200 Received: from g225119140.adsl.alicedsl.de ([92.225.119.140] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XVOG1-003KeK-39>; Sat, 20 Sep 2014 19:15:37 +0200 Date: Sat, 20 Sep 2014 19:15:30 +0200 From: "O. Hartmann" To: Warren Block Subject: Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT Message-ID: <20140920191530.6b538c62.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20140919201210.72650231.ohartman@zedat.fu-berlin.de> <20140920161012.02844320.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/DcMqZwnwul8SCQIAk6B.oTy"; protocol="application/pgp-signature" X-Originating-IP: 92.225.119.140 X-ZEDAT-Hint: A Cc: freebsd-x11@freebsd.org, FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 17:15:39 -0000 --Sig_/DcMqZwnwul8SCQIAk6B.oTy Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sat, 20 Sep 2014 08:27:27 -0600 (MDT) Warren Block schrieb: > On Sat, 20 Sep 2014, O. Hartmann wrote: >=20 > > Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) > > Warren Block schrieb: > > > >> On Fri, 19 Sep 2014, O. Hartmann wrote: > >> > >>> nVidia's BLOB from port x11/nvidia-driver seems to have problems in F= reeBSD > >>> 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Leno= vo ThinkPad > >>> Edge E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 I= ntel iGPU and > >>> dedicated nVidia GT 740M (Optimus) working correctly. > >> > >> Optimus is supposed to be full Intel graphics plus an Nvidia GPU. The > >> extra GPU uses the same display memory and can be enabled to speed up > >> the Intel graphics or disabled for power saving. I don't know if > >> versions where the Nvidia section is a full discrete video adapter that > >> can be used alone are still called "Optimus". > >> > >> Some Optimus owners have reported being able to use the Intel drivers > >> after disabling the Nvidia GPU in the BIOS or UEFI. If an option to > >> disable the Nvidia GPU is not present, some people have reported succe= ss > >> with an xorg.conf that uses only the intel driver and ignores the Nvid= ia > >> hardware. > > > > Thanks Warren. > > > > But this sounds even more frustrating now. I look around the web even a= t Lenovo's > > support forum. Many people report the GT 740M nVidia adaptor as a discr= ete adaptor > > with Optimus technology and everything sounds to me like it can be sele= cted > > exclusively. What you describes is that I definitely need to use the HD= 4600 iGPU on > > FreeBSD in the first place since the nVidia hardware is a kind of "appe= ndix" to the > > HD4600. >=20 > Optimus started out that way, but they might use the same name now for=20 > models where the additional GPU is a full discrete adapter. I tried to retrieve informations about the settings and implementations in= the lenovo E540, but I guess the only answer can be given by developer documentation. = I can not figure out how the GPU is attached to the system. The technical specificati= ons do not mention the requirement of a iGPU and shared memory - as Optimus would requ= ire. But extrapolating from that "shit-covering" public relations talking at nVi= dia's site I guess the GT 740M is definitely a shared memory solution and requires the p= resence of the iGPU. That would explain why the nvidia BLOB is detecting the GPU, but = can not find any physical display socket, not even the built-in LCD. They're maybe wired= all throught the Haswell's HD4600 iGPU?=20 >=20 > > Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't wo= rk properly: it > > doesn't even start up and loading the "intel" driver complains about a = missing device > > - preceeded by a lot of /dev/dri errors. This indicates to me, in a nai= v manner, that > > this HD4600 isn't recodnized by the kernel, either. I do not see any ki= nd of vga0: > > entry in the kernel log when enabling "Integrated Graphics" only in the= laptop's > > UEFI/Firmware. When enabling "nVidia Optimus", a recognized vga0: devic= e shows up. >=20 > Whoops, HD4600 is Haswell. The intel driver on FreeBSD does not support= =20 > Haswell video yet. I suspected that :-( Thanks anyway, Oliver --Sig_/DcMqZwnwul8SCQIAk6B.oTy Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUHbY3AAoJEOgBcD7A/5N82ZwH/RHrHH/93U89F4A8jkTEEiOe 5u7mlGTnoN/YO8RG2U+npJrfx9Yq0IYglgBPH5qbu+4Ng008Q328JPko7nVEm/Vu LDElH7eknEC6wvUxFrWD8LCVfFV0YG19Q1E4AJqYjjfj4+iUZX/SEnYGhQKiokL9 yXcoP8VVbT37iYBgWkawRdXt3Prp/ad3p4h0cI42blrULr7gnpAVziA0ON8Xir5Z taFrHCJEVRWm7tzbcRGXDopXADt48jbGCvnoQftVX/89bLpOWvzCZX9zfgEhFrpP Nrp1NxnMGJ3V9uiGvFr3uAgz0P+jfj5IpFU/5CvdG2qCr1HdhTyX6EkmqUUjj1I= =AmER -----END PGP SIGNATURE----- --Sig_/DcMqZwnwul8SCQIAk6B.oTy-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 18:13:57 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77E8CA32; Sat, 20 Sep 2014 18:13:57 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0218892A; Sat, 20 Sep 2014 18:13:56 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XVPAQ-002y9d-R0>; Sat, 20 Sep 2014 20:13:54 +0200 Received: from g225119140.adsl.alicedsl.de ([92.225.119.140] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XVPAQ-003QI9-Jj>; Sat, 20 Sep 2014 20:13:54 +0200 Date: Sat, 20 Sep 2014 20:13:47 +0200 From: "O. Hartmann" To: Warren Block Subject: Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT Message-ID: <20140920201347.0a4b9658.ohartman@zedat.fu-berlin.de> In-Reply-To: <20140920191530.6b538c62.ohartman@zedat.fu-berlin.de> References: <20140919201210.72650231.ohartman@zedat.fu-berlin.de> <20140920161012.02844320.ohartman@zedat.fu-berlin.de> <20140920191530.6b538c62.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/e0nZ7=37..Fjcs67e0DDPKx"; protocol="application/pgp-signature" X-Originating-IP: 92.225.119.140 X-ZEDAT-Hint: A Cc: freebsd-x11@freebsd.org, FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 18:13:57 -0000 --Sig_/e0nZ7=37..Fjcs67e0DDPKx Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sat, 20 Sep 2014 19:15:30 +0200 "O. Hartmann" schrieb: > Am Sat, 20 Sep 2014 08:27:27 -0600 (MDT) > Warren Block schrieb: >=20 > > On Sat, 20 Sep 2014, O. Hartmann wrote: > >=20 > > > Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) > > > Warren Block schrieb: > > > > > >> On Fri, 19 Sep 2014, O. Hartmann wrote: > > >> > > >>> nVidia's BLOB from port x11/nvidia-driver seems to have problems in= FreeBSD > > >>> 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Le= novo ThinkPad > > >>> Edge E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600= Intel iGPU and > > >>> dedicated nVidia GT 740M (Optimus) working correctly. > > >> > > >> Optimus is supposed to be full Intel graphics plus an Nvidia GPU. T= he > > >> extra GPU uses the same display memory and can be enabled to speed up > > >> the Intel graphics or disabled for power saving. I don't know if > > >> versions where the Nvidia section is a full discrete video adapter t= hat > > >> can be used alone are still called "Optimus". > > >> > > >> Some Optimus owners have reported being able to use the Intel drivers > > >> after disabling the Nvidia GPU in the BIOS or UEFI. If an option to > > >> disable the Nvidia GPU is not present, some people have reported suc= cess > > >> with an xorg.conf that uses only the intel driver and ignores the Nv= idia > > >> hardware. > > > > > > Thanks Warren. > > > > > > But this sounds even more frustrating now. I look around the web even= at Lenovo's > > > support forum. Many people report the GT 740M nVidia adaptor as a dis= crete adaptor > > > with Optimus technology and everything sounds to me like it can be se= lected > > > exclusively. What you describes is that I definitely need to use the = HD4600 iGPU on > > > FreeBSD in the first place since the nVidia hardware is a kind of "ap= pendix" to the > > > HD4600. > >=20 > > Optimus started out that way, but they might use the same name now for= =20 > > models where the additional GPU is a full discrete adapter. >=20 > I tried to retrieve informations about the settings and implementations = in the lenovo > E540, but I guess the only answer can be given by developer documentation= . I can not > figure out how the GPU is attached to the system. The technical specifica= tions do not > mention the requirement of a iGPU and shared memory - as Optimus would re= quire. >=20 > But extrapolating from that "shit-covering" public relations talking at n= Vidia's site I > guess the GT 740M is definitely a shared memory solution and requires the= presence of > the iGPU. That would explain why the nvidia BLOB is detecting the GPU, bu= t can not find > any physical display socket, not even the built-in LCD. They're maybe wir= ed all throught > the Haswell's HD4600 iGPU?=20 >=20 > >=20 > > > Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't = work properly: > > > it doesn't even start up and loading the "intel" driver complains abo= ut a missing > > > device > > > - preceeded by a lot of /dev/dri errors. This indicates to me, in a n= aiv manner, > > > that this HD4600 isn't recodnized by the kernel, either. I do not see= any kind of > > > vga0: entry in the kernel log when enabling "Integrated Graphics" onl= y in the > > > laptop's UEFI/Firmware. When enabling "nVidia Optimus", a recognized = vga0: device > > > shows up. > >=20 > > Whoops, HD4600 is Haswell. The intel driver on FreeBSD does not suppor= t=20 > > Haswell video yet. >=20 >=20 > I suspected that :-( >=20 > Thanks anyway, >=20 > Oliver Oh, by the way, where is x11-drivers/xf86-video-noveau? I can only find x11-drivers/xf86-video-nv, which covers old hardware and it is not applicab= le to the GT 740M (complains, rightfully, that the found device isn't supported by the "= nv" driver). I face a mess here ... :-( --Sig_/e0nZ7=37..Fjcs67e0DDPKx Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUHcPgAAoJEOgBcD7A/5N8J3QH/0O8FK25GlIF/g47wQMTDNt+ EWg85fHgU80dq3zUc/a4TsHWKLWbGE3PuhMCmrHDbmMeKPpdsoHkos6BQoFwr/E+ 5S3EQoj0/Lce3H1Q7spg0BNhomk1V48pFrKVF8++zglGd0itnvybYXYvCdsgU/O4 L/0ZSuWfHw7roIMzDYwGyvpigEoPKtn2FhnCDztv1GVDckNq5t4YhEO0hAznPC88 A5k7r3+7hsUce9OXvDySWDylTQBHLfsbm0C1jPpwLoanmCmJHfCZl7AyzbE28PhQ N+/jy6q8JQHTOFY8JK+BrLiVoXsP9+oDSE4fXOyv/2tT3nyLjDC1rF7fqCmmbn4= =QK4n -----END PGP SIGNATURE----- --Sig_/e0nZ7=37..Fjcs67e0DDPKx-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 18:44:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1BD3A1CA; Sat, 20 Sep 2014 18:44:28 +0000 (UTC) Received: from mail.bein.link (bein.link [37.252.124.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D181BBCB; Sat, 20 Sep 2014 18:44:27 +0000 (UTC) Received: from quad.localnet (home.bein.link [172.16.32.6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bein.link (Postfix) with ESMTPS id 2272C1AF374; Sat, 20 Sep 2014 18:44:24 +0000 (UTC) From: Maxim V FIlimonov To: freebsd-current@freebsd.org Subject: FreeBSD-11.0-CURRENT on ARM: performance and load average Date: Sat, 20 Sep 2014 22:44:23 +0400 Message-ID: <7351653.A2UeEk9AA3@quad> User-Agent: KMail/4.12.5 (FreeBSD/10.0-RELEASE-p8; KDE/4.12.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: freebsd-arm@freebsd.org, mav@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 18:44:28 -0000 Hello everyone, Recently, I encountered a problem with -CURRENT on an ARM board (cubieboard2 to be precise). The problem was that the load average was above 2. Including the fact that the board has 2 CPU cores, that's strange. Also, the network throughput was way too slow: from 3 kilobytes per second earlier to 20..50 about now. Here's a workaround for that: > sysctl kern.eventtimer.periodic=1 With that, the network performance increased while LA decreased to a decent 0.3..0.5. -- wbr, Maxim Filimonov che@bein.link From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 18:46:04 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4624C374; Sat, 20 Sep 2014 18:46:04 +0000 (UTC) Received: from mail.bein.link (bein.link [37.252.124.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 07036BE2; Sat, 20 Sep 2014 18:46:03 +0000 (UTC) Received: from quad.localnet (home.bein.link [172.16.32.6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bein.link (Postfix) with ESMTPS id EDB531AF279; Sat, 20 Sep 2014 18:36:53 +0000 (UTC) From: Maxim V FIlimonov To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org, mav@freebsd.org Subject: FreeBSD-11.0-CURRENT on ARM: performance and load average Date: Sat, 20 Sep 2014 22:36:43 +0400 Message-ID: <6819027.8v2Z16lWiU@quad> User-Agent: KMail/4.12.5 (FreeBSD/10.0-RELEASE-p8; KDE/4.12.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 18:46:04 -0000 Hello everyone, Recently, I encountered a problem with -CURRENT on an ARM board (cubieboard2 to be precise). The problem was that the load average was above 2. Including the fact that the board has 2 CPU cores, that's strange. Also, the network throughput was way too slow: from 3 kilobytes per second earlier to 20..50 about now. Here's a workaround for that: > sysctl kern.eventtimer.periodic=1 With that, the network performance increased while LA decreased to a decent 0.3..0.5. -- wbr, Maxim Filimonov che@bein.link From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 19:22:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41239D74; Sat, 20 Sep 2014 19:22:53 +0000 (UTC) Received: from fep20.mx.upcmail.net (fep20.mx.upcmail.net [62.179.121.40]) by mx1.freebsd.org (Postfix) with ESMTP id 66D6BF2E; Sat, 20 Sep 2014 19:22:51 +0000 (UTC) Received: from edge04.upcmail.net ([192.168.13.239]) by viefep20-int.chello.at (InterMail vM.8.01.05.13 201-2260-151-135-20130320) with ESMTP id <20140920192249.RDGS24820.viefep20-int.chello.at@edge04.upcmail.net>; Sat, 20 Sep 2014 21:22:49 +0200 Received: from [192.168.1.60] ([95.96.229.21]) by edge04.upcmail.net with edge id tXNa1o0180ULilr01XNbBn; Sat, 20 Sep 2014 21:22:35 +0200 X-SourceIP: 95.96.229.21 Message-ID: <1411240906.1174.2.camel@rainbow-runner.nl> Subject: Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT From: Koop Mast To: "O. Hartmann" Date: Sat, 20 Sep 2014 21:21:46 +0200 In-Reply-To: <20140920201347.0a4b9658.ohartman@zedat.fu-berlin.de> References: <20140919201210.72650231.ohartman@zedat.fu-berlin.de> <20140920161012.02844320.ohartman@zedat.fu-berlin.de> <20140920191530.6b538c62.ohartman@zedat.fu-berlin.de> <20140920201347.0a4b9658.ohartman@zedat.fu-berlin.de> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.6 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: Warren Block , freebsd-x11@freebsd.org, FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 19:22:53 -0000 On Sat, 2014-09-20 at 20:13 +0200, O. Hartmann wrote: > Am Sat, 20 Sep 2014 19:15:30 +0200 > "O. Hartmann" schrieb: > > > Am Sat, 20 Sep 2014 08:27:27 -0600 (MDT) > > Warren Block schrieb: > > > > > On Sat, 20 Sep 2014, O. Hartmann wrote: > > > > > > > Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) > > > > Warren Block schrieb: > > > > > > > >> On Fri, 19 Sep 2014, O. Hartmann wrote: > > > >> > > > >>> nVidia's BLOB from port x11/nvidia-driver seems to have problems in FreeBSD > > > >>> 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo ThinkPad > > > >>> Edge E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 Intel iGPU and > > > >>> dedicated nVidia GT 740M (Optimus) working correctly. > > > >> > > > >> Optimus is supposed to be full Intel graphics plus an Nvidia GPU. The > > > >> extra GPU uses the same display memory and can be enabled to speed up > > > >> the Intel graphics or disabled for power saving. I don't know if > > > >> versions where the Nvidia section is a full discrete video adapter that > > > >> can be used alone are still called "Optimus". > > > >> > > > >> Some Optimus owners have reported being able to use the Intel drivers > > > >> after disabling the Nvidia GPU in the BIOS or UEFI. If an option to > > > >> disable the Nvidia GPU is not present, some people have reported success > > > >> with an xorg.conf that uses only the intel driver and ignores the Nvidia > > > >> hardware. > > > > > > > > Thanks Warren. > > > > > > > > But this sounds even more frustrating now. I look around the web even at Lenovo's > > > > support forum. Many people report the GT 740M nVidia adaptor as a discrete adaptor > > > > with Optimus technology and everything sounds to me like it can be selected > > > > exclusively. What you describes is that I definitely need to use the HD4600 iGPU on > > > > FreeBSD in the first place since the nVidia hardware is a kind of "appendix" to the > > > > HD4600. > > > > > > Optimus started out that way, but they might use the same name now for > > > models where the additional GPU is a full discrete adapter. > > > > I tried to retrieve informations about the settings and implementations in the lenovo > > E540, but I guess the only answer can be given by developer documentation. I can not > > figure out how the GPU is attached to the system. The technical specifications do not > > mention the requirement of a iGPU and shared memory - as Optimus would require. > > > > But extrapolating from that "shit-covering" public relations talking at nVidia's site I > > guess the GT 740M is definitely a shared memory solution and requires the presence of > > the iGPU. That would explain why the nvidia BLOB is detecting the GPU, but can not find > > any physical display socket, not even the built-in LCD. They're maybe wired all throught > > the Haswell's HD4600 iGPU? > > > > > > > > > Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't work properly: > > > > it doesn't even start up and loading the "intel" driver complains about a missing > > > > device > > > > - preceeded by a lot of /dev/dri errors. This indicates to me, in a naiv manner, > > > > that this HD4600 isn't recodnized by the kernel, either. I do not see any kind of > > > > vga0: entry in the kernel log when enabling "Integrated Graphics" only in the > > > > laptop's UEFI/Firmware. When enabling "nVidia Optimus", a recognized vga0: device > > > > shows up. > > > > > > Whoops, HD4600 is Haswell. The intel driver on FreeBSD does not support > > > Haswell video yet. > > > > > > I suspected that :-( > > > > Thanks anyway, > > > > Oliver > > Oh, by the way, where is x11-drivers/xf86-video-noveau? I can only find > x11-drivers/xf86-video-nv, which covers old hardware and it is not applicable to the GT > 740M (complains, rightfully, that the found device isn't supported by the "nv" driver). > > I face a mess here ... :-( It was removed, because we missing kernel support for the nouveau driver. From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 19:24:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E98EFEE5; Sat, 20 Sep 2014 19:24:17 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 61AE3F48; Sat, 20 Sep 2014 19:24:17 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XVQGQ-0001If-DY; Sat, 20 Sep 2014 19:24:10 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s8KJO9qr016862; Sat, 20 Sep 2014 13:24:09 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/hPFpEMvfkAv00kf34fk4v X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: FreeBSD-11.0-CURRENT on ARM: performance and load average From: Ian Lepore To: Maxim V FIlimonov In-Reply-To: <7351653.A2UeEk9AA3@quad> References: <7351653.A2UeEk9AA3@quad> Content-Type: multipart/mixed; boundary="=-z+3p5YfilYZLalC+jqRC" Date: Sat, 20 Sep 2014 13:24:08 -0600 Message-ID: <1411241048.66615.148.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org, mav@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 19:24:18 -0000 --=-z+3p5YfilYZLalC+jqRC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sat, 2014-09-20 at 22:44 +0400, Maxim V FIlimonov wrote: > Hello everyone, > > Recently, I encountered a problem with -CURRENT on an ARM board (cubieboard2 > to be precise). The problem was that the load average was above 2. Including > the fact that the board has 2 CPU cores, that's strange. Also, the network > throughput was way too slow: from 3 kilobytes per second earlier to 20..50 > about now. > > Here's a workaround for that: > > sysctl kern.eventtimer.periodic=1 > With that, the network performance increased while LA decreased to a decent > 0.3..0.5. Since it's happening only on that hardware, there's a good chance the problem is in the allwinner a10/a20 clock driver, not in the general eventtimer code. In fact, looking at the code it appears that a divide-by-16 is being set in the hardware, but not accounted for when setting the frequency of the eventtimer. Hmm, it should affect the timecounter too, in which case you'd see time-of-day advancing 16x too fast. If ntpd is running it would need to step the clock pretty frequently, which would show up in syslog. I don't have hardware to test on, please see if the attached patch makes a difference. -- Ian --=-z+3p5YfilYZLalC+jqRC Content-Disposition: inline; filename="allwinner_timer.diff" Content-Type: text/x-patch; name="allwinner_timer.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/arm/allwinner/timer.c =================================================================== --- sys/arm/allwinner/timer.c (revision 271909) +++ sys/arm/allwinner/timer.c (working copy) @@ -199,7 +199,7 @@ a10_timer_attach(device_t dev) val |= TIMER_ENABLE; timer_write_4(sc, SW_TIMER_IRQ_EN_REG, val); - sc->timer0_freq = SYS_TIMER_CLKSRC; + sc->timer0_freq = SYS_TIMER_CLKSRC / 16; /* Set desired frequency in event timer and timecounter */ sc->et.et_frequency = sc->timer0_freq; --=-z+3p5YfilYZLalC+jqRC-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 19:29:46 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D96FC151 for ; Sat, 20 Sep 2014 19:29:46 +0000 (UTC) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C64BF83 for ; Sat, 20 Sep 2014 19:29:45 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id em10so1041937wid.17 for ; Sat, 20 Sep 2014 12:29:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=SRn/w5pnPgNA2ePQGjmy673kf6oAmXF3HYfbRJbKVOU=; b=ZAxuF/Boa+U1UwRKthZ1fZG8/ScKoh9NBtV7ezbtNL2/2N3HcETTGjydh5JEq/DgfH FPiFvHsEurR94H6mhDr00amBSeKsKLWWNXigwql2Epy87VQnpIYeNRDOc79TD5FRNraB Fi7X4vyXxCy46Tnj5EEGPuDJ9OTTukXdIl5fDP2qjvXdUbeae2UiPeMkiQR21IyuKiln 6YdXZGrNKwvt5ZKwhe09x7lt3OKF2aBVR5q96Jp5VZs5aYEq2LRr2hK2nhuMstcyMXrn gl5evvVz+MXvItSmXbWaepEJWCtcN19c8pEYDj1ojdVcLbPbvQ0rdTQBXUMPDumJPqRy Avtw== X-Gm-Message-State: ALoCoQlj46wRakfne3mCFhBXy8MxIFieOwEEwgJ3s1b2NYPayLRjRop+biiGlkz9Cirrz+dvkpJO MIME-Version: 1.0 X-Received: by 10.180.14.101 with SMTP id o5mr5006958wic.25.1411241377976; Sat, 20 Sep 2014 12:29:37 -0700 (PDT) Received: by 10.217.70.69 with HTTP; Sat, 20 Sep 2014 12:29:37 -0700 (PDT) Date: Sat, 20 Sep 2014 13:29:37 -0600 Message-ID: Subject: Crash in GEOM, booting on Soekris From: Tom Everett To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 19:29:47 -0000 I am seeing this crash on r271882, booting a Soekris 4501. POST: 012345689bcefghipsajklnopqr,,,tvwxy comBIOS ver. 1.33 20080103 Copyright (C) 2000-2007 Soekris Engineering. net45xx 0064 Mbyte Memory CPU Elan SC520 133 Mhz Pri Mas SanDisk SDCFX-016G LBA Xlt 1024--63 15625 Mbyte Slot Vend Dev ClassRev Cmd Stat CL LT HT Base1 Base2 Int ------------------------------------------------------------------- 0:00:0 1022 3000 06000000 0006 2280 00 00 00 00000000 00000000 0:18:0 100B 0020 02000000 0107 0290 00 3F 00 0000E001 A0000000 10 0:19:0 100B 0020 02000000 0107 0290 00 3F 00 0000E101 A0001000 11 0:20:0 100B 0020 02000000 0107 0290 00 3F 00 0000E201 A0002000 05 1 Seconds to automatic boot. Press Ctrl-P for entering Monitor. /boot/config: -h Consoles: serial port BIOS drive C: is disk0 BIOS 639kB/64512kB available memory FreeBSD/x86 bootstrap loader, Revision 1.1 (tom@bernice, Fri Sep 19 19:39:16 MDT 2014) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x790cd5 data=0x5e2a0+0x2f0eb8 syms=[0x4+0x89480+0x4+0xebe59] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 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 11.0-CURRENT #0 r271882M: Fri Sep 19 20:21:03 MDT 2014 tom@bernice:/storage/home/tom/crochet-kientzle/crochet-freebsd/work/obj/i386.i386/storage/home/tom/crochet/src/FreeBSDHead/head/sys/SOEKRIS i386 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 WARNING: WITNESS option enabled, expect reduced performance. CPU: AMD Enhanced Am486DX4/Am5x86 Write-Back (486-class CPU) Origin="AuthenticAMD" Id=0x494 Family=0x4 Model=0x9 Stepping=4 Features=0x1 real memory = 67108864 (64 MB) avail memory = 47398912 (45 MB) random device not loaded; using insecure entropy random: initialized module_register_init: MOD_LOAD (vesa, 0xc0a447c0, 0) error 19 kbd1 at kbdmux0 ACPI BIOS Error (bug): A valid RSDP was not found (20130823/tbxfroot-223) ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. sysctl machdep.i8254_freq=1189161 returns 0 Timecounter "ELAN" frequency 8333333 Hz quality 1000 pcib0 pcibus 0 on motherboard pci0: on pcib0 sis0: port 0xe000-0xe0ff mem 0xa0000000-0xa0000fff irq 10 at device 18.0 on pci0 sis0: Silicon Revision: DP83816A miibus0: on sis0 nsphyter0: PHY 0 on miibus0 nsphyter0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:00:24:c8:d4:d4 sis1: port 0xe100-0xe1ff mem 0xa0001000-0xa0001fff irq 11 at device 19.0 on pci0 sis1: Silicon Revision: DP83816A miibus1: on sis1 nsphyter1: PHY 0 on miibus1 nsphyter1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis1: Ethernet address: 00:00:24:c8:d4:d5 sis2: port 0xe200-0xe2ff mem 0xa0002000-0xa0002fff irq 5 at device 20.0 on pci0 sis2: Silicon Revision: DP83816A miibus2: on sis2 nsphyter2: PHY 0 on miibus2 nsphyter2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis2: Ethernet address: 00:00:24:c8:d4:d6 cpu0 on motherboard isa0: on motherboard pmtimer0 on isa0 orm0: at iomem 0xc8000-0xd0fff pnpid ORM0000 on isa0 ata0: at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1: at port 0x170-0x177,0x376 irq 15 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atrtc0: at port 0x70 irq 8 on isa0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: at port 0x40 on isa0 Timecounter "i8254" frequency 1189161 Hz quality 0 Event timer "i8254" frequency 1189161 Hz quality 100 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 Timecounters tick every 1.000 msec interrupt storm detected on "irq5:"; throttling interrupt source Elan-mmcr driver: MMCR at 0xc37ff000. Elan-mmcr Soekris net45xx comBIOS ver. 1.33 20080103 Copyright (C) 2000-2007 random: unblocking device. ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: CFA-0 device ada0: Serial Number AJZ061813191928 ada0: 16.700MB/s transfers (PIO4, PIO 512bytes) ada0: 15259MB (31250432 512 byte sectors: 16H 63S/T 31002C) ada0: Previously was known as ad0 panic: Bio not on queue bp=0xc2aaa4c0 target 0xc0c0f8bc KDB: stack backtrace: db_trace_self_wrapper(c0b3f07a,c29eb800,c2689be4,c06231d1,c29eb830,...) at db_trace_self_wrapper+0x2d/frame 0xc2689bb8 kdb_backtrace(c0b3a646,c0c11888,c0b277fe,c2689c70,c0b277fe,...) at kdb_backtrace+0x30/frame 0xc2689c1c vpanic(c0c11728,100,c0b277fe,c2689c70,c2689c70,...) at vpanic+0x80/frame 0xc2689c40 kassert_panic(c0b277fe,c2aaa4c0,c0c0f8bc,0,c28cfc40,...) at kassert_panic+0xe9/frame 0xc2689c64 g_bioq_first(c0c0f8d4,0,c0b275c0,5c,0,...) at g_bioq_first+0x63/frame 0xc2689c80 g_io_schedule_up(c28cfc40,0,c0b27a0d,60,c2689cf4,...) at g_io_schedule_up+0x94/frame 0xc2689cb4 g_up_procbody(0,c2689d08,c0b33cde,3c9,0,...) at g_up_procbody+0x9d/frame 0xc2689ccc fork_exit(c0706640,0,c2689d08) at fork_exit+0x7f/frame 0xc2689cf4 fork_trampoline() at fork_trampoline+0x8/frame 0xc2689cf4 --- trap 0, eip = 0, esp = 0xc2689d40, ebp = 0 --- KDB: enter: panic [ thread pid 13 tid 100009 ] Stopped at kdb_enter+0x3d: movl $0,kdb_why db> -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 19:31:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3A07290; Sat, 20 Sep 2014 19:31:43 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 918CCA4; Sat, 20 Sep 2014 19:31:43 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s8KJVdol015873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 20 Sep 2014 12:31:41 -0700 Message-ID: <541DD61B.2030803@freebsd.org> Date: Sat, 20 Sep 2014 12:31:39 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Warren Block , "O. Hartmann" Subject: Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT References: <20140919201210.72650231.ohartman@zedat.fu-berlin.de> <20140920161012.02844320.ohartman@zedat.fu-berlin.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVafPsaZu7+JunMmx9YKE+SLrcjthJVW2qqfP9lymgsxUWxlslBEIlWwGOwzzjrcImzTxV+mp0bgV/ggSdQM5G3+PnS9Nhi9oGE= X-Sonic-ID: C;iDBMvvxA5BGAZjZXoK8kYw== M;dh8ov/xA5BGAZjZXoK8kYw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Cc: freebsd-x11@freebsd.org, FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 19:31:43 -0000 On 09/20/14 07:27, Warren Block wrote: > On Sat, 20 Sep 2014, O. Hartmann wrote: > >> Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) >> Warren Block schrieb: >> >>> On Fri, 19 Sep 2014, O. Hartmann wrote: >>> >>>> nVidia's BLOB from port x11/nvidia-driver seems to have problems in >>>> FreeBSD >>>> 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on >>>> Lenovo ThinkPad Edge >>>> E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 >>>> Intel iGPU and >>>> dedicated nVidia GT 740M (Optimus) working correctly. >>> >>> Optimus is supposed to be full Intel graphics plus an Nvidia GPU. The >>> extra GPU uses the same display memory and can be enabled to speed up >>> the Intel graphics or disabled for power saving. I don't know if >>> versions where the Nvidia section is a full discrete video adapter that >>> can be used alone are still called "Optimus". >>> >>> Some Optimus owners have reported being able to use the Intel drivers >>> after disabling the Nvidia GPU in the BIOS or UEFI. If an option to >>> disable the Nvidia GPU is not present, some people have reported >>> success >>> with an xorg.conf that uses only the intel driver and ignores the >>> Nvidia >>> hardware. >> >> Thanks Warren. >> >> But this sounds even more frustrating now. I look around the web even >> at Lenovo's support >> forum. Many people report the GT 740M nVidia adaptor as a discrete >> adaptor with Optimus >> technology and everything sounds to me like it can be selected >> exclusively. What you >> describes is that I definitely need to use the HD4600 iGPU on FreeBSD >> in the first place >> since the nVidia hardware is a kind of "appendix" to the HD4600. > > Optimus started out that way, but they might use the same name now for > models where the additional GPU is a full discrete adapter. > >> Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't >> work properly: it >> doesn't even start up and loading the "intel" driver complains about >> a missing device - >> preceeded by a lot of /dev/dri errors. This indicates to me, in a >> naiv manner, that this >> HD4600 isn't recodnized by the kernel, either. I do not see any kind >> of vga0: entry in >> the kernel log when enabling "Integrated Graphics" only in the >> laptop's UEFI/Firmware. >> When enabling "nVidia Optimus", a recognized vga0: device shows up. > > Whoops, HD4600 is Haswell. The intel driver on FreeBSD does not > support Haswell video yet. > Is there any kind of status update on Haswell? The wiki has the last update 11 months ago and it's becoming a major useability issue for the operating system. -Nathan From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 20:04:37 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A183A970 for ; Sat, 20 Sep 2014 20:04:37 +0000 (UTC) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CFDF387 for ; Sat, 20 Sep 2014 20:04:37 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id jd19so2836298oac.9 for ; Sat, 20 Sep 2014 13:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=uC9BrBFhjA4e9N/O5QUNOii+Ho7jcBoHadP0aCWTntU=; b=N8NeY7vTsO3W54TpuR+NycWo5A0U502KiIE5l1RxfOgPSMplW8Z5afCRQ5ZFnqQGkg iOhCdJgjs6VnruOfYtfVS0rrw5QEVeJtVQZ1GMEskXFsKHb66Pw9HMqwx+k631aSrKsx QGG0IY4myXl6V+QZ9BwvZiObMf9LK2yEdhV0S3DITPjM2A1C/t6J8dnUUBSYuRSTnVms 6YDNonoqekRGCnLM10Zm+COWHM/cpges9T6eIgk7BbvNccJtk8wI4/OZ0qKthOmLWkKR RbsTeXwWJ9Vu7ZfdsDwanXNBPOqxgRedI9tGbWYngwAv+uCZIhXJJwBZqaOhy+LGyEPA rtUQ== MIME-Version: 1.0 X-Received: by 10.182.153.68 with SMTP id ve4mr17132435obb.60.1411243476678; Sat, 20 Sep 2014 13:04:36 -0700 (PDT) Received: by 10.182.228.51 with HTTP; Sat, 20 Sep 2014 13:04:36 -0700 (PDT) Date: Sat, 20 Sep 2014 22:04:36 +0200 Message-ID: Subject: memo: Re: [PATCH] Fix integer overflow handling in dd(1) From: Oliver Pinter To: dev@hardenedbsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, William Orr X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 20:04:37 -0000 pick On 9/20/14, William Orr wrote: > Hey, > > I've submitted this patch before, and it's gotten comments and fixes, > but still hasn't been merged. Any thoughts? Does it need more work? > > Thanks, > William Orr > > Index: args.c > =================================================================== > --- args.c (revision 270645) > +++ args.c (working copy) > @@ -41,6 +41,7 @@ > > #include > > +#include > #include > #include > #include > @@ -171,8 +172,7 @@ > */ > if (in.offset > OFF_MAX / (ssize_t)in.dbsz || > out.offset > OFF_MAX / (ssize_t)out.dbsz) > - errx(1, "seek offsets cannot be larger than %jd", > - (intmax_t)OFF_MAX); > + errx(1, "seek offsets cannot be larger than %jd", OFF_MAX); > } > > static int > @@ -186,37 +186,28 @@ > static void > f_bs(char *arg) > { > - uintmax_t res; > > - res = get_num(arg); > - if (res < 1 || res > SSIZE_MAX) > - errx(1, "bs must be between 1 and %jd", (intmax_t)SSIZE_MAX); > - in.dbsz = out.dbsz = (size_t)res; > + in.dbsz = out.dbsz = get_num(arg); > + if (out.dbsz < 1 || out.dbsz > SSIZE_MAX) > + errx(1, "bs must be between 1 and %jd", SSIZE_MAX); > } > > static void > f_cbs(char *arg) > { > - uintmax_t res; > > - res = get_num(arg); > - if (res < 1 || res > SSIZE_MAX) > - errx(1, "cbs must be between 1 and %jd", (intmax_t)SSIZE_MAX); > - cbsz = (size_t)res; > + cbsz = get_num(arg); > + if (cbsz < 1 || cbsz > SSIZE_MAX) > + errx(1, "cbs must be between 1 and %jd", SSIZE_MAX); > } > > static void > f_count(char *arg) > { > - intmax_t res; > > - res = (intmax_t)get_num(arg); > - if (res < 0) > - errx(1, "count cannot be negative"); > - if (res == 0) > - cpy_cnt = (uintmax_t)-1; > - else > - cpy_cnt = (uintmax_t)res; > + cpy_cnt = get_num(arg); > + if (cpy_cnt == 0) > + cpy_cnt = -1; > } > > static void > @@ -225,7 +216,7 @@ > > files_cnt = get_num(arg); > if (files_cnt < 1) > - errx(1, "files must be between 1 and %jd", (uintmax_t)-1); > + errx(1, "files must be between 1 and %ju", SIZE_MAX); > } > > static void > @@ -241,14 +232,11 @@ > static void > f_ibs(char *arg) > { > - uintmax_t res; > > if (!(ddflags & C_BS)) { > - res = get_num(arg); > - if (res < 1 || res > SSIZE_MAX) > - errx(1, "ibs must be between 1 and %jd", > - (intmax_t)SSIZE_MAX); > - in.dbsz = (size_t)res; > + in.dbsz = get_num(arg); > + if (in.dbsz < 1 || in.dbsz > SSIZE_MAX) > + errx(1, "ibs must be between 1 and %ju", SSIZE_MAX); > } > } > > @@ -262,14 +250,11 @@ > static void > f_obs(char *arg) > { > - uintmax_t res; > > if (!(ddflags & C_BS)) { > - res = get_num(arg); > - if (res < 1 || res > SSIZE_MAX) > - errx(1, "obs must be between 1 and %jd", > - (intmax_t)SSIZE_MAX); > - out.dbsz = (size_t)res; > + out.dbsz = get_num(arg); > + if (out.dbsz < 1 || out.dbsz > SSIZE_MAX) > + errx(1, "obs must be between 1 and %jd", SSIZE_MAX); > } > } > > @@ -378,11 +363,17 @@ > uintmax_t num, mult, prevnum; > char *expr; > > + while (isspace(val[0])) > + val++; > + > + if (val[0] == '-') > + errx(1, "%s: cannot be negative", oper); > + > errno = 0; > - num = strtouq(val, &expr, 0); > + num = strtoull(val, &expr, 0); > if (errno != 0) /* Overflow or underflow. */ > err(1, "%s", oper); > - > + > if (expr == val) /* No valid digits. */ > errx(1, "%s: illegal numeric value", oper); > > Index: conv.c > =================================================================== > --- conv.c (revision 270645) > +++ conv.c (working copy) > @@ -133,7 +133,7 @@ > */ > ch = 0; > for (inp = in.dbp - in.dbcnt, outp = out.dbp; in.dbcnt;) { > - maxlen = MIN(cbsz, in.dbcnt); > + maxlen = MIN(cbsz, (size_t)in.dbcnt); > if ((t = ctab) != NULL) > for (cnt = 0; cnt < maxlen && (ch = *inp++) != '\n'; > ++cnt) > @@ -146,7 +146,7 @@ > * Check for short record without a newline. Reassemble the > * input block. > */ > - if (ch != '\n' && in.dbcnt < cbsz) { > + if (ch != '\n' && (size_t)in.dbcnt < cbsz) { > (void)memmove(in.db, in.dbp - in.dbcnt, in.dbcnt); > break; > } > @@ -228,7 +228,7 @@ > * translation has to already be done or we might not recognize the > * spaces. > */ > - for (inp = in.db; in.dbcnt >= cbsz; inp += cbsz, in.dbcnt -= cbsz) { > + for (inp = in.db; (size_t)in.dbcnt >= cbsz; inp += cbsz, in.dbcnt > -= cbsz) { > for (t = inp + cbsz - 1; t >= inp && *t == ' '; --t) > ; > if (t >= inp) { > Index: dd.c > =================================================================== > --- dd.c (revision 270645) > +++ dd.c (working copy) > @@ -168,10 +168,10 @@ > * record oriented I/O, only need a single buffer. > */ > if (!(ddflags & (C_BLOCK | C_UNBLOCK))) { > - if ((in.db = malloc(out.dbsz + in.dbsz - 1)) == NULL) > + if ((in.db = malloc((size_t)out.dbsz + in.dbsz - 1)) == NULL) > err(1, "input buffer"); > out.db = in.db; > - } else if ((in.db = malloc(MAX(in.dbsz, cbsz) + cbsz)) == NULL || > + } else if ((in.db = malloc(MAX((size_t)in.dbsz, cbsz) + cbsz)) == > NULL || > (out.db = malloc(out.dbsz + cbsz)) == NULL) > err(1, "output buffer"); > > @@ -343,7 +343,7 @@ > ++st.in_full; > > /* Handle full input blocks. */ > - } else if ((size_t)n == in.dbsz) { > + } else if ((size_t)n == (size_t)in.dbsz) { > in.dbcnt += in.dbrcnt = n; > ++st.in_full; > > @@ -493,7 +493,7 @@ > outp += nw; > st.bytes += nw; > > - if ((size_t)nw == n && n == out.dbsz) > + if ((size_t)nw == n && n == (size_t)out.dbsz) > ++st.out_full; > else > ++st.out_part; > Index: dd.h > =================================================================== > --- dd.h (revision 270645) > +++ dd.h (working copy) > @@ -38,10 +38,9 @@ > typedef struct { > u_char *db; /* buffer address */ > u_char *dbp; /* current buffer I/O address */ > - /* XXX ssize_t? */ > - size_t dbcnt; /* current buffer byte count */ > - size_t dbrcnt; /* last read byte count */ > - size_t dbsz; /* block size */ > + ssize_t dbcnt; /* current buffer byte count */ > + ssize_t dbrcnt; /* last read byte count */ > + ssize_t dbsz; /* block size */ > > #define ISCHR 0x01 /* character device (warn on short) > */ > #define ISPIPE 0x02 /* pipe-like (see position.c) */ > @@ -57,13 +56,13 @@ > } IO; > > typedef struct { > - uintmax_t in_full; /* # of full input blocks */ > - uintmax_t in_part; /* # of partial input blocks */ > - uintmax_t out_full; /* # of full output blocks */ > - uintmax_t out_part; /* # of partial output blocks */ > - uintmax_t trunc; /* # of truncated records */ > - uintmax_t swab; /* # of odd-length swab blocks */ > - uintmax_t bytes; /* # of bytes written */ > + size_t in_full; /* # of full input blocks */ > + size_t in_part; /* # of partial input blocks */ > + size_t out_full; /* # of full output blocks */ > + size_t out_part; /* # of partial output blocks */ > + size_t trunc; /* # of truncated records */ > + size_t swab; /* # of odd-length swab blocks */ > + size_t bytes; /* # of bytes written */ > struct timespec start; /* start time of dd */ > } STAT; > > Index: position.c > =================================================================== > --- position.c (revision 270645) > +++ position.c (working copy) > @@ -178,7 +178,7 @@ > n = write(out.fd, out.db, out.dbsz); > if (n == -1) > err(1, "%s", out.name); > - if ((size_t)n != out.dbsz) > + if (n != out.dbsz) > errx(1, "%s: write failure", out.name); > } > break; > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 21:04:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5434EA5B; Sat, 20 Sep 2014 21:04:32 +0000 (UTC) Received: from mail.bein.link (bein.link [37.252.124.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1284EACB; Sat, 20 Sep 2014 21:04:31 +0000 (UTC) Received: from quad.localnet (home.bein.link [172.16.32.6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bein.link (Postfix) with ESMTPS id 848691AF26D; Sat, 20 Sep 2014 21:04:27 +0000 (UTC) From: Maxim V FIlimonov To: freebsd-current@freebsd.org Subject: Re: FreeBSD-11.0-CURRENT on ARM: performance and load average Date: Sun, 21 Sep 2014 01:04:27 +0400 Message-ID: <1989123.lKm0QJoZES@quad> User-Agent: KMail/4.12.5 (FreeBSD/10.0-RELEASE-p8; KDE/4.12.5; amd64; ; ) In-Reply-To: <1411241048.66615.148.camel@revolution.hippie.lan> References: <7351653.A2UeEk9AA3@quad> <1411241048.66615.148.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: freebsd-arm@freebsd.org, mav@freebsd.org, Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 21:04:32 -0000 On Saturday 20 September 2014 13:24:08 Ian Lepore wrote: > Since it's happening only on that hardware, there's a good chance the > problem is in the allwinner a10/a20 clock driver, not in the general > eventtimer code. In fact, looking at the code it appears that a > divide-by-16 is being set in the hardware, but not accounted for when > setting the frequency of the eventtimer. > > Hmm, it should affect the timecounter too, in which case you'd see > time-of-day advancing 16x too fast. If ntpd is running it would need to > step the clock pretty frequently, which would show up in syslog. > I'm running FreeBSD-current on the board right now, the time is just fine. > I don't have hardware to test on, please see if the attached patch makes > a difference. > Well, it did: with the patch applied, the time ran about 60 times as fast as it should have. I didn't notice any changes with load average, though: maybe it's because I forgot to turn that sysctl setting I set before back to 0. wbr, Maxim Filimonov che@bein.link From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 23:11:54 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1757B1F0; Sat, 20 Sep 2014 23:11:54 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9379E811; Sat, 20 Sep 2014 23:11:53 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XVTok-003YWP-M5>; Sun, 21 Sep 2014 01:11:50 +0200 Received: from g225159012.adsl.alicedsl.de ([92.225.159.12] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XVTok-003uSs-Eg>; Sun, 21 Sep 2014 01:11:50 +0200 Date: Sun, 21 Sep 2014 01:11:43 +0200 From: "O. Hartmann" To: Koop Mast Subject: Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT Message-ID: <20140921011143.0ae998ff.ohartman@zedat.fu-berlin.de> In-Reply-To: <1411240906.1174.2.camel@rainbow-runner.nl> References: <20140919201210.72650231.ohartman@zedat.fu-berlin.de> <20140920161012.02844320.ohartman@zedat.fu-berlin.de> <20140920191530.6b538c62.ohartman@zedat.fu-berlin.de> <20140920201347.0a4b9658.ohartman@zedat.fu-berlin.de> <1411240906.1174.2.camel@rainbow-runner.nl> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/D.zRqyuQCX93Df6_cOoFDnI"; protocol="application/pgp-signature" X-Originating-IP: 92.225.159.12 X-ZEDAT-Hint: A Cc: Warren Block , freebsd-x11@freebsd.org, FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 23:11:54 -0000 --Sig_/D.zRqyuQCX93Df6_cOoFDnI Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sat, 20 Sep 2014 21:21:46 +0200 Koop Mast schrieb: > On Sat, 2014-09-20 at 20:13 +0200, O. Hartmann wrote: > > Am Sat, 20 Sep 2014 19:15:30 +0200 > > "O. Hartmann" schrieb: > >=20 > > > Am Sat, 20 Sep 2014 08:27:27 -0600 (MDT) > > > Warren Block schrieb: > > >=20 > > > > On Sat, 20 Sep 2014, O. Hartmann wrote: > > > >=20 > > > > > Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) > > > > > Warren Block schrieb: > > > > > > > > > >> On Fri, 19 Sep 2014, O. Hartmann wrote: > > > > >> > > > > >>> nVidia's BLOB from port x11/nvidia-driver seems to have problem= s in FreeBSD > > > > >>> 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, o= n Lenovo > > > > >>> ThinkPad Edge E540 laptop with CPU i5-4200M (Haswell) with inte= grated HD4600 > > > > >>> Intel iGPU and dedicated nVidia GT 740M (Optimus) working corre= ctly. > > > > >> > > > > >> Optimus is supposed to be full Intel graphics plus an Nvidia GPU= . The > > > > >> extra GPU uses the same display memory and can be enabled to spe= ed up > > > > >> the Intel graphics or disabled for power saving. I don't know if > > > > >> versions where the Nvidia section is a full discrete video adapt= er that > > > > >> can be used alone are still called "Optimus". > > > > >> > > > > >> Some Optimus owners have reported being able to use the Intel dr= ivers > > > > >> after disabling the Nvidia GPU in the BIOS or UEFI. If an optio= n to > > > > >> disable the Nvidia GPU is not present, some people have reported= success > > > > >> with an xorg.conf that uses only the intel driver and ignores th= e Nvidia > > > > >> hardware. > > > > > > > > > > Thanks Warren. > > > > > > > > > > But this sounds even more frustrating now. I look around the web = even at > > > > > Lenovo's support forum. Many people report the GT 740M nVidia ada= ptor as a > > > > > discrete adaptor with Optimus technology and everything sounds to= me like it > > > > > can be selected exclusively. What you describes is that I definit= ely need to > > > > > use the HD4600 iGPU on FreeBSD in the first place since the nVidi= a hardware is > > > > > a kind of "appendix" to the HD4600. > > > >=20 > > > > Optimus started out that way, but they might use the same name now = for=20 > > > > models where the additional GPU is a full discrete adapter. > > >=20 > > > I tried to retrieve informations about the settings and implementati= ons in the > > > lenovo E540, but I guess the only answer can be given by developer do= cumentation. I > > > can not figure out how the GPU is attached to the system. The technic= al > > > specifications do not mention the requirement of a iGPU and shared me= mory - as > > > Optimus would require. > > >=20 > > > But extrapolating from that "shit-covering" public relations talking = at nVidia's > > > site I guess the GT 740M is definitely a shared memory solution and r= equires the > > > presence of the iGPU. That would explain why the nvidia BLOB is detec= ting the GPU, > > > but can not find any physical display socket, not even the built-in L= CD. They're > > > maybe wired all throught the Haswell's HD4600 iGPU?=20 > > >=20 > > > >=20 > > > > > Anyway, I also tried to configure X11 as HD4600 only and X11 does= n't work > > > > > properly: it doesn't even start up and loading the "intel" driver= complains > > > > > about a missing device > > > > > - preceeded by a lot of /dev/dri errors. This indicates to me, in= a naiv manner, > > > > > that this HD4600 isn't recodnized by the kernel, either. I do not= see any kind > > > > > of vga0: entry in the kernel log when enabling "Integrated Graphi= cs" only in the > > > > > laptop's UEFI/Firmware. When enabling "nVidia Optimus", a recogni= zed vga0: > > > > > device shows up. > > > >=20 > > > > Whoops, HD4600 is Haswell. The intel driver on FreeBSD does not su= pport=20 > > > > Haswell video yet. > > >=20 > > >=20 > > > I suspected that :-( > > >=20 > > > Thanks anyway, > > >=20 > > > Oliver > >=20 > > Oh, by the way, where is x11-drivers/xf86-video-noveau? I can only find > > x11-drivers/xf86-video-nv, which covers old hardware and it is not appl= icable to the > > GT 740M (complains, rightfully, that the found device isn't supported b= y the "nv" > > driver). > >=20 > > I face a mess here ... :-( >=20 > It was removed, because we missing kernel support for the nouveau > driver. So, every new GPU not supported by xf86-video-nv has to use nVidia's BLOB t= hen? --Sig_/D.zRqyuQCX93Df6_cOoFDnI Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUHgm0AAoJEOgBcD7A/5N8taMH/1V+URu7GqrqP2ji+rtw7COf wg7WqSBQbUKLz/2H7VaCL4Ff+VRCqw61eto28q1wE6zE+sUJOi2peJS4WviUHWp8 d9BLS9StEFU+tmlD3VqxxvCsfKJR2jiO/GGtgnlPSTtgnUbunQR2M7pgztA9B20X 6+i22VCYS38lwyHuW6mkRT0KaIWNsjTIscmeXembWbAzu/IgYFlFvmlhmB7/la3N G5rDYYgOI0r/GR52geApXkm9hZfA2kzMoLMADKzgej45UHlhYeGryMzsXsQ3bz+j 5alk6W32i2zwv2NnEortXyt7IF+XLbaIzAc/Re74mSuYai6pNkN9sBZxltLelM4= =SPtR -----END PGP SIGNATURE----- --Sig_/D.zRqyuQCX93Df6_cOoFDnI--