Hello,
I'm just starting build my first RT kernels and I'm not sure about this item:
Kernel log buffer size (16 => 64KB, 17 => 128KB) (LOG_BUF_SHIFT)
Select kernel log buffer size as a power of 2.
Defaults and Examples:
17 => 128 KB for S/390
16 => 64 KB for x86 NUMAQ or IA-64
15 => 32 KB for SMP
14 => 16 KB for uniprocessor
13 => 8 KB
12 => 4 KB
I will make kernel for two machines 1. Laptop Intel Core processor 2. Workstation P4
What are right values for these processors?
Thanks for help.
Mira
< Sorry for toppost but it's quick. If you don't care about imposed hipness,
< "make xconfig" instead of "make menuconfig" does give those new to custom
< kernels a better overall picture since all help notes are shown by default
< and tree view allows checking ahrad with somewhat less hassle.
< Jimmy
<
Thank you Jimmy,
it is really better overview in "xconfig".. :-)
Mira
I am running Ubuntu studio 64 on a Thinkpad laptop (X61s), and
i get an horrible battery life. Powertop suggest to configure the
kernel with CONFIG_NO_HZ=y.
How does this interact with the -rt kernel (2.6.24) used in Ubuntu Studio ? Any good reason to don't do it ?
And in case, where i find the ubuntu studio kernel source ?
Thanks and sorry for the FAQ like questions,
Maurizio De Cecco
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
re all,
i just thought i'd say hello :) i'm following this list of course,
good that it exists.
and let me add for the record:
dyne:bolic GNU/Linux 2.x is using a real-time kernel that many people
reported to work well with jack applications: it is the (missed,
alas!) Con Kolivas (-ck) patchset for desktop against linux (in d:b
2.5.2 that is 2.6.18-ck3)
IMHO Con is definitely a big loss in the development sphere: he
abandoned the scene as he was mistreated by other kernel developers
and Linus himself. real pity. his contributions are amazing
(esp. the prefetch approach for desktop) and his -rt series have been
powering dyne:II releases for long time.
regarding the status of future kernel releases, as dyne:bolic is a
100% free GNU/Linux distribution we'll follow the kernel-libre branch
(now mantained by Alexandre Oliva) in any future release, as it is a
truly free redistribution of the Linux kernel.
Alexandre's releases are frequent and well compatible with -rt
patchsets, as Jeff Moe is packing a linux-libre-rt kernel we already
use in our new FREEEEE distribution for EEEPC computers
http://freeeee.org
results are quite satisfying, still some corners to be smoothed, but
well jack is the default audio daemon for our distro and it runs well
without xruns. i've been performing myself using Jack and FFTW3 on my
EEEPC 701 with FreeJ and Fluxus scripts with very good results.
ciao
- --
Jaromil, dyne.org developer, http://jaromil.dyne.org
GPG: 779F E8B5 47C7 3A89 4112 64D0 7B64 3184 [ B534 0B5E ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkjH1GYACgkQe2QxhLU0C16RSACdHUS1Rb7qs5+xknAGQZXpmCFp
QmYAoPXe6lQfwupRfB5spxb2vdA1JWVT
=UsD7
-----END PGP SIGNATURE-----
Jussi Laako wrote:
> Rui Nuno Capela wrote:
>> just tested 2.6.23.3-rt3 here with NO_HZ not set in my (old) pentium4
>> desktop.
>>
>> it just confirmed that NO_HZ is not the culprit here. midi events are
>> still being delivered *completely* out of time and the funny thing is
>> it just gets somewhat better whenever you hit the pc-keyboard keys.
>> however, it all gets back to badness once you stop pressing any key
>> (eg. shift-key)
>>
>> another funny thing goes that on a core2 duo T7200 laptop (x86_64) the
>> same kernel config it runs all fine (NO_HZ=y)
>
> I'm kind of wondering what these have in
> /sys/devices/system/clocksource/clocksource0/current_clocksource
>
a) on the desktop (p4(a)2.80C), where midi timing delivery is completely
broken:
# uname -a
Linux gamma 2.6.26.3-rt3 #1 SMP PREEMPT RT Sat Aug 23 19:34:05 WEST 2008
i686 i686 i386 GNU/Linux
# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
b) on the laptop (core2@T7200), where midi seems to work fine:
# uname -a
Linux zeta 2.6.26.3-rt3 #1 SMP PREEMPT RT Sat Aug 23 19:14:58 WEST 2008
x86_64 x86_64 x86_64 GNU/Linux
# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hpet
least to say, audio (ie. jackd) works fine on both cases. i've also
tried to set the clocksource to hpet in a) and got no change in midi/tty
brokenness.
byee
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rui Nuno Capela wrote:
> Robin Gareus wrote:
>> Rui Nuno Capela wrote:
>>> Tim Goetze wrote:
>>>> [Tim Goetze]
>>>>
>>>>> [victor]
>>>>>> I was told to revert to 2.6.24.17 (not possible in my specific
>>>>>> case, but there you go), in this list. Or to join the tuner's list.
>>>>> http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.26.3-rt2.bz2
>>>>>
>>>>>
>>>>> worked for me. Applied cleanly and compiled well after turning off
>>>>> some RCU-related preemption options that caused compilation errors,
>>>>> but I was in no mood to find out the exact how and why. So far, it
>>>>> has collected a few hours of solid uptime too, but I haven't done
>>>>> any latency measuring.
>>>> Update: on my laptop, the patched 2.6.26.3 kernel boots into an
>>>> endless list of tracebacks on the console. On the main box, USB
>>>> MIDI input is only read as soon as a key is pressed on the USB
>>>> keyboard (the one with the letters, not the MIDI one ...). USB MIDI
>>>> out is broken, too. So it's back to the old version.
>>>>
>>> ah, it seems i'm not alone.
>>
>> hehe , nice try. We won't let you go that easily ;)
>>
>>> i'm currently recovering myself from schock after returning from
>>> vacation and while trying 2.6.26.x-rt for the rentrýe it all seemed
>>> to work fine except omg... midi timing is a wreck, specially wrt.alsa
>>> sequencer. event delivery is completely fubar. i mean, completely.
>>> true showstopper, whatever :(
>>
>>> cacophony seems to be the right word to express what it is.
>>
>>> however, didn't had the time to check whether NOHZ is at stake. i'm
>>> certainly going back to 2.6.25.x-rt where things are still sane and
>>> pleasant for a while.
>>
>>> btw, having NOHZ=y (aka tickless kernel) has been the norm here,
>>> since its inception
>>
>> CONFIG_NO_HZ=y - same norm here; with good results iff it works.
>>
>
> just tested 2.6.23.3-rt3 here with NO_HZ not set in my (old) pentium4
> desktop.
>
> it just confirmed that NO_HZ is not the culprit here. midi events are
> still being delivered *completely* out of time and the funny thing is it
> just gets somewhat better whenever you hit the pc-keyboard keys.
> however, it all gets back to badness once you stop pressing any key (eg.
> shift-key)
>
> another funny thing goes that on a core2 duo T7200 laptop (x86_64) the
> same kernel config it runs all fine (NO_HZ=y)
>
http://kerneltrap.org/Linux/Removing_the_Big_Kernel_Lock mentions TTY
drivers being a problem, actually "a long and difficult task"..
2c,
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkixWYkACgkQeVUk8U+VK0KoDgCgrFy2K9eamJrZUOHbG3m4ZuIz
ypgAn36etP4eo/+I0mbnAO4BbX8kajgA
=B1I0
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey guys,
After bleeding-edge linux-tuning and some br0ken 2.6.25's what are
candidates for a stable audio setup?
I'm currently running "2.6.24.7-rt17-pure #3 SMP PREEMPT RT" from
http://guests.goto10.org/~krgn/files/ which seems great for day-to-day
work and sound-production. runs for 3 days now, few suspend to RAM, no
reboot since, and worked out of the box.
It passes the mplayer via wifi-NFS and jconv test without a single xrun
at 256 frames/period, 3period @ 48Ksps with HDA-intel/PCI and UA-25+USB.
JACK (ardour, rosegarden, etc) works as usual.. including
gnome,iceweasel+flash and whatever - gonna test firewire soon.
I'm considering to make this my new default; maybe recompile it with
few minor changes (optimized for MCORE2, no generic i386) - It also
seems to be a bit more power-hungry that 2.6.24.3-rt3 - hard to tell
since former kernel does support `powertop`:
(No detailed statistics available; please enable the CONFIG_TIMER_STATS
kernel options - This option is located in the Kernel Debugging section
of menuconfig which is CONFIG_DEBUG_KERNEL=y in the config file)
Just for reference it's a X60s, running a
debian-lenny/sid/debian-multimedia/64studio distro mix..
I changed the USB-irq in the bios but I didn't do much besides using
rtirq.deb from 64studio and usual limits.conf with debian jackd
0.109.2. - I still have `dev.rtc.max-user-freq=8192` in sysctl.conf -
but I don't think it is being used with HPET.
What kernel/setup/system are you guys *tuning* for work, recording,
production and/or live performance.
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkiqXOgACgkQeVUk8U+VK0LsLgCfa61CKCKoS/xFhaBxWzZRfS9A
fsUAn1ybxfn/P7fjiEr4WLijOXpcVM8r
=CH0l
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rui Nuno Capela wrote:
> Tim Goetze wrote:
>> [Tim Goetze]
>>
>>> [victor]
>>>> I was told to revert to 2.6.24.17 (not possible in my specific
>>>> case, but there you go), in this list. Or to join the tuner's list.
>>> http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.26.3-rt2.bz2
>>>
>>> worked for me. Applied cleanly and compiled well after turning off
>>> some RCU-related preemption options that caused compilation errors,
>>> but I was in no mood to find out the exact how and why. So far, it
>>> has collected a few hours of solid uptime too, but I haven't done any
>>> latency measuring.
>> Update: on my laptop, the patched 2.6.26.3 kernel boots into an
>> endless list of tracebacks on the console. On the main box, USB MIDI
>> input is only read as soon as a key is pressed on the USB keyboard
>> (the one with the letters, not the MIDI one ...). USB MIDI out is
>> broken, too. So it's back to the old version.
>>
>
> ah, it seems i'm not alone.
hehe , nice try. We won't let you go that easily ;)
> i'm currently recovering myself from schock after returning from
> vacation and while trying 2.6.26.x-rt for the rentr�e it all seemed to
> work fine except omg... midi timing is a wreck, specially wrt.alsa
> sequencer. event delivery is completely fubar. i mean, completely. true
> showstopper, whatever :(
>
> cacophony seems to be the right word to express what it is.
>
> however, didn't had the time to check whether NOHZ is at stake. i'm
> certainly going back to 2.6.25.x-rt where things are still sane and
> pleasant for a while.
>
> btw, having NOHZ=y (aka tickless kernel) has been the norm here, since
> its inception
CONFIG_NO_HZ=y - same norm here; with good results iff it works.
I'll forward this email to LAT. MIDI with 2.6.26 MIDI has not been
mentioned there.
Since there's more of you LAD's compiling your own kernel that does not
work, what about posting .config, version/patchset and compiler info
before we all run into the same walls. - We're planning something like
this with http://wiki.linuxaudio.org/wiki/kernel/
Does anyone know of similar projects? How in your opinion can LAO best
supplement [rt] kernel bug tracking?
There's 2.6.26-rtX testing packages from various distributions eg:
http://linux.ilmainen.net/musix/temp/ or at
http://guests.goto10.org/~krgn/files/ more at LAT - none of which is
stable at the moment.
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkiu6E4ACgkQeVUk8U+VK0ItUwCguWgCtuPlnZoQQHVIDpVJRtvt
suYAoKkv8JvmehvEOtKq81ameZnxw7yn
=DXcK
-----END PGP SIGNATURE-----
Hi folks!
All the files are here:
http://www.musix.org.ar/ogg/mgg2008/lentitud/
On Musix 1.0 R4 (debian etch+backports)
Rosegarden 1.7.0 used to crash when recording MIDI from my sb live (it
begins to crash when recording the 4th DSSI track), so, I installed
1.6.1 (ftp://ftp.ourproject.org/pub/musix/deb-testing/) and went
almost Ok, sineshaper produced some strange "hang" to the rosegarden
sequencer (a note remains, and when I rewind or forward it makes all
the system slow... so I killed rosegardensequencer, and re-started
rosegarden)
apt-cache policy sineshaper
sineshaper:
Instalados: 0.4.2-1
But, it was a beautiful recording session: quantize, change note
velocities, move and fix some recordings was really easy, smooth and
comfortable, I love Rosegarden :D
I disabled the USB ports on my PC because they have the same IRQ as my
SB Live, then, I also used icewm because it's light.
rtirq status
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
1340 FF 85 - 125 0.1 S< IRQ-10 EMU10K1
374 FF 75 - 115 0.0 S< IRQ-1 i8042
373 FF 74 - 114 0.0 S< IRQ-12 i8042
5 FF 50 - 90 0.0 S< softirq-high/0
6 FF 50 - 90 1.3 S< softirq-timer/0
7 FF 50 - 90 0.0 S< softirq-net-tx/
8 FF 50 - 90 0.0 S< softirq-net-rx/
9 FF 50 - 90 0.0 S< softirq-block/0
10 FF 50 - 90 0.0 S< softirq-tasklet
11 FF 50 - 90 0.0 S< softirq-sched/0
12 FF 50 - 90 0.0 S< softirq-hrtimer
13 FF 50 - 90 0.0 S< softirq-rcu/0
61 FF 50 - 90 0.0 S< IRQ-9 acpi
290 FF 50 - 90 0.0 S< IRQ-14 ide0
293 FF 50 - 90 0.0 S< IRQ-15 ide1
619 FF 50 - 90 0.0 S< IRQ-8
1215 FF 50 - 90 0.0 S< IRQ-6
1289 FF 50 - 90 0.0 S< IRQ-7 parport0
1774 FF 50 - 90 0.0 S< IRQ-11 eth0
3325 FF 50 - 90 0.0 S< IRQ-4 serial
uname -a
Linux musix1.0r4dvd 2.6.23-rt1 #1 SMP PREEMPT RT Sun Oct 14 15:17:12
EEST 2007 i686 GNU/Linux
cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Duron(tm)
stepping : 1
cpu MHz : 1800.247
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up ts
bogomips : 3602.98
clflush size : 32
free
total used free shared buffers
cached
Mem: 350504 342596 7908 0 14960
146908
-/+ buffers/cache: 180728 169776
Swap: 2771132 20912 2750220
Spanish article: http://www.mastermagazine.info/articulo/13251.php
--
Marcos Guglielmetti - www.musix.org.ar Software Libre para Artistas
Y al final, como tan astutamente fue observado en la década de
1860: "Todo lo que era sólido se ha desvanecido en el aire, y el aire
y era algo que todos sabíamos que podíamos respirar libremente".
Y así nos encontramos confrontando un sistema de poder basado en las
ideas de las relaciones de propiedad que la tecnología de los
propietarios ya estaba haciendo obsoletas.
Eben Moglen, FSF.
http://www.mastermagazine.info/articulo/13220.php--------------------------
Banda: http://libraabedul.com/banda/
