With the 2.4.0 kernel the loops_per_sec field was replaced (for i386)
with current_cpu_data.loops_per_jiffy.
So... since I am using the ALSA drivers that Mandrake supplied, for the
2.4.x series of kernels I replaced the equated #define with
#define LOOPS_PER_SEC current_cpu_data.loops_per_jiffy * 100
This seems to build modules that work for 2.4.0. However, if you play
many songs then do some heavy disk I/0 after awhile the songs start
sounding like a hellicoptor is hovering right next to the speakers.
This wasn't too bad as it usually took about 30 to 40 mins to go
south.
Now compiling the same ALSA modules with 2.4.2 this problem happens
much quicker and you don't need any other activity. In fact it is hard
to play more than half a song. (MP3)
It doesn't matter if what set of music players or tools I use the
problem is quite visible.
When I boot back to the original 2.2.x kernel everything is perfect.
So I guess I have a few questions here.
1) Is a jiffy 100th of a second or is it smaller (so my loop count
is starving things.) (10ms) ?
2) Why is it so much worse in 2.4.2 than 2.4.0?
3) Any other "gotch's" that are important to watch for when moving
2.2.x drivers to 2.4.x?
Thanks....
Watermodem
On Mon, Mar 19, 2001 at 12:20:47AM -0600, watermodem wrote:
> With the 2.4.0 kernel the loops_per_sec field was replaced (for i386)
> with current_cpu_data.loops_per_jiffy.
...
> #define LOOPS_PER_SEC current_cpu_data.loops_per_jiffy * 100
The intention was to accomodate systems with faster than 2 GHz clock
at which the LOOPS_PER_SEC counter spins around a bit too fast..
('signed long' at i386 handles 0..2G just fine, then it thinks the sign
got inverted.. 'unsigned long' works fine until 4 GHz processors.)
Why does the ALSA need LOOPS_PER_SEC ?
Is it doing timing by busy-looping ?
> Now compiling the same ALSA modules with 2.4.2 this problem happens
> much quicker and you don't need any other activity. In fact it is hard
> to play more than half a song. (MP3)
> It doesn't matter if what set of music players or tools I use the
> problem is quite visible.
>
> When I boot back to the original 2.2.x kernel everything is perfect.
>
> So I guess I have a few questions here.
> 1) Is a jiffy 100th of a second or is it smaller (so my loop count
> is starving things.) (10ms) ?
"HZ" is the answer. E.g. Alpha has HZ=1024, while i386 has HZ=100
Nearly all architectures have different values based on what some
other UNIX uses at given system.
> 2) Why is it so much worse in 2.4.2 than 2.4.0?
> 3) Any other "gotch's" that are important to watch for when moving
> 2.2.x drivers to 2.4.x?
The FAQ may have some pointers to "porting drivers to 2.4" documents.
> Thanks....
> Watermodem
> -
> Please read the FAQ at http://www.tux.org/lkml/
/Matti Aarnio
Matti Aarnio wrote:
>
> On Mon, Mar 19, 2001 at 12:20:47AM -0600, watermodem wrote:
> > With the 2.4.0 kernel the loops_per_sec field was replaced (for i386)
> > with current_cpu_data.loops_per_jiffy.
> ...
> > #define LOOPS_PER_SEC current_cpu_data.loops_per_jiffy * 100
>
> The intention was to accomodate systems with faster than 2 GHz clock
> at which the LOOPS_PER_SEC counter spins around a bit too fast..
> ('signed long' at i386 handles 0..2G just fine, then it thinks the sign
> got inverted.. 'unsigned long' works fine until 4 GHz processors.)
>
My sound card uses ALSA and ALSA wasn't available yet for
the new kernel. So.. Noting that LOOPS_PER_SEC was what
failed in the kernel I modified it and compiled. I am
not associated in anyway with the ALSA folks just wanted
too listen to music while working away. I have no idea
why it needs it or if it is busy-looping... (I hope not).
> Why does the ALSA need LOOPS_PER_SEC ?
> Is it doing timing by busy-looping ?
>
> > Now compiling the same ALSA modules with 2.4.2 this problem happens
> > much quicker and you don't need any other activity. In fact it is hard
> > to play more than half a song. (MP3)
> > It doesn't matter if what set of music players or tools I use the
> > problem is quite visible.
> >
> > When I boot back to the original 2.2.x kernel everything is perfect.
> >
> > So I guess I have a few questions here.
> > 1) Is a jiffy 100th of a second or is it smaller (so my loop count
> > is starving things.) (10ms) ?
>
> "HZ" is the answer. E.g. Alpha has HZ=1024, while i386 has HZ=100
> Nearly all architectures have different values based on what some
> other UNIX uses at given system.
>
> > 2) Why is it so much worse in 2.4.2 than 2.4.0?
> > 3) Any other "gotch's" that are important to watch for when moving
> > 2.2.x drivers to 2.4.x?
>
> The FAQ may have some pointers to "porting drivers to 2.4" documents.
>
> > Thanks....
> > Watermodem
> > -
> > Please read the FAQ at http://www.tux.org/lkml/
>
> /Matti Aarnio
watermodem wrote:
>
> Matti Aarnio wrote:
> >
> > On Mon, Mar 19, 2001 at 12:20:47AM -0600, watermodem wrote:
> > > With the 2.4.0 kernel the loops_per_sec field was replaced (for i386)
> > > with current_cpu_data.loops_per_jiffy.
> > ...
> > > #define LOOPS_PER_SEC current_cpu_data.loops_per_jiffy * 100
> >
> > The intention was to accomodate systems with faster than 2 GHz clock
> > at which the LOOPS_PER_SEC counter spins around a bit too fast..
> > ('signed long' at i386 handles 0..2G just fine, then it thinks the sign
> > got inverted.. 'unsigned long' works fine until 4 GHz processors.)
> >
>
> My sound card uses ALSA and ALSA wasn't available yet for
> the new kernel. So.. Noting that LOOPS_PER_SEC was what
> failed in the kernel I modified it and compiled. I am
> not associated in anyway with the ALSA folks just wanted
> too listen to music while working away. I have no idea
> why it needs it or if it is busy-looping... (I hope not).
I noticed that if I kill the "artsd" daemon and then
let it naturally restart when starting another music player
the problem goes away for awhile. When artsd starts using
more than 1.7% of the CPU then the problem occurs. So I think
I was looking at the wrong code. Perhaps the problem is with
the daemon.
>
> > Why does the ALSA need LOOPS_PER_SEC ?
> > Is it doing timing by busy-looping ?
> >
> > > Now compiling the same ALSA modules with 2.4.2 this problem happens
> > > much quicker and you don't need any other activity. In fact it is hard
> > > to play more than half a song. (MP3)
> > > It doesn't matter if what set of music players or tools I use the
> > > problem is quite visible.
> > >
> > > When I boot back to the original 2.2.x kernel everything is perfect.
> > >
> > > So I guess I have a few questions here.
> > > 1) Is a jiffy 100th of a second or is it smaller (so my loop count
> > > is starving things.) (10ms) ?
> >
> > "HZ" is the answer. E.g. Alpha has HZ=1024, while i386 has HZ=100
> > Nearly all architectures have different values based on what some
> > other UNIX uses at given system.
> >
> > > 2) Why is it so much worse in 2.4.2 than 2.4.0?
> > > 3) Any other "gotch's" that are important to watch for when moving
> > > 2.2.x drivers to 2.4.x?
> >
> > The FAQ may have some pointers to "porting drivers to 2.4" documents.
> >
> > > Thanks....
> > > Watermodem
> > > -
> > > Please read the FAQ at http://www.tux.org/lkml/
> >
> > /Matti Aarnio
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/