HDA beep regression...

Stefan Bader stefan.bader at canonical.com
Tue Feb 23 09:20:49 UTC 2010


Daniel J Blueman wrote:
> Hi Andy,
> 
> On Tue, Feb 9, 2010 at 3:41 PM, Daniel J Blueman
> <daniel.blueman at gmail.com> wrote:
>> Hi Andy,
>>
>> On Tue, Feb 9, 2010 at 3:10 PM, Andy Whitcroft <apw at canonical.com> wrote:
>>> On Tue, Feb 09, 2010 at 02:48:04PM +0000, Daniel J Blueman wrote:
>>>> Hi Tim, Andy,
>>>>
>>>> With newer mainline kernel builds (eg 2.6.33-rc) containing the new
>>>> HDA beep framework, a new config option was introduced that was set
>>>> on, re-introducing the (somewhat overzealous) system beep. With pulse
>>>> audio not reconfiguring the PC-beep channel volume, this often
>>>> saturates built-in or external speakers/headphones at undesired times
>>>> (eg when shutting down).
>>>>
>>>> Is it reasonable to ask to change the Ubuntu mainline kernel configuration:
>>>>
>>>> CONFIG_SND_HDA_INPUT_BEEP_MODE=1
>>>>
>>>> to =0, or, disable:
>>>>
>>>> CONFIG_SND_HDA_INPUT_BEEP=y ?
>>> It is cirtainly possible to change configurations for these kernels
>>> slightly from those used in the main Ubuntu kernels.  What do these two
>>> do?  Which is preferred?
>> The HDA-beep isn't active when booting into the 2.6.32-12-generic
>> Ubuntu kernel [1], but is with newer mainline kernels (eg [2]) -
>> looking at the kernel .config difference, we see:
>>
>> - "CONFIG_SND_HDA_INPUT_BEEP_MODE=1" was introduced in 2.6.33-rc
>> - "CONFIG_SND_HDA_PATCH_LOADER" is unset in 2.6.33-rc
>>
>> Rebuilding the mainline kernel with BEEP_MODE=0 mutes the beep per
>> default, perhaps the best option, as it is possible to re-enable the
>> beep via module options/sysfs if needed.
>>
>> Also, PATCH_LOADER is needed for loading model-specific codec
>> configuration, where the BIOS doesn't present the correct data, so
>> should be enabled as per the Ubuntu kernel.
>>
>> It would be great if you can enable these options for the next
>> mainline kernel build.
>>
>> Many thanks!
>>  Daniel
>>
>> [1] http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-image-2.6.32-12-generic_2.6.32-12.17_amd64.deb
>> [2] http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33-rc7/linux-image-2.6.33-020633rc7-generic_2.6.33-020633rc7_amd64.deb
> 
> I also noticed while checking through the mainline and 9.10 kernel
> configs (relevant to mainline and 10.04 kernels) and found:
> 

Just my thoughts on those:

>  - CONFIG_BLK_DEV_BSG should be enabled: "This option is required by
> recent UDEV versions to properly access device serial numbers, etc. If
> unsure, say Y."

Sounds sort of reasonable to me. Though we surely want to check with Scott to be
sure we are not accidentally actually cause pain.

>  - CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT should be set to 1: "Convert
> MTRR layout from continuous to discrete, so X drivers can add
> writeback entries. If unsure, say Y."
>  -> an over-specified uncacheable MTRR entry will override per-page
> PAT flags, killing performance

The "if unsure: yes" seems to relate to the generic enablement of the sanitizer.
I feel we should not enable it by default. It is not fatal if not optimized, we
probably do not want to find out it can cause problems and its very easy to
enable for someone who has the problem.

>  - CONFIG_PM_RUNTIME should be enabled, since it prevents USB (etc)
> suspend working on platforms that implement it correctly

Sounds safe. What would you think Amit?

>  - CONFIG_PCIEASPM
>   -> the kernel backlists platforms where these are not reliable, but
> everyone else shouldn't lose out as a result

Rather not. Marked experimental and defaults to no.

> 
> What do you think?
> 
> Thanks,
>   Daniel





More information about the kernel-team mailing list