Bug 102568 - cpufreq has odd interactions with i810_audio
cpufreq has odd interactions with i810_audio
Status: CLOSED WONTFIX
Product: Red Hat Linux Beta
Classification: Retired
Component: kernel (Show other bugs)
beta1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-08-18 01:09 EDT by Bill Nottingham
Modified: 2015-01-04 17:02 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-19 20:58:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bill Nottingham 2003-08-18 01:09:38 EDT
Pentium M, 1600Mhz. Supports 600Mhz - 1600Mhz.

00:1f.5 Multimedia audio controller: Intel Corp. 82801DB AC'97 Audio Controller
(rev 01)
        Subsystem: IBM: Unknown device 0537

echo -n "0%37%100%powersave" > /proc/cpufreq
<play some sound, sounds fine>
echo -n "0%100%100%performance" > /proc/cpufreq
<sound is now about 2/2.5x slower>
Comment 1 Bill Nottingham 2003-08-18 01:14:45 EDT
It appears cpufreq's machinations really confuse the 'clocking' aspect of the
i810_audio driver; if I hardcode clocking on the commandline, it behaves more
sanely.
Comment 2 Dave Jones 2003-09-04 08:53:34 EDT
Repeatable with the kernel update (2.4.22-20.1.2024.2.36) in rawhide ?

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