Kernel panic when loading OSS

volatilevoid

volatilevoid

Hi,

I've got another problem with 10-CURRENT and OSS:

After installing audio/oss and removing everything sound-related (see installation notes) from the kernel, starting the sound system results in a kernel panic:

/usr/local/etc/rc.d/oss onestart
Code: 
panic: Lock (sx) module subsystem sx lock not locked @ /usr/src/sys/kern/kern_module.c:223.
cpuid = 5
KDB: enter: panic
[ thread pid 1127 tid 100489 ]
Stopped at      kdb_enter+0x3e: movq    $0,kdb_why

After checking the kernel source tree, the problematic function seems to be

Code: 
217    module_t
218    module_lookupbyname(const char *name)
219    {
220        module_t mod;
221        int err;
222
[B]223        MOD_LOCK_ASSERT;[/B]
224
225        TAILQ_FOREACH(mod, &modules, link) {
226            err = strcmp(mod->name, name);
227            if (err == 0)
228                return (mod);
229        }
230        return (NULL);
231    }

I know that there was another problem with a kernel panic introduced by the integration of sound(4) in r222980 but this one seems to be different. I've got a C-Media CMI8788 which isn't supported by sound(4) so I need OSS support.

Any hints would be greatly appreciated!

Thomas
 
Make a kernel without these lines:

Code: 
# Sound support
device          sound           # Generic sound driver (required)#this line conflicts with ossv4 kmod, next lines depend on this line
device          snd_cmi         # CMedia CMI8338/CMI8738
device          snd_csa         # Crystal Semiconductor CS461x/428x
device          snd_emu10kx     # Creative SoundBlaster Live! and Audigy
device          snd_es137x      # Ensoniq AudioPCI ES137x
device          snd_hda         # Intel High Definition Audio
device          snd_ich         # Intel, NVidia and other ICH AC'97 Audio
device          snd_uaudio      # USB Audio
device          snd_via8233     # VIA VT8233x Audio
You can find kernel source code configuration file in /usr/src/sys/$yourarch/conf/GENERIC. Those lines are at the end of the file GENERIC.

It is recommended to change the name of the kernel configuration file and the identification when someone modifies it. To make it easier, create a file with a different name, with the same content of GENERIC, and then edit it with the desired modifications. Then edit the line:

Code: 
ident GENERIC
placing instead of GENERIC, the same name of your new configuration file. Then compile the kernel:

Code: 
# cd /usr/src
# make buildkernel KERNCONF=$YOURDESIREDNAME
# make installkernel KERNCONF=$YOURDESIREDNAME

This operation can take several minutes. Reboot, make sure your system is working properly, and then follow OSS4 (audio/oss) instructions (usually oss_enable="YES" in /etc/rc.conf).

Read the Handbook for a more detailed explanation.
 
Hello @ColdfireMC,

ColdfireMC said:
Make a kernel without this lines...

Code: 
# Sound support
device          sound           # Generic sound driver (required)#this line conflicts with ossv4 kmod, next lines depend on this line
device          snd_cmi         # CMedia CMI8338/CMI8738
device          snd_csa         # Crystal Semiconductor CS461x/428x
device          snd_emu10kx     # Creative SoundBlaster Live! and Audigy
device          snd_es137x      # Ensoniq AudioPCI ES137x
device          snd_hda         # Intel High Definition Audio
device          snd_ich         # Intel, NVidia and other ICH AC'97 Audio
device          snd_uaudio      # USB Audio
device          snd_via8233     # VIA VT8233x Audio
Click to expand...

I already compiled a kernel without sound support and that kernel gives me the kernel panic. I also tried GENERIC which gives me the exact same kernel panic so it may not be directly related to the sound subsystem.

You probably meant this kernel panic. That one is sound(4) related. Mine is a different one. ;)
 
Last edited by a moderator:
kldstat -v | grep snd

