Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
A blast from the past - strange sysctl behavior
0 views
Skip to first unread message
Paul Goyette
Sep 5, 2016, 5:42:24 AM9/5/16
to tech...@netbsd.org
Nearly a year ago, I posted [1] on the current-users list. Since that
time I've been running with the attached patch, in an attempt to find
out what was going on. And as is usually the case, the debug code
didn't get triggered, until now - 11 months later!
I haven't had a chance to investigate in any detail, but the problem
(and associated KASSERT) occurred while starting firefox. A bit more
detail shows that it was installing the sysctl tree for the sysv_ipc
module. However, after the reboot I was able to successfully launch
firefox without triggering the KASSERT.
If anyone has any clues about how this anomaly can happen (a newly
created sysctl node has a wrong parent), I'd love to hear them. I am
guessing that there's some sort of locking botch in the sysctl code,
however I haven't been able to spot it.
[1] https://mail-index.netbsd.org/current-users/2015/10/27/msg028285.html
+------------------+--------------------------+------------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+------------------+--------------------------+------------------------+
time I've been running with the attached patch, in an attempt to find
out what was going on. And as is usually the case, the debug code
didn't get triggered, until now - 11 months later!
I haven't had a chance to investigate in any detail, but the problem
(and associated KASSERT) occurred while starting firefox. A bit more
detail shows that it was installing the sysctl tree for the sysv_ipc
module. However, after the reboot I was able to successfully launch
firefox without triggering the KASSERT.
If anyone has any clues about how this anomaly can happen (a newly
created sysctl node has a wrong parent), I'd love to hear them. I am
guessing that there's some sort of locking botch in the sysctl code,
however I haven't been able to spot it.
[1] https://mail-index.netbsd.org/current-users/2015/10/27/msg028285.html
+------------------+--------------------------+------------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+------------------+--------------------------+------------------------+
Paul Goyette
Sep 5, 2016, 5:49:53 AM9/5/16
to tech...@netbsd.org
On Mon, 5 Sep 2016, Paul Goyette wrote:
> Nearly a year ago, I posted [1] on the current-users list. Since that time
> I've been running with the attached patch, in an attempt to find out what was
> going on. And as is usually the case, the debug code didn't get triggered,
> until now - 11 months later!
>
> I haven't had a chance to investigate in any detail, but the problem (and
> associated KASSERT) occurred while starting firefox. A bit more detail shows
> that it was installing the sysctl tree for the sysv_ipc module. However,
> after the reboot I was able to successfully launch firefox without triggering
> the KASSERT.
>
> If anyone has any clues about how this anomaly can happen (a newly created
> sysctl node has a wrong parent), I'd love to hear them. I am guessing that
> there's some sort of locking botch in the sysctl code, however I haven't been
> able to spot it.
>
>
> [1] https://mail-index.netbsd.org/current-users/2015/10/27/msg028285.html
FWIW, the KASSERT() triggered right after I had updated my amd64 kernel
> Nearly a year ago, I posted [1] on the current-users list. Since that time
> I've been running with the attached patch, in an attempt to find out what was
> going on. And as is usually the case, the debug code didn't get triggered,
> until now - 11 months later!
>
> I haven't had a chance to investigate in any detail, but the problem (and
> associated KASSERT) occurred while starting firefox. A bit more detail shows
> that it was installing the sysctl tree for the sysv_ipc module. However,
> after the reboot I was able to successfully launch firefox without triggering
> the KASSERT.
>
> If anyone has any clues about how this anomaly can happen (a newly created
> sysctl node has a wrong parent), I'd love to hear them. I am guessing that
> there's some sort of locking botch in the sysctl code, however I haven't been
> able to spot it.
>
>
> [1] https://mail-index.netbsd.org/current-users/2015/10/27/msg028285.html
and userland from a July 4th 7.99.33 to a Sept. 5th 7.99.36.
0 new messages