Came across this and wanted to show it to others more knowledgeable for
feedback. Is this value-added or not? Upstream URL
is: https://gitorious.org/rummage/random_patches
Please cc me on replies as I am not a regular subscriber to lkml. Thank you.
--- linux-3.6/arch/x86/include/asm/module.h
> This only makes sense if you can show a noticeable performance
> improvement using one of the those -march options with at least one
> benchmark from those which we have now in the kernel.
Thank you for the feedback, Boris. Can you point me to the built in benchmarks
to which you referred? I
Please cc me on replies as I am not a regular subscriber to lkml. Thank you.
I tested the attached patch written by André Ramnitz using three different
machines running a generic x86-64 kernel and an otherwise identical kernel
running with the optimized gcc options.
Conclusion: There are sm
> Let's see, if I'm reading the log file correctly, the average values of
> each test run differ by ~ 0.1 seconds tops.
>
> For example, i7-3770K generic build gives on average 69.41404 while
> the more optimized version 69.33554. The diff between the two is even
> less than 0.1 second. The other
> Oh, maybe I wasn't clear - I wasn't talking about statistical
> significance but rather about practical significance.
OK. I will not argue with that :)
> A minuscule speedup (a lot less than 1%) showing only in a *single*
> workload so far and relevant only for a *very* *small* number of linu
Two hunks fail for me patching source from linux-3.10.tar.xz as shown:
patching file Documentation/parisc/registers
patching file Makefile
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej
patching file arch/arm/boot/dts/imx23.dtsi
patching file arch/arm/boot/dts/i
After upgrading to the official Arch Linux 3.9-2 kernel package, dmesg reports
that my NIC is hanging:
[ 5.955720] e1000e :00:19.0 eno1: changing MTU from 1500 to 4000
[ 8.464507] e1000e :00:19.0 eno1: Detected Hardware Unit Hang:
TDH <0>
TDT <2
- Original Message -
> From: Bjorn Helgaas
> To: John
> Cc: lkml ; Jeff Kirsher
> ; "e1000-de...@lists.sourceforge.net"
>
> Sent: Monday, May 6, 2013 1:29 PM
> Subject: Re: 3.9.0 dmesg reports that my NIC is hanging
>
> [+cc Jeff, e1000-devel
Sorry if this is a repeat. Can't find anything on it. My guess is that
I don't know where to look. I am trying to build the 2.4.5 kernel on a
Sparc LX. I get numerous error messages when trying to build the
kernel:
> make[1]: Entering directory `/usr/src/linux-2.4.5/mm'
> make all_targets
> m
--
This submission of the AppArmor security module is based against 2.6.24-rc4-mm.
Any comments and feedback to improve implementation are appreciated.
Changes since previous submission
- added apparmor security goal document.
Documentation/lsm/AppArmor-Security-Goal.txt
- removed DAC style p
This is needed for computing pathnames in the AppArmor LSM.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/namei.c |2 +-
include/linux
Required by a later patch that adds a struct vfsmount parameter to
notify_change().
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/ntfs/file.c
;
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/attr.c |3 ++-
fs/ecryptfs/inode.c |4 +++-
fs/exec.c |3 ++-
fs/fat/file.c |2 +-
fs/hpfs/namei.c |2 +-
fs/namei.c |2 +-
fs/nfsd/vfs.c |8
fs/open.
The vfsmount will be passed down to the LSM hook so that LSMs can compute
pathnames.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/ecryptfs/inode.c |5
This is needed for computing pathnames in the AppArmor LSM.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/namei.c |2 +-
include/linux
The vfsmount will be passed down to the LSM hook so that LSMs can compute
pathnames.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/ecryptfs/inode.c |5
This is needed for computing pathnames in the AppArmor LSM.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/namei.c |2 +-
include/linux
The vfsmount will be passed down to the LSM hook so that LSMs can compute
pathnames.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/ecryptfs/inode.c |
This is needed for computing pathnames in the AppArmor LSM.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/namei.c |2 +-
include/linux
This is needed for computing pathnames in the AppArmor LSM.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/stat.c|3 ++-
include/linux
The vfsmount will be passed down to the LSM hook so that LSMs can compute
pathnames.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/ecryptfs/inode.c |9 +++
This is needed for computing pathnames in the AppArmor LSM.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/namei.c |3 ++-
include/linux
The vfsmount will be passed down to the LSM hook so that LSMs can compute
pathnames.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/ecryptfs/inode.c |
This is needed for computing pathnames in the AppArmor LSM.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/namei.c |2 +-
include/linux
If we unhash the dentry before calling the security_inode_rmdir hook,
we cannot compute the file's pathname in the hook anymore. AppArmor
needs to know the filename in order to decide whether a file may be
deleted, though.
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
Signed-off-
The vfsmount will be passed down to the LSM hook so that LSMs can compute
pathnames.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/ecryptfs/inode.c |
This is needed for computing pathnames in the AppArmor LSM.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/namei.c |2 +-
include/linux
The vfsmount will be passed down to the LSM hook so that LSMs can compute
pathnames.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/ecryptfs/inode.c |7 +
This is needed for computing pathnames in the AppArmor LSM.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/namei.c |6 --
include/linux
The vfsmount will be passed down to the LSM hook so that LSMs can compute
pathnames.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/nfsd/vfs.c | 16 ++
This is needed for computing pathnames in the AppArmor LSM.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/xattr.c |4 ++--
include/linux
The vfsmount will be passed down to the LSM hook so that LSMs can compute
pathnames.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/nfsd/nfs4xdr.c |2
This is needed for computing pathnames in the AppArmor LSM.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/xattr.c |2 +-
include/linux
The vfsmount will be passed down to the LSM hook so that LSMs can compute
pathnames.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/unionfs/copyup.c |5 +++--
This is needed for computing pathnames in the AppArmor LSM.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/xattr.c |2 +-
include/linux
The vfsmount will be passed down to the LSM hook so that LSMs can compute
pathnames.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/nfsd/vfs.c |7 ---
This is needed for computing pathnames in the AppArmor LSM.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/xattr.c |2 +-
include/linux
eaves getcwd() and d_path() as they were before for everything
except for bind-mounted directories; for them, it reports ``/foo/bar'' instead
of ``foobar'' in the example described above.
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Joha
TED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/dcache.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1766,7 +1766,7 @@ shouldnt_be_hashed:
static char *__d_path(struct path *path, struct path *root,
In AppArmor, we are interested in pathnames relative to the namespace root.
This is the same as d_path() except for the root where the search ends. Add
a function for computing the namespace-relative path.
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen &
MAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
---
fs/fuse/file.c | 13 +
fs/stat.c | 29 -
include/linux/fs.h |1 +
3 files changed, 42 insertions(+), 1 deletion(-)
--- a/fs/fuse/file.c
+++ b/fs/fuse/f
igned-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/afs/dir.c |1 +
fs/afs/file.c|1 +
fs/afs/inode.c | 19 ++
This allows LSMs to also distinguish between file descriptor and path
access for the xattr operations. (The other relevant operations are
covered by the setattr hook.)
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
f
Convert the selinux sysctl pathname computation code into a standalone
function.
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
Reviewed-by: James Morris <[EMAIL PROTECTED]>
---
include/linux/sysctl.h |2 +
Set the LOOKUP_CONTINUE flag when checking parent permissions. This allows
permission functions to tell between parent and leaf checks.
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/namei.c |2 ++
1 file changed,
Switch from file_permission() to vfs_permission() in sys_fchdir(): this
avoids calling permission() with a NULL nameidata here.
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/open.c | 11 ++-
1 file changed,
We cannot easily switch from file_permission() to vfs_permission()
everywhere, so fix file_permission() to not use a NULL nameidata
for the remaining users.
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/namei.c |8
nally visible (analagous to vprintf)
Patch is not in mainline -- pending AppArmor code submission to lkml
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
include/linux/audit.h | 12 +++-
kernel/audit.c|
The underlying functions by which the AppArmor LSM hooks are implemented.
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
---
security/apparmor/main.c | 1357 +++
1 file changed, 135
Module parameters, LSM hooks, initialization and teardown.
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
---
security/apparmor/lsm.c | 815
1 file changed, 815 insertions(
Pathname matching, transition table loading, profile loading and
manipulation.
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
---
security/apparmor/match.c| 299 +
security/apparmor/match.h
d-off-by: John Johansen <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
---
security/apparmor/Kconfig |9 +
security/apparmor/Makefile | 13 +
security/apparmor/apparmor.h | 323 +
security/apparmor/ap
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
---
security/Kconfig |1 +
security/Makefile |1 +
security/apparmor/Kconfig | 22 --
3 files changed, 22 insertions(+), 2 deletio
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
Signed-off-by: Jesse Michael <[EMAIL PROTECTED]>
---
security/apparmor/Makefile |7 +
security/apparmor/apparmor.h |7 +
security/apparmor/lsm.c | 129 ++-
secur
Switch from file_permission() to vfs_permission() in do_path_lookup():
this avoids calling permission() with a NULL nameidata here.
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/namei.c |9 +++--
1 fil
--- /dev/null
+++ b/Documentation/lsm/AppArmor-Security-Goal.txt
@@ -0,0 +1,134 @@
+AppArmor Security Goal
+Crispin Cowan, PhD
+MercenaryLinux.com
+
+This document specifies the security goal that AppArmor is intended to
+achieve, so that users can evaluate whether AppArmor will meet their
+needs,
This is needed for computing pathnames in the AppArmor LSM.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/attr.c|4 ++--
include/linux
John Stultz wrote:
On Wed, 2007-01-24 at 10:41 +0100, John wrote:
I'm using the POSIX timers API. My platform is x86 running Linux
2.6.18.6 patched with the high-resolution timer subsystem.
http://www.tglx.de/hrtimers.html
I've written a small "de-jittering engine" that
[ Re-sending in the hope that it will be archived ]
Ingo Molnar wrote:
John Stultz wrote:
On Wed, 2007-01-24 at 10:41 +0100, John wrote:
I'm using the POSIX timers API. My platform is x86 running Linux
2.6.18.6 patched with the high-resolution timer subsystem.
http://www.tg
next->timestamp = now;
+ next->timestamp = next->last_ran = now;
rq->nr_switches++;
rq->curr = next;
++*switch_count;
Regards,
John
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
Hello,
It is possible to ask Linux to timestamp incoming datagrams when they
are received, then to retrieve this timestamp with an ioctl command or
a recvmsg call (which would save one round trip to kernel space).
SIOCGSTAMP
Return a struct timeval with the receive timestamp of the last
pack
John wrote:
It is possible to ask Linux to timestamp incoming datagrams when they
are received, then to retrieve this timestamp with an ioctl command or
a recvmsg call (which would save one round trip to kernel space).
SIOCGSTAMP
Return a struct timeval with the receive timestamp of the
Andi Kleen wrote:
John wrote:
My app expects a stream of UDP datagrams containing compressed video.
These datagrams have been time stamped by the source using a high
resolution clock.
Why do you need another time stamp then?
Source and receiver do not share a common clock. Thus, I have to
John wrote:
Andi Kleen wrote:
John wrote:
My app expects a stream of UDP datagrams containing compressed video.
These datagrams have been time stamped by the source using a high
resolution clock.
Why do you need another time stamp then?
Source and receiver do not share a common clock
Ingo Molnar wrote:
John wrote:
John Stultz wrote:
Also do check the -rt tree as Ingo suggested. I mis-read your earlier
email and thought you were running it.
I've been pulling my hair over a related issue for the past two days.
(I think I may be tickling a -hrt bug...)
I'm wo
Ingo Molnar wrote:
John wrote:
Ingo Molnar wrote:
2.6.18-rt7 is pretty old, do you see the problem in 2.6.20-rc6-rt5 too?
Ingo, Thomas,
I cannot reproduce in 2.6.20-rc6-rt6, but it is not strictly an
apples-to-apples comparison because I get a tsc clocksource in
2.6.20-rc6-rt6, and an
Peter Zijlstra wrote:
John wrote:
Ingo Molnar wrote:
John wrote:
John Stultz wrote:
Also do check the -rt tree as Ingo suggested. I mis-read your earlier
email and thought you were running it.
I've been pulling my hair over a related issue for the past two days.
(I think I m
Jesse Brandeburg wrote:
John wrote:
Jesse Brandeburg wrote:
can you try adding mdelay(100); in e100_eeprom_load before the for loop,
and then change the multiple udelay(4) to mdelay(1) in e100_eeprom_read
I applied the attached patch.
Loading the driver now takes around one minute
Thomas Gleixner wrote:
On Wed, 2007-02-07 at 11:25 +0100, John wrote:
Are there people that use the -rt patch set in real industrial applications?
Yes. But we use a stabilized version of 2.6.16-rt29.
http://www.osadl.org/projects/downloads/preempt-rt/linux-2.6.16/
Thanks for the pointer
John Stultz wrote:
Also do check the -rt tree as Ingo suggested. I mis-read your earlier
email and thought you were running it.
I've been pulling my hair over a related issue for the past two days.
(I think I may be tickling a -hrt bug...)
I'm working with 2.6.18.6 + patch-2.6.18
[ Same player shoot again. Fix address. ]
Ingo Molnar wrote:
John wrote:
John Stultz wrote:
Also do check the -rt tree as Ingo suggested. I mis-read your earlier
email and thought you were running it.
I've been pulling my hair over a related issue for the past two days.
(I think
eck whether the signal is pending, and block waiting for the
signal. I then print how long I've had to wait.
# ./a.out
RESOLUTION=1 ns
NOW=969.735545919
SLEEPING 1 SECOND...
NOW=970.735581398
NOW=970.735613525
NOW=970.735749017
nsdiff=135492 ns i.e. 135.5 µs
Any ideas?
Regards,
John
John wrote:
I'm playing with the POSIX timers API. My platform is x86 running Linux
2.6.18.1 patched with the high-resolution timer subsystem.
http://www.tglx.de/hrtimers.html
I'm seeing unexpected behavior from timer_settime().
int timer_settime(timer_t timerid, int flags,
co
John wrote:
-0009 : System RAM
000a-000b : Video RAM area
000f-000f : System ROM
0010-0ffe : System RAM
0010-00296a1a : Kernel code
00296a1b-0031bbe7 : Kernel data
0fff-0fff2fff : ACPI Non-volatile Storage
0fff3000-0fff : ACPI Tables
2000
Jesse Brandeburg wrote:
John wrote:
Here is some context for those who have been added to the CC list:
http://groups.google.com/group/linux.kernel/browse_frm/thread/bdc8fd08fb601c26
As far as I understand, some consider the eepro100 driver to be
obsolete, and it has been considered for
Hello,
I've tweaked patch-2.6.20-rt8 so that it applies to 2.6.20.3
The unified diff is attached to this message.
I'd be happy to hear comments on what I've done wrong!
Regards.
--- patch-2.6.20-rt82007-02-16 10:48:03.0 +0100
+++ patch-2.6.20.3-rt8 2007-03-14 18:00:24.0 +0
Hello everyone,
According to Wikipedia:
http://en.wikipedia.org/wiki/Non-Maskable_Interrupt
http://en.wikipedia.org/wiki/System_Management_Mode
"SMM is an operating mode of the Intel 386SL and later microprocessor in
which all normal execution (including the operating system) is
suspended, and
John wrote:
On the systems I have to work with [...]
I didn't specify what they were.
CPU: Intel Pentium 3
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 11
model name : Intel(R) Pentium(R) III CPU - S 12
John wrote:
I've tweaked patch-2.6.20-rt8 so that it applies to 2.6.20.3
The unified diff is attached to this message.
I'd be happy to hear comments on what I've done wrong!
Would anybody care to comment on the patch? :-)
I made 4 simple edits.
linux/Makefile
Hello,
I've tweaked patch-2.6.20-rt8 so that it applies to 2.6.20.5
The unified diff is attached to this message.
I'd be happy to hear comments on what I've done wrong.
78 hunks had to be offset and 3 hunks had to be fuzzed.
$ grep -B1 fuzz patch.log
patching file arch/ia64/kernel/iosapic.c
H
Ingo Molnar wrote:
John wrote:
I've tweaked patch-2.6.20-rt8 so that it applies to 2.6.20.5
The unified diff is attached to this message.
thanks - this is useful to those who are not that much on the bleeding
edge.
I'd be happy to hear comments on what I've done wrong.
Ingo Molnar wrote:
John wrote:
I'd be happy to generate a clean patch!
(Would you agree to host it in your directory?)
http://people.redhat.com/mingo/realtime-preempt/older/
sure, i can put it there.
Great! Can you tell me how you generate the original -rt patch, so I can
provi
Ingo Molnar wrote:
John wrote:
Great! Can you tell me how you generate the original -rt patch, so I
can provide an updated version when a new 2.6.20 kernel is released?
they should be generated the way you did: apply the 2.6.20 baseline -rt
kernel patch to the later patches and fix up
Hello everyone,
I'm using 2.6.20.3 patched with -rt8 (and glibc 2.3.6).
http://people.redhat.com/mingo/realtime-preempt/older/patch-2.6.20-rt8
I've written a small program where I call clock_nanosleep() in a loop
requesting a 2-ms pause, then call clock_gettime().
cf. clock_nanosleep_bug.cxx
A
John wrote:
It seems the CPU was not switched to high-resolution mode?
# dmesg | grep resolution
/* NOTHING */
Do I need to enable ACPI?
ACPI seems mandatory for high-resolution mode?
I added...
CONFIG_ACPI=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
Hello everyone,
I'm runnning 2.6.20.3 patched with -rt8 (and glibc 2.3.6).
http://people.redhat.com/mingo/realtime-preempt/older/patch-2.6.20-rt8
I've written a program to highlight a phenomenon I don't understand.
This system includes a PCI board that provides data at ~38 Mbit/s.
I request dat
Lee Revell wrote:
John wrote:
I'm runnning 2.6.20.3 patched with -rt8 (and glibc 2.3.6).
http://people.redhat.com/mingo/realtime-preempt/older/patch-2.6.20-rt8
I've written a program to highlight a phenomenon I don't understand.
This system includes a PCI board that provi
Lee Revell wrote:
John wrote:
Would someone know how to disable SMM in this BIOS?
There's no generic way.
I understand. Would someone know how to disable SMM in the VIA Pro133T
chipset (VT82C596B south bridge). What I/O ports do I need to write to,
and what values should I wri
I'm interested in financing your business project. I'm open to further
discussion aimed at reaching an agreement.
David,
No objections. I've been using it in production and have not seen any
problems.
-John
On 1/25/2015 10:05 AM, Greg Kroah-Hartman wrote:
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: David Vrabel
[ Upstram c
Mama Mia!
These fem@les are pleasing themselves with machines!!!
http://www.fuckingmachines.com/track/MTYyMTA1MTozOjM,4/
No more such Info? Simply answer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kerne
might be related to the fact
that 24 cores can be described with a traditional 32-bit mask, but I
wasn't able to find anywhere that a larger mask wouldn't be handled
correctly.
In my case, it was happening with ixgbe and i40e cards.
-John
--
To unsubscribe from this list: sen
ail; in particular we need the
> Signed-off-by: statements.
>
>
> -hpa
>
From: John Audia
Signed-off-by: John Audia
This patch has been tested on and known to work with kernel versions from 3.2
up to the latest git version (pulled on 12/14/2013).
This patch will expand
> From: Austin S Hemmelgarn <>
> This really depends on how you define 'big'. Even a 1% performance
> increase is significant for a realtime system, and for someone with a
> cluster of systems, getting even a small improvement in performance on
> all of the systems could mean a huge increase in ef
- Original Message -
> From: Richard Weinberger <>
>
> A *very* small speedup.
>
> And I really doubt your numbers.
> Why are you using ANOVA? You're comparing *two* groups not more than two.
> I had a quick look at your raw numbers, they don't seem to be normally
> distributed at all.
When booting into linux v3.13.3, I am unable to mount an nfs share on this
particular hardware. I get the same problem using v3.12.11. Only the 3.10.x
series allows normal operation. Partial dmesg output shown inline, additional
logs available upon request.
PLEASE cc me on my replies as I am
> When booting into linux v3.13.3, I am unable to mount an nfs share on this
> particular hardware. I get the same problem using v3.12.11. Only the 3.10.x
> series allows normal operation. Partial dmesg output shown inline,
> additional
> logs available upon request.
>
> PLEASE cc me on my
- Original Message -
> From: Borislav Petkov <>
> Sent: Saturday, February 15, 2014 3:30 PM
> Subject: Re: [BUG] unable to handle kernel NULL pointer dereference
>
> If I'd have to guess, that's trying to rcu deref that struct net_generic
> *ng in net_generic() but this is only guesswork
- Original Message -
> From: Borislav Petkov <>
> Sent: Saturday, February 15, 2014 6:25 PM
> Subject: Re: [BUG] unable to handle kernel NULL pointer dereference
>
> On Sat, Feb 15, 2014 at 01:04:22PM -0800, John wrote:
>> Thanks for the reply, Boris.
- Original Message -
> From: Trond Myklebust
> To: Borislav Petkov ; Linux NFS Mailing List
>
> Cc: John ; lkml ;
> "net...@vger.kernel.org" ;
> "step...@networkplumber.org" ;
> "mlind...@marvell.com" ; J. Bruce Fields
>
&g
1 - 100 of 6511 matches
Mail list logo
