Bug 29131

Summary: Current hungs in sysctl -a while booting + patch
Product: Base System Reporter: kabaev <kabaev>
Component: kernAssignee: Peter Pentchev <roam>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 5.0-CURRENT   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff
none
kern_sysctl.c-style.patch
none
sysctl-auto-start.patch none

Description kabaev 2001-07-22 04:40:09 UTC 
	-CURRENT appears to hung while booting because sysctl -a never
	finishes. ^C can be used to interrupt the sysctl execution and
	to continue booting. 
	
	It appears, that a sysctl oid_number collision is happening. Namely,
	sysctl_register_oid allocates new numbers for OID_AUTO sysctl nodes
	starting from the number 100, while at the same time kernel registers
	predefined sysctls with ids as high as 255 (see SYSCTL_NODE for
	net.inet.raw). If I raise the starting number for dynamic sysctls
	to be 255, the problem disappears.

How-To-Repeat: 	N/A
Comment 1 Peter Pentchev freebsd_committer freebsd_triage 2001-07-22 19:17:17 UTC 
State Changed
From-To: open->analyzed

I have a patch in the works, and there is ongoing discussion 
on the -arch mailing list.
Comment 2 Peter Pentchev freebsd_committer freebsd_triage 2001-07-22 19:17:17 UTC 
Responsible Changed
From-To: freebsd-bugs->roam

I'll take a look at this.
Comment 3 Peter Pentchev 2001-07-22 21:59:34 UTC 
On Sun, Jul 22, 2001 at 03:42:33AM -0500, Alfred Perlstein wrote:
> * Peter Pentchev <roam@orbitel.bg> [010722 03:02] wrote:
> > Hi,
> > 
> > Can anyone envision any side effects from committing the patch
> > in this PR?  Seems like a trivial fix for a typo to me..
> 
> Shouldn't "magic" constants be put into the sysctl.h header?

Good call!

Attached are two patches: one to make sys/kern/kern_sysctl.c a bit
more style(9)-compliant (what made me do it was the failed search
for /^sysctl_register_oid/ when I saw it referenced), and one to put
a magic constant into sysctl.h and make kern_sysctl.c use it and
complain (albeit a bit harshly ;) about misbehaving static sysctl's.

Comments?

G'luck,
Peter

-- 
If I were you, who would be reading this sentence?
Comment 4 ak03 2001-10-29 16:40:40 UTC 
This PR can be closed.
Comment 5 ak03 2002-04-18 18:42:00 UTC 
Please close this PR.  The problem has been fixed a long time ago and 
yet PR is
still lingers in analyzed state.

This is a second attempt to get this PR closed.
Comment 6 Alexander Kabaev freebsd_committer freebsd_triage 2002-07-22 20:16:44 UTC 
State Changed
From-To: analyzed->closed

The problem has been resolved. Closed at the originator request.