Please don't send patches via bugzilla - it causes lots of problems with
our usual patch management and review processes.

Please send this patch via email as per Documentation/SubmittingPatches. 
Suitable recipients may be found via scripts/get_maintainer.pl.  Please
also cc myself on the email.

Thanks.

This patch was originally sent to the following without any responses.  After what I thought as an appropriate amount of time I opened this bug report to document the regression before 2.6.35 is shipped.
To: linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org
Cc: Kailang Yang <kailang@realtek.com>, Takashi Iwai <tiwai@suse.de>
Date: Tue, 1 Jun 2010 23:31:30 -0500
Subject: [PATCH] regression 2.6.35-rc1+ hda realtek missing beep 10ec0883

With Kailang Yang being the author of the patch which disabled the beep for my laptop and Takashi Iwai as a sign off on that patch.

I also don't want to just push this version of the fix into the kernel.  The patch with disabled the beep for me sounded like it was trying to detect if the hardware supports the beep hardware and only enable it if it does.  That fails on my hardware and my patch just forces it back on for anyone with the chip id that I have.  So I don't expect this to be the best solution, I just wanted to put out the patch for someone who knows the hardware to look at and hopefully come up with the right solution.

What about the patch below?

Created attachment 26897 [details]
Patch to fix detection of h/w bits for realtek chips

No beep control and no beep.

HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16
hda_codec: ALC883: SKU not ready 0x99830132
SKU: PCISUB=0x140d
SKU: port_connectivity=0x0
SKU: enable_pcbeep=0x0
SKU: check_sum=0x00000000
SKU: customization=0x00000000
SKU: external_amp=0x1
SKU: platform_type=0x1
SKU: swap=0x0
SKU: override=0x1
hda_codec: ALC883: BIOS auto-probing.
autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0)
   speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
   hp_outs=0 (0x0/0x0/0x0/0x0/0x0)
   mono: mono_out=0x0
   dig-out=0x1e/0x0
   inputs: mic=0x18, fmic=0x0, line=0x1a, fline=0x0, cd=0x1c, aux=0x0
realtek: Enabling init ASM_ID=0x140d CODEC_ID=10ec0883
input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:14.2/input/input18

So your BIOS is really broken ;)

OTOH, enabling the beep in such a case wouldn't hurt much.  Please try the patch below.  It's less intrusive than enabling always.

Created attachment 26911 [details]
Enable PC-beep for broken BIOS

This realtek-pcbeep-enable.diff patch works, thanks.  It's an Acer Aspire 5100 laptop.

OK, I'll add it to the next pull request.  Thanks for testing.

Patch : https://bugzilla.kernel.org/attachment.cgi?id=26911
Handled-By : Takashi Iwai <tiwai@suse.de>

Fixed by commit f189efcd1cc06b75fe18642c9751d26aa5ed2b54 .

I have a very similar problem on Asus EeePC 1001hag. After upgrading to 2.6.35 beep control disappeared from mixer, and I can't hear any beeps anymore.
Everything worked fine on 2.6.34.
Checked with 2.6.35-gentoo kernel. I'll also check with vanilla 2.6.35.3 and 2.6.36_rc1 kernels.

# lspci -nn | grep Audio
00:1b.0 Audio device [0403]: Intel Corporation N10/ICH 7 Family High Definition Audio Controller [8086:27d8] (rev 02)

What additional info may be needed?

Tested on 2.6.35-gentoo-r4 (2.6.35.3 with several patches) and on vanilla 2.6.36-rc1. Both have same problem.