From owner-freebsd-hackers@freebsd.org Wed Aug 28 15:10:34 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F2AE2DF390 for ; Wed, 28 Aug 2019 15:10:34 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46JThB3qSJz4KLF for ; Wed, 28 Aug 2019 15:10:34 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1567005032; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=Bz/5zZEBiOJmfLtTTu1GxTjwwSYmBRmTpGyIq3y94HpVgh42Q+wjjmD6tJ6OBOqmEZ3rgT7BARYBU BOaGop07Hhkx88aGY4DSP466OOwxn+7T9V6cbQohZRBfg4TC/ySVWfqwtRbeKvKJtFmGWP+N6IFgAs qbQlUGbQx3jqYgJMMLan7Vq2iLIaxNPgP7/vlTZHWEKuHSerCYc5IkcHyjusOQFZ0gC5DHDkdby2hx kqcuC8cAaOsHGdWnpzFQd4psm9zql9LplliYxv4wT51wk/1CjA2M/fRUexWj2DAqc6+vUuukyAC5Le KO8uBdNGrnsv5EENpTpC08ET2iet+lA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=+ddXZEC8+IfwYKdSTfqKGVbi2NKyditxNmoxXdclZ/E=; b=wCRrSc2WQZQKoXj4Eg64Hr1X7DbYJm3e4bpvhNm/l3o5VAuljekqQI4fM6kFM+RIbTpVI9ZKDtNt6 PPIwoRm4SUOKn6GE0L7gtZpwz56n2ImZUpe7k+xzLoYbUu7u4TO7Aiqf4lDDUQcEb0E24NHijsR7A6 wSQNplanTzjr4GoQZRYORBJpJJ6EH9lQvXkHc6VfKta6TPnFzh687BPVEJZcsNmE0BOLZiw8U1wvV8 3GZGK5qwNJxxpW8DyyAVFMRN5Ka0jr1s9JUY9hVN3sbo0BMzbTBeml0UlOZMkqqtIFeAPS7cQJtmMO nkD0CzMg65J5C5Corl4lPuV+Of6pCRA== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=+ddXZEC8+IfwYKdSTfqKGVbi2NKyditxNmoxXdclZ/E=; b=FHpUW3RpzBhAOjWa39GxO7MPAs95+fnJTaamXyVd6/Tbl/WKwh9mys1WoGj0mVnywR45Kp7j7eQx+ XNJ9xzOQqo+Bp1XF4/dvIyeMfIouheOLS5qJG6UGWvqqF6pUEjMauovhTfOehTPquORypSoyrO4dWE gNM9oO8iHQ/e3DEN3oq4lQPt5a6Ox1XPNj7CeG0TV9A2XvI8x/SVrbfxX+wJ4FPcI029dnr3pROxli fsG2tKDmDmIoJB6Hah+eKgQU9GULTCTjzVYcSpQ9G+dnJnxrY5l9eiq/tYZ3ui6NyHnTEa621q5y7r K53w0LT6mzEJgSlmctKacIIY5k+0laA== X-MHO-RoutePath: aGlwcGll X-MHO-User: f8653cea-c9a5-11e9-85ed-13b9aae3a1d2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id f8653cea-c9a5-11e9-85ed-13b9aae3a1d2; Wed, 28 Aug 2019 15:10:31 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x7SFASZ3013329; Wed, 28 Aug 2019 09:10:28 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <197d072dc73ec3b0426f3c4d4db8c1fdd9b124c8.camel@freebsd.org> Subject: Re: ichsmb(4) and msleep() From: Ian Lepore To: Yuri Pankov , Hans Petter Selasky , freebsd-hackers@freebsd.org Date: Wed, 28 Aug 2019 09:10:28 -0600 In-Reply-To: <311a21e3-ed61-8679-b416-b2a4c255c6e7@yuripv.net> References: <7dfebbd3-85d6-c7b7-b83b-fae8b644649e@yuripv.net> <478965aa-5256-e356-5339-de6fb82c3459@selasky.org> <63daa36a-5c22-6b08-3cd7-562fa961ab61@yuripv.net> <7f6de96d-8b56-e242-8950-04a20b197bce@selasky.org> <311a21e3-ed61-8679-b416-b2a4c255c6e7@yuripv.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46JThB3qSJz4KLF X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 15:10:35 -0000 On Wed, 2019-08-28 at 14:41 +0300, Yuri Pankov wrote: > Hans Petter Selasky wrote: > > On 2019-08-28 11:44, Yuri Pankov wrote: > > > Hans Petter Selasky wrote: > > > > On 2019-08-28 11:07, Yuri Pankov wrote: > > > > > I have a "timed sleep before timers are working" panic in > > > > > ichsmb_readb() > > > > > calling ichsmb_wait() which uses msleep(). That is trying to > > > > > jedec_dimm(4) module so it's trying to attach pretty early in > > > > > boot. > > > > > What would be the correct replacement for msleep() here? > > > > > > > > > > > > > If you only need a sleep-delay, pause() is the right one. It > > > > handles > > > > cold-boot. > > > > > > I guess that won't work here as we need to be waked up by > > > interrupt > > > handler on command completion, and pause() seems to sleep > > > unconditionally for the given time in 'cold' case (if I'm reading > > > the > > > code correctly). > > > > If you are too early inside a SYSINIT() path, then you cannot use > > sleeping. You will have to use polling in a loop with a fixed > > DELAY() to > > know the timeout. > > Thanks for the help. > > Something like the following (it seems to work)? > Do you actually need to communicate with these i2c slave devices as part of making the system usable early in boot? That sometimes happens on embedded systems where you need to communicate with a power- management system via i2c to bring up other devices. In that case you need to do polling until interrupts are available. If not, then this is probably fallout from a historic freebsd glitch where almost all i2c controller drivers attach the iicbus child before interrupts are available, and then rely on all the slave device drivers to not do any IO until interrupts are available. IMO, that's insane... a driver shouldn't attach children until it's in a state where it's able to service the IO requests from them. The simple fix is usually to change the last few lines of the controller's attach() code. Usually it's something like return bus_generic_attach(dev); and you can just change it to config_intrhook_oneshot((ich_func_t)bus_generic_attach, dev); return (0); -- Ian