This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 501314 - No beep when running xen kernel
No beep when running xen kernel
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel-xen (Show other bugs)
5.3
All Linux
low Severity medium
: rc
: ---
Assigned To: Igor Mammedov
Virtualization Bugs
: Reopened
Depends On:
Blocks: 514490
  Show dependency treegraph
 
Reported: 2009-05-18 10:02 EDT by Veaceslav Falico
Modified: 2014-09-30 19:44 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-07-21 06:25:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Allows Dom0 to use PC speaker. (3.54 KB, patch)
2011-05-09 04:48 EDT, Igor Mammedov
no flags Details | Diff

  None (edit)
Description Veaceslav Falico 2009-05-18 10:02:31 EDT
When booting the xen kernel (kernel-xen-2.6.18-128.1.1.el5), he no longer get any warning beeps.  It did work fine with the corresponding regular kernel (kernel-2.6.18-128.1.1.el5).

Note that customer is talking about the beep sound from the builtin speaker, not the sound/audio system.  The one that gets rung by the shell when something goes wrong, or which we hear when running xkbbell.  When running the xen kernel, xkbbell does not generate any sound, but otherwise appears to exit normally. The pcspkr module IS loaded.  The problem is elsewhere. Regular sound/audio system is working fine.

I searched a bit on this and found that a bug has been submitted for Fedora without any resolution. https://bugzilla.redhat.com/show_bug.cgi?id=230900

I searched upstream and found a patch which I though might help resolve this issue.

http://article.gmane.org/gmane.comp.emulators.xen.cvs/11376
http://lists.xensource.com/archives/html/xen-changelog/2007-03/msg00094.html

I compiled a test kernel with the above patch and tested, but unfortunately didn't see this issue resolved by the above patch.

How to reproduce:

It's very easy to reproduce.

- Boot a system to 5.3 stock kernel. Hook up a keyboard physically and run "backspace" on a terminal window or run xkbbell in gnome-terminal. You would hear the beep sound.

- Boot the same system to 5.3 xen kernel and test. There wouldn't be any beep sound.
Comment 3 Miroslav Rezanina 2009-06-15 02:46:22 EDT
This bug was fixed in kernel 2.6.18-137, where beep device was added. So this bug can be closed.
Comment 4 Chris Lalancette 2009-07-09 08:26:16 EDT
Since these seems to have been fixed by the ALSA update, going to close this as a DUP of that.  If this continues to be a problem after 5.4 is released, feel free to reopen.

Chris Lalancette

*** This bug has been marked as a duplicate of bug 483594 ***
Comment 5 Veaceslav Falico 2009-11-30 08:33:22 EST
Reopening, didn't help...
Comment 7 Laszlo Ersek 2010-11-12 10:04:10 EST
I reproduced the problem using the following two kernels:
- speaker works from dom0:        2.6.18-226.el5
- speaker doesn't work from dom0: 2.6.18-226.el5xen

It seems that the current RHEL5 xen hypervisor doesn't allow direct access to the PC speaker. construct_dom0() in "arch/x86/domain_build.c" does the following:

    /* Interval Timer (PIT). */
    rc |= ioports_deny_access(dom0, 0x40, 0x43);
    /* PIT Channel 2 / PC Speaker Control. */
    rc |= ioports_deny_access(dom0, 0x61, 0x61);

Furthermore, it only seems to *emulate* the PIT and the PC speaker; it never touches real speaker hardware. See:
- guest_io_write() in "xen/arch/x86/traps.c",
- pv_pit_handler() in "xen/arch/x86/hvm/i8254.c",
- handle_speaker_io() -||-,
- speaker_ioport_write() -||-,
- pit_set_gate() -||-.

I found two mailing list messages / patches that allow dom0 to access the PC speaker of the host:
- The first is "allow Dom0 to drive PC speaker" from Jan Beulich [0].
- The second has the same subject [1], and it seems to be a cleaned up version of the previous patch. This one was committed to xen-unstable [2], c/s 15882:9dd580b8b056.

There are some deeper differences between the patches. For example, the committed version doesn't seem to provide direct access to port 0x42.

I'm assigning this to myself. I'll try to backport and test [2] unless I'm told otherwise.

For the patch to have any effect, I believe it will be important *not* to start the hypervisor with "clocksource=pit". (Without the parameter it should usually work as if with "clocksource=hpet".)

Veaceslav, does the customer still care?

Thanks,
lacos

[0] http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00489.html
[1] http://lists.xensource.com/archives/html/xen-changelog/2007-09/msg00226.html
[2] http://xenbits.xensource.com/xen-unstable.hg?rev/15882
Comment 9 Igor Mammedov 2011-05-09 04:09:17 EDT
Backported of cs 15882:9dd580b8b056 from xen-unstable.hg
Comment 10 Igor Mammedov 2011-05-09 04:48:55 EDT
Created attachment 497739 [details]
Allows Dom0 to use PC speaker.

For this to work, Xen shouldn't be booted with a 'clocksource=pit'.
Comment 11 RHEL Product and Program Management 2011-05-19 18:59:12 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 13 Jarod Wilson 2011-05-25 12:29:12 EDT
Patch(es) available in kernel-2.6.18-264.el5
You can download this test kernel (or newer) from http://people.redhat.com/jwilson/el5
Detailed testing feedback is always welcomed.
Comment 15 Qixiang Wan 2011-06-02 01:32:56 EDT
tried with kernel-2.6.18-262.el5, no beep when run 'echo -e "\007"', verified with kernel-2.6.18-264.el5, there is beep sound when run 'echo -e "\007"'.
Comment 16 errata-xmlrpc 2011-07-21 06:25:32 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-1065.html

Note You need to log in before you can comment on or make changes to this bug.