Can you run that before loading the OSS drivers? Can you check that the command(s) you use to start OSS do the same as the commands in the writeup on OSS that I did in the HowTo section a few years back? (or both?)
 
Looks like your problem is related this fix in work/oss-v4.2-build2007-src-bsd/kernel/OS/FreeBSD/wrapper/bsddefs.h
Code: 
#if 0 /* __FreeBSD_version >= 700031 */
/* Some crashes have been reported with SX on 7-STABLE/8-CURRENT:
 * http://4front-tech.com/forum/viewtopic.php?t=2718
 * http://4front-tech.com/forum/viewtopic.php?t=2563
 */
#define USE_SX_LOCK     1
#endif

Try to uncomment above lines and rebuild the port.
 
jb_fvwm2 said:
kldstat -v | grep snd
Click to expand...
This returned nothing so the sound subsystem is not running.

cpu82 said:
Looks like your problem is related this fix in work/oss-v4.2-build2007-src-bsd/kernel/OS/FreeBSD/wrapper/bsddefs.h
Code: 
#if 0 /* __FreeBSD_version >= 700031 */
/* Some crashes have been reported with SX on 7-STABLE/8-CURRENT:
 * http://4front-tech.com/forum/viewtopic.php?t=2718
 * http://4front-tech.com/forum/viewtopic.php?t=2563
 */
#define USE_SX_LOCK     1
#endif

Try to uncomment above lines and rebuild the port.
Click to expand...

Tried that and it still gives a kernel panic, but it seems like I found the reason for the kernel panic and it lies inside OSS: soundcard_attach() in OSS's os_freebsd.c uses the kernel function module_lookupbyname() which requires that the modules subsystem sx lock is locked but soundcard_attach() isn't locking it. I checked the latest changes to this file in the OSS source code repository and well, see the last added code block in the last revision. There you go (ironically, the commit comment is "Fixes for FreeBSD")! ;)

What surprises me a bit is that it seems no one else had this problem before. The sx lock was introduced into the modules subsystem in 2002 and the change causing the kernel panic was implemented 14 months ago.

I'll try to patch os_freebsd.c and will come back to you with the results.

Thanks for your help so far!

Thomas


Edit: I removed the module_lookupbyname() block from os_freebsd.c and now I get another kernel panic. :\

This time it's

Code: 
panic: Unregistered use of FPU in kernel

After googling this kernel panic, I found this message which describes a way how to avoid this kernel panic (can occur when code accesses the XMM registers which deliberately causes a kernel panic). So I started patching OSS to make the kernel panic go away; the problem is that it keeps coming - I patch one function then I get this kernel panic in some other function. Sometimes I'm lucky and OSS loads without panicking the kernel but that happens very rarely. So it seems I'm at least on the right track.

Has anyone maybe a hint how I can omit patching half of OSS to make it work? ;)



Edit 2: It works without panicking the kernel when OSS is compiled with GCC. Still, I get a GPF when unloading it but that's probably another issue.
 
Hello @cpu82,

I've got another update:
  1. It seems like GCC doesn't utilize the XMM registers which explains why I don't get FPU-related kernel panics with the GCC version of OSS. Compiling OSS with Clang after patching the port to use -mno-sse fixes that issue. Only the module_lookupbyname() part needs to be removed to successfully load OSS (otherwise the sx lock kernel panic occurs).
  2. I've isolated the code part which causes the trap 9 during module unloading but wasn't yet able to resolve the issue. The problem lies in os_freebsd.c in function osdev_delete():
    Code: 
    void
