De beschikbare en huidige clock source in Linux kan met 2.6 kernels gevonden worden in de map /sys/devices/system/clocksource/clocksource0. Het bestand “available_clocksource” bevat de beschikbare en het bestand “current_clocksource” bevat de huidige.
Linux’s timekeeping architecture depends also on the availability of the Time Stamp Counter (TSC), of the ACPI Power Management Timer, and of the High Precision Event Timer (HPET). The kernel uses two basic timekeeping functions: one to keep the current time up-to-date and another to count the number of nanoseconds that have elapsed within the current second. There are different ways to get the last value. Some methods are more precise and are available if the CPU has a Time Stamp Counter or a HPET; a less-precise method is used in the opposite case (see the later section “The time( ) and gettimeofday( ) System Calls”).
6.2.1. Data Structures of the Timekeeping Architecture
The timekeeping architecture of Linux 2.6 makes use of a large number of data structures. As usual, we will describe the most important variables by referring to the 80 x 86 architecture.
6.2.1.1. The timer object
In order to handle the possible timer sources in a uniform way, the kernel makes use of a “timer object,” which is a descriptor of type timer_opts consisting of the timer name and of four standard methods shown in Table 6-1.
Table 6-1. The fields of the timer_opts data structure
Field name Description name
A string identifying the timer source
mark_offset
Records the exact time of the last tick; it is invoked by the timer interrupt handler
get_offset
Returns the time elapsed since the last tick
monotonic_clock
Returns the number of nanoseconds since the kernel initialization
delay
Waits for a given number of “loops” (see the later section “Delay Functions”)
The most important methods of the timer object are mark_offset and get_offset. The mark_offset method is invoked by the timer interrupt handler, and records in a suitable data structure the exact time at which the tick occurred. Using the saved value, the get_offset method computes the time in microseconds elapsed since the last timer interrupt (tick). Thanks to these two methods, Linux timekeeping architecture achieves a sub-tick resolutionthat is, the kernel is able to determine the current time with a precision much higher than the tick duration. This operation is called time interpolation .
The cur_timer variable stores the address of the timer object corresponding to the “best” timer source available in the system. Initially, cur_timer points to timer_none, which is the object corresponding to a dummy timer source used when the kernel is being initialized. During kernel initialization, the select_timer( ) function sets cur_timer to the address of the appropriate timer object. Table 6-2 shows the most common timer objects used in the 80x86 architecture, in order of preference. As you see, select_timer( ) selects the HPET, if available; otherwise, it selects the ACPI Power Management Timer , if available, or the TSC. As the last resort, select_timer( ) selects the always-present PIT. The “Time interpolation” column lists the timer sources used by the mark_offset and get_offset methods of the timer object; the “Delay” column lists the timer sources used by the delay method.
Table 6-2. Typical timer objects of the 80x86 architecture, in order of preference
Timer object name
Description
Time interpolation
Delay
timer_hpet
High Precision Event Timer (HPET)
HPET
HPET
timer_pmtmr
ACPI Power Management Timer (ACPI PMT)
ACPI PMT
TSC
timer_tsc
Time Stamp Counter (TSC)
TSC
TSC
timer_pit
Programmable Interval Timer (PIT)
PIT
Tight loop
timer_none
Generic dummy timer source(used during kernel initialization)
(none)
Tight loop
Notice that local APIC timers do not have a corresponding timer object. The reason is that local APIC timers are used only to generate periodic interrupts and are never used to achieve sub-tick resolution. 6.2.1.2. The jiffies variable
The jiffies variable is a counter that stores the number of elapsed ticks since the system was started. It is increased by one when a timer interrupt occursthat is, on every tick. In the 80 x 86 architecture, jiffies is a 32-bit variable, therefore it wraps around in approximately 50 daysa relatively short time interval for a Linux server. However, the kernel handles cleanly the overflow of jiffies thanks to the time_after, time_after_eq, time_before, and time_before_eq macros: they yield the correct value even if a wraparound occurred.
You might suppose that jiffies is initialized to zero at system startup. Actually, this is not the case: jiffies is initialized to 0xfffb6c20, which corresponds to the 32-bit signed value 300,000; therefore, the counter will overflow five minutes after the system boot. This is done on purpose, so that buggy kernel code that does not check for the overflow of jiffies shows up very soon in the developing phase and does not pass unnoticed in stable kernels.
In a few cases, however, the kernel needs the real number of system ticks elapsed since the system boot, regardless of the overflows of jiffies. Therefore, in the 80 x 86 architecture the jiffies variable is equated by the linker to the 32 less significant bits of a 64-bit counter called jiffies_64. With a tick of 1 millisecond, the jiffies_64 variable wraps around in several hundreds of millions of years, thus we can safely assume that it never overflows.
You might wonder why jiffies has not been directly declared as a 64-bit unsigned long long integer on the 80 x 86 architecture. The answer is that accesses to 64-bit variables in 32-bit architectures cannot be done atomically. Therefore, every read operation on the whole 64 bits requires some synchronization technique to ensure that the counter is not updated while the two 32-bit half-counters are read; as a consequence, every 64-bit read operation is significantly slower than a 32-bit read operation.
The get_jiffies_64( ) function reads the value of jiffies_64 and returns its value:
unsigned long long get_jiffies_64(void)
{
unsigned long seq;
unsigned long long ret;
do {
seq = read_seqbegin(&xtime_lock);
ret = jiffies_64;
} while (read_seqretry(&xime_lock, seq));
return ret;
}
The 64-bit read operation is protected by the xtime_lock seqlock (see the section “Seqlocks” in Chapter 5): the function keeps reading the jiffies_64 variable until it knows for sure that it has not been concurrently updated by another kernel control path.
Conversely, the critical region increasing the jiffies_64 variable must be protected by means of write_seqlock(&xtime_lock ) and write_sequnlock( &xtime_lock). Notice that the ++jiffies_64 instruction also increases the 32-bit jiffies variable, because the latter corresponds to the lower half of jiffies_64. 6.2.1.3. The xtime variable
The xtime variable stores the current time and date; it is a structure of type timespec having two fields:
tv_sec
Stores the number of seconds that have elapsed since midnight of January 1, 1970 (UTC)
tv_nsec
Stores the number of nanoseconds that have elapsed within the last second (its value ranges between 0 and 999,999,999)
The xtime variable is usually updated once in a tickthat is, roughly 1000 times per second. As we’ll see in the later section “System Calls Related to Timing Measurements,” user programs get the current time and date from the xtime variable. The kernel also often refers to it, for instance, when updating inode timestamps (see the section “File Descriptor and Inode” in Chapter 1).
The xtime_lock seqlock avoids the race conditions that could occur due to concurrent accesses to the xtime variable. Remember that xtime_lock also protects the jiffies_64 variable; in general, this seqlock is used to define several critical regions of the timekeeping architecture.
Installing audio: apt-get install alsa-base alsa-oss alsa-source alsa-utils alsamixergui alsaplayer alsaplayer-common alsaplayer-gtk alsaplayer-oss snd-gtk-alsa vlc-plugin-alsa alsaplayer-jack jack jackd sysv-rc-conf jack-tools mozilla-plugin-vlc
un
lspci | grep Audio |
This should tell you what audio card you have.
If your sound card is not already built into the kernel -
Get module-assistant and run it and select the audio card from the list (you can fix an error here by running dpkg-reconfigure alsa-source)
You will need to run
sysv-rc-conf
and turn on runlevels 2-3-4-5 for alsa and alsa-utils
You can try sicking the following in .bash_profile
jack -d alsa &
This fails to work all the time right now - let me know or update this page with details if you get Jack working well under KDE (3.2 right now)
You will want to run [edit] Testing
run
alsaconf
Then run
alsactl store
then run
speaker-test
In KDE (3.2 for now) set sound system to use ALSA (Advanced Linux Sound architecture) [edit] Lenny setup
I have the following script in the .kde/Autostart folder
killall jackd killall timidity jackd -d alsa & timidity -iA -Oj &
timidity still hangs once in a while so you might need to re run it.