Bug 102568 - cpufreq has odd interactions with i810_audio
Summary: cpufreq has odd interactions with i810_audio
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux Beta
Classification: Retired
Component: kernel
Version: beta1
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
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:
Clone Of:
Environment:
Last Closed: 2004-11-20 01:58:25 UTC
Embargoed:

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.