osdev_delete (oss_device_t * osdev)
{
  int i;

  if (osdev == NULL)
    return;

  osdev->available = 0;
[B]/*
 * Mark all minor nodes for this module as invalid.
 */
  for (i = 0; i < oss_num_cdevs; i++)
    if (oss_cdevs[i]->osdev == osdev)
      {
	if (oss_cdevs[i]->info != NULL)
	  destroy_dev (oss_cdevs[i]->info);
	oss_cdevs[i]->d = NULL;
	oss_cdevs[i]->info = NULL;
	oss_cdevs[i]->osdev = NULL;
	strcpy (oss_cdevs[i]->name, "Removed device");
      }[/B]
}
When I comment out the for loop no trap is raised with the side effect that the character devices which are created during kldload'ing the module aren't deleted which means OSS can't be reloaded again (which wouldn't be much of a problem when the machine is shut down anyway) but disabling the for loop seems to me like a very dirty hack so I would prefer to fix the problem (which I already saw in FreeBSD RELEASE versions so it doesn't seem to be a kernel related problem).

I tried to debug osdev_delete() but for an unknown reason (at least for me), ddb freezes after some time during stepping through the code so I never got to the actual crash.

I'll try out what you proposed and try to create a full backtrace, coming back to you with the results.

Bests
Thomas



Edit: Just found out that dumping the core isn't too well supported by ZFS. :r Is there something else I can do to get more information about the panic?



Edit 2: Yay, OSS causes a kernel panic also when I try to play audio. find_output_space() doesn't properly lock the mutex before calling oss_sleep()... AND it doesn't matter if USE_SX_LOCK is enabled or not. This is getting slightly annoying... x(
 
Last edited by a moderator:
volatilevoid said:
Edit 2: Yay, OSS causes a kernel panic also when I try to play audio. find_output_space() doesn't properly lock the mutex before calling oss_sleep()... AND it doesn't matter if USE_SX_LOCK is enabled or not. This is getting slightly annoying... x(
Click to expand...

Do you have kernel compiled with WITNESS? Seems that witness(4)() does not handle recursion of shared sx(9)() locks properly.

Check if you compiled with options INVARIANTS and options INVARIANT_SUPPORT in this case SX_* options should be renamed as SA_*

As MOD_LOCK_ASSERT is defined in /usr/src/sys/sys/module.h
Code: 
#define MOD_LOCK_ASSERT sx_assert(&modules_sx, SX_LOCKED)

Also, is recommended disable debugging knobs on HEAD. Read additional information in locking(9)() man page.
 
Hello @cpu82,
cpu82 said:
Do you have kernel compiled with WITNESS? Seems that witness(4)() does not handle recursion of shared sx() locks properly.

Check if you compiled with options INVARIANTS and options INVARIANT_SUPPORT in this case SX_* options should be renamed as SA_*
Click to expand...
As my kernel configuration is based on GENERIC from HEAD, I left all debugging options enabled, so I'll disable WITNESS, INVARIANTS and INVARIANTS_SUPPORT and give it another try.

Thank you very much for your support! :)

Thomas



Edit: After removing the three debugging options, I finally have sound. :)
 
Last edited by a moderator:
I'm glad the problem is solved ;)

As a personal curiosity, I investigated further about the FreeBSD support for CMedia CMI8788 audio card, and it seems that the OSSv4 infraestructure takes the cake because this card uses an unsupported PCI bridge to communicate with the motherboard.

Useful links related:

http://lists.freebsd.org/pipermail/freebsd-questions/2012-August/244601.html.

http://lists.freebsd.org/pipermail/freebsd-multimedia/2012-August/013299.html.

http://lists.freebsd.org/pipermail/freebsd-hardware/2012-September/007125.html.
 
Hi @cpu82,
cpu82 said:
As a personal curiosity, I investigated further about the FreeBSD support for CMedia CMI8788 audio card, and it seems that the OSSv4 infraestructure takes the cake because this card uses an unsupported PCI bridge to communicate with the motherboard.
Click to expand...
Thanks for the background information! I'd love to see native support for CMI878x cards in FreeBSD; unfortunately I don't have any experience with writing sound drivers otherwise I'd maybe give it a try. The OSSv4 sources really don't look too good, at least what I saw from my fiddling the last couple of days. ;)

It seems that @ariff@ agrees (look for the "OSSv4 Compatibility" sections)... :e
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top