# Kernel panic when loading OSS



## volatilevoid (May 23, 2013)

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`

```
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


```
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


----------



## ColdfireMC (May 23, 2013)

Make a kernel *without* these lines:


```
# 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
```
*Y*ou can find kernel source code configuration file in /usr/src/sys/$yourarch/conf/GENERIC. *T*hose 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:


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


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

*T*his 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.


----------



## volatilevoid (May 23, 2013)

Hello @ColdfireMC,



			
				ColdfireMC said:
			
		

> Make a kernel *without* this lines...
> 
> 
> ```
> ...



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.


----------



## jb_fvwm2 (May 23, 2013)

`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?)


----------



## cpm@ (May 23, 2013)

Looks like your problem is related this fix in work/oss-v4.2-build2007-src-bsd/kernel/OS/FreeBSD/wrapper/bsddefs.h

```
#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.


----------



## volatilevoid (May 23, 2013)

jb_fvwm2 said:
			
		

> `kldstat -v | grep snd`


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
> 
> ```
> #if 0 /* __FreeBSD_version >= 700031 */
> ...



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


```
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.


----------



## cpm@ (May 25, 2013)

Can you show the vmcore's full backtrace?

Read section 10.2. Debugging a Kernel Crash Dump with kgdb for more details.


----------



## volatilevoid (May 25, 2013)

Hello @cpu82,

I've got another update:

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).

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():

```
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(


----------



## cpm@ (May 26, 2013)

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(



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

```
#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.


----------



## volatilevoid (May 26, 2013)

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_*


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.


----------



## cpm@ (May 28, 2013)

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.


----------



## volatilevoid (May 28, 2013)

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.


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


----------

