https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
Mark Linimon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|In Progres
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
--- Comment #17 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=aeb4214375b7197ccc7c6ad9b2bc3185545eaf8e
commit aeb4214375b7197ccc7c6ad9b2bc3185545eaf8e
Author
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
--- Comment #16 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=74f11a40f8e4e1b3ae254edf499d467153242ce9
commit 74f11a40f8e4e1b3ae254edf499d467153242ce9
Author
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
--- Comment #15 from Aleksander Slomka ---
(In reply to Ed Maste from comment #14)
> The || operator performs short-circuit evaluation
Thanks for the explanation, this makes much more sense now :^)
> If you're willing I may have a patch in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
Ed Maste changed:
What|Removed |Added
Status|New |In Progress
--
You are receiving this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
--- Comment #14 from Ed Maste ---
> why the `if` statement didn't work when the condition was in reverse order
The || operator performs short-circuit evaluation - if the first condition is
true the second is not evaluated. I am still curio
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
--- Comment #13 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=da03ac41c9bca270b491fcf4bf219c4108688a05
commit da03ac41c9bca270b491fcf4bf219c4108688a05
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
--- Comment #12 from Aleksander Slomka ---
(In reply to Ed Maste from comment #11)
Thank you for the help! The patch indeed solves the issue for me. Now the
`ioctl` properly returns `EINVAL`:
31415 test CALL ioctl(0x3,SNDCTL_MIXERIN
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
--- Comment #11 from Ed Maste ---
If this is readily reproducible for you could you please give the attached
patch a try?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
--- Comment #10 from Ed Maste ---
Created attachment 232613
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=232613&action=edit
possible patch
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
--- Comment #9 from Ed Maste ---
(In reply to Aleksander Slomka from comment #8)
Indeed; trying successive mi.dev values here is fine:
#include
#include
#include
#include
#include
int
main()
{
int fd;
fd = open("/dev
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
--- Comment #8 from Aleksander Slomka ---
> The highest unit number here is 3, but when I checked in kgdb
> `devclass_get_maxunit(pcm_devclass)` returns the value `5`.
To clarify things - `devclass_get_maxunit(pcm_devclass)` should return
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
--- Comment #7 from Aleksander Slomka ---
OK, I think I know what's going on. So It looks like in my case
`devclass_get_maxunit` is returning a bigger value than the actual number of
devices. That's why on the 4th iteration of the `for` loo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
--- Comment #6 from Aleksander Slomka ---
I'm on commit 1b3bef43e3cb7fb0ab49b813839915514c1134cc.
kgdb shows that the panic happens on this line:
1463if (PCM_DETACHING(d) || !PCM_REGISTERED(d))
So for some reason when I spec
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
Ed Maste changed:
What|Removed |Added
CC||h...@freebsd.org
--- Comment #5 from Ed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
--- Comment #4 from Aleksander Slomka ---
Perhaps try setting the `dev` field to some irrational value like `-5`?
This will ensure that the value is invalid and maybe trigger the panic more
reliably.
--
You are receiving this mail because
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
--- Comment #3 from Aleksander Slomka ---
#0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=textdump@entry=1) at
/usr/src/sys/kern/kern_shutdown.c:406
#2 0x80c17dbc in kern_reboot (howto=260) at
/
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
Ed Maste changed:
What|Removed |Added
CC||ema...@freebsd.org
--- Comment #2 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
Aleksander Slomka changed:
What|Removed |Added
Attachment #232582|text/x-csrc |text/plain
mime type|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
Bug ID: 262671
Summary: Kernel panics after a invalid SNDCTL_MIXERINFO ioctl
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
20 matches
Mail list logo
