From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 27 06:51:14 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CCDF9187; Sun, 27 Jan 2013 06:51:14 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id AF7B524E; Sun, 27 Jan 2013 06:51:14 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r0R6pDoe025565; Sun, 27 Jan 2013 06:51:13 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 479pvcxm5s2i5gcrg4hudf455i; Sun, 27 Jan 2013 06:51:13 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Testing SIOCADDMULTI? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: Date: Sat, 26 Jan 2013 22:51:12 -0800 Content-Transfer-Encoding: 7bit Message-Id: <7A0E9B71-0232-4808-B5D4-5B0D811B353C@kientzle.com> References: To: Tim Kientzle X-Mailer: Apple Mail (2.1283) Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 06:51:14 -0000 On Jan 26, 2013, at 3:56 PM, Tim Kientzle wrote: > My next TODO items for this network driver is to implement > the SIOCADDMULTI and SIOCDELMULTI ioctls. Looking through other drivers (and net/if.c), I've managed to implement ADDMULTI by adding the multicast ethernet address to the list maintained by the controller. DELMULTI seems trickier. Since if.c does not pass the specific address being removed down to the driver, it looks like I have no choice but to remove every multicast address from the controller and then re-insert all of the ones that are still valid. (This controller doesn't use a hash filter; it uses a list of valid multicast addresses.) Is there a better approach? > I'm not quite sure what they do, though, and have > no idea how to test them to see if they are working > correctly. Would still appreciate any suggestions for how to test these. Cheers, Tim From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 27 12:24:04 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E8744F72; Sun, 27 Jan 2013 12:24:04 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B74A6DD9; Sun, 27 Jan 2013 12:24:03 +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 OAA19523; Sun, 27 Jan 2013 14:24:02 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TzRHF-000JDr-Mc; Sun, 27 Jan 2013 14:24:01 +0200 Message-ID: <51051C61.4060608@FreeBSD.org> Date: Sun, 27 Jan 2013 14:24:01 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Subject: dtrace vs module unloading X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 12:24:05 -0000 It seems that FreeBSD DTrace currently does not track module loading / unloading at all. dtrace_module_loaded/dtrace_module_unloaded are both under ifdef sun. I think that this is a root cause of e.g. fbt probes for some functions remaining after a module that provides the functions is unloaded. It looks like currently we do not post any event when a module gets loaded / unloaded. Perhaps this is one of the factors in current situation. OTOH, in Solaris they just have some dtrace hooks in the form of function pointers directly in the module handling code (equivalent of our kern_linker). -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 27 14:41:29 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6B57A2D9; Sun, 27 Jan 2013 14:41:29 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1A8FB2C7; Sun, 27 Jan 2013 14:41:28 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id l8so515728qaq.6 for ; Sun, 27 Jan 2013 06:41:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BbTUwVNH5vt9ZKxxRTsFEb8eU7TuOkfC55Qh+NpGqQk=; b=qOOoG46gHv6B6Bawjs5nzo8GsCCXr4Z2NBz1zjR45qLxRdt2Aikzrzw1EBAPbKFAUi walbJ1ipYt92Vw2vYaMCM/r1buLIvrv/Js2tW6MXjoQj/q07OD5w4RY0jgRJRQJbbBZ9 x6yxoX0Q+N75b147klVGOC/dxqJw3cbkmIqFICePOAWmWk2LdotWNUD/G9POJZf0vJ8g ScVNrRSV4TC6QpN3GLXGVT7Bzrq2QS7QPFzyJr6SRYQ5MXlG5HjpDEitWb3fIh+Q+CBm 5NNrrVZ/i7tx5xykIEXD8YxlLEM3xY7zsCoZ88nd2g22rLweOZ4tG62Wyar2LBRg05ol URAw== MIME-Version: 1.0 X-Received: by 10.224.186.82 with SMTP id cr18mr12683692qab.64.1359297688397; Sun, 27 Jan 2013 06:41:28 -0800 (PST) Received: by 10.49.72.138 with HTTP; Sun, 27 Jan 2013 06:41:28 -0800 (PST) In-Reply-To: <51051C61.4060608@FreeBSD.org> References: <51051C61.4060608@FreeBSD.org> Date: Sun, 27 Jan 2013 09:41:28 -0500 Message-ID: Subject: Re: dtrace vs module unloading From: Ryan Stone To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 14:41:29 -0000 On Sun, Jan 27, 2013 at 7:24 AM, Andriy Gapon wrote: > > It seems that FreeBSD DTrace currently does not track module loading / > unloading > at all. dtrace_module_loaded/dtrace_module_unloaded are both under ifdef > sun. > > I think that this is a root cause of e.g. fbt probes for some functions > remaining after a module that provides the functions is unloaded. > > It looks like currently we do not post any event when a module gets loaded > / > unloaded. Perhaps this is one of the factors in current situation. > OTOH, in Solaris they just have some dtrace hooks in the form of function > pointers directly in the module handling code (equivalent of our > kern_linker). > I have a PR in about this. I haven't had a chance to look into fixing it myself. From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 28 14:30:15 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1F34DB83 for ; Mon, 28 Jan 2013 14:30:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 55D27F82 for ; Mon, 28 Jan 2013 14:30:14 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA01576 for ; Mon, 28 Jan 2013 16:30:12 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <51068B74.2070808@FreeBSD.org> Date: Mon, 28 Jan 2013 16:30:12 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-hackers Subject: NMI while trying to read acpi timer register X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 14:30:15 -0000 Guys, is there any reasonable explanation for getting an NMI while trying to read acpi timer register? Note: this happens only after ACPI suspend/resume. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 28 15:12:17 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0123AA49 for ; Mon, 28 Jan 2013 15:12:16 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id B6DDE20B for ; Mon, 28 Jan 2013 15:12:16 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r0SFC9IW046658 for ; Mon, 28 Jan 2013 08:12:09 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0SFBlpw020899 for ; Mon, 28 Jan 2013 08:11:47 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Sockets programming question From: Ian Lepore To: freebsd-hackers Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Jan 2013 08:11:47 -0700 Message-ID: <1359385907.93359.84.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 15:12:17 -0000 I've got a question that isn't exactly freebsd-specific, but implemenation-specific behavior may be involved. I've got a server process that accepts connections from clients on a PF_LOCAL stream socket. Multiple clients can be connected at once; a list of them is tracked internally. The server occasionally sends data to each client. The time between messages to clients can range literally from milliseconds to months. Clients never send any data to the server, indeed they may shutdown that side of the connection and just receive data. The only way I can find to discover that a client has disappeared is by trying to send them a message and getting an error because they've closed the socket or died completely. At that point I can reap the resources and remove them from the client list. This is problem because of the "months between messages" thing. A lot of clients can come and go during those months and I've got this ever-growing list of open socket descriptors because I never had anything to say the whole time they were connected. By trial and error I've discovered that I can sort of "poll" for their presence by writing a zero-length message. If the other end of the connection is gone I get the expected error and can reap the client, otherwise it appears to quietly write nothing and return zero and have no other side effects than polling the status of the server->client side of the pipe. My problem with this "polling" is that I can't find anything in writing that sanctions this behavior. Would this amount to relying on a non-portable accident of the current implementation? Also, am I missing something simple and there's a cannonical way to handle this? In all the years I've done client/server stuff I've never had quite this type of interaction (or lack thereof) between client and server before. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 28 15:50:18 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D107CEFD; Mon, 28 Jan 2013 15:50:18 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id C1B3771C; Mon, 28 Jan 2013 15:50:18 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (207.110.29.135.ptr.us.xo.net [207.110.29.135]) by elvis.mu.org (Postfix) with ESMTPSA id 361051A3C1B; Mon, 28 Jan 2013 07:50:10 -0800 (PST) Message-ID: <51069E30.5020003@mu.org> Date: Mon, 28 Jan 2013 10:50:08 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Sockets programming question References: <1359385907.93359.84.camel@revolution.hippie.lan> In-Reply-To: <1359385907.93359.84.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 15:50:18 -0000 On 1/28/13 10:11 AM, Ian Lepore wrote: > I've got a question that isn't exactly freebsd-specific, but > implemenation-specific behavior may be involved. > > I've got a server process that accepts connections from clients on a > PF_LOCAL stream socket. Multiple clients can be connected at once; a > list of them is tracked internally. The server occasionally sends data > to each client. The time between messages to clients can range > literally from milliseconds to months. Clients never send any data to > the server, indeed they may shutdown that side of the connection and > just receive data. > > The only way I can find to discover that a client has disappeared is by > trying to send them a message and getting an error because they've > closed the socket or died completely. At that point I can reap the > resources and remove them from the client list. This is problem because > of the "months between messages" thing. A lot of clients can come and > go during those months and I've got this ever-growing list of open > socket descriptors because I never had anything to say the whole time > they were connected. > > By trial and error I've discovered that I can sort of "poll" for their > presence by writing a zero-length message. If the other end of the > connection is gone I get the expected error and can reap the client, > otherwise it appears to quietly write nothing and return zero and have > no other side effects than polling the status of the server->client side > of the pipe. > > My problem with this "polling" is that I can't find anything in writing > that sanctions this behavior. Would this amount to relying on a > non-portable accident of the current implementation? > > Also, am I missing something simple and there's a cannonical way to > handle this? In all the years I've done client/server stuff I've never > had quite this type of interaction (or lack thereof) between client and > server before. I may be mistaken, but doesn't poll(2) allow you to see this as well? I think you should see POLLHUP in revents if POLLOUT is set in events. I think there also is an analogous way to do this with kevent as well. -Alfred From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 28 16:02:46 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 504AC84D; Mon, 28 Jan 2013 16:02:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id B63CA825; Mon, 28 Jan 2013 16:02:45 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0SG2cFN085268; Mon, 28 Jan 2013 18:02:38 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0SG2cFN085268 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0SG2cNt085267; Mon, 28 Jan 2013 18:02:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 28 Jan 2013 18:02:38 +0200 From: Konstantin Belousov To: Ian Lepore Subject: Re: Sockets programming question Message-ID: <20130128160238.GT2522@kib.kiev.ua> References: <1359385907.93359.84.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LBl8gXKyGkO5T0RG" Content-Disposition: inline In-Reply-To: <1359385907.93359.84.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 16:02:46 -0000 --LBl8gXKyGkO5T0RG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 28, 2013 at 08:11:47AM -0700, Ian Lepore wrote: > I've got a question that isn't exactly freebsd-specific, but > implemenation-specific behavior may be involved. >=20 > I've got a server process that accepts connections from clients on a > PF_LOCAL stream socket. Multiple clients can be connected at once; a > list of them is tracked internally. The server occasionally sends data > to each client. The time between messages to clients can range > literally from milliseconds to months. Clients never send any data to > the server, indeed they may shutdown that side of the connection and > just receive data. >=20 > The only way I can find to discover that a client has disappeared is by > trying to send them a message and getting an error because they've > closed the socket or died completely. At that point I can reap the > resources and remove them from the client list. This is problem because > of the "months between messages" thing. A lot of clients can come and > go during those months and I've got this ever-growing list of open > socket descriptors because I never had anything to say the whole time > they were connected. >=20 > By trial and error I've discovered that I can sort of "poll" for their > presence by writing a zero-length message. If the other end of the > connection is gone I get the expected error and can reap the client, > otherwise it appears to quietly write nothing and return zero and have > no other side effects than polling the status of the server->client side > of the pipe. >=20 > My problem with this "polling" is that I can't find anything in writing > that sanctions this behavior. Would this amount to relying on a > non-portable accident of the current implementation? =20 >=20 > Also, am I missing something simple and there's a cannonical way to > handle this? In all the years I've done client/server stuff I've never > had quite this type of interaction (or lack thereof) between client and > server before. Check for the IN events as well. I would not trust the mere presence of the IN in the poll result, but consequent read should return EOF and this is good indicator of the dead client. --LBl8gXKyGkO5T0RG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRBqEeAAoJEJDCuSvBvK1BJVUP/2CJIOO4MBob58JspdeeIafM OzzGrGZy64GQnhs2+BCgR1bPxt4bt53rhP4KnsXc9F3LEZhmesDmb4zY8U2zliop Q3sTPoesCzDqWwP6rNzQgQEjrWX6LKq798uO4LdJksMTSz1fPZnuTdKFiszPHMd1 mG3/TDju2Z8WhHK3iEetu82HNdrpXTxe4z7ZLEteUfZ25zZE9aw830w3a/eNdtE7 7rH1UfL+X82O74ayW8pM579JQgIA6W+jKWfVYdsGXXKj2sk+5Bd6RpDdgP6JMa2v brncs9zbUu8KKeyQy30tSwLlZ5o7AOf2uIAZuIrHcfRcw0gxpxwgoeAsroYLEBZV ZU0xR7Q2Q3L5lNMBj74fqBagb5GDZuxivlxun1mmo8O53+hbtsugSAMxaJxjQaMG ChUkvnkpfGCZI8CYFbGzPkPMTFllVmDWyTadqWWbjxor7WEPcNkTZ5j/jX6RO2Nf 7l1nhCQKj1E3OWH3OlVNwFElHoCehREyEJNT9TuLmkbmGQ9KtkJilQrDbbks8GvT Xcnv/TsFpTTTQFC8kHoCCwKQYH25WTTnB9NXDflNJoam+8uRuU3JjPhihcIFU2rr 7/fL4EurxplecixZhV2uuvKELkdecYiM8+sJsPcjtKZTDt4qfj9s7FR1bVg0cL38 UhZytb2q9/9k9X9OWPpt =7kI4 -----END PGP SIGNATURE----- --LBl8gXKyGkO5T0RG-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 28 18:58:17 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1039C21D; Mon, 28 Jan 2013 18:58:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id E238825D; Mon, 28 Jan 2013 18:58:16 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 51DC2B953; Mon, 28 Jan 2013 13:58:16 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: some questions on kern_linker and pre-loaded modules Date: Mon, 28 Jan 2013 10:40:38 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <5103C361.6060605@FreeBSD.org> In-Reply-To: <5103C361.6060605@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201301281040.38727.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 28 Jan 2013 13:58:16 -0500 (EST) Cc: freebsd-hackers@freebsd.org, Andriy Gapon X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 18:58:17 -0000 On Saturday, January 26, 2013 6:52:01 am Andriy Gapon wrote: > > I. > It seems that linker_preload checks a module for being a duplicate module only > if the module has MDT_VERSION. > > This is probably designed to allow different version of the same module to > co-exist (for some definition of co-exist)? Yes, that is likely true, but it is a bit dubious. > But, OTOH, this doesn't work well if the module is version-less (no > MODULE_VERSION in the code) and is pre-loaded twice (e.g. once in kernel and > once in a preloaded file). Yes. > At present a good example of this is zfsctrl module, which could be present both > in kernel (options ZFS) and in zfs.ko. > > I haven't thought about any linker-level resolution for this issue. > I've just tried a plug the ZFS hole for now. I think we should require all modules declared by DECLARE_MODULE() to have a version. You might be able to enforce that by failing to register a linker file if it contains any modules that do not include at least one version metadata note in the same linker file. You could check this before running the MOD_LOAD handlers (though after running SYSINITs). Truly fixing this would mean making module data true metadata that is parsed by the linker rather than having it all provided to the kernel via SYSINITs so that you could evaluate this before running SYSINITs. That is a larger project however. I think your fix for zfsctrl is correct. > II. > It seems that linker_file_register_modules() for the kernel is called after > linker_file_register_modules() is called for all the pre-loaded files. > linker_file_register_modules() for the kernel is called from > linker_init_kernel_modules via SYSINIT(SI_SUB_KLD, SI_ORDER_ANY) and that > happens after linker_preload() which is executed via SYSINIT(SI_SUB_KLD, > SI_ORDER_MIDDLE). > > Perhaps this is designed to allow modules in the preloaded files to override > modules compiled into the kernel? Yes, likely so. > But this doesn't seem to work well. > Because modules from the kernel are not registered yet, > linker_file_register_modules() would be successful for the duplicate modules in > a preloaded file and thus any sysinits present in the file will also be registered. > So, if the module is present both in the kernel and in the preloaded file and > the module has a module event handler (modeventhand_t), then the handler will > registered and called twice. Yes, I think it is too hard at present to safely allow a linker file to override the same module in a kernel, so the duplicate linker file should just be rejected entirely. I'm not sure if your change is completely correct for that. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 28 18:58:22 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 79E21374; Mon, 28 Jan 2013 18:58:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4E6CE261; Mon, 28 Jan 2013 18:58:22 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B380BB997; Mon, 28 Jan 2013 13:58:21 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Testing SIOCADDMULTI? Date: Mon, 28 Jan 2013 11:09:24 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <7A0E9B71-0232-4808-B5D4-5B0D811B353C@kientzle.com> In-Reply-To: <7A0E9B71-0232-4808-B5D4-5B0D811B353C@kientzle.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301281109.24879.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 28 Jan 2013 13:58:21 -0500 (EST) Cc: Tim Kientzle X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 18:58:22 -0000 On Sunday, January 27, 2013 1:51:12 am Tim Kientzle wrote: > > On Jan 26, 2013, at 3:56 PM, Tim Kientzle wrote: > > > My next TODO items for this network driver is to implement > > the SIOCADDMULTI and SIOCDELMULTI ioctls. > > Looking through other drivers (and net/if.c), I've > managed to implement ADDMULTI by adding > the multicast ethernet address to the list maintained > by the controller. > > DELMULTI seems trickier. Since if.c does not pass > the specific address being removed down to the > driver, it looks like I have no choice but to remove > every multicast address from the controller and then > re-insert all of the ones that are still valid. > > (This controller doesn't use a hash filter; it uses > a list of valid multicast addresses.) > > Is there a better approach? You should always reprogram the full table while holding if_maddr_rlock(). All the ioctl's tell you is that an entry was added or removed from that list. There is currently no race-free way for the stack to tell you which specific address to add or remove. > > I'm not quite sure what they do, though, and have > > no idea how to test them to see if they are working > > correctly. > > Would still appreciate any suggestions for how to test these. You can write a simple app to listen for UDP packets and have it join a multicast group and have another machine on the same network write a packet to the multicast group. However, a simpler test is to toggle the sysctl to enable multicast ping replies and to ping a multicast address from another machine after joining it on the test machine using mtest. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 29 17:46:09 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B7D782D9 for ; Tue, 29 Jan 2013 17:46:09 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 6BA6BBDF for ; Tue, 29 Jan 2013 17:46:09 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r0THk8MH069077 for ; Tue, 29 Jan 2013 10:46:08 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0THk6KE022532; Tue, 29 Jan 2013 10:46:06 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: Sockets programming question From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20130128160238.GT2522@kib.kiev.ua> References: <1359385907.93359.84.camel@revolution.hippie.lan> <20130128160238.GT2522@kib.kiev.ua> Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Jan 2013 10:46:05 -0700 Message-ID: <1359481565.93359.160.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 17:46:09 -0000 On Mon, 2013-01-28 at 18:02 +0200, Konstantin Belousov wrote: > On Mon, Jan 28, 2013 at 08:11:47AM -0700, Ian Lepore wrote: > > I've got a question that isn't exactly freebsd-specific, but > > implemenation-specific behavior may be involved. > > > > I've got a server process that accepts connections from clients on a > > PF_LOCAL stream socket. Multiple clients can be connected at once; a > > list of them is tracked internally. The server occasionally sends data > > to each client. The time between messages to clients can range > > literally from milliseconds to months. Clients never send any data to > > the server, indeed they may shutdown that side of the connection and > > just receive data. > > > > The only way I can find to discover that a client has disappeared is by > > trying to send them a message and getting an error because they've > > closed the socket or died completely. At that point I can reap the > > resources and remove them from the client list. This is problem because > > of the "months between messages" thing. A lot of clients can come and > > go during those months and I've got this ever-growing list of open > > socket descriptors because I never had anything to say the whole time > > they were connected. > > > > By trial and error I've discovered that I can sort of "poll" for their > > presence by writing a zero-length message. If the other end of the > > connection is gone I get the expected error and can reap the client, > > otherwise it appears to quietly write nothing and return zero and have > > no other side effects than polling the status of the server->client side > > of the pipe. > > > > My problem with this "polling" is that I can't find anything in writing > > that sanctions this behavior. Would this amount to relying on a > > non-portable accident of the current implementation? > > > > Also, am I missing something simple and there's a cannonical way to > > handle this? In all the years I've done client/server stuff I've never > > had quite this type of interaction (or lack thereof) between client and > > server before. > > Check for the IN events as well. I would not trust the mere presence > of the IN in the poll result, but consequent read should return EOF > and this is good indicator of the dead client. You can't use EOF on a read() to determine client life when the nature of the client/server relationship is that clients are allowed to shutdown(fd, SHUT_WR) as soon as they connect because they expect to receive but never send any data. On the other hand, Alfred's suggestion of using poll(2) rather than select(2) worked perfectly. Polling with an events mask of zero results in it returning POLLHUP in revents if the client has closed the socket. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 29 17:56:50 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A1C94B29; Tue, 29 Jan 2013 17:56:50 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by mx1.freebsd.org (Postfix) with ESMTP id 0982FD10; Tue, 29 Jan 2013 17:56:49 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id fn15so487082wgb.8 for ; Tue, 29 Jan 2013 09:56:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pd7H9vmSNfVaO3FsSl5Hh951BUKzywrvgxJ5qNkhJiY=; b=rJZRbnkRmdVBI+qRNYgSh8LDrqoNALhj/zYFcBLH+2HvKHSLBYTAXTFaA6TqQc1Dio 7uQdjLkXxH6U3e9btr3y8J97wVvaiasBNZv0HACt2Xs7cbOZbJmkaD5oGtXqRXN7aGC7 BUd8Kn1NzR7Azza3wuxPXj3AiQSZ+OV1sJ2lZixiWsxw8FRnyIxV0W07G86JE3rGvC37 E8li5bRFf3U/piZC1hsLiXjHJbkXjl6HvaGEHyz7MpfyA8AUWpD6ztB83Jwk2f+/Tcdn 8biSZ7oUndy1A55f9DwWyDELXGdV5uZEcK9/qfDS/YYcCMWxSH9u9JjyMVY9qa8CchER Kugw== MIME-Version: 1.0 X-Received: by 10.180.82.65 with SMTP id g1mr4224440wiy.22.1359482203045; Tue, 29 Jan 2013 09:56:43 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.67.6 with HTTP; Tue, 29 Jan 2013 09:56:42 -0800 (PST) In-Reply-To: <1359481565.93359.160.camel@revolution.hippie.lan> References: <1359385907.93359.84.camel@revolution.hippie.lan> <20130128160238.GT2522@kib.kiev.ua> <1359481565.93359.160.camel@revolution.hippie.lan> Date: Tue, 29 Jan 2013 09:56:42 -0800 X-Google-Sender-Auth: 4bS5EGinOT0RHcxZT0spTw-KZ2I Message-ID: Subject: Re: Sockets programming question From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 17:56:50 -0000 On 29 January 2013 09:46, Ian Lepore wrote: > You can't use EOF on a read() to determine client life when the nature > of the client/server relationship is that clients are allowed to > shutdown(fd, SHUT_WR) as soon as they connect because they expect to > receive but never send any data. > > On the other hand, Alfred's suggestion of using poll(2) rather than > select(2) worked perfectly. Polling with an events mask of zero results > in it returning POLLHUP in revents if the client has closed the socket. Just make sure that's portable.. :-) adrian From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 30 21:03:29 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7096DFE7 for ; Wed, 30 Jan 2013 21:03:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B41C66DC for ; Wed, 30 Jan 2013 21:03:28 +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 XAA29821 for ; Wed, 30 Jan 2013 23:03:27 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U0eoY-000OPW-To for freebsd-hackers@freebsd.org; Wed, 30 Jan 2013 23:03:27 +0200 Message-ID: <51098A9E.1080100@FreeBSD.org> Date: Wed, 30 Jan 2013 23:03:26 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-hackers Subject: [clang] NMI while trying to read acpi timer register References: <51068B74.2070808@FreeBSD.org> In-Reply-To: <51068B74.2070808@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 21:03:29 -0000 on 28/01/2013 16:30 Andriy Gapon said the following: > is there any reasonable explanation for getting an NMI while trying to read acpi > timer register? > Note: this happens only after ACPI suspend/resume. An update. This happens only with clang compiled kernel, gcc compiled kernel is OK. Also, this happens only in the depth of fwohci driver (where it calls DELAY). If firewire is not loaded, then there is no problem. I suspect that perhaps there is some miscompilation that results in some incorrect I/O access that later leads to NMI. Too many unknowns and guesses here, obviously. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 30 21:39:31 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 56C8A84D for ; Wed, 30 Jan 2013 21:39:31 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by mx1.freebsd.org (Postfix) with ESMTP id 10B8A85F for ; Wed, 30 Jan 2013 21:39:30 +0000 (UTC) Received: by mail-ve0-f176.google.com with SMTP id jz10so1470944veb.7 for ; Wed, 30 Jan 2013 13:39:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=1kPPECLsomScGrIRJt61YzMrwUOcRmgc10M91MLFWqA=; b=DrIbVY4YS5cBUIy1oWCUsLk2ui87vr+etZhX+DTkOT1C9MdkhRHwN0++xrsSHV20Nl 419zm1nR1GkW2vvAgPDmjkfSn/WacHJ/V9QkxLpV0upSZXEUHqZTscNNV/J+kxPEHBGz wU0dMEdEe0jPy+H38PWC8CQDwbKz4MmIimmJA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=1kPPECLsomScGrIRJt61YzMrwUOcRmgc10M91MLFWqA=; b=H/dM8nCa9thWAUNJmsV2hPs61gJbW3qZOeSRMLeYuIFUO5cXVumtQNyWtjObdU/sZ/ OlEvibKfpH4TOLF7ZGVgMdhvNJejOsFnEA18IU3WI5cH7l9cPQKeSszcFNUTCK75U/Bk 7qfm/a/r4+rn9yJ4HoXUjV2bu1LEo8TzzXnwQNxfJ8NuP64cuNRlB3ZF4zWbo6D69Ecm MtL7P5c3IUrOby6MSI6FocGo+8AzYDaR9UKSso7TECIS9ZpWdiN3HOmcgu8nbQMBcrB1 ruy75Jp767TaukZXfAaOAI1w7HzJ6U7/klNOQ0HxDRGy9qCv5SCOVBa0gBC/9FCNddBh iv7w== X-Received: by 10.52.35.129 with SMTP id h1mr5385735vdj.74.1359581970089; Wed, 30 Jan 2013 13:39:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.195.70 with HTTP; Wed, 30 Jan 2013 13:39:00 -0800 (PST) From: Eitan Adler Date: Wed, 30 Jan 2013 16:39:00 -0500 Message-ID: Subject: removing plip from GENERIC To: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQklbMcSO0/DcxtNDGHmYJxe8loP0P8q5fpi9wBOsa9nezVyRNXrmy6AY/iVs+q0vb++tvvx X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 21:39:31 -0000 There has been some discussion about removing plip support from GENERIC kernels. plip still appears in sys/conf/NOTES Does anyone object to the following? commit f4efd3cf43514bcb1378e2c5e8879a411b943be2 Author: Eitan Adler Date: Mon Jan 28 15:13:57 2013 -0500 Remove support for plip from the GENERIC kernel as no systems in the last 10 years require this support. Discussed with: db Discussed with: imp Reviewed by: -hackers Approved by: ??? (mentor) diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC index e53f692..5819a0d 100644 --- a/sys/amd64/conf/GENERIC +++ b/sys/amd64/conf/GENERIC @@ -197,7 +197,6 @@ device uart # Generic UART driver device ppc device ppbus # Parallel port bus (required) device lpt # Printer -device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da diff --git a/sys/i386/conf/GENERIC b/sys/i386/conf/GENERIC index 819379e..47af43b 100644 --- a/sys/i386/conf/GENERIC +++ b/sys/i386/conf/GENERIC @@ -208,7 +208,6 @@ device uart # Generic UART driver device ppc device ppbus # Parallel port bus (required) device lpt # Printer -device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da diff --git a/sys/pc98/conf/GENERIC b/sys/pc98/conf/GENERIC index 2b048a9..eda1d14 100644 --- a/sys/pc98/conf/GENERIC +++ b/sys/pc98/conf/GENERIC @@ -151,7 +151,6 @@ device mse device ppc device ppbus # Parallel port bus (required) device lpt # Printer -device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # OLD Parallel port diff --git a/sys/sparc64/conf/GENERIC b/sys/sparc64/conf/GENERIC index f9d3b93..79124ab 100644 --- a/sys/sparc64/conf/GENERIC +++ b/sys/sparc64/conf/GENERIC @@ -161,7 +161,6 @@ device uart # Multi-uart driver #device ppc #device ppbus # Parallel port bus (required) #device lpt # Printer -#device plip # TCP/IP over parallel #device ppi # Parallel port interface device #device vpo # Requires scbus and da -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 30 21:45:58 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BED0AC4E for ; Wed, 30 Jan 2013 21:45:58 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by mx1.freebsd.org (Postfix) with ESMTP id 800958D0 for ; Wed, 30 Jan 2013 21:45:58 +0000 (UTC) Received: by mail-vc0-f173.google.com with SMTP id fy7so1320613vcb.18 for ; Wed, 30 Jan 2013 13:45:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=kbLR0DUc+5inLJZLZrxgnStIsEuxZRbiwsBdDcnXeMM=; b=hsVLGFyvUkU11LJL9Txw3imMYGPbB99IjROoQTz0soW5BxCCzpbJ1dKdWkyr/M/lMB 7lY3C6RtPrGrO1/ykGtcdUvtiCJO3//W3XEnokuk+SDWFVyrMuk0ASHULVBGBZQiaZIN zqaoZxl5dnORD2uMyor6OFm/5XYMZQSOF1jZM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=kbLR0DUc+5inLJZLZrxgnStIsEuxZRbiwsBdDcnXeMM=; b=lTriHafBPh5JMmSxtI8kHTMxxMbntTvI3kaGkJpRPVPg2WDrCI7oP5otxB93csL+UW YsRvMC64mAkFgp08WhN4XDNnXl8pLBmDNivuTYYcuNGzYXCzJ+COBVGoM1NRzuIgl0tT nakbD9REzPS6KLfHkSVYIDwOW/rxS0oJygF+ju4Egsuv4FUha2HFM4dDfpYnJPF0p9FE BqCeA4mXQzlkZdHhoOCEH0kKbYBkq9mXgnoIKi+/50ain7ph8TxMnJOfUWge5jDW43eP zj0XxX09XUKHvQsbhkUrpRPZ7UwzIvLj09IKvgn6fwKKEw1v/HRprmjdmH4F3+zIEFkL o2Hw== X-Received: by 10.52.35.129 with SMTP id h1mr5397653vdj.74.1359582352246; Wed, 30 Jan 2013 13:45:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.195.70 with HTTP; Wed, 30 Jan 2013 13:45:22 -0800 (PST) In-Reply-To: References: From: Eitan Adler Date: Wed, 30 Jan 2013 16:45:22 -0500 Message-ID: Subject: Re: removing plip from GENERIC To: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmXgSBKmEW/36HpGbDeLqPfKwBjncnko6dhmJOFU/rCSRiZAr0JH0GRVHDNsPsEXmldmh5w X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 21:45:58 -0000 On 30 January 2013 16:39, Eitan Adler wrote: > There has been some discussion about removing plip support from GENERIC kernels. > plip still appears in sys/conf/NOTES A quick follow up to this: -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 30 21:46:44 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E6635D42 for ; Wed, 30 Jan 2013 21:46:44 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by mx1.freebsd.org (Postfix) with ESMTP id A8A298E3 for ; Wed, 30 Jan 2013 21:46:44 +0000 (UTC) Received: by mail-ve0-f169.google.com with SMTP id cy12so1528273veb.0 for ; Wed, 30 Jan 2013 13:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=UvzAHqOfNo1+w/mCbRp+PdyObfUP6pQgWkRGsEkV7T4=; b=V7LquPhr8u2rTuFH+pyJqkFkR1VzVoFDYFDk7Qvc+TLhpaSY4Nue2R8u2RV9H5levn z9/Cek7HHRLmp2dsyONDQa1/RkU3QD1cv/gt2HWh5USN0x0n5AJ98nmnB33Ir4h/ZKHr Dx/RGco1efejz/PmYQ4zrAKt4RZNZog9Ht018= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=UvzAHqOfNo1+w/mCbRp+PdyObfUP6pQgWkRGsEkV7T4=; b=h51rYQ3C1Qgwgd9sHhiaMUGkbP7xDFbUPPGCAG6mKnnjXE5YEWL/JE/54q/GExhzrM 2nF0wuul1DI5C4ADUwBTfxDK3BUtaODAVAlAPKFwVeG/p60U1eLKdCQAR8PJHdQRf/WP 3dyqXszvjz3UECQaIbSXa88xvdQr+4EnmzCYTMzSCNjctVNu2uvy/wu73lpTRGr9PGwN ePLsNt734zZPzyHqQocHdIppIdNg58cn8AVnabhXO3ao5nypyTxi1sQueSO4esBhke5u gqyco7V6+Y9fymK3XX9DOzTm4IpgjdrDMB0wijMMqq1uhFF1o341lOOxunRw8PDh21KT FjJA== X-Received: by 10.220.157.18 with SMTP id z18mr6141585vcw.72.1359582403899; Wed, 30 Jan 2013 13:46:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.195.70 with HTTP; Wed, 30 Jan 2013 13:46:13 -0800 (PST) In-Reply-To: References: From: Eitan Adler Date: Wed, 30 Jan 2013 16:46:13 -0500 Message-ID: Subject: Re: removing plip from GENERIC To: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkGTHK75nssCPTgr9CCaeuwO/PgvnA0mSJVNgYEgwezF1vnR5WneFOUhtb3lGnHD9WG4gm/ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 21:46:45 -0000 On 30 January 2013 16:39, Eitan Adler wrote: > There has been some discussion about removing plip support from GENERIC kernels. > plip still appears in sys/conf/NOTES A quick follow up to this: the documentation about plip from the handbook has already been removed by others. -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 30 22:10:02 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EA7385D0 for ; Wed, 30 Jan 2013 22:10:02 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id DB1949CC for ; Wed, 30 Jan 2013 22:10:02 +0000 (UTC) Received: from [10.246.180.89] (134.sub-174-255-125.myvzw.com [174.255.125.134]) by elvis.mu.org (Postfix) with ESMTPSA id 1F6651A3DB8; Wed, 30 Jan 2013 14:10:01 -0800 (PST) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <0245666F-066A-40EB-9E09-875B6A29DB9C@mu.org> X-Mailer: iPhone Mail (10B141) From: Alfred Perlstein Subject: Re: removing plip from GENERIC Date: Wed, 30 Jan 2013 17:09:56 -0500 To: Eitan Adler Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 22:10:03 -0000 Does plip no longer work? Sent from my iPhone On Jan 30, 2013, at 4:39 PM, Eitan Adler wrote: > There has been some discussion about removing plip support from GENERIC ke= rnels. > plip still appears in sys/conf/NOTES >=20 > Does anyone object to the following? >=20 > commit f4efd3cf43514bcb1378e2c5e8879a411b943be2 > Author: Eitan Adler > Date: Mon Jan 28 15:13:57 2013 -0500 >=20 > Remove support for plip from the GENERIC kernel as no systems in the > last 10 years require this support. >=20 > Discussed with: db > Discussed with: imp > Reviewed by: -hackers > Approved by: ??? (mentor) >=20 > diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC > index e53f692..5819a0d 100644 > --- a/sys/amd64/conf/GENERIC > +++ b/sys/amd64/conf/GENERIC > @@ -197,7 +197,6 @@ device uart # Generic UART driver > device ppc > device ppbus # Parallel port bus (required) > device lpt # Printer > -device plip # TCP/IP over parallel > device ppi # Parallel port interface device > #device vpo # Requires scbus and da >=20 > diff --git a/sys/i386/conf/GENERIC b/sys/i386/conf/GENERIC > index 819379e..47af43b 100644 > --- a/sys/i386/conf/GENERIC > +++ b/sys/i386/conf/GENERIC > @@ -208,7 +208,6 @@ device uart # Generic UART driver > device ppc > device ppbus # Parallel port bus (required) > device lpt # Printer > -device plip # TCP/IP over parallel > device ppi # Parallel port interface device > #device vpo # Requires scbus and da >=20 > diff --git a/sys/pc98/conf/GENERIC b/sys/pc98/conf/GENERIC > index 2b048a9..eda1d14 100644 > --- a/sys/pc98/conf/GENERIC > +++ b/sys/pc98/conf/GENERIC > @@ -151,7 +151,6 @@ device mse > device ppc > device ppbus # Parallel port bus (required) > device lpt # Printer > -device plip # TCP/IP over parallel > device ppi # Parallel port interface device > #device vpo # Requires scbus and da > # OLD Parallel port > diff --git a/sys/sparc64/conf/GENERIC b/sys/sparc64/conf/GENERIC > index f9d3b93..79124ab 100644 > --- a/sys/sparc64/conf/GENERIC > +++ b/sys/sparc64/conf/GENERIC > @@ -161,7 +161,6 @@ device uart # Multi-uart driver > #device ppc > #device ppbus # Parallel port bus (required) > #device lpt # Printer > -#device plip # TCP/IP over parallel > #device ppi # Parallel port interface device > #device vpo # Requires scbus and da >=20 >=20 >=20 > --=20 > Eitan Adler > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= >=20 From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 31 07:53:25 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B70AD80D for ; Thu, 31 Jan 2013 07:53:25 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 4B290134 for ; Thu, 31 Jan 2013 07:53:24 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id hn3so2460809wib.17 for ; Wed, 30 Jan 2013 23:53:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to:x-gm-message-state; bh=wpcXWOuyvU9Yzi4smeR/dT0dDB09tugwtdigqxnkDTs=; b=O5No1WaWIU0T4bn7cZt4F1u2qCC2krOzciCdXEaxHpK/vwjQu6IQwF2MaBzzV2XPON TwXapnomrkF96GOFTVmj2XETYrs/hrQsK4MrYoHZz70FkZmhCxhKG7xJ/0m5QMtRJOlL C4yRx1TFLHK13WVocEuJiG+4IHbjshCJE6Qm3F9CqGi1eH7fQrA2+bB2PU9xE1xHpmST Gs8RmcaUjSHcsurbox8QdBhYcNijM9d8YHWb1+s90M4i87UC5GsS0J/U6unMIHnf6Guo SjojWqQIobYbREd+cWLQTqypjGypVdLrBQkEn3dkejm+cEDkO5OY65IuaN6uq1Nti3/j regQ== X-Received: by 10.180.72.232 with SMTP id g8mr13362653wiv.0.1359618797774; Wed, 30 Jan 2013 23:53:17 -0800 (PST) Received: from [172.16.14.113] (cust.static.46-14-182-165.swisscomdata.ch. [46.14.182.165]) by mx.google.com with ESMTPS id s8sm13287550wif.9.2013.01.30.23.53.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jan 2013 23:53:16 -0800 (PST) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <194A1E3D-7EBF-4CE9-9584-54AD43DF064D@my.gd> X-Mailer: iPhone Mail (9A405) From: Damien Fleuriot Subject: Re: removing plip from GENERIC Date: Thu, 31 Jan 2013 08:52:09 +0100 To: Eitan Adler X-Gm-Message-State: ALoCoQnFOKhYA0tZwE7W3akZS4J7jEQ6mgbkkTxL/rcUqyujJLCcFIOMJeSUSo+Xubj2Y9F+4KX9 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 07:53:25 -0000 On 30 Jan 2013, at 22:46, Eitan Adler wrote: > On 30 January 2013 16:39, Eitan Adler wrote: >> There has been some discussion about removing plip support from GENERIC k= ernels. >> plip still appears in sys/conf/NOTES >=20 > A quick follow up to this: the documentation about plip from the > handbook has already been removed by others. >=20 >=20 > --=20 > Eitan Adler >=20 I speak only for myself but no objection here, I remove it (as well as // po= rt) from every single kernel build. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 31 13:20:58 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 84ED7687 for ; Thu, 31 Jan 2013 13:20:58 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id E4CEC703 for ; Thu, 31 Jan 2013 13:20:57 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0VDKll7007476 for ; Thu, 31 Jan 2013 14:20:48 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0VDKln4007473 for ; Thu, 31 Jan 2013 14:20:47 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 31 Jan 2013 14:20:47 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: Xorg help Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 31 Jan 2013 14:20:48 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 13:20:58 -0000 long time ago with CRT monitors i used xvidtune and defined my modeline based on existing one. With LCD laptop Xorg automatically selected good one. Now with desktop and new LG monitor capable of 1920x1080 it uses 1024x768 no possible modelines are displayed and i have no idea how to set it properly. It is LG Flatron E2211 if it helps. What driver should i use with Atom D525? xf86-video-intel29 is the only one that works, in spite of market as not supported. Or am i missing something? .. .. . (--) PCI:*(0:0:2:0) 8086:a001:8086:574d Intel Corporation N10 Family Integrated Graphics Controller rev 2, Mem @ 0xf0200000/524288, 0xe0000000/268435456, 0xf0100000/1048576, I/O @ 0x000020c0/8, BIOS @ 0x????????/65536 (II) "extmod" will be loaded. This was enabled by default and also specified in the config file. (II) "dbe" will be loaded. This was enabled by default and also specified in the config file. (II) "glx" will be loaded. This was enabled by default and also specified in the config file. (II) "record" will be loaded. This was enabled by default and also specified in the config file. (II) "dri" will be loaded. This was enabled by default and also specified in the config file. (II) "dri2" will be loaded. This was enabled by default and also specified in the config file. . . . (II) LoadModule: "intel" (II) Loading /usr/local/lib/xorg/modules/drivers/intel_drv.so (II) Module intel: vendor="X.Org Foundation" compiled for 1.7.7, module version = 2.9.1 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 6.0 . . . (==) intel(0): RGB weight 888 (==) intel(0): Default visual is TrueColor (II) intel(0): Integrated Graphics Chipset: Intel(R) Pineview G (--) intel(0): Chipset: "Pineview G" (--) intel(0): Linear framebuffer at 0xE0000000 (--) intel(0): IO registers at addr 0xF0200000 size 524288 (II) intel(0): No SDVO device is found in VBT (II) intel(0): 2 display pipes available. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 31 13:33:35 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F2974B01; Thu, 31 Jan 2013 13:33:34 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id A8C7E79A; Thu, 31 Jan 2013 13:33:34 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 0748340020; Thu, 31 Jan 2013 14:33:34 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id F0FD440004; Thu, 31 Jan 2013 14:33:33 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (h-45-105.a163.priv.bahnhof.se [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 7FA2C40002; Thu, 31 Jan 2013 14:33:33 +0100 (CET) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3Yxj7x2WhRz8hVm; Thu, 31 Jan 2013 14:33:33 +0100 (CET) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([IPv6:2001:470:dca9:0:1::3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) (amavisd-new, port 10025) with ESMTPS id UPHWxXfXG5OK; Thu, 31 Jan 2013 14:33:31 +0100 (CET) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 3Yxj7v1Nh7z8hVt; Thu, 31 Jan 2013 14:33:31 +0100 (CET) Received: from vivi.daemonic.se (vivi.daemonic.se [IPv6:2001:470:dca9:1::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 3Yxj7v10Jjz9CwY; Thu, 31 Jan 2013 14:33:31 +0100 (CET) Message-ID: <510A724F.1070704@freebsd.org> Date: Thu, 31 Jan 2013 14:31:59 +0100 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Wojciech Puchar Subject: Re: Xorg help References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: hackers@freebsd.org, x11@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 13:33:35 -0000 This should have been sent to x11@ instead. On 01/31/13 14:20, Wojciech Puchar wrote: > long time ago with CRT monitors i used xvidtune and defined my modeline > based on existing one. > > With LCD laptop Xorg automatically selected good one. > > Now with desktop and new LG monitor capable of 1920x1080 it uses 1024x768 > > no possible modelines are displayed and i have no idea how to set it > properly. > > It is LG Flatron E2211 if it helps. > > What driver should i use with Atom D525? xf86-video-intel29 is the only > one that works, in spite of market as not supported. > > Or am i missing something? xf86-video-intel29 is not supported. It was used for a short time when gem/kms was still developed. I have no idea what graphics card your atom comes with, it has integrated graphics, but you have to find out which exact version it is. In general, for newer intel graphics cards, the best is to use the new xorg distribution, that should give you hardware acceleration. Otherwise you can try xf86-video-intel in the old xorg distribution, but the risk is that it will revert back to using vesa instead. Regards! -- Niclas Zeising From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 31 13:50:30 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D40E921D for ; Thu, 31 Jan 2013 13:50:30 +0000 (UTC) (envelope-from ukaszg@gmail.com) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by mx1.freebsd.org (Postfix) with ESMTP id 9C653869 for ; Thu, 31 Jan 2013 13:50:30 +0000 (UTC) Received: by mail-qc0-f178.google.com with SMTP id j34so1272435qco.9 for ; Thu, 31 Jan 2013 05:50:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:cc:content-type; bh=apjwaR7nPuWAj5ztVJtgbtHhhY/ZCTF7L/OdDsgWZw0=; b=MkjLcbNZZH2VLfzKQYDSdkKXqRJL/qtoEpsT9xV8WTDSJkkjrbq/KWp13GUi8kQRzT VIghDclAqZ3nM8Xmq1D6SiS5EtjdK/v+Wa0/TvGyc60/WnYp6KS7khMUHa2joCoBNmW+ q8P6ncd14qoY/q4K+tqPdxUVu4L6X/X5Rdm5DKCSObvpkMnXfl8H/KmZucVVLuBMcoxB 9KOBhbYZ01CM/LA0YnY8BgoReEvo+HGRuPmADkEUvzRLaFeIZMx1fSliyBysrja/3Ssu aVr/WMJIQL8PnQtujXeZKIPp/pZN5ke2zK3HPu6iyrkhnjstDAQlxLMnY4BkgSlFWVlH ENRA== MIME-Version: 1.0 X-Received: by 10.49.59.131 with SMTP id z3mt12212176qeq.1.1359640224386; Thu, 31 Jan 2013 05:50:24 -0800 (PST) Received: by 10.49.26.169 with HTTP; Thu, 31 Jan 2013 05:50:24 -0800 (PST) In-Reply-To: <510A724F.1070704@freebsd.org> References: <510A724F.1070704@freebsd.org> Date: Thu, 31 Jan 2013 14:50:24 +0100 Message-ID: Subject: Re: Xorg help From: uki Content-Type: text/plain; charset=UTF-8 Cc: hackers@freebsd.org, x11@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 13:50:30 -0000 2013/1/31 Niclas Zeising : > This should have been sent to x11@ instead. > On 01/31/13 14:20, Wojciech Puchar wrote: >> long time ago with CRT monitors i used xvidtune and defined my modeline >> based on existing one. >> >> With LCD laptop Xorg automatically selected good one. >> >> Now with desktop and new LG monitor capable of 1920x1080 it uses 1024x768 You probably are using vesa driver, which is limited to 1024x768 max >> What driver should i use with Atom D525? xf86-video-intel29 is the only >> one that works, in spite of market as not supported. Citing https://wiki.freebsd.org/Intel_GPU "Required usermode components are available in the ports tree, you need to add WITH_NEW_XORG=true and WITH_KMS=true to /etc/make.conf. " the driver you should use is xf86-video-intel (rebuild X/kernel if you just changed make.conf) I'm not sure if this is reqired, but my kernel has device i915kms and device drm. With this configuration intel works perfectly. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 31 13:54:27 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CEAD2373; Thu, 31 Jan 2013 13:54:27 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 7C555894; Thu, 31 Jan 2013 13:54:27 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id r0VDsQKJ018144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 31 Jan 2013 07:54:26 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.02.0309.002; Thu, 31 Jan 2013 07:54:25 -0600 From: "Teske, Devin" To: Niclas Zeising , Wojciech Puchar Subject: RE: Xorg help Thread-Topic: Xorg help Thread-Index: AQHN/7XWRcV957C/NEGg73Y+kexmG5hj09qA//+elN0= Date: Thu, 31 Jan 2013 13:54:25 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201EA09B2@ltcfiswmsgmb21> References: , <510A724F.1070704@freebsd.org> In-Reply-To: <510A724F.1070704@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-31_03:2013-01-31,2013-01-31,1970-01-01 signatures=0 Cc: "hackers@freebsd.org" , "x11@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 13:54:27 -0000 (first, apologies for the top-post; using a dumb web-mail client that can't= handle inline) Hi, We use LG Flatron at $work (tho not wide-aspect like the model you mention = -- read: we run our LG Flatron LCDs at 1600x1200). I've had a little experi= ence in working on higher definitions tho (like 1920x1080). Very first thing I do is I run "xrandr" with no arguments to see if the mod= e that I want is listed and available, just not used. If the resolution you want is listed in the xrandr output, then switching t= o it is as simple as running "xrandr --size WxH" where W is pixel-width and= H is pixel-height (e.g. "xrandr --size 1920x1080"). After which, you can m= ake this mode your default by adding the following to =A0the appropriate "D= isplay" subsection in /etc/X11/xorg.conf: Modes "1920x1080" However, if instead the desired mode is _not_ listed by xrandr, it could be= as simple as switching cables (if you're trying to hit 1920x1080 for examp= le, avoid [S]VGA and try DVI or HDMI or DP; switching cables could help). Next, there's a possibility you're not using a driver that supports your gr= aphics card. What I do in that situation is run (as root): X -configure :99 Then I go look at the Driver settings in /root/xorg.conf.new -- if it comes= back as "vesa" then that's the fallback driver and you can't make use of a= nything higher than 1600x1200. If it comes back as something other than "ve= sa" like "nvidia", "ati", "radeon", or "intel", then there's a chance you c= an hit 1920x1080 but we're not done yet. Last thing to do is to update xf86-video-* driver from the ports tree (pick= the one most appropriate for your Desktop hardware). --=20 Devin ________________________________________ From: owner-freebsd-hackers@freebsd.org [owner-freebsd-hackers@freebsd.org]= on behalf of Niclas Zeising [zeising@freebsd.org] Sent: Thursday, January 31, 2013 5:31 AM To: Wojciech Puchar Cc: hackers@freebsd.org; x11@freebsd.org Subject: Re: Xorg help This should have been sent to x11@ instead. On 01/31/13 14:20, Wojciech Puchar wrote: > long time ago with CRT monitors i used xvidtune and defined my modeline > based on existing one. > > With LCD laptop Xorg automatically selected good one. > > Now with desktop and new LG monitor capable of 1920x1080 it uses 1024x768 > > no possible modelines are displayed and i have no idea how to set it > properly. > > It is LG Flatron E2211 if it helps. > > What driver should i use with Atom D525? xf86-video-intel29 is the only > one that works, in spite of market as not supported. > > Or am i missing something? xf86-video-intel29 is not supported. It was used for a short time when gem/kms was still developed. I have no idea what graphics card your atom comes with, it has integrated graphics, but you have to find out which exact version it is. In general, for newer intel graphics cards, the best is to use the new xorg distribution, that should give you hardware acceleration. Otherwise you can try xf86-video-intel in the old xorg distribution, but the risk is that it will revert back to using vesa instead. Regards! -- Niclas Zeising _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 31 15:35:42 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 81A3119F; Thu, 31 Jan 2013 15:35:42 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id F0811E4F; Thu, 31 Jan 2013 15:35:41 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0VFZbB4001814; Thu, 31 Jan 2013 16:35:37 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0VFZb4U001811; Thu, 31 Jan 2013 16:35:37 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 31 Jan 2013 16:35:37 +0100 (CET) From: Wojciech Puchar To: Niclas Zeising Subject: Re: Xorg help In-Reply-To: <510A724F.1070704@freebsd.org> Message-ID: References: <510A724F.1070704@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 31 Jan 2013 16:35:37 +0100 (CET) Cc: hackers@freebsd.org, x11@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 15:35:42 -0000 > xf86-video-intel29 is not supported. It was used for a short time when > gem/kms was still developed. I have no idea what graphics card your > atom comes with, it has integrated graphics, but you have to find out vgapci0@pci0:0:2:0: class=0x030000 card=0x574d8086 chip=0xa0018086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'N10 Family Integrated Graphics Controller' class = display subclass = VGA > which exact version it is. In general, for newer intel graphics cards, > the best is to use the new xorg distribution, that should give you > hardware acceleration. Otherwise you can try xf86-video-intel in the > old xorg distribution, but the risk is that it will revert back to using xf86-video-intel will turn whole screen off and run at 100% CPU (checked by logging from other machine), then only reboot will get display back. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 31 15:36:25 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 53F952C0; Thu, 31 Jan 2013 15:36:25 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id D3F02E62; Thu, 31 Jan 2013 15:36:24 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0VFaMaf001823; Thu, 31 Jan 2013 16:36:22 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0VFaM2x001820; Thu, 31 Jan 2013 16:36:22 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 31 Jan 2013 16:36:22 +0100 (CET) From: Wojciech Puchar To: uki Subject: Re: Xorg help In-Reply-To: Message-ID: References: <510A724F.1070704@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 31 Jan 2013 16:36:22 +0100 (CET) Cc: hackers@freebsd.org, x11@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 15:36:25 -0000 > >>> What driver should i use with Atom D525? xf86-video-intel29 is the only >>> one that works, in spite of market as not supported. > Citing https://wiki.freebsd.org/Intel_GPU > "Required usermode components are available in the ports tree, you > need to add WITH_NEW_XORG=true and WITH_KMS=true to /etc/make.conf. " > > the driver you should use is xf86-video-intel (rebuild X/kernel if you > just changed make.conf) > > I'm not sure if this is reqired, but my kernel has device i915kms and > device drm. With this configuration intel works perfectly. thank you very much. you mean rebuilding X server, X libraries or just xf86-video-intel and kernel? From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 31 15:41:46 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C5E754F9; Thu, 31 Jan 2013 15:41:46 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 74BCCEB9; Thu, 31 Jan 2013 15:41:46 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r0VFfjar006180; Thu, 31 Jan 2013 08:41:45 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r0VFfiLQ006177; Thu, 31 Jan 2013 08:41:44 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 31 Jan 2013 08:41:44 -0700 (MST) From: Warren Block To: Wojciech Puchar Subject: Re: Xorg help In-Reply-To: Message-ID: References: <510A724F.1070704@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Thu, 31 Jan 2013 08:41:45 -0700 (MST) Cc: hackers@freebsd.org, x11@freebsd.org, uki X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 15:41:46 -0000 On Thu, 31 Jan 2013, Wojciech Puchar wrote: >> >>>> What driver should i use with Atom D525? xf86-video-intel29 is the only >>>> one that works, in spite of market as not supported. >> Citing https://wiki.freebsd.org/Intel_GPU >> "Required usermode components are available in the ports tree, you >> need to add WITH_NEW_XORG=true and WITH_KMS=true to /etc/make.conf. " >> >> the driver you should use is xf86-video-intel (rebuild X/kernel if you >> just changed make.conf) >> >> I'm not sure if this is reqired, but my kernel has device i915kms and >> device drm. With this configuration intel works perfectly. > thank you very much. > you mean rebuilding X server, X libraries or just xf86-video-intel and > kernel? This forum post tries for the minimum amount of rebuilding. It is not necessary to rebuild the kernel if you have 9.1 already. http://forums.freebsd.org/showpost.php?p=206841&postcount=8 From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 31 17:04:26 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D24EF171 for ; Thu, 31 Jan 2013 17:04:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B1E1438B for ; Thu, 31 Jan 2013 17:04:26 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 70F36B922; Thu, 31 Jan 2013 12:04:25 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: removing plip from GENERIC Date: Thu, 31 Jan 2013 12:04:11 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <0245666F-066A-40EB-9E09-875B6A29DB9C@mu.org> In-Reply-To: <0245666F-066A-40EB-9E09-875B6A29DB9C@mu.org> MIME-Version: 1.0 Message-Id: <201301311204.11333.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 31 Jan 2013 12:04:25 -0500 (EST) Cc: Eitan Adler , Alfred Perlstein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 17:04:26 -0000 On Wednesday, January 30, 2013 5:09:56 pm Alfred Perlstein wrote: > Does plip no longer work? I had one user ("bf") who verified that plip(4) still worked in March of 2009 after my locking changes to ppc/ppbus. OTOH, I doubt it is very widely used at all. I would probably only leave it in GENERIC for i386 and pc98 if anywhere. Of course, there are many far, far older drivers (like just about everything that is ISA but doesn't include built-in LPC stuff like psm, atkbdc, uart, and ppc) that should be removed before GENERIC before plip. There are machines that may have a ppc port that do not have an ISA slots. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 31 21:56:16 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8BACB1BB; Thu, 31 Jan 2013 21:56:16 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id D51653F3; Thu, 31 Jan 2013 21:56:15 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0VLu6ha002232; Thu, 31 Jan 2013 22:56:06 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0VLu5Lw002223; Thu, 31 Jan 2013 22:56:05 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 31 Jan 2013 22:56:05 +0100 (CET) From: Wojciech Puchar To: "Teske, Devin" Subject: RE: Xorg help In-Reply-To: <13CA24D6AB415D428143D44749F57D7201EA09B2@ltcfiswmsgmb21> Message-ID: References: , <510A724F.1070704@freebsd.org> <13CA24D6AB415D428143D44749F57D7201EA09B2@ltcfiswmsgmb21> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2456600518-1707406617-1359666759=:1445" Content-ID: X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 31 Jan 2013 22:56:06 +0100 (CET) Cc: "hackers@freebsd.org" , "x11@freebsd.org" , Niclas Zeising X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 21:56:16 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2456600518-1707406617-1359666759=:1445 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: > > Hi, > > We use LG Flatron at $work (tho not wide-aspect like the model you mention -- read: we run our LG Flatron LCDs at 1600x1200). I've had a little experience in working on higher definitions tho (like 1920x1080). > > Very first thing I do is I run "xrandr" with no arguments to see if the mode that I want is listed and available, just not used. > > If the resolution you want is listed in the xrandr output, then switching to it is as simple as running "xrandr --size WxH" where W is pixel-width and H is pixel-height (e.g. "xrandr --size 1920x1080"). After which, you can make this mode your default by adding the following to  the appropriate "Display" subsection in /etc/X11/xorg.conf: > > Modes "1920x1080" thanks for all help. now server runs with i915kms, but still required Modes "1920x1080" to turn it. By default it still used 1024x768 no idea why autodetect doesn't work. but works fine manually. thank you LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1280x800 58.1*+ 1024x768 85.0 75.0 70.1 60.0 43.5 832x624 74.6 800x600 85.1 72.2 75.0 60.3 56.2 640x480 85.0 72.8 75.0 59.9 720x400 85.0 640x400 85.1 640x350 85.1 VGA1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm 1920x1080 60.0*+ 1680x1050 60.0 1280x1024 75.0 60.0 1152x864 75.0 1024x768 75.1 60.0 800x600 75.0 60.3 640x480 75.0 60.0 720x400 70.1 --2456600518-1707406617-1359666759=:1445-- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 1 06:23:35 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 68CFE2E0; Fri, 1 Feb 2013 06:23:35 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 2D0FFD3F; Fri, 1 Feb 2013 06:23:34 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r116NRCo059212; Fri, 1 Feb 2013 06:23:27 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id hfvkn86myvzupfitr7f2pvrxui; Fri, 01 Feb 2013 06:23:27 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Testing SIOCADDMULTI? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <201301281109.24879.jhb@freebsd.org> Date: Thu, 31 Jan 2013 22:23:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <965B76D3-8BE8-4DA1-8A48-D22238490D03@kientzle.com> References: <7A0E9B71-0232-4808-B5D4-5B0D811B353C@kientzle.com> <201301281109.24879.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1283) Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 06:23:35 -0000 On Jan 28, 2013, at 8:09 AM, John Baldwin wrote: > On Sunday, January 27, 2013 1:51:12 am Tim Kientzle wrote: >>=20 >> On Jan 26, 2013, at 3:56 PM, Tim Kientzle wrote: >>=20 >>> My next TODO items for this network driver is to implement >>> the SIOCADDMULTI and SIOCDELMULTI ioctls. >>=20 >> DELMULTI seems trickier. ... >> ... it looks like I have no choice but to remove >> every multicast address from the controller and then >> re-insert all of the ones that are still valid. >> ... >> Is there a better approach? >=20 > You should always reprogram the full table while holding = if_maddr_rlock(). Thanks. That's ultimately what I did. I was able to dump the table from the controller to eyeball that the entries looked right but haven't yet done any testing beyond that. >> Would still appreciate any suggestions for how to test these. >=20 > You can write a simple app to listen for UDP packets and have it join = a=20 > multicast group and have another machine on the same network write a = packet to=20 > the multicast group. I tried this first, but the test program worked fine even without ADDMULTI/DELMULTI support. Watching tcpdump -e, it appears that IP4 multicast UDP uses broadcast at the Ethernet layer. > However, a simpler test is to toggle the sysctl to enable multicast = ping=20 > replies and to ping a multicast address from another machine after = joining it=20 > on the test machine using mutest. Ahhh=85. I wasn't aware of these tools; I'll take a look. Thanks for the pointer! Tim From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 1 12:47:05 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CC8279DB for ; Fri, 1 Feb 2013 12:47:05 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3A4CA2A2 for ; Fri, 1 Feb 2013 12:47:04 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r11Cl0hK074733 for ; Fri, 1 Feb 2013 13:47:00 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r11Ckxsf074730 for ; Fri, 1 Feb 2013 13:47:00 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 1 Feb 2013 13:46:59 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: receiving aerial digital TV Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 01 Feb 2013 13:47:00 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 12:47:05 -0000 i am out of current knowledge about common TV for about 10 years. Currently in Poland there is aerial TV broadcasted in DVB-T standard. There are TVs with builtin decoder/demodulator or separate decoders/demodulator with HDMI output. But how about just receiving demodulated data and letting mplayer play it, and - most importantly - recording it directly. I know there are USB receivers on market. Are such devices supported under FreeBSD? if so - what driver, what chipset to look when buying such a thing? any other recommendation. With analog TV broadcast there were PCI cards with brooktree chipset that worked with FreeBSD. Thank you very much From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 1 13:01:36 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C49C7E03; Fri, 1 Feb 2013 13:01:36 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B25D7354; Fri, 1 Feb 2013 13:01:35 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA19552; Fri, 01 Feb 2013 15:01:34 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <510BBCAD.3070705@FreeBSD.org> Date: Fri, 01 Feb 2013 15:01:33 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 To: toolchain@FreeBSD.org Subject: Re: base gcc and _GLIBCXX_USE_C99 References: <5106953E.2020907@FreeBSD.org> In-Reply-To: <5106953E.2020907@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 13:01:36 -0000 [ping] on 28/01/2013 17:11 Andriy Gapon said the following: > > Guys, > > I wonder why the following is the case for the base gcc. > /usr/include/c++/4.2/bits/c++config.h: > > /* Define if C99 functions or macros from , , , > , and can be used or exposed. */ > /* #undef _GLIBCXX_USE_C99 */ > > Because of this undef there is no e.g. std::strtoll(). > Ditto for other things in stdlib.h. > -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 1 13:08:24 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3F9C6298; Fri, 1 Feb 2013 13:08:24 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id EEE9E3F2; Fri, 1 Feb 2013 13:08:23 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6CC2B5C5A; Fri, 1 Feb 2013 14:08:22 +0100 (CET) Message-ID: <510BBE48.4070101@FreeBSD.org> Date: Fri, 01 Feb 2013 14:08:24 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Andriy Gapon , toolchain@FreeBSD.org Subject: Re: base gcc and _GLIBCXX_USE_C99 References: <5106953E.2020907@FreeBSD.org> <510BBCAD.3070705@FreeBSD.org> In-Reply-To: <510BBCAD.3070705@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 13:08:24 -0000 On 2013-02-01 14:01, Andriy Gapon wrote: > on 28/01/2013 17:11 Andriy Gapon said the following: >> I wonder why the following is the case for the base gcc. >> /usr/include/c++/4.2/bits/c++config.h: >> >> /* Define if C99 functions or macros from , , , >> , and can be used or exposed. */ >> /* #undef _GLIBCXX_USE_C99 */ >> >> Because of this undef there is no e.g. std::strtoll(). >> Ditto for other things in stdlib.h. Maybe this support can't be enabled, because we don't expose all the required functions yet? Or maybe it is just something that was committed years ago, and then forgotten. If we are sure that all the C99 functions libstdc++ requires are now available and working, I see no problem in turning on _GLIBCXX_USE_C99. From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 1 13:31:22 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A266590C; Fri, 1 Feb 2013 13:31:22 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8658D752; Fri, 1 Feb 2013 13:31:20 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA19836; Fri, 01 Feb 2013 15:31:19 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <510BC3A7.5040405@FreeBSD.org> Date: Fri, 01 Feb 2013 15:31:19 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: base gcc and _GLIBCXX_USE_C99 References: <5106953E.2020907@FreeBSD.org> <510BBCAD.3070705@FreeBSD.org> <510BBE48.4070101@FreeBSD.org> In-Reply-To: <510BBE48.4070101@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: toolchain@FreeBSD.org, freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 13:31:22 -0000 on 01/02/2013 15:08 Dimitry Andric said the following: > On 2013-02-01 14:01, Andriy Gapon wrote: >> on 28/01/2013 17:11 Andriy Gapon said the following: >>> I wonder why the following is the case for the base gcc. >>> /usr/include/c++/4.2/bits/c++config.h: >>> >>> /* Define if C99 functions or macros from , , , >>> , and can be used or exposed. */ >>> /* #undef _GLIBCXX_USE_C99 */ >>> >>> Because of this undef there is no e.g. std::strtoll(). >>> Ditto for other things in stdlib.h. > > Maybe this support can't be enabled, because we don't expose all the > required functions yet? Or maybe it is just something that was > committed years ago, and then forgotten. > > If we are sure that all the C99 functions libstdc++ requires are now > available and working, I see no problem in turning on _GLIBCXX_USE_C99. Having looked into the source code of a recent GCC I get an impression that this is a silliness on GCC's part (plus incompleteness of FreeBSD C99 support, it seems). cstdlib would provide e.g. std::strtoull only when _GLIBCXX_USE_C99 is defined. Now looking at libstdc++-v3/acinclude.m4 we can see that there is a dedicated check "for ISO C99 support in ". That check sets variable glibcxx_cv_c99_stdlib. But, _GLIBCXX_USE_C99 is set only if all of glibcxx_cv_c99_math, glibcxx_cv_c99_complex, glibcxx_cv_c99_stdio, glibcxx_cv_c99_stdlib and glibcxx_cv_c99_wchar are set. So if glibcxx_cv_c99_stdlib is yes, but something like glibcxx_cv_c99_complex is no, then no std::strtoull for me. Not sure why GCC couldn't have a dedicated macro "_GLIBCXX_USE_C99_STDLIB" like e.g. _GLIBCXX_USE_C99_MATH that it does have. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 1 14:03:00 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 10AF0E7D; Fri, 1 Feb 2013 14:03:00 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id C3F1E899; Fri, 1 Feb 2013 14:02:59 +0000 (UTC) Received: from [10.59.59.246] (ip-62-235-212-202.dsl.scarlet.be [62.235.212.202]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r11E2pRq017104 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 1 Feb 2013 14:02:52 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: base gcc and _GLIBCXX_USE_C99 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_CE12C059-AE20-49B6-9CC3-FD2DD38B96FF"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: David Chisnall In-Reply-To: <510BC3A7.5040405@FreeBSD.org> Date: Fri, 1 Feb 2013 14:02:53 +0000 Message-Id: <2F55F617-B12D-478D-8B24-3A705D6114BB@FreeBSD.org> References: <5106953E.2020907@FreeBSD.org> <510BBCAD.3070705@FreeBSD.org> <510BBE48.4070101@FreeBSD.org> <510BC3A7.5040405@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1278) Cc: toolchain@FreeBSD.org, Dimitry Andric , freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 14:03:00 -0000 --Apple-Mail=_CE12C059-AE20-49B6-9CC3-FD2DD38B96FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 1 Feb 2013, at 13:31, Andriy Gapon wrote: > cstdlib would provide e.g. std::strtoull only when _GLIBCXX_USE_C99 is = defined. This is entirely consistent with the standard. strtoull() should only = be visible when compiling in C++11 mode, it is not part of C++98 / = C++03. David --Apple-Mail=_CE12C059-AE20-49B6-9CC3-FD2DD38B96FF 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----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQIcBAEBAgAGBQJRC8sNAAoJEKx65DEEsqIdcCEQAIkmYIMH2vL8o7g4Hbjh2b+R kTMbdXJnZGTxVIAL2rJ/Aq7qw1FKRui8kyLFBaby258PPgD0lsD+GaTbiCHbmFVn FPjBValn+kwxxcp2jt68VG0Lt6jNPrP15CGL7AFkIhqL6mDI/lW1VZI2FPhTycS+ SaiTdSniruXeL7nN1jOti73y637Cm9MeGfnp1C2Hp0VhDKIcEvr0uDeotz+/FJd9 U6PkTaS2tvo4E2q3zCjh1IYVaAQhW1HoD/R7ATysE2yRmcqyFG5uTqqNashede1f h9D1YI4kg8OGzX5ZSJrOJ3S2dYiuLGQJa4XIMSV6RuvGvztVd2FF/Y5n0lcJxuEu brHur06bEbzG9GC/xtB8F+j/WHtG9VsfO6nTPdOSf3T1LNuO4P9xrfUJIwuQuYmz hEp0uYIqGc74cXw+BECiK+fGjf4l+gqWDXZ8SLrVKhk+iihz8PX+gurJVYXzUf5q G1zqIJNsgg3/dQUAuxXB2eXp0G3S9uYOVUOoIdRXESlVbIxUfp+7NaJnSs2KFvP1 6ehVUgsgbWnFQPUNMcr6v+uM0iLLtLgo1rMACKnfkwOxSC3TvC6yWa/roza7o72c tFN5rAFvK2k906f9onfX64uJ4Lq5/PPkD8Im/Np5tYjcBaWyl0yCHzpUll6BKzyH PrW4BjcebJtAPFKNCMMi =Ocnj -----END PGP SIGNATURE----- --Apple-Mail=_CE12C059-AE20-49B6-9CC3-FD2DD38B96FF-- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 1 14:19:34 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 77843408 for ; Fri, 1 Feb 2013 14:19:34 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.c2i.net [212.247.154.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0A3F4964 for ; Fri, 1 Feb 2013 14:19:33 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 377116802; Fri, 01 Feb 2013 15:19:25 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Subject: Re: receiving aerial digital TV Date: Fri, 1 Feb 2013 15:20:36 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: In-Reply-To: X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, Cc: Wojciech Puchar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 14:19:34 -0000 On Friday 01 February 2013 13:46:59 Wojciech Puchar wrote: > i am out of current knowledge about common TV for about 10 years. > > Currently in Poland there is aerial TV broadcasted in DVB-T standard. > There are TVs with builtin decoder/demodulator or separate > decoders/demodulator with HDMI output. > > But how about just receiving demodulated data and letting mplayer play it, > and - most importantly - recording it directly. I know there are USB > receivers on market. > > Are such devices supported under FreeBSD? if so - what driver, what > chipset to look when buying such a thing? any other recommendation. > > With analog TV broadcast there were PCI cards with brooktree chipset that > worked with FreeBSD. > /usr/ports/multimedia/webcamd /usr/ports/multimedia/cx88 --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 1 14:27:08 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2F654A45 for ; Fri, 1 Feb 2013 14:27:08 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id B16AD9C2 for ; Fri, 1 Feb 2013 14:27:07 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r11EQwlw043735 for ; Fri, 1 Feb 2013 15:26:58 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r11EQwTV043732 for ; Fri, 1 Feb 2013 15:26:58 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 1 Feb 2013 15:26:58 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: HDD write cache Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 01 Feb 2013 15:26:58 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 14:27:08 -0000 after reading quite recent topics about disabling/enabling write cache, i tried to test in on desktop 3.5" drive kern.cam.ada.write_cache: 1 kern.cam.ada.read_ahead: 1 kern.cam.ada.0.read_ahead: -1 kern.cam.ada.0.write_cache: -1 i tried writing 1 or 0 to kern.cam.ada.0.write_cache, and there were exactly no differences at all, and disk seems to do always write caching. Does that drive lie and ignore commands or i do it wrong? this is my disk. ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 1 14:54:35 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 395C83DA for ; Fri, 1 Feb 2013 14:54:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1871CB07 for ; Fri, 1 Feb 2013 14:54:35 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6BF7EB9AB; Fri, 1 Feb 2013 09:54:34 -0500 (EST) From: John Baldwin To: Tim Kientzle Subject: Re: Testing SIOCADDMULTI? Date: Fri, 1 Feb 2013 09:52:26 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201301281109.24879.jhb@freebsd.org> <965B76D3-8BE8-4DA1-8A48-D22238490D03@kientzle.com> In-Reply-To: <965B76D3-8BE8-4DA1-8A48-D22238490D03@kientzle.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <201302010952.26859.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 01 Feb 2013 09:54:34 -0500 (EST) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 14:54:35 -0000 On Friday, February 01, 2013 1:23:26 am Tim Kientzle wrote: > >> Would still appreciate any suggestions for how to test these. > > > > You can write a simple app to listen for UDP packets and have it join a > > multicast group and have another machine on the same network write a packet to > > the multicast group. > > I tried this first, but the test program worked fine even > without ADDMULTI/DELMULTI support. Watching > tcpdump -e, it appears that IP4 multicast UDP uses > broadcast at the Ethernet layer. Were you running tcpdump? You have to use tcpdump -p to avoid putting the chip into promiscuous mode if so (promiscious causes the NIC to receive all multicast regardless of the filters assuming that your driver supports it correctly). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 1 15:03:57 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DBEE6586 for ; Fri, 1 Feb 2013 15:03:57 +0000 (UTC) (envelope-from prvs=174407b200=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 73853B8D for ; Fri, 1 Feb 2013 15:03:57 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50001963435.msg for ; Fri, 01 Feb 2013 15:03:50 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 01 Feb 2013 15:03:50 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=174407b200=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org Message-ID: From: "Steven Hartland" To: "Wojciech Puchar" , References: Subject: Re: HDD write cache Date: Fri, 1 Feb 2013 15:04:30 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 15:03:57 -0000 Looking at the cam ata code I can't see how those values would do anything after booting. I suspect they should be loader only tunables with the current code and cant be changed on the fly for a disk that's already been registered. Try setting the values in /boot/loader.conf if you haven't already? You can check the actual status of the disk itself using:- camcontrol identify ada0 Regards Steve ----- Original Message ----- From: "Wojciech Puchar" To: Sent: Friday, February 01, 2013 2:26 PM Subject: HDD write cache > after reading quite recent topics about disabling/enabling write cache, i > tried to test in on desktop 3.5" drive > > kern.cam.ada.write_cache: 1 > kern.cam.ada.read_ahead: 1 > kern.cam.ada.0.read_ahead: -1 > kern.cam.ada.0.write_cache: -1 > > i tried writing 1 or 0 to kern.cam.ada.0.write_cache, and there were > exactly no differences at all, and disk seems to do always write caching. > > Does that drive lie and ignore commands or i do it wrong? > > this is my disk. > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-8 SATA 2.x device > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 1 16:30:52 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CD3C6F77 for ; Fri, 1 Feb 2013 16:30:52 +0000 (UTC) (envelope-from prvs=174407b200=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 633F068 for ; Fri, 1 Feb 2013 16:30:51 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50001964739.msg for ; Fri, 01 Feb 2013 16:30:49 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 01 Feb 2013 16:30:49 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=174407b200=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org Message-ID: <72C01AB30B93443C8C6F1183A04BBE30@multiplay.co.uk> From: "Steven Hartland" To: "Steven Hartland" , "Wojciech Puchar" , References: Subject: Re: HDD write cache Date: Fri, 1 Feb 2013 16:31:30 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 16:30:52 -0000 Investigating a bit more a device reset will also trigger the change so after changing the value you can use camcontrol reset to trigger the change to apply using e.g. camcontrol reset 0:0:0 While this is stated in the man for ada its not obvious that changing the sysctl without a reset won't work, so you might want to raise a PR about it. Regards Steve ----- Original Message ----- From: "Steven Hartland" > Looking at the cam ata code I can't see how those values would do > anything after booting. > > I suspect they should be loader only tunables with the current code > and cant be changed on the fly for a disk that's already been > registered. > > Try setting the values in /boot/loader.conf if you haven't already? > > You can check the actual status of the disk itself using:- > camcontrol identify ada0 > > Regards > Steve > > ----- Original Message ----- > From: "Wojciech Puchar" > >> after reading quite recent topics about disabling/enabling write cache, i >> tried to test in on desktop 3.5" drive >> >> kern.cam.ada.write_cache: 1 >> kern.cam.ada.read_ahead: 1 >> kern.cam.ada.0.read_ahead: -1 >> kern.cam.ada.0.write_cache: -1 >> >> i tried writing 1 or 0 to kern.cam.ada.0.write_cache, and there were >> exactly no differences at all, and disk seems to do always write caching. >> >> Does that drive lie and ignore commands or i do it wrong? >> >> this is my disk. >> >> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >> ada0: ATA-8 SATA 2.x device >> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> ada0: Command Queueing enabled >> ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 1 18:27:55 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BC84E6BB; Fri, 1 Feb 2013 18:27:55 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-ia0-x234.google.com (ia-in-x0234.1e100.net [IPv6:2607:f8b0:4001:c02::234]) by mx1.freebsd.org (Postfix) with ESMTP id 8C0627EB; Fri, 1 Feb 2013 18:27:55 +0000 (UTC) Received: by mail-ia0-f180.google.com with SMTP id f27so5644492iae.25 for ; Fri, 01 Feb 2013 10:27:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=w3/KHsW7ERIhgE46U9ftqdvWdJMsfeesZldmTgb5hFg=; b=dE64BePTYm2DUvUcys9E4dlBzVyc4DmvNYPVf3f1IV//fiNy/olbxW1yOA4qeQwmwi MR14mrCOFEUvLqX5BlO1S0s+RUl+9YsssBgQieIgOBTbbn8Z0LyFEG7XvYmqPXoDDfOK GanTqD0z+4umRFFzQPcqK7hw1PoxI0rHA08i1Mu9hfROOEVtfMfalRXxX3/jKHgQ0Vt9 ppck1UCxrqJEQMfvLLnVxdbBbXKl7bDm+Gmoua+v1m2GEe3INmXXmM0nHtJUb3JdaRWK 8d5uIKUK1EDfn7b92pfKpAgAsC7oXgyDYnotClKaiTJlEv9p9V1XNL2joDqBevVBSFVr NKaw== MIME-Version: 1.0 X-Received: by 10.43.131.202 with SMTP id hr10mr1516057icc.15.1359743274997; Fri, 01 Feb 2013 10:27:54 -0800 (PST) Received: by 10.64.107.196 with HTTP; Fri, 1 Feb 2013 10:27:54 -0800 (PST) Date: Fri, 1 Feb 2013 10:27:54 -0800 Message-ID: Subject: Re: receiving aerial digital TV From: Dieter BSD To: freebsd-hackers@freebsd.org, freebsd-multimedia@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 18:27:55 -0000 [ This topic is better discussed in -multimedia@, suggest that followups drop -hackers@ ] > i am out of current knowledge about common TV for about 10 years. > > Currently in Poland there is aerial TV broadcasted in DVB-T standard. > There are TVs with builtin decoder/demodulator or separate > decoders/demodulator with HDMI output. > > But how about just receiving demodulated data and letting mplayer play it, > and - most importantly - recording it directly. I know there are USB > receivers on market. > > Are such devices supported under FreeBSD? if so - what driver, what > chipset to look when buying such a thing? any other recommendation. > > With analog TV broadcast there were PCI cards with brooktree chipset that > worked with FreeBSD. There are PCI and PCIe tuner cards, USB tuners, and Ethernet tuners. There used to be firewire tuners but these have disappeared the last time I looked. Each type has advantages and disadvantages. Cards require expansion slots, which you may or may not have available. Ethernet tuners allow locating the tuner near the antenna, giving less signal loss in the coax. And they don't need a slot, and are OS independent. Unfortunately, there seems to be only 1 brand of Ethernet tuner (Silicondust HDhomerun). The ATSC/8VSB version has better debugging info than other tuners, but there are many reports that other tuners give better reception. I don't know if this applies to the DVB-T version. Word is that some of the very small USB tuners suffer from poor reception. A high-gain "outdoor" antenna will give much better reception (due to less multipath) than a low gain antenna. Garbage in garbage out. If you manage to get a signal that is too strong, an attenuator is very inexpensive. Yes, you should be able to record to a file on disk and watch it later. Cron(8) and at(1) are useful for this. Some people like mythtv. Many of the cards use a cx88 family chip. cx88 (in ports) supports many of these cards. http://corona.homeunix.net/cx88wiki Ethernet tuners http://www.silicondust.com/ Useful forums for tuners, antennas, how to fix reception problems, ... http://www.avsforum.com/ Useful info about antennas and reception http://www.hdtvprimer.com From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 1 19:04:54 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 40DC6273 for ; Fri, 1 Feb 2013 19:04:54 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-ia0-x22f.google.com (ia-in-x022f.1e100.net [IPv6:2607:f8b0:4001:c02::22f]) by mx1.freebsd.org (Postfix) with ESMTP id E59D69B1 for ; Fri, 1 Feb 2013 19:04:53 +0000 (UTC) Received: by mail-ia0-f175.google.com with SMTP id r4so5802537iaj.34 for ; Fri, 01 Feb 2013 11:04:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=Y/Kwr7/4vFPZy0EiJb9dIbsdttrFjjvswIEq3zbDHGM=; b=JgGDfeONtE60b2W4jVtYKRIT0Xu/xcS0zi1Vifpuiu/M5hMRXBvqWQYXJvDFCL81pG JkMLLWLkthtzCd3rG/2Ncd/O+TLH1xp/hkLdGDL+LKh0thDMf03AFI4g6yWKGgTRABlc duk5ecqg/mF19WUxQ1Hgq2tg3rj4fym+4UX4prxebObI7FPKGAbcjAVhhvx912wpyHRG nFYsujrXFwcb3115LvGDGHc8KBR79eL+tBHO4S/QmoFftMM77lXq4TOt0L+UWzznCVE3 3Me+0tPQ8tC4l21Lkjq4sRvDyOhGvqKWe5FGGMOMWegph3WWeRfTZ6RFfnLcPN+R2qkE GfAQ== MIME-Version: 1.0 X-Received: by 10.50.185.229 with SMTP id ff5mr1881494igc.82.1359745488115; Fri, 01 Feb 2013 11:04:48 -0800 (PST) Received: by 10.64.107.196 with HTTP; Fri, 1 Feb 2013 11:04:47 -0800 (PST) Date: Fri, 1 Feb 2013 11:04:47 -0800 Message-ID: Subject: Re: HDD write cache From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 19:04:54 -0000 Wojciech writes: > after reading quite recent topics about disabling/enabling write cache, i > tried to test in on desktop 3.5" drive > > kern.cam.ada.write_cache: 1 > kern.cam.ada.read_ahead: 1 > kern.cam.ada.0.read_ahead: -1 > kern.cam.ada.0.write_cache: -1 > > i tried writing 1 or 0 to kern.cam.ada.0.write_cache, and there were > exactly no differences at all, and disk seems to do always write caching. > > Does that drive lie and ignore commands or i do it wrong? > > this is my disk. > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-8 SATA 2.x device > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) 1) See the other followups about making sure this change actually takes effect. 2) How, exactly, are you testing this? With Command Queueing enabled, (and assuming that it is working properly) you will not see any difference in speed with a casual test. Does ata(4) support your controller? Last time I looked, ata did not support NCQ. :-( So turning the write cache on/off gives a huge difference in speed. When ahci and siis came out, NCQ was so fast that it looked like the write cache was on. I had to write a special pathological test to be able to tell the difference between having the write cache on and using NCQ. I needed to verify that the write cache was really off so that my data was safe. In anything resembling normal use, NCQ with the write cache off is just as fast as having the write cache on. You really get the best of both worlds, speed and safety. Now all we need is NCQ support for all the controllers that have it. From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 2 00:14:43 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 872DE3BE for ; Sat, 2 Feb 2013 00:14:43 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id DCC9975C for ; Sat, 2 Feb 2013 00:14:42 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r120Ebrj001910; Sat, 2 Feb 2013 01:14:37 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r120EbV8001894; Sat, 2 Feb 2013 01:14:37 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 2 Feb 2013 01:14:37 +0100 (CET) From: Wojciech Puchar To: Steven Hartland Subject: Re: HDD write cache In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 02 Feb 2013 01:14:37 +0100 (CET) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 00:14:43 -0000 > registered. > > Try setting the values in /boot/loader.conf if you haven't already? > > You can check the actual status of the disk itself using:- > camcontrol identify ada0 this proved your statement. will check it out at next reboot. > > Regards > Steve > > ----- Original Message ----- From: "Wojciech Puchar" > > To: > Sent: Friday, February 01, 2013 2:26 PM > Subject: HDD write cache > > >> after reading quite recent topics about disabling/enabling write cache, i >> tried to test in on desktop 3.5" drive >> >> kern.cam.ada.write_cache: 1 >> kern.cam.ada.read_ahead: 1 >> kern.cam.ada.0.read_ahead: -1 >> kern.cam.ada.0.write_cache: -1 >> >> i tried writing 1 or 0 to kern.cam.ada.0.write_cache, and there were >> exactly no differences at all, and disk seems to do always write caching. >> >> Does that drive lie and ignore commands or i do it wrong? >> >> this is my disk. >> >> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >> ada0: ATA-8 SATA 2.x device >> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> ada0: Command Queueing enabled >> ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. and the > person or entity to whom it is addressed. In the event of misdirection, the > recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 2 00:19:53 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 634814C8 for ; Sat, 2 Feb 2013 00:19:53 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id D5C45793 for ; Sat, 2 Feb 2013 00:19:52 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r120Jo83007801; Sat, 2 Feb 2013 01:19:50 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r120JoIA007798; Sat, 2 Feb 2013 01:19:50 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 2 Feb 2013 01:19:50 +0100 (CET) From: Wojciech Puchar To: Steven Hartland Subject: Re: HDD write cache In-Reply-To: <72C01AB30B93443C8C6F1183A04BBE30@multiplay.co.uk> Message-ID: References: <72C01AB30B93443C8C6F1183A04BBE30@multiplay.co.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 02 Feb 2013 01:19:50 +0100 (CET) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 00:19:53 -0000 > Investigating a bit more a device reset will also trigger the > change so after changing the value you can use camcontrol reset > to trigger the change to apply using e.g. > camcontrol reset 0:0:0 THIS actually work. And the results are disastrous. in spite of NCQ working and fully filled, when unpacking source tree (as a test) onto UFS filesystem gstat shows at most 100 IOPS, and average 700 with write cache disabled. this is on / partition that spans 1/10 of disk. Drive can actually manage multiple writes in short distance well with write cache enabled. > > While this is stated in the man for ada its not obvious that > changing the sysctl without a reset won't work, so you might > want to raise a PR about it. > > Regards > Steve > > ----- Original Message ----- From: "Steven Hartland" >> Looking at the cam ata code I can't see how those values would do >> anything after booting. >> >> I suspect they should be loader only tunables with the current code >> and cant be changed on the fly for a disk that's already been >> registered. >> >> Try setting the values in /boot/loader.conf if you haven't already? >> >> You can check the actual status of the disk itself using:- >> camcontrol identify ada0 >> >> Regards >> Steve >> >> ----- Original Message ----- From: "Wojciech Puchar" >> >>> after reading quite recent topics about disabling/enabling write cache, i >>> tried to test in on desktop 3.5" drive >>> >>> kern.cam.ada.write_cache: 1 >>> kern.cam.ada.read_ahead: 1 >>> kern.cam.ada.0.read_ahead: -1 >>> kern.cam.ada.0.write_cache: -1 >>> >>> i tried writing 1 or 0 to kern.cam.ada.0.write_cache, and there were >>> exactly no differences at all, and disk seems to do always write caching. >>> >>> Does that drive lie and ignore commands or i do it wrong? >>> >>> this is my disk. >>> >>> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >>> ada0: ATA-8 SATA 2.x device >>> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >>> ada0: Command Queueing enabled >>> ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. and the > person or entity to whom it is addressed. In the event of misdirection, the > recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 2 08:20:20 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 83DAB8FD for ; Sat, 2 Feb 2013 08:20:20 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by mx1.freebsd.org (Postfix) with ESMTP id 1EACC3DF for ; Sat, 2 Feb 2013 08:20:19 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id c13so2379646eek.14 for ; Sat, 02 Feb 2013 00:20:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:date:from:to:subject:message-id:in-reply-to:references :reply-to:x-mailer:mime-version:content-type :content-transfer-encoding; bh=QFLstRuzNqmImPVPWlS49GEE5gFMa32uq8Bs48Jy6sM=; b=w365+jUJlKlv/k/PGgVZUBBVAbTwL2axPXKEI92DPQE1TU37AbhYz4LDBvknnnBzOS Lawrqu6fzLMQLF5XPNbKao5nYRgH4e4SOk1aVO3H6f2Syr5xYOs8t1Uz1aBn9QaJWexb ByJRu4Pw1DCtTPB3u7Nbd65fA5AoYXZ7YiJmWKwpucI/mWurngYYKHCCnHsV4skDnAka cST8aT/vejkrxaeO5Xbuyy6c4Z0paiftYHxjr7q6cMMIuMvjEGD6gY74zurSyHasJf0v KjAjcVvyMPvCR0k+6xQDPD5udgupFMtmrGH3+c6lEu7Lmzt6L+OXmhRHEO1WkRdnivyF Z89Q== X-Received: by 10.14.176.133 with SMTP id b5mr33919919eem.37.1359793218927; Sat, 02 Feb 2013 00:20:18 -0800 (PST) Received: from ernst.jennejohn.org (p578E2091.dip.t-dialin.net. [87.142.32.145]) by mx.google.com with ESMTPS id 3sm16417158eej.6.2013.02.02.00.20.17 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 02 Feb 2013 00:20:18 -0800 (PST) Date: Sat, 2 Feb 2013 09:20:16 +0100 From: Gary Jennejohn To: freebsd-hackers@freebsd.org Subject: Re: HDD write cache Message-ID: <20130202092016.6352519f@ernst.jennejohn.org> In-Reply-To: References: <72C01AB30B93443C8C6F1183A04BBE30@multiplay.co.uk> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 08:20:20 -0000 On Sat, 2 Feb 2013 01:19:50 +0100 (CET) Wojciech Puchar wrote: > > Investigating a bit more a device reset will also trigger the > > change so after changing the value you can use camcontrol reset > > to trigger the change to apply using e.g. > > camcontrol reset 0:0:0 > > THIS actually work. > > And the results are disastrous. in spite of NCQ working and fully filled, > when unpacking source tree (as a test) onto UFS filesystem gstat shows at > most 100 IOPS, and average 700 with write cache disabled. > > this is on / partition that spans 1/10 of disk. Drive can actually manage > multiple writes in short distance well with write cache enabled. > I also noticed a drastic drop in throughput when I disabled the write cache, about a factor of 4 or 5. However, in my case every HDD supports NCQ (32 tags), but NCQ is not enabled on any HDD. Whether that's because the driver for my chipset (ATI IXP700 AHCI SATA controller) doesn't turn NCQ on or for another reason, I can't say. I looked at the man page for camcontrol but a mechanism to turn on NCQ in the HDDs didn't jump off the page. Does anyone know off-hand of a way to turn on NCQ in the HDDs, other than maybe modifying the driver? -- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 2 10:26:25 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 631A7AF3 for ; Sat, 2 Feb 2013 10:26:25 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-la0-x22e.google.com (la-in-x022e.1e100.net [IPv6:2a00:1450:4010:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id D193D93B for ; Sat, 2 Feb 2013 10:26:24 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id fq12so3435349lab.19 for ; Sat, 02 Feb 2013 02:26:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :x-gm-message-state; bh=w+XZXqq6QvkBDeRMctuoiAJsg20NV90O+w5bNf1NOE0=; b=Xut9r+3jCkFoj2v+ym7r/IzHVu2ZGlAPxgk+AAHndsGfqKbw7s//MJz56Vt6UStTt/ juBtGxk1D0aak4VXnvLYa+m7yYAvnxLgW+grkjjaCrASsxyioQ5WdV8MZiVcngv55Cm4 v2y1zDb4tAUsjZWM82/T2GMAmexB937nnI+jmmFHxJodmJ4Nn/vNUsAykd5RwXF8q0ll Qm6cCA0YIabOzN/bfIXrQLsXR/gqr3OZ0k3mUhkUHI0VAEwgf3Qptmj5xn6D2abP+MVf TzcctsI2XVybzgC6ez5xETUufYgLWjXJqoAQttFh8+xMArlgp05rpeODuqQZN24gCcXj Nn5g== X-Received: by 10.152.122.100 with SMTP id lr4mr389463lab.28.1359800783813; Sat, 02 Feb 2013 02:26:23 -0800 (PST) Received: from zont-osx.local (ppp95-165-134-17.pppoe.spdop.ru. [95.165.134.17]) by mx.google.com with ESMTPS id u5sm3361180lbm.8.2013.02.02.02.26.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Feb 2013 02:26:22 -0800 (PST) Sender: Andrey Zonov Message-ID: <510CE9CB.6070901@FreeBSD.org> Date: Sat, 02 Feb 2013 14:26:19 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Willem Jan Withagen Subject: Re: Failsafe on kernel panic References: <201301161513.27016.jhb@freebsd.org> <1358392725.32417.179.camel@revolution.hippie.lan> <50FBFA2C.2010504@digiware.nl> In-Reply-To: <50FBFA2C.2010504@digiware.nl> X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2MVDUAHWIKNSFOUDCWMAO" X-Gm-Message-State: ALoCoQl7xK9VNBFQgbwBrMSZNBpkBPbdAXLTpWOmr9xSFcuFFcYCO5ehJXd7WnQ5FyPDfDiYPsD7 Cc: freebsd-hackers@FreeBSD.org, Sami Halabi , "freebsd-stable@freebsd.org" , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 10:26:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2MVDUAHWIKNSFOUDCWMAO Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/20/13 6:07 PM, Willem Jan Withagen wrote: > On 17-1-2013 4:18, Ian Lepore wrote: >> On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote: >>> Thank you for your response, very helpful. >>> one question - how do i configure auto-reboot once kernel panic occur= s? >>> >>> Sami >>> >> >> From src/sys/conf/NOTES, this may be what you're looking for... >> >> # >> # Don't enter the debugger for a panic. Intended for unattended operat= ion >> # where you may want to enter the debugger from the console, but still= want >> # the machine to recover from a panic. >> # >> options KDB_UNATTENDED >> >> But I think it only has meaning if you have option KDB in effect, >> otherwise it should just reboot itself after a 15 second pause. >=20 > Well it is not the magical fix-all solution. >=20 > Last night I had to drive to the colo (lucky for me a 5 min drive.) > because I could not get a system to reboot/recover from a crash. >=20 > Upon arrival the system was crashed and halted on the message: > rebooting in 15 sec. >=20 I've seen the same thing many and many times. Now I'm using ddb to save crash dump and reboot machine on panic. It's much more reliable. --=20 Andrey Zonov ------enig2MVDUAHWIKNSFOUDCWMAO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJRDOnOAAoJEBWLemxX/CvTPfMH/R2X0hi913nmL1Tvrw+zMGqz MLFv+karGxYuHeQgquKv85/ShW07pCGeo0raeb+V0RAD3hoZaBpqnOYjGQdK3ju9 0bOhpHezexb6U6XmFMuLwhKRdh5aZU4DkfVOWLudKGHFIic/NUmu1JKa5XOLGo2V frmIbQnzIgaK+TLDylWwFwtA9V1AsEMWQuHxVt1LJ3MZzMcJy3Gi1GVHIieg/QhH nGE3eNYKylvmSkvlnPAdS/pQgO9du9JkxdhdSlZKwII5FuMEucinA23sarTAvKJ3 SPYTKYpyTkTu+0L9a98aR6CnSjmuV7so9gYnxDTVV1tiWONoXWpnBlioLNgu2Bo= =3ZmE -----END PGP SIGNATURE----- ------enig2MVDUAHWIKNSFOUDCWMAO-- From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 2 10:55:35 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E816F1BF; Sat, 2 Feb 2013 10:55:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C2586A25; Sat, 2 Feb 2013 10:55:34 +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 MAA28996; Sat, 02 Feb 2013 12:55:27 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U1ako-00046L-QH; Sat, 02 Feb 2013 12:55:26 +0200 Message-ID: <510CF09C.7020109@FreeBSD.org> Date: Sat, 02 Feb 2013 12:55:24 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Baldwin Subject: Re: some questions on kern_linker and pre-loaded modules References: <5103C361.6060605@FreeBSD.org> <201301281040.38727.jhb@freebsd.org> In-Reply-To: <201301281040.38727.jhb@freebsd.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 10:55:36 -0000 on 28/01/2013 17:40 John Baldwin said the following: > Yes, I think it is too hard at present to safely allow a linker file to > override the same module in a kernel, so the duplicate linker file should > just be rejected entirely. I'm not sure if your change is completely > correct for that. Incidentally that particular patch was broken. Here is a working patch: http://people.freebsd.org/~avg/linker_file_register_modules-linker_kernel_file.diff But I really need to get a better understanding of the bigger picture and then discuss what has to be done in that scope. I plan to write a larger response to your complete followup. Thank you. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 2 11:50:44 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BD501402; Sat, 2 Feb 2013 11:50:44 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A771ECC0; Sat, 2 Feb 2013 11:50:43 +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 NAA29528; Sat, 02 Feb 2013 13:50:42 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U1bcH-0004Bz-PW; Sat, 02 Feb 2013 13:50:41 +0200 Message-ID: <510CFD90.9000304@FreeBSD.org> Date: Sat, 02 Feb 2013 13:50:40 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Subject: scheduler->swapper, SI_SUB_RUN_SCHEDULER->SI_SUB_LAST X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 11:50:44 -0000 I would like to propose the following mostly cosmetic change: http://people.freebsd.org/~avg/scheduler-swapper.diff This is something that bit me early in my FreeBSD days, so I am kind of obsessed with it. The current naming is confusing/misleading indeed. And magic properties of SI_SUB_RUN_SCHEDULER:SI_ORDER_LAST is a "hidden gem". -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 2 14:50:18 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8D7A2A97; Sat, 2 Feb 2013 14:50:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id DB51A6A5; Sat, 2 Feb 2013 14:50:17 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r12EoDIg077606; Sat, 2 Feb 2013 16:50:13 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r12EoDIg077606 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r12EoDq1077604; Sat, 2 Feb 2013 16:50:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 2 Feb 2013 16:50:13 +0200 From: Konstantin Belousov To: Andriy Gapon Subject: Re: scheduler->swapper, SI_SUB_RUN_SCHEDULER->SI_SUB_LAST Message-ID: <20130202145013.GV2522@kib.kiev.ua> References: <510CFD90.9000304@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0ujaWV404FI0kHa9" Content-Disposition: inline In-Reply-To: <510CFD90.9000304@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 14:50:18 -0000 --0ujaWV404FI0kHa9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 02, 2013 at 01:50:40PM +0200, Andriy Gapon wrote: >=20 > I would like to propose the following mostly cosmetic change: > http://people.freebsd.org/~avg/scheduler-swapper.diff >=20 > This is something that bit me early in my FreeBSD days, so I am kind of o= bsessed > with it. > The current naming is confusing/misleading indeed. > And magic properties of SI_SUB_RUN_SCHEDULER:SI_ORDER_LAST is a "hidden g= em". You may remove the Giant unlock from the scheduler()/swapper() as well then, doing it before the swapper() call in the mi_startup(). Note that the wait chain for the idle swapper is still called "sched". --0ujaWV404FI0kHa9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRDSelAAoJEJDCuSvBvK1B6usP/i4nVfbHVB++Sk8BUy5+zrIM B+dAEnb64hEnELVjcQfAYO7+UDkgMMo63eVmgq8kYtiVBJ7bF6+QxbjNObubXM7B 0MbLpcHgnwtwuqMF4swVofJzR7pqbqo7lq3E5R9Bd57kZJfhzNS7CPhycX4HQiV0 WZZB1SLz+eoc+jfyFgOSfR+Eq9hrrPS2lH2k76FwScU1x0IpiTnkaYkfcs0QYqgW z0AqRmQjAEl9V8HyM4b2qTa+6k0K+HiXaQMNzpn+GZhlpjmmVe7pQy2fy/5NBAzU rK0dxu2J0FH1PEJgLwJIIlMYl0MI3KjeX1O4QmCkQLros0o6+ZwQ7t0irRsydGsX dJI7T57i3+BZvo61Uq3snFRbkiIBKhUtnwTBWF9z+qSJW10Ma+UcASltN0/6YFhP trdcVqbN4jsOLpYTAGBLgxzf4LjqzVHeNPX3wmL42LfFXmwPm7mYbbKsucbfxFCQ WJvbJCvo/PMzwHCK+aC0UueZ1yI8nx95oGp+HWQGc6AgD9PmmzWMZng9gAdUK5kO +v1S4t7aQymjASwUtNpHZnjC+keQy/Zk/L7GT0mveD0hm7+jtlAKqzBkqTS/7dfJ yba9uoxT3gZpYkEA7GmSerERJfDvXAF1azYUdzhk9Kcu8lX8OTvsov0xjUrXIL5J 9oH+HRNGtfKWsdN2QH1y =qdWH -----END PGP SIGNATURE----- --0ujaWV404FI0kHa9-- From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 2 18:44:25 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 82B29F42 for ; Sat, 2 Feb 2013 18:44:25 +0000 (UTC) (envelope-from loic.blot@unix-experience.fr) Received: from smtp.unix-experience.fr (unix-experience.fr [88.190.14.11]) by mx1.freebsd.org (Postfix) with ESMTP id 369FEFC1 for ; Sat, 2 Feb 2013 18:44:24 +0000 (UTC) Received: from mail.unix-experience.fr (unknown [192.168.200.1]) by smtp.unix-experience.fr (Postfix) with ESMTP id 168D239D26 for ; Sat, 2 Feb 2013 19:37:27 +0100 (CET) MIME-Version: 1.0 Date: Sat, 02 Feb 2013 18:53:03 +0100 From: "loic.blot" To: Subject: backport RSU from OpenBSD Message-ID: <162ca6500d1189fb3fa93204e9170ce1@unix-experience.fr> X-Sender: loic.blot@unix-experience.fr User-Agent: Roundcube Webmail/0.8.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 18:44:25 -0000 Hello people, I notice you i am trying to import RSU driver from OpenBSD. a diff will be available later. Loïc BLOT