We are pleased to announce the 2.6.24-rc7-rt2 tree, which can be
downloaded from the location:
http://rt.et.redhat.com/download/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
Changes since 2.6.24-rc7-rt1
- Several merge fixes reported by:
Mariusz Kozloski
- Removal of kvm-rt.patch (it's so old it is now bogus)
- PPC compile fix (reported by: Robert Schwebel)
- Remove of running softirq by hardirq (too dangerous)
- Changed BUG_ON in filemap from atomic to pagefault disabled
(Steven Rostedt)
Note: There are still some fixes that are not incorporated here yet.
to build a 2.6.24-rc7-rt2 tree, the following patches should be applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.23.tar.bz2
http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.24-rc7.bz2
http://rt.et.redhat.com/download/patch-2.6.24-rc7-rt2.bz2
And like always, my RT version of Matt Mackall's ketchup will get this
for you nicely:
http://people.redhat.com/srostedt/rt/tools/ketchup-0.9.8-rt3
The broken out patches are also available.
-- Steve
On Jan 14, 2008 10:41 AM, Steven Rostedt <[email protected]> wrote:
> We are pleased to announce the 2.6.24-rc7-rt2 tree, which can be
> downloaded from the location:
>
Up and running here:
mark@lightning ~ $ uname -a
Linux lightning 2.6.24-rc7-rt2 #1 PREEMPT RT Mon Jan 14 11:18:04 PST
2008 x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux
mark@lightning ~ $
I must learn how to use some of the test tools so I can do better
testing for you guys. I see no problems in dmesg but in
/var/log/messages I spotted this:
Jan 14 11:56:54 lightning sshd[5915]: Server listening on :: port 22.
Jan 14 11:56:54 lightning sshd[5915]: error: Bind to port 22 on
0.0.0.0 failed: Address already in use.
Scanning back through /var/log/messages I don't see that in earlier kernels.
- Mark
Hello,
> We are pleased to announce the 2.6.24-rc7-rt2 tree, which can be
> downloaded from the location:
>
> http://rt.et.redhat.com/download/
Compiles fine but I run into another problem. On startup kernel oopses
early and this 'oops' loops over and over again on the screen until you
shut down the box. So I can't (easily) capture the output. I tried different
boot_delay values but it seems that it doesn't work as intended. Seems that
it delays only the first printk from oops, then the rest loops over the screen
without delay - again it becomes unreadable. I used my usual config with a bunch
of debug options enabled so that maybe is not real rt system case. Also tried to
bisect it with quilt but that is hard. Lots of patches depends on another patches
so bisection brakes things. I'll look into this tommorow and reply if I get
anything substantial.
I attached my config in case anybody wants to try to reproduce that.
Regards,
Mariusz
On Mon, 14 Jan 2008, Mariusz Kozlowski wrote:
> Hello,
>
> > We are pleased to announce the 2.6.24-rc7-rt2 tree, which can be
> > downloaded from the location:
> >
> > http://rt.et.redhat.com/download/
>
> Compiles fine but I run into another problem. On startup kernel oopses
> early and this 'oops' loops over and over again on the screen until you
> shut down the box. So I can't (easily) capture the output. I tried different
> boot_delay values but it seems that it doesn't work as intended. Seems that
> it delays only the first printk from oops, then the rest loops over the screen
> without delay - again it becomes unreadable. I used my usual config with a bunch
> of debug options enabled so that maybe is not real rt system case. Also tried to
> bisect it with quilt but that is hard. Lots of patches depends on another patches
> so bisection brakes things. I'll look into this tommorow and reply if I get
> anything substantial.
>
> I attached my config in case anybody wants to try to reproduce that.
>
Turn off LOCKDEP and see if you still have the same problems. This might
be fixed with Daniel's patch.
-- Steve
Hi;
14 Oca 2008 Pts tarihinde, Steven Rostedt şunları yazmıştı:
> We are pleased to announce the 2.6.24-rc7-rt2 tree, which can be
> downloaded from the location:
[...]
> The broken out patches are also available.
2.6.24-rc7-rt2 (-rt2 patchset on top of Linus's current git commit
031f2dcd7075e218e74dd7f942ad015cf82dffab) starts to complain like following
(full dmesg can be found @ [1]) when try to login from console (the other
acpi related errors also existed in 2.6.24-rc5-rt1) and FYI, plain 2.6.24-rc7
(again commit 031f2dcd7075e218e74dd7f942ad015cf82dffab) has no issues.
[...]
sysfs: duplicate filename 'vcs1' can not be created
WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
Pid: 1298, comm: mingetty Not tainted 2.6.24-rc7-rt2-99 #1
[...]
And because of mcount-add-basic-support-for-gcc-profiler-instrum.patch, closed
source nvidia-new module cannot be used with this release (mcount is exported
GPL only), i know this is not supported but i used it with that [2] patch up
until now without a single problem.
Please don't misunderstand this, i really do not want to start a discussion
for this, i just want to ask the possibility of converting this into
EXPORT_SYMBOL cause i thought some of the possible -rt users may need this
closed source module explicitly because of its 3D performance.
If anything else needed for sysfs warnings please just say it...
[1] http://cekirdek.pardus.org.tr/~caglar/dmesg.rt
[2]
http://svn.pardus.org.tr/pardus/devel/kernel/drivers/nvidia-new/files/rt.patch
Cheers
--
S.Çağlar Onur <[email protected]>
http://cekirdek.pardus.org.tr/~caglar/
Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
Greetings,
I receive $subject upon every resume.
[ 115.223202] CPU1 is down
[ 3.725918] Intel machine check architecture supported.
[ 3.725925] Intel machine check reporting enabled on CPU#0.
[ 3.725927] CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
[ 3.725930] CPU0: Thermal monitoring enabled
[ 3.725936] Back to C!
[ 3.726468] Force enabled HPET at resume
[ 3.726532] Enabling non-boot CPUs ...
[ 3.726796] CPU0 attaching NULL sched-domain.
[ 3.726912] SMP alternatives: switching to SMP code
[ 3.727602] Booting processor 1/1 eip 3000
[ 3.727605] CPU 1 irqstacks, hard=b042d000 soft=b042b000
[ 3.737950] Initializing CPU#1
[ 3.798694] Calibrating delay using timer specific routine.. 5986.21 BogoMIPS (lpj=2993108)
[ 3.798703] CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000 00000000
[ 3.798714] CPU: Trace cache: 12K uops, L1 D cache: 8K
[ 3.798717] CPU: L2 cache: 512K
[ 3.798719] CPU: Physical Processor ID: 0
[ 3.798721] CPU: After all inits, caps: bfebfbff 00000000 00000000 0000b080 00004400 00000000 00000000 00000000
[ 3.798729] Intel machine check architecture supported.
[ 3.798734] Intel machine check reporting enabled on CPU#1.
[ 3.798738] CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
[ 3.798741] CPU1: Thermal monitoring enabled
[ 3.798893] CPU1: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 09
[ 3.798916] checking TSC synchronization [CPU#0 -> CPU#1]: passed.
[ 3.818995] CPU0 attaching sched-domain:
[ 3.819000] domain 0: span 3
[ 3.819002] groups: 1 2
[ 3.819006] domain 1: span 3
[ 3.819009] groups: 3
[ 3.819013] CPU1 attaching sched-domain:
[ 3.819016] domain 0: span 3
[ 3.819018] groups: 2 1
[ 3.819020] domain 1: span 3
[ 3.819021] groups: 3
[ 3.819615] CPU1 is up
[ 3.820379] ACPI: Unable to turn cooling device [ef83ab80] 'off'
[ 3.820424] PM: Writing back config space on device 0000:00:01.0 at offset 7 (was 22a0a0a0, writing 2a0a0a0)
[ 3.820444] ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 17
[ 3.820450] PCI: Setting latency timer of device 0000:00:1d.0 to 64
[ 3.820481] ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 18
[ 3.820487] PCI: Setting latency timer of device 0000:00:1d.1 to 64
[ 3.820517] ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 16
[ 3.820523] PCI: Setting latency timer of device 0000:00:1d.2 to 64
[ 3.820553] ACPI: PCI Interrupt 0000:00:1d.3[A] -> GSI 16 (level, low) -> IRQ 17
[ 3.820558] PCI: Setting latency timer of device 0000:00:1d.3 to 64
[ 3.820614] BUG: bad accounting of dynamic ticks
[ 3.820616] will try to fix, but it is best to reboot
[ 3.820618] WARNING: at include/linux/rcupreempt.h:110 rcu_enter_nohz()
[ 3.820621] Pid: 0, comm: swapper Not tainted 2.6.24-rt2-smp #64
[ 3.820624] [<b010522a>] show_trace_log_lvl+0x1a/0x30
[ 3.820631] [<b0105ccd>] show_trace+0x12/0x14
[ 3.820634] [<b010641f>] dump_stack+0x6c/0x72
[ 3.820637] [<b0148f10>] tick_nohz_stop_sched_tick+0x2fa/0x30c
[ 3.820641] [<b010256d>] cpu_idle+0x27/0xd2
[ 3.820644] [<b0116f01>] start_secondary+0x19f/0x1a5
[ 3.820648] [<00000000>] 0x0
[ 3.820661] =======================
Hi,
On Mon, Jan 14, 2008 at 01:41:20PM -0500, Steven Rostedt wrote:
> We are pleased to announce the 2.6.24-rc7-rt2 tree, which can be
> downloaded from the location:
>
> http://rt.et.redhat.com/download/
>
..........
> Changes since 2.6.24-rc7-rt1
>
..........
> - PPC compile fix (reported by: Robert Schwebel)
>
Compiling with tracing function turned seemed still to be broken to me:
kernel/built-in.o: In function `early_printk_name':
latency_trace.c:(.text+0x3cd18): undefined reference to `early_printk'
latency_trace.c:(.text+0x3cd40): undefined reference to `early_printk'
kernel/built-in.o: In function `early_print_entry':
latency_trace.c:(.text+0x3cd80): undefined reference to `early_printk'
latency_trace.c:(.text+0x3cdd8): undefined reference to `early_printk'
latency_trace.c:(.text+0x3cdfc): undefined reference to `early_printk'
We made a early_printk patch based on the 8250_early for powerpc 32bit here.
(still absolutely untested and incomplete, we will post it asap). I added
early_printk() and exported _mcount() and could compile succesfully. However the
kernel will not boot. I attached a bdi to it and found out that it stucks at
_mcount in arch/powerpc/kernel/entry_32.S at about line 1080, where the variable
mcount_enabled is loaded and checked. Obviously the variable is still not valid
at the time of check. To check this I took out the lines like above
--- arch/powerpc/kernel/entry_32.S.orig 2008-01-15 17:01:25.000000000 +0100
+++ arch/powerpc/kernel/entry_32.S 2008-01-15 17:17:18.000000000 +0100
@@ -1075,9 +1075,6 @@
stw r6, 24(r1)
mflr r3 /* will use as first arg to __trace() */
mfcr r4
- lis r5,mcount_enabled@ha
- lwz r5,mcount_enabled@l(r5)
- cmpwi r5,0
stw r3, 44(r1) /* lr */
stw r4, 8(r1) /* cr */
stw r7, 28(r1)
After recompiling the kernel started normally and it seems to work. I was even
able to make a trace with cyclictest. However there were several crashes (which
might be caused by other problems). I still have to take a closer look.
I am just wondering why the check for mcount_enabled is there at all and I think
that there due to be some better fixes than just throw it out ;-). On the other
side, I just can't find in which way mcount_enabled is used in the tracer at
all. Could you give me some hints on this one?
cheers
Luotao Fu
--
Dipl.-Ing. Luotao Fu | Phone: +49-5121-206917-3
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord http://www.pengutronix.de
> > > We are pleased to announce the 2.6.24-rc7-rt2 tree, which can be
> > > downloaded from the location:
> > >
> > > http://rt.et.redhat.com/download/
> >
> > Compiles fine but I run into another problem. On startup kernel oopses
> > early and this 'oops' loops over and over again on the screen until you
> > shut down the box. So I can't (easily) capture the output. I tried different
> > boot_delay values but it seems that it doesn't work as intended. Seems that
> > it delays only the first printk from oops, then the rest loops over the screen
> > without delay - again it becomes unreadable. I used my usual config with a bunch
> > of debug options enabled so that maybe is not real rt system case. Also tried to
> > bisect it with quilt but that is hard. Lots of patches depends on another patches
> > so bisection brakes things. I'll look into this tommorow and reply if I get
> > anything substantial.
> >
> > I attached my config in case anybody wants to try to reproduce that.
> >
>
> Turn off LOCKDEP and see if you still have the same problems. This might
> be fixed with Daniel's patch.
Ok. It works.
I found this in dmesg:
BUG: swapper:0 task might have lost a preemption check!
Pid: 0, comm: swapper Not tainted 2.6.24-rc7-rt2 #3
[<c010386b>] show_trace_log_lvl+0x1d/0x3b
[<c01042f3>] show_trace+0x12/0x14
[<c0104a2f>] dump_stack+0x6a/0x70
[<c0115419>] preempt_enable_no_resched+0x5c/0x5e
[<c0100e35>] cpu_idle+0x6d/0x82
[<c0323b6e>] rest_init+0x66/0x68
[<c043aba6>] start_kernel+0x20c/0x276
[<00000000>] 0x0
=======================
---------------------------
| preempt count: 00000000 ]
| 0-level deep critical section nesting:
----------------------------------------
Box runs fine though.
Regards,
Mariusz
On Tue, 15 Jan 2008, Luotao Fu wrote:
>
> Compiling with tracing function turned seemed still to be broken to me:
Could you email me your config (privately)
> kernel/built-in.o: In function `early_printk_name':
> latency_trace.c:(.text+0x3cd18): undefined reference to `early_printk'
> latency_trace.c:(.text+0x3cd40): undefined reference to `early_printk'
> kernel/built-in.o: In function `early_print_entry':
> latency_trace.c:(.text+0x3cd80): undefined reference to `early_printk'
> latency_trace.c:(.text+0x3cdd8): undefined reference to `early_printk'
> latency_trace.c:(.text+0x3cdfc): undefined reference to `early_printk'
>
> We made a early_printk patch based on the 8250_early for powerpc 32bit here.
> (still absolutely untested and incomplete, we will post it asap). I added
> early_printk() and exported _mcount() and could compile succesfully. However the
> kernel will not boot. I attached a bdi to it and found out that it stucks at
> _mcount in arch/powerpc/kernel/entry_32.S at about line 1080, where the variable
> mcount_enabled is loaded and checked. Obviously the variable is still not valid
> at the time of check. To check this I took out the lines like above
>
> --- arch/powerpc/kernel/entry_32.S.orig 2008-01-15 17:01:25.000000000 +0100
> +++ arch/powerpc/kernel/entry_32.S 2008-01-15 17:17:18.000000000 +0100
> @@ -1075,9 +1075,6 @@
> stw r6, 24(r1)
> mflr r3 /* will use as first arg to __trace() */
> mfcr r4
> - lis r5,mcount_enabled@ha
> - lwz r5,mcount_enabled@l(r5)
> - cmpwi r5,0
> stw r3, 44(r1) /* lr */
> stw r4, 8(r1) /* cr */
> stw r7, 28(r1)
>
> After recompiling the kernel started normally and it seems to work. I was even
> able to make a trace with cyclictest. However there were several crashes (which
> might be caused by other problems). I still have to take a closer look.
>
> I am just wondering why the check for mcount_enabled is there at all and I think
> that there due to be some better fixes than just throw it out ;-). On the other
> side, I just can't find in which way mcount_enabled is used in the tracer at
> all. Could you give me some hints on this one?
>
The way we turn on and off mcount function calls at run time is through
mcount_enable. I'll look into why this is broken for you. I'm able to run
with this. My box is a ppc64, and my ppc32 (powerbook) wont come close to
booting RT (never did). On boot up it locks up right away and the screen
looks like it starts to melt. No serial, so I don't have much to debug
that with.
Anyway, I'll take a deeper look into this.
Thanks,
-- Steve
Hi Steven,
On Tue, Jan 15, 2008 at 01:06:25PM -0500, Steven Rostedt wrote:
>
>
> On Tue, 15 Jan 2008, Luotao Fu wrote:
> >
> > Compiling with tracing function turned seemed still to be broken to me:
>
> Could you email me your config (privately)
will send it later in another private mail, actually nothing spectacular. The
early_printk() is simply missing for 32bit powerpc. The 64bit implementation
puts a dummy for early_printk in setup_64.c:
~ grep -A 4 EARLY_PRINTK ./arch/powerpc/kernel/setup_64.c | head -6
#ifdef CONFIG_EARLY_PRINTK
void notrace early_printk(const char *fmt, ...)
{
BUG();
}
#endif /* CONFIG_EARLY_PRINTK */
;-)
that could be why it works for you.
>
....
> > After recompiling the kernel started normally and it seems to work. I was even
> > able to make a trace with cyclictest. However there were several crashes (which
> > might be caused by other problems). I still have to take a closer look.
> >
> > I am just wondering why the check for mcount_enabled is there at all and I think
> > that there due to be some better fixes than just throw it out ;-). On the other
> > side, I just can't find in which way mcount_enabled is used in the tracer at
> > all. Could you give me some hints on this one?
> >
>
> The way we turn on and off mcount function calls at run time is through
> mcount_enable. I'll look into why this is broken for you. I'm able to run
> with this. My box is a ppc64, and my ppc32 (powerbook) wont come close to
> booting RT (never did). On boot up it locks up right away and the screen
> looks like it starts to melt. No serial, so I don't have much to debug
> that with.
>
ah, thx for the hint. I took a look in the entry_64.S file. The checking of
mcount_enabled is indeed literally the same as the 32bit architecture.
An important point for the failure on 32bit machines is that due to my bdi the
machine got stuck still before the mmu is running. Hence I get quite funny pc
address like
Current PC : 0x000135dc
it still lies over on 0x0 as the physical adress of the decompressed kernel in
memory. I think that mcount_enabled is linked somewhere in the virtual addess
space, so that the cmpwi stucks forever for _mcount is called so early, that we
still don't work with virtual addresses. I don't understand enough powerpc
assembler to work out how the LOAD_REG_ADDR() (used in entry_64.S to load
mcount_enabled) of 64 bit powerpcs work around this problem. Anyway, If my guess
is right, we might need something to get or simply ignore mcount_enabled
checking in the _mcount calls during early initialisation.
> Anyway, I'll take a deeper look into this.
>
Thanks
cheers
Luotao Fu
--
Dipl.-Ing. Luotao Fu | Phone: +49-5121-206917-3
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord http://www.pengutronix.de
On Tue, 15 Jan 2008 02:37:37 +0200, =?utf-8?q?S=2E=C3=87a=C4=9Flar?= Onur said:
> And because of mcount-add-basic-support-for-gcc-profiler-instrum.patch, closed
> source nvidia-new module cannot be used with this release (mcount is exported
> GPL only), i know this is not supported but i used it with that [2] patch up
> until now without a single problem.
Playing devil's advocate here - the claim is that EXPORT_SYMBOL_GPL is to
indicate that code is getting too chummy with Linux internals.
However, in *this* case, isn't it "code that is too chummy with *GCC* internals",
and thus it isn't our place to say what can and can't be done with code that
is derivative of the GCC compiler? ;)
On Tue, 15 Jan 2008, [utf-8] S.?^Ga?^_lar Onur wrote:
>
> 2.6.24-rc7-rt2 (-rt2 patchset on top of Linus's current git commit
> 031f2dcd7075e218e74dd7f942ad015cf82dffab) starts to complain like following
> (full dmesg can be found @ [1]) when try to login from console (the other
> acpi related errors also existed in 2.6.24-rc5-rt1) and FYI, plain 2.6.24-rc7
> (again commit 031f2dcd7075e218e74dd7f942ad015cf82dffab) has no issues.
Do you get the same issues if you add to -rc7 and not git.
>
> [...]
> sysfs: duplicate filename 'vcs1' can not be created
> WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> Pid: 1298, comm: mingetty Not tainted 2.6.24-rc7-rt2-99 #1
> [...]
>
> And because of mcount-add-basic-support-for-gcc-profiler-instrum.patch, closed
> source nvidia-new module cannot be used with this release (mcount is exported
> GPL only), i know this is not supported but i used it with that [2] patch up
> until now without a single problem.
Ah, sorry about that. I'll try to fix that later on. You should still be
able to use NVidia by turning off function trace.
>
> Please don't misunderstand this, i really do not want to start a discussion
> for this, i just want to ask the possibility of converting this into
> EXPORT_SYMBOL cause i thought some of the possible -rt users may need this
> closed source module explicitly because of its 3D performance.
>
> If anything else needed for sysfs warnings please just say it...
>
> [1] http://cekirdek.pardus.org.tr/~caglar/dmesg.rt
> [2]
> http://svn.pardus.org.tr/pardus/devel/kernel/drivers/nvidia-new/files/rt.patch
>
Thanks for the report. I'll see what I can do for the next release. But
for now this will have to wait till after -rt3.
-- Steve
On Tue, 15 Jan 2008 [email protected] wrote:
> On Tue, 15 Jan 2008 02:37:37 +0200, =?utf-8?q?S=2E=C3=87a=C4=9Flar?= Onur said:
> > And because of mcount-add-basic-support-for-gcc-profiler-instrum.patch, closed
> > source nvidia-new module cannot be used with this release (mcount is exported
> > GPL only), i know this is not supported but i used it with that [2] patch up
> > until now without a single problem.
>
> Playing devil's advocate here - the claim is that EXPORT_SYMBOL_GPL is to
> indicate that code is getting too chummy with Linux internals.
>
> However, in *this* case, isn't it "code that is too chummy with *GCC* internals",
> and thus it isn't our place to say what can and can't be done with code that
> is derivative of the GCC compiler? ;)
Actually, it got put in there by accident. I usually default all my
exports as GPL. But this breaks pretty much everything, so I'll leave it
as EXPORT_SYMBOL.
-- Steve
On Tue, 15 Jan 2008 23:04:39 EST, Steven Rostedt said:
>
> On Tue, 15 Jan 2008 [email protected] wrote:
>
> > On Tue, 15 Jan 2008 02:37:37 +0200, =?utf-8?q?S=2E=C3=87a=C4=9Flar?= Onur said:
> > > And because of mcount-add-basic-support-for-gcc-profiler-instrum.patch, closed
> > > source nvidia-new module cannot be used with this release (mcount is exported
> > > GPL only), i know this is not supported but i used it with that [2] patch up
> > > until now without a single problem.
> >
> > Playing devil's advocate here - the claim is that EXPORT_SYMBOL_GPL is to
> > indicate that code is getting too chummy with Linux internals.
> >
> > However, in *this* case, isn't it "code that is too chummy with *GCC* internals",
> > and thus it isn't our place to say what can and can't be done with code that
> > is derivative of the GCC compiler? ;)
>
> Actually, it got put in there by accident. I usually default all my
> exports as GPL. But this breaks pretty much everything, so I'll leave it
> as EXPORT_SYMBOL.
OK, I can live with that. ;)
Hi,
16 Oca 2008 Çar tarihinde, Steven Rostedt şunları yazmıştı:
> On Tue, 15 Jan 2008, [utf-8] S.Ã^GaÄ^_lar Onur wrote:
> > 2.6.24-rc7-rt2 (-rt2 patchset on top of Linus's current git commit
> > 031f2dcd7075e218e74dd7f942ad015cf82dffab) starts to complain like
> > following (full dmesg can be found @ [1]) when try to login from console
> > (the other acpi related errors also existed in 2.6.24-rc5-rt1) and FYI,
> > plain 2.6.24-rc7 (again commit 031f2dcd7075e218e74dd7f942ad015cf82dffab)
> > has no issues.
>
> Do you get the same issues if you add to -rc7 and not git.
I'll try after trying -rt3.
> > [...]
> > sysfs: duplicate filename 'vcs1' can not be created
> > WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> > Pid: 1298, comm: mingetty Not tainted 2.6.24-rc7-rt2-99 #1
> > [...]
> >
> > And because of mcount-add-basic-support-for-gcc-profiler-instrum.patch,
> > closed source nvidia-new module cannot be used with this release (mcount
> > is exported GPL only), i know this is not supported but i used it with
> > that [2] patch up until now without a single problem.
>
> Ah, sorry about that. I'll try to fix that later on. You should still be
> able to use NVidia by turning off function trace.
Wonderfull news :) [and yes turning off function trace works]
> > Please don't misunderstand this, i really do not want to start a
> > discussion for this, i just want to ask the possibility of converting
> > this into EXPORT_SYMBOL cause i thought some of the possible -rt users
> > may need this closed source module explicitly because of its 3D
> > performance.
> >
> > If anything else needed for sysfs warnings please just say it...
> >
> > [1] http://cekirdek.pardus.org.tr/~caglar/dmesg.rt
> > [2]
> > http://svn.pardus.org.tr/pardus/devel/kernel/drivers/nvidia-new/files/rt.
> >patch
>
> Thanks for the report. I'll see what I can do for the next release. But
> for now this will have to wait till after -rt3.
Thanks...
Cheers
--
S.Çağlar Onur <[email protected]>
http://cekirdek.pardus.org.tr/~caglar/
Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
Hi Again;
16 Oca 2008 Çar tarihinde, S.Çağlar Onur şunları yazmıştı:
> 16 Oca 2008 Çar tarihinde, Steven Rostedt şunları yazmıştı:
> > On Tue, 15 Jan 2008, [utf-8] S.Ã^GaÄ^_lar Onur wrote:
> > > 2.6.24-rc7-rt2 (-rt2 patchset on top of Linus's current git commit
> > > 031f2dcd7075e218e74dd7f942ad015cf82dffab) starts to complain like
> > > following (full dmesg can be found @ [1]) when try to login from
> > > console (the other acpi related errors also existed in 2.6.24-rc5-rt1)
> > > and FYI, plain 2.6.24-rc7 (again commit
> > > 031f2dcd7075e218e74dd7f942ad015cf82dffab) has no issues.
> >
> > Do you get the same issues if you add to -rc7 and not git.
>
> I'll try after trying -rt3.
-rt3 on top of 2.6.24-rc8 works fine without that sysfs problem (acpi warnings
still there and full dmesg can be found from [1]), whatever causes this seems
solved :)
[1] http://cekirdek.pardus.org.tr/~caglar/dmesg.rt3
Cheers
--
S.Çağlar Onur <[email protected]>
http://cekirdek.pardus.org.tr/~caglar/
Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
Hi Steve,
I found out that the tracer got stuck on ppc32 platforms because some early
functions call _mcount before mcount_enabled is initialized at all. I made a
patch, which marks these functions as notrace to solve this problem. With this
patch I can successfully boot up our mpc5200b platform and make latency trace.
(tested with -b switch in cyclictest). Please comment.
I made my patch against the -rt2 tree since the dummy call early_printk() in
-rt3 conflicts with our implementation of a functional early_printk(). It
should also work with -rt3 though.
cheers
Luotao Fu
--
Dipl.-Ing. Luotao Fu | Phone: +49-5121-206917-3
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord http://www.pengutronix.de
> Playing devil's advocate here - the claim is that EXPORT_SYMBOL_GPL is to
> indicate that code is getting too chummy with Linux internals.
>
> However, in *this* case, isn't it "code that is too chummy with *GCC* internals",
> and thus it isn't our place to say what can and can't be done with code that
> is derivative of the GCC compiler? ;)
Yes. It would be something to discuss with the FSF.
However I don't think it matters. If you are doing instruction profiling
you need *all* the code built with profiling to get good results. You
can't rebuild the Nvidia modules so you can't profile them.
Alan
> > > On Tue, 15 Jan 2008 02:37:37 +0200, =?utf-8?q?S=2E=C3=87a=C4=9Flar?= Onur said:
> > > > And because of mcount-add-basic-support-for-gcc-profiler-instrum.patch, closed
> > > > source nvidia-new module cannot be used with this release (mcount is exported
> > > > GPL only), i know this is not supported but i used it with that [2] patch up
> > > > until now without a single problem.
> > >
> > > Playing devil's advocate here - the claim is that EXPORT_SYMBOL_GPL is to
> > > indicate that code is getting too chummy with Linux internals.
> > >
> > > However, in *this* case, isn't it "code that is too chummy with *GCC* internals",
> > > and thus it isn't our place to say what can and can't be done with code that
> > > is derivative of the GCC compiler? ;)
> >
> > Actually, it got put in there by accident. I usually default all my
> > exports as GPL. But this breaks pretty much everything, so I'll leave it
> > as EXPORT_SYMBOL.
>
> OK, I can live with that. ;)
>
We modified mcount now, and it is derived from an objdump of glibc. So
this is most definitely a "derived" work from glibc. But glibc is licensed
as LGPL, which IIRC allows for non GPL to link to it.
I personally could care less if we use EXPORT_SYMBOL or EXPORT_SYMBOL_GPL.
But I really want to do The Right Thing(tm). I'm not a lawyer and don't
claim that I know anything about the law, but I'm leaning towards the non
_GPL version because the code was from LGPL and not from strict GPL.
-- Steve
On Wed, 16 Jan 2008, Steven Rostedt wrote:
>
> We modified mcount now, and it is derived from an objdump of glibc. So
> this is most definitely a "derived" work from glibc. But glibc is licensed
> as LGPL, which IIRC allows for non GPL to link to it.
>
> I personally could care less if we use EXPORT_SYMBOL or EXPORT_SYMBOL_GPL.
> But I really want to do The Right Thing(tm). I'm not a lawyer and don't
> claim that I know anything about the law, but I'm leaning towards the non
> _GPL version because the code was from LGPL and not from strict GPL.
Sorry folks, I'm going to stick with the _GPL version. It doesn't mean
that you can't still load your nVidia module into -rt. I just means you
can't turn on function trace and then load it. Well, you might if you
don't compile the nVidia wrapper against it with function trace on.
The reason simply is to cover my butt. By limiting it to GPL, I'm fine.
Even if the original author didn't care. But by opening it up to external
prorietary modules, I may be considered infringing on the license.
So, unless I hear from a lawyer that is willing to back me up on a non
_GPL export publically, the mcount function will stay as an
EXPORT_SYMBOL_GPL.
Note: There is a definite reason for this change. The previous version
of mcount was written by Ingo Molnar, and he added the export. I've
changed mcount to be closer to the glibc code (which I derived it from),
so the change in EXPORT type is legitimate.
-- Steve
On Tue, 15 Jan 2008, Mariusz Kozlowski wrote:
> Ok. It works.
>
> I found this in dmesg:
>
> BUG: swapper:0 task might have lost a preemption check!
> Pid: 0, comm: swapper Not tainted 2.6.24-rc7-rt2 #3
> [<c010386b>] show_trace_log_lvl+0x1d/0x3b
> [<c01042f3>] show_trace+0x12/0x14
> [<c0104a2f>] dump_stack+0x6a/0x70
> [<c0115419>] preempt_enable_no_resched+0x5c/0x5e
This is really really strange. cpu_idle calls __preempt_enable_no_resched
and not preempt_enable_no_resched (notice the prefixed underscores).
So I don't know how you got that output. Did you get any strance rejects
in applying this patch?
-- Steve
> [<c0100e35>] cpu_idle+0x6d/0x82
> [<c0323b6e>] rest_init+0x66/0x68
> [<c043aba6>] start_kernel+0x20c/0x276
> [<00000000>] 0x0
> =======================
> ---------------------------
> | preempt count: 00000000 ]
> | 0-level deep critical section nesting:
> ----------------------------------------
>
> Box runs fine though.
>
> Regards,
>
> Mariusz
> -
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Thomas, can you look at this. He's getting APIC errors on bootup. I'm
wondering if this isn't another strange anomaly of this controller.
He also states that he doesn't get this with the non-rt kernel.
>
> -rt3 on top of 2.6.24-rc8 works fine without that sysfs problem (acpi warnings
> still there and full dmesg can be found from [1]), whatever causes this seems
> solved :)
>
> [1] http://cekirdek.pardus.org.tr/~caglar/dmesg.rt3
-- Steve
On Wed, 16 Jan 2008, Luotao Fu wrote:
>
> I found out that the tracer got stuck on ppc32 platforms because some early
> functions call _mcount before mcount_enabled is initialized at all. I made a
> patch, which marks these functions as notrace to solve this problem. With this
> patch I can successfully boot up our mpc5200b platform and make latency trace.
> (tested with -b switch in cyclictest). Please comment.
>
> I made my patch against the -rt2 tree since the dummy call early_printk() in
> -rt3 conflicts with our implementation of a functional early_printk(). It
> should also work with -rt3 though.
>
Thanks, applied.
But for future reference, if you attach your patch please name it with the
ending of .patch and not .diff. Also do it at a -p1 level and not -p0.
-- Steve
Hello,
> > I found this in dmesg:
> >
> > BUG: swapper:0 task might have lost a preemption check!
> > Pid: 0, comm: swapper Not tainted 2.6.24-rc7-rt2 #3
> > [<c010386b>] show_trace_log_lvl+0x1d/0x3b
> > [<c01042f3>] show_trace+0x12/0x14
> > [<c0104a2f>] dump_stack+0x6a/0x70
> > [<c0115419>] preempt_enable_no_resched+0x5c/0x5e
>
> This is really really strange. cpu_idle calls __preempt_enable_no_resched
> and not preempt_enable_no_resched (notice the prefixed underscores).
> So I don't know how you got that output. Did you get any strance rejects
> in applying this patch?
Nope. Your rt patch applied cleanly to vanilla 2.6.24-rc7.
Regards,
Mariusz
> > [<c0100e35>] cpu_idle+0x6d/0x82
> > [<c0323b6e>] rest_init+0x66/0x68
> > [<c043aba6>] start_kernel+0x20c/0x276
> > [<00000000>] 0x0
> > =======================
> > ---------------------------
> > | preempt count: 00000000 ]
> > | 0-level deep critical section nesting:
> > ----------------------------------------
> >
> > Box runs fine though.
On Thu, 17 Jan 2008, Mariusz Kozlowski wrote:
> Hello,
>
> > > I found this in dmesg:
> > >
> > > BUG: swapper:0 task might have lost a preemption check!
> > > Pid: 0, comm: swapper Not tainted 2.6.24-rc7-rt2 #3
> > > [<c010386b>] show_trace_log_lvl+0x1d/0x3b
> > > [<c01042f3>] show_trace+0x12/0x14
> > > [<c0104a2f>] dump_stack+0x6a/0x70
> > > [<c0115419>] preempt_enable_no_resched+0x5c/0x5e
> >
> > This is really really strange. cpu_idle calls __preempt_enable_no_resched
> > and not preempt_enable_no_resched (notice the prefixed underscores).
> > So I don't know how you got that output. Did you get any strance rejects
> > in applying this patch?
>
> Nope. Your rt patch applied cleanly to vanilla 2.6.24-rc7.
>
OK, do you still get this message? Also I'm assuming this is x86, right?
Could you also do the following.
Go into your kernel build directory.
Start up gdb (I'm hoping that you compiled with DEBUG_INFO)
gdb vmlinux
(gdb) li *0xc0100e35
and show me what you get.
Thanks,
-- Steve
>
> > > [<c0100e35>] cpu_idle+0x6d/0x82
> > > [<c0323b6e>] rest_init+0x66/0x68
> > > [<c043aba6>] start_kernel+0x20c/0x276
> > > [<00000000>] 0x0
> > > =======================
> > > ---------------------------
> > > | preempt count: 00000000 ]
> > > | 0-level deep critical section nesting:
> > > ----------------------------------------
> > >
> > > Box runs fine though.
>
Hello,
> > > > I found this in dmesg:
> > > >
> > > > BUG: swapper:0 task might have lost a preemption check!
> > > > Pid: 0, comm: swapper Not tainted 2.6.24-rc7-rt2 #3
> > > > [<c010386b>] show_trace_log_lvl+0x1d/0x3b
> > > > [<c01042f3>] show_trace+0x12/0x14
> > > > [<c0104a2f>] dump_stack+0x6a/0x70
> > > > [<c0115419>] preempt_enable_no_resched+0x5c/0x5e
> > >
> > > This is really really strange. cpu_idle calls __preempt_enable_no_resched
> > > and not preempt_enable_no_resched (notice the prefixed underscores).
> > > So I don't know how you got that output. Did you get any strance rejects
> > > in applying this patch?
> >
> > Nope. Your rt patch applied cleanly to vanilla 2.6.24-rc7.
> >
>
> OK, do you still get this message? Also I'm assuming this is x86, right?
>
> Could you also do the following.
>
> Go into your kernel build directory.
> Start up gdb (I'm hoping that you compiled with DEBUG_INFO)
> gdb vmlinux
> (gdb) li *0xc0100e35
>
> and show me what you get.
Oh crap. You are totaly right. I messed with quilt on that tree to bisect that thing
with LOCKDEP. A few patches from rt series were left unapplied somehow :/ Sorry for
the noise then.
Regards,
Mariusz
BTW this is the gdb output which ofcourse is bogus.
(gdb) l*0xc0100e35
0xc0100e35 is in cpu_idle (arch/x86/kernel/process_32.c:203).
198 __get_cpu_var(irq_stat).idle_timestamp = jiffies;
199 idle();
200 }
201 tick_nohz_restart_sched_tick();
202 preempt_enable_no_resched();
203 schedule();
204 preempt_disable();
205 }
206 }
207
On Wed, 16 Jan 2008, Steven Rostedt wrote:
>
> On Wed, 16 Jan 2008, Steven Rostedt wrote:
>>
>> We modified mcount now, and it is derived from an objdump of glibc. So
>> this is most definitely a "derived" work from glibc. But glibc is licensed
>> as LGPL, which IIRC allows for non GPL to link to it.
>>
>> I personally could care less if we use EXPORT_SYMBOL or EXPORT_SYMBOL_GPL.
>> But I really want to do The Right Thing(tm). I'm not a lawyer and don't
>> claim that I know anything about the law, but I'm leaning towards the non
>> _GPL version because the code was from LGPL and not from strict GPL.
>
> Sorry folks, I'm going to stick with the _GPL version. It doesn't mean
> that you can't still load your nVidia module into -rt. I just means you
> can't turn on function trace and then load it. Well, you might if you
> don't compile the nVidia wrapper against it with function trace on.
>
> The reason simply is to cover my butt. By limiting it to GPL, I'm fine.
> Even if the original author didn't care. But by opening it up to external
> prorietary modules, I may be considered infringing on the license.
>
> So, unless I hear from a lawyer that is willing to back me up on a non
> _GPL export publically, the mcount function will stay as an
> EXPORT_SYMBOL_GPL.
>
> Note: There is a definite reason for this change. The previous version
> of mcount was written by Ingo Molnar, and he added the export. I've
> changed mcount to be closer to the glibc code (which I derived it from),
> so the change in EXPORT type is legitimate.
>
> -- Steve
Please, tell what in the license forbids me to make a global replacement
EXPORT_SYMBOL_GPL -> EXPORT_SYMBOL and distribute the result?
For me, on the other hand, it is against the spirit of free software to
actively make a block for people to do what ever they want with the code
when they are only doing it to themselves. That includes loading non-GPL
software into the kernel. The only thing they are not allowed to do is to
distribute it and in that way "hurt" other people.
Esben
> -
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Mon, 21 Jan 2008, Esben Nielsen wrote:
>
> Please, tell what in the license forbids me to make a global replacement
> EXPORT_SYMBOL_GPL -> EXPORT_SYMBOL and distribute the result?
If you want to distribute that code, the authors of that said code
may be able to challenge you in saying that you are enabling a means to
circumvent a way around the license, and hold you liable. Remember, all it
takes is one country with the laws that will grant this complaint.
>
> For me, on the other hand, it is against the spirit of free software to
> actively make a block for people to do what ever they want with the code
> when they are only doing it to themselves. That includes loading non-GPL
> software into the kernel. The only thing they are not allowed to do is to
> distribute it and in that way "hurt" other people.
Honestly, I don't care which export it is. The thing is that I derived
that code from someone else. I did not look up the original author of the
code to find out which export they would like it to be. I may be able to
argue that since it was under a LGPL and not a GPL license, I may very
well be able to export it that way.
I'm taking the safe way out. By exporting it as EXPORT_SYMBOL_GPL, I am
safe either way. By exporting it as EXPORT_SYMBOL without first hearing
from the original author (and getting that in writing), or hearing it from
a lawyer, I may be putting myself at risk.
Feel free to creating a version of this code and
s/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/ and distribute it. I wont come after
you for that, but at least I know those that would, will go after you and
not me.
Call me a chicken, I don't care, but I'm just not going to put myself nor
my company I work for, at risk over this issue.
-- Steve
On Mon, 21 Jan 2008, Steven Rostedt wrote:
>
> On Mon, 21 Jan 2008, Esben Nielsen wrote:
>>
>> Please, tell what in the license forbids me to make a global replacement
>> EXPORT_SYMBOL_GPL -> EXPORT_SYMBOL and distribute the result?
>
> If you want to distribute that code, the authors of that said code
> may be able to challenge you in saying that you are enabling a means to
> circumvent a way around the license, and hold you liable. Remember, all it
> takes is one country with the laws that will grant this complaint.
>
>>
>> For me, on the other hand, it is against the spirit of free software to
>> actively make a block for people to do what ever they want with the code
>> when they are only doing it to themselves. That includes loading non-GPL
>> software into the kernel. The only thing they are not allowed to do is to
>> distribute it and in that way "hurt" other people.
>
> Honestly, I don't care which export it is. The thing is that I derived
> that code from someone else. I did not look up the original author of the
> code to find out which export they would like it to be. I may be able to
> argue that since it was under a LGPL and not a GPL license, I may very
> well be able to export it that way.
>
> I'm taking the safe way out. By exporting it as EXPORT_SYMBOL_GPL, I am
> safe either way. By exporting it as EXPORT_SYMBOL without first hearing
> from the original author (and getting that in writing), or hearing it from
> a lawyer, I may be putting myself at risk.
>
> Feel free to creating a version of this code and
> s/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/ and distribute it. I wont come after
> you for that, but at least I know those that would, will go after you and
> not me.
>
> Call me a chicken, I don't care, but I'm just not going to put myself nor
> my company I work for, at risk over this issue.
>
First off, sorry for sounding so harsh and sorry for taking this
discussion onto you. It is quite off-topic in this context. It was just
a rant about the misconception that adding/removing _GPL to
EXPORT_SYMBOL can make non-GPL modules more or less legal. Is is a
_political_ issue, not a legal one.
Esben
> -- Steve
>
> For me, on the other hand, it is against the spirit of free software to
> actively make a block for people to do what ever they want with the code
> when they are only doing it to themselves. That includes loading non-GPL
> software into the kernel. The only thing they are not allowed to do is to
> distribute it and in that way "hurt" other people.
Since the GPL only applies to the people to whom you distribute your
code, if you do not distribute the code, licensing it under the GPL is
100% harmless to you.
So the requirement to only load GPL'd code does not prevent people from
loading code that they do not intend to distribute. They just have to
label it as GPL and then not distribute it.
Stefan