From owner-freebsd-stable@freebsd.org Sun May 1 15:07:26 2016 Return-Path: Delivered-To: freebsd-stable@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 52F45B29661 for ; Sun, 1 May 2016 15:07:26 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F030C1EEA for ; Sun, 1 May 2016 15:07:25 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id u41F7Je5062300 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 May 2016 17:07:19 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id u41F7IVf062297; Sun, 1 May 2016 17:07:19 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Sun, 1 May 2016 17:07:18 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: Scott Long cc: FreeBSD stable Subject: Re: devd(8) complains loudly when DVD player is empty, possibly due to r298134 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 15:07:26 -0000 On Wed, 27 Apr 2016 13:46-0400, Scott Long wrote: > Thanks for the report. I might be mistaken, but the default system > is not configured to direct devd messages to user.info, so I didn’t > see this during my development. However, what you’re reporting is > definitely annoying, so Warner Losh and I are working on a solution. > > Scott I solved the problem by running devd with -q, i.e. devd_flags="-q" in /etc/rc.conf. This should probably be the default anyway. All of my systems (stable/10) have custom logging where each facility has its own file. Also *.*;mark.* is sent to /dev/ttyvb and to the central log host. /dev/ttyvb was pretty busy on the log host. Making devd less chatty does have its merits. The next servers I buy will probably exclude a DVD player. Happy hacking. > > On Apr 27, 2016, at 1:23 PM, Trond Endrestøl wrote: > > > > Hi, > > > > The symptoms began after upgrading from stable/10 r298033 to stable/10 r298573. > > > > Apr 27 18:40:00 [HOSTNAME] devd: Processing event '!system=CAM subsystem=periph type=error device=cd0 serial="R8KL6GKC900AFG" cam_status="0xcc" scsi_status=2 scsi_sense="70 02 04 01" CDB="00 00 00 00 00 00 " ' > > > > These messages are just seconds apart: > > > > Apr 27 18:40:01 [HOSTNAME] devd: Processing event '!system=CAM subsystem=periph type=error device=pass1 serial="R8KL6GKC900AFG" cam_status="0xcc" scsi_status=2 scsi_sense="70 02 04 01" CDB="00 00 00 00 00 00 " ' > > Apr 27 18:40:03 [HOSTNAME] devd: Processing event '!system=CAM subsystem=periph type=error device=pass1 serial="R8KL6GKC900AFG" cam_status="0xcc" scsi_status=2 scsi_sense="70 02 04 01" CDB="00 00 00 00 00 00 " ' > > Apr 27 18:40:05 [HOSTNAME] devd: Processing event '!system=CAM subsystem=periph type=error device=pass1 serial="R8KL6GKC900AFG" cam_status="0xcc" scsi_status=2 scsi_sense="70 02 04 01" CDB="00 00 00 00 00 00 " ' > > > > When I put a CD or DVD in the DVD player, the messages stop. As soon > > as I eject the disc, they start appearing again. > > > > Here's the relevant part from dmesg: > > > > cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 > > cd0: Removable CD-ROM SCSI device > > cd0: Serial Number R8KL6GKC900AFG > > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > > cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed > > > > This is on a mid-2012 Dell Latitude E5530 with the stock DVD player. > > > > Upgrading to stable/10 r298705 doesn't resolve this issue. > > > > Does anyone else see this? > > > > Maybe r298134 is to blame: > > > > stable/10/sys/cam/cam_periph.c > > > > MFC r298004: > > > > Add a devctl/devd notification conduit for CAM errors that happen at the > > periph level. > > > > Due to not merging the changes to ata_res_sbuf(), this version is a little > > messy. > > > > Sponsored by: Netflix > > > > http://svnweb.freebsd.org/base?view=revision&revision=298134 -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-stable@freebsd.org Sun May 1 22:04:43 2016 Return-Path: Delivered-To: freebsd-stable@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 66857B29734 for ; Sun, 1 May 2016 22:04:43 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from saturn.lyxys.ka.sub.org (saturn.lyxys.ka.sub.org [217.29.35.151]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5D79197E for ; Sun, 1 May 2016 22:04:42 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (juno.lyx [IPv6:fd2a:89ca:7d54:0:240:caff:fe92:4f47]) by saturn.lyxys.ka.sub.org (8.15.2/8.15.2) with ESMTPS id u41M18DL040488 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=FAIL) for ; Mon, 2 May 2016 00:01:09 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (localhost [127.0.0.1]) by juno.lyxys.ka.sub.org (8.15.2/8.15.2) with ESMTPS id u41M18QY058979 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 2 May 2016 00:01:08 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: (from wolfgang@localhost) by juno.lyxys.ka.sub.org (8.15.2/8.15.2/Submit) id u41M18WF058978 for freebsd-stable@FreeBSD.org; Mon, 2 May 2016 00:01:08 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) X-Authentication-Warning: juno.lyx: wolfgang set sender to wolfgang@lyxys.ka.sub.org using -f Date: Mon, 2 May 2016 00:01:07 +0200 From: Wolfgang Zenker To: freebsd-stable@FreeBSD.org Subject: Recent stable: bsnmpd eats up memory and cpu Message-ID: <20160501220107.GA58930@lyxys.ka.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: private site User-Agent: Mutt/1.6.0 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (saturn.lyxys.ka.sub.org [IPv6:fd2a:89ca:7d54:1:200:24ff:feca:b4cc]); Mon, 02 May 2016 00:01:09 +0200 (CEST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 22:04:43 -0000 Hi, after updating some 10-STABLE systems a few days ago, I noticed that on two of those systems bsnmpd started to use up a lot of cpu time, and the available memory shrinked until rendering the system unusable. Killing bsnmpd stops the cpu usage but does not free up memory. Both affected systems are amd64, one having moved from r297555 to r298723, the other from r297555 to r298722. Another amd64 system that went from r297555 to r298722 appears to be not affected. The two affected systems are on an internal LAN segment and there is currently no application connecting to snmp on those machines. What would be useful debugging data to collect in this case? Wolfgang