Does not work on 2.6.82.2

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Patch does not apply
2. Manually apply patch (see attachment)

2. Install sreadahead to start early in boot
3. Pack file of size 0 is created

And 

4. echo open >/sys/kernel/debug/tracing/current_tracer 
5. echo 1 >/sys/kernel/debug/tracing/tracing_enabled
6. Run some commands that open files.
7. No data in /sys/kernel/debug/tracing/trace

What is the expected output?
Pack file should contain some entries, and the trace should contain some
entries.

What version of the product are you using? On what operating system?
1.0, x86_64 Debian Linux, 2.6.28.2

Please provide any additional information below.
The kernel patch was obviously not intended for 2.6.28.2, since it didn't
apply, so manually applying (and fixing names like using DEFINE_TRACE
instead of DECLARE_TRACE) may not be good enough.
It would be nice if there was a patch that applies to 2.6.28.2, and has
been tested to work with it.

Original issue reported on code.google.com by [email protected] on 30 Jan 2009 at 12:22

Attachments:

• sreadahead-manual.patch

[GoogleCodeExporter]

I can confirm I had the same issue with 2.6.28.2.
I have followed the same steps, and also get no output on 
/sys/kernel/debug/tracing/trace

When you change DEFINE_TRACE and DECLARE_TRACE, the compiler spits out some 
warning,
about a pointer type mismatch. I am not sure it this is the reason no output is
generated?

Original comment by ashley%[email protected] on 31 Jan 2009 at 12:02

[GoogleCodeExporter]

Managed to get sreadahead working under 2.6.28.2. It looks like something has 
changed
in the was the tracing is configured. The following patch fixes the problem of 
an
empty pack file.

Original comment by ashley%[email protected] on 1 Feb 2009 at 6:41

Attachments:

• sreadahead_iter_ctrl.patch

[GoogleCodeExporter]

Confirmed, it works using the sreadahead_iter_ctrl.patch. I get nice, almost 
constant
105Mb/s I/O during boot (the "disk" is a SSD, YMMV).

Original comment by [email protected] on 2 Feb 2009 at 2:11

[GoogleCodeExporter]

can someone hint me on how to apply which patches to what? i know how to use 
patch,
but if i apply sreadahead-manual.patch and the one included with 1.0 to 2.6.28,
things start going wrong.

Original comment by [email protected] on 2 Feb 2009 at 2:41

[GoogleCodeExporter]

The patch currently only works on 2.6.29-rc1 and newer kernel versions.

Original comment by [email protected] on 2 Feb 2009 at 3:28

[GoogleCodeExporter]

auke.booij: On my 2.6.28 I applied sreadahead-manual.patch and
sreadahead_iter_ctrl.patch, and not the one from the package. However you may 
want to
wait until an official 2.6.28 patch is released ;)

Original comment by [email protected] on 2 Feb 2009 at 7:43

[GoogleCodeExporter]

When will the official patch for 2.6.28 be released? 
edwintorok: I followed your procedure above. readahead-manual.patch applies but
compiling the kernel fails. trace_open not found. I am using 2.6.28.4. The 
patch in
the package has kernel/trace/trace_open.c but readahead-manual.patch does not 
have
this. Am I missing something? Can somebody please update me how they got this 
working? 

Original comment by [email protected] on 16 Feb 2009 at 3:32

[GoogleCodeExporter]

I'm not going to release a patch for 2.6.28. I'm currently investigating making
sreadahead working WITHOUT any kernel patches for 2.6.30 and above, and welcome
anyone making patches for older kernels.

Original comment by [email protected] on 14 May 2009 at 4:39

[GoogleCodeExporter]

Does anyone have the patch for 2.6.30-rc8? Im building the new kernel, but I 
cant
patch it using 0001-kernel-trace-open.patch.

Original comment by [email protected] on 9 Jun 2009 at 12:48

[GoogleCodeExporter]

In the mean time that new sreadahead for 2.6.30 is developed, I have adapted 
existing
patch for 2.6.30.

Original comment by [email protected] on 15 Jun 2009 at 9:00

Attachments:

• 0001-dapted-Auke-Kok-s-patch-to-kernel-2.6.30.patch

[GoogleCodeExporter]

thanks you for your patch I will try it

Original comment by [email protected] on 17 Jun 2009 at 8:51

[GoogleCodeExporter]

Here's a patch to add a TRACE_EVENT for the open() syscall as a stop-gap until 
the
syscall tracepoint patches are merged

Original comment by [email protected] on 20 Jul 2009 at 4:22

Attachments:

• 0001-trace-add-trace_event-for-the-open-syscall.patch

[GoogleCodeExporter]

sreadahead patch to support the above in my fixes branch:
http://bazaar.launchpad.net/~scott/sreadahead/fixes/revision/37

Original comment by [email protected] on 20 Jul 2009 at 4:29