From owner-freebsd-current@freebsd.org Sun Oct 9 00:00:12 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE949C06A8F for ; Sun, 9 Oct 2016 00:00:12 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 313C6977 for ; Sun, 9 Oct 2016 00:00:11 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: (qmail 25103 invoked by uid 89); 8 Oct 2016 23:53:28 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@185.17.205.219) by mail.grem.de with ESMTPA; 8 Oct 2016 23:53:28 -0000 Date: Sun, 9 Oct 2016 01:53:24 +0200 From: Michael Gmelin To: Warner Losh Cc: Andriy Gapon , Matthias Apitz , FreeBSD Current Subject: Re: [request for testing] isl, cyapa on chromebooks Message-ID: <20161009015324.007a7b42@bsd64.grem.de> In-Reply-To: References: <20161005004831.2a2fdc4b@bsd64.grem.de> <1bcfd282-63fd-f8ee-4dad-393b51f14bcd@FreeBSD.org> <302FDA6E-DEC7-49F0-8F2C-8C26C8A884AF@freebsd.org> <53bca4d2-975f-f4a0-d12a-5d73fba01a0c@FreeBSD.org> <20161006044732.GA2393@c720-r292778-amd64.oa.oclc.org> <734c7ac0-9018-051e-1df4-a3b719057e19@FreeBSD.org> <773efe54-8ebb-e0e7-7824-10cfaa96d850@FreeBSD.org> <1EE0A2F3-86B9-4806-875E-3845A209A743@freebsd.org> <20161008180742.GA1912@c720-r292778-amd64> <846bf31f-a757-2be0-a293-8c4ce3d42a2f@FreeBSD.org> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd10.2) X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 00:00:12 -0000 On Sat, 8 Oct 2016 15:54:27 -0600 Warner Losh wrote: > Speaking of Chromebooks, what's the best way to put FreeBSD onto one? > > Warner > > Depends on the Chromebook in question, when porting the drivers for the c720, I wrote a blog post about it (quite a while ago): https://blog.grem.de/pages/c720.html Would I maybe make sense to have man pages for specific laptops (instead of the "FreeBSD Laptop" page, blogs on the internet and Wiki pages). Just thinking that after this change, people will need to know the correct addresses for device.hints to make isl and cyapa work, and putting things like that (and other hints, e.g. to route the Intel HDA correctly) into a man page ("apropos c720") would be the next best thing to having it work out of the box. -m -- Michael Gmelin From owner-freebsd-current@freebsd.org Sun Oct 9 06:36:39 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A9EC1C079D9 for ; Sun, 9 Oct 2016 06:36:39 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 580EE145; Sun, 9 Oct 2016 06:36:38 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [88.217.126.241] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1bt7it-0005IM-TV; Sun, 09 Oct 2016 08:36:36 +0200 Received: from localhost.my.domain (c720-r292778-amd64 [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id u996aZK8001876 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 9 Oct 2016 08:36:35 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id u996aZAs001875; Sun, 9 Oct 2016 08:36:35 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sun, 9 Oct 2016 08:36:35 +0200 From: Matthias Apitz To: Andriy Gapon Cc: Michael Gmelin , FreeBSD Current Subject: Re: [request for testing] isl, cyapa on chromebooks Message-ID: <20161009063635.GA1825@c720-r292778-amd64> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , Andriy Gapon , Michael Gmelin , FreeBSD Current References: <1bcfd282-63fd-f8ee-4dad-393b51f14bcd@FreeBSD.org> <302FDA6E-DEC7-49F0-8F2C-8C26C8A884AF@freebsd.org> <53bca4d2-975f-f4a0-d12a-5d73fba01a0c@FreeBSD.org> <20161006044732.GA2393@c720-r292778-amd64.oa.oclc.org> <734c7ac0-9018-051e-1df4-a3b719057e19@FreeBSD.org> <773efe54-8ebb-e0e7-7824-10cfaa96d850@FreeBSD.org> <1EE0A2F3-86B9-4806-875E-3845A209A743@freebsd.org> <20161008180742.GA1912@c720-r292778-amd64> <846bf31f-a757-2be0-a293-8c4ce3d42a2f@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <846bf31f-a757-2be0-a293-8c4ce3d42a2f@FreeBSD.org> X-Operating-System: FreeBSD 11.0-CURRENT r292778 (amd64) User-Agent: Mutt/1.5.24 (2015-08-30) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 88.217.126.241 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 06:36:39 -0000 El día Saturday, October 08, 2016 a las 10:17:07PM +0300, Andriy Gapon escribió: > On 08/10/2016 21:07, Matthias Apitz wrote: > > I have now produced a memstick with (unpatched) r306769 of October 6. It boots > > fine in my Acer C720 Chromebook and the moused is working fine with the > > cyapa(4) driver. I will apply tomorrow the above v4 patch or is there > > anything newer? And will test/report. > > v4 is the latest. Thanks! The patch applies cleanly, the 'make buildkernel' does fine and system boots, but cyapa(4) can not bring the device out of bootstrap. The verbose dmesg is here http://www.unixarea.de/dmesg-00.txt And yes, I have in /boot/device.hints: ... # The change moves the drivers from the SMBus to the I2C bus and as such some # configuration changes are required. # Namely, you will now need iicbus driver either in the kernel configuration or as # a module. For now the smbus driver is also required. # You also need to add some entries to /boot/device.hints: # hint.isl.0.at="iicbus0" hint.isl.0.addr=0x88 hint.isl.1.at="iicbus1" hint.isl.1.addr=0x88 hint.cyapa.0.at="iicbus0" hint.cyapa.0.addr=0xce hint.cyapa.1.at="iicbus1" hint.cyapa.1.addr=0xce # # The hints are required because auto-probing (either via the bus enumeration or # self-identification) is disabled for now for safety reason. # Also, as I understand, the Intel chipset used in the supported Chromebooks # provides to i2c buses (possibly in addition in an smbus) and I am not sure on # which of the i2c buses the devices reside. Please let me know what to check/debug. matthias -- Matthias Apitz, ✉ guru@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 Einheitsfeier? Nein, danke! Kann ich bitte mein Land wiederhaben und am 7. Oktober feiern. From owner-freebsd-current@freebsd.org Sun Oct 9 06:50:36 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98318C07C1A for ; Sun, 9 Oct 2016 06:50:36 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 925B180C; Sun, 9 Oct 2016 06:50:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA15583; Sun, 09 Oct 2016 09:50:33 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1bt7wO-000Dhx-RG; Sun, 09 Oct 2016 09:50:32 +0300 Subject: Re: [request for testing] isl, cyapa on chromebooks To: Matthias Apitz , Michael Gmelin , FreeBSD Current References: <1bcfd282-63fd-f8ee-4dad-393b51f14bcd@FreeBSD.org> <302FDA6E-DEC7-49F0-8F2C-8C26C8A884AF@freebsd.org> <53bca4d2-975f-f4a0-d12a-5d73fba01a0c@FreeBSD.org> <20161006044732.GA2393@c720-r292778-amd64.oa.oclc.org> <734c7ac0-9018-051e-1df4-a3b719057e19@FreeBSD.org> <773efe54-8ebb-e0e7-7824-10cfaa96d850@FreeBSD.org> <1EE0A2F3-86B9-4806-875E-3845A209A743@freebsd.org> <20161008180742.GA1912@c720-r292778-amd64> <846bf31f-a757-2be0-a293-8c4ce3d42a2f@FreeBSD.org> <20161009063635.GA1825@c720-r292778-amd64> From: Andriy Gapon Message-ID: Date: Sun, 9 Oct 2016 09:49:36 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161009063635.GA1825@c720-r292778-amd64> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 06:50:36 -0000 On 09/10/2016 09:36, Matthias Apitz wrote: > El día Saturday, October 08, 2016 a las 10:17:07PM +0300, Andriy Gapon escribió: > >> On 08/10/2016 21:07, Matthias Apitz wrote: >>> I have now produced a memstick with (unpatched) r306769 of October 6. It boots >>> fine in my Acer C720 Chromebook and the moused is working fine with the >>> cyapa(4) driver. I will apply tomorrow the above v4 patch or is there >>> anything newer? And will test/report. >> >> v4 is the latest. Thanks! > > The patch applies cleanly, the 'make buildkernel' does fine and system > boots, but cyapa(4) can not bring the device out of bootstrap. The verbose dmesg > is here http://www.unixarea.de/dmesg-00.txt > > And yes, I have in /boot/device.hints: Well, comparing the hints and the boot message, you have exactly the problem that I feared many people would have until we add auto-probing to isl and cyapa. Basically it's easy to connect the dots once you know what they are. You hint that isl and cyapa should be on iicbus0 or iicbus1. But iicbus0 is connected to iicbb0 which is intel_iicbb0 on drmn0, which is a video card. That is clearly wrong. And a similar thing with iicbus1: on intel_gmbus0. But later you have: iicbus14: on ig4iic0 iicbus15: on ig4iic1 So, in your case, and with that probing order (hopefully it not changes from boot to boot), you should use those two buses to look for isl and cyapa. Examining output of devinfo -v -r should be even easier than going through dmesg. Hope this helps. > ... > # The change moves the drivers from the SMBus to the I2C bus and as such some > # configuration changes are required. > # Namely, you will now need iicbus driver either in the kernel configuration or as > # a module. For now the smbus driver is also required. > # You also need to add some entries to /boot/device.hints: > # > hint.isl.0.at="iicbus0" > hint.isl.0.addr=0x88 > hint.isl.1.at="iicbus1" > hint.isl.1.addr=0x88 > hint.cyapa.0.at="iicbus0" > hint.cyapa.0.addr=0xce > hint.cyapa.1.at="iicbus1" > hint.cyapa.1.addr=0xce > # > # The hints are required because auto-probing (either via the bus enumeration or > # self-identification) is disabled for now for safety reason. > # Also, as I understand, the Intel chipset used in the supported Chromebooks > # provides to i2c buses (possibly in addition in an smbus) and I am not sure on > # which of the i2c buses the devices reside. > > Please let me know what to check/debug. > > matthias > -- Andriy Gapon From owner-freebsd-current@freebsd.org Sun Oct 9 06:54:26 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C996AC07D88 for ; Sun, 9 Oct 2016 06:54:26 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 88A2CB73; Sun, 9 Oct 2016 06:54:26 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [88.217.126.241] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1bt808-0002OY-93; Sun, 09 Oct 2016 08:54:24 +0200 Received: from localhost.my.domain (c720-r292778-amd64 [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id u996sNOZ002063 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 9 Oct 2016 08:54:23 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id u996sNGn002062; Sun, 9 Oct 2016 08:54:23 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sun, 9 Oct 2016 08:54:23 +0200 From: Matthias Apitz To: Michael Gmelin Cc: Warner Losh , Andriy Gapon , FreeBSD Current Subject: Re: [request for testing] isl, cyapa on chromebooks Message-ID: <20161009065423.GA2012@c720-r292778-amd64> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , Michael Gmelin , Warner Losh , Andriy Gapon , FreeBSD Current References: <53bca4d2-975f-f4a0-d12a-5d73fba01a0c@FreeBSD.org> <20161006044732.GA2393@c720-r292778-amd64.oa.oclc.org> <734c7ac0-9018-051e-1df4-a3b719057e19@FreeBSD.org> <773efe54-8ebb-e0e7-7824-10cfaa96d850@FreeBSD.org> <1EE0A2F3-86B9-4806-875E-3845A209A743@freebsd.org> <20161008180742.GA1912@c720-r292778-amd64> <846bf31f-a757-2be0-a293-8c4ce3d42a2f@FreeBSD.org> <20161009015324.007a7b42@bsd64.grem.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20161009015324.007a7b42@bsd64.grem.de> X-Operating-System: FreeBSD 11.0-CURRENT r292778 (amd64) User-Agent: Mutt/1.5.24 (2015-08-30) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 88.217.126.241 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 06:54:26 -0000 El día Sunday, October 09, 2016 a las 01:53:24AM +0200, Michael Gmelin escribió: > Would I maybe make sense to have man pages for specific laptops (instead > of the "FreeBSD Laptop" page, blogs on the internet and Wiki pages). > > Just thinking that after this change, people will need to know the > correct addresses for device.hints to make isl and cyapa work, and > putting things like that (and other hints, e.g. to route the Intel HDA > correctly) into a man page ("apropos c720") would be the next best > thing to having it work out of the box. Good idea. The problem with such an approach is, that new laptops get only inserted into man pages when some maintainer/approver does so and seldom if someone brings a new device to working (more or less) with FreeBSD. In the past (some 15 years ago) there was a database and a web frotnend where people (everyone) could insert/update a new working device. It was here: http://laptop.bsdgroup.de/freebsd/ but the site is offline for many year. I even tried and contacted the provide of 'bsdgroup.de' to get a copy of the database, w/o any luck. matthias -- Matthias Apitz, ✉ guru@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 Einheitsfeier? Nein, danke! Kann ich bitte mein Land wiederhaben und am 7. Oktober feiern. From owner-freebsd-current@freebsd.org Sun Oct 9 07:39:15 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61089C05638 for ; Sun, 9 Oct 2016 07:39:15 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 27930C0C for ; Sun, 9 Oct 2016 07:39:14 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [2.247.246.180] (helo=[10.246.230.180]) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1bt8hU-0001zj-4o for freebsd-current@freebsd.org; Sun, 09 Oct 2016 09:39:12 +0200 From: Matthias Apitz To: Subject: Re: [request for testing] isl, cyapa on chromebooks Date: Sun, 09 Oct 2016 09:39:01 +0200 User-Agent: Dekko/0.6.20; Qt/5.4.1; ubuntumirclient; Linux; MIME-Version: 1.0 Message-ID: <73f919f5-6952-44f8-9d66-12744b5b841d@unixarea.de> In-Reply-To: <181117b0-69ab-4a83-b428-295d5d1c998d@unixarea.de> References: <20161005004831.2a2fdc4b@bsd64.grem.de> <1bcfd282-63fd-f8ee-4dad-393b51f14bcd@FreeBSD.org> <302FDA6E-DEC7-49F0-8F2C-8C26C8A884AF@freebsd.org> <53bca4d2-975f-f4a0-d12a-5d73fba01a0c@FreeBSD.org> <20161006044732.GA2393@c720-r292778-amd64.oa.oclc.org> <734c7ac0-9018-051e-1df4-a3b719057e19@FreeBSD.org> <773efe54-8ebb-e0e7-7824-10cfaa96d850@FreeBSD.org> <1EE0A2F3-86B9-4806-875E-3845A209A743@freebsd.org> <20161008180742.GA1912@c720-r292778-amd64> <846bf31f-a757-2be0-a293-8c4ce3d42a2f@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 2.247.246.180 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 07:39:15 -0000 Thanks. Changing device.hints to iicbus14 iicbus15 makes cyapa(4) attaching and moused working fine. I will later install xorg=20= into this memstick. matthias --=20 Sent from my Ubuntu phone http://www.unixarea.de/ From owner-freebsd-current@freebsd.org Sun Oct 9 10:38:47 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49001C078C5 for ; Sun, 9 Oct 2016 10:38:47 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 88817E87 for ; Sun, 9 Oct 2016 10:38:46 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA15845 for ; Sun, 09 Oct 2016 13:38:44 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1btBVE-000Drn-Fm for freebsd-current@FreeBSD.org; Sun, 09 Oct 2016 13:38:44 +0300 To: FreeBSD Current From: Andriy Gapon Subject: vtterm_cngrab is broken on kms-enabled systems when entering kdb Message-ID: Date: Sun, 9 Oct 2016 13:37:48 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 10:38:47 -0000 JFYI, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213334 -- Andriy Gapon From owner-freebsd-current@freebsd.org Sun Oct 9 20:22:27 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1843C0B89F for ; Sun, 9 Oct 2016 20:22:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AEDF1C9D for ; Sun, 9 Oct 2016 20:22:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x234.google.com with SMTP id z65so53467856itc.0 for ; Sun, 09 Oct 2016 13:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-transfer-encoding; bh=qsRPrlTsaVszUl9VeqUoAftNDiSu5rdazUwU8tka2Gw=; b=MkH+bJd3UtNZteJ9oDwRF+quUHNfqoCyRXXHyooSv/OgIuh8U75T2av/UWRYcyUfKG DIp4jXumcsaeLuM49MT6iyi8Xe/J5tqsAARAuYwmjUOZx+70ykWlg9dl5V33jMiKKiCd D5+/B38PoYb4/byrOJMDZpgUkviDwH1UNR+7LhFudlmE+w5h/ymEG+GwD2UbvHJy+H7/ gR0//RJz9la0KwKdjA2EyoSxDmAaBPFkSClCxkPj18Bed2Oyhi55LeFdZP1iE36Q9Hlk NMGN5YD0BXumYXHiWljNvDnIvwcqnFRwl229OaWp9GpfcpUJkBJ33fU/5fwpjN0cdvKe 5RtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-transfer-encoding; bh=qsRPrlTsaVszUl9VeqUoAftNDiSu5rdazUwU8tka2Gw=; b=jFn61HunXekgrWgFFTeJUYMj7sB6HWPqWBpadzYzJNEx0n6GhL93aNVzQ1u8FtWkA2 iEciv8dmgLOVVag9u14jQuFlsTvCg/vfT+g4XDIerlV4eAW90+wTfkr5ZQzvhfGqbMne u9cAIf+Tx3WGhZAHpXU50eyUoa7ZEe24AW5IYLdCgdRnDwK1Qj7LalHt0yaUlttx2djq 2zIdri+OlW5OlhSun9B4o74Xc165KqiZw1DIo3kDhh2xVeayOkVZW8Kcg+eWyrbN+NOv BZQ2KxlbiRQfhua/JTQEeFpZ8P/gotkEeAaJeN3YJ7pqHaGh2zcHeYr0F/r9527BodDh aXBw== X-Gm-Message-State: AA6/9Rm5tHJsqVinLJA8qv/U818l8i5l521qKnKZO5WzAKjryBrjOQtgTtnO+TI9W2z4swOqFneuXf1qpBS0wg== X-Received: by 10.36.89.206 with SMTP id p197mr6788582itb.103.1476044546912; Sun, 09 Oct 2016 13:22:26 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.77.85 with HTTP; Sun, 9 Oct 2016 13:22:26 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <20161009065423.GA2012@c720-r292778-amd64> References: <53bca4d2-975f-f4a0-d12a-5d73fba01a0c@FreeBSD.org> <20161006044732.GA2393@c720-r292778-amd64.oa.oclc.org> <734c7ac0-9018-051e-1df4-a3b719057e19@FreeBSD.org> <773efe54-8ebb-e0e7-7824-10cfaa96d850@FreeBSD.org> <1EE0A2F3-86B9-4806-875E-3845A209A743@freebsd.org> <20161008180742.GA1912@c720-r292778-amd64> <846bf31f-a757-2be0-a293-8c4ce3d42a2f@FreeBSD.org> <20161009015324.007a7b42@bsd64.grem.de> <20161009065423.GA2012@c720-r292778-amd64> From: Warner Losh Date: Sun, 9 Oct 2016 14:22:26 -0600 X-Google-Sender-Auth: 4YL97h7T7u-58MM2ig4uYYyo-XE Message-ID: Subject: Re: [request for testing] isl, cyapa on chromebooks To: Matthias Apitz , Michael Gmelin , Warner Losh , Andriy Gapon , FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 20:22:28 -0000 On Sun, Oct 9, 2016 at 12:54 AM, Matthias Apitz wrote: > El d=C3=ADa Sunday, October 09, 2016 a las 01:53:24AM +0200, Michael Gmel= in escribi=C3=B3: > >> Would I maybe make sense to have man pages for specific laptops (instead >> of the "FreeBSD Laptop" page, blogs on the internet and Wiki pages). >> >> Just thinking that after this change, people will need to know the >> correct addresses for device.hints to make isl and cyapa work, and >> putting things like that (and other hints, e.g. to route the Intel HDA >> correctly) into a man page ("apropos c720") would be the next best >> thing to having it work out of the box. > > Good idea. The problem with such an approach is, that new laptops get > only inserted into man pages when some maintainer/approver does so and > seldom if someone brings a new device to working (more or less) with > FreeBSD. > > In the past (some 15 years ago) there was a database and a web frotnend > where people (everyone) could insert/update a new working device. It was > here: http://laptop.bsdgroup.de/freebsd/ but the site is offline for > many year. I even tried and contacted the provide of 'bsdgroup.de' to > get a copy of the database, w/o any luck. There seems to be enough information present in the smbios data to know what devices are at what addresses. Perhaps we should use it as much as possible in well controlled situations to move this knowledge into the OS. Now, where did I put the power supply to my chromebook... Warner From owner-freebsd-current@freebsd.org Mon Oct 10 11:36:21 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B7E6C0B821 for ; Mon, 10 Oct 2016 11:36:21 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7A995BFD; Mon, 10 Oct 2016 11:36:20 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA19275; Mon, 10 Oct 2016 14:36:18 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1btYsT-000F8w-SJ; Mon, 10 Oct 2016 14:36:17 +0300 Subject: Re: [request for testing] isl, cyapa on chromebooks To: Warner Losh , Matthias Apitz , Michael Gmelin , FreeBSD Current References: <53bca4d2-975f-f4a0-d12a-5d73fba01a0c@FreeBSD.org> <20161006044732.GA2393@c720-r292778-amd64.oa.oclc.org> <734c7ac0-9018-051e-1df4-a3b719057e19@FreeBSD.org> <773efe54-8ebb-e0e7-7824-10cfaa96d850@FreeBSD.org> <1EE0A2F3-86B9-4806-875E-3845A209A743@freebsd.org> <20161008180742.GA1912@c720-r292778-amd64> <846bf31f-a757-2be0-a293-8c4ce3d42a2f@FreeBSD.org> <20161009015324.007a7b42@bsd64.grem.de> <20161009065423.GA2012@c720-r292778-amd64> From: Andriy Gapon Message-ID: <23c6b4f0-77e9-fe90-0eed-9d0125e7624b@FreeBSD.org> Date: Mon, 10 Oct 2016 14:35:22 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 11:36:21 -0000 On 09/10/2016 23:22, Warner Losh wrote: > There seems to be enough information present in the smbios data to > know what devices are at what addresses. Perhaps we should use it as > much as possible in well controlled situations to move this knowledge > into the OS. So, I was thinking about maybe doing something like this to preserve the status quo, to avoid requiring manual hints and to lay a foundation for the proper Chromebook I2C slave discovery: static struct { uint32_t ctlrid, const char *name; uint_t addr; } slaves[] = { { 0x9c628086, "isl", 0x88 }, { 0x9c628086, "cyapa", 0xce }, } static void chromebook_i2c_identify(driver_t *driver, device_t bus) { device_t controller; device_t child; int i; /* * A stop gap approach to preserve the status quo. * A more intelligent approach is required to correctly * identify a machine model and hadrdware available on it. * For instance, DMI could be used. * See http://lxr.free-electrons.com/source/drivers/platform/chrome/chromeos_laptop.c */ controller = device_get_parent(bus); if (strcmp(device_get_name(controller), "ig4iic") != 0) return; for (i = 0; i < nitems(slaves); i++) { if (device_find_child(bus, slave->name, -1) != NULL) continue; if (slave->ctlrid != pci_get_devid(controller)) continue; child = BUS_ADD_CHILD(bus, 0, slave->name, -1); if (child != NULL) iicbus_set_addr(child, slave->addr); } } static device_method_t chromebook_i2c_methods[] = { DEVMETHOD(device_identify, chromebook_i2c_identify), { 0, 0 } }; static driver_t chromebook_i2c_driver = { "chromebook_i2c", chromebook_i2c_methods, 0 /* no softc */ }; static devclass_t chromebook_i2c_devclass; DRIVER_MODULE(chromebook_i2c, iicbus, chromebook_i2c_driver, chromebook_i2c_devclass, 0, 0); MODULE_DEPEND(chromebook_i2c, iicbus, IICBUS_MINVER, IICBUS_PREFVER, IICBUS_MAXVER); MODULE_VERSION(chromebook_i2c, 1); The idea is that this is a driver that listens for new iicbus-es and adds isl and cyapa devices to a bus if some criteria are met. -- Andriy Gapon From owner-freebsd-current@freebsd.org Mon Oct 10 11:46:20 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B91BC0BE2B for ; Mon, 10 Oct 2016 11:46:20 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id C4889E4B for ; Mon, 10 Oct 2016 11:46:19 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: (qmail 49054 invoked by uid 89); 10 Oct 2016 11:46:12 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@194.97.158.70) by mail.grem.de with ESMTPA; 10 Oct 2016 11:46:12 -0000 Date: Mon, 10 Oct 2016 13:46:10 +0200 From: Michael Gmelin To: Andriy Gapon Cc: Warner Losh , Matthias Apitz , FreeBSD Current Subject: Re: [request for testing] isl, cyapa on chromebooks Message-ID: <20161010134610.32120b55@bsd64.grem.de> In-Reply-To: <23c6b4f0-77e9-fe90-0eed-9d0125e7624b@FreeBSD.org> References: <53bca4d2-975f-f4a0-d12a-5d73fba01a0c@FreeBSD.org> <20161006044732.GA2393@c720-r292778-amd64.oa.oclc.org> <734c7ac0-9018-051e-1df4-a3b719057e19@FreeBSD.org> <773efe54-8ebb-e0e7-7824-10cfaa96d850@FreeBSD.org> <1EE0A2F3-86B9-4806-875E-3845A209A743@freebsd.org> <20161008180742.GA1912@c720-r292778-amd64> <846bf31f-a757-2be0-a293-8c4ce3d42a2f@FreeBSD.org> <20161009015324.007a7b42@bsd64.grem.de> <20161009065423.GA2012@c720-r292778-amd64> <23c6b4f0-77e9-fe90-0eed-9d0125e7624b@FreeBSD.org> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd10.2) X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 11:46:20 -0000 On Mon, 10 Oct 2016 14:35:22 +0300 Andriy Gapon wrote: > On 09/10/2016 23:22, Warner Losh wrote: > > There seems to be enough information present in the smbios data to > > know what devices are at what addresses. Perhaps we should use it as > > much as possible in well controlled situations to move this > > knowledge into the OS. > > So, I was thinking about maybe doing something like this to preserve > the status quo, to avoid requiring manual hints and to lay a > foundation for the proper Chromebook I2C slave discovery: > > > static struct { > uint32_t ctlrid, > const char *name; > uint_t addr; > } slaves[] = { > { 0x9c628086, "isl", 0x88 }, > { 0x9c628086, "cyapa", 0xce }, > } > > static void > chromebook_i2c_identify(driver_t *driver, device_t bus) > { > device_t controller; > device_t child; > int i; > > /* > * A stop gap approach to preserve the status quo. > * A more intelligent approach is required to correctly > * identify a machine model and hadrdware available on it. > * For instance, DMI could be used. > * See > http://lxr.free-electrons.com/source/drivers/platform/chrome/chromeos_laptop.c > */ > controller = device_get_parent(bus); > if (strcmp(device_get_name(controller), "ig4iic") != 0) > return; > > for (i = 0; i < nitems(slaves); i++) { > if (device_find_child(bus, slave->name, -1) != NULL) > continue; > if (slave->ctlrid != pci_get_devid(controller)) > continue; > child = BUS_ADD_CHILD(bus, 0, slave->name, -1); > if (child != NULL) > iicbus_set_addr(child, slave->addr); > } > } > > static device_method_t chromebook_i2c_methods[] = { > DEVMETHOD(device_identify, chromebook_i2c_identify), > { 0, 0 } > }; > > static driver_t chromebook_i2c_driver = { > "chromebook_i2c", > chromebook_i2c_methods, > 0 /* no softc */ > }; > > static devclass_t chromebook_i2c_devclass; > > DRIVER_MODULE(chromebook_i2c, iicbus, chromebook_i2c_driver, > chromebook_i2c_devclass, 0, 0); > MODULE_DEPEND(chromebook_i2c, iicbus, IICBUS_MINVER, IICBUS_PREFVER, > IICBUS_MAXVER); > MODULE_VERSION(chromebook_i2c, 1); > > The idea is that this is a driver that listens for new iicbus-es and > adds isl and cyapa devices to a bus if some criteria are met. > For the Acer c720, these criteria would be: smbios.bios.vendor=="coreboot" smbios.system.maker=="Acer" smbios.system.product=="Peppy" See also boot/i386/libi386/biosmem.c dev/atkbdc/atkbdc.c - Michael -- Michael Gmelin From owner-freebsd-current@freebsd.org Mon Oct 10 15:26:28 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AFEEFC07A73 for ; Mon, 10 Oct 2016 15:26:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 738001AE for ; Mon, 10 Oct 2016 15:26:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x242.google.com with SMTP id o19so5977861ito.3 for ; Mon, 10 Oct 2016 08:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DGbO/0vv9/6uf2Q7zD2ITMIotpzF/JHK4l+UoDkI5UE=; b=I21tN8yTh/GQUOR4tJdpVUJXnkU81n55GPbAgWKRs10st7fKLqjClXaq2eaAw9uBE7 2mnDsLtCIQMC1p/l/osN9YRM4rlsxnDyKilNuXTH1Iqk5Y5d6w9ttUk+MdZeoN9Lq5F2 gaF9uH3TOrw6vs4s4fvl0XRgSYN9RwSFCbrZ0KEDiY6vTKKgxtqQqh6z8vhGZAB75Cn9 lc5bCsB93M3ymTlyMU1JOwWTw2mzIE5wVmEIRedTksrQicSkz4pkILfglN9wZHshgbO3 d0inEEMBlV8EMUyjCZr/ISrHCNo/2NeiRmAsqExA8rasCj/befZ4l3ObcHfcP5ADselN uXcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DGbO/0vv9/6uf2Q7zD2ITMIotpzF/JHK4l+UoDkI5UE=; b=GRc8uOtXrRS9WY92ERLyhl5JrrniclIZ3Bo3gaEVco/QZpxv3b1rMg9glQ6tKv2cqh UgJfM9BIxCCRJzUWsE7kSRxAptq0uWLS7fgytcY4WrZFs43CX2JhESymjY6PF4eFUJiF Vudpt0RniKEgVPi4OdTwcxuv41XokJJy1/ik/0kJB3k/yyYs/VTUtYzQrQs47jrLUTpy gnjKCd8VvLiUIF8PmYnF2KM/9gBenmIdZZirggvGzCYEmpFnIol8i5jaQgo+rml6Gnyf phU//yrV7cQVauwTJUhzn3ULbNMIdDLwIMIP1WVTamAQ9UTVAO2h54yXOxBuq+4brJle 5inA== X-Gm-Message-State: AA6/9Rl7ojz1O8yYRFNczOX/DNInk0dHWU3YlCXi7k9KaQdR0t7qDZMCdvgE7xfXz9B6WM52DUS/uw7TaPLeRg== X-Received: by 10.36.16.138 with SMTP id 132mr12363399ity.60.1476113187739; Mon, 10 Oct 2016 08:26:27 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.77.85 with HTTP; Mon, 10 Oct 2016 08:26:26 -0700 (PDT) X-Originating-IP: [50.205.115.50] In-Reply-To: <20161010134610.32120b55@bsd64.grem.de> References: <53bca4d2-975f-f4a0-d12a-5d73fba01a0c@FreeBSD.org> <20161006044732.GA2393@c720-r292778-amd64.oa.oclc.org> <734c7ac0-9018-051e-1df4-a3b719057e19@FreeBSD.org> <773efe54-8ebb-e0e7-7824-10cfaa96d850@FreeBSD.org> <1EE0A2F3-86B9-4806-875E-3845A209A743@freebsd.org> <20161008180742.GA1912@c720-r292778-amd64> <846bf31f-a757-2be0-a293-8c4ce3d42a2f@FreeBSD.org> <20161009015324.007a7b42@bsd64.grem.de> <20161009065423.GA2012@c720-r292778-amd64> <23c6b4f0-77e9-fe90-0eed-9d0125e7624b@FreeBSD.org> <20161010134610.32120b55@bsd64.grem.de> From: Warner Losh Date: Mon, 10 Oct 2016 09:26:26 -0600 X-Google-Sender-Auth: MnTuMUqRxAZsJw-6g40rOZRkYEM Message-ID: Subject: Re: [request for testing] isl, cyapa on chromebooks To: Michael Gmelin Cc: Andriy Gapon , Matthias Apitz , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 15:26:28 -0000 I see no reason not to start the table right away based on smbios.sys.product and other criteria. I don't think we need all the matches that Linux uses, but we can expand the table if we find it so. Why have a stop gap that's a table that we kludge together when the real table is of comparable difficulty and wouldn't need to be reworked. Warner On Mon, Oct 10, 2016 at 5:46 AM, Michael Gmelin wrote: > On Mon, 10 Oct 2016 14:35:22 +0300 > Andriy Gapon wrote: > >> On 09/10/2016 23:22, Warner Losh wrote: >> > There seems to be enough information present in the smbios data to >> > know what devices are at what addresses. Perhaps we should use it as >> > much as possible in well controlled situations to move this >> > knowledge into the OS. >> >> So, I was thinking about maybe doing something like this to preserve >> the status quo, to avoid requiring manual hints and to lay a >> foundation for the proper Chromebook I2C slave discovery: >> >> >> static struct { >> uint32_t ctlrid, >> const char *name; >> uint_t addr; >> } slaves[] = { >> { 0x9c628086, "isl", 0x88 }, >> { 0x9c628086, "cyapa", 0xce }, >> } >> >> static void >> chromebook_i2c_identify(driver_t *driver, device_t bus) >> { >> device_t controller; >> device_t child; >> int i; >> >> /* >> * A stop gap approach to preserve the status quo. >> * A more intelligent approach is required to correctly >> * identify a machine model and hadrdware available on it. >> * For instance, DMI could be used. >> * See >> http://lxr.free-electrons.com/source/drivers/platform/chrome/chromeos_laptop.c >> */ >> controller = device_get_parent(bus); >> if (strcmp(device_get_name(controller), "ig4iic") != 0) >> return; >> >> for (i = 0; i < nitems(slaves); i++) { >> if (device_find_child(bus, slave->name, -1) != NULL) >> continue; >> if (slave->ctlrid != pci_get_devid(controller)) >> continue; >> child = BUS_ADD_CHILD(bus, 0, slave->name, -1); >> if (child != NULL) >> iicbus_set_addr(child, slave->addr); >> } >> } >> >> static device_method_t chromebook_i2c_methods[] = { >> DEVMETHOD(device_identify, chromebook_i2c_identify), >> { 0, 0 } >> }; >> >> static driver_t chromebook_i2c_driver = { >> "chromebook_i2c", >> chromebook_i2c_methods, >> 0 /* no softc */ >> }; >> >> static devclass_t chromebook_i2c_devclass; >> >> DRIVER_MODULE(chromebook_i2c, iicbus, chromebook_i2c_driver, >> chromebook_i2c_devclass, 0, 0); >> MODULE_DEPEND(chromebook_i2c, iicbus, IICBUS_MINVER, IICBUS_PREFVER, >> IICBUS_MAXVER); >> MODULE_VERSION(chromebook_i2c, 1); >> >> The idea is that this is a driver that listens for new iicbus-es and >> adds isl and cyapa devices to a bus if some criteria are met. >> > > For the Acer c720, these criteria would be: > > smbios.bios.vendor=="coreboot" > smbios.system.maker=="Acer" > smbios.system.product=="Peppy" > > See also > > boot/i386/libi386/biosmem.c > dev/atkbdc/atkbdc.c > > - Michael > > -- > Michael Gmelin From owner-freebsd-current@freebsd.org Mon Oct 10 16:31:24 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2DD2C0B4B7 for ; Mon, 10 Oct 2016 16:31:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B90DDD1E; Mon, 10 Oct 2016 16:31:23 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA20429; Mon, 10 Oct 2016 19:31:21 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1btdU1-000FS4-47; Mon, 10 Oct 2016 19:31:21 +0300 Subject: Re: [request for testing] isl, cyapa on chromebooks To: Warner Losh , Michael Gmelin References: <53bca4d2-975f-f4a0-d12a-5d73fba01a0c@FreeBSD.org> <20161006044732.GA2393@c720-r292778-amd64.oa.oclc.org> <734c7ac0-9018-051e-1df4-a3b719057e19@FreeBSD.org> <773efe54-8ebb-e0e7-7824-10cfaa96d850@FreeBSD.org> <1EE0A2F3-86B9-4806-875E-3845A209A743@freebsd.org> <20161008180742.GA1912@c720-r292778-amd64> <846bf31f-a757-2be0-a293-8c4ce3d42a2f@FreeBSD.org> <20161009015324.007a7b42@bsd64.grem.de> <20161009065423.GA2012@c720-r292778-amd64> <23c6b4f0-77e9-fe90-0eed-9d0125e7624b@FreeBSD.org> <20161010134610.32120b55@bsd64.grem.de> Cc: Matthias Apitz , FreeBSD Current From: Andriy Gapon Message-ID: <50c65364-49f3-30b2-8c42-763daec96b55@FreeBSD.org> Date: Mon, 10 Oct 2016 19:30:24 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 16:31:24 -0000 On 10/10/2016 18:26, Warner Losh wrote: > I see no reason not to start the table right away based on > smbios.sys.product and other criteria. I don't think we need all the > matches that Linux uses, but we can expand the table if we find it so. > Why have a stop gap that's a table that we kludge together when the > real table is of comparable difficulty and wouldn't need to be > reworked. One simple reason for me personally. I do not have the hardware and I am not particularly interested in it. I am interested only in cleaning up the smbus interface and moving ig4iic to iicbus. I want to get done with that as quickly as possible and my goal is just that the result is not worse than the current code. I am sure that people who are more interested than me can make the code much better. > On Mon, Oct 10, 2016 at 5:46 AM, Michael Gmelin wrote: >> On Mon, 10 Oct 2016 14:35:22 +0300 >> Andriy Gapon wrote: >> >>> On 09/10/2016 23:22, Warner Losh wrote: >>>> There seems to be enough information present in the smbios data to >>>> know what devices are at what addresses. Perhaps we should use it as >>>> much as possible in well controlled situations to move this >>>> knowledge into the OS. >>> >>> So, I was thinking about maybe doing something like this to preserve >>> the status quo, to avoid requiring manual hints and to lay a >>> foundation for the proper Chromebook I2C slave discovery: >>> [snip] -- Andriy Gapon From owner-freebsd-current@freebsd.org Mon Oct 10 18:27:19 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0EAFC0C8D1 for ; Mon, 10 Oct 2016 18:27:19 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF10299E; Mon, 10 Oct 2016 18:27:19 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [82.113.106.192] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1btfIC-0007aT-Hu; Mon, 10 Oct 2016 20:27:16 +0200 Received: from localhost.my.domain (c720-r292778-amd64 [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id u9AIRDua002002 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 10 Oct 2016 20:27:13 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id u9AIRBh9002001; Mon, 10 Oct 2016 20:27:11 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Mon, 10 Oct 2016 20:27:10 +0200 From: Matthias Apitz To: Warner Losh , Michael Gmelin , Andriy Gapon , FreeBSD Current Subject: Re: [request for testing] isl, cyapa on chromebooks Message-ID: <20161010182710.GA1956@c720-r292778-amd64> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , Warner Losh , Michael Gmelin , Andriy Gapon , FreeBSD Current References: <20161008180742.GA1912@c720-r292778-amd64> <846bf31f-a757-2be0-a293-8c4ce3d42a2f@FreeBSD.org> <20161009015324.007a7b42@bsd64.grem.de> <20161009065423.GA2012@c720-r292778-amd64> <23c6b4f0-77e9-fe90-0eed-9d0125e7624b@FreeBSD.org> <20161010134610.32120b55@bsd64.grem.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT r292778 (amd64) User-Agent: Mutt/1.5.24 (2015-08-30) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 82.113.106.192 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 18:27:20 -0000 El día Monday, October 10, 2016 a las 09:26:26AM -0600, Warner Losh escribió: > I see no reason not to start the table right away based on > smbios.sys.product and other criteria. I don't think we need all the > matches that Linux uses, but we can expand the table if we find it so. > Why have a stop gap that's a table that we kludge together when the > real table is of comparable difficulty and wouldn't need to be > reworked. Please let us together concentrate on getting other i2c devices working, like the Elan TouchPad, because I fear that newer Chromebooks are all equipped with this and not with the Cyapa anymore. matthias -- Matthias Apitz, ✉ guru@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 Einheitsfeier? Nein, danke! Kann ich bitte mein Land wiederhaben und am 7. Oktober feiern. From owner-freebsd-current@freebsd.org Mon Oct 10 18:52:21 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8945C0CECE for ; Mon, 10 Oct 2016 18:52:21 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 5600D1A43 for ; Mon, 10 Oct 2016 18:52:20 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: (qmail 53467 invoked by uid 89); 10 Oct 2016 18:45:37 -0000 Received: from unknown (HELO ?192.168.250.192?) (mg@grem.de@185.17.205.219) by mail.grem.de with ESMTPA; 10 Oct 2016 18:45:37 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: [request for testing] isl, cyapa on chromebooks From: Michael Gmelin X-Mailer: iPhone Mail (13G36) In-Reply-To: <20161010182710.GA1956@c720-r292778-amd64> Date: Mon, 10 Oct 2016 20:45:35 +0200 Cc: Warner Losh , Andriy Gapon , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <63DC842D-48EC-4A5F-938F-AF8CE1E37BF8@freebsd.org> References: <20161008180742.GA1912@c720-r292778-amd64> <846bf31f-a757-2be0-a293-8c4ce3d42a2f@FreeBSD.org> <20161009015324.007a7b42@bsd64.grem.de> <20161009065423.GA2012@c720-r292778-amd64> <23c6b4f0-77e9-fe90-0eed-9d0125e7624b@FreeBSD.org> <20161010134610.32120b55@bsd64.grem.de> <20161010182710.GA1956@c720-r292778-amd64> To: Matthias Apitz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 18:52:22 -0000 > On 10 Oct 2016, at 20:27, Matthias Apitz wrote: >=20 >> El d=C3=ADa Monday, October 10, 2016 a las 09:26:26AM -0600, Warner Losh e= scribi=C3=B3: >>=20 >> I see no reason not to start the table right away based on >> smbios.sys.product and other criteria. I don't think we need all the >> matches that Linux uses, but we can expand the table if we find it so. >> Why have a stop gap that's a table that we kludge together when the >> real table is of comparable difficulty and wouldn't need to be >> reworked. >=20 > Please let us together concentrate on getting other i2c devices working, > like the Elan TouchPad, because I fear that newer Chromebooks are all > equipped with this and not with the Cyapa anymore. >=20 I see three tasks here: - Andriy finishes his change, moving things from smbus to iicbus, adding s= ome workaround to keep the user experience like it is - Someone else implements the device table mechanism for auto detection - Someone else ports HDI over I2C to allow implementing drivers for device= s like the elan touchpad Matthias is referring to Makes sense? -m From owner-freebsd-current@freebsd.org Mon Oct 10 20:02:39 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67452C0C2DF for ; Mon, 10 Oct 2016 20:02:39 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7D124380; Mon, 10 Oct 2016 20:02:37 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA21457; Mon, 10 Oct 2016 23:02:36 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1btgmS-000FfU-1l; Mon, 10 Oct 2016 23:02:36 +0300 Subject: Re: [request for testing] isl, cyapa on chromebooks To: Michael Gmelin , Matthias Apitz References: <20161008180742.GA1912@c720-r292778-amd64> <846bf31f-a757-2be0-a293-8c4ce3d42a2f@FreeBSD.org> <20161009015324.007a7b42@bsd64.grem.de> <20161009065423.GA2012@c720-r292778-amd64> <23c6b4f0-77e9-fe90-0eed-9d0125e7624b@FreeBSD.org> <20161010134610.32120b55@bsd64.grem.de> <20161010182710.GA1956@c720-r292778-amd64> <63DC842D-48EC-4A5F-938F-AF8CE1E37BF8@freebsd.org> Cc: Warner Losh , FreeBSD Current From: Andriy Gapon Message-ID: Date: Mon, 10 Oct 2016 23:01:59 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <63DC842D-48EC-4A5F-938F-AF8CE1E37BF8@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 20:02:39 -0000 On 10/10/2016 21:45, Michael Gmelin wrote: > I see three tasks here: - Andriy finishes his change, moving things from > smbus to iicbus, adding some workaround to keep the user experience like it > is - Someone else implements the device table mechanism for auto detection - > Someone else ports HDI over I2C to allow implementing drivers for devices > like the elan touchpad Matthias is referring to > > Makes sense? It does to me. Also, I can suggest another task related to SMBus / I2C. Looking at the code in the Linux chromeos_laptop driver I see that on some models some sensors are actually attached to SMBus rather that to I2C. And, for example, cyapa can be attached to either bus. But there is a quirk. cyapa won't work over a standard SMBus, it needs some extensions that are typically provided by Intel chipsets. I specifically mean the so called "I2C Block Read" and the transaction that results from the Block Write command when the I2C bit is set in the SMBus controller's configuration register. Neither of these modes is supported by our ichsmb(4) driver. But on Linux they are both supported and exposed as I2C_SMBUS_I2C_BLOCK_DATA transaction type. For one reference please see Mobile 4th Generation Intel® CoreTM Processor Family I/O Datasheet, section 5.21.1.1. And, just in case, ig4(4) is about the controllers described in section 5.22 of that document. Perhaps, I2C_SMBUS_I2C_BLOCK_DATA served as an inspiration (and perhaps a source of confusion) for Matt when he added smbus_trans(). Right now I do not have any good suggestion on how to expose that 90% SMBus, 10% I2C functionality in the FreeBSD model. -- Andriy Gapon From owner-freebsd-current@freebsd.org Tue Oct 11 01:28:13 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 636CBC0B54B; Tue, 11 Oct 2016 01:28:13 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns.kevlo.org", Issuer "ns.kevlo.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 074BD6E5; Tue, 11 Oct 2016 01:28:12 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (localhost [127.0.0.1]) by ns.kevlo.org (8.15.2/8.15.2) with ESMTPS id u9B1R3NO036722 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 11 Oct 2016 09:27:04 +0800 (CST) (envelope-from kevlo@ns.kevlo.org) Received: (from kevlo@localhost) by ns.kevlo.org (8.15.2/8.15.2/Submit) id u9B1R3qM036721; Tue, 11 Oct 2016 09:27:03 +0800 (CST) (envelope-from kevlo) Date: Tue, 11 Oct 2016 09:27:02 +0800 From: Kevin Lo To: Andriy Voskoboinyk Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" , Adrian Chadd Subject: Re: urtwn(4) / rtwn(4) drivers are merged - call for review / testing Message-ID: <20161011012702.GA36712@ns.kevlo.org> References: <20160922092442.GA72044@ns.kevlo.org> <20160923015840.GA77979@ns.kevlo.org> <20160923071830.GA79146@ns.kevlo.org> <20161001150924.GA48641@ns.kevlo.org> <20161003005523.GA57437@ns.kevlo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 01:28:13 -0000 On Sat, Oct 08, 2016 at 02:18:54AM +0300, Andriy Voskoboinyk wrote: > > Mon, 03 Oct 2016 03:55:23 +0300 було написано Kevin Lo : > > Hi! Hi Andriy, > Can you refresh the tree and retest it (dev.rtwn.0.debug=0x829f) ? I refreshed the tree and retested it, unfortunately it's still the same. Here's the log: https://people.freebsd.org/~kevlo/rtl8188ce-debuglog > > P.S. If Rx is still broken (status is always 0) try to execute > 'ifconfig wlan0 promisc' It doesn't help either :( > > On Sun, Oct 02, 2016 at 10:15:49AM -0700, Adrian Chadd wrote: > >> > >> hi, > > > > Hi Adrian, > > > >> can you turn on debugging? Do you see RX frames? > > > > No Rx frames. The log is pretty much the same one I sent on the list: > > https://lists.freebsd.org/pipermail/freebsd-wireless/2016-September/007093.html > > > >> -a > > > > Thanks, > > Kevin > > > >> On 1 October 2016 at 08:09, Kevin Lo wrote: > >> > Strange, rtwn(4) stops working. I tried to scan for the available > >> network, > >> > but it just returns empty results. > >> > > >> > On Fri, Sep 23, 2016 at 02:44:13PM +0300, Andriy Voskoboinyk wrote: > >> >> > >> >> Fri, 23 Sep 2016 10:18:30 +0300 було написано Kevin Lo > >> : > >> >> > >> >> Few more questions: > >> >> 1) does it work with h/w encryption support? (enabled by default) > >> >> (if 'yes' - I will remove 'hardware crypto enabled' warning). > >> >> 2) is there rate control support? (wlandebug -i wlan0 rate ; then > >> transmit > >> >> something - if it works then AMRR will print it's current status > >> >> periodically) > >> >> 3) can you test some disabled capabilities? (ad-hoc/AP modes, 11n) > >> >> (see r92ce_adj_devcaps() in > >> sys/dev/rtwn/rtl8192c/pci/r92ce_attach.c). > >> >> > >> >> > It works for me, thanks :) > >> >> > > >> >> > Kevin > >> >> > > >> >> > On Fri, Sep 23, 2016 at 09:08:15AM +0300, Andriy Voskoboinyk wrote: > >> >> >> > >> >> >> Fri, 23 Sep 2016 04:58:40 +0300 було написано Kevin Lo > >> >> >> : > >> >> >> > >> >> >> Thanks for the log file, > >> >> >> > >> >> >> Tx 'device timeouts' should be fixed in > >> >> >> > >> https://github.com/s3erios/rtwn/commit/f78d51b6ed8590e3aeb65fbf616aa767034a89f5 > >> >> >> (currently I'm reviewing PCI-specific code to see if there are any > >> >> >> additional > >> >> >> issues - e.g., there are no Rx events in the log file). > >> >> >> > >> >> >> > On Thu, Sep 22, 2016 at 01:54:21PM +0300, Andriy Voskoboinyk > >> wrote: > >> >> >> >> > >> >> >> >> Thu, 22 Sep 2016 12:24:42 +0300 було написано Kevin Lo > >> >> >> >> : > >> >> >> >> > >> >> >> >> Hi, > >> >> >> >> > >> >> >> >> So, the driver was fully tested. Thanks! > >> >> >> >> Can you set dev.rtwn.0.debug=0x829f for RTL8188CE to see how > >> big > >> >> >> >> the problem is? > >> >> >> > > >> >> >> > Sure. Here you go > >> >> >> https://people.freebsd.org/~kevlo/rtl8188ce-debug.txt > >> >> >> > > >> >> >> > Thanks, > >> >> >> > Kevin > >> >> >> > > >> >> >> >> > Hi Andriy, > >> >> >> >> > > >> >> >> >> > First of all, THANK YOU! You're doing amazing work! > >> >> >> >> > Second, I've done some testing on the following devices, > >> >> >> downloading > >> >> >> >> > FreeBSD-12.0-CURRENT-amd64-20160809-r303880-disc1.iso from > >> >> >> >> > ftp.freebsd.org: > >> >> >> >> > > >> >> >> >> > - ASUS USB-N10 NANO (RTL8188CUS): > >> >> >> >> > rtwn0: >> 2.00/2.00, > >> >> >> addr > >> >> >> >> > 3> on usbus0 > >> >> >> >> > rtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R > >> >> >> >> > > >> >> >> >> > - TP-Link TL-WN725N v2 (RTL8188EU): > >> >> >> >> > rtwn0: >> addr 4> on > >> >> >> >> > usbus0 > >> >> >> >> > rtwn0: MAC/BB RTL8188EU, RF 6052 1T1R > >> >> >> >> > > >> >> >> >> > - D-Link DWA-131 (RTL8192CU): > >> >> >> >> > rtwn0: >> 2.00/2.00, > >> >> >> addr > >> >> >> >> > 3> on usbus0 > >> >> >> >> > rtwn0: MAC/BB RTL8192CU, RF 6052 2T2R > >> >> >> >> > > >> >> >> >> > - TP-Link Archer T4U (RTL8812AU): > >> >> >> >> > rtwn0: >> addr 7> on > >> >> >> >> > usbus0 > >> >> >> >> > rtwn0: MAC/BB RTL8812AU, RF 6052 2T2R > >> >> >> >> > > >> >> >> >> > - D-Link DWA-171 rev A1 (RTL8821AU): > >> >> >> >> > rtwn0: <802.11n WLAN Adapter> on usbus0 > >> >> >> >> > rtwn0: MAC/BB RTL8821AU, RF 6052 1T1R > >> >> >> >> > > >> >> >> >> > - RTL8188CE mini pcie: > >> >> >> >> > rtwn0: port 0xd000-0xd0ff mem > >> >> >> >> > 0x90800000-0x90803fff irq 17 at device 0.0 on pci1 > >> >> >> >> > rtwn0: r92ce_attach: warning: hardware crypto enabled > >> >> >> >> > rtwn0: MAC/BB RTL8188CE, RF 6052 1T1R > >> >> >> >> > > >> >> >> >> > All seems to be ok, except RTL8188CE PCIe adapter doesn't > >> work: > >> >> >> >> > > >> >> >> >> > rtwn0: r92ce_post_init: warning: net80211 ratectl is used > >> >> >> >> > rtwn0: device timeout > >> >> >> >> > > >> >> >> >> > Kevin > >> >> >> >> > > >> >> >> >> > On Mon, Sep 19, 2016 at 04:26:38PM +0300, Andriy Voskoboinyk > >> wrote: > >> >> >> >> >> > >> >> >> >> >> Thu, 01 Sep 2016 19:29:03 +0300 було написано Andriy > >> Voskoboinyk > >> >> >> >> >> : > >> >> >> >> >> > >> >> >> >> >> Now it resides on https://github.com/s3erios/freebsd-rtwn > >> >> >> (integrated > >> >> >> >> >> into src tree, so it can be built with 'make buildkernel' / > >> 'make > >> >> >> >> >> buildworld'). > >> >> >> >> >> > >> >> >> >> >> This the last stage; once all reported issues will be > >> resolved, > >> >> >> I'm > >> >> >> >> >> going to merge it into HEAD. > >> >> >> >> >> > >> >> >> >> >> > Hi everyone, > >> >> >> >> >> > > >> >> >> >> >> > rtwn(4), urtwn(4) and urtwm (from previous emails) > >> drivers were > >> >> >> >> merged > >> >> >> >> >> > into a > >> >> >> >> >> > single rtwn driver (plus rtwn_usb / rtwn_pci device > >> glue); the > >> >> >> >> code is > >> >> >> >> >> > available on https://github.com/s3erios/rtwn repository. > >> Among > >> >> >> >> >> bugfixes / > >> >> >> >> >> > code deduplication, there some new features too: > >> >> >> >> >> > > >> >> >> >> >> > 1) multi-vap support (one any wireless interface + one STA > >> >> >> >> interface + > >> >> >> >> >> > any number of monitor mode interfaces). > >> >> >> >> >> > 2) few new sysctls: > >> >> >> >> >> > * dev.rtwn.#.crypto - controls how to use hardware > >> crypto > >> >> >> >> >> acceleration > >> >> >> >> >> > * dev.rtwn.#.ratectl_selected > >> >> >> >> >> > * dev.rtwn.#.ratectl - selects current 'rate control' > >> >> >> algorithm > >> >> >> >> >> > (currently only 'none' and 'net80211' are supported; > >> RTL8192CE > >> >> >> >> needs > >> >> >> >> >> > testing > >> >> >> >> >> > with the last). > >> >> >> >> >> > 3) (incomplete) power management support for RTL8188EU > >> (requires > >> >> >> >> >> > firmware). > >> >> >> >> >> > 4) Short Guard Interval support. > >> >> >> >> >> > > >> >> >> >> >> > It's known to work with RTL8188CUS, RTL8188EU and > >> RTL8821AU; > >> >> >> >> however, > >> >> >> >> >> > it was never tested with RTL8192CE or RTL8812AU. > >> >> >> >> >> > > >> >> >> >> >> > How-to-build: > >> >> >> >> >> > 1) download / checkout the repository. > >> >> >> >> >> > 2) apply 'patch-usbdevs.diff' against '/usr/src' > >> >> >> >> >> > 3) build and install rtwn module: > >> >> >> >> >> > cd $repository/sys/modules/rtwn && make && make > >> install > >> >> >> >> >> > 4) build and install rtwn_usb/rtwn_pci: > >> >> >> >> >> > cd ../rtwn_usb && make && make install > >> >> >> >> >> > cd ../rtwn_pci && make && make install > >> >> >> >> >> > 5) unload previous && load current drivers: > >> >> >> >> >> > kldunload if_urtwn if_rtwn > >> >> >> >> >> > kldload /boot/modules/if_rtwn.ko > >> >> >> /boot/modules/if_rtwn_usb.ko > >> >> >> >> >> > /boot/modules/if_rtwn_pci.ko > >> >> >> >> >> > 6) Use. > >> >> >> >> >> _______________________________________________ > >> >> >> >> >> freebsd-wireless@freebsd.org mailing list > >> >> >> >> >> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > >> >> >> >> >> To unsubscribe, send any mail to > >> >> >> >> >> "freebsd-wireless-unsubscribe@freebsd.org" > >> >> >> >> >> > >> >> >> >> > >> >> >> _______________________________________________ > >> >> >> freebsd-current@freebsd.org mailing list > >> >> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> >> >> To unsubscribe, send any mail to > >> >> >> "freebsd-current-unsubscribe@freebsd.org" > >> >> >> > >> >> >> > >> >> > _______________________________________________ > >> >> > freebsd-wireless@freebsd.org mailing list > >> >> > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > >> >> > To unsubscribe, send any mail to > >> >> > "freebsd-wireless-unsubscribe@freebsd.org" > >> >> > >> >> > >> > _______________________________________________ > >> > freebsd-current@freebsd.org mailing list > >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> > To unsubscribe, send any mail to > >> "freebsd-current-unsubscribe@freebsd.org" > >> > >> > > _______________________________________________ > > freebsd-wireless@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > > To unsubscribe, send any mail to > > "freebsd-wireless-unsubscribe@freebsd.org" > > From owner-freebsd-current@freebsd.org Tue Oct 11 03:49:09 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A99F0C072C7 for ; Tue, 11 Oct 2016 03:49:09 +0000 (UTC) (envelope-from sm@ara-ler.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7B6EB3CD for ; Tue, 11 Oct 2016 03:49:09 +0000 (UTC) (envelope-from sm@ara-ler.com) Received: by mail-it0-x22a.google.com with SMTP id l13so91755072itl.1 for ; Mon, 10 Oct 2016 20:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ara-ler-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=JJq8NgQaKshiov+xtPokMnqDHxSfjwqvDXrGaWngtss=; b=oVObXJhsWDoqMNg8225GgV3OjmvkqSSoqEez5OHeMyn6TMSxA20fLMwKnbA037/a1K M54REI9POP17nIZWKJBIom+wjISjvK4yp+0V8A+/3wD/AA/ptrlRn1WUa3lt9bW9VHd0 AwG4W6MB+di00jKA7GiWyP5ulL6yfBC+XVD+1ANvBfMynhY7THQd6OTF5lDmccWqSCZa LZP55G7+dwWkiAYtNcryhywgyyi9Rv0UljgFUvD+GlngvmBZAZmxbczJI/WAdgdPOzO8 5Yz9l8Yxvj7asP3PV83fp/nZfWdFPA01ryB4MYa0RK2/5qR8iKoB9Z+5spYctFOqsw0O pLbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=JJq8NgQaKshiov+xtPokMnqDHxSfjwqvDXrGaWngtss=; b=ZdX8kg6Do/qWHKP6dJmviPnnsEt+Nsyiym881PwZ55ZOpfXtNhQEFBevJ2/KzSC1aP ce5fZfI7JGLHu1w1ICOl4uz96u2tJJVe386Y1CqyyCVfKNBFmo1VWM3tRYSt1piMqGp2 Wope6pLNFR60myyPODnrH2ooZr/Pl3sZS/+ik16IeVcP4wmbiVIFCxI8ubLgLM2RAzaX JW4JabJ14g6N4gumOTQWRGdzODKXQCK31GY4cYfIJHYJfrBShIE1saRLz2KhPoX8xdDE Yl8jR1iMFuamBxUYYuoOOneMuW6m/whyCK5CWKV0lNOlfrMV/VMKclTruqY5dhzpyeuU 6WEg== X-Gm-Message-State: AA6/9RnX6cVH1C9xkrgkZNMcPhqHg04l+AWO+99awb1kJ1+/dnSxyajBsNEzsUFkls9hiQ== X-Received: by 10.36.29.212 with SMTP id 203mr3142619itj.64.1476157748693; Mon, 10 Oct 2016 20:49:08 -0700 (PDT) Received: from dendrobates.Home (97-122-166-145.hlrn.qwest.net. [97.122.166.145]) by smtp.gmail.com with ESMTPSA id u6sm8012243itb.3.2016.10.10.20.49.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Oct 2016 20:49:07 -0700 (PDT) Date: Mon, 10 Oct 2016 21:49:05 -0600 From: Sergey Manucharian To: FreeBSD Current Subject: [SOLVED] LibreOffice and CUPS Message-ID: <20161011034905.GC42953@dendrobates.Home> References: <20160514182728.GA1388@dendrobates.araler.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160514182728.GA1388@dendrobates.araler.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 03:49:09 -0000 Excerpts from Sergey Manucharian's message from Sat 14-May-16 12:27: > After recent system update (I'm on FreeBSD 11.0-CURRENT r298793) > LibreOffice doesn't see CUPS printers. It shows only "Generic printer", > but doesn't actually print anything. > I've found and posted the solution: https://forums.freebsd.org/threads/57815 Sergey. From owner-freebsd-current@freebsd.org Tue Oct 11 15:44:30 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76110C0DD6C for ; Tue, 11 Oct 2016 15:44:30 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 392DA1B24 for ; Tue, 11 Oct 2016 15:44:29 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1btzE4-000tNs-IH>; Tue, 11 Oct 2016 17:44:20 +0200 Received: from x5ce12a35.dyn.telefonica.de ([92.225.42.53] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1btzE4-0018et-9d>; Tue, 11 Oct 2016 17:44:20 +0200 Date: Tue, 11 Oct 2016 17:44:19 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: make delete-old: sticky remants: mqtest3, Message-ID: <20161011174419.2bc252a8.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/CWOR=nbx=jW7VOknP7P8Do6"; protocol="application/pgp-signature" X-Originating-IP: 92.225.42.53 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 15:44:30 -0000 --Sig_/CWOR=nbx=jW7VOknP7P8Do6 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable The following files are sticky on my CURRENT (FreeBSD 12.0-CURRENT #5 r3070= 03: Mon Oct 10 21:28:55 CEST 2016), sources as of revision 307042. Performing "make delete= -old" in /usr/src seem to kill them in one round after make installworld, but the= next make installworld seem to install them again. I build sources with "filemon.ko" loaded and WITH_META_MODE=3DYES set in /e= tc/src-env.conf. Is this a bug? >>> Removing old files (only deletes safe to delete libs) remove /usr/tests/sys/mqueue/mqtest3?=20 remove /usr/tests/sys/mqueue/mqtest4? --Sig_/CWOR=nbx=jW7VOknP7P8Do6 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJX/QjTAAoJEOgBcD7A/5N85ZEH/0Y3Lub5uxnrnqXocT50YNP6 T09cV1ZDyn1r//hq+fA+/rK38apgkLUpSw/zBQn066PHvvw5nRNowR/gESQp2nKl pdQj6T8/5VNt/TlzMpuINTTFGIEuRr32vppeb0u5C0vMSYvnbny1KrHtriv/KPpb XZXcm+o7ZKAULugnb3fk2iEnlswsGYgnWxS7Natyv5wTmp1bEtJJk+MlZsEg5fz+ 9+SBwaZQZxnSV1pP4ELlfMIyWZlpOIJC8KECBH4r10AGSyoca6tLyiTqYiOR8usc h9u9aVp2740cY4PV7PzPhX1tE+rcjNyLPxvUQ0pKDH6iYwvUT2T8NeR1dfc+6JY= =RCgG -----END PGP SIGNATURE----- --Sig_/CWOR=nbx=jW7VOknP7P8Do6-- From owner-freebsd-current@freebsd.org Tue Oct 11 15:56:00 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1500FC0D06C for ; Tue, 11 Oct 2016 15:56:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9D791258 for ; Tue, 11 Oct 2016 15:55:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u9BFtshu039220 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 11 Oct 2016 18:55:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u9BFtshu039220 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u9BFtsmY039219; Tue, 11 Oct 2016 18:55:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 11 Oct 2016 18:55:54 +0300 From: Konstantin Belousov To: "O. Hartmann" Cc: FreeBSD CURRENT Subject: Re: make delete-old: sticky remants: mqtest3, Message-ID: <20161011155554.GS68202@kib.kiev.ua> References: <20161011174419.2bc252a8.ohartman@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161011174419.2bc252a8.ohartman@zedat.fu-berlin.de> User-Agent: Mutt/1.7.0 (2016-08-17) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 15:56:00 -0000 On Tue, Oct 11, 2016 at 05:44:19PM +0200, O. Hartmann wrote: > The following files are sticky on my CURRENT (FreeBSD 12.0-CURRENT #5 r307003: Mon Oct 10 > 21:28:55 CEST 2016), sources as of revision 307042. Performing "make delete-old" > in /usr/src seem to kill them in one round after make installworld, but the next make > installworld seem to install them again. > > I build sources with "filemon.ko" loaded and WITH_META_MODE=YES set in /etc/src-env.conf. > > Is this a bug? > > >>> Removing old files (only deletes safe to delete libs) > remove /usr/tests/sys/mqueue/mqtest3? > remove /usr/tests/sys/mqueue/mqtest4? Should be fixed by r307043. Thank you for the report. From owner-freebsd-current@freebsd.org Tue Oct 11 20:21:40 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B737EC0DA4E; Tue, 11 Oct 2016 20:21:40 +0000 (UTC) (envelope-from andriyvos@gmail.com) Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 453D9AB1; Tue, 11 Oct 2016 20:21:39 +0000 (UTC) (envelope-from andriyvos@gmail.com) Received: by mail-lf0-f44.google.com with SMTP id b75so55558578lfg.3; Tue, 11 Oct 2016 13:21:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:cc:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=MPG1u7jiQC6tzI11BpZKI3eYKzu3WwlZheT/DYrPDoQ=; b=itIAV9tFmcxpQCyVfmG487jUXbs0OjwOS5Xe9mMfudwLsqhos4lK2fJLmB2AVJu4aA YedzBGNjunqK9rRgn5s27jpsXMastd0TMuFMjf0PLK0uFCodwNwanWQhLpnuRP7OemlZ WZ+zoZ7uP/X7+ToljDt4zHwiwSNAZXDnlD6ITiyttECS752vCOs2mEn4uRtUS1GvNxJA GEsn6YTaDIyQByRtTWOLoMTJjafZxYM9o41Yqyn3t+jO/xK7+QzVhsUTxSkTIZN/VHHh D9EoYx+l8f3SNwv/mDcHMNNmoBAiNirp6G4L5oZzMhLJa0qQEeISlVn3dejTJXRBLVJN hjYw== X-Gm-Message-State: AA6/9RmtPJ5+dCxqlaCP2ZJ85qDbwtxR8AITcnOtZ2BNGN9Hon3R7Xiply4GgcHjo4HCDg== X-Received: by 10.25.212.212 with SMTP id l203mr4524197lfg.2.1476217291751; Tue, 11 Oct 2016 13:21:31 -0700 (PDT) Received: from localhost (host-176-37-109-22.la.net.ua. [176.37.109.22]) by smtp.gmail.com with ESMTPSA id 102sm1467442lft.33.2016.10.11.13.21.30 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 11 Oct 2016 13:21:30 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Kevin Lo" Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" , "Adrian Chadd" Subject: Re: urtwn(4) / rtwn(4) drivers are merged - call for review / testing References: <20160922092442.GA72044@ns.kevlo.org> <20160923015840.GA77979@ns.kevlo.org> <20160923071830.GA79146@ns.kevlo.org> <20161001150924.GA48641@ns.kevlo.org> <20161003005523.GA57437@ns.kevlo.org> <20161011012702.GA36712@ns.kevlo.org> Date: Tue, 11 Oct 2016 23:21:24 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Andriy Voskoboinyk" Message-ID: In-Reply-To: <20161011012702.GA36712@ns.kevlo.org> User-Agent: Opera Mail/12.16 (FreeBSD) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 20:21:40 -0000 Tue, 11 Oct 2016 04:27:02 +0300 =D0=B1=D1=83=D0=BB=D0=BE =D0=BD=D0=B0=D0= =BF=D0=B8=D1=81=D0=B0=D0=BD=D0=BE Kevin Lo : I have created 'pci_modified' branch to speed-up the process (RTL881*AU = = will not work with it for now); right now it contains (mostly) unmodified initialization path from rtwn(4) driver. If this version will work, I will revert some 'RTWN_PCI_WORKAROUND' temporary blocks until the culprit is found. > On Sat, Oct 08, 2016 at 02:18:54AM +0300, Andriy Voskoboinyk wrote: >> >> Mon, 03 Oct 2016 03:55:23 +0300 =D0=B1=D1=83=D0=BB=D0=BE =D0=BD=D0=B0= =D0=BF=D0=B8=D1=81=D0=B0=D0=BD=D0=BE Kevin Lo = >> : >> >> Hi! > > Hi Andriy, > >> Can you refresh the tree and retest it (dev.rtwn.0.debug=3D0x829f) ? > > I refreshed the tree and retested it, unfortunately it's still the sam= e. > Here's the log: https://people.freebsd.org/~kevlo/rtl8188ce-debuglog >> >> P.S. If Rx is still broken (status is always 0) try to execute >> 'ifconfig wlan0 promisc' > > It doesn't help either :( From owner-freebsd-current@freebsd.org Wed Oct 12 02:08:09 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF91AC0D303; Wed, 12 Oct 2016 02:08:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B5BC810FA; Wed, 12 Oct 2016 02:08:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-it0-x231.google.com with SMTP id e203so70803418itc.0; Tue, 11 Oct 2016 19:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4O2RMNlKO4erAK/bE8A+KfvkLy7U6jDibA1qsj5kQn4=; b=r+Ewp5UCMZq5gQ1W6wTEPp/3GYQn5TgBZ/NW3ciOEWKK/gPcDC12NxdQxj0c4/Gx74 QCvO58jJyElbMZCrG+8nyT3ZV/W3fF+O0DIUhbk9IxKzwEHI3dJKL2ddrcHEN6k6xWtv 9p8U8LNBwpkniM+ckT8ii7zMzKjJuORn66V3/RtVIxdQZ9CSdNiWKIoYs9z+6EjmXwLi ZNlPbguqu5Qm/Axw9GlaKHpyjOHmiEt9SkFeyZokjKr+dhnrFZRwQSjosp3GU9Cuypbc lbYlkIjuKG4oCLXe/INcM3VQfklx4WuBz4+IlAPDMbcb/5eqFQGsRNsf0jxlP9lJb2yv 8y7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4O2RMNlKO4erAK/bE8A+KfvkLy7U6jDibA1qsj5kQn4=; b=ZTNCq/Hh5ZRVuNBI9d0u+/OuOfMInQjvWe5P9j/i9fSWEsckqCN5yLISF92YRT9/WF epZqRfhJMw6H6vngLZ80zqYk1YGyj3t4eSn2vhcG1eJnnhQZ71KQX1UaEV5aztf1mm/x DxQkFm/1kKbtUpoFdRU8lrnkd8ez6UiE/HmhtwgYluILc9btRA4X07dGL3DqiAzevrZ2 LY0Czx02zA/PhJsh1/n+XwlHWLWuvPYynKHZGAZ5vDWcDuqvdCyaUyA3hunXZ9VEESCu GHQiaZIBWMQATKiSosAas2DpZ8+zEewAQhMrAharOIxebg9jEJzGAzjAd16MdXS9WuFI Dgzw== X-Gm-Message-State: AA6/9RnDdHf8yufkgGOnxHuS3+ePEDc4dgcmW8XNAIMvcHx4iEGo7u6QwPdcUHvcmbTTgkq6uDHlp8IeVofFvA== X-Received: by 10.36.52.141 with SMTP id z135mr566301itz.78.1476238088976; Tue, 11 Oct 2016 19:08:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.141.129 with HTTP; Tue, 11 Oct 2016 19:08:07 -0700 (PDT) In-Reply-To: References: <20160922092442.GA72044@ns.kevlo.org> <20160923015840.GA77979@ns.kevlo.org> <20160923071830.GA79146@ns.kevlo.org> <20161001150924.GA48641@ns.kevlo.org> <20161003005523.GA57437@ns.kevlo.org> <20161011012702.GA36712@ns.kevlo.org> From: Adrian Chadd Date: Tue, 11 Oct 2016 19:08:07 -0700 Message-ID: Subject: Re: urtwn(4) / rtwn(4) drivers are merged - call for review / testing To: Andriy Voskoboinyk Cc: Kevin Lo , "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 02:08:10 -0000 Hiya, So uhm - normal rtwn works fine, but andriy's merged version doesn't? -a From owner-freebsd-current@freebsd.org Wed Oct 12 04:03:14 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A98FC0B728 for ; Wed, 12 Oct 2016 04:03:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C2AC6F82 for ; Wed, 12 Oct 2016 04:03:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x244.google.com with SMTP id e203so3194162itc.1 for ; Tue, 11 Oct 2016 21:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=IQCvfuVyW3OQfKd9F70HfsZ8QHqX7xPv7sTdzgtB/a0=; b=RIr5eXsCzJuVn33KxtZ2wso/3jINxYZtHaIHykl5YD3Jz6Ukhazrd72rpcN0swILbN 59S44UrHLAjrXFdbbU1tiiTHd/FhywXj0EY8We68VJCVbKbSTkDofDJyeYM1dGa0UJ2Y WA4aPd7aZhbzbvVg09C4IwErLYLsgVlmESNwZSTjFwPnpPkp6HujmnAJ8Q9nsIfZkUma 6nsEgs+bGjlYh4LuMD4iZ/VOR2P3yvFjFSkpd6EwRWvEMuTs+Cmp/mELSbMifZ1q3Mvt ZnLqFry40buwCkdpQgTqbwBx9ka8AYyPmDALplkq8sM7ktH5hbxzThKwB+8y8ps53Vyu Uirg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=IQCvfuVyW3OQfKd9F70HfsZ8QHqX7xPv7sTdzgtB/a0=; b=hbhVUcEd/9eaup/dh8FpLFfmydFGK2rQKN3kGtw9KdEcm+xbSZtzx+Tca2mtol/kmB h8EbkdmysQyPXnu7IaBskqj/4w42RC6wBZyOpnhU4PiDBK8MmEqk6dsdLFNrGqDZ4moa fpkCbEbbNY/p7bv3jeYqD+7n9EJ6gKSVgbbyuLUsPHp2SmKZKIT319aXMB6aoMc6Kdkr rkdwJAWeKRK2TvPEdl6GlyP4digd2d82ukLfMrEuIb8VNJOsxViWb6z1yniq1POVN5z+ 0IErhX4hu3qcV7zMceEKcBAKg6phY8bErXiuf4+5ifFnFli85Gx6EqruVy4mienNqfGj oW8Q== X-Gm-Message-State: AA6/9RnAP3P4d3hQYxhwiz8Wv3h7YYENnmTENNGsIt4Jlf5bEKM+QeD/sO0JCpwIBfb5e+GI/kxC9uAHOIGeFA== X-Received: by 10.36.19.147 with SMTP id 141mr733351itz.85.1476244993114; Tue, 11 Oct 2016 21:03:13 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.77.85 with HTTP; Tue, 11 Oct 2016 21:03:12 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <63DC842D-48EC-4A5F-938F-AF8CE1E37BF8@freebsd.org> References: <20161008180742.GA1912@c720-r292778-amd64> <846bf31f-a757-2be0-a293-8c4ce3d42a2f@FreeBSD.org> <20161009015324.007a7b42@bsd64.grem.de> <20161009065423.GA2012@c720-r292778-amd64> <23c6b4f0-77e9-fe90-0eed-9d0125e7624b@FreeBSD.org> <20161010134610.32120b55@bsd64.grem.de> <20161010182710.GA1956@c720-r292778-amd64> <63DC842D-48EC-4A5F-938F-AF8CE1E37BF8@freebsd.org> From: Warner Losh Date: Tue, 11 Oct 2016 22:03:12 -0600 X-Google-Sender-Auth: W32B9qbD9Vn1VydcKjHmjzZAhUM Message-ID: Subject: Re: [request for testing] isl, cyapa on chromebooks To: Michael Gmelin Cc: Matthias Apitz , Andriy Gapon , FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 04:03:14 -0000 On Mon, Oct 10, 2016 at 12:45 PM, Michael Gmelin wrote= : > > >> On 10 Oct 2016, at 20:27, Matthias Apitz wrote: >> >>> El d=C3=ADa Monday, October 10, 2016 a las 09:26:26AM -0600, Warner Los= h escribi=C3=B3: >>> >>> I see no reason not to start the table right away based on >>> smbios.sys.product and other criteria. I don't think we need all the >>> matches that Linux uses, but we can expand the table if we find it so. >>> Why have a stop gap that's a table that we kludge together when the >>> real table is of comparable difficulty and wouldn't need to be >>> reworked. >> >> Please let us together concentrate on getting other i2c devices working, >> like the Elan TouchPad, because I fear that newer Chromebooks are all >> equipped with this and not with the Cyapa anymore. >> > > I see three tasks here: > - Andriy finishes his change, moving things from smbus to iicbus, addin= g some workaround to keep the user experience like it is > - Someone else implements the device table mechanism for auto detection > - Someone else ports HDI over I2C to allow implementing drivers for dev= ices like the elan touchpad Matthias is referring to I think I can do the device table mechanism if Andriy isn't up for it. Warner From owner-freebsd-current@freebsd.org Wed Oct 12 04:35:30 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6DBE3C0BDDD; Wed, 12 Oct 2016 04:35:30 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns.kevlo.org", Issuer "ns.kevlo.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DAF48DC1; Wed, 12 Oct 2016 04:35:28 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (localhost [127.0.0.1]) by ns.kevlo.org (8.15.2/8.15.2) with ESMTPS id u9C4YFMS045678 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Oct 2016 12:34:16 +0800 (CST) (envelope-from kevlo@ns.kevlo.org) Received: (from kevlo@localhost) by ns.kevlo.org (8.15.2/8.15.2/Submit) id u9C4YFli045677; Wed, 12 Oct 2016 12:34:15 +0800 (CST) (envelope-from kevlo) Date: Wed, 12 Oct 2016 12:34:15 +0800 From: Kevin Lo To: Andriy Voskoboinyk Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" , Adrian Chadd Subject: Re: urtwn(4) / rtwn(4) drivers are merged - call for review / testing Message-ID: <20161012043415.GA45653@ns.kevlo.org> References: <20160923015840.GA77979@ns.kevlo.org> <20160923071830.GA79146@ns.kevlo.org> <20161001150924.GA48641@ns.kevlo.org> <20161003005523.GA57437@ns.kevlo.org> <20161011012702.GA36712@ns.kevlo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 04:35:30 -0000 I tried to use https://github.com/s3erios/rtwn/tree/pci_modified, still no luck. BTW, there's a compilation error: http://pastebin.com/hCFfYVSj To ensure that the adapter is not faulty, I tested with the snapshots image (FreeBSD-12.0-CURRENT-amd64-20160829-r305028-memstick.img), rtwn(4) works fine. Kevin On Tue, Oct 11, 2016 at 11:21:24PM +0300, Andriy Voskoboinyk wrote: > > Tue, 11 Oct 2016 04:27:02 +0300 було написано Kevin Lo : > > I have created 'pci_modified' branch to speed-up the process (RTL881*AU > will > not work with it for now); right now it contains (mostly) unmodified > initialization path from rtwn(4) driver. > > If this version will work, I will revert some 'RTWN_PCI_WORKAROUND' > temporary blocks until the culprit is found. > > > On Sat, Oct 08, 2016 at 02:18:54AM +0300, Andriy Voskoboinyk wrote: > >> > >> Mon, 03 Oct 2016 03:55:23 +0300 було написано Kevin Lo > >> : > >> > >> Hi! > > > > Hi Andriy, > > > >> Can you refresh the tree and retest it (dev.rtwn.0.debug=0x829f) ? > > > > I refreshed the tree and retested it, unfortunately it's still the same. > > Here's the log: https://people.freebsd.org/~kevlo/rtl8188ce-debuglog > >> > >> P.S. If Rx is still broken (status is always 0) try to execute > >> 'ifconfig wlan0 promisc' > > > > It doesn't help either :( > > From owner-freebsd-current@freebsd.org Wed Oct 12 06:22:13 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA2DCC0E159 for ; Wed, 12 Oct 2016 06:22:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BEA41F38; Wed, 12 Oct 2016 06:22:12 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA29636; Wed, 12 Oct 2016 09:22:10 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1buCva-000Hko-1P; Wed, 12 Oct 2016 09:22:10 +0300 Subject: Re: [request for testing] isl, cyapa on chromebooks To: Warner Losh , Michael Gmelin References: <20161008180742.GA1912@c720-r292778-amd64> <846bf31f-a757-2be0-a293-8c4ce3d42a2f@FreeBSD.org> <20161009015324.007a7b42@bsd64.grem.de> <20161009065423.GA2012@c720-r292778-amd64> <23c6b4f0-77e9-fe90-0eed-9d0125e7624b@FreeBSD.org> <20161010134610.32120b55@bsd64.grem.de> <20161010182710.GA1956@c720-r292778-amd64> <63DC842D-48EC-4A5F-938F-AF8CE1E37BF8@freebsd.org> Cc: Matthias Apitz , FreeBSD Current From: Andriy Gapon Message-ID: <84f2393c-9b3f-a6de-abe7-b9c9912820dd@FreeBSD.org> Date: Wed, 12 Oct 2016 09:21:13 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 06:22:13 -0000 On 12/10/2016 07:03, Warner Losh wrote: > I think I can do the device table mechanism if Andriy isn't up for it. That would be great, thank you! -- Andriy Gapon From owner-freebsd-current@freebsd.org Wed Oct 12 08:45:54 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DDA93C0DF6D for ; Wed, 12 Oct 2016 08:45:54 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CD49282A; Wed, 12 Oct 2016 08:45:52 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA00387; Wed, 12 Oct 2016 11:45:51 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1buFAc-000Ht7-RA; Wed, 12 Oct 2016 11:45:50 +0300 Subject: Re: [request for testing] isl, cyapa on chromebooks To: Michael Gmelin , Matthias Apitz References: <20161008180742.GA1912@c720-r292778-amd64> <846bf31f-a757-2be0-a293-8c4ce3d42a2f@FreeBSD.org> <20161009015324.007a7b42@bsd64.grem.de> <20161009065423.GA2012@c720-r292778-amd64> <23c6b4f0-77e9-fe90-0eed-9d0125e7624b@FreeBSD.org> <20161010134610.32120b55@bsd64.grem.de> <20161010182710.GA1956@c720-r292778-amd64> <63DC842D-48EC-4A5F-938F-AF8CE1E37BF8@freebsd.org> <84f2393c-9b3f-a6de-abe7-b9c9912820dd@FreeBSD.org> Cc: Warner Losh , FreeBSD Current From: Andriy Gapon Message-ID: Date: Wed, 12 Oct 2016 11:45:14 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <84f2393c-9b3f-a6de-abe7-b9c9912820dd@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 08:45:55 -0000 On 12/10/2016 09:21, Andriy Gapon wrote: > On 12/10/2016 07:03, Warner Losh wrote: >> I think I can do the device table mechanism if Andriy isn't up for it. > > That would be great, thank you! > Meanwhile, I've added a "stop-gap" version of 'chromebook_platform' driver here: https://reviews.freebsd.org/D8172 A full patch can be downloaded from the review request. Could you please test if it works? All hints should be removed and the new module should be loaded in addition to other modules. It should not matter in which order the modules are loaded. Could you please test if loading chromebook_platform before and after isl and cyapa works the same? It's required to either reboot or reload iicbus between the tests, so that previously added devices are not re-used. Thanks! P.S. Not sure if the name is good, it's certainly verbose. -- Andriy Gapon From owner-freebsd-current@freebsd.org Wed Oct 12 11:23:09 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 223E4C0EA13; Wed, 12 Oct 2016 11:23:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4BBE196B; Wed, 12 Oct 2016 11:23:07 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA00973; Wed, 12 Oct 2016 14:23:05 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1buHcn-000I2H-FV; Wed, 12 Oct 2016 14:23:05 +0300 Subject: install header files required for development with libzfs_core References: <201610120708.u9C78WCw055832@repo.freebsd.org> To: freebsd-current@FreeBSD.org, freebsd-ports@FreeBSD.org From: Andriy Gapon X-Forwarded-Message-Id: <201610120708.u9C78WCw055832@repo.freebsd.org> Message-ID: <8574454c-b19f-288e-0be1-96f212700d53@FreeBSD.org> Date: Wed, 12 Oct 2016 14:21:44 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <201610120708.u9C78WCw055832@repo.freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 11:23:09 -0000 JFYI. I bumped __FreeBSD_version to 1200013 to mark this change. -------- Forwarded Message -------- Subject: svn commit: r307131 - head/include Date: Wed, 12 Oct 2016 07:08:32 +0000 (UTC) From: Andriy Gapon To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Author: avg Date: Wed Oct 12 07:08:32 2016 New Revision: 307131 URL: https://svnweb.freebsd.org/changeset/base/307131 Log: install header files required development with libzfs_core libzfs_core provides a rather limited but committed (stable) interface for working with ZFS. We install libzfs_core shared library but we do not install header files required for developing programs that use the library. This change is to install the required header files libzfs_core.h, libnvpair.h and sys/nvpair.h. The headers are installed into the same locations as on illumos. Reviewed by: mav, markj Differential Revision: https://reviews.freebsd.org/D8005 Modified: head/include/Makefile Modified: head/include/Makefile ============================================================================== --- head/include/Makefile Wed Oct 12 06:58:01 2016 (r307130) +++ head/include/Makefile Wed Oct 12 07:08:32 2016 (r307131) @@ -237,6 +237,17 @@ copies: .PHONY .META cd ${.CURDIR}/../sys/teken; \ ${INSTALL} -C ${TAG_ARGS} -o ${BINOWN} -g ${BINGRP} -m 444 teken.h \ ${DESTDIR}${INCLUDEDIR}/teken +.if ${MK_CDDL} != "no" + cd ${.CURDIR}/../cddl/contrib/opensolaris/lib/libzfs_core/common; \ + ${INSTALL} -C ${TAG_ARGS} -o ${BINOWN} -g ${BINGRP} -m 444 libzfs_core.h \ + ${DESTDIR}${INCLUDEDIR} + cd ${.CURDIR}/../cddl/contrib/opensolaris/lib/libnvpair; \ + ${INSTALL} -C ${TAG_ARGS} -o ${BINOWN} -g ${BINGRP} -m 444 libnvpair.h \ + ${DESTDIR}${INCLUDEDIR} + cd ${.CURDIR}/../sys/cddl/contrib/opensolaris/uts/common/sys; \ + ${INSTALL} -C ${TAG_ARGS} -o ${BINOWN} -g ${BINGRP} -m 444 nvpair.h \ + ${DESTDIR}${INCLUDEDIR}/sys +.endif symlinks: .PHONY .META @${ECHO} "Setting up symlinks to kernel source tree..." From owner-freebsd-current@freebsd.org Fri Oct 14 00:03:43 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D222EC10F8D; Fri, 14 Oct 2016 00:03:43 +0000 (UTC) (envelope-from andriyvos@gmail.com) Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5621E102; Fri, 14 Oct 2016 00:03:43 +0000 (UTC) (envelope-from andriyvos@gmail.com) Received: by mail-lf0-f43.google.com with SMTP id l131so122931137lfl.2; Thu, 13 Oct 2016 17:03:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:cc:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=58L+1HH41zDqvyFWoQdPw+IatCq9LLZfoKOwmoBNIQA=; b=l36fS3WAHmNvCjdSbbU7QE4iAV/2ZRqDcts8QhQYzsapJLQoZ3bBYML8WnRYVQSuMJ KLOl9uP5h+Tmkul2xn8Iaa7Etir3IUsr7ftxFLhg2VQNT/8///Fy6DDEX0xY/X8OM3Qo lzaML6X8G1k+sDU17hD9QjSC17WblcTxZiKpvDfI/BktCbq0cT4RvutqcDpoEp6DKe7/ nuEqBXHf4KvZqvOp7bkf2kLNLOfkD8KZFVRcp5PD8qpkqKmaxTuEF0+V9uDjrs0WKdxP ZwshWM5FtL5aaLI5IuHuHjLkaBDnvFYE/JbmxZs2IbhiJcjFl+VVTTNbUx/ELG0pJVaA tn1g== X-Gm-Message-State: AA6/9RnssaczCc/6600OEj0AdmbLiEiIu9IBBThkRfsYoGT16QvcgfiXi/KCFSQbOASDaw== X-Received: by 10.25.132.18 with SMTP id g18mr285954lfd.7.1476403420659; Thu, 13 Oct 2016 17:03:40 -0700 (PDT) Received: from localhost (host-176-37-109-22.la.net.ua. [176.37.109.22]) by smtp.gmail.com with ESMTPSA id g5sm4399045lfe.14.2016.10.13.17.03.39 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 13 Oct 2016 17:03:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Kevin Lo" Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" , "Adrian Chadd" Subject: Re: urtwn(4) / rtwn(4) drivers are merged - call for review / testing References: <20160923015840.GA77979@ns.kevlo.org> <20160923071830.GA79146@ns.kevlo.org> <20161001150924.GA48641@ns.kevlo.org> <20161003005523.GA57437@ns.kevlo.org> <20161011012702.GA36712@ns.kevlo.org> <20161012043415.GA45653@ns.kevlo.org> Date: Fri, 14 Oct 2016 03:03:41 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Andriy Voskoboinyk" Message-ID: In-Reply-To: <20161012043415.GA45653@ns.kevlo.org> User-Agent: Opera Mail/12.16 (FreeBSD) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 00:03:44 -0000 Wed, 12 Oct 2016 07:34:15 +0300 =D0=B1=D1=83=D0=BB=D0=BE =D0=BD=D0=B0=D0= =BF=D0=B8=D1=81=D0=B0=D0=BD=D0=BE Kevin Lo : Thanks for testing! (I have got another one to simplify the process) Can you approve that current tree (master) works without any (new) = problems? P.S. Known issue (present in the current driver too): - the card ACKs only some frames that were sent using CCK rates (whilst sees all retransmissions - that can be seen in 'rx discard 'cuz = = dup' counter via wlanstats) > I tried to use https://github.com/s3erios/rtwn/tree/pci_modified, > still no luck. BTW, there's a compilation error: = > http://pastebin.com/hCFfYVSj > > To ensure that the adapter is not faulty, I tested with the snapshots = = > image > (FreeBSD-12.0-CURRENT-amd64-20160829-r305028-memstick.img), rtwn(4) = > works fine. > > Kevin > > On Tue, Oct 11, 2016 at 11:21:24PM +0300, Andriy Voskoboinyk wrote: >> >> Tue, 11 Oct 2016 04:27:02 +0300 =D0=B1=D1=83=D0=BB=D0=BE =D0=BD=D0=B0= =D0=BF=D0=B8=D1=81=D0=B0=D0=BD=D0=BE Kevin Lo = >> : >> >> I have created 'pci_modified' branch to speed-up the process (RTL881*= AU >> will >> not work with it for now); right now it contains (mostly) unmodified >> initialization path from rtwn(4) driver. >> >> If this version will work, I will revert some 'RTWN_PCI_WORKAROUND' >> temporary blocks until the culprit is found. >> >> > On Sat, Oct 08, 2016 at 02:18:54AM +0300, Andriy Voskoboinyk wrote:= >> >> >> >> Mon, 03 Oct 2016 03:55:23 +0300 =D0=B1=D1=83=D0=BB=D0=BE =D0=BD=D0= =B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BD=D0=BE Kevin Lo >> >> : >> >> >> >> Hi! >> > >> > Hi Andriy, >> > >> >> Can you refresh the tree and retest it (dev.rtwn.0.debug=3D0x829f)= ? >> > >> > I refreshed the tree and retested it, unfortunately it's still the = = >> same. >> > Here's the log: https://people.freebsd.org/~kevlo/rtl8188ce-debuglo= g >> >> >> >> P.S. If Rx is still broken (status is always 0) try to execute >> >> 'ifconfig wlan0 promisc' >> > >> > It doesn't help either :( >> From owner-freebsd-current@freebsd.org Fri Oct 14 00:16:14 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B5C1AC647F for ; Fri, 14 Oct 2016 00:16:14 +0000 (UTC) (envelope-from scott.k.mitch1@gmail.com) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F028DABF for ; Fri, 14 Oct 2016 00:16:13 +0000 (UTC) (envelope-from scott.k.mitch1@gmail.com) Received: by mail-yb0-x22f.google.com with SMTP id o189so11893426yba.1 for ; Thu, 13 Oct 2016 17:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=/CZ2a+TH5imLmQ2hcrWlqygNqfQw/eDq2BDa8WIY9/c=; b=kSD1Bxn4bIlSMbqEhB4W7gSfh0wVAtSflSidzeH/MtwQsE/m+78E/XuKBcy5UDlGmH PVJnihJ9m/DN2bT46+GUdq4bJkrfl/Vy2no2VC+WEehaS6jbSpUS5OoAykKArLCDK/Y9 c1oGHNqTQxaye6Z9oprYx06MXeyJTQvW73kdVREzFqcjzns/uSiowzqVGr10pZZfMhhU +BPWv8+rHNYX/0YlALLDkL4CVBgfRUkpT8Gvwg63cxvZ8h+q6kBsxGWTQnZSrWfs2Wa4 YlBd7MJvsQzyhpIUxllVIVMZPmwPGZhewT9Wz3fSSsDG9Y2ER+7+ppxe8r9AQzPmrqHT i3LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=/CZ2a+TH5imLmQ2hcrWlqygNqfQw/eDq2BDa8WIY9/c=; b=Rdrw1lSYePWg3yjNne9jmjtCjAIupvQAGlHGJoNrL9FYXrsISkSUgF79fZe+Lc4pg5 34NAVzmoH34KRyaR3gT0IrxKeD5jDll6ez28TjHUgazzjW3YDg8HiqP2e846CN3KKXcw RgnVHo/UNLOx0e6/PDCkWgqizeZAR5bHWnQKj+4C0IIYWnfYAZUWNVlD0INX34g4n8rW U9hlA6y8U0jIg2Z5JmlMVhU61KnukUp8XmPNQcbhiJlvysnYdadl3qLwhquII0fWnAoG aKh1pKmdZajajMys+rJ2UncaImztSGQzhNxrGuBebkroPaTKfcqzW9OmtsUezKb5zLu8 gUHA== X-Gm-Message-State: AA6/9Rm2RMkWrnr26jufZaLtmu06aLjZVByJAsTsLkFeSbaiWzSoiAPlRLrN+lwNEJpMOEHDtjfviLbxxBqa6g== X-Received: by 10.37.51.132 with SMTP id z126mr8155910ybz.2.1476404173180; Thu, 13 Oct 2016 17:16:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.223.198 with HTTP; Thu, 13 Oct 2016 17:16:12 -0700 (PDT) From: Scott Mitchell Date: Thu, 13 Oct 2016 17:16:12 -0700 Message-ID: Subject: (boost::)asio and kqueue problem To: freebsd-current@freebsd.org Cc: sepherosa@gmail.com, kostikbel@gmail.com, hartmut.brandt@dlr.de, adrian.chadd@gmail.com X-Mailman-Approved-At: Fri, 14 Oct 2016 00:37:38 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 00:16:14 -0000 I am not using boost but I have also encountered this unexpected behavior when calling listen after kevent. Is their any update on the approach to merge filt_soread and filt_solisten? FYI - MacOS does not have this unexpected behavior. Read events are not "missed" if the listen is done after the kevent *EVFILT_READ *change is registered. Thanks, -Scott From owner-freebsd-current@freebsd.org Fri Oct 14 01:59:06 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7676AC10B59; Fri, 14 Oct 2016 01:59:06 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns.kevlo.org", Issuer "ns.kevlo.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D6510D8A; Fri, 14 Oct 2016 01:59:05 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (localhost [127.0.0.1]) by ns.kevlo.org (8.15.2/8.15.2) with ESMTPS id u9E1vnEx069346 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 14 Oct 2016 09:57:49 +0800 (CST) (envelope-from kevlo@ns.kevlo.org) Received: (from kevlo@localhost) by ns.kevlo.org (8.15.2/8.15.2/Submit) id u9E1vmZg069345; Fri, 14 Oct 2016 09:57:49 +0800 (CST) (envelope-from kevlo) Date: Fri, 14 Oct 2016 09:57:48 +0800 From: Kevin Lo To: Andriy Voskoboinyk Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" , Adrian Chadd Subject: Re: urtwn(4) / rtwn(4) drivers are merged - call for review / testing Message-ID: <20161014015748.GA69328@ns.kevlo.org> References: <20160923071830.GA79146@ns.kevlo.org> <20161001150924.GA48641@ns.kevlo.org> <20161003005523.GA57437@ns.kevlo.org> <20161011012702.GA36712@ns.kevlo.org> <20161012043415.GA45653@ns.kevlo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 01:59:06 -0000 On Fri, Oct 14, 2016 at 03:03:41AM +0300, Andriy Voskoboinyk wrote: > > Wed, 12 Oct 2016 07:34:15 +0300 було написано Kevin Lo : > > Thanks for testing! (I have got another one to simplify the process) > Can you approve that current tree (master) works without any (new) > problems? Sure. For usb wireless adapters, they work quite well :) Thanks. > P.S. Known issue (present in the current driver too): > - the card ACKs only some frames that were sent using CCK rates > (whilst sees all retransmissions - that can be seen in 'rx discard 'cuz > dup' > counter via wlanstats) > > > I tried to use https://github.com/s3erios/rtwn/tree/pci_modified, > > still no luck. BTW, there's a compilation error: > > http://pastebin.com/hCFfYVSj > > > > To ensure that the adapter is not faulty, I tested with the snapshots > > image > > (FreeBSD-12.0-CURRENT-amd64-20160829-r305028-memstick.img), rtwn(4) > > works fine. > > > > Kevin > > > > On Tue, Oct 11, 2016 at 11:21:24PM +0300, Andriy Voskoboinyk wrote: > >> > >> Tue, 11 Oct 2016 04:27:02 +0300 було написано Kevin Lo > >> : > >> > >> I have created 'pci_modified' branch to speed-up the process (RTL881*AU > >> will > >> not work with it for now); right now it contains (mostly) unmodified > >> initialization path from rtwn(4) driver. > >> > >> If this version will work, I will revert some 'RTWN_PCI_WORKAROUND' > >> temporary blocks until the culprit is found. > >> > >> > On Sat, Oct 08, 2016 at 02:18:54AM +0300, Andriy Voskoboinyk wrote: > >> >> > >> >> Mon, 03 Oct 2016 03:55:23 +0300 було написано Kevin Lo > >> >> : > >> >> > >> >> Hi! > >> > > >> > Hi Andriy, > >> > > >> >> Can you refresh the tree and retest it (dev.rtwn.0.debug=0x829f) ? > >> > > >> > I refreshed the tree and retested it, unfortunately it's still the > >> same. > >> > Here's the log: https://people.freebsd.org/~kevlo/rtl8188ce-debuglog > >> >> > >> >> P.S. If Rx is still broken (status is always 0) try to execute > >> >> 'ifconfig wlan0 promisc' > >> > > >> > It doesn't help either :( > >> > > From owner-freebsd-current@freebsd.org Fri Oct 14 07:19:35 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8BDBDC113A1; Fri, 14 Oct 2016 07:19:35 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BB7D31B; Fri, 14 Oct 2016 07:19:35 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u9E7JREn094856 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 14 Oct 2016 00:19:28 -0700 (PDT) (envelope-from julian@freebsd.org) To: "freebsd-fs@freebsd.org" , freebsd-current From: Julian Elischer Subject: zfs crash on FreeBSD 10.3 Message-ID: <55fa7ab0-2a65-6a3c-4b19-49c2588b5911@freebsd.org> Date: Fri, 14 Oct 2016 00:19:21 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 07:19:35 -0000 I attempted to add a second partition to an existing FS pool in FreeBSD 10.3 and the result was a crash.. is there anyone out there with a scratch system (10.3) (or two spare drives) who can show me this working? Does it look familiar to anyone? The drive 'boot0' is being used as the root drive, but we are in single user mode, so its' read-only at this stage. =============== cut-n-paste ============= [boot -s] [...] Trying to mount root from zfs:p8/image1 []... Enter full pathname of shell or RETURN for /bin/sh: PS1="# " # # # ls /dev/gpt boot0 boot1 # zpool attach -f p8 gpt/boot0 gpt/boot1 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x50 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff81717063 stack pointer = 0x28:0xfffffe0169bfc640 frame pointer = 0x28:0xfffffe0169bfc9a0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 3 (txg_thread_enter) trap number = 12 Panic:Thought about setting the watchdog to 10 Minutes panic: page fault cpuid = 1 KDB: stack backtrace: stack1 db_trace_self_wrapper+0x2a kdb_backtrace+0x37 vpanic+0xf7 panic+0x67 trap_fatal+0x264 trap_pfault+0x1c2 trap+0x38c calltrap+0x8 dsl_scan_sync+0x2f3 spa_sync+0x328 txg_sync_thread+0x140 fork_exit+0x135 fork_trampoline+0xe KDB: enter: panic [ thread pid 3 tid 100328 ] Stopped at kdb_enter+0x50: movq $0,0x6bd5cd(%rip) db> reboot I will add that after this, every boot hits this problem. (same stack trace). the box is effectively bricked (or would be if it weren't just a bhyve image) From owner-freebsd-current@freebsd.org Fri Oct 14 08:19:17 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9612EC11FF8 for ; Fri, 14 Oct 2016 08:19:17 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from mailhost.dlr.de (mailhost.dlr.de [129.247.252.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailhost.dlr.de", Issuer "DLR CA - G02" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 07189B55 for ; Fri, 14 Oct 2016 08:19:16 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from DLREXHUB01.intra.dlr.de (172.21.152.130) by mailhost.dlr.de (172.21.163.100) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 14 Oct 2016 10:18:00 +0200 Received: from DLREXMBX01.intra.dlr.de ([fe80::d198:77e5:d411:fccd]) by dlrexhub01.intra.dlr.de ([::1]) with mapi id 14.03.0301.000; Fri, 14 Oct 2016 10:18:04 +0200 From: To: , CC: , , Subject: RE: (boost::)asio and kqueue problem Thread-Topic: (boost::)asio and kqueue problem Thread-Index: AQHSJbAtfCrhAIEjLE+yOuce+WOwUqCnm0Sw Date: Fri, 14 Oct 2016 08:18:03 +0000 Message-ID: <611243783F62AF48AFB07BC25FA4B1061CE6471B@DLREXMBX01.intra.dlr.de> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 08:19:17 -0000 SSBoYXZlIGEgZml4IHRoYXQgd29ya3MgYW5kIGlzIGJldHRlciBhbmQgc2ltcGxlciB0aGFuIHRo ZSBwcmV2aW91cyBhbmQgd2lsbCB0cnkgdG8gcHV0IGl0IHRvZ2V0aGVyIGluIHRoZSBuZXh0IGZl dyBkYXlzLg0KDQpoYXJ0aQ0KDQpGcm9tOiBTY290dCBNaXRjaGVsbCBbbWFpbHRvOnNjb3R0Lmsu bWl0Y2gxQGdtYWlsLmNvbV0NClNlbnQ6IEZyaWRheSwgT2N0b2JlciAxNCwgMjAxNiAyOjE2IEFN DQpUbzogZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3JnDQpDYzogc2VwaGVyb3NhQGdtYWlsLmNv bTsga29zdGlrYmVsQGdtYWlsLmNvbTsgQnJhbmR0LCBIYXJ0bXV0OyBhZHJpYW4uY2hhZGRAZ21h aWwuY29tDQpTdWJqZWN0OiAoYm9vc3Q6Oilhc2lvIGFuZCBrcXVldWUgcHJvYmxlbQ0KDQpJIGFt IG5vdCB1c2luZyBib29zdCBidXQgSSBoYXZlIGFsc28gZW5jb3VudGVyZWQgdGhpcyB1bmV4cGVj dGVkIGJlaGF2aW9yIHdoZW4gY2FsbGluZyBsaXN0ZW4gYWZ0ZXIga2V2ZW50LiBJcyB0aGVpciBh bnkgdXBkYXRlIG9uIHRoZSBhcHByb2FjaCB0byBtZXJnZSBmaWx0X3NvcmVhZCBhbmQgZmlsdF9z b2xpc3Rlbj8NCg0KRllJIC0gTWFjT1MgZG9lcyBub3QgaGF2ZSB0aGlzIHVuZXhwZWN0ZWQgYmVo YXZpb3IuIFJlYWQgZXZlbnRzIGFyZSBub3QgIm1pc3NlZCIgaWYgdGhlIGxpc3RlbiBpcyBkb25l IGFmdGVyIHRoZSBrZXZlbnQgRVZGSUxUX1JFQUQgY2hhbmdlIGlzIHJlZ2lzdGVyZWQuDQoNClRo YW5rcywNCi1TY290dA0K From owner-freebsd-current@freebsd.org Fri Oct 14 08:48:48 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2DD3FC10ACF for ; Fri, 14 Oct 2016 08:48:48 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E7A5E690 for ; Fri, 14 Oct 2016 08:48:47 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1buyAQ-0001D5-Mr>; Fri, 14 Oct 2016 10:48:38 +0200 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1buyAQ-001pEO-Dd>; Fri, 14 Oct 2016 10:48:38 +0200 Date: Fri, 14 Oct 2016 10:48:33 +0200 From: "O. Hartmann" To: freebsd-current Subject: CURRENT [r307305]: Crashing Message-ID: <20161014104833.7a2ac588@freyja.zeit4.iv.bundesimmobilien.de> Organization: FU Berlin X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 08:48:48 -0000 Systems I updated to recent CURRENT start crashing spontaneously. recent crashing system is on 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r307305: Fri Oct 14 08:37:59 CEST 2016 other (no access since it is remote and not accessible until later the day) has been updated ~ 12 hours ago and it is alos rebooting/crashing without any warnings. Can be triggered on heavy load. Only system with r307263 and stable so far is an older two-socket XEON Core2Duao based machine, all crashing boxes have CPUs newer or equal than IvyBridge. Does anyone also see these crashes? I tried to compile a debug kernel on one host, but that's the remote machine I have access to later, it failed compiling the kernel - under load it crashed often. After ZFS scrubbing kickied in, it vanished from the net ;-/ kind regards, oh From owner-freebsd-current@freebsd.org Fri Oct 14 09:23:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BF970C11982 for ; Fri, 14 Oct 2016 09:23:07 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from mailhost.dlr.de (mailhost.dlr.de [129.247.252.33]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailhost.dlr.de", Issuer "DLR CA - G02" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 28393F8B for ; Fri, 14 Oct 2016 09:23:06 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from DLREXHUB01.intra.dlr.de (172.21.152.130) by mailhost.dlr.de (172.21.163.101) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 14 Oct 2016 11:21:48 +0200 Received: from DLREXMBX01.intra.dlr.de ([fe80::d198:77e5:d411:fccd]) by dlrexhub01.intra.dlr.de ([::1]) with mapi id 14.03.0301.000; Fri, 14 Oct 2016 11:21:53 +0200 From: To: , CC: , , Subject: asio and kqueue (2nd trye) (was: RE: (boost::)asio and kqueue problem) Thread-Topic: asio and kqueue (2nd trye) (was: RE: (boost::)asio and kqueue problem) Thread-Index: AdIl/BJiSN1ghx5qSpSgQRvAcWA/Sw== Date: Fri, 14 Oct 2016 09:21:52 +0000 Message-ID: <611243783F62AF48AFB07BC25FA4B1061CE64959@DLREXMBX01.intra.dlr.de> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/mixed; boundary="_002_611243783F62AF48AFB07BC25FA4B1061CE64959DLREXMBX01intra_" MIME-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 09:23:07 -0000 --_002_611243783F62AF48AFB07BC25FA4B1061CE64959DLREXMBX01intra_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpoZXJlIGlzIHRoZSAybmQgdHJ5IHRha2luZyBpbnRvIGFjY291bnQgdGhlIGNv bW1lbnRzIEkgcmVjZWl2ZWQuIFNpbmNlIEknbSBub3QgZmFtaWxpYXIgd2l0aCB0aGUgbG9ja2lu ZyBpbiB0aGUgc29ja2V0cyBhcmVhIEkgYXNrIHNvbWVib2R5IHdpdGggdGhhdCBrbm93bGVkZ2Ug dG8gY2hlY2sgaXQgYmVmb3JlIEkgY29tbWl0IGl0Lg0KDQpUaGFua3MsDQpoYXJ0aQ0KDQoNCg0K DQpGcm9tOiBTY290dCBNaXRjaGVsbCBbbWFpbHRvOnNjb3R0LmsubWl0Y2gxQGdtYWlsLmNvbV0g DQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMTQsIDIwMTYgMjoxNiBBTQ0KVG86IGZyZWVic2QtY3Vy cmVudEBmcmVlYnNkLm9yZw0KQ2M6IHNlcGhlcm9zYUBnbWFpbC5jb207IGtvc3Rpa2JlbEBnbWFp bC5jb207IEJyYW5kdCwgSGFydG11dDsgYWRyaWFuLmNoYWRkQGdtYWlsLmNvbQ0KU3ViamVjdDog KGJvb3N0OjopYXNpbyBhbmQga3F1ZXVlIHByb2JsZW0NCg0KSSBhbSBub3QgdXNpbmcgYm9vc3Qg YnV0IEkgaGF2ZSBhbHNvIGVuY291bnRlcmVkIHRoaXMgdW5leHBlY3RlZCBiZWhhdmlvciB3aGVu IGNhbGxpbmcgbGlzdGVuIGFmdGVyIGtldmVudC4gSXMgdGhlaXIgYW55IHVwZGF0ZSBvbiB0aGUg YXBwcm9hY2ggdG8gbWVyZ2UgZmlsdF9zb3JlYWQgYW5kIGZpbHRfc29saXN0ZW4/DQoNCkZZSSAt IE1hY09TIGRvZXMgbm90IGhhdmUgdGhpcyB1bmV4cGVjdGVkIGJlaGF2aW9yLiBSZWFkIGV2ZW50 cyBhcmUgbm90ICJtaXNzZWQiIGlmIHRoZSBsaXN0ZW4gaXMgZG9uZSBhZnRlciB0aGUga2V2ZW50 wqBFVkZJTFRfUkVBRMKgY2hhbmdlIGlzIHJlZ2lzdGVyZWQuDQoNClRoYW5rcywNCi1TY290dA0K --_002_611243783F62AF48AFB07BC25FA4B1061CE64959DLREXMBX01intra_ Content-Type: application/octet-stream; name="asio_listen.diff" Content-Description: asio_listen.diff Content-Disposition: attachment; filename="asio_listen.diff"; size=2796; creation-date="Fri, 14 Oct 2016 09:18:26 GMT"; modification-date="Fri, 14 Oct 2016 09:16:54 GMT" Content-Transfer-Encoding: base64 SW5kZXg6IHVpcGNfc29ja2V0LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdWlwY19zb2NrZXQuYwkocmV2aXNp b24gMzA3MDkxKQorKysgdWlwY19zb2NrZXQuYwkod29ya2luZyBjb3B5KQpAQCAtMTU5LDE1ICsx NTksOSBAQAogc3RhdGljIGludAlmaWx0X3NvcmVhZChzdHJ1Y3Qga25vdGUgKmtuLCBsb25nIGhp bnQpOwogc3RhdGljIHZvaWQJZmlsdF9zb3dkZXRhY2goc3RydWN0IGtub3RlICprbik7CiBzdGF0 aWMgaW50CWZpbHRfc293cml0ZShzdHJ1Y3Qga25vdGUgKmtuLCBsb25nIGhpbnQpOwotc3RhdGlj IGludAlmaWx0X3NvbGlzdGVuKHN0cnVjdCBrbm90ZSAqa24sIGxvbmcgaGludCk7CiBzdGF0aWMg aW50IGlubGluZSBoaG9va19ydW5fc29ja2V0KHN0cnVjdCBzb2NrZXQgKnNvLCB2b2lkICpoY3R4 LCBpbnQzMl90IGhfaWQpOwogZm9fa3FmaWx0ZXJfdAlzb29fa3FmaWx0ZXI7CiAKLXN0YXRpYyBz dHJ1Y3QgZmlsdGVyb3BzIHNvbGlzdGVuX2ZpbHRvcHMgPSB7Ci0JLmZfaXNmZCA9IDEsCi0JLmZf ZGV0YWNoID0gZmlsdF9zb3JkZXRhY2gsCi0JLmZfZXZlbnQgPSBmaWx0X3NvbGlzdGVuLAotfTsK IHN0YXRpYyBzdHJ1Y3QgZmlsdGVyb3BzIHNvcmVhZF9maWx0b3BzID0gewogCS5mX2lzZmQgPSAx LAogCS5mX2RldGFjaCA9IGZpbHRfc29yZGV0YWNoLApAQCAtMzA3NSwxMCArMzA2OSw3IEBACiAK IAlzd2l0Y2ggKGtuLT5rbl9maWx0ZXIpIHsKIAljYXNlIEVWRklMVF9SRUFEOgotCQlpZiAoc28t PnNvX29wdGlvbnMgJiBTT19BQ0NFUFRDT05OKQotCQkJa24tPmtuX2ZvcCA9ICZzb2xpc3Rlbl9m aWx0b3BzOwotCQllbHNlCi0JCQlrbi0+a25fZm9wID0gJnNvcmVhZF9maWx0b3BzOworCQlrbi0+ a25fZm9wID0gJnNvcmVhZF9maWx0b3BzOwogCQlzYiA9ICZzby0+c29fcmN2OwogCQlicmVhazsK IAljYXNlIEVWRklMVF9XUklURToKQEAgLTMyODIsMjkgKzMyNzMsMzQgQEAKIHN0YXRpYyBpbnQK IGZpbHRfc29yZWFkKHN0cnVjdCBrbm90ZSAqa24sIGxvbmcgaGludCkKIHsKLQlzdHJ1Y3Qgc29j a2V0ICpzbzsKKwlzdHJ1Y3Qgc29ja2V0ICpzbyA9IGtuLT5rbl9mcC0+Zl9kYXRhOwogCi0Jc28g PSBrbi0+a25fZnAtPmZfZGF0YTsKLQlTT0NLQlVGX0xPQ0tfQVNTRVJUKCZzby0+c29fcmN2KTsK KwlpZiAoc28tPnNvX29wdGlvbnMgJiBTT19BQ0NFUFRDT05OKSB7CisJCWtuLT5rbl9kYXRhID0g c28tPnNvX3FsZW47CisJCXJldHVybiAoIVRBSUxRX0VNUFRZKCZzby0+c29fY29tcCkpOwogCi0J a24tPmtuX2RhdGEgPSBzYmF2YWlsKCZzby0+c29fcmN2KSAtIHNvLT5zb19yY3Yuc2JfY3RsOwot CWlmIChzby0+c29fcmN2LnNiX3N0YXRlICYgU0JTX0NBTlRSQ1ZNT1JFKSB7Ci0JCWtuLT5rbl9m bGFncyB8PSBFVl9FT0Y7Ci0JCWtuLT5rbl9mZmxhZ3MgPSBzby0+c29fZXJyb3I7Ci0JCXJldHVy biAoMSk7Ci0JfSBlbHNlIGlmIChzby0+c29fZXJyb3IpCS8qIHRlbXBvcmFyeSB1ZHAgZXJyb3Ig Ki8KLQkJcmV0dXJuICgxKTsKKwl9IGVsc2UgeworCQlTT0NLQlVGX0xPQ0tfQVNTRVJUKCZzby0+ c29fcmN2KTsKIAotCWlmIChrbi0+a25fc2ZmbGFncyAmIE5PVEVfTE9XQVQpIHsKLQkJaWYgKGtu LT5rbl9kYXRhID49IGtuLT5rbl9zZGF0YSkKLQkJCXJldHVybiAxOwotCX0gZWxzZSB7Ci0JCWlm IChzYmF2YWlsKCZzby0+c29fcmN2KSA+PSBzby0+c29fcmN2LnNiX2xvd2F0KQotCQkJcmV0dXJu IDE7CisJCWtuLT5rbl9kYXRhID0gc2JhdmFpbCgmc28tPnNvX3JjdikgLSBzby0+c29fcmN2LnNi X2N0bDsKKwkJaWYgKHNvLT5zb19yY3Yuc2Jfc3RhdGUgJiBTQlNfQ0FOVFJDVk1PUkUpIHsKKwkJ CWtuLT5rbl9mbGFncyB8PSBFVl9FT0Y7CisJCQlrbi0+a25fZmZsYWdzID0gc28tPnNvX2Vycm9y OworCQkJcmV0dXJuICgxKTsKKwkJfSBlbHNlIGlmIChzby0+c29fZXJyb3IpCS8qIHRlbXBvcmFy eSB1ZHAgZXJyb3IgKi8KKwkJCXJldHVybiAoMSk7CisKKwkJaWYgKGtuLT5rbl9zZmZsYWdzICYg Tk9URV9MT1dBVCkgeworCQkJaWYgKGtuLT5rbl9kYXRhID49IGtuLT5rbl9zZGF0YSkKKwkJCQly ZXR1cm4gMTsKKwkJfSBlbHNlIHsKKwkJCWlmIChzYmF2YWlsKCZzby0+c29fcmN2KSA+PSBzby0+ c29fcmN2LnNiX2xvd2F0KQorCQkJCXJldHVybiAxOworCQl9CisKKwkJLyogVGhpcyBob29rIHJl dHVybmluZyBub24temVybyBpbmRpY2F0ZXMgYW4gZXZlbnQsIG5vdCBlcnJvciAqLworCQlyZXR1 cm4gKGhob29rX3J1bl9zb2NrZXQoc28sIE5VTEwsIEhIT09LX0ZJTFRfU09SRUFEKSk7CiAJfQot Ci0JLyogVGhpcyBob29rIHJldHVybmluZyBub24temVybyBpbmRpY2F0ZXMgYW4gZXZlbnQsIG5v dCBlcnJvciAqLwotCXJldHVybiAoaGhvb2tfcnVuX3NvY2tldChzbywgTlVMTCwgSEhPT0tfRklM VF9TT1JFQUQpKTsKIH0KIAogc3RhdGljIHZvaWQKQEAgLTMzNDYsMTYgKzMzNDIsNiBAQAogCQly ZXR1cm4gKGtuLT5rbl9kYXRhID49IHNvLT5zb19zbmQuc2JfbG93YXQpOwogfQogCi0vKkFSR1NV U0VEKi8KLXN0YXRpYyBpbnQKLWZpbHRfc29saXN0ZW4oc3RydWN0IGtub3RlICprbiwgbG9uZyBo aW50KQotewotCXN0cnVjdCBzb2NrZXQgKnNvID0ga24tPmtuX2ZwLT5mX2RhdGE7Ci0KLQlrbi0+ a25fZGF0YSA9IHNvLT5zb19xbGVuOwotCXJldHVybiAoIVRBSUxRX0VNUFRZKCZzby0+c29fY29t cCkpOwotfQotCiBpbnQKIHNvY2hlY2t1aWQoc3RydWN0IHNvY2tldCAqc28sIHVpZF90IHVpZCkK IHsK --_002_611243783F62AF48AFB07BC25FA4B1061CE64959DLREXMBX01intra_-- From owner-freebsd-current@freebsd.org Fri Oct 14 10:32:08 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51A67C11333; Fri, 14 Oct 2016 10:32:08 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EC147B78; Fri, 14 Oct 2016 10:32:07 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id u9EAVvDu039755 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 14 Oct 2016 12:31:57 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id u9EAVuUq039752; Fri, 14 Oct 2016 12:31:56 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Fri, 14 Oct 2016 12:31:56 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: Julian Elischer cc: "freebsd-fs@freebsd.org" , freebsd-current Subject: Re: zfs crash on FreeBSD 10.3 In-Reply-To: <55fa7ab0-2a65-6a3c-4b19-49c2588b5911@freebsd.org> Message-ID: References: <55fa7ab0-2a65-6a3c-4b19-49c2588b5911@freebsd.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 10:32:08 -0000 On Fri, 14 Oct 2016 00:19-0700, Julian Elischer wrote: > I attempted to add a second partition to an existing FS pool in FreeBSD 10.3 > and the result was a crash.. > > is there anyone out there with a scratch system (10.3) (or two spare drives) > who can show me this working? > > Does it look familiar to anyone? > > The drive 'boot0' is being used as the root drive, but we are in single user > mode, so its' read-only at this stage. > > =============== cut-n-paste ============= > > [boot -s] > > [...] > > Trying to mount root from zfs:p8/image1 []... > Enter full pathname of shell or RETURN for /bin/sh: > PS1="# " > # > # > # ls /dev/gpt > boot0 boot1 > # zpool attach -f p8 gpt/boot0 gpt/boot1 Do you really need to force zpool to attach the second partition? What happens if you omit the -f flag? > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x50 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff81717063 > stack pointer = 0x28:0xfffffe0169bfc640 > frame pointer = 0x28:0xfffffe0169bfc9a0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 3 (txg_thread_enter) > trap number = 12 > Panic:Thought about setting the watchdog to 10 Minutes > panic: page fault > cpuid = 1 > > KDB: stack backtrace: > stack1 db_trace_self_wrapper+0x2a > kdb_backtrace+0x37 vpanic+0xf7 > panic+0x67 trap_fatal+0x264 > trap_pfault+0x1c2 > trap+0x38c > calltrap+0x8 > dsl_scan_sync+0x2f3 > spa_sync+0x328 > txg_sync_thread+0x140 > fork_exit+0x135 > fork_trampoline+0xe > > KDB: enter: panic > [ thread pid 3 tid 100328 ] > Stopped at kdb_enter+0x50: movq $0,0x6bd5cd(%rip) > db> reboot > > I will add that after this, every boot hits this problem. (same stack trace). > the box is effectively bricked > (or would be if it weren't just a bhyve image) -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestl, | Trond Endrestl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@freebsd.org Fri Oct 14 12:04:02 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA3B4C106A7 for ; Fri, 14 Oct 2016 12:04:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 34E70D98 for ; Fri, 14 Oct 2016 12:04:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u9EC3Y8l060616 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 14 Oct 2016 15:03:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u9EC3Y8l060616 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u9EC3XKR060609; Fri, 14 Oct 2016 15:03:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 14 Oct 2016 15:03:33 +0300 From: Konstantin Belousov To: Hartmut.Brandt@dlr.de Cc: scott.k.mitch1@gmail.com, freebsd-current@freebsd.org, sepherosa@gmail.com, adrian.chadd@gmail.com Subject: Re: asio and kqueue (2nd trye) (was: RE: (boost::)asio and kqueue problem) Message-ID: <20161014120333.GB2404@kib.kiev.ua> References: <611243783F62AF48AFB07BC25FA4B1061CE64959@DLREXMBX01.intra.dlr.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <611243783F62AF48AFB07BC25FA4B1061CE64959@DLREXMBX01.intra.dlr.de> User-Agent: Mutt/1.7.0 (2016-08-17) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 12:04:02 -0000 On Fri, Oct 14, 2016 at 09:21:52AM +0000, Hartmut.Brandt@dlr.de wrote: > Hi all, > > here is the 2nd try taking into account the comments I received. Since I'm not familiar with the locking in the sockets area I ask somebody with that knowledge to check it before I commit it. I have only style notes, the factual code changes in the patch look good to me. Index: uipc_socket.c =================================================================== --- uipc_socket.c (revision 307091) +++ uipc_socket.c (working copy) @@ -159,15 +159,9 @@ static int filt_soread(struct knote *kn, long hint); static void filt_sowdetach(struct knote *kn); static int filt_sowrite(struct knote *kn, long hint); -static int filt_solisten(struct knote *kn, long hint); static int inline hhook_run_socket(struct socket *so, void *hctx, int32_t h_id); fo_kqfilter_t soo_kqfilter; -static struct filterops solisten_filtops = { - .f_isfd = 1, - .f_detach = filt_sordetach, - .f_event = filt_solisten, -}; static struct filterops soread_filtops = { .f_isfd = 1, .f_detach = filt_sordetach, @@ -3075,10 +3069,7 @@ switch (kn->kn_filter) { case EVFILT_READ: - if (so->so_options & SO_ACCEPTCONN) - kn->kn_fop = &solisten_filtops; - else - kn->kn_fop = &soread_filtops; + kn->kn_fop = &soread_filtops; sb = &so->so_rcv; break; case EVFILT_WRITE: @@ -3282,29 +3273,34 @@ static int filt_soread(struct knote *kn, long hint) { - struct socket *so; + struct socket *so = kn->kn_fp->f_data; Style is against mixing declaration and initialization. Please keep the next removed line instead. - so = kn->kn_fp->f_data; This one. - SOCKBUF_LOCK_ASSERT(&so->so_rcv); + if (so->so_options & SO_ACCEPTCONN) { + kn->kn_data = so->so_qlen; + return (!TAILQ_EMPTY(&so->so_comp)); - kn->kn_data = sbavail(&so->so_rcv) - so->so_rcv.sb_ctl; - if (so->so_rcv.sb_state & SBS_CANTRCVMORE) { - kn->kn_flags |= EV_EOF; - kn->kn_fflags = so->so_error; - return (1); - } else if (so->so_error) /* temporary udp error */ - return (1); + } else { You do not need else {} block, 'then' branch ends with return(). If you remove else, you do not need additional indent for the old filt_soread() function' body. + SOCKBUF_LOCK_ASSERT(&so->so_rcv); - if (kn->kn_sfflags & NOTE_LOWAT) { - if (kn->kn_data >= kn->kn_sdata) - return 1; - } else { - if (sbavail(&so->so_rcv) >= so->so_rcv.sb_lowat) - return 1; + kn->kn_data = sbavail(&so->so_rcv) - so->so_rcv.sb_ctl; + if (so->so_rcv.sb_state & SBS_CANTRCVMORE) { + kn->kn_flags |= EV_EOF; + kn->kn_fflags = so->so_error; + return (1); + } else if (so->so_error) /* temporary udp error */ + return (1); + + if (kn->kn_sfflags & NOTE_LOWAT) { + if (kn->kn_data >= kn->kn_sdata) + return 1; return (1); since you change the line anyway. + } else { + if (sbavail(&so->so_rcv) >= so->so_rcv.sb_lowat) + return 1; Same. + } + + /* This hook returning non-zero indicates an event, not error */ + return (hhook_run_socket(so, NULL, HHOOK_FILT_SOREAD)); } - - /* This hook returning non-zero indicates an event, not error */ - return (hhook_run_socket(so, NULL, HHOOK_FILT_SOREAD)); } static void @@ -3346,16 +3342,6 @@ return (kn->kn_data >= so->so_snd.sb_lowat); } -/*ARGSUSED*/ -static int -filt_solisten(struct knote *kn, long hint) -{ - struct socket *so = kn->kn_fp->f_data; - - kn->kn_data = so->so_qlen; - return (!TAILQ_EMPTY(&so->so_comp)); -} - int socheckuid(struct socket *so, uid_t uid) { From owner-freebsd-current@freebsd.org Fri Oct 14 14:51:57 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C395EC11B1B; Fri, 14 Oct 2016 14:51:57 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 31F45FE1; Fri, 14 Oct 2016 14:51:55 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA09302; Fri, 14 Oct 2016 17:51:52 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1bv3ps-000Kvw-37; Fri, 14 Oct 2016 17:51:52 +0300 Subject: Re: SM bus ioctls incorrect in FreeBSD 11 To: Lewis Donzis , freebsd-current@FreeBSD.org, "freebsd-arch@freebsd.org" References: <06929AC5-D350-4236-A813-56C862B58174@perftech.com> From: Andriy Gapon Message-ID: Date: Fri, 14 Oct 2016 17:50:40 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <06929AC5-D350-4236-A813-56C862B58174@perftech.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 14:51:57 -0000 On 14/10/2016 00:39, Lewis Donzis wrote: > After upgrading to FreeBSD 11.0 and changing source code to use the new > version of “struct smbcmd”, some commands are not working as documented, > specifically those that read data. > > As an example, SMB_READW is documented as returning the word read from the > device in rdata.word. However, this doesn’t happen, I think because the > ioctl request value is defined using _IOW(), so the kernel doesn’t copy the > data it read back out. > > In prior versions, the structure had only a pointer to the data, and the > smb.c code used copyout() to transfer the data back to userland. > > As a temporary work-around, we added code to set rbuf to point to rdata.word > and rcount to two. Lewis, thank you for the report. This is a bug indeed and your analysis is correct. Could you please open a bugzilla issue for the bug? https://bugs.freebsd.org/bugzilla/ Looking at ports commit 385155 https://svnweb.freebsd.org/ports/head/sysutils/xmbmon/files/patch-getMB-smb_ioctl.c?r1=385155&r2=385154&pathrev=385155 I see that it also used the approach that you use as a workaround. And that port commit is by Michael Gmelin who made the change to smb.h in r281985 https://svnweb.freebsd.org/base?view=revision&revision=281985 So, I am not sure if the documented approach was known to not work. The src change is described as "Expand SMBUS API ...", but in fact it also _changed_ the existing ioctls. And both binary compatibility and programming compatibility were broken because of how struct smbcmd was changed. In FreeBSD we try to not do that without a very strong reason, but alas. And, as you report, the change was not done entirely correctly. I see several possibilities now. Option 1. Change the documentation to reflect the actual behavior. In this case data.rdata will remain unusable and unused. No interface changes. Option 2. Redefine SMB_READB, SMB_READW and SMB_PCALL ioctls using _IOWR, so that data.rdata could be returned from kernel. This seems like a proper fix, but it is another binary level incompatibility. Option 3. Use a horrible hack to discover a userland address of smbcmd and explicitly copyout to data.rdata. No interface incompatibilities, but it will be a horrible hack. Besides, not sure how feasible it is. Option 4. Revert smb ioctl changes to what they used to be before r281985. Personally, I would prefer this approach. But now that the new interface is in 11.0, it means another interface change just like Option 2. I would like to hear other developers' opinions about this situation. P.S. Two changes that I want to do no matter which course of action we select are: - revert SMB_MAXBLOCKSIZE to 32 - remove SMB_TRANS as it does not map to anything defined by the SMBus specification and it can not be implemented for most, if not all, SMBus controllers -- Andriy Gapon From owner-freebsd-current@freebsd.org Fri Oct 14 15:18:11 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3CD5C11453 for ; Fri, 14 Oct 2016 15:18:11 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 1248D274 for ; Fri, 14 Oct 2016 15:18:10 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: (qmail 23590 invoked by uid 89); 14 Oct 2016 15:11:28 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@194.97.158.70) by mail.grem.de with ESMTPA; 14 Oct 2016 15:11:28 -0000 Date: Fri, 14 Oct 2016 17:11:26 +0200 From: Michael Gmelin To: Andriy Gapon Cc: Lewis Donzis , freebsd-current@FreeBSD.org, "freebsd-arch@freebsd.org" Subject: Re: SM bus ioctls incorrect in FreeBSD 11 Message-ID: <20161014171126.74e6e2fc@bsd64.grem.de> In-Reply-To: References: <06929AC5-D350-4236-A813-56C862B58174@perftech.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd10.2) X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 15:18:11 -0000 On Fri, 14 Oct 2016 17:50:40 +0300 Andriy Gapon wrote: > On 14/10/2016 00:39, Lewis Donzis wrote: > > After upgrading to FreeBSD 11.0 and changing source code to use the > > new version of =E2=80=9Cstruct smbcmd=E2=80=9D, some commands are not w= orking as > > documented, specifically those that read data. > >=20 > > As an example, SMB_READW is documented as returning the word read > > from the device in rdata.word. However, this doesn=E2=80=99t happen, I > > think because the ioctl request value is defined using _IOW(), so > > the kernel doesn=E2=80=99t copy the data it read back out. > >=20 > > In prior versions, the structure had only a pointer to the data, > > and the smb.c code used copyout() to transfer the data back to > > userland. > >=20 > > As a temporary work-around, we added code to set rbuf to point to > > rdata.word and rcount to two. =20 >=20 > Lewis, >=20 > thank you for the report. This is a bug indeed and your analysis is > correct. Could you please open a bugzilla issue for the bug? > https://bugs.freebsd.org/bugzilla/ >=20 > Looking at ports commit 385155 > https://svnweb.freebsd.org/ports/head/sysutils/xmbmon/files/patch-getMB-s= mb_ioctl.c?r1=3D385155&r2=3D385154&pathrev=3D385155 > I see that it also used the approach that you use as a workaround. > And that port commit is by Michael Gmelin who made the change to > smb.h in r281985 > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D281985 So, I > am not sure if the documented approach was known to not work. >=20 > The src change is described as "Expand SMBUS API ...", but in fact it > also _changed_ the existing ioctls. And both binary compatibility > and programming compatibility were broken because of how struct > smbcmd was changed. In FreeBSD we try to not do that without a very > strong reason, but alas. And, as you report, the change was not done > entirely correctly. >=20 > I see several possibilities now. >=20 > Option 1. Change the documentation to reflect the actual behavior. > In this case data.rdata will remain unusable and unused. No > interface changes. >=20 > Option 2. Redefine SMB_READB, SMB_READW and SMB_PCALL ioctls using > _IOWR, so that data.rdata could be returned from kernel. This seems > like a proper fix, but it is another binary level incompatibility. >=20 > Option 3. Use a horrible hack to discover a userland address of > smbcmd and explicitly copyout to data.rdata. No interface > incompatibilities, but it will be a horrible hack. Besides, not sure > how feasible it is. >=20 > Option 4. Revert smb ioctl changes to what they used to be before > r281985. Personally, I would prefer this approach. But now that the > new interface is in 11.0, it means another interface change just like > Option 2. >=20 > I would like to hear other developers' opinions about this situation. >=20 > P.S. > Two changes that I want to do no matter which course of action we > select are: > - revert SMB_MAXBLOCKSIZE to 32 > - remove SMB_TRANS as it does not map to anything defined by the SMBus > specification and it can not be implemented for most, if not all, > SMBus controllers >=20 For some history on these changes, please see also [1] and [2] (there were a few discussions and the revision was bumped, I also tried to get some attention, but not enough it seems). Given your recent changes to iicbus in HEAD, I think it would be best to MFC those and go with Option 4 or, if that's to drastic, go with Option 1. Thanks for cleaning after me. - Michael [1]https://lists.freebsd.org/pipermail/freebsd-arch/2015-March/016972.html [2]https://lists.freebsd.org/pipermail/freebsd-arch/2015-May/017157.html --=20 Michael Gmelin From owner-freebsd-current@freebsd.org Fri Oct 14 15:31:15 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A9162C11838; Fri, 14 Oct 2016 15:31:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A73EBCE7; Fri, 14 Oct 2016 15:31:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA09427; Fri, 14 Oct 2016 18:31:11 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1bv4Rz-000KyQ-Lt; Fri, 14 Oct 2016 18:31:11 +0300 Subject: Re: SM bus ioctls incorrect in FreeBSD 11 To: Michael Gmelin References: <06929AC5-D350-4236-A813-56C862B58174@perftech.com> <20161014171126.74e6e2fc@bsd64.grem.de> Cc: freebsd-current@FreeBSD.org, "freebsd-arch@freebsd.org" From: Andriy Gapon Message-ID: Date: Fri, 14 Oct 2016 18:30:36 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161014171126.74e6e2fc@bsd64.grem.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 15:31:15 -0000 On 14/10/2016 18:11, Michael Gmelin wrote: > For some history on these changes, please see also [1] and [2] (there > were a few discussions and the revision was bumped, I also tried to > get some attention, but not enough it seems). > > Given your recent changes to iicbus in HEAD, I think it would be best to > MFC those and go with Option 4 or, if that's to drastic, go with > Option 1. I am leaning towards this approach as well. > Thanks for cleaning after me. You asked for a discussion and reviews. I can not recall what I was doing at that time, but I completely ignored the development and for that I can only blame myself. > [1]https://lists.freebsd.org/pipermail/freebsd-arch/2015-March/016972.html > [2]https://lists.freebsd.org/pipermail/freebsd-arch/2015-May/017157.html I also agree that having a thin library on top of the ioctl would be a convenience. -- Andriy Gapon From owner-freebsd-current@freebsd.org Fri Oct 14 15:53:18 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8ECABC1021D for ; Fri, 14 Oct 2016 15:53:18 +0000 (UTC) (envelope-from lew@perftech.com) Received: from smtp-gw.pt.net (smtp-gw.pt.net [206.210.194.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp-gw.pt.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 64930FA0 for ; Fri, 14 Oct 2016 15:53:18 +0000 (UTC) (envelope-from lew@perftech.com) X-ASG-Debug-ID: 1476460306-09411a4d54e70f0001-guiu90 Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by smtp-gw.pt.net with ESMTP id s28qEGlHKHnbI0nj (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 14 Oct 2016 10:51:46 -0500 (CDT) X-Barracuda-Envelope-From: lew@perftech.com X-Barracuda-Effective-Source-IP: mail.pt.net[206.210.194.11] X-Barracuda-Apparent-Source-IP: 206.210.194.11 Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 93CC3841DA5; Fri, 14 Oct 2016 10:51:46 -0500 (CDT) Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id sXjNM9tidETp; Fri, 14 Oct 2016 10:51:46 -0500 (CDT) Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 58E06842566; Fri, 14 Oct 2016 10:51:46 -0500 (CDT) X-Virus-Scanned: amavisd-new at pt.net Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id rGGR-kYdDMhc; Fri, 14 Oct 2016 10:51:46 -0500 (CDT) Received: from dhcp-221-110.perftech.com (dhcp-221-110.perftech.com [206.210.221.110]) (Authenticated sender: lew@pt.net) by mail.pt.net (Postfix) with ESMTPSA id 3FCE4841DA5; Fri, 14 Oct 2016 10:51:46 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: SM bus ioctls incorrect in FreeBSD 11 From: Lewis Donzis X-ASG-Orig-Subj: Re: SM bus ioctls incorrect in FreeBSD 11 In-Reply-To: Date: Fri, 14 Oct 2016 10:51:46 -0500 Cc: freebsd-current@FreeBSD.org, "freebsd-arch@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1AA2BB21-0D6D-42F4-9CB2-3CBB00F389C6@perftech.com> References: <06929AC5-D350-4236-A813-56C862B58174@perftech.com> To: Andriy Gapon X-Mailer: Apple Mail (2.3124) X-Barracuda-Connect: mail.pt.net[206.210.194.11] X-Barracuda-Start-Time: 1476460306 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://smtp-gw.pt.net:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 2592 X-Virus-Scanned: by bsmtpd at pt.net X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.33713 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Mailman-Approved-At: Fri, 14 Oct 2016 16:05:36 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 15:53:18 -0000 > On Oct 14, 2016, at 9:50 AM, Andriy Gapon wrote: > Could you please open a bugzilla issue for the bug? > https://bugs.freebsd.org/bugzilla/ Sure, will do. I was unsure of the effectiveness of that, because I = filed a much more serious report about a different issue a couple of = weeks ago and have seen no activity or even acknowledgement. > The src change is described as "Expand SMBUS API ...", but in fact it = also > _changed_ the existing ioctls. And both binary compatibility and = programming > compatibility were broken because of how struct smbcmd was changed. > In FreeBSD we try to not do that without a very strong reason, but = alas. > And, as you report, the change was not done entirely correctly. I was also surprised, but it wasn=E2=80=99t really a big deal, and the = new structure might be slightly easier to use. There have been other = similar things in 11.0, like __mq_oshandle() disappearing, and more .so = files needing to be added to our embedded system, so all things = considered, it=E2=80=99s been reasonably smooth moving from 10.3 to = 11.0. > I see several possibilities now. >=20 > Option 1. Change the documentation to reflect the actual behavior. > In this case data.rdata will remain unusable and unused. No interface = changes. >=20 > Option 2. Redefine SMB_READB, SMB_READW and SMB_PCALL ioctls using = _IOWR, so > that data.rdata could be returned from kernel. This seems like a = proper fix, > but it is another binary level incompatibility. >=20 > Option 3. Use a horrible hack to discover a userland address of = smbcmd and > explicitly copyout to data.rdata. No interface incompatibilities, but = it will > be a horrible hack. Besides, not sure how feasible it is. >=20 > Option 4. Revert smb ioctl changes to what they used to be before = r281985. > Personally, I would prefer this approach. But now that the new = interface is in > 11.0, it means another interface change just like Option 2. >=20 > I would like to hear other developers' opinions about this situation. Our opinion doesn=E2=80=99t count for much, but I like 2 or 4. Option 1 = would essentially obviate the entire purpose of changing the structure. = Option 2 basically finishes the job and makes it work properly. Option = 3 is, as you say, unappealing. I have no problem with Option 4, = obviously we can change our code back to the old way, but assuming there = was a good reason for this change in the first place, Option 2 seems = more logical. But whatever y=E2=80=99all decide is fine with us, we=E2=80=99ll just = change code to match at the appropriate time. Thanks, lew From owner-freebsd-current@freebsd.org Fri Oct 14 16:24:00 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40B1BC1119D for ; Fri, 14 Oct 2016 16:24:00 +0000 (UTC) (envelope-from scott.k.mitch1@gmail.com) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0936CE2C for ; Fri, 14 Oct 2016 16:23:59 +0000 (UTC) (envelope-from scott.k.mitch1@gmail.com) Received: by mail-yb0-x236.google.com with SMTP id 184so44387977yby.2 for ; Fri, 14 Oct 2016 09:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q2B0lQAYKRnepNKPw+4HSbxo9hXKc+Blmou/rJgqkh8=; b=oPbx8ArYBZk+yR7ydC8usch4/otq24DAMK5GcXheEq2+vosCDxwAht9zAMwovaV+K4 IAn23dI821vBPOFbkez/crHwpyHLg/cCp6VOXGHbpAcfbj0ayPG/Ra7SWRZNAOCChQOC ijqX9w6k8XXZTPcxWfiNMEBnwjimsDA/QApj72LBm2zUaSmDl9VSbgYWZBXirWIn7/k5 qRvRxUNc6FkOKhqLGSOYTOqjdsROVdBjUF/0i7sredNEbol3XP6SvcDS32b9UavTfGwR Hm440pZz+43xxf7VKmJk5jkHcpySPrA788fxhVhHG4azr3kvFjUcpcpl31rTA+mqG49c RQ9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q2B0lQAYKRnepNKPw+4HSbxo9hXKc+Blmou/rJgqkh8=; b=VkhGWZzoGkzMDk5XDQh7Bwq/47EbJh0KzfQOMvbCV5hEqw/oD3Da2+H0kYaxl399Bq +gh8LHnJINxF1H9nYPSYSL10AjSPVzb8ld75jWxk1eXSJtuZJtrI0jD55rAWOIeOvZg4 eAj2KbCEAVMEYYa9TcXNyKrYptv0GYvfMJmo0EruX+d1Gw20rReXcTeeFgqY9gw//BTe Laxd/5dA0xujU1sNNfKSH5zlz8XAq2pc3oy7bZRbJjJ4I5UGHod4L6qbKpJ/xj2Wyqb4 B41Wuthfz0jzKICWR9kwcIvRB1fCpoxMy9lUTHzYXBmZQFitiAPHi+NUyDb9Hk0kIEOe EmWg== X-Gm-Message-State: AA6/9RlOAOAjBfFgWMaVjBsi0r/uWhcx7/hybOPcCHXJZN60k8wRBmD4WpdmHxEYNcVZM2YTVmdpMkxm9ObY2A== X-Received: by 10.37.19.136 with SMTP id 130mr10948558ybt.26.1476462239191; Fri, 14 Oct 2016 09:23:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.223.198 with HTTP; Fri, 14 Oct 2016 09:23:58 -0700 (PDT) In-Reply-To: <20161014120333.GB2404@kib.kiev.ua> References: <611243783F62AF48AFB07BC25FA4B1061CE64959@DLREXMBX01.intra.dlr.de> <20161014120333.GB2404@kib.kiev.ua> From: Scott Mitchell Date: Fri, 14 Oct 2016 09:23:58 -0700 Message-ID: Subject: Re: asio and kqueue (2nd trye) (was: RE: (boost::)asio and kqueue problem) To: Konstantin Belousov Cc: Hartmut.Brandt@dlr.de, freebsd-current@freebsd.org, Sepherosa Ziehau , Adrian Chadd X-Mailman-Approved-At: Fri, 14 Oct 2016 16:35:15 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 16:24:00 -0000 Patch generally lgtm ... just 1 nit comment: + } else { + if (sbavail(&so->so_rcv) >= so->so_rcv.sb_lowat) + return 1; + } Collapse the else and the block inside to just make it an `else if` for less branching. On Fri, Oct 14, 2016 at 5:03 AM, Konstantin Belousov wrote: > On Fri, Oct 14, 2016 at 09:21:52AM +0000, Hartmut.Brandt@dlr.de wrote: > > Hi all, > > > > here is the 2nd try taking into account the comments I received. Since > I'm not familiar with the locking in the sockets area I ask somebody with > that knowledge to check it before I commit it. > > I have only style notes, the factual code changes in the patch look good > to me. > > Index: uipc_socket.c > =================================================================== > --- uipc_socket.c (revision 307091) > +++ uipc_socket.c (working copy) > @@ -159,15 +159,9 @@ > static int filt_soread(struct knote *kn, long hint); > static void filt_sowdetach(struct knote *kn); > static int filt_sowrite(struct knote *kn, long hint); > -static int filt_solisten(struct knote *kn, long hint); > static int inline hhook_run_socket(struct socket *so, void *hctx, int32_t > h_id); > fo_kqfilter_t soo_kqfilter; > > -static struct filterops solisten_filtops = { > - .f_isfd = 1, > - .f_detach = filt_sordetach, > - .f_event = filt_solisten, > -}; > static struct filterops soread_filtops = { > .f_isfd = 1, > .f_detach = filt_sordetach, > @@ -3075,10 +3069,7 @@ > > switch (kn->kn_filter) { > case EVFILT_READ: > - if (so->so_options & SO_ACCEPTCONN) > - kn->kn_fop = &solisten_filtops; > - else > - kn->kn_fop = &soread_filtops; > + kn->kn_fop = &soread_filtops; > sb = &so->so_rcv; > break; > case EVFILT_WRITE: > @@ -3282,29 +3273,34 @@ > static int > filt_soread(struct knote *kn, long hint) > { > - struct socket *so; > + struct socket *so = kn->kn_fp->f_data; > Style is against mixing declaration and initialization. Please keep the > next removed line instead. > > - so = kn->kn_fp->f_data; > This one. > > - SOCKBUF_LOCK_ASSERT(&so->so_rcv); > + if (so->so_options & SO_ACCEPTCONN) { > + kn->kn_data = so->so_qlen; > + return (!TAILQ_EMPTY(&so->so_comp)); > > - kn->kn_data = sbavail(&so->so_rcv) - so->so_rcv.sb_ctl; > - if (so->so_rcv.sb_state & SBS_CANTRCVMORE) { > - kn->kn_flags |= EV_EOF; > - kn->kn_fflags = so->so_error; > - return (1); > - } else if (so->so_error) /* temporary udp error */ > - return (1); > + } else { > You do not need else {} block, 'then' branch ends with return(). If you > remove else, you do not need additional indent for the old filt_soread() > function' body. > > + SOCKBUF_LOCK_ASSERT(&so->so_rcv); > > - if (kn->kn_sfflags & NOTE_LOWAT) { > - if (kn->kn_data >= kn->kn_sdata) > - return 1; > - } else { > - if (sbavail(&so->so_rcv) >= so->so_rcv.sb_lowat) > - return 1; > + kn->kn_data = sbavail(&so->so_rcv) - so->so_rcv.sb_ctl; > + if (so->so_rcv.sb_state & SBS_CANTRCVMORE) { > + kn->kn_flags |= EV_EOF; > + kn->kn_fflags = so->so_error; > + return (1); > + } else if (so->so_error) /* temporary udp error */ > + return (1); > + > + if (kn->kn_sfflags & NOTE_LOWAT) { > + if (kn->kn_data >= kn->kn_sdata) > + return 1; > return (1); > since you change the line anyway. > > + } else { > + if (sbavail(&so->so_rcv) >= so->so_rcv.sb_lowat) > + return 1; > Same. > > + } > + > + /* This hook returning non-zero indicates an event, not > error */ > + return (hhook_run_socket(so, NULL, HHOOK_FILT_SOREAD)); > } > - > - /* This hook returning non-zero indicates an event, not error */ > - return (hhook_run_socket(so, NULL, HHOOK_FILT_SOREAD)); > } > > static void > @@ -3346,16 +3342,6 @@ > return (kn->kn_data >= so->so_snd.sb_lowat); > } > > -/*ARGSUSED*/ > -static int > -filt_solisten(struct knote *kn, long hint) > -{ > - struct socket *so = kn->kn_fp->f_data; > - > - kn->kn_data = so->so_qlen; > - return (!TAILQ_EMPTY(&so->so_comp)); > -} > - > int > socheckuid(struct socket *so, uid_t uid) > { > From owner-freebsd-current@freebsd.org Fri Oct 14 18:35:29 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09BE9C122F9; Fri, 14 Oct 2016 18:35:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D697226B; Fri, 14 Oct 2016 18:35:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 8934410AF90; Fri, 14 Oct 2016 14:35:27 -0400 (EDT) From: John Baldwin To: Andriy Gapon Cc: Lewis Donzis , freebsd-current@freebsd.org, "freebsd-arch@freebsd.org" Subject: Re: SM bus ioctls incorrect in FreeBSD 11 Date: Fri, 14 Oct 2016 11:34:45 -0700 Message-ID: <13130323.4rNJusEcix@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-PRERELEASE; KDE/4.14.10; amd64; ; ) In-Reply-To: References: <06929AC5-D350-4236-A813-56C862B58174@perftech.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 14 Oct 2016 14:35:27 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 18:35:29 -0000 On Friday, October 14, 2016 05:50:40 PM Andriy Gapon wrote: > On 14/10/2016 00:39, Lewis Donzis wrote: > > After upgrading to FreeBSD 11.0 and changing source code to use the= new > > version of =E2=80=9Cstruct smbcmd=E2=80=9D, some commands are not w= orking as documented, > > specifically those that read data. > >=20 > > As an example, SMB_READW is documented as returning the word read f= rom the > > device in rdata.word. However, this doesn=E2=80=99t happen, I thin= k because the > > ioctl request value is defined using _IOW(), so the kernel doesn=E2= =80=99t copy the > > data it read back out. > >=20 > > In prior versions, the structure had only a pointer to the data, an= d the > > smb.c code used copyout() to transfer the data back to userland. > >=20 > > As a temporary work-around, we added code to set rbuf to point to r= data.word > > and rcount to two. >=20 > Lewis, >=20 > thank you for the report. This is a bug indeed and your analysis is = correct. > Could you please open a bugzilla issue for the bug? > https://bugs.freebsd.org/bugzilla/ >=20 > Looking at ports commit 385155 > https://svnweb.freebsd.org/ports/head/sysutils/xmbmon/files/patch-get= MB-smb_ioctl.c?r1=3D385155&r2=3D385154&pathrev=3D385155 > I see that it also used the approach that you use as a workaround. > And that port commit is by Michael Gmelin who made the change to smb.= h in > r281985 https://svnweb.freebsd.org/base?view=3Drevision&revision=3D28= 1985 > So, I am not sure if the documented approach was known to not work. >=20 > The src change is described as "Expand SMBUS API ...", but in fact it= also > _changed_ the existing ioctls. And both binary compatibility and pro= gramming > compatibility were broken because of how struct smbcmd was changed. > In FreeBSD we try to not do that without a very strong reason, but al= as. > And, as you report, the change was not done entirely correctly. >=20 > I see several possibilities now. >=20 > Option 1. Change the documentation to reflect the actual behavior. > In this case data.rdata will remain unusable and unused. No interfac= e changes. >=20 > Option 2. Redefine SMB_READB, SMB_READW and SMB_PCALL ioctls using _I= OWR, so > that data.rdata could be returned from kernel. This seems like a pro= per fix, > but it is another binary level incompatibility. >=20 > Option 3. Use a horrible hack to discover a userland address of smbc= md and > explicitly copyout to data.rdata. No interface incompatibilities, bu= t it will > be a horrible hack. Besides, not sure how feasible it is. >=20 > Option 4. Revert smb ioctl changes to what they used to be before r2= 81985. > Personally, I would prefer this approach. But now that the new inter= face is in > 11.0, it means another interface change just like Option 2. >=20 > I would like to hear other developers' opinions about this situation.= >=20 > P.S. > Two changes that I want to do no matter which course of action we sel= ect are: > - revert SMB_MAXBLOCKSIZE to 32 > - remove SMB_TRANS as it does not map to anything defined by the SMBu= s > specification and it can not be implemented for most, if not all, > SMBus controllers During the review the assumption was that breaking the ABI wasn't great= , but that we could always fix it by adding compat handlers for the old ioctl valu= es. If those are needed then they need to be restored. If the new API is usef= ul then it needs to be fixed which I think is option 2. I think it is new enough = to just fix without support compat shims for the broken version of it. Unfortunately I don't know SMBus well enough to comment on your latter = changes, so I will defer to your call on those. --=20 John Baldwin From owner-freebsd-current@freebsd.org Sat Oct 15 08:22:50 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F24AEC11616 for ; Sat, 15 Oct 2016 08:22:50 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B4F852FE for ; Sat, 15 Oct 2016 08:22:50 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bvKEy-002N6x-0C>; Sat, 15 Oct 2016 10:22:48 +0200 Received: from x55b3ada1.dyn.telefonica.de ([85.179.173.161] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bvKEx-003SwN-NG>; Sat, 15 Oct 2016 10:22:47 +0200 Date: Sat, 15 Oct 2016 10:22:42 +0200 From: "O. Hartmann" To: freebsd-current Subject: Re: CURRENT [r307305]: Crashing Message-ID: <20161015102242.3c0f2fbb.ohartman@zedat.fu-berlin.de> In-Reply-To: <20161014104833.7a2ac588@freyja.zeit4.iv.bundesimmobilien.de> References: <20161014104833.7a2ac588@freyja.zeit4.iv.bundesimmobilien.de> Organization: FU Berlin X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/rseq3OP2EzRkRCdYFCL2BEv"; protocol="application/pgp-signature" X-Originating-IP: 85.179.173.161 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2016 08:22:51 -0000 --Sig_/rseq3OP2EzRkRCdYFCL2BEv Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Fri, 14 Oct 2016 10:48:33 +0200 "O. Hartmann" schrieb: > Systems I updated to recent CURRENT start crashing spontaneously. >=20 > recent crashing system is on > 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r307305: Fri Oct 14 08:37:59 CEST 2= 016 >=20 > other (no access since it is remote and not accessible until later the da= y) has > been updated ~ 12 hours ago and it is alos rebooting/crashing without any > warnings. Can be triggered on heavy load. >=20 > Only system with r307263 and stable so far is an older two-socket XEON > Core2Duao based machine, all crashing boxes have CPUs newer or equal than > IvyBridge. >=20 > Does anyone also see these crashes? I tried to compile a debug kernel on = one > host, but that's the remote machine I have access to later, it failed com= piling > the kernel - under load it crashed often. After ZFS scrubbing kickied in,= it > vanished from the net ;-/ >=20 > kind regards, > oh > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Still 307341 is crashing undpredicted ( FreeBSD 12.0-CURRENT #5 r307341: Sa= t Oct 15 09:36:16 CEST 2016). I'm back to r307157, which seems to be "stable". --Sig_/rseq3OP2EzRkRCdYFCL2BEv Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYAedSAAoJEOgBcD7A/5N8fCIH/3g02q2gj1u56/t84uiqdzZ6 VIcPao0YAKCc2IUwSdQVsZ9rCCSzkOnUPnkE8oLAg251Yjn1ZWCs9x3bJQr1NpCh jMNE6HZK2IXHbJK0c50XqL3bsEBOUmr7jdp85mD4QVBI0i0UwdJsWTfZXVy16Maq 8YST2XfXsdsjXZEgXd0x48einqmdqmKe+ESHKt/tuoKIDMFGd7yT6Mt6cmHMISKr Iw2YtSncJT2fIqf9J1mju3exvgTq8Zq3JE1C1irKvI35tr/twfRphcjqWYEpA98x 1MHd40yiLyOvrJtxSJzJwrkUWR0FVjP07KUzb09Mhk6GrOcC5nYp9WAvTgyjSxU= =yfI5 -----END PGP SIGNATURE----- --Sig_/rseq3OP2EzRkRCdYFCL2BEv-- From owner-freebsd-current@freebsd.org Sat Oct 15 10:13:37 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 946FBC11751 for ; Sat, 15 Oct 2016 10:13:37 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 55D647AD for ; Sat, 15 Oct 2016 10:13:36 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bvLy5-002iDx-17>; Sat, 15 Oct 2016 12:13:29 +0200 Received: from x55b3ada1.dyn.telefonica.de ([85.179.173.161] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bvLy4-003aSs-NG>; Sat, 15 Oct 2016 12:13:28 +0200 Date: Sat, 15 Oct 2016 12:13:21 +0200 From: "O. Hartmann" To: freebsd-current Subject: Re: CURRENT [r307305]: Crashing ZFS related? Message-ID: <20161015121321.25007de8.ohartman@zedat.fu-berlin.de> In-Reply-To: <20161015102242.3c0f2fbb.ohartman@zedat.fu-berlin.de> References: <20161014104833.7a2ac588@freyja.zeit4.iv.bundesimmobilien.de> <20161015102242.3c0f2fbb.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/+SUJ1QPoH6T=FE/KUCmz/LZ"; protocol="application/pgp-signature" X-Originating-IP: 85.179.173.161 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2016 10:13:37 -0000 --Sig_/+SUJ1QPoH6T=FE/KUCmz/LZ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sat, 15 Oct 2016 10:22:42 +0200 "O. Hartmann" schrieb: > Am Fri, 14 Oct 2016 10:48:33 +0200 > "O. Hartmann" schrieb: >=20 > > Systems I updated to recent CURRENT start crashing spontaneously. > >=20 > > recent crashing system is on > > 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r307305: Fri Oct 14 08:37:59 CEST= 2016 > >=20 > > other (no access since it is remote and not accessible until later the = day) has > > been updated ~ 12 hours ago and it is alos rebooting/crashing without a= ny > > warnings. Can be triggered on heavy load. > >=20 > > Only system with r307263 and stable so far is an older two-socket XEON > > Core2Duao based machine, all crashing boxes have CPUs newer or equal th= an > > IvyBridge. > >=20 > > Does anyone also see these crashes? I tried to compile a debug kernel o= n one > > host, but that's the remote machine I have access to later, it failed c= ompiling > > the kernel - under load it crashed often. After ZFS scrubbing kickied i= n, it > > vanished from the net ;-/ > >=20 > > kind regards, > > oh > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" =20 >=20 > Still 307341 is crashing undpredicted ( FreeBSD 12.0-CURRENT #5 r307341: = Sat Oct 15 > 09:36:16 CEST 2016). >=20 > I'm back to r307157, which seems to be "stable". >=20 Seems, I'm the only one at the moment having those problems :-( I now have a laptop avalable and start putting debugging options into the k= ernel. But the laptop, so far, doesn't expose the problems of crashes described above. Th= e laptop is the only system so far without ZFS! The most frequent crashing box is a CURRENT server with the largest ZFS vol= ume. When on most recent CURRENT (>r307157, see above), starting a scrubbing on a RAIDZ = volume with ~ 12 TB brutto size AND running a poudriere job, triggers the crash every 1 -= 18 minutes. Another box with only /home as ZFS volume on a dedicated hdd crashes after = minutes or hours. A laptop, also CURRENT (now at r307349) without ZFS is working stabl= e as long as I do not pull the LAN wire (a problem I described also in the list, I try to = capture the screen when crashing right now). --Sig_/+SUJ1QPoH6T=FE/KUCmz/LZ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYAgFBAAoJEOgBcD7A/5N80JgH/jqFqUGx1vZCRocFsoEbPv0T VSDvrYV6HsQ8RX/6Z1YBTyH+dyMZ1M3M39wZdO9qFmdk9nI11IXChOAWaB6mJzvu hHhdq2dAd6Lnz2mZpTxFGiv1n3Bklnm0A9HfUpjMj8yVFCKjFsDXf2l+b/RfendO xYFiaPewHNoZSJiLQtKywZ0Zwf04cpx1TveF4dGVbx2OuG0Ggz4GG2iVaAdZUsIx pFZmlKguMOLBtgs3ZMms4ujtH+w2lj2YW8B5RmXSLcPBRE4uJW5inw38yWDizbj7 7JpKCk28F+iQbwOnoKhcNHZcuIbKDL5Rulpedb5/QiM45bc7PWZiFTTAh4SDHkg= =cSln -----END PGP SIGNATURE----- --Sig_/+SUJ1QPoH6T=FE/KUCmz/LZ-- From owner-freebsd-current@freebsd.org Sat Oct 15 12:01:08 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70183C12CBF for ; Sat, 15 Oct 2016 12:01:08 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 516A8DE0 for ; Sat, 15 Oct 2016 12:01:06 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bvNeC-00310a-UK>; Sat, 15 Oct 2016 14:01:04 +0200 Received: from x55b3ada1.dyn.telefonica.de ([85.179.173.161] helo=hermann) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bvNeA-003iCd-Ar>; Sat, 15 Oct 2016 14:01:04 +0200 Date: Sat, 15 Oct 2016 14:00:59 +0200 From: "Hartmann, O." To: FreeBSD CURRENT Subject: options EFIRT: immediate crash of CURRENT Message-ID: <20161015140059.06f60244@hermann> Organization: FU Berlin MIME-Version: 1.0 X-Originating-IP: 85.179.173.161 X-ZEDAT-Hint: A X-Mailman-Approved-At: Sat, 15 Oct 2016 12:26:06 +0000 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2016 12:01:08 -0000 Playing around with some EFI related options and putting options EFIRT into the kernel config, results in an immediate crash after booting, see screenshot attached. This happens on non-EFI booting systems as well as EFI capable systems. The screenshot is taken from a box with UEFI firmware, but disabled and used via CSM/BIOS, but with option enabled. Regards, oh From owner-freebsd-current@freebsd.org Sat Oct 15 13:21:43 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31DBEC13B76 for ; Sat, 15 Oct 2016 13:21:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CAB66BDB for ; Sat, 15 Oct 2016 13:21:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u9FDLbSo081692 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 15 Oct 2016 16:21:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u9FDLbSo081692 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u9FDLbtb081691; Sat, 15 Oct 2016 16:21:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 15 Oct 2016 16:21:37 +0300 From: Konstantin Belousov To: "Hartmann, O." Cc: FreeBSD CURRENT Subject: Re: options EFIRT: immediate crash of CURRENT Message-ID: <20161015132137.GH2404@kib.kiev.ua> References: <20161015140059.06f60244@hermann> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161015140059.06f60244@hermann> User-Agent: Mutt/1.7.0 (2016-08-17) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2016 13:21:43 -0000 On Sat, Oct 15, 2016 at 02:00:59PM +0200, Hartmann, O. wrote: > > Playing around with some EFI related options and putting > > options EFIRT > > into the kernel config, results in an immediate crash after booting, > see screenshot attached. > > This happens on non-EFI booting systems as well as EFI capable systems. > The screenshot is taken from a box with UEFI firmware, but disabled and > used via CSM/BIOS, but with option enabled. There is no screenshot. Anyway, I have a guess, possibly similar issue was reported already, you might try this patch. diff --git a/sys/amd64/amd64/efirt.c b/sys/amd64/amd64/efirt.c index 4c0454c..4540625 100644 --- a/sys/amd64/amd64/efirt.c +++ b/sys/amd64/amd64/efirt.c @@ -61,7 +61,6 @@ __FBSDID("$FreeBSD$"); static struct efi_systbl *efi_systbl; static struct efi_cfgtbl *efi_cfgtbl; static struct efi_rt *efi_runtime; -static struct cdev *efi_cdev; static int efi_status2err[25] = { 0, /* EFI_SUCCESS */ @@ -403,15 +402,13 @@ efi_init(void) return (ENXIO); } - return (efidev_init(&efi_cdev)); + return (0); } static void efi_uninit(void) { - efidev_uninit(efi_cdev); - efi_destroy_1t1_map(); efi_systbl = NULL; @@ -566,7 +563,6 @@ efirt_modevents(module_t m, int event, void *arg __unused) switch (event) { case MOD_LOAD: return (efi_init()); - break; case MOD_UNLOAD: efi_uninit(); diff --git a/sys/dev/efidev/efidev.c b/sys/dev/efidev/efidev.c index abceec8..d6e0e06 100644 --- a/sys/dev/efidev/efidev.c +++ b/sys/dev/efidev/efidev.c @@ -47,7 +47,6 @@ static struct cdevsw efi_cdevsw = { .d_ioctl = efidev_ioctl, }; -/* ARGSUSED */ static int efidev_ioctl(struct cdev *dev __unused, u_long cmd, caddr_t addr, int flags __unused, struct thread *td __unused) @@ -173,21 +172,45 @@ vs_out: return (error); } -int -efidev_init(struct cdev **cdev) +static struct cdev *efidev; + +static int +efidev_modevents(module_t m, int event, void *arg __unused) { - - *cdev = make_dev(&efi_cdevsw, 0, UID_ROOT, GID_WHEEL, 0700, - "efi"); + struct make_dev_args mda; + int error; + + switch (event) { + case MOD_LOAD: + make_dev_args_init(&mda); + mda.mda_flags = MAKEDEV_WAITOK | MAKEDEV_CHECKNAME; + mda.mda_devsw = &efi_cdevsw; + mda.mda_uid = UID_ROOT; + mda.mda_gid = GID_WHEEL; + mda.mda_mode = 0700; + error = make_dev_s(&mda, &efidev, "efi"); + return (error); + + case MOD_UNLOAD: + if (efidev != NULL) + destroy_dev(efidev); + efidev = NULL; + return (0); + + case MOD_SHUTDOWN: + return (0); - return (0); + default: + return (EOPNOTSUPP); + } } -int -efidev_uninit(struct cdev *cdev) -{ - - destroy_dev(cdev); +static moduledata_t efidev_moddata = { + .name = "efidev", + .evhand = efidev_modevents, + .priv = NULL, +}; - return (0); -} +DECLARE_MODULE(efidev, efidev_moddata, SI_SUB_DEVFS, SI_ORDER_ANY); +MODULE_VERSION(efidev, 1); +MODULE_DEPEND(efidev, efirt, 1, 1, 1); diff --git a/sys/sys/efi.h b/sys/sys/efi.h index 81c6fd3..68fc281 100644 --- a/sys/sys/efi.h +++ b/sys/sys/efi.h @@ -165,9 +165,6 @@ struct efi_systbl { #ifdef _KERNEL extern vm_paddr_t efi_systbl_phys; -struct cdev; -int efidev_init(struct cdev **); -int efidev_uninit(struct cdev *); #endif /* _KERNEL */ #endif /* _SYS_EFI_H_ */ From owner-freebsd-current@freebsd.org Sat Oct 15 16:18:53 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2DF6AC134EB for ; Sat, 15 Oct 2016 16:18:53 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a02:2528:fa:1000::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.spoerlein.net", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B20D1A65 for ; Sat, 15 Oct 2016 16:18:52 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from localhost (acme.spoerlein.net [IPv6:2a02:2528:fa:1000::1]) by acme.spoerlein.net (8.15.2/8.15.2) with ESMTPS id u9FGImI0052077 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 15 Oct 2016 18:18:48 +0200 (CEST) (envelope-from uqs@FreeBSD.org) Date: Sat, 15 Oct 2016 18:18:48 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: freebsd-current@freebsd.org Subject: FreeBSD 11.x grinds to a halt after about 48h of uptime Message-ID: <20161015161848.GD2532@acme.spoerlein.net> Mail-Followup-To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.0 (2016-04-01) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2016 16:18:53 -0000 Hey all, while 11.x is -STABLE now, this happens to my machine ever since I upgraded it to 11-CURRENT years ago. I have no idea when this started, actually, but what always happens is this: - System and X11 is up and running, I keep it running over night as I'm too lazy to reboot and restart everthing. - There's a bunch of xterms, Chrome, Clementine-Player and some other programs running - Coming back to the machine the next day (or the day after) it will exit the screensaver just fine and then either I can use it for a couple of seconds before it freezes, or it's pretty much dead already. The mouse cursor still moves for a bit, but the also freezes (so it this a GPU problem??) Now what I currently see on the screen is a clock widget stuck at 18:04 but conky itself has last updated at 18:00:18 ... This time I had some SSH sessions from another machine to see some more useful things. There was nothing in various logs under /var/log (I also can't run dmesg anymore ...) I had top(1) running in a loop, this is the last output: last pid: 25633; load averages: 0.27, 0.39, 0.36 up 1+23:03:28 18:00:12 202 processes: 2 running, 188 sleeping, 11 zombie, 1 waiting Mem: 8873M Active, 1783M Inact, 5072M Wired, 567M Buf, 132M Free ARC: 1844M Total, 469M MFU, 268M MRU, 16K Anon, 96M Header, 1012M Other Swap: 4096M Total, 2395M Used, 1701M Free, 58% Inuse PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 8 155 ki31 0K 128K CPU0 0 364.6H 772.95% idle 3122 uqs 15 28 0 7113M 5861M uwait 0 94:44 13.96% chrome 2887 uqs 28 22 0 1394M 237M select 2 172:53 6.98% chrome 2890 uqs 11 21 0 1034M 178M select 5 231:21 1.95% chrome 1062 root 9 21 0 440M 47220K select 0 67:09 0.98% Xorg 3002 uqs 15 25 5 1159M 172M uwait 2 19:09 0.00% chrome 3139 uqs 17 25 5 1163M 156M uwait 2 16:15 0.00% chrome 3001 uqs 18 25 5 1639M 575M uwait 0 16:05 0.00% chrome 12 root 24 -64 - 0K 384K WAIT -1 10:53 0.00% intr 3129 uqs 12 20 0 2820M 1746M uwait 6 8:36 0.00% chrome 2822 uqs 9 20 0 217M 81300K select 0 5:10 0.00% conky 3174 root 1 20 0 21532K 3188K select 0 4:20 0.00% systat 3130 uqs 16 20 0 1058M 131M uwait 4 3:03 0.00% chrome 2998 uqs 16 20 0 1110M 123M uwait 2 2:53 0.00% chrome 3165 uqs 10 20 0 1209M 215M uwait 6 2:52 0.00% chrome 3142 uqs 11 25 5 1344M 195M uwait 2 2:46 0.00% chrome 2876 uqs 19 20 0 580M 37164K select 3 2:42 0.00% clementine-player 20 root 2 -16 - 0K 32K psleep 6 2:25 0.00% pagedaemon I also had systat -vm running and it continued to update its screen ... for a short while, this is the last update before SSH died: Mem usage: 0k%Phy 5%Kmem Mem: KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 11051k 67868 71051992 255448 61840 count All 11051k 67924 71058776 262100 pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt ioflt 224 total 25 730 11 724 109 404 101 13 cow 2 ehci0 16 zfod 3 ehci1 23 0.0%Sys 0.1%Intr 0.0%User 0.0%Nice 99.9%Idle ozfod 16 cpu0:timer | | | | | | | | | | %ozfod xhci0 264 daefr 3 em0 265 50 dtbuf prcfr 94 hdac1 266 Namei Name-cache Dir-cache 349167 desvn totfr ahci0 270 Calls hits % hits % 349155 numvn react 5 cpu1:timer 121 121 100 253501 frevn pdwak 1 cpu2:timer pdpgs 29 cpu7:timer Disks md0 ada0 ada1 pass0 pass1 pass2 intrn 12 cpu3:timer KB/t 0.00 0.00 0.00 0.00 0.00 0.00 5318892 wire 41 cpu6:timer tps 0 0 0 0 0 0 9261404 act 12 cpu5:timer MB/s 0.00 0.00 0.00 0.00 0.00 0.00 1598184 inact 6 cpu4:timer %busy 0 0 0 0 0 0 cache vgapci0 61840 free 712304 buf Why do I have a Chrome tab using about 6G? What other sort of debugging output can be helpful to get to the bottom of this? The machine still responds to pings just fine, TCP connections get set up but the SSH handshake never completes. This always happens between 30-50h and is super annoying and has been going on for >1year. Help? Note, I cut the power to the monitor overnight to save electricity, can this mess up something in the Radeon card or X server? What combinations would be most useful to try next? Uli From owner-freebsd-current@freebsd.org Sat Oct 15 16:21:28 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18A32C1367D for ; Sat, 15 Oct 2016 16:21:28 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B631DD39 for ; Sat, 15 Oct 2016 16:21:26 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 40D391FE022 for ; Sat, 15 Oct 2016 18:21:18 +0200 (CEST) Subject: Re: FreeBSD 11.x grinds to a halt after about 48h of uptime To: freebsd-current@freebsd.org References: <20161015161848.GD2532@acme.spoerlein.net> From: Hans Petter Selasky Message-ID: <6926bd72-35c9-cb21-4785-b50a05e581be@selasky.org> Date: Sat, 15 Oct 2016 18:26:16 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20161015161848.GD2532@acme.spoerlein.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2016 16:21:28 -0000 On 10/15/16 18:18, Ulrich Sprlein wrote: > Hey all, while 11.x is -STABLE now, this happens to my machine ever > since I upgraded it to 11-CURRENT years ago. I have no idea when this > started, actually, but what always happens is this: > > - System and X11 is up and running, I keep it running over night as I'm > too lazy to reboot and restart everthing. > - There's a bunch of xterms, Chrome, Clementine-Player and some other > programs running > - Coming back to the machine the next day (or the day after) it will > exit the screensaver just fine and then either I can use it for a couple > of seconds before it freezes, or it's pretty much dead already. The > mouse cursor still moves for a bit, but the also freezes (so it this a > GPU problem??) > > Now what I currently see on the screen is a clock widget stuck at 18:04 > but conky itself has last updated at 18:00:18 ... > > This time I had some SSH sessions from another machine to see some more > useful things. There was nothing in various logs under /var/log (I also > can't run dmesg anymore ...) > I had top(1) running in a loop, this is the last output: > > last pid: 25633; load averages: 0.27, 0.39, 0.36 up 1+23:03:28 18:00:12 > 202 processes: 2 running, 188 sleeping, 11 zombie, 1 waiting > > Mem: 8873M Active, 1783M Inact, 5072M Wired, 567M Buf, 132M Free > ARC: 1844M Total, 469M MFU, 268M MRU, 16K Anon, 96M Header, 1012M Other > Swap: 4096M Total, 2395M Used, 1701M Free, 58% Inuse > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 11 root 8 155 ki31 0K 128K CPU0 0 364.6H 772.95% idle 3122 uqs 15 28 0 7113M 5861M uwait 0 94:44 13.96% chrome 2887 uqs 28 22 0 1394M 237M select 2 172:53 6.98% chrome 2890 uqs 11 21 0 1034M 178M select 5 231:21 1.95% chrome 1062 root 9 21 0 440M 47220K select 0 67:09 0.98% Xorg 3002 uqs 15 25 5 1159M 172M uwait 2 19:09 0.00% chrome > 3139 uqs 17 25 5 1163M 156M uwait 2 16:15 0.00% chrome > 3001 uqs 18 25 5 1639M 575M uwait 0 16:05 0.00% chrome > 12 root 24 -64 - 0K 384K WAIT -1 10:53 0.00% intr > 3129 uqs 12 20 0 2820M 1746M uwait 6 8:36 0.00% chrome > 2822 uqs 9 20 0 217M 81300K select 0 5:10 0.00% conky > 3174 root 1 20 0 21532K 3188K select 0 4:20 0.00% systat > 3130 uqs 16 20 0 1058M 131M uwait 4 3:03 0.00% chrome > 2998 uqs 16 20 0 1110M 123M uwait 2 2:53 0.00% chrome > 3165 uqs 10 20 0 1209M 215M uwait 6 2:52 0.00% chrome > 3142 uqs 11 25 5 1344M 195M uwait 2 2:46 0.00% chrome > 2876 uqs 19 20 0 580M 37164K select 3 2:42 0.00% clementine-player > 20 root 2 -16 - 0K 32K psleep 6 2:25 0.00% pagedaemon > > I also had systat -vm running and it continued to update its screen ... > for a short while, this is the last update before SSH died: > > > Mem usage: 0k%Phy 5%Kmem > Mem: KB REAL VIRTUAL VN PAGER SWAP PAGER > Tot Share Tot Share Free in out in out > Act 11051k 67868 71051992 255448 61840 count > All 11051k 67924 71058776 262100 pages > Proc: Interrupts > r p d s w Csw Trp Sys Int Sof Flt ioflt 224 total > 25 730 11 724 109 404 101 13 cow 2 ehci0 16 > zfod 3 ehci1 23 > 0.0%Sys 0.1%Intr 0.0%User 0.0%Nice 99.9%Idle ozfod 16 cpu0:timer > | | | | | | | | | | %ozfod xhci0 264 > daefr 3 em0 265 > 50 dtbuf prcfr 94 hdac1 266 > Namei Name-cache Dir-cache 349167 desvn totfr ahci0 270 > Calls hits % hits % 349155 numvn react 5 cpu1:timer > 121 121 100 253501 frevn pdwak 1 cpu2:timer > pdpgs 29 cpu7:timer > Disks md0 ada0 ada1 pass0 pass1 pass2 intrn 12 cpu3:timer > KB/t 0.00 0.00 0.00 0.00 0.00 0.00 5318892 wire 41 cpu6:timer > tps 0 0 0 0 0 0 9261404 act 12 cpu5:timer > MB/s 0.00 0.00 0.00 0.00 0.00 0.00 1598184 inact 6 cpu4:timer > %busy 0 0 0 0 0 0 cache vgapci0 > 61840 free > 712304 buf > > > Why do I have a Chrome tab using about 6G? What other sort of debugging > output can be helpful to get to the bottom of this? The machine still > responds to pings just fine, TCP connections get set up but the SSH > handshake never completes. > > This always happens between 30-50h and is super annoying and has been > going on for >1year. Help? > > Note, I cut the power to the monitor overnight to save electricity, can > this mess up something in the Radeon card or X server? What combinations > would be most useful to try next? > Hi, Sounds like a memory leak. Can you track the memory use over time? Did you look at the output from: vmstat -m ? --HPS From owner-freebsd-current@freebsd.org Sat Oct 15 16:36:29 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58DEDC139A3 for ; Sat, 15 Oct 2016 16:36:29 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 03215766 for ; Sat, 15 Oct 2016 16:36:29 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-ua0-x22b.google.com with SMTP id m11so6497332uab.3 for ; Sat, 15 Oct 2016 09:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bwrNM9ih4F0+Pk8EsUo6y2BXEy9RtPipiNIS0adZlfU=; b=I7P8+JK8mVYDBcKihktFe8eWoR0yrZRKEYxfb/63+AE3Qy+C+KozIWR2DMRP4JvQrw Vn5t0rhz8HvZ1uYhjCw2Yq+gNh05Fj+GqGr4+SjXrBioY018fJoJyY6YPcIJq59oLj2y 2j09SC+gjjIYpMNdpj/FRiQ5JOL5+QE5WV4wbPjyX1oGZVaeUG89Lcy7g2p3oSUtBOqV IwBqnYJdHLx/1FmdP8UJ427GM/Kt48uyid4ZEsqcfH7hJbKmzRUnmVWam7ZRXUiIV4Kj 0ccyklgW4tg1rGkxtnM3d58U2dbeiWSINVAj/I0IOSz+VYDtMvwtoQK2UwnrhZg4OH+m 2dVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=bwrNM9ih4F0+Pk8EsUo6y2BXEy9RtPipiNIS0adZlfU=; b=jmcVCIrgJtjIpEHJ7mwiWXdFe0NcSOIR6vL5gMlhzRJ4Q8lfh670l869rS6639bAF7 E9TUmvEh3vuUZDU7TFZafSIpb80kMK++N3prvZNjSOBmXnh8DDJPFV3wmPf8lOHwkbvU KX+7ogRbBjBvHRQPxo+FNldMo315+j52t6sJNJu6hoVeVgDV+FKSggaB3aCzlDP/Qxfj j2yRwqh5+LtCDM6RrUH1bicHtpzVtcHNy6dUgbn0hSTL2738fh7IuCY6BSNoYQhI3NtP NrT0Ahs2BLMJ/Eh3IRWpELg8PC+vkhlGINf/TJBXmRotdKjLtPOjRiTvGsOV7b/U/9vr HQ5w== X-Gm-Message-State: AA6/9RmIP2dcmxhBTBtrVWMAs1dfioOSVGRpzWBARAg2LTQvoKHLvrxH5iufalV0MpMKeRBIkuQGlPPvNCAT0Q== X-Received: by 10.176.81.219 with SMTP id h27mr1609870uaa.65.1476549388118; Sat, 15 Oct 2016 09:36:28 -0700 (PDT) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.103.118.78 with HTTP; Sat, 15 Oct 2016 09:36:27 -0700 (PDT) In-Reply-To: <6926bd72-35c9-cb21-4785-b50a05e581be@selasky.org> References: <20161015161848.GD2532@acme.spoerlein.net> <6926bd72-35c9-cb21-4785-b50a05e581be@selasky.org> From: Kevin Oberman Date: Sat, 15 Oct 2016 09:36:27 -0700 X-Google-Sender-Auth: CzbgWghvG1ALHI-zTXTsU0phcL0 Message-ID: Subject: Re: FreeBSD 11.x grinds to a halt after about 48h of uptime To: Hans Petter Selasky Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2016 16:36:29 -0000 On Sat, Oct 15, 2016 at 9:26 AM, Hans Petter Selasky wrote: > On 10/15/16 18:18, Ulrich Sp=C3=B6rlein wrote: > >> Hey all, while 11.x is -STABLE now, this happens to my machine ever >> since I upgraded it to 11-CURRENT years ago. I have no idea when this >> started, actually, but what always happens is this: >> >> - System and X11 is up and running, I keep it running over night as I'm >> too lazy to reboot and restart everthing. >> - There's a bunch of xterms, Chrome, Clementine-Player and some other >> programs running >> - Coming back to the machine the next day (or the day after) it will >> exit the screensaver just fine and then either I can use it for a couple >> of seconds before it freezes, or it's pretty much dead already. The >> mouse cursor still moves for a bit, but the also freezes (so it this a >> GPU problem??) >> >> Now what I currently see on the screen is a clock widget stuck at 18:04 >> but conky itself has last updated at 18:00:18 ... >> >> This time I had some SSH sessions from another machine to see some more >> useful things. There was nothing in various logs under /var/log (I also >> can't run dmesg anymore ...) >> I had top(1) running in a loop, this is the last output: >> >> last pid: 25633; load averages: 0.27, 0.39, 0.36 up 1+23:03:28 >> 18:00:12 >> 202 processes: 2 running, 188 sleeping, 11 zombie, 1 waiting >> >> Mem: 8873M Active, 1783M Inact, 5072M Wired, 567M Buf, 132M Free >> ARC: 1844M Total, 469M MFU, 268M MRU, 16K Anon, 96M Header, 1012M Other >> Swap: 4096M Total, 2395M Used, 1701M Free, 58% Inuse >> >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >> COMMAND >> 11 root 8 155 ki31 0K 128K CPU0 0 364.6H 772.95% >> idle >> 3122 uqs 15 28 0 7113M 5861M uwait 0 >> 94:44 13.96% chrome >> 2887 uqs 28 22 0 1394M 237M >> select 2 172:53 6.98% chrome >> 2890 uqs 11 21 0 >> 1034M 178M select 5 231:21 1.95% chrome >> 1062 root = 9 >> 21 0 440M 47220K select 0 67:09 0.98% Xorg >> 3002 uqs >> 15 25 5 1159M 172M uwait 2 19:09 0.00% chrome >> 3139 uqs 17 25 5 1163M 156M uwait 2 16:15 0.00% >> chrome >> 3001 uqs 18 25 5 1639M 575M uwait 0 16:05 0.00% >> chrome >> 12 root 24 -64 - 0K 384K WAIT -1 10:53 0.00% >> intr >> 3129 uqs 12 20 0 2820M 1746M uwait 6 8:36 0.00% >> chrome >> 2822 uqs 9 20 0 217M 81300K select 0 5:10 0.00% >> conky >> 3174 root 1 20 0 21532K 3188K select 0 4:20 0.00% >> systat >> 3130 uqs 16 20 0 1058M 131M uwait 4 3:03 0.00% >> chrome >> 2998 uqs 16 20 0 1110M 123M uwait 2 2:53 0.00% >> chrome >> 3165 uqs 10 20 0 1209M 215M uwait 6 2:52 0.00% >> chrome >> 3142 uqs 11 25 5 1344M 195M uwait 2 2:46 0.00% >> chrome >> 2876 uqs 19 20 0 580M 37164K select 3 2:42 0.00% >> clementine-player >> 20 root 2 -16 - 0K 32K psleep 6 2:25 0.00% >> pagedaemon >> >> I also had systat -vm running and it continued to update its screen ... >> for a short while, this is the last update before SSH died: >> >> >> Mem usage: 0k%Phy 5%Kmem >> Mem: KB REAL VIRTUAL VN PAGER SWAP >> PAGER >> Tot Share Tot Share Free in out in >> out >> Act 11051k 67868 71051992 255448 61840 count >> All 11051k 67924 71058776 262100 pages >> Proc: >> Interrupts >> r p d s w Csw Trp Sys Int Sof Flt ioflt 224 >> total >> 25 730 11 724 109 404 101 13 cow 2 >> ehci0 16 >> zfod 3 >> ehci1 23 >> 0.0%Sys 0.1%Intr 0.0%User 0.0%Nice 99.9%Idle ozfod 16 >> cpu0:timer >> | | | | | | | | | | %ozfod >> xhci0 264 >> daefr 3 em= 0 >> 265 >> 50 dtbuf prcfr 94 >> hdac1 266 >> Namei Name-cache Dir-cache 349167 desvn totfr >> ahci0 270 >> Calls hits % hits % 349155 numvn react 5 >> cpu1:timer >> 121 121 100 253501 frevn pdwak 1 >> cpu2:timer >> pdpgs 29 >> cpu7:timer >> Disks md0 ada0 ada1 pass0 pass1 pass2 intrn 12 >> cpu3:timer >> KB/t 0.00 0.00 0.00 0.00 0.00 0.00 5318892 wire 41 >> cpu6:timer >> tps 0 0 0 0 0 0 9261404 act 12 >> cpu5:timer >> MB/s 0.00 0.00 0.00 0.00 0.00 0.00 1598184 inact 6 >> cpu4:timer >> %busy 0 0 0 0 0 0 cache >> vgapci0 >> 61840 free >> 712304 buf >> >> >> Why do I have a Chrome tab using about 6G? What other sort of debugging >> output can be helpful to get to the bottom of this? The machine still >> responds to pings just fine, TCP connections get set up but the SSH >> handshake never completes. >> >> This always happens between 30-50h and is super annoying and has been >> going on for >1year. Help? >> >> Note, I cut the power to the monitor overnight to save electricity, can >> this mess up something in the Radeon card or X server? What combinations >> would be most useful to try next? >> >> > Hi, > > Sounds like a memory leak. Can you track the memory use over time? > > Did you look at the output from: > > vmstat -m ? > > --HPS I have noted significant memory leakage in chromium for some time. If I leave it running overnight, my system is essentially frozen. If I terminate the chromium process, it slowly comes back to life. I always keep a gkrellm session on-screen where the memory and swap utilization is continuously displayed and that clearly shows resources declining. Try closing your chromium at night and see if that fixes the problem. If you have never tried gkrellm (sysutils/gkrellm2), it is a the best system monitor I have found. though pulls in a lot of dependencies. It also can run as a server with remote systems displaying the data. Handy to monitor servers. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-current@freebsd.org Sat Oct 15 19:17:21 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86C62C138F8 for ; Sat, 15 Oct 2016 19:17:21 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A1EE89C for ; Sat, 15 Oct 2016 19:17:21 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by mail-lf0-x229.google.com with SMTP id b75so220068776lfg.3 for ; Sat, 15 Oct 2016 12:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xf0oxVGv6F4Zd/xsov/PwyQxHc/uYapjwA08s2QvyZg=; b=QulIWwbtUFnLA+q3H3Aj4+Yb5DyHudaJMSKnhFop51lQh+KwdRHmcJq6XkHnhXSj2r r7qW2nUBSOPKrLJTKSLMxI+aYFUKDnwy5J4Je9aXHh77xOPbtng9LfeC7iDbsUW4k5Am Y6htg862klliZmZP/T7ksAJngHO7viT9BdsPs6GMxjL17Y1YRhrgnB8xOfFEemp5jlvK CIDp5vVJx3eKYy+MLyVSlPh9iGBrFBmp9F76NPB/6DjdIm1YHqiFn97si5a5AnhA6fHW vLrUzXzjKs51WKT//pNPliFFnAGf8ILLtXjj4XFWU7TxChI0GDWhi+tByFR/YgZ1RH6M 7thw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xf0oxVGv6F4Zd/xsov/PwyQxHc/uYapjwA08s2QvyZg=; b=hmCOEcIVikAthdL3Gxv4Bv80iRCG66Qb7k6hqXpidV+XmEb3b/g5/ZVW1A/YgGsibP pCNfZ7EicBx4IFuNFXreRyGb1yOu0jWMOLEY0tEYHzxoC+knYUDrJvp0OZGwz5rE8eBs KhbHVuID92bwerkwMvVNIrt/Qsi602G6B/UZbtFHWV4W1A23mHEiGbTVywnuuawsiKrn w245mbL2xLtV1LUbTMqDpaoUy13WfUtf+eT/DkZ8g+Ll+P60E0KCxgk5vfjM082RxsKc HEb48aXV24J6HMmlECxdaFlinqITUPQ0T+y0Jo8WClyOJcVfzHYlzpmX3dfsa2vXMIHv PsLQ== X-Gm-Message-State: AA6/9RnyQ8FfZzjpbU49InPsHX+qRjshb3TRCz8QdgBxiA+J4mgPOEa+6R0R5dyabGKjN6XMi6DzSYnOyJrCMw== X-Received: by 10.25.89.70 with SMTP id n67mr7622983lfb.163.1476559038688; Sat, 15 Oct 2016 12:17:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.37.147 with HTTP; Sat, 15 Oct 2016 12:17:17 -0700 (PDT) In-Reply-To: References: <20161015161848.GD2532@acme.spoerlein.net> <6926bd72-35c9-cb21-4785-b50a05e581be@selasky.org> From: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= Date: Sat, 15 Oct 2016 21:17:17 +0200 Message-ID: Subject: Re: FreeBSD 11.x grinds to a halt after about 48h of uptime To: Kevin Oberman Cc: Hans Petter Selasky , FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 15 Oct 2016 20:33:06 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2016 19:17:21 -0000 2016-10-15 18:36 GMT+02:00 Kevin Oberman : > > On Sat, Oct 15, 2016 at 9:26 AM, Hans Petter Selasky > wrote: > > > On 10/15/16 18:18, Ulrich Sp=C3=B6rlein wrote: > > > >> Hey all, while 11.x is -STABLE now, this happens to my machine ever > >> since I upgraded it to 11-CURRENT years ago. I have no idea when this > >> started, actually, but what always happens is this: > >> > >> - System and X11 is up and running, I keep it running over night as I'= m > >> too lazy to reboot and restart everthing. > >> - There's a bunch of xterms, Chrome, Clementine-Player and some other > >> programs running > >> - Coming back to the machine the next day (or the day after) it will > >> exit the screensaver just fine and then either I can use it for a coup= le > >> of seconds before it freezes, or it's pretty much dead already. The > >> mouse cursor still moves for a bit, but the also freezes (so it this a > >> GPU problem??) > >> > >> Now what I currently see on the screen is a clock widget stuck at 18:0= 4 > >> but conky itself has last updated at 18:00:18 ... > >> > >> This time I had some SSH sessions from another machine to see some mor= e > >> useful things. There was nothing in various logs under /var/log (I als= o > >> can't run dmesg anymore ...) > >> I had top(1) running in a loop, this is the last output: > >> > >> last pid: 25633; load averages: 0.27, 0.39, 0.36 up 1+23:03:28 > >> 18:00:12 > >> 202 processes: 2 running, 188 sleeping, 11 zombie, 1 waiting > >> > >> Mem: 8873M Active, 1783M Inact, 5072M Wired, 567M Buf, 132M Free > >> ARC: 1844M Total, 469M MFU, 268M MRU, 16K Anon, 96M Header, 1012M Othe= r > >> Swap: 4096M Total, 2395M Used, 1701M Free, 58% Inuse > >> > >> > >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCP= U > >> COMMAND > >> 11 root 8 155 ki31 0K 128K CPU0 0 364.6H 772.95= % > >> idle > >> 3122 uqs 15 28 0 7113M 5861M uwait 0 > >> 94:44 13.96% chrome > >> 2887 uqs 28 22 0 1394M 23= 7M > >> select 2 172:53 6.98% chrome > >> 2890 uqs 11 21 0 > >> 1034M 178M select 5 231:21 1.95% chrome > >> 1062 root = 9 > >> 21 0 440M 47220K select 0 67:09 0.98% Xorg > >> 3002 uqs > >> 15 25 5 1159M 172M uwait 2 19:09 0.00% chrome > >> 3139 uqs 17 25 5 1163M 156M uwait 2 16:15 0.00= % > >> chrome > >> 3001 uqs 18 25 5 1639M 575M uwait 0 16:05 0.00= % > >> chrome > >> 12 root 24 -64 - 0K 384K WAIT -1 10:53 0.00= % > >> intr > >> 3129 uqs 12 20 0 2820M 1746M uwait 6 8:36 0.00= % > >> chrome > >> 2822 uqs 9 20 0 217M 81300K select 0 5:10 0.00= % > >> conky > >> 3174 root 1 20 0 21532K 3188K select 0 4:20 0.00= % > >> systat > >> 3130 uqs 16 20 0 1058M 131M uwait 4 3:03 0.00= % > >> chrome > >> 2998 uqs 16 20 0 1110M 123M uwait 2 2:53 0.00= % > >> chrome > >> 3165 uqs 10 20 0 1209M 215M uwait 6 2:52 0.00= % > >> chrome > >> 3142 uqs 11 25 5 1344M 195M uwait 2 2:46 0.00= % > >> chrome > >> 2876 uqs 19 20 0 580M 37164K select 3 2:42 0.00= % > >> clementine-player > >> 20 root 2 -16 - 0K 32K psleep 6 2:25 0.00= % > >> pagedaemon > >> > >> I also had systat -vm running and it continued to update its screen ..= . > >> for a short while, this is the last update before SSH died: > >> > >> > >> Mem usage: 0k%Phy 5%Kmem > >> Mem: KB REAL VIRTUAL VN PAGER SWA= P > >> PAGER > >> Tot Share Tot Share Free in out i= n > >> out > >> Act 11051k 67868 71051992 255448 61840 count > >> All 11051k 67924 71058776 262100 pages > >> Proc: > >> Interrupts > >> r p d s w Csw Trp Sys Int Sof Flt ioflt 224 > >> total > >> 25 730 11 724 109 404 101 13 cow 2 > >> ehci0 16 > >> zfod 3 > >> ehci1 23 > >> 0.0%Sys 0.1%Intr 0.0%User 0.0%Nice 99.9%Idle ozfod 16 > >> cpu0:timer > >> | | | | | | | | | | %ozfod > >> xhci0 264 > >> daefr 3 = em0 > >> 265 > >> 50 dtbuf prcfr 94 > >> hdac1 266 > >> Namei Name-cache Dir-cache 349167 desvn totfr > >> ahci0 270 > >> Calls hits % hits % 349155 numvn react 5 > >> cpu1:timer > >> 121 121 100 253501 frevn pdwak 1 > >> cpu2:timer > >> pdpgs 29 > >> cpu7:timer > >> Disks md0 ada0 ada1 pass0 pass1 pass2 intrn 12 > >> cpu3:timer > >> KB/t 0.00 0.00 0.00 0.00 0.00 0.00 5318892 wire 41 > >> cpu6:timer > >> tps 0 0 0 0 0 0 9261404 act 12 > >> cpu5:timer > >> MB/s 0.00 0.00 0.00 0.00 0.00 0.00 1598184 inact 6 > >> cpu4:timer > >> %busy 0 0 0 0 0 0 cache > >> vgapci0 > >> 61840 free > >> 712304 buf > >> > >> > >> Why do I have a Chrome tab using about 6G? What other sort of debuggin= g > >> output can be helpful to get to the bottom of this? The machine still > >> responds to pings just fine, TCP connections get set up but the SSH > >> handshake never completes. > >> > >> This always happens between 30-50h and is super annoying and has been > >> going on for >1year. Help? > >> > >> Note, I cut the power to the monitor overnight to save electricity, ca= n > >> this mess up something in the Radeon card or X server? What combinatio= ns > >> would be most useful to try next? > >> > >> > > Hi, > > > > Sounds like a memory leak. Can you track the memory use over time? Memory leak or not, it shouldn't lock up the whole system just the minute/second that I start using it again. > > > > > Did you look at the output from: > > > > vmstat -m ? No, but I'll capture it for the next cycle :) > > > > > --HPS > > > I have noted significant memory leakage in chromium for some time. If I > leave it running overnight, my system is essentially frozen. If I termina= te > the chromium process, it slowly comes back to life. I always keep a gkrel= lm > session on-screen where the memory and swap utilization is continuously > displayed and that clearly shows resources declining. > > Try closing your chromium at night and see if that fixes the problem. > > If you have never tried gkrellm (sysutils/gkrellm2), it is a the best > system monitor I have found. though pulls in a lot of dependencies. It al= so > can run as a server with remote systems displaying the data. Handy to > monitor servers. I'll try w/o Chrome, it's easy to stop and restart anyway. I'll be back in a week or so :) Uli