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
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
> 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.
I am pleased to report that the problem has been solved by
Rick's RMap15j. So, I am now running
2.4.21-rc6-rmap15j.
Relevant information can be found at
http://www.ussg.iu.edu/hypermail/linux/kernel/0305.3/1850.html
If anyone is having the same problem, please take a note.
Regards,
G. Hugh Song