From owner-freebsd-hackers@freebsd.org Sun Dec 3 06:48:37 2017 Return-Path: Delivered-To: freebsd-hackers@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 D7221DF0C2D for ; Sun, 3 Dec 2017 06:48:37 +0000 (UTC) (envelope-from ingegneriaforense@alice.it) Received: from smtp301.alice.it (smtp301.alice.it [82.57.200.117]) by mx1.freebsd.org (Postfix) with ESMTP id 6F47D6DF6F for ; Sun, 3 Dec 2017 06:48:37 +0000 (UTC) (envelope-from ingegneriaforense@alice.it) Received: from feu22-alice (82.57.204.77) by smtp301.alice.it (8.6.060.43) id 5A1260FA00A581DC for freebsd-hackers@freebsd.org; Sun, 3 Dec 2017 07:48:30 +0100 Received: from (185.87.69.18) by webmail22a.pc.tim.it; Sun, 3 Dec 2017 07:48:30 +0100 Message-ID: <1601b22242a.ingegneriaforense@alice.it> Date: Sun, 3 Dec 2017 07:48:30 +0100 (CET) From: "ingegneriaforense@alice.it" Reply-To: "ingegneriaforense@alice.it" To: freebsd-hackers@freebsd.org Subject: USB_ERR_IOERR: a proposal solution Mime-Version: 1.0 X-Originating-IP: 185.87.69.18:51334 X-Priority: 1 (Highest) Importance: high Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 06:48:37 -0000 During the freebsd installation I receive some messages: >> usbd_req_re_enumerate: addre=3, set address failed (USB_ERR_IOERROR, ignored) >> usbd_setup_device_desc: getting device descriptor at addr 3 failed, >> USB_ERR_IOERROR ugen0.3: at usbus0 (disconnected) >> uhub_reattach_port: could not allocate new device These messages appear during the whole installation process overwriting the monitor and this also happen when the sysinstall windows are shown. THE SOLUTION: To solve this tedious problem i've disabled in the BIOS the "USB 1.1 OHCI Controllers" that prevent the "USB Legacy" option. No devices I have plugged in the USB ports (I've used old PS/2 keyboard and mouse). THE QUESTION: please, can you tell me what this means ? It means the HUB is unable to enumerate some device, because it is not responding correctly to the USB tokens the host controller is sending. But for an hardware problem or maybe the Freebsd kernel does'n support the USB Legacy ? Thanks in advance. Vincenzo.During the freebsd installation I receive some messages: >> usbd_req_re_enumerate: addre=3, set address failed (USB_ERR_IOERROR, ignored) >> usbd_setup_device_desc: getting device descriptor at addr 3 failed, >> USB_ERR_IOERROR ugen0.3: at usbus0 (disconnected) >> uhub_reattach_port: could not allocate new device These messages appear during the whole installation process overwriting the monitor and this also happen when the sysinstall windows are shown. THE SOLUTION: To solve this tedious problem i've disabled in the BIOS the "USB 1.1 OHCI Controllers" that prevent the "USB Legacy" option. No devices I have plugged in the USB ports (I've used old PS/2 keyboard and mouse). THE QUESTION: please, can you tell me what this means ? It means the HUB is unable to enumerate some device, because it is not responding correctly to the USB tokens the host controller is sending. But for an hardware problem or maybe the Freebsd kernel does'n support the USB Legacy ? Thanks in advance. Vincenzo. Forensic Consultant Tribunale di Lecce Studio: Strada di Garibaldi - Contrada Paradisi 73010 Lequile (LE) cell: 339.7968555 skype: vincenzo.di_salvo From owner-freebsd-hackers@freebsd.org Sun Dec 3 16:48:56 2017 Return-Path: Delivered-To: freebsd-hackers@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 12047DFFB6C for ; Sun, 3 Dec 2017 16:48:56 +0000 (UTC) (envelope-from ingegneriaforense@alice.it) Received: from smtp303.alice.it (smtp303.alice.it [82.57.200.119]) by mx1.freebsd.org (Postfix) with ESMTP id 7F1927DFAC for ; Sun, 3 Dec 2017 16:48:55 +0000 (UTC) (envelope-from ingegneriaforense@alice.it) Received: from feu18-alice (82.57.204.73) by smtp303.alice.it (8.6.060.43) id 59C3C0C401E373ED for freebsd-hackers@freebsd.org; Sun, 3 Dec 2017 17:48:48 +0100 Received: from (151.45.22.251) by webmail18c.pc.tim.it; Sun, 3 Dec 2017 17:48:48 +0100 Message-ID: <1601d47bad7.ingegneriaforense@alice.it> Date: Sun, 3 Dec 2017 17:48:48 +0100 (CET) From: "ingegneriaforense@alice.it" Reply-To: "ingegneriaforense@alice.it" To: freebsd-hackers@freebsd.org Subject: how to create image for usb stick from iso Mime-Version: 1.0 X-Originating-IP: 151.45.22.251:49316 X-Priority: 1 (Highest) Importance: high Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 16:48:56 -0000 Hello guys, i'm trying to create a bootable usbstick from the iso file: FreeBSD-12.0-CURRENT-i386-20171130-r326378-memstick To do this, I've installed Win32DiskImager on my laptop with windows 7. However when the process finish my laptop show the blu desktop informing windows crash. Please, can you tell me in which a way I can do a bootable usbstick ? No problem if I create a bootable DVD. Thanks very much in advance. Vincenzo. Forensic Consultant Tribunale di Lecce Studio: Strada di Garibaldi - Contrada Paradisi 73010 Lequile (LE) cell: 339.7968555 skype: vincenzo.di_salvo ----Messaggio originale---- Da: ingegneriaforense@alice.it Data: 3-dic-2017 7.48 A: Ogg: USB_ERR_IOERR: a proposal solution During the freebsd installation I receive some messages: >> usbd_req_re_enumerate: addre=3, set address failed (USB_ERR_IOERROR, ignored) >> usbd_setup_device_desc: getting device descriptor at addr 3 failed, >> USB_ERR_IOERROR ugen0.3: at usbus0 (disconnected) >> uhub_reattach_port: could not allocate new device These messages appear during the whole installation process overwriting the monitor and this also happen when the sysinstall windows are shown. THE SOLUTION: To solve this tedious problem i've disabled in the BIOS the "USB 1.1 OHCI Controllers" that prevent the "USB Legacy" option. No devices I have plugged in the USB ports (I've used old PS/2 keyboard and mouse). THE QUESTION: please, can you tell me what this means ? It means the HUB is unable to enumerate some device, because it is not responding correctly to the USB tokens the host controller is sending. But for an hardware problem or maybe the Freebsd kernel does'n support the USB Legacy ? Thanks in advance. Vincenzo.During the freebsd installation I receive some messages: >> usbd_req_re_enumerate: addre=3, set address failed (USB_ERR_IOERROR, ignored) >> usbd_setup_device_desc: getting device descriptor at addr 3 failed, >> USB_ERR_IOERROR ugen0.3: at usbus0 (disconnected) >> uhub_reattach_port: could not allocate new device These messages appear during the whole installation process overwriting the monitor and this also happen when the sysinstall windows are shown. THE SOLUTION: To solve this tedious problem i've disabled in the BIOS the "USB 1.1 OHCI Controllers" that prevent the "USB Legacy" option. No devices I have plugged in the USB ports (I've used old PS/2 keyboard and mouse). THE QUESTION: please, can you tell me what this means ? It means the HUB is unable to enumerate some device, because it is not responding correctly to the USB tokens the host controller is sending. But for an hardware problem or maybe the Freebsd kernel does'n support the USB Legacy ? Thanks in advance. Vincenzo. Forensic Consultant Tribunale di Lecce Studio: Strada di Garibaldi - Contrada Paradisi 73010 Lequile (LE) cell: 339.7968555 skype: vincenzo.di_salvo _______________________________________________ freebsd-hackers@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Sun Dec 3 17:13:57 2017 Return-Path: Delivered-To: freebsd-hackers@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 A9641E56F65 for ; Sun, 3 Dec 2017 17:13:57 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 70B6D7F428 for ; Sun, 3 Dec 2017 17:13:57 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: by mail-oi0-x22e.google.com with SMTP id 184so10243316oii.2 for ; Sun, 03 Dec 2017 09:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=TsW4ex1hawdXMpUcg3TOiW4x2E1jb/6ZXWRH6hKEYRo=; b=JzozVMC0zdGB6SG+VYd8CrPPP8ZJMvgcwG0JPR0pmyhGky5uXn3zA/rymfdOVD25cf E5XAuc3mZlIkzDn2zenut3da6xV+qdbOidEszWUHsYuityFDgsWVYP2p+2MvJpFQMK/N EUG1i39Yiabp0yVC+czB/d7F14sf7+rXF9egv6/kZcMiI0XSgjo453RRzRLG20YP38Kw lPV9BDipBsqfLyZc2rLGP7L4gBvlg5zblQ5KdcekWTQQFl47iRJjIvCChNC9daXpJS8c 0xEH+13orbkwSRfIeNf+wHg08cP+pt+ILyhGWkksrPxq/+frgdDSfsuSHaiuevthjyT7 M7JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TsW4ex1hawdXMpUcg3TOiW4x2E1jb/6ZXWRH6hKEYRo=; b=JnRhlmPv3kbR7ide/bvqO72MI1rh7+CaVpNionIYlW39Osmlc+RNvVMh6ZM6oGbXMB min9LLnau1en1nudfIyHSkK8y1QRmbArYZ1H1yVO+WV/ucyte/jls0oBHi5/+AUgU+pi 1ARWfOLrqRallljn5MSR+g4k0B7dNDLSGaf2jG7FbBuBAj5YpzXM+lMJfghlqC/eHb5V lpsuYdbvMdy6KaA27WWvHOdctfbTZzrOqfUhm1Fn1zCUNjlD7Yo8hkmxWfb5AyLxCTc8 8+Y3c9/YHEuS3NsnB2Q6xQoV29clF6hdlOs2HJsUN2lcIhAmVCA2qdeWQP9OdkNLI4m7 mPpg== X-Gm-Message-State: AJaThX7XczqE7FyKG7vGZYu7/ZTnQ6pBD/gKsD6qANRj1ISbD0iJdhtV kuvr2nSmHEvkYcgPjaZKkhtVQl7L40CZw4Y4HMtIYBlS X-Google-Smtp-Source: AGs4zMYxz+q/hos3xutCm8I02j01HBOsA1ZLd/MAHgqG4dSfJuFA5wvHpy41gnqztTWJJk87DHfCJ4MP9emRN2v5RBg= X-Received: by 10.202.73.134 with SMTP id w128mr11622222oia.11.1512321236630; Sun, 03 Dec 2017 09:13:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.47 with HTTP; Sun, 3 Dec 2017 09:13:16 -0800 (PST) From: Lee D Date: Sun, 3 Dec 2017 12:13:16 -0500 Message-ID: Subject: How do I make my device driver respond to lseek? To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 17:13:57 -0000 Hi, I've been trying to figure out how to make my device driver respond to lseek(). There doesn't seem to be an appropriate entry in the cdevsw structure (in src/sys/sys/conf.h). Obviously I can make an ioctl() call for this (and I have, in the interim), but I'd like to do it it the right way. I have a feeling like I am misunderstanding some critical abstraction layer... But at some point the device driver must be told what position to start reading from/writing to, right? FWIW, this is a device driver interface to a SPI flash in my custom ARM embedded system. I need to be able to locate to a point in the flash to read and write my app config info, without disturbing my boot loader. I want to be able to write code like this: int fd = open ("/dev/my_spi_flash0", O_RDWR); lseek(fd, 0x10000, SEEK_SET); write(fd, buf, 100); close(fd); Does anyone know the proper way to implement lseek? From owner-freebsd-hackers@freebsd.org Sun Dec 3 17:32:11 2017 Return-Path: Delivered-To: freebsd-hackers@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 47E1BE5790E for ; Sun, 3 Dec 2017 17:32:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 D219B7FD0B for ; Sun, 3 Dec 2017 17:32:10 +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 vB3HW5oZ003768 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 3 Dec 2017 19:32:06 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua vB3HW5oZ003768 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id vB3HW52B003767; Sun, 3 Dec 2017 19:32:05 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 3 Dec 2017 19:32:05 +0200 From: Konstantin Belousov To: Lee D Cc: freebsd-hackers@freebsd.org Subject: Re: How do I make my device driver respond to lseek? Message-ID: <20171203173205.GL2272@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) 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-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 17:32:11 -0000 On Sun, Dec 03, 2017 at 12:13:16PM -0500, Lee D wrote: > Hi, > > I've been trying to figure out how to make my device driver respond to > lseek(). There doesn't seem to be an appropriate entry in the cdevsw > structure (in src/sys/sys/conf.h). > > Obviously I can make an ioctl() call for this (and I have, in the > interim), but I'd like to do it it the right way. > > I have a feeling like I am misunderstanding some critical abstraction > layer... But at some point the device driver must be told what > position to start reading from/writing to, right? > > FWIW, this is a device driver interface to a SPI flash in my custom > ARM embedded system. I need to be able to locate to a point in the > flash to read and write my app config info, without disturbing my boot > loader. > > I want to be able to write code like this: > > int fd = open ("/dev/my_spi_flash0", O_RDWR); > lseek(fd, 0x10000, SEEK_SET); > write(fd, buf, 100); > close(fd); > > Does anyone know the proper way to implement lseek? You did not say which driver you implement. It could be devfs cdev, with only supported d_read/d_write methods. In this case, io request parameters are packed into struct uio, including the offset where io starts. Or you might implement it as proper block-oriented device by providing d_strategy. Then struct bio contains the block number. Or your driver might be geom disk, see geom/geom_disk.h, in which case disk_strategy method takes struct bio as well. Last reasonable variant is to have driver implementing CAM SIM, then sim_action processes ccb's, also holding all needed information about io request parameters. From owner-freebsd-hackers@freebsd.org Sun Dec 3 22:53:19 2017 Return-Path: Delivered-To: freebsd-hackers@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 016FCE6AF2C for ; Sun, 3 Dec 2017 22:53:19 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::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 B79966D191 for ; Sun, 3 Dec 2017 22:53:18 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: by mail-ot0-x22b.google.com with SMTP id s4so13271595ote.4 for ; Sun, 03 Dec 2017 14:53:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ofaUXsI0sl7e2RotCQt2CrphjHE7Q1TDV5Y8mnTt7DM=; b=PoNjMj+hEd7K3m7NarYKKFhnbi2TX+I4fV5G5ojRWfxrMX5fo3ZiZD9P7zs2/OZ/w1 8uRd00nJ7ftI3400OAYOvZqu0Q0bJEZwVme5SGvEm3uiq/h5qOuNh5EU/ELOxPI/jFCa 9dmo7tuFggrzMfsT9TJUw4jIGE/czLSUe7XNNjWq4AgT13yfp/B7xR+Af/+bzOXlPsT0 0YovwMZJRqxV+DEpCeBFDixOpsDAvKrbLr3hVyXuGxeK+3eiuRFFtId/o9E32ouKOAMw srGmhqFnaEJ8T4126ghwVNrCjrVuS3s48MfZLVTXnzcmw528gYeXDjkCjSxAN6YV6CMi /TMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ofaUXsI0sl7e2RotCQt2CrphjHE7Q1TDV5Y8mnTt7DM=; b=sStLtl+I9L+6SLkfMWo8Lnxpvk++niffGlDLrDotygjcIf7j6PLGy7sIGvQJpWux/Y a/PZ1Hm6F+ZdQ8/wVfx+DcCOS33gmxamJ3mFrwF7eNbdbb+JpSsa+lYvXrCz8Y4gZPO3 heslVhUdhIJnoo8m1Q67AXOUTEDox+qiipT1dlh2FU27fWLU40ujNpU7oUONea6tSs5p O50Qvy/2Bmo1X6IlOUaF/V7QbKe8ZL1kWnkQV/uB/H8wASdo1Mwd+aKYuKcK4/9t86Db S+aNBX5vLNIVTlo+WC3aIM4YVc1TZPCUw0nUQQKCS4DpJ3HC2lsoEYQCjjBflBErYh3F IuUQ== X-Gm-Message-State: AJaThX5jYv/X92ftHTm3qPXntJD//QeGmgN74umEmMphCqvgX806UeS2 rGCcL6HGfF0SuLyYnzkPPHNULhidmE5o6V3u9BU= X-Google-Smtp-Source: AGs4zMbeCSOKkq0Vme+tY0ZN35vRHywREtWMc+zjB4nHJP6Y67nY0xN1URN56dwiKVXvpG71o7tHwFT5ltI9rnENfTI= X-Received: by 10.157.42.9 with SMTP id t9mr14435025ota.233.1512341597847; Sun, 03 Dec 2017 14:53:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.47 with HTTP; Sun, 3 Dec 2017 14:52:37 -0800 (PST) In-Reply-To: <20171203173205.GL2272@kib.kiev.ua> References: <20171203173205.GL2272@kib.kiev.ua> From: Lee D Date: Sun, 3 Dec 2017 17:52:37 -0500 Message-ID: Subject: Re: How do I make my device driver respond to lseek? To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 22:53:19 -0000 On Sun, Dec 3, 2017 at 12:32 PM, Konstantin Belousov wrote: > On Sun, Dec 03, 2017 at 12:13:16PM -0500, Lee D wrote: >> Hi, >> >> I've been trying to figure out how to make my device driver respond to >> lseek(). There doesn't seem to be an appropriate entry in the cdevsw >> structure (in src/sys/sys/conf.h). >> >> Obviously I can make an ioctl() call for this (and I have, in the >> interim), but I'd like to do it it the right way. >> >> I have a feeling like I am misunderstanding some critical abstraction >> layer... But at some point the device driver must be told what >> position to start reading from/writing to, right? >> >> FWIW, this is a device driver interface to a SPI flash in my custom >> ARM embedded system. I need to be able to locate to a point in the >> flash to read and write my app config info, without disturbing my boot >> loader. >> >> I want to be able to write code like this: >> >> int fd = open ("/dev/my_spi_flash0", O_RDWR); >> lseek(fd, 0x10000, SEEK_SET); >> write(fd, buf, 100); >> close(fd); >> >> Does anyone know the proper way to implement lseek? > > You did not say which driver you implement. > > It could be devfs cdev, with only supported d_read/d_write methods. In > this case, io request parameters are packed into struct uio, including > the offset where io starts. > > Or you might implement it as proper block-oriented device by providing > d_strategy. Then struct bio contains the block number. > > Or your driver might be geom disk, see geom/geom_disk.h, in which case > disk_strategy method takes struct bio as well. > > Last reasonable variant is to have driver implementing CAM SIM, then > sim_action processes ccb's, also holding all needed information about > io request parameters. It is a devfs cdev, which is what I am using for everything. uio->uio_offset is exactly what I was looking for. My driver now works perfectly with lseek. thanks! From owner-freebsd-hackers@freebsd.org Sun Dec 3 23:34:42 2017 Return-Path: Delivered-To: freebsd-hackers@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 E931EE6BE23 for ; Sun, 3 Dec 2017 23:34:42 +0000 (UTC) (envelope-from rozhuk.im@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 6AEC86E517 for ; Sun, 3 Dec 2017 23:34:42 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-lf0-x229.google.com with SMTP id f20so17180533lfe.3 for ; Sun, 03 Dec 2017 15:34:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=L+5eC4eoPXgUT7ATguuIyh9qwsMU4mbt9QxhOzottg4=; b=b7CP0yfuEcQwQ4AZND85kYCs2GoQeYBYpB3VlBDfz/Jj2tfMO0N3+C6r8lLDFSJK0s E9+PWcDpuebIurYSz+ovumO8REiDs7SYvFJD1+Hla/4epftAMF3tiILJsInvMF2P5upm oU4rqMc3G9zZbdkeDEXWmNrfJRdt4MvODS7a2FCRnJz06CvdP4AXZql0KB/7otZRYFaG kSxm0guiT/wb5M0Ui+XO//eEGoYaJMos5HtmLz/tUlZorty1I34E8sGCas7QnRSJXxmd /Cpn5lNrBMdXf2XpGW/Dy7aTvoAuv2j8WPWR4iXe4Sjwv1AaCHQHRy1mpDMTrpzkQX/o odRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=L+5eC4eoPXgUT7ATguuIyh9qwsMU4mbt9QxhOzottg4=; b=ci9wlTDxyVyCRhIprxyi/8gBqGdJi126rhptsQ32U+fmfpCEzd8+CjXKzQLmh97clb Tz81wAD0cbeIXvQ75/mvs+tQbcVwqhJGSnI/t30IJB95uMgCW2EzIkArUQK4ai+23B8a PNczh2xztrWHGKqGDCqLOhiZ2McTrsp20At49UNWPWAgjJ4hyfyvWGLFIDULXyIa//H4 2CrgKH41OkmpwLXB6xbsIPxiMN7WTeIr6MYXUzrPckr+8wer0oxat7GZMA8Beb5W6eHF EGldpIP0gtnBIxBRna4LSqhjN8hURK+Gu5QAcq9dG0yrnfYn4iwukdTOE2cXrj/MqUei Tdpw== X-Gm-Message-State: AJaThX6ThEBIcEMJjLmSR2s1BxT4GwkZNiP9q1iIPzFzQnLHfip5rVcw A/KGP+ymX3XB4NKp8tvEyhk0ww== X-Google-Smtp-Source: AGs4zMacEfw438kKYgMPkZ9gozXiddK/akToHhQQ22avm0rdOm6xnmEFcpWGkiPjf+7zvoqMDWTXug== X-Received: by 10.46.2.17 with SMTP id 17mr8979624ljc.67.1512344080193; Sun, 03 Dec 2017 15:34:40 -0800 (PST) Received: from localhost ([185.44.68.92]) by smtp.gmail.com with ESMTPSA id o21sm2089064lff.64.2017.12.03.15.34.39 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 03 Dec 2017 15:34:39 -0800 (PST) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Mon, 4 Dec 2017 02:33:12 +0300 To: "ingegneriaforense@alice.it" Cc: freebsd-hackers@freebsd.org Subject: Re: how to create image for usb stick from iso Message-ID: <20171204023312.25ba8579@gmail.com> In-Reply-To: <1601d47bad7.ingegneriaforense@alice.it> References: <1601d47bad7.ingegneriaforense@alice.it> X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 23:34:43 -0000 On Sun, 3 Dec 2017 17:48:48 +0100 (CET) "ingegneriaforense@alice.it" wrote: > i'm trying to create a bootable usbstick from the iso file: > > FreeBSD-12.0-CURRENT-i386-20171130-r326378-memstick > > To do this, I've installed Win32DiskImager on my laptop with windows > 7. However when the process finish my laptop show the blu desktop > informing windows crash. > > Please, can you tell me in which a way I can do a bootable usbstick ? > > No problem if I create a bootable DVD. > This will not work. I need create GPT on flash drive, then add loaders, add UFS partition, make new fs and copy all files from CD/DVD to it. Then you need edit /etc/fstab. From owner-freebsd-hackers@freebsd.org Mon Dec 4 00:43:28 2017 Return-Path: Delivered-To: freebsd-hackers@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 29375E6E65D for ; Mon, 4 Dec 2017 00:43:28 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (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 DC63370E9F for ; Mon, 4 Dec 2017 00:43:27 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: by mail-yb0-x22c.google.com with SMTP id b73so2526692yba.6 for ; Sun, 03 Dec 2017 16:43:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=R6eNZ0TJzy0/BnpWkXEBnYbGk+GyTY5BBshcGIQxnJU=; b=RyPvs29bg25Fex8tmiEiGfRGKf/09IUeNM9T1jlx4kaBU/11wnbb/4HZr2aD32Fikx qXvd0EE+ZIrobLT2kR08SJLpKqXT7kg31K8KDq9LTaw8gbiNt6rr8oXeZDFz68u5CWXI cPRqJAMiqlDlRo4HDquOa+TXDqF2b82UmF04TYft57GjXx9k99LaDLSbNWq40xXMRONc M4/C62hczhEhVrOPZt64CohQms9o36ttRXVFK++MUeVok6Gl8zpdf7T7yK0AMvx1j4T3 TNWkU1pK6SoNHWA87C1+okG2yxhYdBfGwcT5PdvAYy+Pl1UGonHy/DjpHJAc+DPrtcue dYhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=R6eNZ0TJzy0/BnpWkXEBnYbGk+GyTY5BBshcGIQxnJU=; b=T0xFGAClMpWSbSt5fqnbN1mXR708HvBwngkJ/ahEvseoHFOcdTMCtExxrI8GRRKDgy ANJNFAo9sGiPSwgTCM2DunfuDWCBD6ZaFnBiAsEvuMvnoUvwZB4KObqtD8KpVtRXdWpV ggSKzXacbxPSJ7g4ADEpQkuGxedzFXsONK24P1TpCRXboUHoMftZKORJLgod+pakPO3h SI1ehSc4Mk1w9WhfXBItCdfDRQDHR92bMBpcewSbRpA6eJd4H0qJbK/RD7fm4UNg9hDr 7lwc7LBkbm5e7WTpByNPhhqiYN9uhgCOVuPy46s2JVfY7kFVHEV2azeoNP78QcwXr0ju d9JQ== X-Gm-Message-State: AJaThX6+NWEUug2T/LXEqnwgsNNmDIy11A1qn+7IFZO4rlflZd6tcFL+ cD6RPg2e5vMMHv+WpaUwmhw31HZ+yBd9IP5m2mnOig== X-Google-Smtp-Source: AGs4zMbclVk1xIO1VFsHJl5D72eQYL1KmaKAoAYobWQuFiKnnhjHAdbE5mQc363fErN8e/oehy0wXtaJksn5cDABLb0= X-Received: by 10.37.20.193 with SMTP id 184mr8121127ybu.400.1512348206823; Sun, 03 Dec 2017 16:43:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.186.147 with HTTP; Sun, 3 Dec 2017 16:43:06 -0800 (PST) From: Farhan Khan Date: Sun, 3 Dec 2017 19:43:06 -0500 Message-ID: Subject: where ifconfig's socket binds to the interface? To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 00:43:28 -0000 Hi all, Does anyone know where in ifconfig(8)'s source it opens a socket and connects that to the specified interface? I see the socket(2) call in /usr/src/sbin/ifconfig/ifconfig.c. The while-loop at 767 seems to iterate through each command. But I can't seem to locate where it connects that socket(2) to the provided interface. Any ideas? Thanks! -- Farhan Khan PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE From owner-freebsd-hackers@freebsd.org Mon Dec 4 00:59:36 2017 Return-Path: Delivered-To: freebsd-hackers@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 CECC1E6ECFD for ; Mon, 4 Dec 2017 00:59:36 +0000 (UTC) (envelope-from matt.joras@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 648C37165A for ; Mon, 4 Dec 2017 00:59:36 +0000 (UTC) (envelope-from matt.joras@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id g75so3040091wme.0 for ; Sun, 03 Dec 2017 16:59:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3WlVgUxHVWvBH9CjaJEi/n/Rn38tDS806ABl4X8xN7A=; b=X0RChM5VLvkRdD+GyVBhnRzVzmrwfC7cjbiLGrrLWOun10fMAiCo8DeW2HuDO1ckAE h/tsSCN87EsbqXr1pSau15k/WnXSFtavGCc8qe+/IKF9DbUvQq1GdHOc2INArln+rt4/ pjMVb5JrnEX/n97uRWLFsffuA35K1tSUfFITUWO8ZtuTOeLQXY33DiRd8HwC83mGUtkd g9AYQiGcET3JJX7jeBblV9VcyX4SULky4CgGYOhr1/88JN+G/oo1wlgaOgHlz2bgN0eg e1Dl2OoLU1baM8Xvr0diyri5HiJKyMDfyLIPA/siZEHw1diSPXxl/3H3D+FxYAAwalK/ rWJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3WlVgUxHVWvBH9CjaJEi/n/Rn38tDS806ABl4X8xN7A=; b=KUXMKCAv7n/R6sysiJ9OwgQcRcqmeHFKVe5RBp54Rijf9dtcG7M8DDsIWnVU62nolb 1SInT0nKEDiA51q6eNZXeBx8WhzhhdAbfQOSuxe+9s63k+we98cQNpiFissbLnCfOgdY Lh4cFYrQKGddSznEcEsdlBtf1Qz7SyYI8AOwfPv3EzdWUCNqDeGhgEp6GOAsMBc5wyzI 1RcPeWrx+Ey7NGgh5YkJSltzfO66C0xib8nxz2txY0qc0Ypa6oy5mCVnnapOcrYFTt9L OFA9eEyxE/rB3BfMbkP5GVtBgUKT6AErBm3c65UbnOqnazNrro4teZ94rMZj/pzVZvR+ Xhqg== X-Gm-Message-State: AKGB3mIhHibT8bDY97cSNhSvGb5UAT/17eOQRdLPORysgrBfpZybSc+/ 1WlaicFDby6yt+EuvPt0E3Xx2K5F/ZpB5XEgm/9IUQ== X-Google-Smtp-Source: AGs4zMb7GGpet+jAJR9m/vjTV64n4sgb8Mykq+AIj2Y4GqnjyrsBnyna5Mw48AZPA979TPK1Nd5eUflz2wrQutEr+3M= X-Received: by 10.28.187.133 with SMTP id l127mr1473952wmf.128.1512349173742; Sun, 03 Dec 2017 16:59:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.196.9 with HTTP; Sun, 3 Dec 2017 16:59:33 -0800 (PST) In-Reply-To: References: From: Matt Joras Date: Sun, 3 Dec 2017 16:59:33 -0800 Message-ID: Subject: Re: where ifconfig's socket binds to the interface? To: Farhan Khan Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Mon, 04 Dec 2017 02:08:52 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 00:59:36 -0000 On Sun, Dec 3, 2017 at 4:43 PM, Farhan Khan wrote: > Hi all, > > Does anyone know where in ifconfig(8)'s source it opens a socket and > connects that to the specified interface? I see the socket(2) call in > /usr/src/sbin/ifconfig/ifconfig.c. The while-loop at 767 seems to iterate > through each command. But I can't seem to locate where it connects that > socket(2) to the provided interface. > > Any ideas? > Thanks! > > -- > Farhan Khan > PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE There is no notion of "connecting" to an interface with the socket opened by ifconfig(8). The socket in question is used as the parameter to the various ioctl(2) calls. See e.g. the setifmtu function for an example usage. Matt Joras From owner-freebsd-hackers@freebsd.org Mon Dec 4 02:45:45 2017 Return-Path: Delivered-To: freebsd-hackers@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 BEB1EDBAD20 for ; Mon, 4 Dec 2017 02:45:45 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: from mail-yw0-x243.google.com (mail-yw0-x243.google.com [IPv6:2607:f8b0:4002:c05::243]) (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 7A14374CB7 for ; Mon, 4 Dec 2017 02:45:45 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: by mail-yw0-x243.google.com with SMTP id w128so6157420ywa.1 for ; Sun, 03 Dec 2017 18:45:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=yf1Myj4/D9mofwQX733M4HyY89u6IhfyxxbpJeB/26k=; b=UV+8glI2JI6h4lRUqjfyoZRIPX4uXSnVRT2Ok/xJvi94TAEWJYJeYRWrHk+MZMMsI7 YtCI3fNnPkcqXfoC80wkooBoHAFuKNSH+xW45bhZgaDQQOu5uOePQGzeZKltyKe8U2mr CvFi1cR7c4Ezc++8YwZIn85NzxtRHJoI7yh0l4mvyOuxuUk+jl7mjsklB8uvTU9SI/gF NSvuAtfEBileNmRBeMakTJXlyetpRBjXWKce4CLrCRlnI4DxWyxRDAZQAqXb5ja8H0vj 5qvYrJsDxCwJdggoauZJFCfvEP0oLlXEGg4U9CIVUt7292lFUgm0uEQhNMMwo58qof2t 8B4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=yf1Myj4/D9mofwQX733M4HyY89u6IhfyxxbpJeB/26k=; b=AcLz8olE9jqpyV36fUCw/yhGS1HHmE0hkemBoYzrFCbY65q6TErFQ6pbxGwSzjM9hb 1Ymj1CTrNDZnZW5fR+RTQ/7+iluMAGDUakWXEEcej2Na2f9bQbAKwUooy9Xzl73HseQ/ ZhsDIGe+oTwmm02mOZ7jE0nedX/DVrerPZ2/ZdL/jCnS4m5mZteH7TBDad4g9ZUXgU51 NUr7GhRsdZ5FJC0AAB6oBfwuu2UVsl2Ej1da8YMCWT2XxNhXL1s/k7WoX55m6N62hhub lqWq1kY01Zu8slHll225/KNh+znjuYNyrXXle2wgE4ApKlanM9w6MU+U61+UpX9Cd2V0 gFLw== X-Gm-Message-State: AJaThX5/ngQ60Z+VsqC4h/72gV1t7q1nMUk+H2GGnVk0DCP7cO9P0pkE pFOuSvTDBlWH+Tbn9+ZjsW6rPnH+5pjRk9mL/T4PRg== X-Google-Smtp-Source: AGs4zMbynM9iJ+aVFDFT8Wz1BpA/v5XIrQXQ2EmisGd2IPc0uu3lv1/boHy5VsF0b9MGJIfkRSU4WIgGU3mkEG8LYcs= X-Received: by 10.129.90.65 with SMTP id o62mr9136725ywb.462.1512355544361; Sun, 03 Dec 2017 18:45:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.186.147 with HTTP; Sun, 3 Dec 2017 18:45:24 -0800 (PST) In-Reply-To: References: From: Farhan Khan Date: Sun, 3 Dec 2017 21:45:24 -0500 Message-ID: Subject: Re: where ifconfig's socket binds to the interface? Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 02:45:45 -0000 I reviewed this about 6 months ago and had forgotten it took place there as an ioctl(2) argument. Thank you for reminding me! -- Farhan Khan PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE On Sun, Dec 3, 2017 at 7:59 PM, Matt Joras wrote: > On Sun, Dec 3, 2017 at 4:43 PM, Farhan Khan wrote: > > Hi all, > > > > Does anyone know where in ifconfig(8)'s source it opens a socket and > > connects that to the specified interface? I see the socket(2) call in > > /usr/src/sbin/ifconfig/ifconfig.c. The while-loop at 767 seems to > iterate > > through each command. But I can't seem to locate where it connects that > > socket(2) to the provided interface. > > > > Any ideas? > > Thanks! > > > > -- > > Farhan Khan > > PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE > There is no notion of "connecting" to an interface with the socket > opened by ifconfig(8). The socket in question is used as the parameter > to the various ioctl(2) calls. See e.g. the setifmtu function for an > example usage. > > Matt Joras > From owner-freebsd-hackers@freebsd.org Mon Dec 4 06:16:43 2017 Return-Path: Delivered-To: freebsd-hackers@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 4DDB5DEF4D5 for ; Mon, 4 Dec 2017 06:16:43 +0000 (UTC) (envelope-from yuripv@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD4347A451 for ; Mon, 4 Dec 2017 06:16:42 +0000 (UTC) (envelope-from yuripv@gmx.com) Received: from thor.xvoid.org ([85.173.23.68]) by mail.gmx.com (mrgmx002 [212.227.17.184]) with ESMTPSA (Nemesis) id 0LjIel-1ewj6K0UbX-00dWWm for ; Mon, 04 Dec 2017 07:16:35 +0100 Subject: Re: Getting PRs fixed To: freebsd-hackers References: <201712011318.vB1DIk4E069397@donotpassgo.dyslexicfish.net> From: Yuri Pankov Message-ID: Date: Mon, 4 Dec 2017 09:16:34 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:aUcJxJSwz7gWvzWJWgR5qnpxhrI5UhaXJWRS7aEGuyghGXXzhcH b2gNw/BtJjDGiUaUNGKtNDlhHXQZ0BiEbu0luXT86b9sXGb8ay3oW9DoZFGofIvQhnvvJ3n 6DUhnqmy/86WpRLDUGoSyTqk8+MsIhg6TLH2R4/4ebGpR+7SPfE5ir7fzv797TZC8lez0xa dbXnG7OdXhmqTzyG3/iYA== X-UI-Out-Filterresults: notjunk:1;V01:K0:3oC0LUkdnAI=:kszLk/snzUsDI/TM6CDv+m WmwRjz0rBoWHVTrYoeZJ6NuX6Fk9OvtP9sJ35UeJmSPXwcFnA8CYY3yFAfM5PiCYW9/lRNeLS NMQt+8TM8zMsVHmInD0tSuNGSvd9ydZ6W3gKNwZdMjyvnuRBFsDkpTeL46u1WfhlapK/USN5J QD9U9/KRbFxlSr6RyMuuyN6e6toKHzTTTr7ZuX+awNCOOxLXQZJRef5UbyI1Nc9moSHFVpd0+ XD8wtvwpon1jQGu2mTAYRze4BgxxYdU8mRtBpAFcGcDfYRZU1zy2/482V0ta5PyzUJ+CzrtuG dYb9y0RjoQ8ipY2+nlw2GYHeO95FHm5chl/4BmROY1VSMHRLTitm8tihwt0ZnB+shKzvranNe keagraeFZSqWu3OqQrB7QhtFGfw1vvWpgtQUqNJKvCzzoJIwCpWzB0Ej2LRdcrmaHJPPhpjXD q9wYJzoR7p2ZXCuF2Mzu6rnVgfhgzg9A59NpGRuCL7BXohr95puWN3gWsqQf10XC16jNypF89 VcrSAf6Fs2c6su6E1ZzT+GFquLyPgSOvAmQ5aH2f/Hx0L+0sevBV6wvF6+Cbo7LInlUd5889m Y0h/xMjYHnB8pLg/bYsFWBSUkD0FEJtPw/k56SSI5U7jaYW/0WQnGXOWy5MI777EBSq/wVta0 9dJGBr7NhXTll6G6X4Uq7UhsbrDKW15o3IJyeAw0xSO74BO8WJzH7CGWQQaq6sxZGxQsh/jNW ZTa+FnQVenYU9m0Fi51DdI2r4csWEjpAaufkMrynA1nwF1WpAAbVBG/g3R458n8yRFV3ccdr7 mR0bgiRQPFXhJxbqtMHQAMWiytFKj48a8axdRactnhoUHRlnv4= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 06:16:43 -0000 On Fri, Dec 1, 2017 at 09:39:22AM -0800, Freddie Cash wrote: > On Fri, Dec 1, 2017 at 6:46 AM, Rebecca Cran wrote: > >> >>> On Dec 1, 2017, at 6:18 AM, Jamie Landeg-Jones >> wrote: >>> >>> I've been using FreeBSD both professionally and personally since >>> 2.2.7-RELEASE and I've fixed various bugs over the years, but a year or >>> so ago, I got fed up with the general indifference these last few years. >> >> I was just thinking about getting back into bug-busting for FreeBSD: a few >> years ago when we were using GNATS we had a team that did triage, >> follow-ups etc. that made some progress. Was that effort wound-down with >> the move to Bugzilla, or is the team still active? >> > > ​I don't know about triage, as in determining priority for specific bugs, > but there is a team that goes through the bug database assigning bugs to > individuals and teams, and updating the Subject: line to better reflect the > issue in the bug. That's good and all, but in my quick walk through the current open PRs against base system, there are a lots of PR with patches that just lie there collecting dust, a lot of PRs that have been analyzed and should be closed as "not a bug" or simply being more suited to be asked on questions@, and I don't see how I'd get someone to actually look at them -- so it's not like there's no interest in fixing bugs -- the number of patches in bugtracker says there's a lot of interest, it's just somewhat hard to get patches integrated. From owner-freebsd-hackers@freebsd.org Mon Dec 4 10:39:18 2017 Return-Path: Delivered-To: freebsd-hackers@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 B22BBDF7C5D for ; Mon, 4 Dec 2017 10:39:18 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com [209.85.215.53]) (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 440042BE5; Mon, 4 Dec 2017 10:39:17 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f53.google.com with SMTP id x20so18576737lff.1; Mon, 04 Dec 2017 02:39:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vqDGRaXJ5zQNHi8UAMmDYjlDrw16HZZIegom7zdATU4=; b=ZSX/pbDkYgUOlC82ZcWtK1EUjdAXrfpaWriKfx5Wa+k7yZCelEBX7ixjbjSnIhu0SM K83IDsA/anZ2vgz3s+LBrU1RRn7rVGvdCFvyoFYfOvSXhGTDWR3x3+BIdfsRt02WeiJr ZDF1Do+z+6B1/R0dBtn+ILqASKZGFKH5w8SXOIBuMqrjQCtq6lgXfmNwo9mnckb2fqZI FznjFmojs7pqhuKjGLbDCWa4fdoAUQpPqlQIw9zBAZTQwPYpHYLUH70YxRtPAtgeDSJ3 ouEVUxCE9wMaCIoota0HKPMu/hcG6kOVQ2kcNXSxQP9fhlPGyiTiIeYTXWAXUk0y02e5 wSjA== X-Gm-Message-State: AJaThX44zI+G75Qbv63fSpHCkGl7FixBT/pLog0E94ZpCveMrmLqcCl7 RsNolOPnLPZ+q93m1wnqhefE5KB5 X-Google-Smtp-Source: AGs4zMaKJPl1f1zj7F0JgYedEivWjv/OdzlreaunWxomf/Y7GNUzu97IPpW2zMF8w4iEU4yez4NqNA== X-Received: by 10.46.78.1 with SMTP id c1mr9697173ljb.188.1512383949850; Mon, 04 Dec 2017 02:39:09 -0800 (PST) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id d81sm2323623lfd.39.2017.12.04.02.39.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Dec 2017 02:39:09 -0800 (PST) Subject: Re: libpci-3.5.6: something is wrong From: Andriy Gapon To: sunpoet@FreeBSD.org Cc: freebsd-hackers@FreeBSD.org References: <1691ad41-40a0-9f49-fd46-6b0b65738d75@FreeBSD.org> Message-ID: <28a66616-4614-c89a-22c1-2fff09975017@FreeBSD.org> Date: Mon, 4 Dec 2017 12:39:08 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1691ad41-40a0-9f49-fd46-6b0b65738d75@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 10:39:18 -0000 [ping] On 25/11/2017 10:09, Andriy Gapon wrote: > > I have seen a report on IRC that libpci-3.5.6 upgrade caused troubles for > someone. Now I also see a problem: > > # flashrom --programmer internal > > flashrom v0.9.9-r1955 on FreeBSD 12.0-CURRENT (amd64) > flashrom is free software, get the source code at https://flashrom.org > > Calibrating delay loop... OK. > Found chipset "AMD SB7x0/SB8x0/SB9x0". > Enabling flash write... OK. > No EEPROM/flash device found. > Note: flashrom can never write if the flash chip isn't found automatically. > > > With libpci-3.5.5: > # > LD_PRELOAD=/usr/local/poudriere/ports/default/devel/libpci/work/pciutils-3.5.5/lib/libpci.so.3 > flashrom --programmer internal > flashrom v0.9.9-r1955 on FreeBSD 12.0-CURRENT (amd64) > flashrom is free software, get the source code at https://flashrom.org > > Calibrating delay loop... OK. > Found chipset "AMD SB7x0/SB8x0/SB9x0". > Enabling flash write... OK. > Found Winbond flash chip "W25Q32.V" (4096 kB, SPI) mapped at physical address > 0x00000000ffc00000. > No operations were specified. > > I am on amd64 head. I wonder if only head is affected. > I also wonder what kind of change in this minor release could have caused the > problem and if the upstream has any fix for it already. > > Thank you! > -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Mon Dec 4 17:04:34 2017 Return-Path: Delivered-To: freebsd-hackers@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 CA3BAE5DC9C for ; Mon, 4 Dec 2017 17:04:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 8CC71703CA for ; Mon, 4 Dec 2017 17:04:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x232.google.com with SMTP id f190so8278218ita.5 for ; Mon, 04 Dec 2017 09:04:34 -0800 (PST) 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=9ma+Z6aYIfzw2syaxzahqqN+dJ6j2CyfF18np2NGV7E=; b=KOcSVhr0ryxzEnetyzsI7xc4XB02SEHW5JIAuwwKDzRrhZOx+VyiyL26MEDYrQ9jE/ UDuC5aM2Wl9kSkI+A5BAGsvdwNowen+MRl/yifmPVjdkc32D0N2k4NL+WL4HuWBJi5mB lP6nC8NNa0JNCDIWXRLjR0bgLpH+QrZYlcBDIOVjGAAe7QFlB6ZZQmps3AcI4BUoLiDf FJgq5IKwLjsuHxaZld86P5vrhBLdXFaLOF/CQCO6ro8xAkNXT2x+w6RbkDbTJaBnMcO8 bAneQjTISsfonuCFdnLKzabKPr87Xo3o21de0Sgyvm0UGSnygCn5wiJoblP4AuLwb0Yy 3O9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=9ma+Z6aYIfzw2syaxzahqqN+dJ6j2CyfF18np2NGV7E=; b=t+ZEwU9jl3os1e2wWUvjQjkRGXI32GnzBA+ujkA5DDoZsMNyQB21ezrQFvCDB4m3SL n2ae9iXWGZuDoYt5Bn0/Jfqym2pI9FRGdnSPEuN0ymFfypdL4EAYfg54pOeEYnBe6uQ4 hXV4E3BlAZ2gjDWlsKF6HP7TgjLoNbiuecWonaHg9STkBgIAXcMwLELwWNI8Elsqpcrl Vu+ou0TsGa5TX45hJtMDEYMTyUGiHOUgYDb+G13z89f+Dng5bs5zmNs8uWGVHPQspfLe Hyfkc5lh3nA6MzGcijEP4XI5OyT9Uq1VHzgr/5iss3CWyLrYbCznhDQ0PkHKTw6hluvL glqA== X-Gm-Message-State: AKGB3mJrEb60YGlRDjoCOygvKyLZW7jFUsz6XYjsdk7N0KLOuttBDTMX KzgzmwVZxHvNcINbXX2wz0XxR9ZJ4ecu3KK7iFUBNg== X-Google-Smtp-Source: AGs4zMZo01FAHgpaw/bOF/VpuV0hf1bf0O5QjV+I0KNy3bKrgmJFhUDG/fqoIYieXjFw7yFm09EdGHkkq0oPUC9Wa9c= X-Received: by 10.107.52.140 with SMTP id b134mr13066006ioa.291.1512407073377; Mon, 04 Dec 2017 09:04:33 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Mon, 4 Dec 2017 09:04:32 -0800 (PST) X-Originating-IP: [50.253.109.65] In-Reply-To: References: <201712011318.vB1DIk4E069397@donotpassgo.dyslexicfish.net> From: Warner Losh Date: Mon, 4 Dec 2017 10:04:32 -0700 X-Google-Sender-Auth: 7w4YC8DJr7mIzgKTNsTPxsCz3x0 Message-ID: Subject: Re: Getting PRs fixed To: Yuri Pankov Cc: freebsd-hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 17:04:34 -0000 On Sun, Dec 3, 2017 at 11:16 PM, Yuri Pankov wrote: > On Fri, Dec 1, 2017 at 09:39:22AM -0800, Freddie Cash wrote: > >> On Fri, Dec 1, 2017 at 6:46 AM, Rebecca Cran >> wrote: >> >> >>> On Dec 1, 2017, at 6:18 AM, Jamie Landeg-Jones >>>> >>> wrote: >>> >>>> >>>> I've been using FreeBSD both professionally and personally since >>>> 2.2.7-RELEASE and I've fixed various bugs over the years, but a year o= r >>>> so ago, I got fed up with the general indifference these last few year= s. >>>> >>> >>> I was just thinking about getting back into bug-busting for FreeBSD: a >>> few >>> years ago when we were using GNATS we had a team that did triage, >>> follow-ups etc. that made some progress. Was that effort wound-down wit= h >>> the move to Bugzilla, or is the team still active? >>> >>> >> =E2=80=8BI don't know about triage, as in determining priority for speci= fic bugs, >> but there is a team that goes through the bug database assigning bugs to >> individuals and teams, and updating the Subject: line to better reflect >> the >> issue in the bug. >> > > That's good and all, but in my quick walk through the current open PRs > against base system, there are a lots of PR with patches that just lie > there collecting dust, a lot of PRs that have been analyzed and should be > closed as "not a bug" or simply being more suited to be asked on question= s@, > and I don't see how I'd get someone to actually look at them -- so it's n= ot > like there's no interest in fixing bugs -- the number of patches in > bugtracker says there's a lot of interest, it's just somewhat hard to get > patches integrated. > As someone who has spent his time in the trenches of patch applying from PRs, I'd have to say things are decidedly mixed. About half of the patches have serious problems (obviously don't work, clearly break other cases, fix the wrong problem, no longer apply, etc). Once you get through that gauntlet, then you have the next round of issues to cope with: subtle problems introduced by the patch. I've been burned several times where I got a patch, it looked good and then when I committed it after light testing all hell broke loose. Or after I committed it some subsystem maintainer pops up and says it's a layering violation, or some other sin that breaks some interface contract that's implicit in the code, but not explicit. So maybe 1/4 of the patches have these issues like that. Then about 1/8 of the code has serious style issues that needs to be cleaned up, lest one get email from the style police, so that cleanup takes time. All told, maybe 10-15% of the patches there are good to go w/o further changes. About 10-15% need some work. 25-30% patches need some serious work as they break something subtle and half of the patches are just junk, not worth wasting time on. With odds like that, and the extra time, frustration and damage to one's reputation when you mess one up, is it any wonder there aren't more people bug busting like that? Warner P.S. This has been my consistent experience through the time on the project. Early days, middle and recently. I tried to pull all the awk patches in, only to discover that two of them fixed the test case, but broke something substantial in the kernel build (each in a different way) and had to be reverted from my branch. Automated testing would help, but we have no automated awk testing in the tree today. I should add it, but that's another barrier to entry: getting the test suite setup for awk, validating the code in the test suite, etc are non-trivial investments in time. From owner-freebsd-hackers@freebsd.org Mon Dec 4 15:50:36 2017 Return-Path: Delivered-To: freebsd-hackers@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 D439ADFFCBA for ; Mon, 4 Dec 2017 15:50:36 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9EB496D5B7 for ; Mon, 4 Dec 2017 15:50:36 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vB4FoYxJ046444; Mon, 4 Dec 2017 07:50:34 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vB4FoXFx046443; Mon, 4 Dec 2017 07:50:33 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712041550.vB4FoXFx046443@pdx.rh.CN85.dnsmgr.net> Subject: Re: Getting PRs fixed In-Reply-To: To: Yuri Pankov Date: Mon, 4 Dec 2017 07:50:33 -0800 (PST) CC: freebsd-hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Mon, 04 Dec 2017 17:22:10 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 15:50:36 -0000 [ Charset UTF-8 unsupported, converting... ] > On Fri, Dec 1, 2017 at 09:39:22AM -0800, Freddie Cash wrote: > > On Fri, Dec 1, 2017 at 6:46 AM, Rebecca Cran wrote: > > > >> > >>> On Dec 1, 2017, at 6:18 AM, Jamie Landeg-Jones > >> wrote: > >>> > >>> I've been using FreeBSD both professionally and personally since > >>> 2.2.7-RELEASE and I've fixed various bugs over the years, but a year or > >>> so ago, I got fed up with the general indifference these last few years. > >> > >> I was just thinking about getting back into bug-busting for FreeBSD: a few > >> years ago when we were using GNATS we had a team that did triage, > >> follow-ups etc. that made some progress. Was that effort wound-down with > >> the move to Bugzilla, or is the team still active? > >> > > > > ?I don't know about triage, as in determining priority for specific bugs, > > but there is a team that goes through the bug database assigning bugs to > > individuals and teams, and updating the Subject: line to better reflect the > > issue in the bug. > > That's good and all, but in my quick walk through the current open PRs > against base system, there are a lots of PR with patches that just lie > there collecting dust, a lot of PRs that have been analyzed and should > be closed as "not a bug" or simply being more suited to be asked on > questions@, and I don't see how I'd get someone to actually look at them > -- so it's not like there's no interest in fixing bugs -- the number of > patches in bugtracker says there's a lot of interest, it's just somewhat > hard to get patches integrated. Part of that comes from often the patches are not correct, or not complete, or cause breakage of some other form. You just cant go take patches out of PR's and commit them, this would probalby generate more bugs in the long run than it could ever fix. Even the experts break code in non subtle ways that often take years to show up as a problem of some form. I am not saying we should ignore PR's with patches, but we should not just blindly go grabbing them for commits, what we need to do is get those patches infront of the expert(s) in that area and get a quick, yes, no, or needs work and reasoning for that to feed back into the PR, so that a non field expert can then try to move the state forward. And again, "the rate of change of the source code == rate of PR's submitted" We need to think about that, A LOT. Thus leads to the fact that any change in an attempt to fix a PR/bug has a high probabilty of introducing another bug, or creating another PR. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Mon Dec 4 21:28:20 2017 Return-Path: Delivered-To: freebsd-hackers@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 CB811E6B38D for ; Mon, 4 Dec 2017 21:28:20 +0000 (UTC) (envelope-from harald.boehm@fau.de) Received: from mx-rz-1.rrze.uni-erlangen.de (mx-rz-1.rrze.uni-erlangen.de [IPv6:2001:638:a000:1025::14]) (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 773A57A327 for ; Mon, 4 Dec 2017 21:28:20 +0000 (UTC) (envelope-from harald.boehm@fau.de) Received: from mx-rz-1.rrze.uni-erlangen.de (mx-rz-1.rrze.uni-erlangen.de [IPv6:2001:638:a000:1025::14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx-rz-1.rrze.uni-erlangen.de (Postfix) with ESMTPS id 3yrHzj4Pltz8t6Y for ; Mon, 4 Dec 2017 22:28:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fau.de; s=fau-2013; t=1512422897; bh=d1xDrSO5l3zx9U9QLW91iMXdUaAc6YYqJVqwR5tK/EM=; h=Subject:From:To:References:Date:In-Reply-To:From:To:CC:Subject; b=d6huB7jRJvPbJpkl38AkyCuAqwM9lptfh0xU1QcFn0zq5kHziXbKbV2jSelMEmDUk PQ8Re6HQHlAx+qJSVi6nYltorr1A6RkhP1A25M9/3n/gg/UdKhMFFcz3lF+4/OzwZ/ 0FAl6z6odqQzkwl5g0WthmJcyRuhOCl3pntAKQ0FMlqccxNRHtPk9mlLFEkauvnv6O U/PH7QTAw9xxWLX2JWHBaxbASY1FaKL9Mc6mhKKiJB1+t2Vbb0GPR+06DDhdhsyroA hySaUJkOpD6E172zWxPy8YvcgqvTATBsyHCG10XM0kALwg5Bw7S5hlWnKHhsK2gQ33 PgsNOS1lJc8dw== X-Virus-Scanned: amavisd-new at boeck2.rrze.uni-erlangen.de (RRZE) X-RRZE-Flag: Not-Spam X-RRZE-Submit-IP: 10.21.40.252 Received: from [10.21.40.252] (faustud-010-021-040-252.pool.uni-erlangen.de [10.21.40.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: U2FsdGVkX1+CTn7CfXxnzGu2JqZItrkjEUjhRrmCJ24=) by smtp-auth.uni-erlangen.de (Postfix) with ESMTPSA id 3yrHzc5rHCz8ssg for ; Mon, 4 Dec 2017 22:28:12 +0100 (CET) Subject: Re: ACPICA missing support for device I/O port ranges From: =?UTF-8?Q?Harald_B=c3=b6hm?= To: freebsd-hackers@freebsd.org References: <2497671.hb7Q7Esj6H@ralph.baldwin.cx> Message-ID: Date: Mon, 4 Dec 2017 22:28:12 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 21:28:20 -0000 > >> IO ranges are not supposed to be in _CRS. An IO range is used for relocatable >> resources and would be in _PRS to say "you can use I/O ports at addresses, A, >> B, or C". Specifically, the "Range" of an I/O port is the range of the >> starting addresses. Normal I/O addresses in _CRS are set to a fixed range >> with the same values for Range Min and Range Max. For example: >> >> IO (Decode16, >> 0x0CF8, // Range Minimum >> 0x0CF8, // Range Maximum >> 0x01, // Alignment >> 0x08, // Length >> ) >> >> This says it uses the '8' (Length) I/O ports starting at 0xcf8 and that they >> are fixed at 0xcf8 because the starting address has to be >= 0xcf8 (range min) >> and <= 0xcf8 (range max). The _CRS blob from your dump says that it wants to >> allocate 255 I/O ports with a starting address of 0x700, 0x701, 0x702, 0x703, >> .... , 0x7fd, 0x7fe, or 0x7ff, but it doesn't tell us _which_ of those ranges >> it is actually using (e.g. is it using 0x700 -> 0x7ff or is it using 0x780 -> >> 0x88f, etc.). > > Thanks for the explanation, after reading it and having a look at the > ACPI spec everyhing makes much more sense now. :) > >> Probably it's just a bug in your BIOS and it means to use >> 0x700 -> 0x7ff and the BIOS author doesn't understand what Range Maximum means. >> It is not the end address of the full I/O port addresses reserved, but the >> maximum starting address (I agree this is a bit odd, but this is what the >> spec says). > > From what I know about the device so far, this seems to be true. The > device only uses I/O ports in the range between 0x700 and 0x7FF, that's > why I was confused in the first place. It also seems to be the only > device that has this buggy port description in my BIOS, all other device > entries look like the example you gave. > > The affected Laptop is a MacBook Pro 11,3. The device should be present > in Apple computers with two graphics cards, it is used to switch between > GPUs. So, if anyone else is using a Mac with two graphics cards, it > would be interesting to see, whether this bug is also present in other > machines (acpidump -td and search for GMUX). > >> Assuming the BIOS is buggy, we can add a hack for iorange that adds the >> resource if max == min + length and emit a warning under bootverbose about >> the BIOS being buggy. I've filed a PR[0] with a revised version of my patch. I'd be glad about feedback/review. Thanks, Harald Böhm [0] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224096 From owner-freebsd-hackers@freebsd.org Tue Dec 5 15:40:06 2017 Return-Path: Delivered-To: freebsd-hackers@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 478C8E6DF62 for ; Tue, 5 Dec 2017 15:40:06 +0000 (UTC) (envelope-from stoa@gmx.us) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A784F7F530 for ; Tue, 5 Dec 2017 15:40:05 +0000 (UTC) (envelope-from stoa@gmx.us) Received: from MyDebian.dutch.net ([97.66.214.165]) by mail.gmx.com (mrgmx001 [212.227.17.184]) with ESMTPSA (Nemesis) id 0LpKKr-1eyrGa0b8H-00fEWf for ; Tue, 05 Dec 2017 16:39:57 +0100 Date: Tue, 5 Dec 2017 09:39:47 -0600 From: Dutch Ingraham To: freebsd-hackers@freebsd.org Subject: Cannot mount ext2 filesystem read-write Message-ID: <20171205153946.GA1997@MyDebian.dutch.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) X-Provags-ID: V03:K0:5bRxylgLkHKUu4g1VGN30S2D1iF2qOW5wVysgROE8FtFSMV+oUm NbFPaK1uHCDZzUCxYNrp+mR1F2MxGcoF8AeIa6tKls8J14T/nmwQ22ncVxj/uooOa7Hq7Gw hVS62/2Vj6+aRyos+IhbtRMZcRdGws2Hp2hViKnRglR1d6ETMI2+7P3zXt9rSxZfiMRX0bc 9SUFHYt6K7kg/jMXXrwJw== X-UI-Out-Filterresults: notjunk:1;V01:K0:869fnc+p3BU=:ypm1M8X/mZUI62oJ1XvlF4 WUnMno7llJplvgfZGmBRHobLKGK7nmNy4vv7kp9L+DKJ0adi6uBne+QLyZtMe2DdSPF7u74JN lxrdOIOQrpu1QrMGymlV0jPke86nGmspJt0SZ8q8wZ+kgCFd4vdZyrycKfEju/gakZ2vUeFLR +f+eA0uWiPEUqyQtGMo2Q+P32T+9c7NFfrzqtHbvl1ZFrU8T15HHT3su/D1YaKlfJWarajhxC Nk1gwp0bHuLROoR+EGYe9ud2LQuDVPRXMZP5zom3B+lmlMRcy+OquYBrqUlEgQu+9GJvBG9Ca kp79KEoU9kMCGN0A2EOdrDxZCXG5KJxLLpwoD0XoN203l74QGWtGb8ERoSrRMLERcqptTw602 ntXqhrP0PDCOBexOqdb2XpkAM/pL9JiHVjla/cSrdEuDPIVOYg7VYZCHgpAsf9LY8b+UmEkez 1zyxMMtQiBSGwmIY2haDFv6WDAZZ88cHsT2l5tqu0WilmR7pPamHVf0BzG4fuSDnztn7NVLjL YjkbzWniABCET7hJdjhJ1IYXuEiVYawpGtHH7rQGO2e2Kf9Rl9SpyCw2IVKB2fQXEYGnueztl XSJ0oZButAwU7ll7rae66x/za8dctBcEoqntr+ecgj9jzZ6jbhTSCKsmdLPiGTSOYGLMFWBZw +TmlN1joMNn5tqlRQLtzoR5WMMQBoozxGvg/iuVDGepzTv5EZRatggXSYlMFSok5uhUmIMsKp 56nXPEsLNu6niH791GGImYU+J35M2ARvBi4LkM5syfsmO7pn2xmTa3NtOjJuABfCqnwN/jQdw cRq6HR5edVGBXfCU119Jgb5vjTeqg== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 15:40:06 -0000 Hi everybody - I'm copying this over from -questions, from which I didn't receive any replies, in the hopes someone here can help. I cannot seem to mount a thumbdrive formatted to ext2 in read-write mode on my FreeBSD 11.1-RELEASE-p4 #0 system. The error is: /usr/home/dutch $ sudo mount -t ext2fs /dev/da0s1 /media/usb mount: /dev/da0s1: Operation not permitted It seems some years ago there was an inode limit of 128 on mounting ext2fs in read-write mode; see this[1] thread for example. There seems to have been a patch that corrected this situation and allowed inodes of 256 (my case). However, the advice in that thread is 9 years old. The current manpage for ext2fs(5) only states one requirement (build-in or load the ext2fs kernel module) and indicates that the restriction on read-write mode only aplies to the ext4 filesystem, and I am attempting to mount the ext2 filesystem. A current forum post[2] seems to indicate there is still an issue (regardless of the 2016 ext2fs manpage) mounting an ext2 filesystem read-write (although it is somewhat ambiguous whether the OP was trying to mount an ext2 or ext4 filesystem). Can someone please advise (1) if FreeBSD provides for mounting an ext2 filesystem in read-write mode, and if so, (2) what I am doing wrong? Thanks for your help. PS - I can mount read-only, but that doesn't help me much. [1] https://forums.freebsd.org/threads/912/ [2] https://forums.freebsd.org/threads/60501/ From owner-freebsd-hackers@freebsd.org Tue Dec 5 21:31:16 2017 Return-Path: Delivered-To: freebsd-hackers@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 3F939E82DEE; Tue, 5 Dec 2017 21:31:16 +0000 (UTC) (envelope-from benno@FreeBSD.org) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 19BAF71A8E; Tue, 5 Dec 2017 21:31:15 +0000 (UTC) (envelope-from benno@FreeBSD.org) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 233C5222A7; Tue, 5 Dec 2017 16:31:14 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Tue, 05 Dec 2017 16:31:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=9P1M6U8lAQsPBgoQWyKlU6oxv+4sT FYIv2fJSoT2Rkg=; b=PyAQ4fHH8awr7pWsmnLal6aObPCFmXepEjP78NVBrfv9C IDKVCqZEJs1bJ8bseSaMntf+I+UxkmGXSWePzTRXF+vmqusAl5fAe1Ln//Q9FRDH Thp84z343ntX32DbbQKNWb4kVxBAeslblFNdDl93nbKo0za3EnWo5pxzjlmghLNH emfnzvb3vEZZC6c7jxrpAvOxGbdjlSb2m6qbH5LG0T7kfgd13gnnJ2A5uuSc582V GbzgBSwTBr87YGWw/PrtFN8wiH6O0q2MkT90zpvmxD8N4SDz0T/UOxUen/Ozsg9b 6YBxXj5Y4UY4S+ysY2PhllW67I9WRfEdazeb+5JMw== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D09239E17F; Tue, 5 Dec 2017 16:31:13 -0500 (EST) Message-Id: <1512509473.1313677.1195210352.2DC7580C@webmail.messagingengine.com> From: Benno Rice To: freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-1b87d328 Subject: Conclusion of fortune(6) discussion Date: Tue, 05 Dec 2017 13:31:13 -0800 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 21:31:16 -0000 Hi all, First up I=E2=80=99d like to apologize for the length of time between my fi= rst email and this. I wanted to wait for the various discussions to play out somewhat and then I had a conference I needed to prep for. I should=E2=80= =99ve worked the timing around that better. So now that the dust has settled somewhat, I feel that the consensus decision is for fortune to remain in base along with freebsd-tips. Some points I=E2=80=99d like to make based on the discussion: Firstly, there were a number of suggestions that removing fortune et al from base is some form of complete deletion. It=E2=80=99s not. It=E2=80=99s= merely that FreeBSD stops distributing it as part of our releases. The code is still available in our Subversion history. Nothing in what I was proposing precluded creating a port. I will however admit that not mentioning a port at all left that unclear. Which brings me to point number two: My discussion was about base, not ports. It=E2=80=99s my firm belief that if I propose removing code from bas= e the onus shouldn=E2=80=99t be on me to create and thus, under the rules governi= ng ports, become the maintainer of a port for a piece of code I have no interest in maintaining. That=E2=80=99s not fair to anyone involved. There= =E2=80=99ve been ongoing efforts to streamline and slim down base. fortune seemed like an obvious thing to move out. There should absolutely be a discussion whenever anyone proposes moving code out of base and that should absolutely leave the option open for that code to move to ports. If a port is created though it should be done by someone with an interest in maintaining the code. And my final point: This was never about political correctness. I am not apologizing for making this move without discussion as any discussion would=E2=80=99ve turned out exactly like the threads that showed up. There = would have been no consensus. There would have been accusations of bias, bad faith and pointless bickering from all directions. The difference to me is that by removing these files from base we never have to have this argument again. If we kept the file we would=E2=80=99ve potentially had this discussion every time the file was touched or looked at by a new pair of eyes. I acknowledge the history that the fortune files embody but we=E2=80= =99re not living in that history any more. We=E2=80=99re living now. The world in= 2017 is not the world in 1987 or the world in 1997. Like it or not we live in a world where there is more expectation on everyone to acknowledge that what is funny to them may be offensive to others and that the nature of that offense may not be immediately obvious. Like I said in another post FreeBSD is an operating system, not an encyclopedia. There are far better projects for collecting humour, quotes, and history than ours. We should let ourselves focus on what we=E2=80=99re good at. Thanks, Benno. From owner-freebsd-hackers@freebsd.org Tue Dec 5 22:30:57 2017 Return-Path: Delivered-To: freebsd-hackers@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 7E5E8E8549F; Tue, 5 Dec 2017 22:30:57 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 43E707602D; Tue, 5 Dec 2017 22:30:56 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 3801027396; Tue, 5 Dec 2017 22:30:50 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id vB5MUYAO024030 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 Dec 2017 22:30:34 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id vB5MUXEJ024029; Tue, 5 Dec 2017 22:30:33 GMT (envelope-from phk) To: Benno Rice cc: freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Conclusion of fortune(6) discussion In-reply-to: <1512509473.1313677.1195210352.2DC7580C@webmail.messagingengine.com> From: "Poul-Henning Kamp" References: <1512509473.1313677.1195210352.2DC7580C@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <24027.1512513033.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Tue, 05 Dec 2017 22:30:33 +0000 Message-ID: <24028.1512513033@critter.freebsd.dk> X-Mailman-Approved-At: Tue, 05 Dec 2017 23:09:50 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 22:30:57 -0000 -------- In message <1512509473.1313677.1195210352.2DC7580C@webmail.messagingengine= .com> , Benno Rice writes: > I acknowledge the history that the fortune files embody but we=E2=80=99r= e >not living in that history any more. We=E2=80=99re living now. The world = in 2017 >is not the world in 1987 or the world in 1997. To me this is the most convincing argument for getting rid of the old jokes: Fortune(6) as joke-supply only make sense if somebody humourously competent actively curate the collection of jokes. Distributing the same old jokes, year after year, release after release is a ritual, and it is certainly not funny. We can argue exactly how well curated the freebsd-tips are, but they are by definition fresh to their intended audience and even I will admit to having learned something from one or two of them. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-hackers@freebsd.org Wed Dec 6 01:57:11 2017 Return-Path: Delivered-To: freebsd-hackers@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 2246AE8B56F; Wed, 6 Dec 2017 01:57:11 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:a:dead:bad:faff]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DD75C7D6E5; Wed, 6 Dec 2017 01:57:10 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id vB61v9wr013842; Wed, 6 Dec 2017 01:57:09 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id vB61v9E3013835; Wed, 6 Dec 2017 01:57:09 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201712060157.vB61v9E3013835@donotpassgo.dyslexicfish.net> Date: Wed, 06 Dec 2017 01:57:09 +0000 Organization: Dyslexic Fish To: freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org, benno@freebsd.org Subject: Re: Conclusion of fortune(6) discussion References: <1512509473.1313677.1195210352.2DC7580C@webmail.messagingengine.com> In-Reply-To: <1512509473.1313677.1195210352.2DC7580C@webmail.messagingengine.com> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 01:57:11 -0000 Benno Rice wrote: > Firstly, there were a number of suggestions that removing fortune et al > from base is some form of complete deletion. It’s not. It’s merely that > FreeBSD stops distributing it as part of our releases. The code is still > available in our Subversion history. That's hardly an argument - you could apply that to anything! Personally. I don't give a rats-arse either way about fortune(6), but agree with others who were uncomfortable that one person just decides to whip out a command that isn't causing problems or security issues without warning. I'm not even talking necessarily about discussions with us plebs; in my 20+ years of FreeBSD, whilst just about everything is discussed, I can't once remember one person just arbitarily removing a command without warning like that. And, you seem to be agreeing about discussion and announcements, Here: > Nothing in what I was proposing precluded creating a port. and here: > Which brings me to point number two: My discussion was about base, not > ports. and here: > There should absolutely be a > discussion whenever anyone proposes moving code out of base and that But then you wrote: > And my final point: This was never about political correctness. I am not > apologizing for making this move without discussion as any discussion So, you say things should be discussed, yet you're not apologising for the fact you made the move without discussion, which sounds like you just broke your own guidelines. Cheers, Jamie From owner-freebsd-hackers@freebsd.org Wed Dec 6 06:57:59 2017 Return-Path: Delivered-To: freebsd-hackers@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 557DEE97EA0 for ; Wed, 6 Dec 2017 06:57:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-161.reflexion.net [208.70.210.161]) (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 1AC3E66563 for ; Wed, 6 Dec 2017 06:57:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28811 invoked from network); 6 Dec 2017 05:57:57 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 6 Dec 2017 05:57:57 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Wed, 06 Dec 2017 00:57:57 -0500 (EST) Received: (qmail 18392 invoked from network); 6 Dec 2017 05:57:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Dec 2017 05:57:57 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A135AEC8B7B; Tue, 5 Dec 2017 21:57:56 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: rpi2 hangup during poudriere build: lots of pfault wmseg status Message-Id: <05BEA04B-249B-4E7D-855A-46DA1A0DEA16@dsl-only.net> Date: Tue, 5 Dec 2017 21:57:56 -0800 To: Freebsd-arm , freebsd-hackers , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 06:57:59 -0000 I tried to build some ports on a rpi2 (via poudriere) but it hung up: Ethernet and normal console use. (Note: the root file system is on a USB SSD and the swap partition is also on that USB SSD.) But ~^b worked for getting to the db> prompt on the console. =46rom there a ps suggests that it got hung up in pfault activity. (Possibly insufficient RAM+swap-partition space?) But it is not clear to me that it should end up hung up vs. killing processes or other such. db> ps pid ppid pgrp uid state wmesg wchan cmd 36369 36770 36588 0 D+ pfault 0xc0832880 sh 36368 36770 36588 0 D+ pfault 0xc0832880 awk 36367 36770 36588 0 D+ pfault 0xc0832880 awk 36353 88873 36588 0 D+J pfault 0xc0832880 gmake 35115 35107 36588 0 D+J pfault 0xc0832880 ld 35107 76552 36588 0 SW+J wait 0xc4a52398 c++ 35071 35066 36588 0 D+J pfault 0xc0832880 ld 35066 76552 36588 0 SW+J wait 0xc64d6730 c++ 35047 35036 36588 0 D+J pfault 0xc0832880 ld 35036 76552 36588 0 SW+J wait 0xc5efc000 c++ 88873 88868 36588 0 S+J select 0xc5ea0b24 gmake 88868 88867 36588 0 SW+J wait 0xc3da1ac8 sh 88867 88674 36588 0 SW+J wait 0xc5904398 gmake 88674 28839 36588 0 SW+J wait 0xc66e4730 gmake 76552 76450 36588 0 SW+J wait 0xc5eb5ac8 gmake 76450 76438 36588 0 SW+J wait 0xc3aa2730 sh 76438 76380 36588 0 SW+J wait 0xc64d6000 gmake 76380 28839 36588 0 SW+J wait 0xc66e4ac8 gmake 28839 28828 36588 0 SW+J wait 0xc5f78ac8 gmake 28828 28826 36588 0 SW+J wait 0xc4a52000 sh 28826 28825 36588 0 SW+J wait 0xc5eb5398 gmake 28825 28793 36588 0 SW+J wait 0xc5c5d730 sh 28793 28792 36588 0 SW+J wait 0xc4262ac8 make 28792 23997 36588 0 SW+ wait 0xc56fb000 sh 23997 36588 36588 0 D+ pfault 0xc0832880 sh 40786 36588 36588 0 S+ piperd 0xc422c5b8 sh 36770 36588 36588 0 S+ wait 0xc5f78000 sh 36588 748 36588 0 D+ pfault 0xc0832880 sh 36387 748 36387 0 TW+ vi 748 747 748 0 SW+ wait 0xc4205000 sh 747 741 747 1001 SW+ wait 0xc4261398 su 741 740 741 1001 SWs+ wait 0xc3da0000 sh 740 737 737 1001 S select 0xc4227524 sshd 737 670 737 0 Ss select 0xc42275a4 sshd 723 722 723 0 D+ pfault 0xc0832880 sh 722 1 722 0 SWs+ wait 0xc4260398 login 721 1 721 0 Ss+ ttyin 0xc39d9474 getty 674 1 674 0 ?Ws cron 670 1 670 0 Ds pfault 0xc0832880 sshd 639 1 639 0 Ss select 0xc4227724 powerd 636 1 636 0 Ss (threaded) ntpd 100106 S select 0xc4227764 ntpd 588 587 587 0 S (threaded) nfsd 100098 S rpcsvc 0xc42ecc50 nfsd: master 100110 S rpcsvc 0xc3995250 nfsd: service 100111 S rpcsvc 0xc41721d0 nfsd: service 100112 S rpcsvc 0xc4171d50 nfsd: service 100113 S rpcsvc 0xc39952d0 nfsd: service 100114 S rpcsvc 0xc41725d0 nfsd: service 100115 S rpcsvc 0xc4171dd0 nfsd: service 100116 S rpcsvc 0xc39956d0 nfsd: service 100117 S rpcsvc 0xc3995350 nfsd: service 100118 S rpcsvc 0xc4172550 nfsd: service 100119 S rpcsvc 0xc3995750 nfsd: service 100120 S rpcsvc 0xc41726d0 nfsd: service 100121 S rpcsvc 0xc39953d0 nfsd: service 100122 S rpcsvc 0xc4172650 nfsd: service 100123 S rpcsvc 0xc41723d0 nfsd: service 100124 S rpcsvc 0xc4172450 nfsd: service 100125 S rpcsvc 0xc3995450 nfsd: service 100126 S rpcsvc 0xc4171cd0 nfsd: service 100127 S rpcsvc 0xc4172350 nfsd: service 100128 S rpcsvc 0xc41724d0 nfsd: service 100129 S rpcsvc 0xc39954d0 nfsd: service 100130 S rpcsvc 0xc4172250 nfsd: service 100131 S rpcsvc 0xc41720d0 nfsd: service 100132 S rpcsvc 0xc41722d0 nfsd: service 100133 S rpcsvc 0xc3995550 nfsd: service 100134 S rpcsvc 0xc4172050 nfsd: service 100135 S rpcsvc 0xc4171e50 nfsd: service 100136 S rpcsvc 0xc4172150 nfsd: service 100137 S rpcsvc 0xc39955d0 nfsd: service 100138 S rpcsvc 0xc4171f50 nfsd: service 100139 S rpcsvc 0xc4171ed0 nfsd: service 100140 S rpcsvc 0xc3995650 nfsd: service 587 1 587 0 Ss select 0xc42277a4 nfsd 585 1 585 0 Ss select 0xc4227624 mountd 455 1 455 0 Ss select 0xc4103d64 rpcbind 446 1 446 0 Ds pfault 0xc0832880 syslogd 375 1 375 0 Ss select 0xc4103fa4 devd 374 1 374 65 Ds pfault 0xc0832880 dhclient 328 1 328 0 Ss select 0xc4227f64 dhclient 325 1 325 0 Ss select 0xc3dec4e4 dhclient 31 0 0 0 DL vlruwt 0xc3da0730 [vnlru] 30 0 0 0 DL syncer 0xc095a6dc [syncer] 29 0 0 0 DL - 0xc095a0c8 [bufspacedaemon] 28 0 0 0 DL (threaded) [bufdaemon] 100070 D psleep 0xc0959fc0 [bufdaemon] 100092 D sdflush 0xc42ae884 [/ worker] 27 0 0 0 DL psleep 0xc095ecb4 [vmdaemon] 26 0 0 0 RL (threaded) [pagedaemon] 100068 RunQ [pagedaemon] 100074 D launds 0xc095ebb4 [laundry: dom0] 100075 D umarcl 0xc095e8fc [uma] 25 0 0 0 SL worker_ 0xc3757a90 = [bcm2835_audio_worke] 24 0 0 0 SL VCHI co 0xc3a9980c [VCHIQka-0] 23 0 0 0 DL mmcsd d 0xc3fe4800 [mmcsd0boot1: = mmc/sd] 22 0 0 0 DL mmcsd d 0xc3fe4a00 [mmcsd0boot0: = mmc/sd] 21 0 0 0 DL mmcsd d 0xc3fe4c00 [mmcsd0: mmc/sd = card] 20 0 0 0 DL - 0xc0959c34 [soaiod4] 19 0 0 0 DL - 0xc0959c34 [soaiod3] 18 0 0 0 DL - 0xc0959c34 [soaiod2] 17 0 0 0 DL - 0xc0959c34 [soaiod1] 16 0 0 0 DL - 0xc0841298 [rand_harvestq] 15 0 0 0 DL waiting 0xc0968ef0 [sctp_iterator] 14 0 0 0 DL (threaded) [usb] 100049 D - 0xc3a9f02c [usbus0] 100050 D - 0xc3a9f05c [usbus0] 100051 D - 0xc3a9f08c [usbus0] 100052 D - 0xc3a9f0bc [usbus0] 100053 D - 0xc3a9f0ec [usbus0] 100067 D - 0xc3a5d428 [smsc0] 13 0 0 0 SL sema cv 0xc0980d80 [VCHIQs-0] 9 0 0 0 SL sema cv 0xc0980d5c [VCHIQr-0] 8 0 0 0 SL sema cv 0xc0980d38 [VCHIQ-0] 7 0 0 0 DL (threaded) [cam] 100031 D - 0xc083e140 [doneq0] 100057 D - 0xc083e06c [scanner] 6 0 0 0 DL crypto_ 0xc39b50c4 [crypto returns 3] 5 0 0 0 DL crypto_ 0xc39b508c [crypto returns 2] 4 0 0 0 DL crypto_ 0xc39b5054 [crypto returns 1] 3 0 0 0 DL crypto_ 0xc39b501c [crypto returns 0] 2 0 0 0 DL crypto_ 0xc095e23c [crypto] 12 0 0 0 DL (threaded) [geom] 100018 D - 0xc0967758 [g_event] 100019 D - 0xc096775c [g_up] 100020 D - 0xc0967760 [g_down] 11 0 0 0 WL (threaded) [intr] 100006 I [swi6: Giant taskq] 100009 I [swi5: fast taskq] 100011 I [swi6: task queue] 100012 I [swi4: clock (0)] 100013 I [swi4: clock (1)] 100014 I [swi4: clock (2)] 100015 I [swi4: clock (3)] 100016 I [swi3: vm] 100017 I [swi1: netisr 0] 100032 I [intc0,69: bcmrng0] 100033 I [intc0,61: iichb0+] 100034 I [intc0,62: spi0] 100035 I [intc0,28: = bcm_dma0] 100036 I [intc0,29: = bcm_dma0] 100037 I [intc0,32: = bcm_dma0] 100038 I [intc0,33: = bcm_dma0] 100039 I [intc0,34: = bcm_dma0] 100040 I [intc0,35: = bcm_dma0] 100041 I [intc0,1: mbox0] 100042 I [intc0,70: +] 100043 I [swi0: uart] 100044 I [intc0,2: vchiq0] 100048 I [intc0,17: +] 10 0 0 0 RL (threaded) [idle] 100002 Run CPU 0 [idle: cpu0] 100003 Run CPU 1 [idle: cpu1] 100004 CanRun [idle: cpu2] 100005 Run CPU 3 [idle: cpu3] 1 0 1 0 SLs wait 0xc38b5000 [init] 0 0 0 0 RLs (threaded) [kernel] 100000 D vmwait 0xc0832880 [swapper] 100007 D - 0xc38ada00 [thread taskq] 100008 D - 0xc38ad980 [aiod_kick taskq] 100010 D - 0xc38ad880 [kqueue_ctx taskq] 100021 D - 0xc38ad780 [firmware taskq] 100022 D - 0xc38ad700 [crypto_0] 100023 D - 0xc38ad700 [crypto_1] 100024 D - 0xc38ad700 [crypto_2] 100025 D - 0xc38ad700 [crypto_3] 100056 D - 0xc38ad680 [CAM taskq] 100076 D - 0xc3fa1f00 [if_config_tqg_0] 100077 D - 0xc40c4100 [softirq_0] 100078 D - 0xc40c4080 [softirq_1] 100079 RunQ [softirq_2] 100080 D - 0xc40c3f00 [softirq_3] 100081 D - 0xc3fa1e00 [if_io_tqg_0] 100082 D - 0xc3fa1d80 [if_io_tqg_1] 100083 RunQ [if_io_tqg_2] 100084 D - 0xc3fa1c80 [if_io_tqg_3] Exploring some commands. . . db> show pageq pq_free 599 dom 0 page_cnt 205724 free 599 pq_act 160929 pq_inact 3178 pq_laund 0 = pq_unsw 0 db> show page vm_cnt.v_free_count: 599 vm_cnt.v_inactive_count: 3178 vm_cnt.v_active_count: 160929 vm_cnt.v_laundry_count: 0 vm_cnt.v_wire_count: 41018 vm_cnt.v_free_reserved: 333 vm_cnt.v_free_min: 1360 vm_cnt.v_free_target: 4441 vm_cnt.v_inactive_target: 6661 db> show freepages DOMAIN: 0 FREE LIST 0: ORDER (SIZE) | NUMBER | POOL 0 -- -- -- -- 08 (001024K) | 000000 07 (000512K) | 000000 06 (000256K) | 000000 05 (000128K) | 000002 04 (000064K) | 000000 03 (000032K) | 000000 02 (000016K) | 000001 01 (000008K) | 000001 00 (000004K) | 000002 db> show allpcpu Current CPU: 0 cpuid =3D 0 dynamic pcpu =3D 0x3d3f00 curthread =3D 0xc38b8ae0: pid 10 tid 100002 "idle: cpu0" curpcb =3D 0xe4c6de98 fpcurthread =3D 0xc4267ae0: pid 639 "powerd" idlethread =3D 0xc38b8ae0: tid 100002 "idle: cpu0" curpmap =3D 0xc0967fa4 curvnet =3D 0 cpuid =3D 1 dynamic pcpu =3D 0x13accf00 curthread =3D 0xc38b8740: pid 10 tid 100003 "idle: cpu1" curpcb =3D 0xe4c70e98 fpcurthread =3D 0xc4028740: pid 636 "ntpd" idlethread =3D 0xc38b8740: tid 100003 "idle: cpu1" curpmap =3D 0xc0967fa4 curvnet =3D 0 cpuid =3D 2 dynamic pcpu =3D 0x13acdf00 curthread =3D 0xc38b83a0: pid 10 tid 100004 "idle: cpu2" curpcb =3D 0xe4c73e98 fpcurthread =3D none idlethread =3D 0xc38b83a0: tid 100004 "idle: cpu2" curpmap =3D 0 curvnet =3D 0 cpuid =3D 3 dynamic pcpu =3D 0x24426f00 curthread =3D 0xc38b8000: pid 10 tid 100005 "idle: cpu3" curpcb =3D 0xe4c76e98 fpcurthread =3D 0xc4267ae0: pid 639 "powerd" idlethread =3D 0xc38b8000: tid 100005 "idle: cpu3" curpmap =3D 0xc0967fa4 curvnet =3D 0 db>=20 At one point before the hangup top -CawPores showed: Mem: 8308K Active, 363M Inact, 11M Laundry, 168M Wired, 88M Buf, 253M = Free Swap: 1536M Total, 1244K Used, 1535M Free Sometime before it hung up there was: # poudriere status SET PORTS JAIL BUILD STATUS QUEUE BUILT = FAIL SKIP IGNORE REMAIN TIME LOGS - default FBSDjailRPI2 2017-12-03_20h38m29s parallel_build 87 32 = 0 0 0 55 04:32:21 = /usr/local/poudriere/data/logs/bulk/FBSDjailRPI2-default/2017-12-03_20h38m= 29s The end of the poudriere output looked like: . . . [07:59:07] [01] [00:00:00] Building sysutils/dtc | dtc-1.4.5 [08:00:12] [01] [00:01:05] Saved sysutils/dtc | dtc-1.4.5 wrkdir to: = /usr/local/poudriere/data/wrkdirs/FBSDjailRPI2-default/default/dtc-1.4.5.t= bz [08:00:14] [01] [00:01:07] Finished sysutils/dtc | dtc-1.4.5: Failed: = build [08:00:14] [01] [00:01:07] Skipping sysutils/u-boot-rpi2 | = u-boot-rpi2-2017.09.00: Dependent port sysutils/dtc | dtc-1.4.5 failed [08:00:15] [01] [00:00:00] Building devel/binutils | binutils-2.28,1 (It looks like a rpi2 does not build its own sysutils/u-boot-rpi2 .) The world and kernel were head -r326192: FreeBSD 12.0-CURRENT r326192M arm FreeBSD clang vers 5.0.0svn) (M is mostly from some powerpc64 and powerpc material: I build the same source for everything generally.) /usr/ports for the ports build was at -r455204 (last before FLAVORS being enabled). I historically have not built ports on a rpi2. So this is not a comparison with past results. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Wed Dec 6 16:16:09 2017 Return-Path: Delivered-To: freebsd-hackers@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 E929BE844EA; Wed, 6 Dec 2017 16:16:09 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) by mx1.freebsd.org (Postfix) with ESMTP id B03BF780D7; Wed, 6 Dec 2017 16:16:09 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id A5FA716045; Wed, 6 Dec 2017 17:16:01 +0100 (CET) Date: Tue, 05 Dec 2017 23:18:15 +0100 From: Steffen Nurpmeso To: "Poul-Henning Kamp" Cc: Benno Rice , freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Conclusion of fortune(6) discussion Message-ID: <20171205221815.VDf9r%steffen@sdaoden.eu> References: <1512509473.1313677.1195210352.2DC7580C@webmail.messagingengine.com> <24028.1512513033@critter.freebsd.dk> In-Reply-To: <24028.1512513033@critter.freebsd.dk> Mail-Followup-To: "Poul-Henning Kamp" , Benno Rice , freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org, Steffen Nurpmeso User-Agent: s-nail v14.9.5-41-g29c58dc6 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 16:16:10 -0000 "Poul-Henning Kamp" wrote: |In message <1512509473.1313677.1195210352.2DC7580C@webmail.messagingengin= e.c\ |om> |, Benno Rice writes: | |> I acknowledge the history that the fortune files embody but we=E2=80=99re |>not living in that history any more. We=E2=80=99re living now. The world= in 2017 |>is not the world in 1987 or the world in 1997. | |To me this is the most convincing argument for getting rid of the |old jokes: Fortune(6) as joke-supply only make sense if somebody |humourously competent actively curate the collection of jokes. | |Distributing the same old jokes, year after year, release after |release is a ritual, and it is certainly not funny. | |We can argue exactly how well curated the freebsd-tips are, but |they are by definition fresh to their intended audience and even I |will admit to having learned something from one or two of them. The public discourse (of those countries that i have on my media radar, embarassingly few) beats with a sledgehammer of lies and an overwhelming amount of (superficial) facts without giving any context. It is not the time for receiving undertones in between written lines, and it seems it has become an impossibility to expect them to appear before one mind's eye just because of the context in which they .. indeed appear. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From owner-freebsd-hackers@freebsd.org Wed Dec 6 22:04:14 2017 Return-Path: Delivered-To: freebsd-hackers@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 3EF71E8D40B; Wed, 6 Dec 2017 22:04:14 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:a:dead:bad:faff]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 028D564311; Wed, 6 Dec 2017 22:04:13 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id vB6M4CXC026346; Wed, 6 Dec 2017 22:04:12 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id vB6M4B03026339; Wed, 6 Dec 2017 22:04:11 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201712062204.vB6M4B03026339@donotpassgo.dyslexicfish.net> Date: Wed, 06 Dec 2017 22:04:11 +0000 Organization: Dyslexic Fish To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, by@meetlost.com Cc: jamie@catflap.org Subject: Re: Strange behavior about pattern matching on manual pages [FIXED] References: <620CD9B7-201A-46FD-8C9D-DD8DDA3A05C3@meetlost.com> In-Reply-To: <620CD9B7-201A-46FD-8C9D-DD8DDA3A05C3@meetlost.com> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Wed, 06 Dec 2017 22:04:12 +0000 (GMT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 22:04:14 -0000 by wrote: > Hi, > > I encounter a problem when viewing manuals via man(1) command. > > The case is simple, when I try to search something, I press ‘/’, and then input the pattern, If it got something in the page, it will direct me into the specified place, and then, I continue with ’n’, and it goes well. > But the problem is, after a sequence of ’n’, the screen go to the end of the manual pages, and keeping press ’n’, I got annoying “...skipping...”, the page is full of skipping and parts of the end of the manual page. Yes. This has been annoying me too - your email prompted me to finally work on a fix for it! Firstly, it isn't man(1) itself - man(1) uses more(1) as the pager. more(1) is in itself actually the program less(1), running in "more emulation mode". And less(1) isn't FreeBSD native code - it's imported into the project from http://www.greenwoodsoftware.com/less/ I noticed the very latest version of less(1) has been checked into freebsd-current, and the issue still occurs there. Anyway, the fix is two small patches to less(1), please let me know if they work for you, and if you see any bad side-effects in man(1) / more(1) and less(1) and I'll then try and get them applied upstream. The patches have been tested against FreeBSD 11.1-STABLE and 12-CURRENT cheers! Jamie --- contrib/less/forwback.c.orig 2017-11-20 08:52:33.978356000 +0000 +++ contrib/less/forwback.c 2017-12-05 15:53:50.517550000 +0000 @@ -255,7 +255,7 @@ * start the display after the beginning of the file, * and it is not appropriate to squish in that case. */ - if ((first_time || less_is_more) && + if ((first_time) && pos == NULL_POSITION && !top_scroll && #if TAGS tagoption == NULL && --- contrib/less/main.c.orig 2017-11-20 08:52:33.978356000 +0000 +++ contrib/less/main.c 2017-12-05 15:53:57.291394000 +0000 @@ -168,7 +168,10 @@ } if (less_is_more) + { no_init = TRUE; + scan_option("--tilde"); + } #if EDITOR editor = lgetenv("VISUAL"); From owner-freebsd-hackers@freebsd.org Wed Dec 6 22:04:26 2017 Return-Path: Delivered-To: freebsd-hackers@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 CFC9FE8D44A; Wed, 6 Dec 2017 22:04:26 +0000 (UTC) (envelope-from laurent@nuxi.ca) Received: from mail.nuxi.ca (nuxi.ca [142.44.162.10]) by mx1.freebsd.org (Postfix) with ESMTP id AD4EC64455; Wed, 6 Dec 2017 22:04:26 +0000 (UTC) (envelope-from laurent@nuxi.ca) Received: from [192.168.0.174] (modemcable058.143-202-24.mc.videotron.ca [24.202.143.58]) (Authenticated sender: laurent) by mail.nuxi.ca (Postfix) with ESMTPSA id 87FD320967; Wed, 6 Dec 2017 16:54:37 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: rpi2 hangup during poudriere build: lots of pfault wmseg status From: Laurent Cimon In-Reply-To: <05BEA04B-249B-4E7D-855A-46DA1A0DEA16@dsl-only.net> Date: Wed, 6 Dec 2017 16:54:36 -0500 Cc: freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <05BEA04B-249B-4E7D-855A-46DA1A0DEA16@dsl-only.net> To: Mark Millard X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 22:04:27 -0000 > On Dec 6, 2017, at 00:57, Mark Millard wrote: >=20 > I tried to build some ports on a rpi2 > (via poudriere) but it hung up: > Ethernet and normal console use. (Note: > the root file system is on a USB SSD > and the swap partition is also on that > USB SSD.) >=20 > But ~^b worked for getting to the db> > prompt on the console. >=20 > =46rom there a ps suggests that it got hung > up in pfault activity. (Possibly insufficient > RAM+swap-partition space?) But it is not > clear to me that it should end up hung up > vs. killing processes or other such. Hi, =46rom what I know the raspberry pis use the same controller for = ethernet and the USB hub on which you=E2=80=99re hosting an SSD. It seems like you = make very heavy use of the USB ports, and all of the resources used by poudriere except = for the CPU and the (very limited) memory that=E2=80=99s not in swap is attached = to them. If you really didn=E2=80=99t have enough memory and swap, the linkers = would=E2=80=99ve been stopped. I think it might just be a swap death. Poudriere compiles and fetches in = parallel a lot, ethernet and disk I/O is slow because it=E2=80=99s very limited, = so linking takes longer. You end up linking a few very big binaries at the same time, and = they all fight for the memory, to get out of swap through page faults, but = there are too many page faults, all too big, requesting for more CPU time = that=E2=80=99s allowed to them. This would explain why you have 3 linkers waiting on a page fault out of = the 4 CPUs poudriere allows builds on, on top of the awk processes. It would = also explain why you had easy access to the debugger: it was in memory = already with the kernel. I=E2=80=99d advise you to disable parallel builds and see if it happens = again, but it would make building much slower. Using makejobs would help if you can afford watching the build. Otherwise be patient, it should resolve = itself eventually, but it will take a while and it will happen again. Good luck, Laurent= From owner-freebsd-hackers@freebsd.org Wed Dec 6 22:23:41 2017 Return-Path: Delivered-To: freebsd-hackers@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 51440E8E1C7; Wed, 6 Dec 2017 22:23:41 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (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 C79216546A; Wed, 6 Dec 2017 22:23:40 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x241.google.com with SMTP id f20so6001013lfe.3; Wed, 06 Dec 2017 14:23:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=APkbrG3xZofywJ8qjIraM1jtmVUZ+pJLVuPWHilzzKI=; b=Lh8lp1s2d4t/cG1Hed9rbBezIpQpLfS7tlHIJ+/rLC3/inOXdGm/3uwyt5OO9W2AAs SsMJ36SmCQ83a3+hKcLkbWjaIy2ViekwF3oBX0tMu5SFbGpMHMQ1r1v9+VeeBfM42n57 q87YqOiYFrPiOp4HXfweWhol4YgrjMrPXjY+3UCUKLcENhwQyzaOf2CO1MgofxOLdno7 Gzigd5Jg3K6XTAPQBlw18nWhdgzAuJNbPvI8p6HCe/QqlapvmP2QJRWzyHQaWbme+6Na sH9KX/Vw7W/AQ+c8iFft9EgvJJ+E7j29uokIAyfsAXC4dm7LKhBe/u49BQkM1iYs6XJV e4KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=APkbrG3xZofywJ8qjIraM1jtmVUZ+pJLVuPWHilzzKI=; b=RpWHW6o71E3JVg0VPqKwfMAzlQ+qZ6MIAptuAvLka6lQoR0GmhcsBkvXsgql5tsPNw F87C8dWIOMiOv/SKd7RLGJ0Da9X7X0ITJuhUSTqCiCRn8gLsfJQsvZFWy6iNG9q92wsk YZ/DQ032W8EwgqO5mxbSzWBwcYEMIxAVK41b7P0TDGBKLPU+Q2xoWCFuLzvETZMR5NUV lDJ85SOskasD5EbB7ZePnRUjt7cVbwYTenvuu5933atyUbrvXpYeqKSgKdxWRZ9wyFRB jJfuVk1Tyzqz0u9DhitkN0jcSDvd8g/QHz4dR/vUPWTKmkcqwp732O9XjgEckD02XihY Yxrw== X-Gm-Message-State: AJaThX6nZKZyTIsW0PDv/zUjR1AE0jYsPH3K+iMIJmjq99J/ClK0vfTM Vr0e8tHZsPVB8J5BqRpGv6mv4XHqHgTcDhtNR3g= X-Google-Smtp-Source: AGs4zMbXTfM91peHPELjflGn3rKilQ5QJdTOlY6/DAkYeqeKM1j+Wg7Mfx5adwHvqp6s1LzlFxj4uT87ToYpC7AfwKM= X-Received: by 10.25.27.18 with SMTP id b18mr10864510lfb.177.1512599013965; Wed, 06 Dec 2017 14:23:33 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.76.19 with HTTP; Wed, 6 Dec 2017 14:23:33 -0800 (PST) In-Reply-To: <201712062204.vB6M4B03026339@donotpassgo.dyslexicfish.net> References: <620CD9B7-201A-46FD-8C9D-DD8DDA3A05C3@meetlost.com> <201712062204.vB6M4B03026339@donotpassgo.dyslexicfish.net> From: Alan Somers Date: Wed, 6 Dec 2017 15:23:33 -0700 X-Google-Sender-Auth: PbHdgm82FpjFJisFwVRSJ66iRhc Message-ID: Subject: Re: Strange behavior about pattern matching on manual pages [FIXED] To: Jamie Landeg-Jones Cc: FreeBSD CURRENT , "freebsd-hackers@freebsd.org" , by@meetlost.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 22:23:41 -0000 On Wed, Dec 6, 2017 at 3:04 PM, Jamie Landeg-Jones wrote: > by wrote: > > > Hi, > > > > I encounter a problem when viewing manuals via man(1) command. > > > > The case is simple, when I try to search something, I press =E2=80=98/= =E2=80=99, and > then input the pattern, If it got something in the page, it will direct m= e > into the specified place, and then, I continue with =E2=80=99n=E2=80=99, = and it goes well. > > But the problem is, after a sequence of =E2=80=99n=E2=80=99, the screen= go to the end of > the manual pages, and keeping press =E2=80=99n=E2=80=99, I got annoying = =E2=80=9C...skipping...=E2=80=9D, > the page is full of skipping and parts of the end of the manual page. > > Yes. This has been annoying me too - your email prompted me to finally wo= rk > on a fix for it! > > Firstly, it isn't man(1) itself - man(1) uses more(1) as the pager. > more(1) is in itself actually the program less(1), running in "more > emulation mode". > > And less(1) isn't FreeBSD native code - it's imported into the project > from http://www.greenwoodsoftware.com/less/ > > I noticed the very latest version of less(1) has been checked into > freebsd-current, and the issue still occurs there. > > Anyway, the fix is two small patches to less(1), please let me know > if they work for you, and if you see any bad side-effects in man(1) / > more(1) and less(1) and I'll then try and get them applied upstream. > > The patches have been tested against FreeBSD 11.1-STABLE and 12-CURRENT > > cheers! Jamie > > --- contrib/less/forwback.c.orig 2017-11-20 08:52:33.978356000 +00= 00 > +++ contrib/less/forwback.c 2017-12-05 15:53:50.517550000 +0000 > @@ -255,7 +255,7 @@ > * start the display after the beginning of the file, > * and it is not appropriate to squish in that case. > */ > - if ((first_time || less_is_more) && > + if ((first_time) && > pos =3D=3D NULL_POSITION && !top_scroll && > #if TAGS > tagoption =3D=3D NULL && > --- contrib/less/main.c.orig 2017-11-20 08:52:33.978356000 +0000 > +++ contrib/less/main.c 2017-12-05 15:53:57.291394000 +0000 > @@ -168,7 +168,10 @@ > } > > if (less_is_more) > + { > no_init =3D TRUE; > + scan_option("--tilde"); > + } > > #if EDITOR > editor =3D lgetenv("VISUAL"); > > How about just setting MANPAGER=3Dless in your environment? From owner-freebsd-hackers@freebsd.org Wed Dec 6 22:35:50 2017 Return-Path: Delivered-To: freebsd-hackers@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 004B6E8E86D; Wed, 6 Dec 2017 22:35:50 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:a:dead:bad:faff]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BE8F765E83; Wed, 6 Dec 2017 22:35:49 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id vB6MZmlY034659; Wed, 6 Dec 2017 22:35:48 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id vB6MZlQv034650; Wed, 6 Dec 2017 22:35:47 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201712062235.vB6MZlQv034650@donotpassgo.dyslexicfish.net> Date: Wed, 06 Dec 2017 22:35:47 +0000 Organization: Dyslexic Fish To: jamie@catflap.org, asomers@freebsd.org Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, by@meetlost.com Subject: Re: Strange behavior about pattern matching on manual pages [FIXED] References: <620CD9B7-201A-46FD-8C9D-DD8DDA3A05C3@meetlost.com> <201712062204.vB6M4B03026339@donotpassgo.dyslexicfish.net> In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Wed, 06 Dec 2017 22:35:48 +0000 (GMT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 22:35:50 -0000 Alan Somers wrote: > How about just setting MANPAGER=less in your environment? Because some of us prefer "more"? And as I said, it's related to searching using the more(1) command generally. I was under the impression that fixing bugs in existing commands was a better solution than telling someone to simply use something else. From owner-freebsd-hackers@freebsd.org Wed Dec 6 22:53:52 2017 Return-Path: Delivered-To: freebsd-hackers@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 0AC43E8EFDA; Wed, 6 Dec 2017 22:53:52 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 7CFC76692C; Wed, 6 Dec 2017 22:53:51 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x22c.google.com with SMTP id x20so6075711lff.1; Wed, 06 Dec 2017 14:53:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4WXC7h69CzMO1gwH2Rw5KbMmhC4SIBd3aGKANq5T/9Y=; b=u86CjR2RyZwFDjw/ZONYFRn/0kmOCHIbZzE/NKYdsjx7KaDMdWbRFfKaCVihMvAdOM TYPChf3ZqNCpgvKrYKbdj5RuJvFf8x1HHbqGM4DHjEgqC3OmNs1qo4fiGG3sR7RqTwNo ZEZfgtzJT/UzM6c7YjjzxGpmO9eNLscxbFzFnsiw5Y0g4y8sVhN8MpHnnYHHpGKEzOQJ vaPvB8Ia/1uSHivFORLV2N/0Ak3YtIb+8jgvaPDtJJuvIIR8/FAHdfKmZB+yalKxxoaX a0lGFK1DzBXTh+s7B9MRww2eNYz3BBv/Y7U+gnMJgesZ304zf5meACS8mJQZ3oSEM4Wt gqBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4WXC7h69CzMO1gwH2Rw5KbMmhC4SIBd3aGKANq5T/9Y=; b=Kq37Rx+injsY9v42xEa6AUiDe9jHw/eEJeYzeRjmgQEPmZ+cumq/GH56D/tKL7jWwC tr03ibjPBW5B4uJYcN7FhVV1ln4DEsGMYG/APgH3R4OzkSFqrKam5QDwoLyCjP+IowCh /OMMAd6nc5Y9OcRNPPU3g2D33WxjGB2gRRFpEtwvUWJihpWVx/uj/JEZeGNdkBFRyYwX dUaCdVC83XfizRe/t9RRl91d8aHVclvfxpWjfX2xJAUjAGm+ZuxIy7h14XnUqHZWTZ4R I/TyyPu+q/Ys/EtLM6iMzuw0MvNakQExJ2S9cGuVZ7zmQZKlwoLm7QYPlAoVWhZF0HRI 9fPQ== X-Gm-Message-State: AJaThX6KHcoa3xGTMvlCZbxrSHRrtVVgQ7qWjTDT/T4uA3XSAVNBBf0n 6ZQ1EyRGeWu4oJAhoWnwDL9qZsnkBmujr77lOlQ= X-Google-Smtp-Source: AGs4zMbbDEmW4tflTzEVzUMY8MOiHdoNJhxHo+VYilQR9fGG1ZTbOPP4rixW8WONz8KU5Pcb/uGBy4aLdKp3TcbJhi8= X-Received: by 10.25.27.18 with SMTP id b18mr10885802lfb.177.1512600824619; Wed, 06 Dec 2017 14:53:44 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.76.19 with HTTP; Wed, 6 Dec 2017 14:53:44 -0800 (PST) In-Reply-To: <201712062235.vB6MZlQv034650@donotpassgo.dyslexicfish.net> References: <620CD9B7-201A-46FD-8C9D-DD8DDA3A05C3@meetlost.com> <201712062204.vB6M4B03026339@donotpassgo.dyslexicfish.net> <201712062235.vB6MZlQv034650@donotpassgo.dyslexicfish.net> From: Alan Somers Date: Wed, 6 Dec 2017 15:53:44 -0700 X-Google-Sender-Auth: Nytb_VP6cwKrILV9mWvqZO4iNwg Message-ID: Subject: Re: Strange behavior about pattern matching on manual pages [FIXED] To: Jamie Landeg-Jones Cc: "freebsd-hackers@freebsd.org" , FreeBSD CURRENT , by@meetlost.com Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 22:53:52 -0000 On Wed, Dec 6, 2017 at 3:35 PM, Jamie Landeg-Jones wrote: > Alan Somers wrote: > > > How about just setting MANPAGER=less in your environment? > > Because some of us prefer "more"? > > And as I said, it's related to searching using the more(1) command > generally. > > I was under the impression that fixing bugs in existing commands was a > better > solution than telling someone to simply use something else. > Yes, it certainly is. Are you sure this is actually a bug in less, or is it just weird-but-intended behavior when less is emulating some old version of more? It would be worth comparing our less sources to upstream's to see what differences have crept in, and svn blaming them to see why. -Alan From owner-freebsd-hackers@freebsd.org Wed Dec 6 23:03:26 2017 Return-Path: Delivered-To: freebsd-hackers@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 5A33DE8F519; Wed, 6 Dec 2017 23:03:26 +0000 (UTC) (envelope-from by@meetlost.com) Received: from meetlost.com (freebsd.meetlost.com [IPv6:2403:2500:8000:1::962]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.meetlost.com", Issuer "mail.meetlost.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0952D66F94; Wed, 6 Dec 2017 23:03:25 +0000 (UTC) (envelope-from by@meetlost.com) Received: from [192.168.1.102] ([163.125.126.145]) (authenticated bits=0) by meetlost.com (8.15.2/8.15.2) with ESMTPSA id vB6N2wUN052275 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Dec 2017 07:02:59 +0800 (CST) (envelope-from by@meetlost.com) From: by Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Strange behavior about pattern matching on manual pages [FIXED] Date: Thu, 7 Dec 2017 07:03:13 +0800 In-Reply-To: Cc: Jamie Landeg-Jones , "freebsd-hackers@freebsd.org" , FreeBSD CURRENT To: Alan Somers References: <620CD9B7-201A-46FD-8C9D-DD8DDA3A05C3@meetlost.com> <201712062204.vB6M4B03026339@donotpassgo.dyslexicfish.net> <201712062235.vB6MZlQv034650@donotpassgo.dyslexicfish.net> X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 23:03:26 -0000 > =D4=DA 2017=C4=EA12=D4=C27=C8=D5=A3=AC06:53=A3=ACAlan Somers = =D0=B4=B5=C0=A3=BA >=20 > On Wed, Dec 6, 2017 at 3:35 PM, Jamie Landeg-Jones > wrote: > Alan Somers > wrote: >=20 > > How about just setting MANPAGER=3Dless in your environment? >=20 > Because some of us prefer "more"? >=20 > And as I said, it's related to searching using the more(1) command = generally. >=20 > I was under the impression that fixing bugs in existing commands was a = better > solution than telling someone to simply use something else. >=20 > Yes, it certainly is. Are you sure this is actually a bug in less, or = is it just weird-but-intended behavior when less is emulating some old = version of more? It would be worth comparing our less sources to = upstream's to see what differences have crept in, and svn blaming them = to see why. >=20 > -Alan I just test it in FreeBSD 11.1-RELEASE-p5 It works well when I change PAGER=3Dmore to PAGER=3Dless before man(1). And I found more(1) and less(1) is the same thing(they have the same = inode number laying in fs), may be just different command name, = different behavior. If it is emulating more(1) behavior by less(1), why not just replace = default PAGER=3Dless ? by= From owner-freebsd-hackers@freebsd.org Thu Dec 7 00:47:40 2017 Return-Path: Delivered-To: freebsd-hackers@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 9917CE9262F for ; Thu, 7 Dec 2017 00:47:40 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 666D46B2D9 for ; Thu, 7 Dec 2017 00:47:40 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id vB70lXRj053824 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 6 Dec 2017 16:47:33 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id vB70lXMK053823 for freebsd-hackers@freebsd.org; Wed, 6 Dec 2017 16:47:33 -0800 (PST) (envelope-from sgk) Date: Wed, 6 Dec 2017 16:47:33 -0800 From: Steve Kargl To: freebsd-hackers@freebsd.org Subject: SPDX tags in file? Message-ID: <20171207004733.GA53700@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 00:47:40 -0000 It seems that the application of SPDX license tags has been automated and done without reviewing whether the tag is correct. For example, the BSD-4-Clause tag has been placed in the files in lib/msun/bsdsrc. Given the UCB letter concerning removal of clauses 3 and 4, these files should probably have had the Copyright updated and a different SPDX clause applied. -- Steve From owner-freebsd-hackers@freebsd.org Thu Dec 7 01:28:25 2017 Return-Path: Delivered-To: freebsd-hackers@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 A4EF8E94B37 for ; Thu, 7 Dec 2017 01:28:25 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-149.reflexion.net [208.70.210.149]) (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 65ACC6D763 for ; Thu, 7 Dec 2017 01:28:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30726 invoked from network); 7 Dec 2017 01:01:38 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 7 Dec 2017 01:01:38 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Wed, 06 Dec 2017 20:01:38 -0500 (EST) Received: (qmail 11093 invoked from network); 7 Dec 2017 01:01:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Dec 2017 01:01:38 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D0409EC861A; Wed, 6 Dec 2017 17:01:37 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: rpi2 hangup during poudriere build: lots of pfault wmseg status From: Mark Millard In-Reply-To: Date: Wed, 6 Dec 2017 17:01:36 -0800 Cc: freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <36A8BDCC-4ECE-4187-8705-54A9E38E8AD5@dsl-only.net> References: <05BEA04B-249B-4E7D-855A-46DA1A0DEA16@dsl-only.net> To: Laurent Cimon X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 01:28:25 -0000 On 2017-Dec-6, at 1:54 PM, Laurent Cimon wrote: >> On Dec 6, 2017, at 00:57, Mark Millard = wrote: >>=20 >> I tried to build some ports on a rpi2 >> (via poudriere) but it hung up: >> Ethernet and normal console use. (Note: >> the root file system is on a USB SSD >> and the swap partition is also on that >> USB SSD.) >>=20 >> But ~^b worked for getting to the db> >> prompt on the console. >>=20 >> =46rom there a ps suggests that it got hung >> up in pfault activity. (Possibly insufficient >> RAM+swap-partition space?) But it is not >> clear to me that it should end up hung up >> vs. killing processes or other such. >=20 > Hi, >=20 > =46rom what I know the raspberry pis use the same controller for = ethernet and > the USB hub on which you=E2=80=99re hosting an SSD. It seems like you = make very heavy > use of the USB ports, and all of the resources used by poudriere = except for the > CPU and the (very limited) memory that=E2=80=99s not in swap is = attached to them. If you > really didn=E2=80=99t have enough memory and swap, the linkers = would=E2=80=99ve been stopped. >=20 > I think it might just be a swap death. Poudriere compiles and fetches = in parallel > a lot, ethernet and disk I/O is slow because it=E2=80=99s very = limited, so linking takes > longer. You end up linking a few very big binaries at the same time, = and they > all fight for the memory, to get out of swap through page faults, but = there > are too many page faults, all too big, requesting for more CPU time = that=E2=80=99s > allowed to them. >=20 > This would explain why you have 3 linkers waiting on a page fault out = of the 4 > CPUs poudriere allows builds on, on top of the awk processes. It would = also > explain why you had easy access to the debugger: it was in memory = already with > the kernel. >=20 > I=E2=80=99d advise you to disable parallel builds and see if it = happens again, > but it would make building much slower. Using makejobs would help if = you > can afford watching the build. Otherwise be patient, it should resolve = itself > eventually, but it will take a while and it will happen again. My post was more about how FreeBSD handled the heavy-use context and less about getting the builds to finish: it managed to to get to a state of no-progress for processes and a loss of normal control as far as I could tell. I did a "c" to ddb and left it until just before this note then did ~ ^B again. Things looked the same. [I've finally rebooted the rpi2.] PARALLEL_JOBS=3D1 was already in use but ALLOW_MAKE_JOBS=3Dyes was also in use. USE_TMPFS=3Dno was already in use. While an ssh session was monitoring the build, Ethernet was not in heavy use. (No nfs mounts to its disks, for example.) I may try without ALLOW_MAKE_JOBS=3Dyes and with ALLOW_MAKE_JOBS_PACKAGES empty/undefined to see if it can complete for such a context without having the same sort of problem. Ultimately I can cross-build and install from those materials when I really want updates. I have the context for such. This was more about seeing how well the rpi2 did for self-hosted. Classically I've used a BPI-M3 with 2 GiBytes of RAM and a proportionally bigger swap partition instead (approximately). FYI (rpi2 after rebooting): # swapinfo Device 1K-blocks Used Avail Capacity /dev/label/RPI2swap 1572860 0 1572860 0% # df -m Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/ufs/RPI2rootfs 195378 30791 148957 17% / devfs 0 0 0 100% /dev /dev/label/RPI2Aboot 49 12 37 25% /boot/msdos An rpi3 (aarch64) with the same amount of RAM, same type of USB SSD, etc., but well more swap completed building basically the same set of ports for the same poudriere settings just fine. Interestingly for the default kern.maxswzone: (Just to show the reported recommended maximum figures for swap.) rpi2: . . . exceeds maximum recommended amount (411488 pages). rpi3: . . . exceeds maximum recommended amount (925680 pages). (I was running with somewhat under those maximums for the tests.) # swapinfo Device 1K-blocks Used Avail Capacity /dev/gpt/RPI3swap 3702784 0 3702784 0% # df -m Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/ufs/RPI3rootfs 195378 14937 164811 8% / devfs 0 0 0 100% /dev /dev/label/RPI3Aboot 49 7 42 15% /boot/efi If I restricted the rpi3 to somewhat under what the rpi2 allows for swap, I do not know if it would also hang up vs. not. If having more swap makes the difference, then it would not seem to be being I/O-bound that would explain the hangup. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Thu Dec 7 01:47:16 2017 Return-Path: Delivered-To: freebsd-hackers@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 80ACDE95830; Thu, 7 Dec 2017 01:47:16 +0000 (UTC) (envelope-from laurent@nuxi.ca) Received: from mail.nuxi.ca (nuxi.ca [142.44.162.10]) by mx1.freebsd.org (Postfix) with ESMTP id 322B06E422; Thu, 7 Dec 2017 01:47:15 +0000 (UTC) (envelope-from laurent@nuxi.ca) Received: from [192.168.0.174] (modemcable058.143-202-24.mc.videotron.ca [24.202.143.58]) (Authenticated sender: laurent) by mail.nuxi.ca (Postfix) with ESMTPSA id 24575209E2; Wed, 6 Dec 2017 20:47:14 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: rpi2 hangup during poudriere build: lots of pfault wmseg status From: Laurent Cimon In-Reply-To: <36A8BDCC-4ECE-4187-8705-54A9E38E8AD5@dsl-only.net> Date: Wed, 6 Dec 2017 20:47:12 -0500 Cc: freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5014B6E6-68BA-4499-8728-EF80237F3269@nuxi.ca> References: <05BEA04B-249B-4E7D-855A-46DA1A0DEA16@dsl-only.net> <36A8BDCC-4ECE-4187-8705-54A9E38E8AD5@dsl-only.net> To: Mark Millard X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 01:47:16 -0000 > On Dec 6, 2017, at 20:01, Mark Millard wrote: >=20 > On 2017-Dec-6, at 1:54 PM, Laurent Cimon wrote: >=20 >>> On Dec 6, 2017, at 00:57, Mark Millard = wrote: >>>=20 >>> I tried to build some ports on a rpi2 >>> (via poudriere) but it hung up: >>> Ethernet and normal console use. (Note: >>> the root file system is on a USB SSD >>> and the swap partition is also on that >>> USB SSD.) >>>=20 >>> But ~^b worked for getting to the db> >>> prompt on the console. >>>=20 >>> =46rom there a ps suggests that it got hung >>> up in pfault activity. (Possibly insufficient >>> RAM+swap-partition space?) But it is not >>> clear to me that it should end up hung up >>> vs. killing processes or other such. >>=20 >> Hi, >>=20 >> =46rom what I know the raspberry pis use the same controller for = ethernet and >> the USB hub on which you=E2=80=99re hosting an SSD. It seems like you = make very heavy >> use of the USB ports, and all of the resources used by poudriere = except for the >> CPU and the (very limited) memory that=E2=80=99s not in swap is = attached to them. If you >> really didn=E2=80=99t have enough memory and swap, the linkers = would=E2=80=99ve been stopped. >>=20 >> I think it might just be a swap death. Poudriere compiles and fetches = in parallel >> a lot, ethernet and disk I/O is slow because it=E2=80=99s very = limited, so linking takes >> longer. You end up linking a few very big binaries at the same time, = and they >> all fight for the memory, to get out of swap through page faults, but = there >> are too many page faults, all too big, requesting for more CPU time = that=E2=80=99s >> allowed to them. >>=20 >> This would explain why you have 3 linkers waiting on a page fault out = of the 4 >> CPUs poudriere allows builds on, on top of the awk processes. It = would also >> explain why you had easy access to the debugger: it was in memory = already with >> the kernel. >>=20 >> I=E2=80=99d advise you to disable parallel builds and see if it = happens again, >> but it would make building much slower. Using makejobs would help if = you >> can afford watching the build. Otherwise be patient, it should = resolve itself >> eventually, but it will take a while and it will happen again. >=20 > My post was more about how FreeBSD handled the > heavy-use context and less about getting the > builds to finish: it managed to to get to a > state of no-progress for processes and a loss > of normal control as far as I could tell. >=20 > I did a "c" to ddb and left it until just before > this note then did ~ ^B again. Things looked the > same. [I've finally rebooted the rpi2.] >=20 > PARALLEL_JOBS=3D1 was already in use but > ALLOW_MAKE_JOBS=3Dyes was also in use. > USE_TMPFS=3Dno was already in use. >=20 > While an ssh session was monitoring the > build, Ethernet was not in heavy use. > (No nfs mounts to its disks, for example.) >=20 > I may try without ALLOW_MAKE_JOBS=3Dyes and > with ALLOW_MAKE_JOBS_PACKAGES empty/undefined > to see if it can complete for such a context > without having the same sort of problem. >=20 > Ultimately I can cross-build and install from > those materials when I really want updates. I > have the context for such. This was more about > seeing how well the rpi2 did for self-hosted. > Classically I've used a BPI-M3 with 2 GiBytes > of RAM and a proportionally bigger swap partition > instead (approximately). >=20 >=20 > FYI (rpi2 after rebooting): >=20 > # swapinfo > Device 1K-blocks Used Avail Capacity > /dev/label/RPI2swap 1572860 0 1572860 0% >=20 > # df -m > Filesystem 1M-blocks Used Avail Capacity Mounted on > /dev/ufs/RPI2rootfs 195378 30791 148957 17% / > devfs 0 0 0 100% /dev > /dev/label/RPI2Aboot 49 12 37 25% /boot/msdos >=20 >=20 > An rpi3 (aarch64) with the same amount of RAM, > same type of USB SSD, etc., but well more swap > completed building basically the same set of > ports for the same poudriere settings just > fine. >=20 > Interestingly for the default kern.maxswzone: > (Just to show the reported recommended maximum > figures for swap.) >=20 > rpi2: . . . exceeds maximum recommended amount (411488 pages). > rpi3: . . . exceeds maximum recommended amount (925680 pages). >=20 > (I was running with somewhat under those maximums for > the tests.) >=20 > # swapinfo > Device 1K-blocks Used Avail Capacity > /dev/gpt/RPI3swap 3702784 0 3702784 0% >=20 > # df -m > Filesystem 1M-blocks Used Avail Capacity Mounted on > /dev/ufs/RPI3rootfs 195378 14937 164811 8% / > devfs 0 0 0 100% /dev > /dev/label/RPI3Aboot 49 7 42 15% /boot/efi >=20 > If I restricted the rpi3 to somewhat under what the > rpi2 allows for swap, I do not know if it would also > hang up vs. not. >=20 > If having more swap makes the difference, then it > would not seem to be being I/O-bound that would > explain the hangup. >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net There are a few factors that could have prevented this on your raspberry = pi 3. It has a faster, 64 bit CPU instead of the raspberry pi 2=E2=80=99s 32 = bit CPU and the RAM is twice as fast. These make it less likely for this to happen, = because it makes both building and linking faster, which reduces the odds of = linking 2 binaries at once, let alone 3. There are many things that could have = gone differently in the build that didn=E2=80=99t make it end up linking 3 = big binaries at the same time to cause the same behaviour. What I think happened on your raspberry pi 2 is just likely bad luck = that could also happen on your raspberry pi 3. The odds of 3 parallel builds = needing so much ram to link at the exact same time are still very low, just less = low on faster hardware. Keep in mind that this is still entirely theoretical, I don=E2=80=99t = present it as an absolute explanation. It=E2=80=99s simply what I understand from this. I=E2=80=99d be curious seeing how a different operating system using a = system similar to poudriere where builds are done on one CPU but in parallel would be = handled on the rpi2. My understanding is that this is simply a mix of hardware = limitation and conceptual flaws with the swap. And by flaws I mean, your operating = system cannot save you when you try to do something that your hardware cannot = possibly do. Laurent= From owner-freebsd-hackers@freebsd.org Thu Dec 7 02:27:15 2017 Return-Path: Delivered-To: freebsd-hackers@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 33ED4E97B21 for ; Thu, 7 Dec 2017 02:27:15 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from sonic312-37.consmr.mail.ne1.yahoo.com (sonic312-37.consmr.mail.ne1.yahoo.com [66.163.191.218]) (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 0473A70719 for ; Thu, 7 Dec 2017 02:27:14 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1512613633; bh=y0Xpi0XofoXrEDm/BqIlm3glJYA4ocN9NtQ2+s3Uf9o=; h=To:Cc:From:Subject:Date:From:Subject; b=IvxAYrPdjq0MAXLRUGr/uzFL0+NwzxGk0hV04mpZ9ppXJMxpeMJE+oxzg9T+8AWirwlWSHOfsBgrOGbZ/yLOR8R/gO9sUyUTbUdul6M/TaTiiMmUsKQgJvU+kuiTBxS+zfVEkIml2QUUmHEy4+gs62ZFyul5eE1DsjyeKLpC9tXgeyUGQ27x1yFywCkt0N9EvDm+3YUcc14T6CWkdEfjLLd4rUWYPLKNfu/p8rYWxoao3+7V9NKZZv4cxR9JBijeLvJrSPNGuG0Ofpy5nbf+xARmbjLXtoMvtV8Dcro9jjWyYPAzUYs+9pxZ5liR5I8bjRmpmDNfuCMiRcGcmjoz/g== X-YMail-OSG: xD7ZWQAVM1nMxo04LfY2Y17T3NEscdfL5SBGP43fADAAzDVfrt6xwzwgpzJBr12 DoY65rvdXyghgwNAqVopc501ZCcilR5uIvrykxYnhZORRJgebdxqyuxsaPtiFQ806Jv4Ue.UmWjZ gZQeX34OkeoiJpj_VBJvX6IV62mAmyBD1mCM6oTbv.cfsEAmleSs2Uf4Q3m_YhCuJa_16OQo.qGz t8DiVPVnSoxnnGAdZYyOjC41QIowCXBv2DHoIs4bFTcnOxFF2yMS5ZZkaIFd90nQTnVNhS98gofH 0oCLhgXzkrTvgJQRd5uEpDDIHSn9nuj6s5xF2lVgqSHP8D1BXKsj2haO2Vbvf6YRxg4sNR9fX7il AgaiH3jkwaQ6.L0pEpf2iqFIeaTh7HX0atqgextzoN4YQhVCVyIQgnHw1XS.IyBN7XURdoUi4e4h MpeMomNAX28M87TwPYSEObyRyPDEgiKtGbwgSc4LDFQszEqteLc0Q2IQtHdhVjK8Is65lz_QL Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ne1.yahoo.com with HTTP; Thu, 7 Dec 2017 02:27:13 +0000 Received: from smtp235.mail.ne1.yahoo.com (EHLO [192.168.0.5]) ([10.218.253.206]) by smtp401.mail.ne1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID -462464354; Thu, 07 Dec 2017 02:17:06 +0000 (UTC) To: FreeBSD Hackers Cc: Steve Kargl From: Pedro Giffuni Subject: Re: SPDX tags in file? Organization: FreeBSD Project Message-ID: <4247a923-a297-1626-a576-a13651da90ab@FreeBSD.org> Date: Wed, 6 Dec 2017 21:17:06 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 02:27:15 -0000 Hi Steve; > It seems that the application of SPDX license tags > has been automated and done without reviewing whether > the tag is correct. For example, the BSD-4-Clause > tag has been placed in the files in lib/msun/bsdsrc. > Given the UCB letter concerning removal of clauses > 3 and 4, these files should probably have had the > Copyright updated and a different SPDX clause applied. > > -- > Steve The initial sweep was done manually, but as you might have noticed, it covered a lot of files and mistakes are certainly possible. The idea at this time is/was not to replace licenses: I am not a lawyer but I think we may have to look at who has touched a file before doing any license change. That may be a complex process. This said. checking for bsd-4-clause is a pretty good opportunity to review and modernize code. If the code comes from another BSD (and particularly NetBSD as I noticed during the sweep), it is likely upstream has updated the license as well and there may be interesting changes involved. Pedro. From owner-freebsd-hackers@freebsd.org Thu Dec 7 03:57:05 2017 Return-Path: Delivered-To: freebsd-hackers@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 2FA68E9B256 for ; Thu, 7 Dec 2017 03:57:05 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EF9B3740BF; Thu, 7 Dec 2017 03:57:04 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id vB73v4Jv055064 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 6 Dec 2017 19:57:04 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id vB73v4DI055063; Wed, 6 Dec 2017 19:57:04 -0800 (PST) (envelope-from sgk) Date: Wed, 6 Dec 2017 19:57:04 -0800 From: Steve Kargl To: Pedro Giffuni Cc: FreeBSD Hackers Subject: Re: SPDX tags in file? Message-ID: <20171207035704.GA54501@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <4247a923-a297-1626-a576-a13651da90ab@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4247a923-a297-1626-a576-a13651da90ab@FreeBSD.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 03:57:05 -0000 On Wed, Dec 06, 2017 at 09:17:06PM -0500, Pedro Giffuni wrote: > > > It seems that the application of SPDX license tags > > has been automated and done without reviewing whether > > the tag is correct. For example, the BSD-4-Clause > > tag has been placed in the files in lib/msun/bsdsrc. > > Given the UCB letter concerning removal of clauses > > 3 and 4, these files should probably have had the > > Copyright updated and a different SPDX clause applied. > > > > -- > > Steve > > The initial sweep was done manually, but as you might have noticed, it > covered a lot of files and mistakes are certainly possible. > > The idea at this time is/was not to replace licenses: I am not a lawyer > but I think we may have to look at who has touched a file before doing > any license change. That may be a complex process. > > This said. checking for bsd-4-clause is a pretty good opportunity to > review and modernize code. If the code comes from another BSD (and > particularly NetBSD as I noticed during the sweep), it is likely > upstream has updated the license as well and there may be interesting > changes involved. > Not all revisions apply to all four files r1573 rgrimes BSD 4.4 Lite r8870 rgrimes Trailing whitespace r84210 dillon Add __FBSDID r92887 obrien Fix SCM ID's r92917 obrien Remove __P() usage. r93211 bde Resurrect Lite1 r97407 keramida Assume __STDC__ r108533 schweikh Typos and whitespace r129312 stefanf Remove some kludges (use C99 hexadecimal constant) r138924 das Cosmetic changes only r138925 das GC unused declaration r150318 bde Fixed aliasing bugs in TRUNC() r152566 bde Removed an unused declaration and style bugs r169209 bde Document current (slightly broken) handling of special values r169212 bde Fix tgamma() on some special args r176449 das Eliminate some warnings r226414 das Fix some non-standard variable declarations. r325966 pfg spdx If you don't count UCB as upstream (aka r1573), then FreeBSD is upstream. Looking at NetBSD the commit message for b_tgamma.c is "Add tgamma{,f} from FreeBSD via rudolf, netbsd at eq dot cz". OpenBSD is a little more complicated, but its initial version appeared in 2008 while FreeBSD's appeard in 1994. IMHO (non-lawyer) opinion, the only thing that might rise to the level of Copyright-able material would be r169212. Bruce did not add his name as he has done elsewhere. BTW, OpenBSD uses a 3-clause BSD license. -- Steve From owner-freebsd-hackers@freebsd.org Thu Dec 7 04:17:43 2017 Return-Path: Delivered-To: freebsd-hackers@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 620B8E9BCD7 for ; Thu, 7 Dec 2017 04:17:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-163.reflexion.net [208.70.210.163]) (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 10C5474C9C for ; Thu, 7 Dec 2017 04:17:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18867 invoked from network); 7 Dec 2017 04:17:35 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 7 Dec 2017 04:17:35 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Wed, 06 Dec 2017 23:17:35 -0500 (EST) Received: (qmail 22177 invoked from network); 7 Dec 2017 04:17:35 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Dec 2017 04:17:35 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E7D79EC9524; Wed, 6 Dec 2017 20:17:34 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: SPDX tags in file? From: Mark Millard In-Reply-To: <20171207035704.GA54501@troutmask.apl.washington.edu> Date: Wed, 6 Dec 2017 20:17:34 -0800 Cc: Pedro Giffuni , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <09278744-3D5C-4B8A-9134-934F9CCA1FF0@dsl-only.net> References: <4247a923-a297-1626-a576-a13651da90ab@FreeBSD.org> <20171207035704.GA54501@troutmask.apl.washington.edu> To: sgk@troutmask.apl.washington.edu X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 04:17:43 -0000 On 2017-Dec-6, at 7:57 PM, Steve Kargl wrote: > On Wed, Dec 06, 2017 at 09:17:06PM -0500, Pedro Giffuni wrote: >>=20 >>> It seems that the application of SPDX license tags >>> has been automated and done without reviewing whether >>> the tag is correct. For example, the BSD-4-Clause >>> tag has been placed in the files in lib/msun/bsdsrc. >>> Given the UCB letter concerning removal of clauses >>> 3 and 4, these files should probably have had the >>> Copyright updated and a different SPDX clause applied. >>>=20 >>> --=20 >>> Steve >>=20 >> The initial sweep was done manually, but as you might have noticed, = it=20 >> covered a lot of files and mistakes are certainly possible. >>=20 >> The idea at this time is/was not to replace licenses: I am not a = lawyer=20 >> but I think we may have to look at who has touched a file before = doing=20 >> any license change. That may be a complex process. >>=20 >> This said. checking for bsd-4-clause is a pretty good opportunity to=20= >> review and modernize code. If the code comes from another BSD (and=20 >> particularly NetBSD as I noticed during the sweep), it is likely=20 >> upstream has updated the license as well and there may be interesting=20= >> changes involved. >>=20 >=20 > Not all revisions apply to all four files >=20 > r1573 rgrimes BSD 4.4 Lite > r8870 rgrimes Trailing whitespace > r84210 dillon Add __FBSDID > r92887 obrien Fix SCM ID's > r92917 obrien Remove __P() usage. > r93211 bde Resurrect Lite1 > r97407 keramida Assume __STDC__ > r108533 schweikh Typos and whitespace > r129312 stefanf Remove some kludges (use C99 hexadecimal constant) > r138924 das Cosmetic changes only > r138925 das GC unused declaration > r150318 bde Fixed aliasing bugs in TRUNC() > r152566 bde Removed an unused declaration and style bugs > r169209 bde Document current (slightly broken) handling of = special values > r169212 bde Fix tgamma() on some special args > r176449 das Eliminate some warnings > r226414 das Fix some non-standard variable declarations. > r325966 pfg spdx >=20 > If you don't count UCB as upstream (aka r1573), then FreeBSD is > upstream. Looking at NetBSD the commit message for b_tgamma.c > is "Add tgamma{,f} from FreeBSD via rudolf, netbsd at eq dot cz". > OpenBSD is a little more complicated, but its initial version=20 > appeared in 2008 while FreeBSD's appeard in 1994. >=20 > IMHO (non-lawyer) opinion, the only thing that might rise to the > level of Copyright-able material would be r169212. Bruce did not > add his name as he has done elsewhere. >=20 > BTW, OpenBSD uses a 3-clause BSD license. That prompted an old memory about newer code for OpenBSD so I took a look. . . https://www.openbsd.org/policy.html says: ISC The ISC copyright is functionally equivalent to a two-term BSD copyright with language removed that is made unnecessary by the Berne convention. This is the preferred license for new code incorporated into OpenBSD. A sample license is available in the file /usr/share/misc/license.template. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Thu Dec 7 05:00:20 2017 Return-Path: Delivered-To: freebsd-hackers@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 966EFE9CDEA for ; Thu, 7 Dec 2017 05:00:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-125.reflexion.net [208.70.210.125]) (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 594357605B for ; Thu, 7 Dec 2017 05:00:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29613 invoked from network); 7 Dec 2017 05:00:13 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 7 Dec 2017 05:00:13 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 07 Dec 2017 00:00:13 -0500 (EST) Received: (qmail 2504 invoked from network); 7 Dec 2017 05:00:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Dec 2017 05:00:13 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7F00BEC932D; Wed, 6 Dec 2017 21:00:12 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: rpi2 hangup during poudriere build: lots of pfault wmseg status From: Mark Millard In-Reply-To: <5014B6E6-68BA-4499-8728-EF80237F3269@nuxi.ca> Date: Wed, 6 Dec 2017 21:00:11 -0800 Cc: freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <05BEA04B-249B-4E7D-855A-46DA1A0DEA16@dsl-only.net> <36A8BDCC-4ECE-4187-8705-54A9E38E8AD5@dsl-only.net> <5014B6E6-68BA-4499-8728-EF80237F3269@nuxi.ca> To: Laurent Cimon X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 05:00:20 -0000 > On 2017-Dec-6, at 5:47 PM, Laurent Cimon wrote: >=20 >> On Dec 6, 2017, at 20:01, Mark Millard = wrote: >>=20 >> On 2017-Dec-6, at 1:54 PM, Laurent Cimon wrote: >>=20 >>>> On Dec 6, 2017, at 00:57, Mark Millard = wrote: >>>>=20 >>>> I tried to build some ports on a rpi2 >>>> (via poudriere) but it hung up: >>>> Ethernet and normal console use. (Note: >>>> the root file system is on a USB SSD >>>> and the swap partition is also on that >>>> USB SSD.) >>>>=20 >>>> But ~^b worked for getting to the db> >>>> prompt on the console. >>>>=20 >>>> =46rom there a ps suggests that it got hung >>>> up in pfault activity. (Possibly insufficient >>>> RAM+swap-partition space?) But it is not >>>> clear to me that it should end up hung up >>>> vs. killing processes or other such. >>>=20 >>> Hi, >>>=20 >>> =46rom what I know the raspberry pis use the same controller for = ethernet and >>> the USB hub on which you=E2=80=99re hosting an SSD. It seems like = you make very heavy >>> use of the USB ports, and all of the resources used by poudriere = except for the >>> CPU and the (very limited) memory that=E2=80=99s not in swap is = attached to them. If you >>> really didn=E2=80=99t have enough memory and swap, the linkers = would=E2=80=99ve been stopped. >>>=20 >>> I think it might just be a swap death. Poudriere compiles and = fetches in parallel >>> a lot, ethernet and disk I/O is slow because it=E2=80=99s very = limited, so linking takes >>> longer. You end up linking a few very big binaries at the same time, = and they >>> all fight for the memory, to get out of swap through page faults, = but there >>> are too many page faults, all too big, requesting for more CPU time = that=E2=80=99s >>> allowed to them. >>>=20 >>> This would explain why you have 3 linkers waiting on a page fault = out of the 4 >>> CPUs poudriere allows builds on, on top of the awk processes. It = would also >>> explain why you had easy access to the debugger: it was in memory = already with >>> the kernel. >>>=20 >>> I=E2=80=99d advise you to disable parallel builds and see if it = happens again, >>> but it would make building much slower. Using makejobs would help if = you >>> can afford watching the build. Otherwise be patient, it should = resolve itself >>> eventually, but it will take a while and it will happen again. >>=20 >> My post was more about how FreeBSD handled the >> heavy-use context and less about getting the >> builds to finish: it managed to to get to a >> state of no-progress for processes and a loss >> of normal control as far as I could tell. >>=20 >> I did a "c" to ddb and left it until just before >> this note then did ~ ^B again. Things looked the >> same. [I've finally rebooted the rpi2.] >>=20 >> PARALLEL_JOBS=3D1 was already in use but >> ALLOW_MAKE_JOBS=3Dyes was also in use. >> USE_TMPFS=3Dno was already in use. >>=20 >> While an ssh session was monitoring the >> build, Ethernet was not in heavy use. >> (No nfs mounts to its disks, for example.) >>=20 >> I may try without ALLOW_MAKE_JOBS=3Dyes and >> with ALLOW_MAKE_JOBS_PACKAGES empty/undefined >> to see if it can complete for such a context >> without having the same sort of problem. >>=20 >> Ultimately I can cross-build and install from >> those materials when I really want updates. I >> have the context for such. This was more about >> seeing how well the rpi2 did for self-hosted. >> Classically I've used a BPI-M3 with 2 GiBytes >> of RAM and a proportionally bigger swap partition >> instead (approximately). >>=20 >>=20 >> FYI (rpi2 after rebooting): >>=20 >> # swapinfo >> Device 1K-blocks Used Avail Capacity >> /dev/label/RPI2swap 1572860 0 1572860 0% >>=20 >> # df -m >> Filesystem 1M-blocks Used Avail Capacity Mounted on >> /dev/ufs/RPI2rootfs 195378 30791 148957 17% / >> devfs 0 0 0 100% /dev >> /dev/label/RPI2Aboot 49 12 37 25% /boot/msdos >>=20 >>=20 >> An rpi3 (aarch64) with the same amount of RAM, >> same type of USB SSD, etc., but well more swap >> completed building basically the same set of >> ports for the same poudriere settings just >> fine. >>=20 >> Interestingly for the default kern.maxswzone: >> (Just to show the reported recommended maximum >> figures for swap.) >>=20 >> rpi2: . . . exceeds maximum recommended amount (411488 pages). >> rpi3: . . . exceeds maximum recommended amount (925680 pages). >>=20 >> (I was running with somewhat under those maximums for >> the tests.) >>=20 >> # swapinfo >> Device 1K-blocks Used Avail Capacity >> /dev/gpt/RPI3swap 3702784 0 3702784 0% >>=20 >> # df -m >> Filesystem 1M-blocks Used Avail Capacity Mounted on >> /dev/ufs/RPI3rootfs 195378 14937 164811 8% / >> devfs 0 0 0 100% /dev >> /dev/label/RPI3Aboot 49 7 42 15% /boot/efi >>=20 >> If I restricted the rpi3 to somewhat under what the >> rpi2 allows for swap, I do not know if it would also >> hang up vs. not. >>=20 >> If having more swap makes the difference, then it >> would not seem to be being I/O-bound that would >> explain the hangup. >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > There are a few factors that could have prevented this on your = raspberry pi 3. >=20 > It has a faster, 64 bit CPU instead of the raspberry pi 2=E2=80=99s 32 = bit CPU and the > RAM is twice as fast. These make it less likely for this to happen, = because it > makes both building and linking faster, which reduces the odds of = linking 2 > binaries at once, let alone 3. There are many things that could have = gone > differently in the build that didn=E2=80=99t make it end up linking 3 = big binaries at > the same time to cause the same behaviour. >=20 > What I think happened on your raspberry pi 2 is just likely bad luck = that could > also happen on your raspberry pi 3. The odds of 3 parallel builds = needing so > much ram to link at the exact same time are still very low, just less = low on > faster hardware. >=20 > Keep in mind that this is still entirely theoretical, I don=E2=80=99t = present it as an > absolute explanation. It=E2=80=99s simply what I understand from this. >=20 > I=E2=80=99d be curious seeing how a different operating system using a = system similar to > poudriere where builds are done on one CPU but in parallel would be = handled on > the rpi2. My understanding is that this is simply a mix of hardware = limitation > and conceptual flaws with the swap. And by flaws I mean, your = operating system > cannot save you when you try to do something that your hardware cannot = possibly > do. For reference: The rpi2 hung up during: [08:00:15] [01] [00:00:00] Building devel/binutils | binutils-2.28,1 (Only one builder, no prior builds should matter. All 4 cores allowed.) On the rpi3 this was: [08:13:38] [01] [00:00:00] Building devel/binutils | binutils-2.28,1 [10:17:12] [01] [02:03:34] Finished devel/binutils | binutils-2.28,1: = Success (Only one builder, no prior or following builds should matter. All 4 cores allowed.) Comparing a couple of examples that both completed: rpi2: [00:43:40] [01] [00:00:00] Building lang/perl5.24 | perl5-5.24.3 [01:38:37] [01] [00:54:57] Finished lang/perl5.24 | perl5-5.24.3: = Success vs. rpi3: [00:26:35] [01] [00:00:00] Building lang/perl5.24 | perl5-5.24.3 [00:56:14] [01] [00:29:39] Finished lang/perl5.24 | perl5-5.24.3: = Success rpi2: [07:12:51] [01] [00:00:00] Building databases/sqlite3 | sqlite3-3.21.0_1 [07:59:04] [01] [00:46:13] Finished databases/sqlite3 | = sqlite3-3.21.0_1: Success vs. rpi3: [07:43:31] [01] [00:00:00] Building databases/sqlite3 | sqlite3-3.21.0_1 [08:13:35] [01] [00:30:04] Finished databases/sqlite3 | = sqlite3-3.21.0_1: Success The rpi2 lasting days longer than the rpi3 2hr figure for devel/binutils is likely out of scale for processor and RAM differences in speed. (The USB-tied performance likely is not all that different.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Thu Dec 7 19:59:16 2017 Return-Path: Delivered-To: freebsd-hackers@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 48650E8FA24; Thu, 7 Dec 2017 19:59:16 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E4397366D; Thu, 7 Dec 2017 19:59:16 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id vB7JxFPA096237 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Dec 2017 11:59:15 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id vB7JxFSM096236; Thu, 7 Dec 2017 11:59:15 -0800 (PST) (envelope-from sgk) Date: Thu, 7 Dec 2017 11:59:15 -0800 From: Steve Kargl To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: [PATCH] update math.3 for reality Message-ID: <20171207195915.GA96227@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 19:59:16 -0000 The following patch updates math.3 to reflect the current state of reality. Index: msun/man/math.3 =================================================================== --- msun/man/math.3 (revision 2046) +++ msun/man/math.3 (working copy) @@ -28,7 +28,7 @@ .\" from: @(#)math.3 6.10 (Berkeley) 5/6/91 .\" $FreeBSD: head/lib/msun/man/math.3 226460 2011-10-17 06:10:32Z das $ .\" -.Dd December 5, 2010 +.Dd December 7, 2017 .Dt MATH 3 .Os .Sh NAME @@ -235,12 +235,6 @@ .Vt long double values, were written for or imported into subsequent versions of FreeBSD. .Sh BUGS -Some of the -.Vt "long double" -math functions in -.St -isoC-99 -are not available. -.Pp Many of the routines to compute transcendental functions produce inaccurate results in other than the default rounding mode. .Pp -- Steve From owner-freebsd-hackers@freebsd.org Thu Dec 7 20:03:20 2017 Return-Path: Delivered-To: freebsd-hackers@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 C2FAFE8FE62; Thu, 7 Dec 2017 20:03:20 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F78473E87; Thu, 7 Dec 2017 20:03:20 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id vB7K3JmW096331 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Dec 2017 12:03:19 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id vB7K3JKj096330; Thu, 7 Dec 2017 12:03:19 -0800 (PST) (envelope-from sgk) Date: Thu, 7 Dec 2017 12:03:19 -0800 From: Steve Kargl To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: [PATCH] Remove unused include file Message-ID: <20171207200319.GA96323@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 20:03:20 -0000 The following patch removes an unused include. Index: msun/bsdsrc/b_log.c =================================================================== --- msun/bsdsrc/b_log.c (revision 2046) +++ msun/bsdsrc/b_log.c (working copy) @@ -36,7 +36,6 @@ __FBSDID("$FreeBSD: head/lib/msun/bsdsrc/b_log.c 176449 2008-02-22 02:26:51Z das $"); #include -#include #include "mathimpl.h" -- Steve From owner-freebsd-hackers@freebsd.org Thu Dec 7 20:49:36 2017 Return-Path: Delivered-To: freebsd-hackers@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 7ADC3E90EA9; Thu, 7 Dec 2017 20:49:36 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C2AA7586B; Thu, 7 Dec 2017 20:49:35 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DED151C9E6; Thu, 7 Dec 2017 21:42:35 +0100 (CET) From: Dimitry Andric Message-Id: <334CF113-1392-4318-B9E0-82C0D90C5C19@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_72A04102-1371-42ED-AACF-FBACD5F44A93"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH] update math.3 for reality Date: Thu, 7 Dec 2017 21:42:35 +0100 In-Reply-To: <20171207195915.GA96227@troutmask.apl.washington.edu> Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org To: sgk@troutmask.apl.washington.edu References: <20171207195915.GA96227@troutmask.apl.washington.edu> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 20:49:36 -0000 --Apple-Mail=_72A04102-1371-42ED-AACF-FBACD5F44A93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 7 Dec 2017, at 20:59, Steve Kargl = wrote: > The following patch updates math.3 to reflect the current > state of reality. >=20 > Index: msun/man/math.3 Thanks, committed in r326669. -Dimitry --Apple-Mail=_72A04102-1371-42ED-AACF-FBACD5F44A93 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWimnuwAKCRCwXqMKLiCW ozR3AJsHfi9STm94fDJLImwdTAJT254kbQCePsr9sWt7uPgi2knBI3D3S918mDQ= =DziV -----END PGP SIGNATURE----- --Apple-Mail=_72A04102-1371-42ED-AACF-FBACD5F44A93-- From owner-freebsd-hackers@freebsd.org Thu Dec 7 20:49:36 2017 Return-Path: Delivered-To: freebsd-hackers@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 799B5E90EA8; Thu, 7 Dec 2017 20:49:36 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C21D7586A; Thu, 7 Dec 2017 20:49:35 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 428961C9E7; Thu, 7 Dec 2017 21:42:41 +0100 (CET) From: Dimitry Andric Message-Id: <1BC2754C-0A91-4214-84A2-5F5DE0E9A6EB@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_0908F8A0-83F2-4C48-8DE4-E431E9F13E0F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH] Remove unused include file Date: Thu, 7 Dec 2017 21:42:40 +0100 In-Reply-To: <20171207200319.GA96323@troutmask.apl.washington.edu> Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org To: sgk@troutmask.apl.washington.edu References: <20171207200319.GA96323@troutmask.apl.washington.edu> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 20:49:36 -0000 --Apple-Mail=_0908F8A0-83F2-4C48-8DE4-E431E9F13E0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 7 Dec 2017, at 21:03, Steve Kargl = wrote: >=20 > The following patch removes an unused include. >=20 > Index: msun/bsdsrc/b_log.c Thanks, committed in r326670. -Dimitry --Apple-Mail=_0908F8A0-83F2-4C48-8DE4-E431E9F13E0F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWimnwAAKCRCwXqMKLiCW o3qYAJ9YkjgfYGBKMZuGRTFeQcjuw56qLACbBYqVvkS8g2sA6hWmNLErmsKVfLY= =WSVq -----END PGP SIGNATURE----- --Apple-Mail=_0908F8A0-83F2-4C48-8DE4-E431E9F13E0F-- From owner-freebsd-hackers@freebsd.org Fri Dec 8 01:14:38 2017 Return-Path: Delivered-To: freebsd-hackers@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 A1A61E95F8E for ; Fri, 8 Dec 2017 01:14:38 +0000 (UTC) (envelope-from lm@mcvoy.com) Received: from mcvoy.com (mcvoy.com [192.169.23.250]) (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 624F17E63D for ; Fri, 8 Dec 2017 01:14:38 +0000 (UTC) (envelope-from lm@mcvoy.com) Received: by mcvoy.com (Postfix, from userid 3546) id ABEBC35E0C0; Thu, 7 Dec 2017 17:14:30 -0800 (PST) Date: Thu, 7 Dec 2017 17:14:30 -0800 From: Larry McVoy To: freebsd-hackers@freebsd.org Subject: OOM problem? Message-ID: <20171208011430.GA16016@mcvoy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 01:14:38 -0000 Hi hackers, I've been playing around on a box that Netflix loaned me, I'm thinking about novel ways to deal with NUMA issues. I ran into a problem with the kernel, wanted to check in and see if anyone cares (I've got a couple different ways that it could be fixed but if noone cares I'll drop it). It's sort of an ugly problem in that when it happens your only recourse is to power cycle the machine, you can't kill off the processes causing the problem. I was trying to create benchmarks that would show what the system could do if you locked things down to different NUMA domains (BTW, the NUMA stuff is a complete red herring, the problem I'm about to describe happens if NUMA support isn't enabled). The machine is running 12.0-CURRENT FreeBSD 12.0-CURRENT #13 ce7b9882181 with a few diffs I did for debugging and a tweak to the pageout daemon suggested by Jeff. It is a 256GB of RAM machine configured with no swap space (that detail is important). I created a set of 10 processes that malloced 25GB each and read it repeatedly. That was enough memory pressure to use up all of free mem. Here is the problem. All of these "misbehaved" (by using lots of ram) processes go to sleep, I believe in vm_wait(). They are all waiting for more ram so the pageout daemon is kicked but to no avail, all the ram is tied up in the processes that want more ram. The pageout daemon kicks out what it can but it quickly gets to the point that it scans everything and finds nothing (I know this because I added debugging to show that's what it is doing). The OOM code kicks in and it behaves poorly. It doesn't kill any of the big processes, those are all sleeping without PCATCH on so they are skipped. The OOM code starts killing off anything it can find, it was killing getty, ssh, bash, dhclient. One buglet is that, in my opinion, it finds stuff to kill that it probably shouldn't. Anything that init will respawn is fine, anything that would not be respawned should be run as not killable. Seems like an audit of those processes might be in order. I know that you'll ask why no swap? Just add swap and the problem goes away. Does it? I don't think so, that's just kicking the can down the road. If we add 256GB of swap now we have a 512GB bag to fill, fill that and I think we're right back to where we started. What are the ideas for fixing it? I've got two. I think the first one is a bit hard to get right and I'm not sure if the second one will work (sorry, it's been a long time since I was a kernel hack, like SunOS 4.x long time). A) Don't allocate more mem than you have. This problem exists simply because the system allowed malloc to return more space than the system had. If the system kept track of all the mem it has (ram plus swap) and when processes asked for an allocation that pushed it over that limit, fail that allocation. It's yet another globally locked thing (though Jeff's NUMA stuff may make that better), you have to keep track of allocations and frees (as in on exit(2) not free(3)), that's why I think it's detail oriented to do it this way. Probably the right way but has to be done carefully and someone has to care enough to keep watching that this doesn't get broken. B) Sleep with PCATCH, if that doesn't work, loop sleeping for a period, wake up and see if you are signaled. I'm rusty enough that I don't remember if msleep() with PCATCH will catch signals or not (I don't remember a msleep(), that might be a BSD thing and not a SunOS thing). But whatever, either it catches signals or you replace that sleep with a loop that sleeps for a second or so, wakes up and looks to see if it's been signaled and if so dies, else goes back to sleep waiting for pageout and/or OOM to free some mem. I kinda like B better because it seems harder to have that approach bit rot. I'm wondering if anyone cares about this problem. If no, fine. If yes, I can cons up a test case and hand that off to someone who wants to fix the problem. If noone wants to fix it, I'll give it a try but I'd like feedback on the above approaches, not interested in going down a rathole for no good reason. Thanks, --lm From owner-freebsd-hackers@freebsd.org Fri Dec 8 04:39:26 2017 Return-Path: Delivered-To: freebsd-hackers@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 7693FE99BFB for ; Fri, 8 Dec 2017 04:39:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-151.reflexion.net [208.70.210.151]) (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 243413E8D for ; Fri, 8 Dec 2017 04:39:25 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25767 invoked from network); 8 Dec 2017 04:12:38 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 8 Dec 2017 04:12:38 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 07 Dec 2017 23:12:38 -0500 (EST) Received: (qmail 19261 invoked from network); 8 Dec 2017 04:12:37 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Dec 2017 04:12:37 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 56336EC952F; Thu, 7 Dec 2017 20:12:37 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: OOM problem? From: Mark Millard In-Reply-To: <20171208011430.GA16016@mcvoy.com> Date: Thu, 7 Dec 2017 20:12:36 -0800 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <80D1ECE3-D983-4DFB-9B28-3F716F73CD47@dsl-only.net> References: <20171208011430.GA16016@mcvoy.com> To: Larry McVoy X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 04:39:26 -0000 [Just a pointer to a potential example report on the lists.] On 2017-Dec-7, at 5:14 PM, Larry McVoy wrote: > . . . > It's sort of an ugly problem in that > when it happens your only recourse is to power cycle the machine, you > can't kill off the processes causing the problem. If there is a serial console, can something like, say, CR TILDE CTRL-B get to the db> prompt? (options ALT_BREAK_TO_DEBUGGER example.) > . . . > > Here is the problem. All of these "misbehaved" (by using lots of ram) > processes go to sleep, I believe in vm_wait(). They are all waiting > for more ram so the pageout daemon is kicked but to no avail, all the > ram is tied up in the processes that want more ram. The pageout daemon > kicks out what it can but it quickly gets to the point that it scans > everything and finds nothing (I know this because I added debugging to > show that's what it is doing). > > The OOM code kicks in and it behaves poorly. It doesn't kill any of > the big processes, those are all sleeping without PCATCH on so they are > skipped. The OOM code starts killing off anything it can find, it was > killing getty, ssh, bash, dhclient. One buglet is that, in my opinion, > it finds stuff to kill that it probably shouldn't. Anything that init > will respawn is fine, anything that would not be respawned should be > run as not killable. Seems like an audit of those processes might be > in order. https://lists.freebsd.org/pipermail/freebsd-hackers/2017-December/051890.html may be an example of the problem on a rpi2 but with a swap partition in use. I was able to get to the db> prompt and included some basic information from there. It was head -r326192 based. (I did eventually reboot the rpi2 so I no longer have that specific context available to examine.) > I know that you'll ask why no swap? Just add swap and the problem > goes away. Does it? I don't think so, that's just kicking the can > down the road. If we add 256GB of swap now we have a 512GB bag to fill, > fill that and I think we're right back to where we started. > > . . . === Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Fri Dec 8 08:19:04 2017 Return-Path: Delivered-To: freebsd-hackers@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 C375BE9D609 for ; Fri, 8 Dec 2017 08:19:04 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 597D868A29 for ; Fri, 8 Dec 2017 08:19:04 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wr0-x22c.google.com with SMTP id h1so9966500wre.12 for ; Fri, 08 Dec 2017 00:19:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jE38ALhqnMq9v8eID8HEi3/3Fsu3lj1by1QzsW22Fzo=; b=GE0nMG5fbHVqI3Ucv42GNzG/iCztRbGe0rR7c72IfgomCouCY10/hLW6beicdHQDyX Pof4X1WVww8W0qtxpSyRKQLHnulaNtxcdlAJigBPYEpdleS2K34ONQo2FxBnFh+sORzP 390adC40LJpQBW6UhqKg3vvZ7tGPQxxvA1sBN4HpH47CIs/gIQ9o/68YU4765Zst/uSv Z5f8iHXPAuDCt0xKnI1f3SFJTo/UTF3aI7arcY6y84YzIhedJ8b9cXFqnZII017+0jVu gXXHdv09V0cXGWWiVHXDMhnpJM76suD7GisP6u7C9wd/tPPnA+8vJ5ysYA+rjwnu1pf/ RKag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jE38ALhqnMq9v8eID8HEi3/3Fsu3lj1by1QzsW22Fzo=; b=Lkka0vWME3Q0TtUEUy3KACp9YnIjQP8Kxns8UhfQtnUFmRhZYhGLY/43FwnuyE1nP5 p78/7rFOCATOQ5np9UwGIa/DpEq63+F+O7k+aytVwdv5OB0h01yhp7p/1LqJUXx9cz2J 4qno2A/QCMAyIeGh5HYUKC6Ctc1qsII/xuU5sSGMOQs1s/d6WOUspvFICrIdhCK3285e t3aXNpLcFzt17gOO7iMTGcYBPEzDFet4d51xfdJGSqKrbemQe6gPFvkYST7uRbVoXIEd Ox24JbFizFWayZwjxnDQANHGTalilwnS5kQRIX1qxlM8FWmmyhCBBMQIIB+CA1OLma5R Hgfw== X-Gm-Message-State: AJaThX7MoK2WgoB9S7A7v6EwhFIDKJd4eI4PLc/8urGpxXtPxW1jiULH 8oCd36GmKMQPGAPPK5RTk6Ac+gsmvxvYebthVEo= X-Google-Smtp-Source: AGs4zMZhnoWbpA6YnCwqY38FHMImWF1GsqFC4nHlyOAV/AY58NzYrPvdGQbM6lDNbnplMinA3rhe0KhZufF2c5q/WmY= X-Received: by 10.223.152.234 with SMTP id w97mr25339949wrb.215.1512721142475; Fri, 08 Dec 2017 00:19:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.197.68 with HTTP; Fri, 8 Dec 2017 00:18:21 -0800 (PST) In-Reply-To: <20171208011430.GA16016@mcvoy.com> References: <20171208011430.GA16016@mcvoy.com> From: Johannes Lundberg Date: Fri, 8 Dec 2017 08:18:21 +0000 Message-ID: Subject: Re: OOM problem? To: Larry McVoy Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 08:19:04 -0000 Regarding potential oom overhaul. Personally I like the idea of an oom signal. The idea comes from iOS where applications get a callback when system memory is low and they're given a chance to free unused resources or resources that can easily be recreated, before getting killed completely. On FreeBSD, occasionally my Firefox gets killed by the oom routine when it uses +5 GB and I run other heavy stuff like poudriere (yes, as I move around a lot I don't own a desktop, all work done on laptop). Wouldn't it be nice if Firefox instead could get a signal where it can free old tabs' contents and stay alive or at least shut down cleanly instead of being forcibly killed. Processes like poudriere could throttle down number of jails in oom situation. Having a rather small SSD like many laptops, I don't want to waste a lot of space on swap. Actually I rather not use swap at all on SSD due to wear. Just an idea how to improve the FreeBSD laptop experience and could as well solve some of OP's issues I think... On Fri, Dec 8, 2017 at 1:14 AM, Larry McVoy wrote: > Hi hackers, > > I've been playing around on a box that Netflix loaned me, I'm thinking > about novel ways to deal with NUMA issues. > > I ran into a problem with the kernel, wanted to check in and see if > anyone cares (I've got a couple different ways that it could be fixed > but if noone cares I'll drop it). It's sort of an ugly problem in that > when it happens your only recourse is to power cycle the machine, you > can't kill off the processes causing the problem. > > I was trying to create benchmarks that would show what the system could do > if you locked things down to different NUMA domains (BTW, the NUMA stuff > is a complete red herring, the problem I'm about to describe happens if > NUMA support isn't enabled). > > The machine is running 12.0-CURRENT FreeBSD 12.0-CURRENT #13 ce7b9882181 > with a few diffs I did for debugging and a tweak to the pageout daemon > suggested by Jeff. It is a 256GB of RAM machine configured with no swap > space (that detail is important). > > I created a set of 10 processes that malloced 25GB each and read it > repeatedly. That was enough memory pressure to use up all of free mem. > > Here is the problem. All of these "misbehaved" (by using lots of ram) > processes go to sleep, I believe in vm_wait(). They are all waiting > for more ram so the pageout daemon is kicked but to no avail, all the > ram is tied up in the processes that want more ram. The pageout daemon > kicks out what it can but it quickly gets to the point that it scans > everything and finds nothing (I know this because I added debugging to > show that's what it is doing). > > The OOM code kicks in and it behaves poorly. It doesn't kill any of > the big processes, those are all sleeping without PCATCH on so they are > skipped. The OOM code starts killing off anything it can find, it was > killing getty, ssh, bash, dhclient. One buglet is that, in my opinion, > it finds stuff to kill that it probably shouldn't. Anything that init > will respawn is fine, anything that would not be respawned should be > run as not killable. Seems like an audit of those processes might be > in order. > > I know that you'll ask why no swap? Just add swap and the problem > goes away. Does it? I don't think so, that's just kicking the can > down the road. If we add 256GB of swap now we have a 512GB bag to fill, > fill that and I think we're right back to where we started. > > What are the ideas for fixing it? I've got two. I think the first > one is a bit hard to get right and I'm not sure if the second one will > work (sorry, it's been a long time since I was a kernel hack, like SunOS > 4.x long time). > > A) Don't allocate more mem than you have. This problem exists simply > because the system allowed malloc to return more space than the > system had. If the system kept track of all the mem it has (ram > plus swap) and when processes asked for an allocation that pushed it > over that limit, fail that allocation. It's yet another globally > locked thing (though Jeff's NUMA stuff may make that better), you > have to keep track of allocations and frees (as in on exit(2) not > free(3)), that's why I think it's detail oriented to do it this way. > Probably the right way but has to be done carefully and someone has > to care enough to keep watching that this doesn't get broken. > > B) Sleep with PCATCH, if that doesn't work, loop sleeping for a period, > wake up and see if you are signaled. I'm rusty enough that I don't > remember if msleep() with PCATCH will catch signals or not (I don't > remember a msleep(), that might be a BSD thing and not a SunOS thing). > But whatever, either it catches signals or you replace that sleep with > a loop that sleeps for a second or so, wakes up and looks to see if it's > been signaled and if so dies, else goes back to sleep waiting for pageout > and/or OOM to free some mem. > > I kinda like B better because it seems harder to have that approach bit rot. > I'm wondering if anyone cares about this problem. If no, fine. If yes, > I can cons up a test case and hand that off to someone who wants to fix > the problem. If noone wants to fix it, I'll give it a try but I'd like > feedback on the above approaches, not interested in going down a rathole > for no good reason. > > Thanks, > > --lm > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Fri Dec 8 09:23:54 2017 Return-Path: Delivered-To: freebsd-hackers@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 57780E9EAA8 for ; Fri, 8 Dec 2017 09:23:54 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (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 24A8E6A8BC for ; Fri, 8 Dec 2017 09:23:54 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (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 57C8C2603A1; Fri, 8 Dec 2017 10:23:48 +0100 (CET) Subject: Re: OOM problem? To: Larry McVoy , freebsd-hackers@freebsd.org References: <20171208011430.GA16016@mcvoy.com> From: Hans Petter Selasky Message-ID: <558cbad9-036a-edce-af57-4b78d197016f@selasky.org> Date: Fri, 8 Dec 2017 10:21:00 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171208011430.GA16016@mcvoy.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 09:23:54 -0000 On 12/08/17 02:14, Larry McVoy wrote: > B) Sleep with PCATCH, if that doesn't work, loop sleeping for a period, > wake up and see if you are signaled. I'm rusty enough that I don't > remember if msleep() with PCATCH will catch signals or not (I don't > remember a msleep(), that might be a BSD thing and not a SunOS thing). > But whatever, either it catches signals or you replace that sleep with > a loop that sleeps for a second or so, wakes up and looks to see if it's > been signaled and if so dies, else goes back to sleep waiting for pageout > and/or OOM to free some mem. Hi, How will you handle kernel memory allocations with M_WAITOK, that are too big, because it is assumed that such allocations will always return non-NULL? When designing the USB stack in FreeBSD, it was important that memory was always pre-allocated, so that regular operation did not do malloc and free. Other systems I've seen simply panic and reboot when critical functions cannot get memory. Computing the exact size which needs to be pre-allocated puts a bit more logic into the software, but is worth it when the system runs out of memory. I see it strange that sshd cannot accept a connection requiring 64K of memory perhaps while another process has allocated Gigs of RAM, like in the example Larry pulled up. The same should be the case for disk space. Let applications like syslogd reserve some space in the file-system to write important logs. You might argue that's what we have partitions for as the simplest solution, so maybe memory should be partitioned aswell? --HPS From owner-freebsd-hackers@freebsd.org Fri Dec 8 10:15:50 2017 Return-Path: Delivered-To: freebsd-hackers@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 954ACEA024B for ; Fri, 8 Dec 2017 10:15:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 3BD516C081 for ; Fri, 8 Dec 2017 10:15:50 +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 vB8AFijY024635 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Dec 2017 12:15:44 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua vB8AFijY024635 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id vB8AFhJn024628; Fri, 8 Dec 2017 12:15:43 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 8 Dec 2017 12:15:43 +0200 From: Konstantin Belousov To: Larry McVoy Cc: freebsd-hackers@freebsd.org Subject: Re: OOM problem? Message-ID: <20171208101543.GC2272@kib.kiev.ua> References: <20171208011430.GA16016@mcvoy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171208011430.GA16016@mcvoy.com> User-Agent: Mutt/1.9.1 (2017-09-22) 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-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 10:15:50 -0000 On Thu, Dec 07, 2017 at 05:14:30PM -0800, Larry McVoy wrote: > Hi hackers, > > I've been playing around on a box that Netflix loaned me, I'm thinking > about novel ways to deal with NUMA issues. > > I ran into a problem with the kernel, wanted to check in and see if > anyone cares (I've got a couple different ways that it could be fixed > but if noone cares I'll drop it). It's sort of an ugly problem in that > when it happens your only recourse is to power cycle the machine, you > can't kill off the processes causing the problem. > > I was trying to create benchmarks that would show what the system could do > if you locked things down to different NUMA domains (BTW, the NUMA stuff > is a complete red herring, the problem I'm about to describe happens if > NUMA support isn't enabled). > > The machine is running 12.0-CURRENT FreeBSD 12.0-CURRENT #13 ce7b9882181 > with a few diffs I did for debugging and a tweak to the pageout daemon > suggested by Jeff. It is a 256GB of RAM machine configured with no swap > space (that detail is important). > > I created a set of 10 processes that malloced 25GB each and read it > repeatedly. That was enough memory pressure to use up all of free mem. > > Here is the problem. All of these "misbehaved" (by using lots of ram) > processes go to sleep, I believe in vm_wait(). They are all waiting > for more ram so the pageout daemon is kicked but to no avail, all the > ram is tied up in the processes that want more ram. The pageout daemon > kicks out what it can but it quickly gets to the point that it scans > everything and finds nothing (I know this because I added debugging to > show that's what it is doing). > > The OOM code kicks in and it behaves poorly. It doesn't kill any of > the big processes, those are all sleeping without PCATCH on so they are > skipped. What is the proof for this statement ? A process waiting for a page in the fault handler must receive the page to get out of the handler, even if the system is in OOM. The OOM and vm_fault() coordinate to make the fault handler notice that the process was killed, in which case the page is requested with highest priority (i.e. page allocator is allowed to reach deep into the system reserve), to enable the process to reach the ast as fast as possible. At the kernel/user boundary, it is killed than. See the P_KILLED() checks in vm_fault(). I do not remember, and the code inspection confirmed my memory, that OOM scan does not skip uninterruptible sleeps. > The OOM code starts killing off anything it can find, it was > killing getty, ssh, bash, dhclient. One buglet is that, in my opinion, > it finds stuff to kill that it probably shouldn't. Anything that init > will respawn is fine, anything that would not be respawned should be > run as not killable. Seems like an audit of those processes might be > in order. > > I know that you'll ask why no swap? Just add swap and the problem > goes away. Does it? I don't think so, that's just kicking the can > down the road. If we add 256GB of swap now we have a 512GB bag to fill, > fill that and I think we're right back to where we started. > > What are the ideas for fixing it? I've got two. I think the first > one is a bit hard to get right and I'm not sure if the second one will > work (sorry, it's been a long time since I was a kernel hack, like SunOS > 4.x long time). > > A) Don't allocate more mem than you have. This problem exists simply > because the system allowed malloc to return more space than the > system had. If the system kept track of all the mem it has (ram > plus swap) and when processes asked for an allocation that pushed it > over that limit, fail that allocation. It's yet another globally > locked thing (though Jeff's NUMA stuff may make that better), you > have to keep track of allocations and frees (as in on exit(2) not > free(3)), that's why I think it's detail oriented to do it this way. > Probably the right way but has to be done carefully and someone has > to care enough to keep watching that this doesn't get broken. This behaviour can be requested by disabling overcommit. See tuning(7). The code might rot from the time it was done, because this feature often asked for, but rarely used for real. > > B) Sleep with PCATCH, if that doesn't work, loop sleeping for a period, > wake up and see if you are signaled. I'm rusty enough that I don't > remember if msleep() with PCATCH will catch signals or not (I don't > remember a msleep(), that might be a BSD thing and not a SunOS thing). > But whatever, either it catches signals or you replace that sleep with > a loop that sleeps for a second or so, wakes up and looks to see if it's > been signaled and if so dies, else goes back to sleep waiting for pageout > and/or OOM to free some mem. Not exactly this, but something close, was done by the patch I provided to you already. > > I kinda like B better because it seems harder to have that approach bit rot. > I'm wondering if anyone cares about this problem. If no, fine. If yes, > I can cons up a test case and hand that off to someone who wants to fix > the problem. If noone wants to fix it, I'll give it a try but I'd like > feedback on the above approaches, not interested in going down a rathole > for no good reason. > > Thanks, > > --lm > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Fri Dec 8 10:17:03 2017 Return-Path: Delivered-To: freebsd-hackers@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 D0433EA0324 for ; Fri, 8 Dec 2017 10:17:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 6502C6C1D7 for ; Fri, 8 Dec 2017 10:17:03 +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 vB8AGwuv024784 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Dec 2017 12:16:59 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua vB8AGwuv024784 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id vB8AGwBY024783; Fri, 8 Dec 2017 12:16:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 8 Dec 2017 12:16:58 +0200 From: Konstantin Belousov To: Johannes Lundberg Cc: Larry McVoy , freebsd-hackers@freebsd.org Subject: Re: OOM problem? Message-ID: <20171208101658.GD2272@kib.kiev.ua> References: <20171208011430.GA16016@mcvoy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) 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-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 10:17:03 -0000 On Fri, Dec 08, 2017 at 08:18:21AM +0000, Johannes Lundberg wrote: > Regarding potential oom overhaul. Personally I like the idea of an oom > signal. The idea comes from iOS where applications get a callback when > system memory is low and they're given a chance to free unused > resources or resources that can easily be recreated, before getting > killed completely. The OOM signal is a topic which was discussed to death many times before. The summary is that it does not work, because you need to provide pages for userspace to be able to handle the signal. From owner-freebsd-hackers@freebsd.org Fri Dec 8 13:34:48 2017 Return-Path: Delivered-To: freebsd-hackers@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 87798E83A86 for ; Fri, 8 Dec 2017 13:34:48 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from sonic303-36.consmr.mail.gq1.yahoo.com (sonic303-36.consmr.mail.gq1.yahoo.com [98.137.64.217]) (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 5D27672310 for ; Fri, 8 Dec 2017 13:34:47 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1512740081; bh=cdGDpCmtIQyiJrGQgQ+XpTWhVCzB9DnW2OGL7Ow1s20=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=hYLfEYY7L9QOmN52jCMOBUTnTBcukhBqLli9/IcStIk7hcesqg3UQh8upOeWbD+ZpBSJCiDZF5E4r3AP/WfDDQucgG0X/vlXBtUIco5kaLN/lnGVRbf0pLVUwpcBjK0nG7CQsHeewzCU+salLXGSOLg3iDh8jKGeRAVVyO28AVrA+G2P6CGLD9SNzoJs1VIhXWjhcAOSutf6BjuzyWKL2Hm+XhWWDvom69E8xfuGctzW/Hj/Dz7FDpxawCxeijfNtov/mnMluZc7jdV79sERSubrEOsgjJWzrLP/xJ3H6OmInMr3b/8QMOp0kfIfeG4lmey+ArSHVkFcQJkVyurWog== X-YMail-OSG: 3KUl99YVM1mCdeLKSL2CmTsXVJbNMa7AIcGRkODT5dO9oF4A13_PP2rO2O4qx.B ZXJxKvhAyHWK4lsJI1bImnBvvLM9XcB_ed1gtgpvm7fkigwXx8qFOvZYW48a26ZeRBGwZYSLW3eF 8Tt.nZgv0ZRBQLKYHSkbCGvx.5OGphfMRziS1Z1ivZmO1v0dutk0u.w4C3.aEjJi4kjCepaFVX7n Fkd.Cs0rTrvfYWimaLQ.Z23ErUYGm44HAqHuDAhx0s93sc1Pd9Ye3Tp9EKXDvb.SQ_owPO0NKLov 4c_VaxqOoWBFoONLHuNQWASqxVcdiJ3XGjWj6eayIqdQIDRNQTzlJs75EtEp5Aal1Vi2r4Vetzkl epe9Qk.Y02iWYFmfqCIJW2OtHDkw4uckLIVkE.nSTYPKmAK9sSWwUew54vzE1CluPqBF8eZPeYNr T1EyQTimhwRgfJvQ71S6LnduJjBe6acogB0TMykuSxL8Jnn8ph6juu1viVwv3O_lSSV1AuB8z Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Fri, 8 Dec 2017 13:34:41 +0000 Received: from smtpgate101.mail.gq1.yahoo.com (EHLO [192.168.0.5]) ([10.214.169.33]) by smtp405.mail.gq1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 406043424; Fri, 08 Dec 2017 13:34:36 +0000 (UTC) Subject: Re: SPDX tags in file? To: sgk@troutmask.apl.washington.edu Cc: FreeBSD Hackers References: <4247a923-a297-1626-a576-a13651da90ab@FreeBSD.org> <20171207035704.GA54501@troutmask.apl.washington.edu> From: Pedro Giffuni Organization: FreeBSD Project Message-ID: <97afe097-db4b-0dc6-fba0-a9d6ad43576e@FreeBSD.org> Date: Fri, 8 Dec 2017 08:34:36 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171207035704.GA54501@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 13:34:48 -0000 Hello; On 06/12/2017 22:57, Steve Kargl wrote: > On Wed, Dec 06, 2017 at 09:17:06PM -0500, Pedro Giffuni wrote: >>> It seems that the application of SPDX license tags >>> has been automated and done without reviewing whether >>> the tag is correct. For example, the BSD-4-Clause >>> tag has been placed in the files in lib/msun/bsdsrc. >>> Given the UCB letter concerning removal of clauses >>> 3 and 4, these files should probably have had the >>> Copyright updated and a different SPDX clause applied. >>> >>> -- >>> Steve >> The initial sweep was done manually, but as you might have noticed, it >> covered a lot of files and mistakes are certainly possible. >> >> The idea at this time is/was not to replace licenses: I am not a lawyer >> but I think we may have to look at who has touched a file before doing >> any license change. That may be a complex process. >> >> This said. checking for bsd-4-clause is a pretty good opportunity to >> review and modernize code. If the code comes from another BSD (and >> particularly NetBSD as I noticed during the sweep), it is likely >> upstream has updated the license as well and there may be interesting >> changes involved. >> > Not all revisions apply to all four files > > r1573 rgrimes BSD 4.4 Lite > r8870 rgrimes Trailing whitespace > r84210 dillon Add __FBSDID > r92887 obrien Fix SCM ID's > r92917 obrien Remove __P() usage. > r93211 bde Resurrect Lite1 > r97407 keramida Assume __STDC__ > r108533 schweikh Typos and whitespace > r129312 stefanf Remove some kludges (use C99 hexadecimal constant) > r138924 das Cosmetic changes only > r138925 das GC unused declaration > r150318 bde Fixed aliasing bugs in TRUNC() > r152566 bde Removed an unused declaration and style bugs > r169209 bde Document current (slightly broken) handling of special values > r169212 bde Fix tgamma() on some special args > r176449 das Eliminate some warnings > r226414 das Fix some non-standard variable declarations. > r325966 pfg spdx > > If you don't count UCB as upstream (aka r1573), then FreeBSD is > upstream. Looking at NetBSD the commit message for b_tgamma.c > is "Add tgamma{,f} from FreeBSD via rudolf, netbsd at eq dot cz". > OpenBSD is a little more complicated, but its initial version > appeared in 2008 while FreeBSD's appeard in 1994. > > IMHO (non-lawyer) opinion, the only thing that might rise to the > level of Copyright-able material would be r169212. Bruce did not > add his name as he has done elsewhere. Just to make this clear: SPDX license tagging is not about *changing* or even interpreting the license, only about highlighting it to make it easier to identify for other tools. If the license is wrong or outdated, then my understanding is we have to check with everyone that has done considerable changes in the file. > BTW, OpenBSD uses a 3-clause BSD license. > Another advantage in SPDX is that it helps find older licenses so we can check the files upstream for updates. OpenBSD has been moving from BSD-3-Clause to ISC. NetBSD has been moving from BSD-4-Clause or BSD-3-Clause to BSD-2-Clause-NetBSD. Such changes always deserve independent commits. Pedro. From owner-freebsd-hackers@freebsd.org Fri Dec 8 15:01:23 2017 Return-Path: Delivered-To: freebsd-hackers@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 0BBF0E858B7 for ; Fri, 8 Dec 2017 15:01:23 +0000 (UTC) (envelope-from lm@mcvoy.com) Received: from mcvoy.com (mcvoy.com [192.169.23.250]) (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 DEA80752E7 for ; Fri, 8 Dec 2017 15:01:22 +0000 (UTC) (envelope-from lm@mcvoy.com) Received: by mcvoy.com (Postfix, from userid 3546) id 2C5DE35E0C0; Fri, 8 Dec 2017 07:01:21 -0800 (PST) Date: Fri, 8 Dec 2017 07:01:21 -0800 From: Larry McVoy To: Konstantin Belousov Cc: Larry McVoy , freebsd-hackers@freebsd.org Subject: Re: OOM problem? Message-ID: <20171208150121.GH16028@mcvoy.com> References: <20171208011430.GA16016@mcvoy.com> <20171208101543.GC2272@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171208101543.GC2272@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 15:01:23 -0000 On Fri, Dec 08, 2017 at 12:15:43PM +0200, Konstantin Belousov wrote: > > The OOM code kicks in and it behaves poorly. It doesn't kill any of > > the big processes, those are all sleeping without PCATCH on so they are > > skipped. > What is the proof for this statement ? I let the system run overnight trying to find more memory and it never killed any of the big processes. I am able to log in and kill -9 would not kill them. I tried a reboot and that hung. It took a power cycle to get the machine back. I've done this multiple times and always get the same result. > A process waiting for a page in the fault handler must receive the page > to get out of the handler, even if the system is in OOM. I may be confusing you because this is not the normal page fault on a file code path (at least I think it is not). The process is indeed faulting in pages but they are pages that were allocated via whatever malloc calls these days (in SunOS it mmapped /dev/zero, before that it was sbrk(2), I dunno what FreeBSD does, I couldn't find malloc in src/lib, I see that it's jemalloc but /usr/src/lib/libc/stdlib/jemalloc has no files?) I think we are landing in vm_wait() but I can put some debugging in there and confirm that if that helps. > > A) Don't allocate more mem than you have. This problem exists simply > > because the system allowed malloc to return more space than the > > system had. If the system kept track of all the mem it has (ram > > plus swap) and when processes asked for an allocation that pushed it > > over that limit, fail that allocation. It's yet another globally > > locked thing (though Jeff's NUMA stuff may make that better), you > > have to keep track of allocations and frees (as in on exit(2) not > > free(3)), that's why I think it's detail oriented to do it this way. > > Probably the right way but has to be done carefully and someone has > > to care enough to keep watching that this doesn't get broken. > This behaviour can be requested by disabling overcommit. See tuning(7). > The code might rot from the time it was done, because this feature often > asked for, but rarely used for real. Seems like that should be on by default, no? > > B) Sleep with PCATCH, if that doesn't work, loop sleeping for a period, > > wake up and see if you are signaled. I'm rusty enough that I don't > > remember if msleep() with PCATCH will catch signals or not (I don't > > remember a msleep(), that might be a BSD thing and not a SunOS thing). > > But whatever, either it catches signals or you replace that sleep with > > a loop that sleeps for a second or so, wakes up and looks to see if it's > > been signaled and if so dies, else goes back to sleep waiting for pageout > > and/or OOM to free some mem. > Not exactly this, but something close, was done by the patch I provided to > you already. I need to double check but I'm pretty sure I'm running with your patch at least some version of it. Doesn't help. Would it help if I packaged up a test case? Right now I'm using something like this: cd LMbench2+/src for i in 1 2 3 4 5 6 7 8 9 0 do ../bin/*/lat_mem_rd 25g 4096 & done but I could make something simpler. I'm willing to keep pushing on this if that's helpful but if you'd prefer to debug it yourself I can package up a test case. Should probably do that anyway. The diffs against head are in http://mcvoy.com/lm/D if you want to see if I am running the right patch. --lm From owner-freebsd-hackers@freebsd.org Fri Dec 8 15:02:03 2017 Return-Path: Delivered-To: freebsd-hackers@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 EF200E8595F for ; Fri, 8 Dec 2017 15:02:03 +0000 (UTC) (envelope-from shivanshrai84@gmail.com) Received: from mail-it0-f50.google.com (mail-it0-f50.google.com [209.85.214.50]) (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 BD5A875491 for ; Fri, 8 Dec 2017 15:02:03 +0000 (UTC) (envelope-from shivanshrai84@gmail.com) Received: by mail-it0-f50.google.com with SMTP id r6so5290819itr.3 for ; Fri, 08 Dec 2017 07:02:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mZ6JT9F2gFddXwotiAGOzFjmtkpT3XxzxSwFJePumGI=; b=V2k8iMjCPSqYdboV3jomJNM2hQLiD3BIlzADM8DFDBzxvyLeYvM8G/JxXrta2RRtC3 mSy9qCetkKTFRfIoUpd4mGkCPFBHEm2JEk4x9ah8efJq2ZleeddyCYvGl2Q/JV4ynueh 5wH9rPTnGo/6uWccSgP2SwOnZ8YTZWcY+nxYymUASWl2+cL1ziIQhXrRKec4oNUsbIhR 7aRvJv5jhbOfaOjH6AMfMoi2zXRdx1WZB7l97t6YObf3dzeJ+Kh87P7p1qAjOGq2KDjk BqAgRZlAli8dcIvishGJGOgyel6hwChKsqha9olKKlMuBr1nFoULI2f/JTNX8H818/t8 c1ZQ== X-Gm-Message-State: AKGB3mI+9uVXpd/kowpQLMqBB1juqzzojodYOsM9p3EwejyejmQzIbo2 9TsGrV32DocdtPukqrZJLPkTvVW7 X-Google-Smtp-Source: AGs4zMZIhjkadSpyKg4ixT0+TH2RonQjAtWjnhT11F8Fp/p5KgBKATiwMpEa2hh2OkzBPVOyhwdXkg== X-Received: by 10.36.135.5 with SMTP id f5mr6454242ite.85.1512745315624; Fri, 08 Dec 2017 07:01:55 -0800 (PST) Received: from mail-it0-f51.google.com (mail-it0-f51.google.com. [209.85.214.51]) by smtp.gmail.com with ESMTPSA id k23sm834515iti.22.2017.12.08.07.01.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Dec 2017 07:01:54 -0800 (PST) Received: by mail-it0-f51.google.com with SMTP id f190so5266848ita.5 for ; Fri, 08 Dec 2017 07:01:54 -0800 (PST) X-Received: by 10.36.2.212 with SMTP id 203mr6150842itu.43.1512745314331; Fri, 08 Dec 2017 07:01:54 -0800 (PST) MIME-Version: 1.0 From: Shivansh Rai Date: Fri, 08 Dec 2017 15:01:42 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Different behavior when running `make` To: "freebsd-hackers@freebsd.org" Content-Type: multipart/mixed; boundary="001a114475ee1968f2055fd5776a" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 15:02:04 -0000 --001a114475ee1968f2055fd5776a Content-Type: text/plain; charset="UTF-8" Hello all, I'm currently working on a tool for automating generation of smoketests for all the utilities in the base system [1]. Until now I was testing things on a very old branch from around August (git sha 92d8705), and after updating my branch (git sha 7ea30ed) I'm starting to notice a different behavior. The tool is located at `~/freebsd/tools/tools/smoketestsuite` [2] in my system. Executing `make` inside [2] produces the following output - ``` [Creating objdir /usr/obj/usr/home/zeebsd/freebsd/amd64.amd64/tools/tools/smoketestsuite...] c++ -I/usr/local/include -std=c++11 -c logging.cpp c++: error: no such file or directory: 'logging.cpp' c++: error: no input files *** Error code 1 ``` The interesting thing to be noted is the first line of the above trace where a new directory under `/usr/obj` is created (I've noticed this for the first time, after I updated my branch). The location `/usr/obj/usr/home/zeebsd/freebsd/amd64.amd64/tools/tools/smoketestsuite` [3] is empty, and it seems that `make` tries to look up `logging.cpp` (and all other files) in [3] instead of [2]. This is evident from the fact that if I manually populate [3] will all the relevant files, everything works fine. Also, all the side-effects which `make` introduces (new files, new binaries etc.) are populated at [3] instead of [2]. If the tool is kept at a location outside the src tree (not under `~/freebsd`), everything works fine (and the temporary directory under `/usr/obj` is not created for those locations when `make` is executed). So the problem seems to be in the way `make` is running inside the src tree. I've attached the system call trace for the failing execution. It'd be extremely helpful if someone could please shed light on what seems to be the problem here, and what should be the right workflow. [1]: For some more reference, the tool is currently available at ` https://github.com/shivansh/smoketestsuite/' (svn branch) (D12249). [2]: `~/freebsd/tools/tools/smoketestsuite` [3]: `/usr/obj/usr/home/zeebsd/freebsd/amd64.amd64/tools/tools/smoketestsuite` Thanks in advance! With best regards, Shivansh Rai --001a114475ee1968f2055fd5776a Content-Type: text/plain; charset="US-ASCII"; name="make_trace.txt" Content-Disposition: attachment; filename="make_trace.txt" Content-Transfer-Encoding: base64 Content-ID: <160369afba452ea61362> X-Attachment-Id: 160369afba452ea61362 cmVhZGxpbmsoIi9ldGMvbWFsbG9jLmNvbmYiLDB4N2ZmZmZmZmZlNGEwLDEwMjQpIEVSUiMyICdO byBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwppc3NldHVnaWQoKQkJCQkJID0gMCAoMHgwKQpfX3N5 c2N0bCgweDdmZmZmZmZmZTM2OCwweDIsMHg3ZmZmZmZmZmUzYjAsMHg3ZmZmZmZmZmUzYTgsMHg0 OTgwNWIsMHhkKSA9IDAgKDB4MCkKX19zeXNjdGwoMHg3ZmZmZmZmZmUzYjAsMHgyLDB4N2ZmZmZm ZmZlNDVjLDB4N2ZmZmZmZmZlNDUwLDB4MCwweDApID0gMCAoMHgwKQptbWFwKDB4MCwyMDk3MTUy LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1BUF9BTk9OLC0xLDB4MCkgPSAzNDM2 NjczNDMzNiAoMHg4MDA2YWMwMDApCm11bm1hcCgweDgwMDZhYzAwMCwyMDk3MTUyKQkJCSA9IDAg KDB4MCkKbW1hcCgweDAsNDE5MDIwOCxQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxN QVBfQU5PTiwtMSwweDApID0gMzQzNjY3MzQzMzYgKDB4ODAwNmFjMDAwKQptdW5tYXAoMHg4MDA2 YWMwMDAsMTM5MjY0MCkJCQkgPSAwICgweDApCm11bm1hcCgweDgwMGEwMDAwMCw3MDA0MTYpCQkJ ID0gMCAoMHgwKQptbWFwKDB4MCwyMDk3MTUyLFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklW QVRFfE1BUF9BTk9OLC0xLDB4MCkgPSAzNDM3MDIyNDEyOCAoMHg4MDBhMDAwMDApCnN5c2FyY2go QU1ENjRfU0VUX0ZTQkFTRSwweDdmZmZmZmZmZTk1MCkJID0gMCAoMHgwKQpzaWdhY3Rpb24oU0lH SU5GTyx7IDB4NDBjYTQwIFNBX1JFU1RBUlQgc3NfdCB9LHsgU0lHX0RGTCBTQV9SRVNUQVJUIHNz X3QgfSkgPSAwICgweDApCmdldHJsaW1pdChSTElNSVRfTk9GSUxFLHsgY3VyPTU4MDQxLG1heD01 ODA0MSB9KSA9IDAgKDB4MCkKX19zeXNjdGwoMHg3ZmZmZmZmZmQ2YjgsMHgyLDB4N2ZmZmZmZmZk YzIwLDB4N2ZmZmZmZmZkNmIwLDB4MCwweDApID0gMCAoMHgwKQpfX3N5c2N0bCgweDdmZmZmZmZm ZDZiOCwweDIsMHg3ZmZmZmZmZmRkMjAsMHg3ZmZmZmZmZmQ2YjAsMHgwLDB4MCkgPSAwICgweDAp Cl9fc3lzY3RsKDB4N2ZmZmZmZmZkNmI4LDB4MiwweDdmZmZmZmZmZGUyMCwweDdmZmZmZmZmZDZi MCwweDAsMHgwKSA9IDAgKDB4MCkKX19zeXNjdGwoMHg3ZmZmZmZmZmQ2YjgsMHgyLDB4N2ZmZmZm ZmZkZjIwLDB4N2ZmZmZmZmZkNmIwLDB4MCwweDApID0gMCAoMHgwKQpfX3N5c2N0bCgweDdmZmZm ZmZmZDZiOCwweDIsMHg3ZmZmZmZmZmUwMjAsMHg3ZmZmZmZmZmQ2YjAsMHgwLDB4MCkgPSAwICgw eDApCmdldHBpZCgpCQkJCQkgPSAzMjIyICgweGM5NikKZ2V0cHBpZCgpCQkJCQkgPSAzMjIxICgw eGM5NSkKX19nZXRjd2QoIi91c3IvaG9tZS96ZWVic2QvZnJlZWJzZC90b29scy90b29scy9zbW9r ZXRlc3RzdWl0ZSIsMTAyNCkgPSAwICgweDApCnN0YXQoIi91c3IvaG9tZS96ZWVic2QvZnJlZWJz ZC90b29scy90b29scy9zbW9rZXRlc3RzdWl0ZSIseyBtb2RlPWRyd3hyLXhyLXggLGlub2RlPTk2 NDk4NSxzaXplPTEwMjQsYmxrc2l6ZT0zMjc2OCB9KSA9IDAgKDB4MCkKb3BlbigiL3Vzci9ob21l L3plZWJzZC9mcmVlYnNkL3Rvb2xzL3Rvb2xzL3Ntb2tldGVzdHN1aXRlIixPX05PTkJMT0NLfE9f RElSRUNUT1JZfE9fQ0xPRVhFQywwNTYpID0gMyAoMHgzKQpmc3RhdGZzKDMseyBmc3R5cGVuYW1l PXVmcyxtbnRvbm5hbWU9LyxtbnRmcm9tbmFtZT0vZGV2L2FkYTBzMWEsZnNpZD0gfSkgPSAwICgw eDApCmdldGRpcmVudHJpZXMoMHgzLDB4ODAwYTM4MDAwLDB4MTAwMCwweDgwMGEzNTAyOCkgPSA0 ODggKDB4MWU4KQpnZXRkaXJlbnRyaWVzKDB4MywweDgwMGEzODAwMCwweDEwMDAsMHg4MDBhMzUw MjgpID0gMCAoMHgwKQpjbG9zZSgzKQkJCQkJID0gMCAoMHgwKQpzdGF0KCIvdXNyL2hvbWUvemVl YnNkL2ZyZWVic2QvdG9vbHMvdG9vbHMvc21va2V0ZXN0c3VpdGUiLHsgbW9kZT1kcnd4ci14ci14 ICxpbm9kZT05NjQ5ODUsc2l6ZT0xMDI0LGJsa3NpemU9MzI3NjggfSkgPSAwICgweDApCmNoZGly KCIvdXNyL2hvbWUvemVlYnNkL2ZyZWVic2QvdG9vbHMvdG9vbHMvc21va2V0ZXN0c3VpdGUiKSA9 IDAgKDB4MCkKb3BlbigiLiIsT19OT05CTE9DS3xPX0RJUkVDVE9SWXxPX0NMT0VYRUMsMDEwNCkJ ID0gMyAoMHgzKQpmc3RhdGZzKDMseyBmc3R5cGVuYW1lPXVmcyxtbnRvbm5hbWU9LyxtbnRmcm9t bmFtZT0vZGV2L2FkYTBzMWEsZnNpZD0gfSkgPSAwICgweDApCmdldGRpcmVudHJpZXMoMHgzLDB4 ODAwYTM4MDAwLDB4MTAwMCwweDgwMGEzNTAyOCkgPSA0ODggKDB4MWU4KQpnZXRkaXJlbnRyaWVz KDB4MywweDgwMGEzODAwMCwweDEwMDAsMHg4MDBhMzUwMjgpID0gMCAoMHgwKQpjbG9zZSgzKQkJ CQkJID0gMCAoMHgwKQpzdGF0KCIvdXNyL2hvbWUvemVlYnNkL2ZyZWVic2QvdG9vbHMvdG9vbHMv c21va2V0ZXN0c3VpdGUvb2JqLmFtZDY0IiwweDdmZmZmZmZmZDI0OCkgRVJSIzIgJ05vIHN1Y2gg ZmlsZSBvciBkaXJlY3RvcnknCnN0YXQoIi91c3IvaG9tZS96ZWVic2QvZnJlZWJzZC90b29scy90 b29scy9zbW9rZXRlc3RzdWl0ZS9vYmoiLDB4N2ZmZmZmZmZkMjQ4KSBFUlIjMiAnTm8gc3VjaCBm aWxlIG9yIGRpcmVjdG9yeScKc3RhdCgiL3Vzci9vYmovdXNyL2hvbWUvemVlYnNkL2ZyZWVic2Qv dG9vbHMvdG9vbHMvc21va2V0ZXN0c3VpdGUiLDB4N2ZmZmZmZmZkMjQ4KSBFUlIjMiAnTm8gc3Vj aCBmaWxlIG9yIGRpcmVjdG9yeScKc3RhdCgiL3Vzci9ob21lL3plZWJzZC9mcmVlYnNkL3Rvb2xz L3Rvb2xzL3Ntb2tldGVzdHN1aXRlL3NoYXJlL21rIiwweDdmZmZmZmZmY2UyOCkgRVJSIzIgJ05v IHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCnN0YXQoIi91c3IvaG9tZS96ZWVic2QvZnJlZWJzZC90 b29scy90b29scy9zaGFyZS9tayIsMHg3ZmZmZmZmZmNlMjgpIEVSUiMyICdObyBzdWNoIGZpbGUg b3IgZGlyZWN0b3J5JwpzdGF0KCIvdXNyL2hvbWUvemVlYnNkL2ZyZWVic2QvdG9vbHMvc2hhcmUv bWsiLDB4N2ZmZmZmZmZjZTI4KSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKc3Rh dCgiL3Vzci9ob21lL3plZWJzZC9mcmVlYnNkL3NoYXJlL21rIix7IG1vZGU9ZHJ3eHIteHIteCAs aW5vZGU9MjMyODE1MCxzaXplPTIwNDgsYmxrc2l6ZT0zMjc2OCB9KSA9IDAgKDB4MCkKb3Blbigi L3Vzci9ob21lL3plZWJzZC9mcmVlYnNkL3NoYXJlL21rIixPX05PTkJMT0NLfE9fRElSRUNUT1JZ fE9fQ0xPRVhFQywwNTcpID0gMyAoMHgzKQpmc3RhdGZzKDMseyBmc3R5cGVuYW1lPXVmcyxtbnRv bm5hbWU9LyxtbnRmcm9tbmFtZT0vZGV2L2FkYTBzMWEsZnNpZD0gfSkgPSAwICgweDApCmdldGRp cmVudHJpZXMoMHgzLDB4ODAwYTM4MDAwLDB4MTAwMCwweDgwMGEzNTA4OCkgPSAxNzcyICgweDZl YykKZ2V0ZGlyZW50cmllcygweDMsMHg4MDBhMzgwMDAsMHgxMDAwLDB4ODAwYTM1MDg4KSA9IDAg KDB4MCkKY2xvc2UoMykJCQkJCSA9IDAgKDB4MCkKb3BlbigiL3Vzci9zaGFyZS9tayIsT19OT05C TE9DS3xPX0RJUkVDVE9SWXxPX0NMT0VYRUMsMDE2MykgPSAzICgweDMpCmZzdGF0ZnMoMyx7IGZz dHlwZW5hbWU9dWZzLG1udG9ubmFtZT0vLG1udGZyb21uYW1lPS9kZXYvYWRhMHMxYSxmc2lkPSB9 KSA9IDAgKDB4MCkKZ2V0ZGlyZW50cmllcygweDMsMHg4MDBhMzgwMDAsMHgxMDAwLDB4ODAwYTM1 MDg4KSA9IDEyMjQgKDB4NGM4KQpnZXRkaXJlbnRyaWVzKDB4MywweDgwMGEzODAwMCwweDEwMDAs MHg4MDBhMzUwODgpID0gMCAoMHgwKQpjbG9zZSgzKQkJCQkJID0gMCAoMHgwKQpvcGVuYXQoQVRf RkRDV0QsIi91c3IvaG9tZS96ZWVic2QvZnJlZWJzZC9zaGFyZS9tay9zeXMubWsiLE9fUkRPTkxZ LDAwKSA9IDMgKDB4MykKZnN0YXQoMyx7IG1vZGU9LXJ3LXItLXItLSAsaW5vZGU9MjMyODk2MSxz aXplPTg2MjAsYmxrc2l6ZT0zMjc2OCB9KSA9IDAgKDB4MCkKX19zeXNjdGwoMHg3ZmZmZmZmZmQ0 ZjgsMHgyLDB4N2ZmZmZmZmZkNGRjLDB4N2ZmZmZmZmZkNGUwLDB4MCwweDApID0gMCAoMHgwKQpt bWFwKDB4MCwxMjI4OCxQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURSwzLDB4MCkgPSAz NDM2NjczNDMzNiAoMHg4MDA2YWMwMDApCmNsb3NlKDMpCQkJCQkgPSAwICgweDApCm9wZW5hdChB VF9GRENXRCwiL3Vzci9ob21lL3plZWJzZC9mcmVlYnNkL3NoYXJlL21rL2xvY2FsLnN5cy5lbnYu bWsiLE9fUkRPTkxZLDAwKSA9IDMgKDB4MykKZnN0YXQoMyx7IG1vZGU9LXJ3LXItLXItLSAsaW5v ZGU9MjMyODk1NCxzaXplPTE1NzEsYmxrc2l6ZT0zMjc2OCB9KSA9IDAgKDB4MCkKX19zeXNjdGwo MHg3ZmZmZmZmZmQ0OTgsMHgyLDB4N2ZmZmZmZmZkNDdjLDB4N2ZmZmZmZmZkNDgwLDB4MCwweDAp ID0gMCAoMHgwKQptbWFwKDB4MCw0MDk2LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRF LDMsMHgwKSA9IDM0MzY2NzQ2NjI0ICgweDgwMDZhZjAwMCkKY2xvc2UoMykJCQkJCSA9IDAgKDB4 MCkKc3RhdCgiL3Vzci9ob21lL3plZWJzZC9mcmVlYnNkL3NoYXJlL21rL3NyYy5zeXMuZW52Lm1r Iix7IG1vZGU9LXJ3LXItLXItLSAsaW5vZGU9MjMyODk1NyxzaXplPTE2NzcsYmxrc2l6ZT0zMjc2 OCB9KSA9IDAgKDB4MCkKb3BlbmF0KEFUX0ZEQ1dELCIvdXNyL2hvbWUvemVlYnNkL2ZyZWVic2Qv c2hhcmUvbWsvc3JjLnN5cy5lbnYubWsiLE9fUkRPTkxZLDAwKSA9IDMgKDB4MykKZnN0YXQoMyx7 IG1vZGU9LXJ3LXItLXItLSAsaW5vZGU9MjMyODk1NyxzaXplPTE2NzcsYmxrc2l6ZT0zMjc2OCB9 KSA9IDAgKDB4MCkKX19zeXNjdGwoMHg3ZmZmZmZmZmQ0OTgsMHgyLDB4N2ZmZmZmZmZkNDdjLDB4 N2ZmZmZmZmZkNDgwLDB4MCwweDApID0gMCAoMHgwKQptbWFwKDB4MCw0MDk2LFBST1RfUkVBRHxQ Uk9UX1dSSVRFLE1BUF9QUklWQVRFLDMsMHgwKSA9IDM0MzY2NzUwNzIwICgweDgwMDZiMDAwMCkK Y2xvc2UoMykJCQkJCSA9IDAgKDB4MCkKbHN0YXQoIi91c3IiLHsgbW9kZT1kcnd4ci14ci14ICxp bm9kZT0zNTMxMjY0LHNpemU9NTEyLGJsa3NpemU9MzI3NjggfSkgPSAwICgweDApCmxzdGF0KCIv dXNyL2hvbWUiLHsgbW9kZT1kcnd4ci14ci14ICxpbm9kZT0zNjM1MDgwLHNpemU9NTEyLGJsa3Np emU9MzI3NjggfSkgPSAwICgweDApCmxzdGF0KCIvdXNyL2hvbWUvemVlYnNkIix7IG1vZGU9ZHJ3 eHIteHIteCAsaW5vZGU9MzYzNTA4MSxzaXplPTE1MzYsYmxrc2l6ZT0zMjc2OCB9KSA9IDAgKDB4 MCkKbHN0YXQoIi91c3IvaG9tZS96ZWVic2QvZnJlZWJzZCIseyBtb2RlPWRyd3hyLXhyLXggLGlu b2RlPTczMTk3NyxzaXplPTEwMjQsYmxrc2l6ZT0zMjc2OCB9KSA9IDAgKDB4MCkKbHN0YXQoIi91 c3IvaG9tZS96ZWVic2QvZnJlZWJzZC9zaGFyZSIseyBtb2RlPWRyd3hyLXhyLXggLGlub2RlPTIw MTMzNDMsc2l6ZT01MTIsYmxrc2l6ZT0zMjc2OCB9KSA9IDAgKDB4MCkKbHN0YXQoIi91c3IvaG9t ZS96ZWVic2QvZnJlZWJzZC9zaGFyZS9tayIseyBtb2RlPWRyd3hyLXhyLXggLGlub2RlPTIzMjgx NTAsc2l6ZT0yMDQ4LGJsa3NpemU9MzI3NjggfSkgPSAwICgweDApCnN0YXQoIi91c3IvaG9tZS96 ZWVic2QvZnJlZWJzZC9zaGFyZS9tayIseyBtb2RlPWRyd3hyLXhyLXggLGlub2RlPTIzMjgxNTAs c2l6ZT0yMDQ4LGJsa3NpemU9MzI3NjggfSkgPSAwICgweDApCm9wZW5hdChBVF9GRENXRCwiL2V0 Yy9zcmMtZW52LmNvbmYiLE9fUkRPTkxZLDAwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVj dG9yeScKb3BlbmF0KEFUX0ZEQ1dELCIvdXNyL2hvbWUvemVlYnNkL2ZyZWVic2Qvc2hhcmUvbWsv YnNkLm1rb3B0Lm1rIixPX1JET05MWSwwMCkgPSAzICgweDMpCmZzdGF0KDMseyBtb2RlPS1ydy1y LS1yLS0gLGlub2RlPTIzMjgxNzQsc2l6ZT0yMzQwLGJsa3NpemU9MzI3NjggfSkgPSAwICgweDAp Cl9fc3lzY3RsKDB4N2ZmZmZmZmZkNDk4LDB4MiwweDdmZmZmZmZmZDQ3YywweDdmZmZmZmZmZDQ4 MCwweDAsMHgwKSA9IDAgKDB4MCkKbW1hcCgweDAsNDA5NixQUk9UX1JFQUR8UFJPVF9XUklURSxN QVBfUFJJVkFURSwzLDB4MCkgPSAzNDM2Njc1NDgxNiAoMHg4MDA2YjEwMDApCmNsb3NlKDMpCQkJ CQkgPSAwICgweDApCm11bm1hcCgweDgwMDZiMTAwMCw0MDk2KQkJCSA9IDAgKDB4MCkKc3RhdCgi L3Vzci9ob21lL3plZWJzZC9mcmVlYnNkL3NoYXJlL21rIix7IG1vZGU9ZHJ3eHIteHIteCAsaW5v ZGU9MjMyODE1MCxzaXplPTIwNDgsYmxrc2l6ZT0zMjc2OCB9KSA9IDAgKDB4MCkKb3BlbmF0KEFU X0ZEQ1dELCIvdXNyL2hvbWUvemVlYnNkL2ZyZWVic2Qvc2hhcmUvbWsvc3JjLnN5cy5vYmoubWsi LE9fUkRPTkxZLDAwKSA9IDMgKDB4MykKZnN0YXQoMyx7IG1vZGU9LXJ3LXItLXItLSAsaW5vZGU9 MjMyODk1OSxzaXplPTY5ODgsYmxrc2l6ZT0zMjc2OCB9KSA9IDAgKDB4MCkKX19zeXNjdGwoMHg3 ZmZmZmZmZmQ0OTgsMHgyLDB4N2ZmZmZmZmZkNDdjLDB4N2ZmZmZmZmZkNDgwLDB4MCwweDApID0g MCAoMHgwKQptbWFwKDB4MCw4MTkyLFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFLDMs MHgwKSA9IDM0MzY2NzU0ODE2ICgweDgwMDZiMTAwMCkKY2xvc2UoMykJCQkJCSA9IDAgKDB4MCkK b3BlbmF0KEFUX0ZEQ1dELCIvdXNyL2hvbWUvemVlYnNkL2ZyZWVic2Qvc2hhcmUvbWsvYnNkLm1r b3B0Lm1rIixPX1JET05MWSwwMCkgPSAzICgweDMpCmZzdGF0KDMseyBtb2RlPS1ydy1yLS1yLS0g LGlub2RlPTIzMjgxNzQsc2l6ZT0yMzQwLGJsa3NpemU9MzI3NjggfSkgPSAwICgweDApCl9fc3lz Y3RsKDB4N2ZmZmZmZmZkNDk4LDB4MiwweDdmZmZmZmZmZDQ3YywweDdmZmZmZmZmZDQ4MCwweDAs MHgwKSA9IDAgKDB4MCkKbW1hcCgweDAsNDA5NixQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJ VkFURSwzLDB4MCkgPSAzNDM2Njc2MzAwOCAoMHg4MDA2YjMwMDApCmNsb3NlKDMpCQkJCQkgPSAw ICgweDApCm11bm1hcCgweDgwMDZiMzAwMCw0MDk2KQkJCSA9IDAgKDB4MCkKbHN0YXQoIi91c3Ii LHsgbW9kZT1kcnd4ci14ci14ICxpbm9kZT0zNTMxMjY0LHNpemU9NTEyLGJsa3NpemU9MzI3Njgg fSkgPSAwICgweDApCmxzdGF0KCIvdXNyL29iaiIseyBtb2RlPWRyd3hyLXhyLXggLGlub2RlPTM2 OTIyMjksc2l6ZT01MTIsYmxrc2l6ZT0zMjc2OCB9KSA9IDAgKDB4MCkKbHN0YXQoIi91c3Ivb2Jq L3VzciIseyBtb2RlPWRyd3hyLXhyLXggLGlub2RlPTMwNTA0OTAsc2l6ZT01MTIsYmxrc2l6ZT0z Mjc2OCB9KSA9IDAgKDB4MCkKbHN0YXQoIi91c3Ivb2JqL3Vzci9ob21lIix7IG1vZGU9ZHJ3eHJ3 eHIteCAsaW5vZGU9MzEzMDQ4MixzaXplPTUxMixibGtzaXplPTMyNzY4IH0pID0gMCAoMHgwKQps c3RhdCgiL3Vzci9vYmovdXNyL2hvbWUvemVlYnNkIix7IG1vZGU9ZHJ3eHJ3eHIteCAsaW5vZGU9 MzEzMDQ4MyxzaXplPTUxMixibGtzaXplPTMyNzY4IH0pID0gMCAoMHgwKQpsc3RhdCgiL3Vzci9v YmovdXNyL2hvbWUvemVlYnNkL2ZyZWVic2QiLHsgbW9kZT1kcnd4cnd4ci14ICxpbm9kZT0zMTMw NDg0LHNpemU9NTEyLGJsa3NpemU9MzI3NjggfSkgPSAwICgweDApCnN0YXQoIi91c3Ivb2JqL3Vz ci9ob21lL3plZWJzZC9mcmVlYnNkIix7IG1vZGU9ZHJ3eHJ3eHIteCAsaW5vZGU9MzEzMDQ4NCxz aXplPTUxMixibGtzaXplPTMyNzY4IH0pID0gMCAoMHgwKQpsc3RhdCgiL3VzciIseyBtb2RlPWRy d3hyLXhyLXggLGlub2RlPTM1MzEyNjQsc2l6ZT01MTIsYmxrc2l6ZT0zMjc2OCB9KSA9IDAgKDB4 MCkKbHN0YXQoIi91c3Ivb2JqIix7IG1vZGU9ZHJ3eHIteHIteCAsaW5vZGU9MzY5MjIyOSxzaXpl PTUxMixibGtzaXplPTMyNzY4IH0pID0gMCAoMHgwKQpsc3RhdCgiL3Vzci9vYmovdXNyIix7IG1v ZGU9ZHJ3eHIteHIteCAsaW5vZGU9MzA1MDQ5MCxzaXplPTUxMixibGtzaXplPTMyNzY4IH0pID0g MCAoMHgwKQpsc3RhdCgiL3Vzci9vYmovdXNyL2hvbWUiLHsgbW9kZT1kcnd4cnd4ci14ICxpbm9k ZT0zMTMwNDgyLHNpemU9NTEyLGJsa3NpemU9MzI3NjggfSkgPSAwICgweDApCmxzdGF0KCIvdXNy L29iai91c3IvaG9tZS96ZWVic2QiLHsgbW9kZT1kcnd4cnd4ci14ICxpbm9kZT0zMTMwNDgzLHNp emU9NTEyLGJsa3NpemU9MzI3NjggfSkgPSAwICgweDApCmxzdGF0KCIvdXNyL29iai91c3IvaG9t ZS96ZWVic2QvZnJlZWJzZCIseyBtb2RlPWRyd3hyd3hyLXggLGlub2RlPTMxMzA0ODQsc2l6ZT01 MTIsYmxrc2l6ZT0zMjc2OCB9KSA9IDAgKDB4MCkKc3RhdCgiL3Vzci9vYmovdXNyL2hvbWUvemVl YnNkL2ZyZWVic2QiLHsgbW9kZT1kcnd4cnd4ci14ICxpbm9kZT0zMTMwNDg0LHNpemU9NTEyLGJs a3NpemU9MzI3NjggfSkgPSAwICgweDApCnBpcGUyKDB4N2ZmZmZmZmZkNTM4LE9fUkRPTkxZKQkJ CSA9IDAgKDB4MCkKZ2V0cGlkKCkJCQkJCSA9IDMyMjIgKDB4Yzk2KQp2Zm9yaygpCQkJCQkJID0g MzIyMyAoMHhjOTcpCmNsb3NlKDQpCQkJCQkgPSAwICgweDApCnJlYWQoMywieWVzXG4iLDEwMjQp CQkJCSA9IDQgKDB4NCkKcmVhZCgzLDB4N2ZmZmZmZmZkMTMwLDEwMjQpCQkJID0gMCAoMHgwKQpj bG9zZSgzKQkJCQkJID0gMCAoMHgwKQp3YWl0NCgzMjIzLHsgRVhJVEVELHZhbD0wIH0sMHgwLDB4 MCkJCSA9IDMyMjMgKDB4Yzk3KQpzdGF0KCIvdXNyL29iai91c3IvaG9tZS96ZWVic2QvZnJlZWJz ZC9hbWQ2NC5hbWQ2NC90b29scy90b29scy9zbW9rZXRlc3RzdWl0ZSIseyBtb2RlPWRyd3hyLXhy LXggLGlub2RlPTMxMzA1Mjcsc2l6ZT0xMDI0LGJsa3NpemU9MzI3NjggfSkgPSAwICgweDApCnN0 YXQoIi91c3Ivb2JqL3Vzci9ob21lL3plZWJzZC9mcmVlYnNkL2FtZDY0LmFtZDY0L3Rvb2xzL3Rv b2xzL3Ntb2tldGVzdHN1aXRlIix7IG1vZGU9ZHJ3eHIteHIteCAsaW5vZGU9MzEzMDUyNyxzaXpl PTEwMjQsYmxrc2l6ZT0zMjc2OCB9KSA9IDAgKDB4MCkKY2hkaXIoIi91c3Ivb2JqL3Vzci9ob21l L3plZWJzZC9mcmVlYnNkL2FtZDY0LmFtZDY0L3Rvb2xzL3Rvb2xzL3Ntb2tldGVzdHN1aXRlIikg PSAwICgweDApCm9wZW4oIi4iLE9fTk9OQkxPQ0t8T19ESVJFQ1RPUll8T19DTE9FWEVDLDAxMDQp CSA9IDMgKDB4MykKZnN0YXRmcygzLHsgZnN0eXBlbmFtZT11ZnMsbW50b25uYW1lPS8sbW50ZnJv bW5hbWU9L2Rldi9hZGEwczFhLGZzaWQ9IH0pID0gMCAoMHgwKQpnZXRkaXJlbnRyaWVzKDB4Myww eDgwMGEzODAwMCwweDEwMDAsMHg4MDBhMzUxYTgpID0gMjQgKDB4MTgpCmdldGRpcmVudHJpZXMo MHgzLDB4ODAwYTM4MDAwLDB4MTAwMCwweDgwMGEzNTFhOCkgPSAwICgweDApCmNsb3NlKDMpCQkJ CQkgPSAwICgweDApCm11bm1hcCgweDgwMDZiMTAwMCw4MTkyKQkJCSA9IDAgKDB4MCkKbXVubWFw KDB4ODAwNmIwMDAwLDQwOTYpCQkJID0gMCAoMHgwKQptdW5tYXAoMHg4MDA2YWYwMDAsNDA5NikJ CQkgPSAwICgweDApCm9wZW5hdChBVF9GRENXRCwiL3Vzci9ob21lL3plZWJzZC9mcmVlYnNkL3No YXJlL21rL2JzZC5ta29wdC5tayIsT19SRE9OTFksMDApID0gMyAoMHgzKQpmc3RhdCgzLHsgbW9k ZT0tcnctci0tci0tICxpbm9kZT0yMzI4MTc0LHNpemU9MjM0MCxibGtzaXplPTMyNzY4IH0pID0g MCAoMHgwKQpfX3N5c2N0bCgweDdmZmZmZmZmZDQ5OCwweDIsMHg3ZmZmZmZmZmQ0N2MsMHg3ZmZm ZmZmZmQ0ODAsMHgwLDB4MCkgPSAwICgweDApCm1tYXAoMHgwLDQwOTYsUFJPVF9SRUFEfFBST1Rf V1JJVEUsTUFQX1BSSVZBVEUsMywweDApID0gMzQzNjY3NDY2MjQgKDB4ODAwNmFmMDAwKQpjbG9z ZSgzKQkJCQkJID0gMCAoMHgwKQptdW5tYXAoMHg4MDA2YWYwMDAsNDA5NikJCQkgPSAwICgweDAp Cm9wZW5hdChBVF9GRENXRCwiL3Vzci9ob21lL3plZWJzZC9mcmVlYnNkL3NoYXJlL21rL2F1dG8u b2JqLm1rIixPX1JET05MWSwwMCkgPSAzICgweDMpCmZzdGF0KDMseyBtb2RlPS1ydy1yLS1yLS0g LGlub2RlPTIzMjg5MDcsc2l6ZT0yNDg3LGJsa3NpemU9MzI3NjggfSkgPSAwICgweDApCl9fc3lz Y3RsKDB4N2ZmZmZmZmZkNDk4LDB4MiwweDdmZmZmZmZmZDQ3YywweDdmZmZmZmZmZDQ4MCwweDAs MHgwKSA9IDAgKDB4MCkKbW1hcCgweDAsNDA5NixQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJ VkFURSwzLDB4MCkgPSAzNDM2Njc0NjYyNCAoMHg4MDA2YWYwMDApCmNsb3NlKDMpCQkJCQkgPSAw ICgweDApCmxzdGF0KCIvdXNyIix7IG1vZGU9ZHJ3eHIteHIteCAsaW5vZGU9MzUzMTI2NCxzaXpl PTUxMixibGtzaXplPTMyNzY4IH0pID0gMCAoMHgwKQpsc3RhdCgiL3Vzci9vYmoiLHsgbW9kZT1k cnd4ci14ci14ICxpbm9kZT0zNjkyMjI5LHNpemU9NTEyLGJsa3NpemU9MzI3NjggfSkgPSAwICgw eDApCmxzdGF0KCIvdXNyL29iai91c3IiLHsgbW9kZT1kcnd4ci14ci14ICxpbm9kZT0zMDUwNDkw LHNpemU9NTEyLGJsa3NpemU9MzI3NjggfSkgPSAwICgweDApCmxzdGF0KCIvdXNyL29iai91c3Iv aG9tZSIseyBtb2RlPWRyd3hyd3hyLXggLGlub2RlPTMxMzA0ODIsc2l6ZT01MTIsYmxrc2l6ZT0z Mjc2OCB9KSA9IDAgKDB4MCkKbHN0YXQoIi91c3Ivb2JqL3Vzci9ob21lL3plZWJzZCIseyBtb2Rl PWRyd3hyd3hyLXggLGlub2RlPTMxMzA0ODMsc2l6ZT01MTIsYmxrc2l6ZT0zMjc2OCB9KSA9IDAg KDB4MCkKbHN0YXQoIi91c3Ivb2JqL3Vzci9ob21lL3plZWJzZC9mcmVlYnNkIix7IG1vZGU9ZHJ3 eHJ3eHIteCAsaW5vZGU9MzEzMDQ4NCxzaXplPTUxMixibGtzaXplPTMyNzY4IH0pID0gMCAoMHgw KQpsc3RhdCgiL3Vzci9vYmovdXNyL2hvbWUvemVlYnNkL2ZyZWVic2QvYW1kNjQuYW1kNjQiLHsg bW9kZT1kcnd4cnd4ci14ICxpbm9kZT0zMTMwNDg1LHNpemU9NTEyLGJsa3NpemU9MzI3NjggfSkg PSAwICgweDApCmxzdGF0KCIvdXNyL29iai91c3IvaG9tZS96ZWVic2QvZnJlZWJzZC9hbWQ2NC5h bWQ2NC90b29scyIseyBtb2RlPWRyd3hyd3hyLXggLGlub2RlPTMxMzA0ODYsc2l6ZT01MTIsYmxr c2l6ZT0zMjc2OCB9KSA9IDAgKDB4MCkKbHN0YXQoIi91c3Ivb2JqL3Vzci9ob21lL3plZWJzZC9m cmVlYnNkL2FtZDY0LmFtZDY0L3Rvb2xzL3Rvb2xzIix7IG1vZGU9ZHJ3eHJ3eHIteCAsaW5vZGU9 MzEzMDQ4NyxzaXplPTUxMixibGtzaXplPTMyNzY4IH0pID0gMCAoMHgwKQpsc3RhdCgiL3Vzci9v YmovdXNyL2hvbWUvemVlYnNkL2ZyZWVic2QvYW1kNjQuYW1kNjQvdG9vbHMvdG9vbHMvc21va2V0 ZXN0c3VpdGUiLHsgbW9kZT1kcnd4ci14ci14ICxpbm9kZT0zMTMwNTI3LHNpemU9MTAyNCxibGtz aXplPTMyNzY4IH0pID0gMCAoMHgwKQpzdGF0KCIvdXNyL29iai91c3IvaG9tZS96ZWVic2QvZnJl ZWJzZC9hbWQ2NC5hbWQ2NC90b29scy90b29scy9zbW9rZXRlc3RzdWl0ZSIseyBtb2RlPWRyd3hy LXhyLXggLGlub2RlPTMxMzA1Mjcsc2l6ZT0xMDI0LGJsa3NpemU9MzI3NjggfSkgPSAwICgweDAp CnN0YXQoIi91c3Ivb2JqL3Vzci9ob21lL3plZWJzZC9mcmVlYnNkL2FtZDY0LmFtZDY0L3Rvb2xz L3Rvb2xzL3Ntb2tldGVzdHN1aXRlIix7IG1vZGU9ZHJ3eHIteHIteCAsaW5vZGU9MzEzMDUyNyxz aXplPTEwMjQsYmxrc2l6ZT0zMjc2OCB9KSA9IDAgKDB4MCkKbXVubWFwKDB4ODAwNmFmMDAwLDQw OTYpCQkJID0gMCAoMHgwKQpzdGF0KCIvdXNyL2hvbWUvemVlYnNkL2ZyZWVic2Qvc2hhcmUvbWsv YnNkLnN1ZmZpeGVzLm1rIix7IG1vZGU9LXJ3LXItLXItLSAsaW5vZGU9MjMyODk0OSxzaXplPTIz OTIsYmxrc2l6ZT0zMjc2OCB9KSA9IDAgKDB4MCkKb3BlbmF0KEFUX0ZEQ1dELCIvdXNyL2hvbWUv emVlYnNkL2ZyZWVic2Qvc2hhcmUvbWsvYnNkLnN1ZmZpeGVzLm1rIixPX1JET05MWSwwMCkgPSAz ICgweDMpCmZzdGF0KDMseyBtb2RlPS1ydy1yLS1yLS0gLGlub2RlPTIzMjg5NDksc2l6ZT0yMzky LGJsa3NpemU9MzI3NjggfSkgPSAwICgweDApCl9fc3lzY3RsKDB4N2ZmZmZmZmZkNDk4LDB4Miww eDdmZmZmZmZmZDQ3YywweDdmZmZmZmZmZDQ4MCwweDAsMHgwKSA9IDAgKDB4MCkKbW1hcCgweDAs NDA5NixQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURSwzLDB4MCkgPSAzNDM2Njc0NjYy NCAoMHg4MDA2YWYwMDApCmNsb3NlKDMpCQkJCQkgPSAwICgweDApCm11bm1hcCgweDgwMDZhZjAw MCw0MDk2KQkJCSA9IDAgKDB4MCkKc3RhdCgiL2V0Yy9tYWtlLmNvbmYiLDB4N2ZmZmZmZmZkM2M4 KQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwpvcGVuYXQoQVRfRkRDV0QsIi91 c3IvaG9tZS96ZWVic2QvZnJlZWJzZC9zaGFyZS9tay9sb2NhbC5zeXMubWsiLE9fUkRPTkxZLDAw KSA9IDMgKDB4MykKZnN0YXQoMyx7IG1vZGU9LXJ3LXItLXItLSAsaW5vZGU9MjMyODExOCxzaXpl PTIzNzYsYmxrc2l6ZT0zMjc2OCB9KSA9IDAgKDB4MCkKX19zeXNjdGwoMHg3ZmZmZmZmZmQ0OTgs MHgyLDB4N2ZmZmZmZmZkNDdjLDB4N2ZmZmZmZmZkNDgwLDB4MCwweDApID0gMCAoMHgwKQptbWFw KDB4MCw0MDk2LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFLDMsMHgwKSA9IDM0MzY2 NzQ2NjI0ICgweDgwMDZhZjAwMCkKY2xvc2UoMykJCQkJCSA9IDAgKDB4MCkKc3RhdCgiL3Vzci9o b21lL3plZWJzZC9mcmVlYnNkL3NoYXJlL21rL3NyYy5zeXMubWsiLHsgbW9kZT0tcnctci0tci0t ICxpbm9kZT0yMzI4OTU4LHNpemU9MTQwMCxibGtzaXplPTMyNzY4IH0pID0gMCAoMHgwKQpvcGVu YXQoQVRfRkRDV0QsIi91c3IvaG9tZS96ZWVic2QvZnJlZWJzZC9zaGFyZS9tay9zcmMuc3lzLm1r IixPX1JET05MWSwwMCkgPSAzICgweDMpCmZzdGF0KDMseyBtb2RlPS1ydy1yLS1yLS0gLGlub2Rl PTIzMjg5NTgsc2l6ZT0xNDAwLGJsa3NpemU9MzI3NjggfSkgPSAwICgweDApCl9fc3lzY3RsKDB4 N2ZmZmZmZmZkNDk4LDB4MiwweDdmZmZmZmZmZDQ3YywweDdmZmZmZmZmZDQ4MCwweDAsMHgwKSA9 IDAgKDB4MCkKbW1hcCgweDAsNDA5NixQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURSwz LDB4MCkgPSAzNDM2Njc1MDcyMCAoMHg4MDA2YjAwMDApCmNsb3NlKDMpCQkJCQkgPSAwICgweDAp CnN0YXQoIi9ldGMvc3JjLmNvbmYiLDB4N2ZmZmZmZmZkMzU4KQkJIEVSUiMyICdObyBzdWNoIGZp bGUgb3IgZGlyZWN0b3J5JwptdW5tYXAoMHg4MDA2YjAwMDAsNDA5NikJCQkgPSAwICgweDApCm11 bm1hcCgweDgwMDZhZjAwMCw0MDk2KQkJCSA9IDAgKDB4MCkKc3RhdCgiL3Vzci9ob21lL3plZWJz ZC9mcmVlYnNkL3Rvb2xzL3Rvb2xzL3Ntb2tldGVzdHN1aXRlLy4uLy4uL01rL2JzZC5wb3J0Lm1r IiwweDdmZmZmZmZmZDNjOCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCm11bm1h cCgweDgwMDZhYzAwMCwxMjI4OCkJCQkgPSAwICgweDApCm9wZW5hdChBVF9GRENXRCwiL3Vzci9o b21lL3plZWJzZC9mcmVlYnNkL3Rvb2xzL3Rvb2xzL3Ntb2tldGVzdHN1aXRlL0JTRG1ha2VmaWxl IixPX1JET05MWSwwMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCm9wZW5hdChB VF9GRENXRCwiL3Vzci9vYmovdXNyL2hvbWUvemVlYnNkL2ZyZWVic2QvYW1kNjQuYW1kNjQvdG9v bHMvdG9vbHMvc21va2V0ZXN0c3VpdGUvQlNEbWFrZWZpbGUiLE9fUkRPTkxZLDAwKSBFUlIjMiAn Tm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKb3BlbmF0KEFUX0ZEQ1dELCIvdXNyL2hvbWUvemVl YnNkL2ZyZWVic2QvdG9vbHMvdG9vbHMvc21va2V0ZXN0c3VpdGUvbWFrZWZpbGUiLE9fUkRPTkxZ LDAwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKb3BlbmF0KEFUX0ZEQ1dELCIv dXNyL29iai91c3IvaG9tZS96ZWVic2QvZnJlZWJzZC9hbWQ2NC5hbWQ2NC90b29scy90b29scy9z bW9rZXRlc3RzdWl0ZS9tYWtlZmlsZSIsT19SRE9OTFksMDApIEVSUiMyICdObyBzdWNoIGZpbGUg b3IgZGlyZWN0b3J5JwpvcGVuYXQoQVRfRkRDV0QsIi91c3IvaG9tZS96ZWVic2QvZnJlZWJzZC90 b29scy90b29scy9zbW9rZXRlc3RzdWl0ZS9NYWtlZmlsZSIsT19SRE9OTFksMDApID0gMyAoMHgz KQpmc3RhdCgzLHsgbW9kZT0tcnctci0tci0tICxpbm9kZT05NjUwMzksc2l6ZT04NjYsYmxrc2l6 ZT0zMjc2OCB9KSA9IDAgKDB4MCkKX19zeXNjdGwoMHg3ZmZmZmZmZmQ0ZjgsMHgyLDB4N2ZmZmZm ZmZkNGRjLDB4N2ZmZmZmZmZkNGUwLDB4MCwweDApID0gMCAoMHgwKQptbWFwKDB4MCw0MDk2LFBS T1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFLDMsMHgwKSA9IDM0MzY2NzM0MzM2ICgweDgw MDZhYzAwMCkKY2xvc2UoMykJCQkJCSA9IDAgKDB4MCkKbXVubWFwKDB4ODAwNmFjMDAwLDQwOTYp CQkJID0gMCAoMHgwKQpvcGVuYXQoQVRfRkRDV0QsIi91c3IvaG9tZS96ZWVic2QvZnJlZWJzZC90 b29scy90b29scy9zbW9rZXRlc3RzdWl0ZS8uZGVwZW5kIixPX1JET05MWSwwMCkgRVJSIzIgJ05v IHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCm9wZW5hdChBVF9GRENXRCwiL3Vzci9vYmovdXNyL2hv bWUvemVlYnNkL2ZyZWVic2QvYW1kNjQuYW1kNjQvdG9vbHMvdG9vbHMvc21va2V0ZXN0c3VpdGUv LmRlcGVuZCIsT19SRE9OTFksMDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwpz aWdhY3Rpb24oU0lHSU5ULHsgU0lHX0lHTiBTQV9SRVNUQVJUIHNzX3QgfSx7IFNJR19ERkwgU0Ff UkVTVEFSVCBzc190IH0pID0gMCAoMHgwKQpzaWdhY3Rpb24oU0lHSU5ULHsgMHg0MDI1MzAgU0Ff UkVTVEFSVCBzc190IH0seyBTSUdfSUdOIFNBX1JFU1RBUlQgc3NfdCB9KSA9IDAgKDB4MCkKc2ln YWN0aW9uKFNJR1RFUk0seyBTSUdfSUdOIFNBX1JFU1RBUlQgc3NfdCB9LHsgU0lHX0RGTCBTQV9S RVNUQVJUIHNzX3QgfSkgPSAwICgweDApCnNpZ2FjdGlvbihTSUdURVJNLHsgMHg0MDI1MzAgU0Ff UkVTVEFSVCBzc190IH0seyBTSUdfSUdOIFNBX1JFU1RBUlQgc3NfdCB9KSA9IDAgKDB4MCkKc2ln YWN0aW9uKFNJR0hVUCx7IFNJR19JR04gU0FfUkVTVEFSVCBzc190IH0seyBTSUdfREZMIDB4MCBz c190IH0pID0gMCAoMHgwKQpzaWdhY3Rpb24oU0lHSFVQLHsgMHg0MDI1MzAgU0FfUkVTVEFSVCBz c190IH0seyBTSUdfSUdOIFNBX1JFU1RBUlQgc3NfdCB9KSA9IDAgKDB4MCkKc2lnYWN0aW9uKFNJ R1FVSVQseyBTSUdfSUdOIFNBX1JFU1RBUlQgc3NfdCB9LHsgU0lHX0RGTCBTQV9SRVNUQVJUIHNz X3QgfSkgPSAwICgweDApCnNpZ2FjdGlvbihTSUdRVUlULHsgMHg0MDI1MzAgU0FfUkVTVEFSVCBz c190IH0seyBTSUdfSUdOIFNBX1JFU1RBUlQgc3NfdCB9KSA9IDAgKDB4MCkKc3RhdCgiZ2VuZXJh dGVfdGVzdHMiLDB4N2ZmZmZmZmZkNWYwKQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5JwpzdGF0KCJsb2dnaW5nLm8iLDB4N2ZmZmZmZmZkNWYwKQkJIEVSUiMyICdObyBzdWNoIGZp bGUgb3IgZGlyZWN0b3J5JwpzdGF0KCJ1dGlscy5vIiwweDdmZmZmZmZmZDVmMCkJCQkgRVJSIzIg J05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCnN0YXQoInJlYWRfYW5ub3RhdGlvbnMubyIsMHg3 ZmZmZmZmZmQ1ZjApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKc3RhdCgiZ2Vu ZXJhdGVfbGljZW5zZS5vIiwweDdmZmZmZmZmZDVmMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3Ig ZGlyZWN0b3J5JwpzdGF0KCJhZGRfdGVzdGNhc2UubyIsMHg3ZmZmZmZmZmQ1ZjApCQkgRVJSIzIg J05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCnN0YXQoImZldGNoX2dyb2ZmLm8iLDB4N2ZmZmZm ZmZkNWYwKQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwpzdGF0KCJnZW5lcmF0 ZV90ZXN0Lm8iLDB4N2ZmZmZmZmZkNWYwKQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5JwpzdGF0KCIvdXNyL2hvbWUvemVlYnNkL2ZyZWVic2QvdG9vbHMvdG9vbHMvc21va2V0ZXN0 c3VpdGUvbG9nZ2luZy5jcHAiLHsgbW9kZT0tcnctci0tci0tICxpbm9kZT05NjcxMDksc2l6ZT0x NTA1LGJsa3NpemU9MzI3NjggfSkgPSAwICgweDApCnN0YXQoIi91c3IvaG9tZS96ZWVic2QvZnJl ZWJzZC90b29scy90b29scy9zbW9rZXRlc3RzdWl0ZS9sb2dnaW5nLmgiLHsgbW9kZT0tcnctci0t ci0tICxpbm9kZT05NjcxMTAsc2l6ZT0xNjMzLGJsa3NpemU9MzI3NjggfSkgPSAwICgweDApCnN0 YXQoIi91c3IvaG9tZS96ZWVic2QvZnJlZWJzZC90b29scy90b29scy9zbW9rZXRlc3RzdWl0ZS91 dGlscy5jcHAiLHsgbW9kZT0tcnctci0tci0tICxpbm9kZT05NjcxMTUsc2l6ZT0xMDA2MyxibGtz aXplPTMyNzY4IH0pID0gMCAoMHgwKQpzdGF0KCIvdXNyL2hvbWUvemVlYnNkL2ZyZWVic2QvdG9v bHMvdG9vbHMvc21va2V0ZXN0c3VpdGUvdXRpbHMuaCIseyBtb2RlPS1ydy1yLS1yLS0gLGlub2Rl PTk2NzExNixzaXplPTI3MDksYmxrc2l6ZT0zMjc2OCB9KSA9IDAgKDB4MCkKc3RhdCgiL3Vzci9o b21lL3plZWJzZC9mcmVlYnNkL3Rvb2xzL3Rvb2xzL3Ntb2tldGVzdHN1aXRlL3JlYWRfYW5ub3Rh dGlvbnMuY3BwIix7IG1vZGU9LXJ3LXItLXItLSAsaW5vZGU9OTY3MTEyLHNpemU9MjI0MixibGtz aXplPTMyNzY4IH0pID0gMCAoMHgwKQpzdGF0KCIvdXNyL2hvbWUvemVlYnNkL2ZyZWVic2QvdG9v bHMvdG9vbHMvc21va2V0ZXN0c3VpdGUvcmVhZF9hbm5vdGF0aW9ucy5oIix7IG1vZGU9LXJ3LXIt LXItLSAsaW5vZGU9OTY3MTEzLHNpemU9MTUwMSxibGtzaXplPTMyNzY4IH0pID0gMCAoMHgwKQpz dGF0KCIvdXNyL2hvbWUvemVlYnNkL2ZyZWVic2QvdG9vbHMvdG9vbHMvc21va2V0ZXN0c3VpdGUv Z2VuZXJhdGVfbGljZW5zZS5jcHAiLHsgbW9kZT0tcnctci0tci0tICxpbm9kZT05NjcwNjksc2l6 ZT0zNDIzLGJsa3NpemU9MzI3NjggfSkgPSAwICgweDApCnN0YXQoIi91c3IvaG9tZS96ZWVic2Qv ZnJlZWJzZC90b29scy90b29scy9zbW9rZXRlc3RzdWl0ZS9nZW5lcmF0ZV9saWNlbnNlLmgiLHsg bW9kZT0tcnctci0tci0tICxpbm9kZT05NjcwNzksc2l6ZT0xNDQxLGJsa3NpemU9MzI3NjggfSkg PSAwICgweDApCnN0YXQoIi91c3IvaG9tZS96ZWVic2QvZnJlZWJzZC90b29scy90b29scy9zbW9r ZXRlc3RzdWl0ZS9hZGRfdGVzdGNhc2UuY3BwIix7IG1vZGU9LXJ3LXItLXItLSAsaW5vZGU9OTY3 MDU1LHNpemU9NTcxNSxibGtzaXplPTMyNzY4IH0pID0gMCAoMHgwKQpzdGF0KCIvdXNyL2hvbWUv emVlYnNkL2ZyZWVic2QvdG9vbHMvdG9vbHMvc21va2V0ZXN0c3VpdGUvYWRkX3Rlc3RjYXNlLmgi LHsgbW9kZT0tcnctci0tci0tICxpbm9kZT05NjcwNTYsc2l6ZT0xNjYzLGJsa3NpemU9MzI3Njgg fSkgPSAwICgweDApCnN0YXQoIi91c3IvaG9tZS96ZWVic2QvZnJlZWJzZC90b29scy90b29scy9z bW9rZXRlc3RzdWl0ZS9mZXRjaF9ncm9mZi5jcHAiLHsgbW9kZT0tcnctci0tci0tICxpbm9kZT05 NjcwNjIsc2l6ZT0zODcyLGJsa3NpemU9MzI3NjggfSkgPSAwICgweDApCnN0YXQoIi91c3IvaG9t ZS96ZWVic2QvZnJlZWJzZC90b29scy90b29scy9zbW9rZXRlc3RzdWl0ZS9mZXRjaF9ncm9mZi5o Iix7IG1vZGU9LXJ3LXItLXItLSAsaW5vZGU9OTY3MDY0LHNpemU9MTUwNixibGtzaXplPTMyNzY4 IH0pID0gMCAoMHgwKQpzdGF0KCIvdXNyL2hvbWUvemVlYnNkL2ZyZWVic2QvdG9vbHMvdG9vbHMv c21va2V0ZXN0c3VpdGUvZ2VuZXJhdGVfdGVzdC5jcHAiLHsgbW9kZT0tcnctci0tci0tICxpbm9k ZT05NjcwOTMsc2l6ZT0xMzgyOCxibGtzaXplPTMyNzY4IH0pID0gMCAoMHgwKQpzdGF0KCIvdXNy L2hvbWUvemVlYnNkL2ZyZWVic2QvdG9vbHMvdG9vbHMvc21va2V0ZXN0c3VpdGUvZ2VuZXJhdGVf dGVzdC5oIix7IG1vZGU9LXJ3LXItLXItLSAsaW5vZGU9OTY3MDk4LHNpemU9MTU2NSxibGtzaXpl PTMyNzY4IH0pID0gMCAoMHgwKQpzdGF0KCIvdXNyL2hvbWUvemVlYnNkL2ZyZWVic2QvdG9vbHMv dG9vbHMvc21va2V0ZXN0c3VpdGUvbG9nZ2luZy5jcHAiLHsgbW9kZT0tcnctci0tci0tICxpbm9k ZT05NjcxMDksc2l6ZT0xNTA1LGJsa3NpemU9MzI3NjggfSkgPSAwICgweDApCnN0YXQoIi91c3Iv aG9tZS96ZWVic2QvZnJlZWJzZC90b29scy90b29scy9zbW9rZXRlc3RzdWl0ZS9sb2dnaW5nLmgi LHsgbW9kZT0tcnctci0tci0tICxpbm9kZT05NjcxMTAsc2l6ZT0xNjMzLGJsa3NpemU9MzI3Njgg fSkgPSAwICgweDApCnN0YXQoImxvZ2dpbmcubyIsMHg3ZmZmZmZmZmQ1NTApCQkgRVJSIzIgJ05v IHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCmZzdGF0KDEseyBtb2RlPS1ydy1yLS1yLS0gLGlub2Rl PTk2NzA1OSxzaXplPTE4MDk0LGJsa3NpemU9MzI3NjggfSkgPSAwICgweDApCmMrKyAtSS91c3Iv bG9jYWwvaW5jbHVkZSAtc3RkPWMrKzExIC1jIGxvZ2dpbmcuY3BwCndyaXRlKDEsImMrKyAtSS91 c3IvbG9jYWwvaW5jbHVkZSAtc3RkPWMrIi4uLiw1MSkgPSA1MSAoMHgzMykKZ2V0cGlkKCkJCQkJ CSA9IDMyMjIgKDB4Yzk2KQp2Zm9yaygpCQkJCQkJID0gMzIyNCAoMHhjOTgpCmMrKzogZXJyb3I6 IG5vIHN1Y2ggZmlsZSBvciBkaXJlY3Rvcnk6ICdsb2dnaW5nLmNwcCcKYysrOiBlcnJvcjogbm8g aW5wdXQgZmlsZXMKd2FpdDQoLTEseyBFWElURUQsdmFsPTEgfSwweDAsMHgwKQkJID0gMzIyNCAo MHhjOTgpCioqKiBFcnJvciBjb2RlIDEKClN0b3AuCm1ha2U6IHN0b3BwZWQgaW4gL3Vzci9ob21l L3plZWJzZC9mcmVlYnNkL3Rvb2xzL3Rvb2xzL3Ntb2tldGVzdHN1aXRlCndyaXRlKDEsIioqKiBF cnJvciBjb2RlIDFcblxuU3RvcC5cbm1ha2U6Ii4uLiw5MykgPSA5MyAoMHg1ZCkKZXhpdCgweDEp CQkJCQkKcHJvY2VzcyBleGl0LCBydmFsID0gMQo= --001a114475ee1968f2055fd5776a-- From owner-freebsd-hackers@freebsd.org Fri Dec 8 15:03:34 2017 Return-Path: Delivered-To: freebsd-hackers@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 F3EDAE85A5E for ; Fri, 8 Dec 2017 15:03:33 +0000 (UTC) (envelope-from lm@mcvoy.com) Received: from mcvoy.com (mcvoy.com [192.169.23.250]) (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 E728B7565E for ; Fri, 8 Dec 2017 15:03:33 +0000 (UTC) (envelope-from lm@mcvoy.com) Received: by mcvoy.com (Postfix, from userid 3546) id 2990535E0C0; Fri, 8 Dec 2017 07:03:33 -0800 (PST) Date: Fri, 8 Dec 2017 07:03:33 -0800 From: Larry McVoy To: Konstantin Belousov Cc: Johannes Lundberg , Larry McVoy , freebsd-hackers@freebsd.org Subject: Re: OOM problem? Message-ID: <20171208150333.GI16028@mcvoy.com> References: <20171208011430.GA16016@mcvoy.com> <20171208101658.GD2272@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171208101658.GD2272@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 15:03:34 -0000 On Fri, Dec 08, 2017 at 12:16:58PM +0200, Konstantin Belousov wrote: > On Fri, Dec 08, 2017 at 08:18:21AM +0000, Johannes Lundberg wrote: > > Regarding potential oom overhaul. Personally I like the idea of an oom > > signal. The idea comes from iOS where applications get a callback when > > system memory is low and they're given a chance to free unused > > resources or resources that can easily be recreated, before getting > > killed completely. > The OOM signal is a topic which was discussed to death many times before. > The summary is that it does not work, because you need to provide pages > for userspace to be able to handle the signal. Just for the record, what I was proposing wasn't as ambitious as what Johannes suggested (while I like his idea it's "weird" and it's unlikely that Firefox et al would use it unless we got Linux to have the same thing). I was just suggesting that processes sleeping in vm_wait() wake up once in a while to respect signals, as in, if I kill -9 that process I want it to go away. Currently, it doesn't. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From owner-freebsd-hackers@freebsd.org Fri Dec 8 15:26:01 2017 Return-Path: Delivered-To: freebsd-hackers@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 62C26E861B6 for ; Fri, 8 Dec 2017 15:26:01 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 E9F4F7637F for ; Fri, 8 Dec 2017 15:26:00 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wm0-x231.google.com with SMTP id y82so4904092wmg.1 for ; Fri, 08 Dec 2017 07:26:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eFFvpfupnIjS7S7Sg4II7bKzH/qJbFL//qWX0f6UFAs=; b=RlU40neF+LctdUQKdmEJ8enmvAkgRA5U3dMXi+DzvQ0N3P/9TW9aAV2+/8rOkByu2i MpoP38MZi21x8vDhKCqvAzfiBokjBInvrds0HujUs83XZT6TYnbGxD2V79qM1HOFSAAY 2igSbOjt3qpMdP+LriGy+oymm/SF0SYcUYcwwvV2a1nx22MzgRWHEn2We0WWfEJhpjea DQkfLmXWy3/Jx9sovIKsw++rQ+unFxsMCi/sHV+Je9yVLpBu3oFN1YH6GwwxyQCkuSwa 8kwoNhjC1NH9G/9eAikBSb94fuv32cgnhu4b4UaGk8nhY12CLlSqxCronA3URd0Zvcym fJrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eFFvpfupnIjS7S7Sg4II7bKzH/qJbFL//qWX0f6UFAs=; b=hcFVich70Jsn3o2qH5AV18hfcesDXDDHLe33FjbItYpEbXZWEB8hplvh0sbuSrwwh9 ndpB/UE3STsPpOQuTznHsHfxkBFwFuL9hAalE1Ec590ouDwi+pFK3+fyO3fGc+6keekr zyv4OLnUxn/8omh4Yzb14LL2iGPFww0in3cG5L2LmsAlrqPqRNkG8W+6LIm4dVvr25M4 6zzjduFx0uF0Q4LZavHZCjw0M35+R0w81tLBziFhghvsjuklvQqdELrBteETENWyDxXm e1zmefohCIaUahBXIjp+74RF4swHXc1ebiqSRVs469GCD0qe9ZELP8+MtB6Fs3JXDT9X m1qA== X-Gm-Message-State: AKGB3mJri5NQgWKhfy82zM1kbIx7fC7jL9ThgJ4DN5TT8DJdHd4AA7rw DDEzhh+xRagPZW8uAwM5O68A/0t1+qg3hlwCwXw= X-Google-Smtp-Source: AGs4zMbsQiTM6zOAderS4iopOMUhkJYMDl1hQe4CaSiHWaDxpdt/X/GjKhTllYZchDylEtNKWDGu6oP94gpHAMH7+fA= X-Received: by 10.28.62.20 with SMTP id l20mr4643161wma.6.1512746759318; Fri, 08 Dec 2017 07:25:59 -0800 (PST) MIME-Version: 1.0 References: <20171208011430.GA16016@mcvoy.com> <20171208101658.GD2272@kib.kiev.ua> <20171208150333.GI16028@mcvoy.com> In-Reply-To: <20171208150333.GI16028@mcvoy.com> From: Johannes Lundberg Date: Fri, 08 Dec 2017 15:25:48 +0000 Message-ID: Subject: Re: OOM problem? To: Larry McVoy Cc: Konstantin Belousov , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 15:26:01 -0000 On Fri, 8 Dec 2017 at 16:03, Larry McVoy wrote: > On Fri, Dec 08, 2017 at 12:16:58PM +0200, Konstantin Belousov wrote: > > On Fri, Dec 08, 2017 at 08:18:21AM +0000, Johannes Lundberg wrote: > > > Regarding potential oom overhaul. Personally I like the idea of an oo= m > > > signal. The idea comes from iOS where applications get a callback whe= n > > > system memory is low and they're given a chance to free unused > > > resources or resources that can easily be recreated, before getting > > > killed completely. > > The OOM signal is a topic which was discussed to death many times befor= e. > > The summary is that it does not work, because you need to provide pages > > for userspace to be able to handle the signal. > > Just for the record, what I was proposing wasn't as ambitious as what > Johannes suggested (while I like his idea it's "weird" and it's unlikely > that Firefox et al would use it unless we got Linux to have the same > thing). I agree on that. Actually I thought Mac apps had it since iOS has it but they don=E2=80=99t. Why is it weird that programs free resources they don= =E2=80=99t use when the system needs it? I think it=E2=80=99s a great solution, much bette= r then killing random programs. However, I don=E2=80=99t really expect it to be implemented in anything but a commercial derivative of FreeBSD... Maybe it instead can be implemented in GTK to keep GUI clients being good citizens of the system. Anyways, sorry for stealing the thread. PS, not my ideas - iOS memory management. > > I was just suggesting that processes sleeping in vm_wait() wake up once > in a while to respect signals, as in, if I kill -9 that process I want it > to go away. Currently, it doesn't. > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > From owner-freebsd-hackers@freebsd.org Fri Dec 8 15:34:36 2017 Return-Path: Delivered-To: freebsd-hackers@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 ABB8AE8678A for ; Fri, 8 Dec 2017 15:34:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 EF57D76CE0; Fri, 8 Dec 2017 15:34:35 +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 vB8FYTw1095150 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Dec 2017 17:34:29 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua vB8FYTw1095150 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id vB8FYTAj095149; Fri, 8 Dec 2017 17:34:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 8 Dec 2017 17:34:29 +0200 From: Konstantin Belousov To: Larry McVoy Cc: freebsd-hackers@freebsd.org, pho@freebsd.org Subject: Re: OOM problem? Message-ID: <20171208153429.GJ2272@kib.kiev.ua> References: <20171208011430.GA16016@mcvoy.com> <20171208101543.GC2272@kib.kiev.ua> <20171208150121.GH16028@mcvoy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171208150121.GH16028@mcvoy.com> User-Agent: Mutt/1.9.1 (2017-09-22) 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-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 15:34:36 -0000 On Fri, Dec 08, 2017 at 07:01:21AM -0800, Larry McVoy wrote: > On Fri, Dec 08, 2017 at 12:15:43PM +0200, Konstantin Belousov wrote: > > > The OOM code kicks in and it behaves poorly. It doesn't kill any of > > > the big processes, those are all sleeping without PCATCH on so they are > > > skipped. > > What is the proof for this statement ? > > I let the system run overnight trying to find more memory and it never > killed any of the big processes. > > I am able to log in and kill -9 would not kill them. The wait channel of the stuck process and its kernel backtrace is the first step to investigate. > > I tried a reboot and that hung. > > It took a power cycle to get the machine back. > > I've done this multiple times and always get the same result. > > > A process waiting for a page in the fault handler must receive the page > > to get out of the handler, even if the system is in OOM. > > I may be confusing you because this is not the normal page fault on a file > code path (at least I think it is not). The process is indeed faulting > in pages but they are pages that were allocated via whatever malloc calls > these days (in SunOS it mmapped /dev/zero, before that it was sbrk(2), > I dunno what FreeBSD does, I couldn't find malloc in src/lib, I see that > it's jemalloc but /usr/src/lib/libc/stdlib/jemalloc has no files?) Backtrace would answer this question easily. > > I think we are landing in vm_wait() but I can put some debugging in there > and confirm that if that helps. There is special version of vm_wait(), vm_waitpfault(), done initially to easily distiguish page faults waiting for a page vs. other unsatisfied page allocations by the name of the wait channel. > > > > A) Don't allocate more mem than you have. This problem exists simply > > > because the system allowed malloc to return more space than the > > > system had. If the system kept track of all the mem it has (ram > > > plus swap) and when processes asked for an allocation that pushed it > > > over that limit, fail that allocation. It's yet another globally > > > locked thing (though Jeff's NUMA stuff may make that better), you > > > have to keep track of allocations and frees (as in on exit(2) not > > > free(3)), that's why I think it's detail oriented to do it this way. > > > Probably the right way but has to be done carefully and someone has > > > to care enough to keep watching that this doesn't get broken. > > This behaviour can be requested by disabling overcommit. See tuning(7). > > The code might rot from the time it was done, because this feature often > > asked for, but rarely used for real. > > Seems like that should be on by default, no? Of course no. Both program's authors and users are accustomed to the overcommit. I.e., programs freely allocate huge UVA but limit actual (faulted in) memory usage, and do fork(2) while owning huge virtual allocations. This is a common behaviour for the languages runtimes with gc, but other programs also do this. > > > > B) Sleep with PCATCH, if that doesn't work, loop sleeping for a period, > > > wake up and see if you are signaled. I'm rusty enough that I don't > > > remember if msleep() with PCATCH will catch signals or not (I don't > > > remember a msleep(), that might be a BSD thing and not a SunOS thing). > > > But whatever, either it catches signals or you replace that sleep with > > > a loop that sleeps for a second or so, wakes up and looks to see if it's > > > been signaled and if so dies, else goes back to sleep waiting for pageout > > > and/or OOM to free some mem. > > Not exactly this, but something close, was done by the patch I provided to > > you already. > > I need to double check but I'm pretty sure I'm running with your patch at > least some version of it. Doesn't help. Would it help if I packaged up > a test case? Right now I'm using something like this: > > cd LMbench2+/src > for i in 1 2 3 4 5 6 7 8 9 0 > do ../bin/*/lat_mem_rd 25g 4096 & > done > > but I could make something simpler. I'm willing to keep pushing on this > if that's helpful but if you'd prefer to debug it yourself I can package > up a test case. Should probably do that anyway. Yes, the reproduction case and machine parameters to reproduce would allow me to see system state and do additional experiments. Please send the scripts to me and Peter Holm (pho, I Cc: ed him). On Fri, Dec 08, 2017 at 07:03:33AM -0800, Larry McVoy wrote: > On Fri, Dec 08, 2017 at 12:16:58PM +0200, Konstantin Belousov wrote: > > On Fri, Dec 08, 2017 at 08:18:21AM +0000, Johannes Lundberg wrote: > > > Regarding potential oom overhaul. Personally I like the idea of an oom > > > signal. The idea comes from iOS where applications get a callback when > > > system memory is low and they're given a chance to free unused > > > resources or resources that can easily be recreated, before getting > > > killed completely. > > The OOM signal is a topic which was discussed to death many times before. > > The summary is that it does not work, because you need to provide pages > > for userspace to be able to handle the signal. > > Just for the record, what I was proposing wasn't as ambitious as what > Johannes suggested (while I like his idea it's "weird" and it's unlikely > that Firefox et al would use it unless we got Linux to have the same > thing). > > I was just suggesting that processes sleeping in vm_wait() wake up once > in a while to respect signals, as in, if I kill -9 that process I want it > to go away. Currently, it doesn't. This cannot work. Currently vm_fault() must either call pmap_enter() to install pte into page table, pointing to the proper page, or return an error. Error must be returned only for the actual cause, i.e. we should not return a code (similar to EFAULT, but it is Mach error, not errno) when we have some transient problem unrelated to the process address map. The reason is that vm_fault() handles not only page faults from userspace, but also kernel accesses. The caller of vm_fault() might not be the trap() routine which handles faults, but other kernel code like uiomove(9) called from a subsystem. In other words, signal might be impossible to deliver (e.g. by terminating the process) in the context which called vm_fault(). So even if we detect a signal in vm_waitpfault(), we still must allocate the page. And if we must allocate it, there is no point in checking for signals. We already speed up allocation in noted that the process was killed. From owner-freebsd-hackers@freebsd.org Fri Dec 8 16:28:21 2017 Return-Path: Delivered-To: freebsd-hackers@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 A66D3E87D9A for ; Fri, 8 Dec 2017 16:28:21 +0000 (UTC) (envelope-from asomers@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 26FC6793F7; Fri, 8 Dec 2017 16:28:21 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x229.google.com with SMTP id f20so12464798lfe.3; Fri, 08 Dec 2017 08:28:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CquSOIFnexwqi7o3m3ONO6FRwCEUK/VzpzI6rpNUTN4=; b=exC6yCq34vfwQpFb0lb4jMEwwO0euAHy93IiVMdBJurKYIFFMzn+2WqiUWWsondGhU oaXtBTJGsHCh4Notvc8HjRTO2PUoOCtesXBdOENpYZ0YzWPACk/w63n0B/Qb/+UY722g w/qXCTyJK0NTWSP577nhsRNPDpgIPHAP45tLVHFhBDHIxGv4kFKxv6Ta78C6hR6EaFAr zBX+gHUtdThPUm/GmC41INVu6WoCO/loc4lmGZYa9Xg4JoLcC4QX0eN2p3z0P/vwWsT9 pYifX9bCsdZG2N0y/M2GJrETmoAhVwIIuafqMqLBpSAJhkPyuQalgFm/PC4/lxqaz4wb cZGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CquSOIFnexwqi7o3m3ONO6FRwCEUK/VzpzI6rpNUTN4=; b=JxxijXz6NP8zsjftLsEROyp/TBrp4TlBOwnEgGl1zLB2WeGjTTVY8XEm9lXbKRb0Vh Kxjd2Rsu+MmrOsSIjMjihMtSgqaj2X5wvdZW6S2MEprMh1xXYYpVPl7QEqPP5TCJVUx1 otuISQJPoQuYyfzpFP25PcSq4mI4BOeiwWuU8T2zjo17e4V7Pq4r7DHZevDQpOJVxPId Nk0I352+hx4pCM0UPgYPnfNp9NDrpbkfK+AItqz2K1lzDGQxFOB+O7cmtPU43j088WS1 0C/GfYU5D7XKuRhtxDjJNPNA70r9mNadBG2b36mQfr7CqTlOWHMT8qSvy+bh4GU4grYC cByg== X-Gm-Message-State: AJaThX5eM0KZDexg0+3dQwoZP16J55V2frXqbkBAX8bJxDHzIclHhvpM 5bUwqQuSmpL6uzmeCAmE4emTCzKECt9/FNLrMs4= X-Google-Smtp-Source: AGs4zMZK2wqJbBsgJu6ickGHyxlux3W3mflV12l2ptdFb3GlMd18fLRbvQZ8QAzageBfG9SOTvWJOQBUYmDD7QSfhqo= X-Received: by 10.46.20.4 with SMTP id u4mr16402116ljd.38.1512750497772; Fri, 08 Dec 2017 08:28:17 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.76.19 with HTTP; Fri, 8 Dec 2017 08:28:16 -0800 (PST) In-Reply-To: References: From: Alan Somers Date: Fri, 8 Dec 2017 09:28:16 -0700 X-Google-Sender-Auth: nyzuFr_LiDwiDfkZkqOgSL3arZ4 Message-ID: Subject: Re: Different behavior when running `make` To: Shivansh Rai Cc: "freebsd-hackers@freebsd.org" Content-Type: multipart/mixed; boundary="f403045fb7760dda62055fd6ac80" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 16:28:21 -0000 --f403045fb7760dda62055fd6ac80 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 8, 2017 at 8:01 AM, Shivansh Rai wrote: > Hello all, > > I'm currently working on a tool for automating generation of smoketests for > all the utilities in the base system [1]. Until now I was testing things on > a very old branch from around August (git sha 92d8705), and after updating > my branch (git sha 7ea30ed) I'm starting to notice a different behavior. > > The tool is located at `~/freebsd/tools/tools/smoketestsuite` [2] in my > system. > Executing `make` inside [2] produces the following output - > ``` > [Creating objdir > /usr/obj/usr/home/zeebsd/freebsd/amd64.amd64/tools/ > tools/smoketestsuite...] > c++ -I/usr/local/include -std=c++11 -c logging.cpp > c++: error: no such file or directory: 'logging.cpp' > c++: error: no input files > *** Error code 1 > ``` > > The interesting thing to be noted is the first line of the above trace > where a new directory under `/usr/obj` is created (I've noticed this for > the first time, after I updated my branch). > > The location > `/usr/obj/usr/home/zeebsd/freebsd/amd64.amd64/tools/tools/smoketestsuite` > [3] is empty, and it seems that `make` tries to look up `logging.cpp` (and > all other files) in [3] instead of [2]. This is evident from the fact that > if I manually populate [3] will all the relevant files, everything works > fine. > Also, all the side-effects which `make` introduces (new files, new binaries > etc.) are populated at [3] instead of [2]. > > If the tool is kept at a location outside the src tree (not under > `~/freebsd`), everything works fine (and the temporary directory under > `/usr/obj` is not created for those locations when `make` is executed). So > the problem seems to be in the way `make` is running inside the src tree. > > I've attached the system call trace for the failing execution. > It'd be extremely helpful if someone could please shed light on what seems > to be the problem here, and what should be the right workflow. > > [1]: For some more reference, the tool is currently available at ` > https://github.com/shivansh/smoketestsuite/' (svn branch) (D12249). > [2]: `~/freebsd/tools/tools/smoketestsuite` > [3]: > `/usr/obj/usr/home/zeebsd/freebsd/amd64.amd64/tools/tools/smoketestsuite` > > Thanks in advance! > With best regards, > Shivansh Rai > make is failing because it's implicitly cd'ing to ${MAKEOBJDIRPREFIX}/${.CURDIR} before running any commands. I don't know if that's at all contingent on the build being started from within a FreeBSD source tree, but the easiest solution is to work with the build system rather than against it. I've attached a working version. The scripts don't all work, however. They still contain assumptions about pwd, for example at scripts/fetch_utils.sh:32. -Alan --f403045fb7760dda62055fd6ac80 Content-Type: application/octet-stream; name=Makefile Content-Disposition: attachment; filename=Makefile Content-Transfer-Encoding: base64 X-Attachment-Id: f_jay4krr61 IyAkRnJlZUJTRCQKIwojIE1ha2VmaWxlIGZvciBidWlsZGluZyB0aGUgdGVzdCBnZW5lcmF0aW9u IHRvb2wKClBST0dfQ1hYPQlnZW5lcmF0ZV90ZXN0cwpMT0NBTEJBU0U9CS91c3IvbG9jYWwKTUFO PQpDWFhGTEFHUys9CS1JJHtMT0NBTEJBU0V9L2luY2x1ZGUgLXN0ZD1jKysxMQpMREZMQUdTKz0J LUwke0xPQ0FMQkFTRX0vbGliIC1sYm9vc3RfZmlsZXN5c3RlbSAtbGJvb3N0X3N5c3RlbQpTUkNT PQlsb2dnaW5nLmNwcCBcCgl1dGlscy5jcHAgXAoJcmVhZF9hbm5vdGF0aW9ucy5jcHAgXAoJZ2Vu ZXJhdGVfbGljZW5zZS5jcHAgXAoJYWRkX3Rlc3RjYXNlLmNwcCBcCglmZXRjaF9ncm9mZi5jcHAg XAoJZ2VuZXJhdGVfdGVzdC5jcHAKCi5QSE9OWTogY2xlYW4gXAoJZmV0Y2hfZ3JvZmYgXAoJZmV0 Y2hfdXRpbHMgXAoJcnVuCgpmZXRjaF9ncm9mZjoKCXNoICR7LkNVUkRJUn0vc2NyaXB0cy9mZXRj aF9ncm9mZi5zaAoKZmV0Y2hfdXRpbHM6CglzaCAkey5DVVJESVJ9L3NjcmlwdHMvZmV0Y2hfdXRp bHMuc2gKCnJ1bjoKCUBlY2hvIEdlbmVyYXRpbmcgYW5ub3RhdGlvbnMuLi4KCXNoICR7LkNVUkRJ Un0vc2NyaXB0cy9nZW5lcmF0ZV9hbm5vdC5zaAoJQGVjaG8gR2VuZXJhdGluZyB0ZXN0IGZpbGVz Li4uCgkuL2dlbmVyYXRlX3Rlc3RzCgouaW5jbHVkZSA8YnNkLnByb2cubWs+Cg== --f403045fb7760dda62055fd6ac80-- From owner-freebsd-hackers@freebsd.org Fri Dec 8 16:44:21 2017 Return-Path: Delivered-To: freebsd-hackers@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 CFE4FE8821D for ; Fri, 8 Dec 2017 16:44:21 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) (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 AB4DE79C64 for ; Fri, 8 Dec 2017 16:44:21 +0000 (UTC) (envelope-from pho@holm.cc) Received: from x2.osted.lan (87-58-223-204-dynamic.dk.customer.tdc.net [87.58.223.204]) by relay01.pair.com (Postfix) with ESMTP id 0A912D003F9; Fri, 8 Dec 2017 11:44:13 -0500 (EST) Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.9/8.14.9) with ESMTP id vB8GiBbA085742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Dec 2017 17:44:11 +0100 (CET) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.9/8.14.9/Submit) id vB8GiAIB085741; Fri, 8 Dec 2017 17:44:10 +0100 (CET) (envelope-from pho) Date: Fri, 8 Dec 2017 17:44:10 +0100 From: Peter Holm To: Konstantin Belousov Cc: Larry McVoy , freebsd-hackers@freebsd.org Subject: Re: OOM problem? Message-ID: <20171208164410.GA85620@x2.osted.lan> References: <20171208011430.GA16016@mcvoy.com> <20171208101543.GC2272@kib.kiev.ua> <20171208150121.GH16028@mcvoy.com> <20171208153429.GJ2272@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171208153429.GJ2272@kib.kiev.ua> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 16:44:21 -0000 On Fri, Dec 08, 2017 at 05:34:29PM +0200, Konstantin Belousov wrote: > On Fri, Dec 08, 2017 at 07:01:21AM -0800, Larry McVoy wrote: > > On Fri, Dec 08, 2017 at 12:15:43PM +0200, Konstantin Belousov wrote: > > > > The OOM code kicks in and it behaves poorly. It doesn't kill any of > > > > the big processes, those are all sleeping without PCATCH on so they are > > > > skipped. > > > What is the proof for this statement ? > > > > I let the system run overnight trying to find more memory and it never > > killed any of the big processes. > > > > I am able to log in and kill -9 would not kill them. > The wait channel of the stuck process and its kernel backtrace is the > first step to investigate. > > > > > I tried a reboot and that hung. > > > > It took a power cycle to get the machine back. > > > > I've done this multiple times and always get the same result. > > > > > A process waiting for a page in the fault handler must receive the page > > > to get out of the handler, even if the system is in OOM. > > > > I may be confusing you because this is not the normal page fault on a file > > code path (at least I think it is not). The process is indeed faulting > > in pages but they are pages that were allocated via whatever malloc calls > > these days (in SunOS it mmapped /dev/zero, before that it was sbrk(2), > > I dunno what FreeBSD does, I couldn't find malloc in src/lib, I see that > > it's jemalloc but /usr/src/lib/libc/stdlib/jemalloc has no files?) > Backtrace would answer this question easily. > > > > > I think we are landing in vm_wait() but I can put some debugging in there > > and confirm that if that helps. > There is special version of vm_wait(), vm_waitpfault(), done initially > to easily distiguish page faults waiting for a page vs. other > unsatisfied page allocations by the name of the wait channel. > > > > > > > A) Don't allocate more mem than you have. This problem exists simply > > > > because the system allowed malloc to return more space than the > > > > system had. If the system kept track of all the mem it has (ram > > > > plus swap) and when processes asked for an allocation that pushed it > > > > over that limit, fail that allocation. It's yet another globally > > > > locked thing (though Jeff's NUMA stuff may make that better), you > > > > have to keep track of allocations and frees (as in on exit(2) not > > > > free(3)), that's why I think it's detail oriented to do it this way. > > > > Probably the right way but has to be done carefully and someone has > > > > to care enough to keep watching that this doesn't get broken. > > > This behaviour can be requested by disabling overcommit. See tuning(7). > > > The code might rot from the time it was done, because this feature often > > > asked for, but rarely used for real. > > > > Seems like that should be on by default, no? > Of course no. Both program's authors and users are accustomed to the > overcommit. I.e., programs freely allocate huge UVA but limit actual > (faulted in) memory usage, and do fork(2) while owning huge virtual > allocations. This is a common behaviour for the languages runtimes with > gc, but other programs also do this. > > > > > > > B) Sleep with PCATCH, if that doesn't work, loop sleeping for a period, > > > > wake up and see if you are signaled. I'm rusty enough that I don't > > > > remember if msleep() with PCATCH will catch signals or not (I don't > > > > remember a msleep(), that might be a BSD thing and not a SunOS thing). > > > > But whatever, either it catches signals or you replace that sleep with > > > > a loop that sleeps for a second or so, wakes up and looks to see if it's > > > > been signaled and if so dies, else goes back to sleep waiting for pageout > > > > and/or OOM to free some mem. > > > Not exactly this, but something close, was done by the patch I provided to > > > you already. > > > > I need to double check but I'm pretty sure I'm running with your patch at > > least some version of it. Doesn't help. Would it help if I packaged up > > a test case? Right now I'm using something like this: > > > > cd LMbench2+/src > > for i in 1 2 3 4 5 6 7 8 9 0 > > do ../bin/*/lat_mem_rd 25g 4096 & > > done > > > > but I could make something simpler. I'm willing to keep pushing on this > > if that's helpful but if you'd prefer to debug it yourself I can package > > up a test case. Should probably do that anyway. > Yes, the reproduction case and machine parameters to reproduce would > allow me to see system state and do additional experiments. Please send > the scripts to me and Peter Holm (pho, I Cc: ed him). > I seem to be able to reproduce this. Unfortunately I did not get a vmcore. I'll try again. https://people.freebsd.org/~pho/stress/log/kostik1067.txt - Peter From owner-freebsd-hackers@freebsd.org Fri Dec 8 17:27:44 2017 Return-Path: Delivered-To: freebsd-hackers@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 EA702E89522 for ; Fri, 8 Dec 2017 17:27:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 B364D7B5BC for ; Fri, 8 Dec 2017 17:27:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22e.google.com with SMTP id z6so6360708iti.4 for ; Fri, 08 Dec 2017 09:27:44 -0800 (PST) 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=sw/hcGltL4+hNfGTjfHRtURGvOv0oCNGh2WXvQnkX0I=; b=zz7378t1CdImMliKYFHKTACxvJQ78cy/ofc72UcvjRdz6QvfIwWeSw3XlI6a/GgOwW APxC8oYmkiiYZxDyo8SAQFjaqXD1Z5U+zHyLdIJ5xss5naowNIZluJ7MF6ZmeZnpEoeA KWEobhWMkvIVJaEl6eQaqMHIrTBD3S4v7Tk42xzGWuijT9iSbpjtoS9GcNxKr/c4Jgob jxoXgcEWNsKtqcYqw9L80VIcJxqrrrY6fP1UHtVHWeUvMTPNBOd0MXO08+KPCGMtb/LQ BuRSIMk9hslmTH7nyL2znKvLCGqPSQ7Vgru20bDjjO1NrCyXSA9IdNQXkKSmYyfHhChJ im/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=sw/hcGltL4+hNfGTjfHRtURGvOv0oCNGh2WXvQnkX0I=; b=GLcKI0+5LJde0kPC6643VM2RK/xYCPqoRox7/yifMdXc8uWkQV/2dXWTreK/ogWsZq 5wUjJWoUAdFTDuMhZygEAPnnXdfhTiArUYDkldG/GeTi0iymFxXMyDsssHK3JCPEQ++Z FwvUbREuqEWEyzWgOFQtI58KJ47iuZ7A0QnO26QJszRTc3pVmOvsFOyAQzEBbIXSd/yF 0VPPJj4qFt4kkOrXjpD6+n93wRbDfz7UANXqhjW2mcJHvHrN4NR5a4LK3260JN1zPUGP RI2s7Cez4Acm454pvAuKjB2O5dZcuaTHZLBzfB8ZfnVIhzTwdd9MshEFaaAB+7n1gvnN pntQ== X-Gm-Message-State: AKGB3mKqxUX2vl6MgZ3yMenrgGNxLViujZdC5XCFMfKi3JweRgaGhqQw Onb5vMMt8lrKk+BiCTly9Gf2JU1/AFEfaHw/+0L19Z02 X-Google-Smtp-Source: AGs4zMYRiKQkX2DONZyti9K5z7Y/pD4SG4n0QTFhZZOAfxdadb9mK+MLEpIi++vdMgu7JD5RoQ9BOoBLg8XsWRP/8vo= X-Received: by 10.36.131.200 with SMTP id d191mr7048776ite.97.1512754063540; Fri, 08 Dec 2017 09:27:43 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Fri, 8 Dec 2017 09:27:42 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20171208150333.GI16028@mcvoy.com> References: <20171208011430.GA16016@mcvoy.com> <20171208101658.GD2272@kib.kiev.ua> <20171208150333.GI16028@mcvoy.com> From: Warner Losh Date: Fri, 8 Dec 2017 10:27:42 -0700 X-Google-Sender-Auth: 8Xkzva9TL4tLwELPdBpaTk9iRf4 Message-ID: Subject: Re: OOM problem? To: Larry McVoy Cc: Konstantin Belousov , "freebsd-hackers@freebsd.org" , Johannes Lundberg Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 17:27:45 -0000 On Fri, Dec 8, 2017 at 8:03 AM, Larry McVoy wrote: > On Fri, Dec 08, 2017 at 12:16:58PM +0200, Konstantin Belousov wrote: > > On Fri, Dec 08, 2017 at 08:18:21AM +0000, Johannes Lundberg wrote: > > > Regarding potential oom overhaul. Personally I like the idea of an oom > > > signal. The idea comes from iOS where applications get a callback when > > > system memory is low and they're given a chance to free unused > > > resources or resources that can easily be recreated, before getting > > > killed completely. > > The OOM signal is a topic which was discussed to death many times before. > > The summary is that it does not work, because you need to provide pages > > for userspace to be able to handle the signal. > > Just for the record, what I was proposing wasn't as ambitious as what > Johannes suggested (while I like his idea it's "weird" and it's unlikely > that Firefox et al would use it unless we got Linux to have the same > thing). > > I was just suggesting that processes sleeping in vm_wait() wake up once > in a while to respect signals, as in, if I kill -9 that process I want it > to go away. Currently, it doesn't. AIX had SIGDANGER that would be sent when pages were getting scarce. There were still pages to be had in the system, just not many, and the idea was when you got tight on, but not out of, memory, you'd signal all the programs in the system to give them a chance to return pages to the OS they were done with. I don't recall all the details, but AIX's syslog-ish thing would create an error log when that happened. Some programs would flush all or part of their cache, etc. It worked fairly well (in that the signal was delivered), but did depend on the cooperation of the running processes not to do something stupid. https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.osdevice/page_space_trouble.htm has a minimalistic description. Not that I'm advocating it, per se, but there is historical precedent for this feature. Warner From owner-freebsd-hackers@freebsd.org Fri Dec 8 17:58:58 2017 Return-Path: Delivered-To: freebsd-hackers@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 2C498E89D29 for ; Fri, 8 Dec 2017 17:58:58 +0000 (UTC) (envelope-from shivanshrai84@gmail.com) Received: from mail-it0-f43.google.com (mail-it0-f43.google.com [209.85.214.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 E3D537C7AA; Fri, 8 Dec 2017 17:58:57 +0000 (UTC) (envelope-from shivanshrai84@gmail.com) Received: by mail-it0-f43.google.com with SMTP id d137so6470811itc.2; Fri, 08 Dec 2017 09:58:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UzUafJTG+vRqYx98Ua4uGvhauRLWNvaZp/bH3wEN3U0=; b=DWGzPMC1RiMFv1DkS94mkb5aBb6Pfp1L4QrIx5pkNtnxR56JBrF14IzV9ipgCP1f8M FmXmd+7iWiNj2gff5xCvWU8GYa0Ai3B+BDbmt02qMXxgegK3doxtPScRopeHtw0mqRcB Dlr+gq2p4impdRw+fTyWz+L4znx/nn/La59ADCin8Lv4dI/ISXq71CHd5ygPbGeaRFIO 2ePsqEblbfgi/lVMab+yjHeKqG8DTQ+dFu6Ndw3VttwwLr8JketEKWxDe4qRYsmdEyk+ 3J/GllTgzS94q4/gOmjRsZMKHHnjHBskN1TSIccVvC8s1EVNdm28QIymimagrIcl0C8H WyQw== X-Gm-Message-State: AKGB3mLQePabz2Gnk8m8RnAo+/Uo43gb9BJbnUYfnxOKxL9IRC6eyc+K gpEcrZ8M/j0BLQ6kWg+9v7vjCZZd X-Google-Smtp-Source: AGs4zMZUyWieeotVqqbTI5DpX73i2V5w7rIwsGjAPtkyWBUVYjNY4Uh2FYRZN0MNq+dzdIxMUWmk3Q== X-Received: by 10.36.70.195 with SMTP id j186mr6669746itb.32.1512755930671; Fri, 08 Dec 2017 09:58:50 -0800 (PST) Received: from mail-it0-f41.google.com (mail-it0-f41.google.com. [209.85.214.41]) by smtp.gmail.com with ESMTPSA id s4sm995339ita.12.2017.12.08.09.58.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Dec 2017 09:58:49 -0800 (PST) Received: by mail-it0-f41.google.com with SMTP id r6so6456718itr.3; Fri, 08 Dec 2017 09:58:49 -0800 (PST) X-Received: by 10.36.249.132 with SMTP id l126mr7318025ith.52.1512755928856; Fri, 08 Dec 2017 09:58:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Shivansh Rai Date: Fri, 08 Dec 2017 17:58:38 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Different behavior when running `make` To: Alan Somers Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 17:58:58 -0000 Awesome, thanks a lot! I've made the relevant updates and removed dependence on pwd: https://github.com/shivansh/smoketestsuite/compare/f3f68db...b9902cf Will update D12249 too. -- Shivansh On Fri, Dec 8, 2017 at 9:58 PM Alan Somers wrote: > On Fri, Dec 8, 2017 at 8:01 AM, Shivansh Rai wrote: > >> Hello all, >> >> I'm currently working on a tool for automating generation of smoketests >> for >> all the utilities in the base system [1]. Until now I was testing things >> on >> a very old branch from around August (git sha 92d8705), and after updating >> my branch (git sha 7ea30ed) I'm starting to notice a different behavior. >> >> The tool is located at `~/freebsd/tools/tools/smoketestsuite` [2] in my >> system. >> Executing `make` inside [2] produces the following output - >> ``` >> [Creating objdir >> >> /usr/obj/usr/home/zeebsd/freebsd/amd64.amd64/tools/tools/smoketestsuite...] >> c++ -I/usr/local/include -std=c++11 -c logging.cpp >> c++: error: no such file or directory: 'logging.cpp' >> c++: error: no input files >> *** Error code 1 >> ``` >> >> The interesting thing to be noted is the first line of the above trace >> where a new directory under `/usr/obj` is created (I've noticed this for >> the first time, after I updated my branch). >> >> The location >> `/usr/obj/usr/home/zeebsd/freebsd/amd64.amd64/tools/tools/smoketestsuite` >> [3] is empty, and it seems that `make` tries to look up `logging.cpp` (and >> all other files) in [3] instead of [2]. This is evident from the fact that >> if I manually populate [3] will all the relevant files, everything works >> fine. >> Also, all the side-effects which `make` introduces (new files, new >> binaries >> etc.) are populated at [3] instead of [2]. >> >> If the tool is kept at a location outside the src tree (not under >> `~/freebsd`), everything works fine (and the temporary directory under >> `/usr/obj` is not created for those locations when `make` is executed). So >> the problem seems to be in the way `make` is running inside the src tree. >> >> I've attached the system call trace for the failing execution. >> It'd be extremely helpful if someone could please shed light on what seems >> to be the problem here, and what should be the right workflow. >> >> [1]: For some more reference, the tool is currently available at ` >> https://github.com/shivansh/smoketestsuite/' (svn branch) (D12249). >> [2]: `~/freebsd/tools/tools/smoketestsuite` >> [3]: >> `/usr/obj/usr/home/zeebsd/freebsd/amd64.amd64/tools/tools/smoketestsuite` >> >> Thanks in advance! >> With best regards, >> Shivansh Rai >> > > make is failing because it's implicitly cd'ing to > ${MAKEOBJDIRPREFIX}/${.CURDIR} before running any commands. I don't know > if that's at all contingent on the build being started from within a > FreeBSD source tree, but the easiest solution is to work with the build > system rather than against it. I've attached a working version. The > scripts don't all work, however. They still contain assumptions about pwd, > for example at scripts/fetch_utils.sh:32. > > -Alan > From owner-freebsd-hackers@freebsd.org Fri Dec 8 18:11:28 2017 Return-Path: Delivered-To: freebsd-hackers@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 545BDE8A5F2 for ; Fri, 8 Dec 2017 18:11:28 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c: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 BBF757D345 for ; Fri, 8 Dec 2017 18:11:27 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id f140so4479468wmd.2 for ; Fri, 08 Dec 2017 10:11:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n8f7Fct1gDa5lbzCftJwGD4yo/9YmjfHzkXFv8yXBV4=; b=SRP78iiazU7zpp1Q/nNgEX6/hexeFRXfpdcekQe70XEKiwYcHxYxASUZm/Q4dWm10y uUS/Pkpyya2f0D2jeRO876p8EeoiALbfAtP3pQat7aO/2lQojYkvWzVZJUuUXDV0ZYKb j6ei/KwvxRBhDLo8uKuesDlWquP4IKXdB6io0c7Ku8JL6KKjYtzD55RGmF/7dWURQHhY COGbuIIEFtIfM26DRVOYbidW/jpwV70ytPaIS0jgeXmJjhsmaXrYGhFSGVCqzZs/ISe4 ftjluyffr+Sa7Dve+dZRm05t6im6zIAVmXY63ei4hs4E4EoLlDxbpmnmqob1Dgi6h98E Gk9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n8f7Fct1gDa5lbzCftJwGD4yo/9YmjfHzkXFv8yXBV4=; b=p4Lk8faRcBxUWtNU/JFYxSaSiNKmEZQxti2Ojf+GK92SH/LftUZ1iZCeuO2o/IsoI7 Z47rSuFWevlELRxI8YnV4QjvcVW88hoEIjSwgRxdt05VqoRw4in3doFLxg7L8Jfgvr/O yFSsv73ffi6/4mgte8vHYYH/sk0zXRF62JVkcghic37nSECfcj9t8cVaLQAZT0lwGw33 2991IGIuaI9G0pe6JxAmTJ8rpS0qBOcMM6Kn6DGBo2KaBwpbbZtyZ++t8AT55N0KGFjZ unVKcmfs8W9Jn3AlfYmZ6RY0Yi6dM0us5LtGyQ60HISd25xGEksuC7Yy1GYjk6mTCGVl EMEw== X-Gm-Message-State: AKGB3mJRVxyaO0QLbVXqomJZj1zduCtZ9piy4zs+1zXoV4/9YkN0XZ2u 3syWetMK7jdrKn1jKy8gUZnjKr1FCZUAHuMFDao= X-Google-Smtp-Source: AGs4zMY6kTJP7N/NN6/u6iG25a1tnznEvrHoAWTYVDJ8ucn6+OLFLU098hQWiEe3MxGvxI0QYoskH9fkGidKqNCgroI= X-Received: by 10.28.62.20 with SMTP id l20mr5038016wma.6.1512756685654; Fri, 08 Dec 2017 10:11:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.197.68 with HTTP; Fri, 8 Dec 2017 10:10:45 -0800 (PST) In-Reply-To: References: <20171208011430.GA16016@mcvoy.com> <20171208101658.GD2272@kib.kiev.ua> <20171208150333.GI16028@mcvoy.com> From: Johannes Lundberg Date: Fri, 8 Dec 2017 19:10:45 +0100 Message-ID: Subject: Re: OOM problem? To: Warner Losh Cc: Larry McVoy , Konstantin Belousov , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 18:11:28 -0000 On Fri, Dec 8, 2017 at 6:27 PM, Warner Losh wrote: > > > AIX had SIGDANGER that would be sent when pages were getting scarce. There > were still pages to be had in the system, just not many, and the idea was > when you got tight on, but not out of, memory, you'd signal all the programs > in the system to give them a chance to return pages to the OS they were done > with. I don't recall all the details, but AIX's syslog-ish thing would > create an error log when that happened. Some programs would flush all or > part of their cache, etc. It worked fairly well (in that the signal was > delivered), but did depend on the cooperation of the running processes not > to do something stupid. > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.osdevice/page_space_trouble.htm > has a minimalistic description. > > Not that I'm advocating it, per se, but there is historical precedent for > this feature. > > Warner > Thanks for the info. I had no idea :) From owner-freebsd-hackers@freebsd.org Sat Dec 9 00:29:02 2017 Return-Path: Delivered-To: freebsd-hackers@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 51850E93313 for ; Sat, 9 Dec 2017 00:29:02 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 27E416AB26 for ; Sat, 9 Dec 2017 00:29:02 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id vB90T3eL029952 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 9 Dec 2017 00:29:04 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id vB90SpIb058586 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Dec 2017 16:28:53 -0800 (PST) (envelope-from truckman@FreeBSD.org) Date: Fri, 8 Dec 2017 16:28:46 -0800 (PST) From: Don Lewis Subject: Re: OOM problem? To: Larry McVoy cc: Konstantin Belousov , freebsd-hackers@freebsd.org In-Reply-To: <20171208150121.GH16028@mcvoy.com> Message-ID: References: <20171208011430.GA16016@mcvoy.com> <20171208101543.GC2272@kib.kiev.ua> <20171208150121.GH16028@mcvoy.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 00:29:02 -0000 On 8 Dec, Larry McVoy wrote: > On Fri, Dec 08, 2017 at 12:15:43PM +0200, Konstantin Belousov wrote: >> A process waiting for a page in the fault handler must receive the page >> to get out of the handler, even if the system is in OOM. > > I may be confusing you because this is not the normal page fault on a file > code path (at least I think it is not). The process is indeed faulting > in pages but they are pages that were allocated via whatever malloc calls > these days (in SunOS it mmapped /dev/zero, before that it was sbrk(2), > I dunno what FreeBSD does, I couldn't find malloc in src/lib, I see that > it's jemalloc but /usr/src/lib/libc/stdlib/jemalloc has no files?) /usr/src/contrib/jemalloc From owner-freebsd-hackers@freebsd.org Sat Dec 9 00:44:54 2017 Return-Path: Delivered-To: freebsd-hackers@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 019C3E9398B for ; Sat, 9 Dec 2017 00:44:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 C384E6B4A6 for ; Sat, 9 Dec 2017 00:44:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id s37so4148031ioe.10 for ; Fri, 08 Dec 2017 16:44:53 -0800 (PST) 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=Hgg+s0k/UpZ084y5Pjcw1ReBfM+cPIkGnZ81o8yyJJ0=; b=xLFTEZ2+3az6L3GBL8VtenZiWStnzlyWDAjEQv0TWgAh4eHByR7eLmYmdTd6SD4QeW 20atRAYcjuA/YyTeQuwojZrq/rJRNxmQestbAGzuqRRHHFM/cRh58ZDTc8hfk5r7mEWX 45U8lH5prBSKqZOwzWAKyFNjH1E9G62LonaKcLemH6mP/odAJzHKzCHbpvnWbQZAIJlG mH5sUAFUOOd+8zXHguLfB4oO1wBpscd+Cko19SnDOdoNrKyIjBgvajwDs3FAkjHsLiyD Q40irbF2E6DvRxl6zoIIce5bw/YGuWsDEGYIWqp0WPW24dzGBu/Vj8j7jjIQRDVOpM1K Srjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Hgg+s0k/UpZ084y5Pjcw1ReBfM+cPIkGnZ81o8yyJJ0=; b=L6mf9RbKV4uD61nhnwvQnNBh0vori7+pYMFqR5qzQ8DI5zLN6rj/bTCIl9GRLDGYZs 5VUXlhjik2qmBFgD6dhY88HKsCMUasINcMpO9gMfVqQiR2eLbI1oem2i4TxHufZx5r38 upMJcyQAaEgowgsJpPy3QQUMbdr5Ujk+j3BT8lDBxM1sklaEH+jiJ+aoXrnNtTig/NTn NhC/vrAv0KXK5QdIckE1oiGOf8xdshpwlFAaSM7hKkoqb34GPQq+rtNoizzL6czesQU+ fKSwrAAqj620m4gFt/WXCypmDEdaTqCJg5miIeDJ9ege+WglJBtviv4RSX1KzNQ+sss3 SFtQ== X-Gm-Message-State: AKGB3mLXZfpmOryJqUCkhvkbjqa5QBFjJPq+Lf005wCZg39+PqR9BYVh /VEh7H0mbyCzQPdCZ407FWJZQ7P/aTe2A46kXzjz1A== X-Google-Smtp-Source: AGs4zMarkjMnR2j4+88PtGFKdovSn2noQRdl5UrYjyWAOTXtv4YiF+po6kd0doyve6PTf0vqTupDrgByMP3ft2jCJ4c= X-Received: by 10.107.52.140 with SMTP id b134mr17784853ioa.291.1512780292750; Fri, 08 Dec 2017 16:44:52 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Fri, 8 Dec 2017 16:44:51 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <20171208011430.GA16016@mcvoy.com> <20171208101543.GC2272@kib.kiev.ua> <20171208150121.GH16028@mcvoy.com> From: Warner Losh Date: Fri, 8 Dec 2017 17:44:51 -0700 X-Google-Sender-Auth: B2ZE9W7Wxu1eoCfzqpZI_wtdPCI Message-ID: Subject: Re: OOM problem? To: Don Lewis Cc: Larry McVoy , Konstantin Belousov , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 00:44:54 -0000 On Fri, Dec 8, 2017 at 5:28 PM, Don Lewis wrote: > On 8 Dec, Larry McVoy wrote: > > On Fri, Dec 08, 2017 at 12:15:43PM +0200, Konstantin Belousov wrote: > > >> A process waiting for a page in the fault handler must receive the page > >> to get out of the handler, even if the system is in OOM. > > > > I may be confusing you because this is not the normal page fault on a > file > > code path (at least I think it is not). The process is indeed faulting > > in pages but they are pages that were allocated via whatever malloc calls > > these days (in SunOS it mmapped /dev/zero, before that it was sbrk(2), > > I dunno what FreeBSD does, I couldn't find malloc in src/lib, I see that > > it's jemalloc but /usr/src/lib/libc/stdlib/jemalloc has no files?) > > /usr/src/contrib/jemalloc > For software we include from another source, we put the main sources in src/contrib/ and use .PATH and other tricks to reach over into the tree to compile it. Only the FreeBSD specific parts are in the main tree, and in this case that's just a Makefile. Warner From owner-freebsd-hackers@freebsd.org Sat Dec 9 01:02:06 2017 Return-Path: Delivered-To: freebsd-hackers@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 B3210E93C46; Sat, 9 Dec 2017 01:02:06 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 92B116BB21; Sat, 9 Dec 2017 01:02:06 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id vB9125ea042299 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Dec 2017 17:02:05 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id vB9125mf042298; Fri, 8 Dec 2017 17:02:05 -0800 (PST) (envelope-from sgk) Date: Fri, 8 Dec 2017 17:02:05 -0800 From: Steve Kargl To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: [PATCH] Document powl and tgammal kludges Message-ID: <20171209010205.GA42226@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 01:02:06 -0000 The following patch documents the remaining kludges that theraven@ committed in r255294 on 2013-09-06. I have cleaned up all of the others, but powl and tgammal remain. ngie@ seems to have documented the existence of powl with r290605, but did not document the rather poor numerical accuracy of the result. tgammal remains undocumented. As it is unlikely that theraven@ will document the nature of his kludge nor the existence of tgammal, I have have prepared a patch that documents the expected numerical accuracy in BUGS sections, and have also documented tgammal. Index: msun/man/exp.3 =================================================================== --- msun/man/exp.3 (revision 2046) +++ msun/man/exp.3 (working copy) @@ -28,7 +28,7 @@ .\" from: @(#)exp.3 6.12 (Berkeley) 7/31/91 .\" $FreeBSD: head/lib/msun/man/exp.3 290606 2015-11-09 10:41:27Z ngie $ .\" -.Dd November 9, 2015 +.Dd December 8, 2017 .Dt EXP 3 .Os .Sh NAME @@ -180,6 +180,15 @@ then \*(Na**0 = 1 too because x**0 = 1 for all finite and infinite x, i.e., independently of x. .El +.Sh BUGS +To conform with newer C/C++ standards, a stub implementation for +.Nm powl +was committed to the math library, where +.Nm powl +is mapped to +.Nm pow . +Thus, the numerical accuracy is at most that of the 53-bit double +precision implementation. .Sh SEE ALSO .Xr fenv 3 , .Xr ldexp 3 , Index: msun/man/lgamma.3 =================================================================== --- msun/man/lgamma.3 (revision 2046) +++ msun/man/lgamma.3 (working copy) @@ -28,7 +28,7 @@ .\" from: @(#)lgamma.3 6.6 (Berkeley) 12/3/92 .\" $FreeBSD: head/lib/msun/man/lgamma.3 282015 2015-04-26 11:35:07Z bapt $ .\" -.Dd September 12, 2014 +.Dd December 8, 2017 .Dt LGAMMA 3 .Os .Sh NAME @@ -43,7 +43,8 @@ .Nm gammaf , .Nm gammaf_r , .Nm tgamma , -.Nm tgammaf +.Nm tgammaf , +.Nm tgammal , .Nd log gamma functions, gamma function .Sh LIBRARY .Lb libm @@ -76,6 +77,8 @@ .Fn tgamma "double x" .Ft float .Fn tgammaf "float x" +.Ft "long double" +.Fn tgammal "long double x" .Sh DESCRIPTION .Fn lgamma x , .Fn lgammaf x , @@ -106,9 +109,10 @@ but the caller must provide an integer to store the sign of \(*G(x). .Pp The -.Fn tgamma x +.Fn tgamma x , +.Fn tgammaf x , and -.Fn tgammaf x +.Fn tgammal x functions return \(*G(x), with no effect on .Fa signgam . .Pp @@ -166,6 +170,15 @@ For large non-integer negative values, .Fn tgamma will underflow. +.Sh BUGS +To conform with newer C/C++ standards, a stub implementation for +.Nm tgammal +was committed to the math library, where +.Nm tgammal +is mapped to +.Nm tgammal . +Thus, the numerical accuracy is at most that of the 53-bit double +precision implementation. .Sh SEE ALSO .Xr math 3 .Sh STANDARDS @@ -174,8 +187,9 @@ .Fn lgammaf , .Fn lgammal , .Fn tgamma , +.Fn tgammaf , and -.Fn tgammaf +.Fn tgammal functions are expected to conform to .St -isoC-99 . .Sh HISTORY -- Steve From owner-freebsd-hackers@freebsd.org Sat Dec 9 01:19:42 2017 Return-Path: Delivered-To: freebsd-hackers@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 27687E94D9F for ; Sat, 9 Dec 2017 01:19:42 +0000 (UTC) (envelope-from holger.herrlich@arcor.de) Received: from vsmx009.vodafonemail.xion.oxcs.net (vsmx009.vodafonemail.xion.oxcs.net [153.92.174.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E48636C8F5 for ; Sat, 9 Dec 2017 01:19:41 +0000 (UTC) (envelope-from holger.herrlich@arcor.de) Received: from vsmx001.vodafonemail.xion.oxcs.net (unknown [192.168.75.191]) by mta-5-out.mta.xion.oxcs.net (Postfix) with ESMTP id 32B7CC03E2 for ; Sat, 9 Dec 2017 01:13:02 +0000 (UTC) Received: from bivalve.fritz.box (unknown [89.244.120.214]) by mta-5-out.mta.xion.oxcs.net (Postfix) with ESMTPA id A71923006D7 for ; Sat, 9 Dec 2017 01:12:59 +0000 (UTC) Date: Sat, 9 Dec 2017 02:12:57 +0100 From: Holger Herrlich To: freebsd-hackers@freebsd.org Subject: dualboot FreeNAS and FreeBSD Message-ID: <20171209021257.6361c33e@bivalve.fritz.box> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-VADE-STATUS: LEGIT X-Mailman-Approved-At: Sat, 09 Dec 2017 02:52:11 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 01:19:42 -0000 Hi, I want to dual boot a FreeBSD based FreeNAS and FreeBSD. While booting FreeNAS succeeds, FreeBSD is inaccessible (FreeNAS always ever boots). constraints: The FreeNAS install is either: a BIOS system partition based boot or a EFI system partition based boot deploying GPT partitioning scheme note: The dual boot is required in order to access HW. ## PROBLEMS ## Using refind: a) Selecting by GPT partition type (freebsd-zfs/freebsd-ufs): Deploying the FreeBSD's efi-loader (boot1.efi) will search for freebsd-ufs and freebsd-zfs partitions, prefering freebsd-zfs. b) Selecting by zfs pool or dataset/filesystem by ID. boot1.efi neither can choose a zfs pool nor a dataset by ID. First found rules. c) Loading FreeNAS using boot1.efi and FreeBSD by directly loading the loader (3rd stage). refind is missing a ufs driver. ---- I will try to configure one of the FreeNAS's GRUBs already in use. However, may an efi-loader be "manufactured" the way to boot one certain BSD install. What about the boot.conf mentioned in boot(8). Thanks Holger From owner-freebsd-hackers@freebsd.org Sat Dec 9 03:09:46 2017 Return-Path: Delivered-To: freebsd-hackers@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 826EFE9AAC7 for ; Sat, 9 Dec 2017 03:09:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (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 EB8ED71703 for ; Sat, 9 Dec 2017 03:09:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x243.google.com with SMTP id r13so914424iod.2 for ; Fri, 08 Dec 2017 19:09:43 -0800 (PST) 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=FtU/82KONP1oVgnueIoVNREpfL7ThhbEudcv4mC/oMU=; b=nKKw+H+ggePepi8J5b7eJgh+a2f/bE+jgI4a/V6xJGm4uv4XkMTZyZ37VFQLHU2vNY ovfYkrPMTikylcwu6RP7y0rL7+sjOOm2MhaCT67RLtIf5Lza95Pf4GG5a+3ezkUjb7zK F/DOndLpUpjv1MKFdlYdvjSut5Xe8wZnR9f6SciUF3aTD1y0TcPE/oECJ0ph9cjJXhFa E70zY16NadeIQnSigI4E+iiEeWPifd5gZnmglQuob+miU0WO9OQYE++fViGE66w7xuYo UYnWgJgFcCdPcjsIyFqkmtVfA2AtjbaNUTuZrQ9MFQ2OxOFrttfQxdVuGWdpdEGA+Fpv 1Tog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=FtU/82KONP1oVgnueIoVNREpfL7ThhbEudcv4mC/oMU=; b=pzdR2XnLTN2FSMu/ihQnxwHGGTHrlWniqTF2825G1/4GHF7abgrNboSMyTnOCOPBV7 H238JJQIVTpo2C0IoqU40JGzP3gV5/FrxrcxWkRkJ3DMxUFRHkqf4QBVo9z4rtSzO6P5 aYjLgEX/P5s3FfTuOAdX5W0zcXpZHD1sq7N5T5zZETnRoiG/T06ErmiNRdgH+jBtP0NU oFtvE9QdYLZC6rTxIJ6cU8DTgJrJuRHdovTdfXoxix/Zt+MWxasvTD3oSIcKD6xjXSCh Zw8Jfi7b4zisIAv42PMhBPVL0IVDDvQOA8s2crhG76TvbZU3tec77WiugVMyMNsFOucK 88GA== X-Gm-Message-State: AJaThX7TeNp02/VmJ4ussF4cg/W7mC2EmHhAHzLN18RZAvm8TLA4JF5E W+5Y8rOtR0ptH+0tLQMDLaWWumO0gaNxjEwrAl0lgw== X-Google-Smtp-Source: AGs4zMb2p9gePtdiuquBsocaCMAoF6qBIL995UkSIT279FxCXgOsITjKUMSrsJqLKFUn19sDg6BNiy70xMzFbWX/flo= X-Received: by 10.107.81.24 with SMTP id f24mr43851284iob.63.1512788982276; Fri, 08 Dec 2017 19:09:42 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Fri, 8 Dec 2017 19:09:41 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20171209021257.6361c33e@bivalve.fritz.box> References: <20171209021257.6361c33e@bivalve.fritz.box> From: Warner Losh Date: Fri, 8 Dec 2017 20:09:41 -0700 X-Google-Sender-Auth: 3eiFHA2RmEpRMYYL3EXqwcIa4qs Message-ID: Subject: Re: dualboot FreeNAS and FreeBSD To: Holger Herrlich Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 03:09:46 -0000 Current boot blocks don't quite support what you want to do. I'm about to commit efibootmgr which should help get us closer.... One or two more tweaks needed for loader.efi still.... Warner On Fri, Dec 8, 2017 at 6:12 PM, Holger Herrlich wrote: > > Hi, > I want to dual boot a FreeBSD based FreeNAS and FreeBSD. While booting > FreeNAS succeeds, FreeBSD is inaccessible (FreeNAS always ever boots). > > constraints: > The FreeNAS install is either: > a BIOS system partition based boot > or a EFI system partition based boot > deploying GPT partitioning scheme > > note: > The dual boot is required in order to access HW. > > > ## PROBLEMS ## > > Using refind: > > a) Selecting by GPT partition type (freebsd-zfs/freebsd-ufs): > Deploying the FreeBSD's efi-loader (boot1.efi) will search for > freebsd-ufs and freebsd-zfs partitions, prefering freebsd-zfs. > > b) Selecting by zfs pool or dataset/filesystem by ID. > boot1.efi neither can choose a zfs pool nor a dataset by ID. > First found rules. > > c) Loading FreeNAS using boot1.efi and FreeBSD by directly loading the > loader (3rd stage). > refind is missing a ufs driver. > > ---- > > I will try to configure one of the FreeNAS's GRUBs already in use. > However, may an efi-loader be "manufactured" the way to boot one > certain BSD install. > > What about the boot.conf mentioned in boot(8). > > > Thanks Holger > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Sat Dec 9 08:18:48 2017 Return-Path: Delivered-To: freebsd-hackers@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 6527BE82D67 for ; Sat, 9 Dec 2017 08:18:48 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 2F58B7C077 for ; Sat, 9 Dec 2017 08:18:47 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yw0-x236.google.com with SMTP id m81so5345598ywd.2 for ; Sat, 09 Dec 2017 00:18:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=NHTaj1ygEQUuYJ4BL+4mI13jzvO31X8DNqquL/TDMVc=; b=AsTDBd+03invp1LY9YAVWXUkQv1pkORcmWi0cGeGMtrZX4BjP/n+VICJgru/1Yzl8D cSZomMoI7uPjIXDD6tmLEd6e1k109KGKp3A0s7bvM7RTdlQ0yhv6gjpyTf46OrJMQDDd aTKSZPiIUXsfXAd6Eoj73JY2oNKUfxboS/cyY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=NHTaj1ygEQUuYJ4BL+4mI13jzvO31X8DNqquL/TDMVc=; b=ZggXZVaYQFlM4cE5MZF0gDJNI2LKh8D/r2ihR/tkRiJxPCqafrCsc1rwpaGwqTwDXM CoFDRdfmmGjldGUmSFuGkzeNqChrNC3bH9UIuTMDxZzxIcq5SlCRqlHRExZD11UuNtyr wmy+l9Z5pmslMxrzEtK8t/5tBvv6v0Mr3tKIfoVWgQD+liAQcgbpRJQSL4tllV+7RWti HgYViIs1M5kI0wCEXHge4vSyKDSe3aaPiLTQ9jB0AmoSrXbfbfyGagfthoV+9H/ClLrh ODZXnl8Z+W41VAoEBsoNe9ZkFbTr8qvZ3l9HD707wyqo8Q32AcsP2rrV+SPzFnHsszh4 WRLw== X-Gm-Message-State: AKGB3mKC9AQVD44eGgxYXmim20wpLpSz+Qkr+FAvr6jJLLO48+YjufcN WoNX9suQlWqYPhBpQDVVZN/uhBmTQzbsAQzacl1qjyPv X-Google-Smtp-Source: AGs4zMYxGDzshFxyF0+JrRtdh1AED2cqiEV+dhwUJI9u8Zkokf79iOr6aGPhxpUmYMPtMaVQXDbCzQNKtPVLrZVJ41M= X-Received: by 10.129.85.11 with SMTP id j11mr18190301ywb.434.1512807526460; Sat, 09 Dec 2017 00:18:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.15.66 with HTTP; Sat, 9 Dec 2017 00:18:15 -0800 (PST) From: Eitan Adler Date: Sat, 9 Dec 2017 00:18:15 -0800 Message-ID: Subject: for fun: cloc(1) run over FreeBSD HEAD To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 08:18:48 -0000 [70926 23:45:55.039 eax@FlyingEagle ~/svn/fbsd/head !2!]=E2=88=B4cloc . (svn:head)-[head:326724]-[326724] 71415 text files. 69012 unique files. Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/^(.*?){ <-- HERE [^$]/ at /opt/local/bin/cloc line 4850. Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/^(.*?){ <-- HERE [^$]/ at /opt/local/bin/cloc line 4850. Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/^(.*?){ <-- HERE [^$].*$/ at /opt/local/bin/cloc line 4854. Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/^(.*?){ <-- HERE [^$]/ at /opt/local/bin/cloc line 4850. Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/^(.*?){ <-- HERE [^$]/ at /opt/local/bin/cloc line 4850. Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/^(.*?){ <-- HERE [^$]/ at /opt/local/bin/cloc line 4850. Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/^(.*?){ <-- HERE [^$]/ at /opt/local/bin/cloc line 4850. 22744 files ignored. github.com/AlDanial/cloc v 1.72 T=3D518.48 s (94.7 files/s, 44035.3 lines/= s) ---------------------------------------------------------------------------= ------------- Language files blank comment code ---------------------------------------------------------------------------= ------------- C 19366 1569280 2134272 9354938 C/C++ Header 15344 519577 1200464 2973088 C++ 3627 317670 378645 1841914 Bourne Shell 2283 132428 134199 823307 Assembly 826 22476 43554 231975 m4 364 14963 6121 142417 Perl 279 15484 13512 121365 make 3997 26457 20094 115816 HTML 305 13582 1063 112990 Markdown 120 13080 0 106024 yacc 146 9558 7904 65453 Windows Module Definition 161 3348 4 35994 INI 24 3264 0 30168 Pascal 27 1778 9810 23391 D 1029 7072 30675 18288 Python 105 3453 3269 15895 TeX 5 1489 5887 11277 Objective C 103 1686 2987 10879 awk 94 1679 3409 10502 lex 54 1988 3225 9877 Korn Shell 263 2957 8060 8318 JavaScript 3 2087 1672 8251 ASP.Net 9 169 6 4863 Forth 41 1138 1945 4742 XML 36 110 92 4664 PO File 59 1481 1938 3905 dtrace 53 509 78 3544 Java 15 317 707 3211 Lisp 22 307 263 3048 CSS 13 436 137 2345 JSON 27 1 0 1967 SQL 6 519 950 1810 C Shell 6 200 100 1732 Antlr 2 0 0 1720 Windows Message File 37 182 0 1534 CMake 28 212 135 1433 Ruby 9 218 189 1248 Bourne Again Shell 7 155 245 1079 Windows Resource File 17 335 55 1073 Expect 51 94 20 1025 sed 21 35 161 793 Qt Project 4 0 0 773 DOS Batch 8 68 55 691 diff 8 66 463 488 vim script 2 35 67 425 YAML 7 26 24 409 Tcl/Tk 7 51 113 379 Mathematica 50 14 0 290 Mercury 3 20 0 196 NAnt script 3 25 0 181 Haskell 2 23 3 165 R 29 2 0 162 Velocity Template Language 1 17 0 134 C# 1 26 99 98 MUMPS 1 10 0 92 Brainfuck 1 0 7 49 Prolog 3 0 2 48 Protocol Buffers 1 47 168 47 Lua 1 6 1 41 MATLAB 1 3 0 31 F# 1 3 0 14 IDL 2 0 0 4 ---------------------------------------------------------------------------= ------------- SUM: 49120 2692216 4016849 16122580 ---------------------------------------------------------------------------= ------------- cloc . 253.13s user 240.48s system 95% cpu 8:38.88 total --=20 Eitan Adler From owner-freebsd-hackers@freebsd.org Sat Dec 9 16:52:12 2017 Return-Path: Delivered-To: freebsd-hackers@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 1C266E91233 for ; Sat, 9 Dec 2017 16:52:12 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id E41B36C550 for ; Sat, 9 Dec 2017 16:52:11 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 4917C4FEC for ; Sat, 9 Dec 2017 16:52:11 +0000 (UTC) To: "freebsd-hackers@freebsd.org" From: Eric McCorkle Subject: Hopefully useful: macro-controlled logger Message-ID: <0dd5240f-6c70-425f-7e98-7946097ea3ef@metricspace.net> Date: Sat, 9 Dec 2017 11:52:10 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 16:52:12 -0000 Hi folks, At some point in the past, I recall reading about a log4j-inspired logging API for C that used the preprocessor to avoid introducing runtime overhead. However, I've never been able to find this library, so I've used my own scrappy macro collection over the years. Anyway, on a recent flight I decided to implement a macro-controlled logging API in earnest. The github project can be found here: https://github.com/emc2/mcl It provides the ability to define module-specific loggers, log at different levels, and set a threshold for dynamically-controlled logging levels. Any log message more severe than the dynamic range will be hardwired in place, and any message less severe will be removed at compilation time. It's not large or complicated at all, but hopefully someone will find it useful. If they do, I'd be more than happy to have it added to the FreeBSD base system.