NetBSD Problem Report #56568

From mlelstv@arnold.localdomain  Wed Dec 22 15:39:55 2021
Return-Path: <mlelstv@arnold.localdomain>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id E44851A9239
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 22 Dec 2021 15:39:54 +0000 (UTC)
Message-Id: <20211222153950.1DF22BC141@arnold.localdomain>
Date: Wed, 22 Dec 2021 16:39:50 +0100 (CET)
From: mlelstv@netbsd.org
Reply-To: mlelstv@netbsd.org
To: gnats-bugs@NetBSD.org
Subject: ipmi.c 1.7 causes large boot delays
X-Send-Pr-Version: 3.95

>Number:         56568
>Category:       kern
>Synopsis:       ipmi.c 1.7 causes large boot delays
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 22 15:40:01 +0000 2021
>Last-Modified:  Fri Dec 24 13:20:01 +0000 2021
>Originator:     mlelstv@netbsd.org
>Release:        NetBSD 9.99.92
>Organization:

>Environment:


System: NetBSD pussyfoot 9.99.92 NetBSD 9.99.92 (PUSSYFOOT_XEN3_DOM0) #4: Wed Dec 22 15:04:19 UTC 2021 mlelstv@slowpoke:/scratch2/obj.amd64/scratch/netbsd-current/src/sys/arch/amd64/compile/PUSSYFOOT_XEN3_DOM0 amd64
Architecture: x86_64
Machine: amd64
>Description:
ipmi(4) talks to a separate system (the BMC) when attaching. The communication
may be done very slowly, often it is passed through the keyboard controller
and can take several ten seconds.

The driver used to set the DV_ATTACH_INPROGRESS flag to signal
that the attachment hasn't completed when ipmi_attach returns.

The flag isn't used anymore by autoconf.

Changing this to config_pending_incr/descr has a different effect,
it makes the boot process wait for the attachment to finish. This is
neither wanted nor necessary, you only have to wait for it before
you can detach the driver again.

On this system (HP ML110 G4) the attachment takes 40 seconds.

>How-To-Repeat:
>Fix:

>Audit-Trail:
From: Taylor R Campbell <riastradh@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: mlelstv@netbsd.org,
	Hauke Fath <hf@spg.tu-darmstadt.de>
Subject: Re: kern/56568: ipmi.c 1.7 causes large boot delays
Date: Fri, 24 Dec 2021 13:18:10 +0000

 There seem to be different opinions about whether or how long ipmi
 should delay boot -- in https://gnats.netbsd.org/56539 the problem was
 that boot happened too fast and ipmi wasn't ready before wdogctl tried
 to set it up!

 I don't have an opinion about whether ipmi should delay boot or
 whether there should be a different mechanism for wdogctl to wait.

 Maybe ipmi_attach can publish the watchdog immediately, and
 ipmi_watchdog_setmode can wait with cv_wait_sig for the thread to
 finish whatever it needs to do first -- and, if we don't use
 config_pending_incr/decr, then ipmi_detach will need to explicitly
 wait for the thread to finish starting up before killing it.

 (But abusing the autoconf DVF_ATTACH_INPROGRESS flag for this was
 bogus and fundamentally buggy, so whatever change you make, please
 don't bring that part back!)

>Unformatted:

Home	PR Database Search