Bug 102568 - cpufreq has odd interactions with i810_audio
Summary: cpufreq has odd interactions with i810_audio
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux Beta
Classification: Retired
Component: kernel (Show other bugs)
(Show other bugs)
Version: beta1
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-08-18 05:09 UTC by Bill Nottingham
Modified: 2015-01-04 22:02 UTC (History)
3 users (show)

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


Attachments (Terms of Use)

Description Bill Nottingham 2003-08-18 05:09:38 UTC
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 05:14:45 UTC
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 12:53:34 UTC
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.