* Something wrong with recent 2.4.21-rc* kernels?
@ 2003-05-31 18:15 ghugh Song
2003-05-31 18:56 ` More on Blade 100/AC97 codec detection failure J.C. Wren
0 siblings, 1 reply; 2+ messages in thread
From: ghugh Song @ 2003-05-31 18:15 UTC (permalink / raw)
To: linux-kernel
I am comparing
2.4.21-pre3-ac4
2.4.21-rc5-ac1
2.4.21-rc6-ac1
In the last two kernels, something is definitely not right.
LaTeXing a big file takes about twice the time compared to
the same job under 2.4.21-pre3-ac4.
However, I am not totally satisfied with the 2.4.21-pre3-ac4, either.
In the beginning just after a reboot, the condition is really nice.
However, after a while, "time"ing a job reveals that something bad is
happening in the first column of "real" time, which means the wall-clock
timing. One might say that it is still better with 2.4.21-pre3-ac4
than the situation with 2.4.21-rc5-ac1 or with 2.4.21-rc6-ac1, because
it still does not contaminate "user" time in the middle column.
With 2.4.21-pre3-ac4, as everyone comlained, there seems to be a
problem with the cursor movement while kernel-compilation in the back.
The mouse movement seemed to have improved in 2.4.21-rc6-ac1. But
overall performance hit is just not acceptable.
BTW, the .config file for 2.4.21-rc6-ac1 has been taken from
2.4.21-pre3-ac4 during compilation.
The motherboard is an Asus with the Nvidia2 chipset.
Main system is running off SCSI hard disks under Adaptec U2-SCSI PCI
controller. No ATAPI hard disk is running at the moment.
I never used the installed ATAPI CDrom during the test.
In the emaillist, I have been reading about random halts in recent
kernels, i.e., 2.4.21-rc*. Well. I did not experience such a
drastic things. maybe because I did not wait long enough.
Regards,
G. Hugh Song
^ permalink raw reply [flat|nested] 2+ messages in thread
* More on Blade 100/AC97 codec detection failure
2003-05-31 18:15 Something wrong with recent 2.4.21-rc* kernels? ghugh Song
@ 2003-05-31 18:56 ` J.C. Wren
0 siblings, 0 replies; 2+ messages in thread
From: J.C. Wren @ 2003-05-31 18:56 UTC (permalink / raw)
To: linux-kernel
I've done a little bit more playing around, trying to get sound working on the
Blade 100. First, ac97_codec.c is reading an ID of 0x00000000 for the codec.
It's supposed to be 0x41445348 (AD1881A). I didn't have much hope that
forcing the codec ID to that value would solve anything, and sure enough, it
didn't. There are two ambiguous comments in the codec detection area:
/* probing AC97 codec, AC97 2.0 says that bit 15 of register 0x00
(reset) should
* be read zero.
*
* FIXME: is the following comment outdated? -jgarzik
* Probing of AC97 in this way is not reliable, it is not even SAFE !!
*/
So which is it?
I have talked to another person with a Blade 100, using 2.4.21-rc6 (I'm on
-rc4), and they have the EXACT same problem. So I'm not hallucinating,
unless we all shared the Koolaid.
I don't know the significance of this but using mpg123 to play a MP3 gives no
audio. Using mpg321 produces a loud hissing *way* over-amped audio that one
can vaguely here modulation on. It sounds like the rate is off somewhat, but
the only way I can even remotely tell that is to use a gain of 1 (-g 1) to
mpg321. To even get mpg123 to work, I had to modprobe in the 'dmy' device
and give it a fake /dev/audioctl to play with itself with.
The other person with the Blade 100 reported that 2.4.20-r8 produced the same
hissy results. However, there are reports of people using Debian with 2.4.18
having it work (http://www.de-brauwer.be/docs/debian_on_sun.html).
--jcwren
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2003-05-31 18:42 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-31 18:15 Something wrong with recent 2.4.21-rc* kernels? ghugh Song
2003-05-31 18:56 ` More on Blade 100/AC97 codec detection failure J.C. Wren
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).