2.6.24-rt1

2.6.24-rt1

[Steven Rostedt]

We are pleased to announce the 2.6.24-rt1 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-rc8-rt1

  - ported to 2.6.24


to build a 2.6.24-rt1 tree, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.24.tar.bz2
  http://rt.et.redhat.com/download/patch-2.6.24-rt1.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.


*** NOTICE ***

This still has the old version of the latency tracer. I'll try to
release a -rt2 soon that has the new version. This way we can see what
kind of regressions the new version might give.

-- Steve

Re: 2.6.24-rt1

[Dragan Noveski]

Steven Rostedt wrote:
> We are pleased to announce the 2.6.24-rt1 tree, which can be
> downloaded from the location:
>
>   http://rt.et.redhat.com/download/
>
>   
hallo list, i just compiled the new release on my laptop (ibm thinkpad 
r50e, debian testing) and im finiding this lines in dmesg:

...
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a 
report
system 00:00: iomem range 0x0-0x9ffff could not be reserved
system 00:00: iomem range 0xc0000-0xc3fff could not be reserved
system 00:00: iomem range 0xc4000-0xc7fff could not be reserved
system 00:00: iomem range 0xc8000-0xcbfff has been reserved
system 00:00: iomem range 0xcc000-0xcffff could not be reserved
system 00:00: iomem range 0x0-0x0 could not be reserved
system 00:00: iomem range 0x0-0x0 could not be reserved
system 00:00: iomem range 0x0-0x0 could not be reserved
system 00:00: iomem range 0xdc000-0xdffff has been reserved
system 00:00: iomem range 0xe0000-0xe3fff could not be reserved
system 00:00: iomem range 0xe4000-0xe7fff could not be reserved
system 00:00: iomem range 0xe8000-0xebfff could not be reserved
system 00:02: ioport range 0x1000-0x107f has been reserved
system 00:02: ioport range 0x1180-0x11bf has been reserved
system 00:02: ioport range 0x15e0-0x15ef has been reserved
system 00:02: ioport range 0x1600-0x167f has been reserved
...

i never saw this before, so could someone guess if i should be scared of it?

cheers,
doc

Re: 2.6.24-rt1

[Sergio Monteiro Basto]

[-- Attachment #1: Type: text/plain, Size: 300 bytes --]


On Sat, 2008-01-26 at 00:59 +0100, Dragan Noveski wrote:
> PCI: Using ACPI for IRQ routing
> PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post
> a report

at least  this part is ACPI message and it an old message , nothing to
worry about 

Regards,
-- 
Sérgio M. B.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2192 bytes --]

Re: 2.6.24-rt1

[Steven Rostedt]

On Sat, 26 Jan 2008, Dragan Noveski wrote:
> >
> hallo list, i just compiled the new release on my laptop (ibm thinkpad
> r50e, debian testing) and im finiding this lines in dmesg:
>
> ....
> PCI: Using ACPI for IRQ routing
> PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a
> report
> system 00:00: iomem range 0x0-0x9ffff could not be reserved
> system 00:00: iomem range 0xc0000-0xc3fff could not be reserved
> system 00:00: iomem range 0xc4000-0xc7fff could not be reserved
> system 00:00: iomem range 0xc8000-0xcbfff has been reserved
> system 00:00: iomem range 0xcc000-0xcffff could not be reserved
> system 00:00: iomem range 0x0-0x0 could not be reserved
> system 00:00: iomem range 0x0-0x0 could not be reserved
> system 00:00: iomem range 0x0-0x0 could not be reserved
> system 00:00: iomem range 0xdc000-0xdffff has been reserved
> system 00:00: iomem range 0xe0000-0xe3fff could not be reserved
> system 00:00: iomem range 0xe4000-0xe7fff could not be reserved
> system 00:00: iomem range 0xe8000-0xebfff could not be reserved
> system 00:02: ioport range 0x1000-0x107f has been reserved
> system 00:02: ioport range 0x1180-0x11bf has been reserved
> system 00:02: ioport range 0x15e0-0x15ef has been reserved
> system 00:02: ioport range 0x1600-0x167f has been reserved
> ....
>
> i never saw this before, so could someone guess if i should be scared of it?
>

Do you see the same with vanilla 2.6.24?

-- Steve

Re: 2.6.24-rt1

[Dragan Noveski]

Steven Rostedt wrote:
> On Sat, 26 Jan 2008, Dragan Noveski wrote:
>   
>> hallo list, i just compiled the new release on my laptop (ibm thinkpad
>> r50e, debian testing) and im finiding this lines in dmesg:
>>
>> ....
>> PCI: Using ACPI for IRQ routing
>> PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a
>> report
>> system 00:00: iomem range 0x0-0x9ffff could not be reserved
>> system 00:00: iomem range 0xc0000-0xc3fff could not be reserved
>> system 00:00: iomem range 0xc4000-0xc7fff could not be reserved
>> system 00:00: iomem range 0xc8000-0xcbfff has been reserved
>> system 00:00: iomem range 0xcc000-0xcffff could not be reserved
>> system 00:00: iomem range 0x0-0x0 could not be reserved
>> system 00:00: iomem range 0x0-0x0 could not be reserved
>> system 00:00: iomem range 0x0-0x0 could not be reserved
>> system 00:00: iomem range 0xdc000-0xdffff has been reserved
>> system 00:00: iomem range 0xe0000-0xe3fff could not be reserved
>> system 00:00: iomem range 0xe4000-0xe7fff could not be reserved
>> system 00:00: iomem range 0xe8000-0xebfff could not be reserved
>> system 00:02: ioport range 0x1000-0x107f has been reserved
>> system 00:02: ioport range 0x1180-0x11bf has been reserved
>> system 00:02: ioport range 0x15e0-0x15ef has been reserved
>> system 00:02: ioport range 0x1600-0x167f has been reserved
>> ....
>>
>> i never saw this before, so could someone guess if i should be scared of it?
>>
>>     
>
> Do you see the same with vanilla 2.6.24?
>
> -- Steve
>
>   
hallo steve, thanks for the response.
i just recompiled without the rt-patch and yes, i see exactly the same 
in dmesg.

cheers,
doc

Re: 2.6.24-rt1

[Steven Rostedt]

On Fri, 25 Jan 2008, Steven Rostedt wrote:
>
> *** NOTICE ***
>
> This still has the old version of the latency tracer. I'll try to
> release a -rt2 soon that has the new version. This way we can see what
> kind of regressions the new version might give.
>

This is taking longer than expected. Removing the old latency tracer has
caused a bit to be broken. The latency tracer has been in the RT kernel
for so long that it has hooks in lots of unrelated patches. It's taking a
bit of surgury to remove all the bits without killing the rest.

I will not be working on this over the weekend. I'll start back up on
Monday.

-- Steve