Bug 30592
| Summary: | [PATCH] panic: static sysctl oid too high: 684 - when unloading snd_es137x.ko | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | mux <mux> | ||||
| Component: | kern | Assignee: | Peter Pentchev <roam> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | ||||||
| Priority: | Normal | ||||||
| Version: | 5.0-CURRENT | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
Hi, After reading sysctl_ctx_free(9), I now think my patch is bad. It clearly says that the oid_number is not changed to preserve the order of oids in the tree and sysctl_register_oid() will not panic because it will reuse the existing oid. That means that in my case, the oid was really deleted and I don't knwo why. I hope someone more aware than me will be able to fix it and I will continue to dig into this. Maxime Henrion -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code Key fingerprint = F9B6 1D5A 4963 331C 88FC CA6A AB50 1EF2 8CBE 99D6 Public Key : http://www.epita.fr/~henrio_m/ Responsible Changed From-To: freebsd-bugs->roam I introduced this panic in rev. 1.112. I'm sitting on a patch discussed in -current and -audit, awaiting aproval from Andrzej Bialecki <abial@FreeBSD.org>; howevr I think I will commit it today. State Changed From-To: open->closed Apparently fixed in version 1.117, 2001/10/12. |
panic: static sysctl oid too high: 684 (kgdb) bt [...] #10 0xc0189716 in sysctl_register_oid (oidp=0xc19710c0) at ../../../kern/kern_sysctl.c:127 #11 0xc01897f8 in sysctl_ctx_free (clist=0xc0cd3c68) at ../../../kern/kern_sysctl.c:192 (kgdb) list 191 while (e1 != NULL) { 192 sysctl_register_oid(e1->entry); 193 e1 = TAILQ_PREV(e1, sysctl_ctx_list, link); 194 } (kgdb) print *e1->entry $1 = {oid_parent = 0xc033d040, oid_link = {sle_next = 0x0}, oid_number = 684, oid_kind = -2113929215, oid_arg1 = 0xc0cd8540, oid_arg2 = 0, oid_name = 0xc0cd8550 "pcm0", oid_handler = 0, oid_fmt = 0xc0338b3d "N", oid_refcnt = 1} (kgdb) printf "%x\n",e1->entry->oid_kind 82000001 ^ CTLFLAG_DYN From src/sys/kern/kern_sysctl.c in sysctl_ctx_free() : /* * First perform a "dry run" to check if it's ok to remove oids. * XXX FIXME * XXX This algorithm is a hack. But I don't know any * XXX better solution for now... */ It appears in the comments of sysctl_ctx_free() that this function is a hack. It seems it sometimes has to re-register an oid, and sometimes tries to re-register dynamic sysctls. In that case it doesn't change the oid_number of the oid, and just call sysctl_register_oid() which panics because it is too high. I'm not able to properly fix this function right now, because I don't understand the reasons of this hack, however I can provide a patch that sets the oid_number to OID_AUTO if it was greater or equal to CTL_AUTO_START. With this patch applied, I can now happily load and unload my sound modules several times. Fix: Note: It would perhaps be better to test oid_kind against CTLFLAG_DYN instead of looking at the oid_number. How-To-Repeat: # kldunload snd_es137x