* David Schwartz [EMAIL PROTECTED] wrote:
These are generic statements, but i'm _really_ interested in the
specifics. Real, specific code that i can look at. The typical Linux
distro consists of in execess of 500 millions of lines of code, in
tens of thousands of apps, so there really
* David Schwartz [EMAIL PROTECTED] wrote:
(user-space spinlocks are broken beyond words for anything but
perhaps SCHED_FIFO tasks.)
User-space spinlocks are broken so spinlocks can only be implemented
in kernel-space? Even if you use the kernel to schedule/unschedule the
tasks, you
Andrew Morton [EMAIL PROTECTED] writes:
revert-x86_64-mm-cpa-einval.patch
fix-x86_64-mm-sched-clock-share.patch
agp-fix-race-condition-between-unmapping-and-freeing-pages.patch
x86_64-mce-poll-at-idle_start-and-printk-fix.patch
fix-x86_64-mm-unwinder.patch
On Tue, 2 Oct 2007, Andi Kleen wrote:
Agreed.
I just got a x8664-hrt report, where I found the following oddity:
0: 1197 172881 IO-APIC-edge timer
That's one of those infamous AMD C1E boxen. Strange, all my systems have
IRQ#0 on CPU#0 and nowhere else. Any
Avi Kivity wrote:
The code doesn't support having both lazy modes active at once. Maybe
that's not an issue, but aren't the two modes orthogonal?
Hm, well, that's a good question. The initial semantics of the lazy
mode calls were what VMI wants, and they're still not really nailed
down. VMI
* David Schwartz [EMAIL PROTECTED] wrote:
at a quick glance this seems broken too - but if you show the
specific code i might be able to point out the breakage in detail.
(One underlying problem here appears to be fairness: a quick
unlock/lock sequence may starve out other threads.
Rusty Russell wrote:
That's good, but this code does lose on native because we no longer
simply replace the entire thing with noops.
Perhaps inverting this and having (inline) helpers is the way to go?
I'm thinking that the overhead will be unmeasurably small, and its not
really worth any
On 02 Oct 2007 08:18:17 +0200 Andi Kleen [EMAIL PROTECTED] wrote:
Andrew Morton [EMAIL PROTECTED] writes:
revert-x86_64-mm-cpa-einval.patch
fix-x86_64-mm-sched-clock-share.patch
agp-fix-race-condition-between-unmapping-and-freeing-pages.patch
On Mon, Oct 01, 2007 at 11:08:14AM -0700, Arjan van de Ven wrote:
On Mon, 1 Oct 2007 16:15:53 +0400
Alexey Dobriyan [EMAIL PROTECTED] wrote:
Save ~650 bytes here.
add/remove: 4/0 grow/shrink: 0/7 up/down: 430/-1088 (-658)
function old new
On Mon, 1 Oct 2007, Jeff Dike wrote:
The Kconfig language seems not to allow calculation of hex constants,
so I moved this to as-layout.h. CONFIG_STUB_CODE, CONFIG_STUB_DATA,
and CONFIG_STUB_START are now gone. In their place are STUB_CODE,
STUB_DATA, and STUB_START in as-layout.h.
Hmm,
* David Schwartz [EMAIL PROTECTED] wrote:
These are generic statements, but i'm _really_ interested in the
specifics. Real, specific code that i can look at. The typical Linux
distro consists of in execess of 500 millions of lines of code, in
tens of thousands of apps, so there really
Ingo Molnar [EMAIL PROTECTED] writes:
* David Schwartz [EMAIL PROTECTED] wrote:
These are generic statements, but i'm _really_ interested in the
specifics. Real, specific code that i can look at. The typical Linux
distro consists of in execess of 500 millions of lines of code, in
On Tue, Oct 02 2007, Benjamin Herrenschmidt wrote:
On Mon, 2007-10-01 at 13:59 +0200, Jens Axboe wrote:
On Sun, Sep 30 2007, Grant Likely wrote:
On 9/30/07, Christoph Hellwig [EMAIL PROTECTED] wrote:
On Sun, Sep 30, 2007 at 04:57:09PM -0600, Grant Likely wrote:
+ if ((rc =
These are fine to me, but should not all go through my tree
because most changes are in other architectures.
I assume you're referring to just
convert-cpu_sibling_map-to-be-a-per-cpu-variable* here.
All the *-to-*per-cpu* patches from Mike yes
I have nothing pending currently. I
Pieter, do applications like yours need the cycle counter only for a few
predetermined packets or for each and every packet?
We need it for every packet for two reasons:
1) it's the only way to determine how many packets were dropped when
packet drops are flagged in the callback
Your
Hi!
From: Rob Landley [EMAIL PROTECTED]
Add Documentation/power/00-INDEX
Signed-off-by: Rob Landley [EMAIL PROTECTED]
Looks mostly ok.
+swsusp.txt
+ - Goals, implementation, and usage of software suspend (ACPI S3)
But please delete (ACPI S3) remark. It is ACPI S4, if anything.
On Tue, 2007-10-02 at 07:15 +0200, Andi Kleen wrote:
On Mon, Oct 01, 2007 at 08:57:10PM -0600, Thayne Harbaugh wrote:
For mmap you can emulate it by passing a low hint != 0 (e.g. getpagesize())
in address but without MAP_FIXED and checking if the result is not beyond
your range.
Cool.
On Mon, 2007-10-01 at 22:01 -0700, Philip Langdale wrote:
Benjamin Herrenschmidt wrote:
On Tue, 2007-10-02 at 14:44 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2007-10-01 at 20:23 -0700, Philip Langdale wrote:
Thanks to Matt Domsch and Rezwanul Kabir at Dell, we know how to disable
the
On Tue, 2 Oct 2007 09:01:10 +0200 Andi Kleen [EMAIL PROTECTED] wrote:
These are fine to me, but should not all go through my tree
because most changes are in other architectures.
I assume you're referring to just
convert-cpu_sibling_map-to-be-a-per-cpu-variable* here.
All the
hi,
I'm trying to dump some information from dev.c to user space
file.Following is the code which i'm using to write to user spcae
file.I'm using 2.6.22.x86_64 kernel.
#define _write(f, buf, sz) (f-f_op-write(f, buf, sz, f-f_pos))
#define WRITABLE(f) (f-f_op f-f_op-write)
int
Domain transition functions for TOMOYO Linux.
Every process belongs to a domain in TOMOYO Linux.
Domain transition occurs when execve(2) is called
and the domain is expressed as 'process invocation history',
such as 'kernel /sbin/init /etc/init.d/rc'.
Domain information is stored in
This patch makes access logs sent to auditing subsystem.
TOMOYO Linux uses two channels for auditing.
One is 'AUDIT_TMY_GRANTED', used for auditing accesses which are
granted in the TOMOYO Linux policy.
The other is 'AUDIT_TMY_REJECTED', used for auditing accesses which
are not granted in the
File access control functions for TOMOYO Linux.
TOMOYO Linux checks permission in
open/creat/unlink/truncate/ftruncate/mknod/mkdir/
rmdir/symlink/link/rename/uselib/sysctl .
Each permission can be automatically accumulated into
the policy of each domain using 'learning mode'.
Signed-off-by:
argv[0] check functions for TOMOYO Linux.
If the executed program name and argv[0] is different,
TOMOYO Linux checks permission.
Each permission can be automatically accumulated into
the policy of each domain using 'learning mode'.
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by:
On Tue, 2 Oct 2007 00:18:09 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
How come? Memoryless node can and do occur in real-world machines.
Kernel
should support that?
But a node is just defined by its memory?
Don't think so. A node is a lump of circuitry which can have
Network access control functions for TOMOYO Linux.
TOMOYO Linux checks permission by the following four parameters.
* protocol type (TCP, UDP, RAW)
* access type (bind, listen, connect, accept)
* IP address (Both IPv4 and IPv6 are available)
* port number
In order to check 'TCP accept' and
This will never work, as you call blocking (non-atomic) functions from
atomic context.
kernel coder wrote:
hi,
I'm trying to dump some information from dev.c to user space
file.Following is the code which i'm using to write to user spcae
file.I'm using 2.6.22.x86_64 kernel.
Mount access control functions for TOMOYO Linux.
TOMOYO Linux checks permission according to
device name, mount point, filesystem type and optional flags.
TOMOYO Linux also checks permission in umount and pivot_root.
Each permission can be automatically accumulated into
the policy using 'learning
* Andrew Morton [EMAIL PROTECTED] wrote:
On 02 Oct 2007 08:18:17 +0200 Andi Kleen [EMAIL PROTECTED] wrote:
The clockevents patches are not included in this; but given the
recent trouble i'm not 100% sure they are even ready yet.
i'm curious, which recent trouble do you refer to? (The NMI
Hi,
The layout of struct blk_user_trace_setup is a bit unfortunate, it gets
padded differently on 32-bit and 64-bit archs. So right now it's not
possible to trace 64-bit kernels with a 32-bit app. This patch fixes
that up by adding a compat ioctl handler for BLKTRACESETUP.
Signed-off-by: Jens
Signal control functions for TOMOYO Linux.
TOMOYO Linux checks sending signal by signal number and
the domain of target process. In order to check signal
permission, LSM expansion patch [TOMOYO 14/15] is needed.
Each permission can be automatically accumulated into
the policy of each domain using
On Fri, Sep 28, 2007 at 07:40:48AM +1000, Nick Piggin wrote:
On Sunday 02 September 2007 08:14, Andi Kleen wrote:
David Miller [EMAIL PROTECTED] writes:
From: Byron Bradley [EMAIL PROTECTED]
Date: Fri, 31 Aug 2007 03:12:46 + (UTC)
Anybody got any ideas of how we fix this?
I
LSM wrapper functions for TOMOYO Linux access control.
If bind mounts are used, TOMOYO requires all permissions for
all possible pathnames (whereas AppArmor requires one of possible pathnames).
If struct vfsmount is passed to LSM hooks as AppArmor proposes,
this file will become more simpler and
This patch allows administrators use conditional permission.
TOMOYO Linux supports conditional permission based on
process's UID,GID etc. and/or requested pathname's UID/GID.
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
LSM expansion for TOMOYO Linux.
LSM hooks for sending signal:
* task_kill_unlocked is added in sys_kill
* task_tkill_unlocked is added in sys_tkill
* task_tgkill_unlocked is added in sys_tgkill
LSM hooks for network accept and recv:
* socket_post_accept is modified to return int.
*
Kconfig and Makefile for TOMOYO Linux.
TOMOYO Linux is placed in security/tomoyo .
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
security/Kconfig |1 +
security/Makefile|1 +
security/tomoyo/Kconfig | 18
On 2007/08/27 21:11, Kyle Moffett wrote:
This is probably not acceptable; I doubt there's a chance in hell
that TOMOYO will get merged as long as it has text-based-language
parsing in the kernel. You also have $NEW_RANDOM_ABUSE_OF_PROCFS and
$PATH_BASED_LSM_ISSUES. See the long flamewars on
On Tue, 2 Oct 2007 16:36:24 +0900 KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote:
On Tue, 2 Oct 2007 00:18:09 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
How come? Memoryless node can and do occur in real-world machines.
Kernel
should support that?
But a node is just
On Tue, Oct 02, 2007 at 09:37:03AM +0200, Ingo Molnar wrote:
* Andrew Morton [EMAIL PROTECTED] wrote:
On 02 Oct 2007 08:18:17 +0200 Andi Kleen [EMAIL PROTECTED] wrote:
The clockevents patches are not included in this; but given the
recent trouble i'm not 100% sure they are even
From: Jens Axboe [EMAIL PROTECTED]
Date: Tue, 2 Oct 2007 09:39:43 +0200
Hi,
The layout of struct blk_user_trace_setup is a bit unfortunate, it gets
padded differently on 32-bit and 64-bit archs. So right now it's not
possible to trace 64-bit kernels with a 32-bit app. This patch fixes
that
On Mon, 2007-10-01 at 23:29 -0700, Jeremy Fitzhardinge wrote:
Rusty Russell wrote:
That's good, but this code does lose on native because we no longer
simply replace the entire thing with noops.
Perhaps inverting this and having (inline) helpers is the way to go?
static inline void
On Tue, Oct 02, 2007 at 12:18:09AM -0700, Andrew Morton wrote:
If so, that might be OK - the app just needs a reliable way of working out
whether it's on a 32- or 64-bit kernel?
That would be ugly and a little error prone (would this case really be
tested in user space normally?) but
On Tue, 2 Oct 2007, Andi Kleen wrote:
On Tue, Oct 02, 2007 at 09:37:03AM +0200, Ingo Molnar wrote:
* Andrew Morton [EMAIL PROTECTED] wrote:
On 02 Oct 2007 08:18:17 +0200 Andi Kleen [EMAIL PROTECTED] wrote:
The clockevents patches are not included in this; but given the
Grumble. The options are:
a) export it in the kernel's native size and have userspace figure it
out
b) add a header
c) lie to 32-bit apps on 64-bit kernels
d) always export 32 bits
e) always export 64 bits
I started with (a), switched to (b), and then Alan and Dave convinced
me to
On 10/01/2007 11:22 PM, Andrew Morton wrote:
v4l-stk11xx-add-a-new-webcam-driver.patch
v4l-stk11xx-use-array_size-in-another-2-cases.patch
v4l-stk11xx-use-retval-from-stk11xx_check_device.patch
v4l-stk11xx-add-static-to-tables.patch
No, hold it please, until v4l extension will be developped
Hi!
How do we know when little memory is available?
Kernel already scales its hash tables according to total RAM
available, perhaps you can use similar mechanism?
Other suggestion which came about was to parse the kernel command line
and look for elfcorehdr=. Is this ok? Is kernel command
On Mon, 2007-09-17 at 18:37 +, Pavel Machek wrote:
That's a bit tricky because hitting the keyboard is what unsticks things.
And the video is black after resume-from-RAM (has always been thus) and we
Ok, can we try to fix the video issue for you? That should make the
development
On Tue, Oct 02, 2007 at 04:31:48PM +0900, Kentaro Takeda wrote:
Common functions for TOMOYO Linux.
TOMOYO Linux uses /sys/kernel/security/tomoyo interface for configuration.
This seems like a bit of an abuse of sysfs. Isn't this precisely what
configfs is for?
-
To unsubscribe from this
Huh, Cc back lkml.
On 10/02/2007 10:08 AM, Jiri Slaby wrote:
On 10/01/2007 11:22 PM, Andrew Morton wrote:
git-net-vs-git-wireless.patch
Hum, latest wireless-2.6?h=everything already had a proper fix when this patch
was merged. But pull/push is stuck somewhere :(.
On 01/10/2007, Kok, Auke [EMAIL PROTECTED] wrote:
...
is this actually a problem? everybody should be running e100. I'm surprised
to see
a patch for eepro100, just before it gets removed...
The patch is actually about a year old, it just never got merged. And
IMHO, as long as the driver is
On Tue, 2 Oct 2007 00:43:24 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
On Tue, 2 Oct 2007 16:36:24 +0900 KAMEZAWA Hiroyuki [EMAIL PROTECTED]
Don't think so. A node is a lump of circuitry which can have zero or more
CPUs, IO and memory.
It may initially have been conceived as a
On Tuesday 02 October 2007, Jens Axboe wrote:
The layout of struct blk_user_trace_setup is a bit unfortunate, it gets
padded differently on 32-bit and 64-bit archs. So right now it's not
possible to trace 64-bit kernels with a 32-bit app. This patch fixes
that up by adding a compat ioctl
On Mon, 2007-10-01 at 14:22 -0700, Andrew Morton wrote:
nfs-remove-congestion_end.patch
lib-percpu_counter_add.patch
lib-percpu_counter_sub.patch
lib-percpu_counter-variable-batch.patch
lib-make-percpu_counter_add-take-s64.patch
lib-percpu_counter_set.patch
On Tue, Oct 02, 2007 at 10:17:05AM +0200, Peter Zijlstra wrote:
On Mon, 2007-10-01 at 14:22 -0700, Andrew Morton wrote:
nfs-remove-congestion_end.patch
lib-percpu_counter_add.patch
lib-percpu_counter_sub.patch
lib-percpu_counter-variable-batch.patch
On Tue, 02 Oct 2007 10:17:05 +0200 Peter Zijlstra [EMAIL PROTECTED] wrote:
On Mon, 2007-10-01 at 14:22 -0700, Andrew Morton wrote:
nfs-remove-congestion_end.patch
lib-percpu_counter_add.patch
lib-percpu_counter_sub.patch
lib-percpu_counter-variable-batch.patch
On Tue, Oct 02 2007, Arnd Bergmann wrote:
On Tuesday 02 October 2007, Jens Axboe wrote:
The layout of struct blk_user_trace_setup is a bit unfortunate, it gets
padded differently on 32-bit and 64-bit archs. So right now it's not
possible to trace 64-bit kernels with a 32-bit app. This
* Christoph Hellwig [EMAIL PROTECTED] [2007-10-02 10:14]:
On Sun, Sep 30, 2007 at 01:16:18AM -0700, Andrew Morton wrote:
reviewed the August thread from your version 1 submission and the message I
take away is that the code has been well-received and looks good when
considered on its own
On Mon, Oct 01, 2007 at 02:22:22PM -0700, Andrew Morton wrote:
[...]
writeback-fix-time-ordering-of-the-per-superblock-dirty-inode-lists.patch
writeback-fix-time-ordering-of-the-per-superblock-dirty-inode-lists-2.patch
writeback-fix-time-ordering-of-the-per-superblock-dirty-inode-lists-3.patch
Hernan Gustavo Solari wrote:
Tejun
netconsole, pritty nice debunging system... but (yes, there is always
a but) it does not get to run.
the method was well implemented, adding the acpi=off it sends the
information to the receiving machine (I can even see passing a
netconsole probing
On Tuesday 02 October 2007 2:10:22 am Pavel Machek wrote:
+swsusp.txt
+ - Goals, implementation, and usage of software suspend (ACPI S3)
But please delete (ACPI S3) remark. It is ACPI S4, if anything.
Pavel
I got that from
On Tue, 2007-10-02 at 01:31 -0700, Andrew Morton wrote:
On Tue, 02 Oct 2007 10:17:05 +0200 Peter Zijlstra [EMAIL PROTECTED] wrote:
On Mon, 2007-10-01 at 14:22 -0700, Andrew Morton wrote:
nfs-remove-congestion_end.patch
lib-percpu_counter_add.patch
lib-percpu_counter_sub.patch
On Mon, Oct 01, 2007 at 06:25:07PM +0200, Ingo Molnar wrote:
* Jarek Poplawski [EMAIL PROTECTED] wrote:
BTW, it looks like risky to criticise sched_yield too much: some
people can misinterpret such discussions and stop using this at all,
even where it's right.
Really, i have never
Revert the check_dirty_inode_list.patch.
I'm pretty sure the time ordering problem has gone.
Signed-off-by: Fengguang Wu [EMAIL PROTECTED]
---
fs/fs-writeback.c | 62
kernel/sysctl.c |8 -
2 files changed, 1 insertion(+), 69 deletions(-)
NTFS's if-condition on dirty inodes is not complete.
Fix it with sb_has_dirty_inodes().
Cc: Anton Altaparmakov [EMAIL PROTECTED]
Cc: Ken Chen [EMAIL PROTECTED]
Cc: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Fengguang Wu [EMAIL PROTECTED]
---
---
fs/fs-writeback.c | 10 +-
Andrew,
The following patches fix the sluggish writeback behavior.
They are well understood and well tested - but not yet widely tested.
The first patch reverts the debugging -mm only check_dirty_inode_list.patch -
which is no longer necessary.
The following 4 patches do the real jobs:
[PATCH
Miklos Szeredi [EMAIL PROTECTED] and me identified a writeback bug:
The following strange behavior can be observed:
1. large file is written
2. after 30 seconds, nr_dirty goes down by 1024
3. then for some time ( 30 sec) nothing happens (disk idle)
4. then nr_dirty again goes down by 1024
After making dirty a 100M file, the normal behavior is to
start the writeback for all data after 30s delays. But
sometimes the following happens instead:
- after 30s:~4M
- after 5s: ~4M
- after 5s: all remaining 92M
Some analyze shows that the internal io
Streamline the management of dirty inode lists and fix time ordering bugs.
The writeback logic used to moving not-yet-expired dirty inodes from s_dirty to
s_io, *only to* move them back. The move-inodes-back-and-forth thing is a mess,
which is eliminated by this patch.
The new scheme is:
-
Try setting features to 14. That helps my similar issues.
Hi Bill,
thanks, but unfortunately that didn't help,
with 2.6.23-rc8 it's already set to 29,
it happens with 2.6.23-rc8 with the new scheduler
what I found out so far:
it definitely is using 3D acceleration:
glxgears -info
Alexander Sabourenkov schrieb:
Have you checked your memory already (memtest86)?
[...]
Again... sounds like bad memory to me.
Nightly memtest86 run : 11 hours, 23 passes, 0 errors.
Okay, I have no idea about any bugs there.
You have several options: Find a 100% working vanilla kernel for
In alternative_instructions(), call free_init_pages() with irqs enabled.
It fixes the warning message in smp_call_function*(), which should be called
with irqs disabled.
[0.31] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[0.31] CPU: L2 Cache: 512K (64
Hi!
+swsusp.txt
+ - Goals, implementation, and usage of software suspend (ACPI S3)
But please delete (ACPI S3) remark. It is ACPI S4, if anything.
Pavel
I got that from Documentation/power/video.txt, which starts Video
On Mon, 1 Oct 2007, Linus Torvalds wrote:
This is also a good time to warn about the fact that we're doing the x86
merge very soon (as in the next day or two) after 2.6.23 is out, so if you
have pending patches for the next series that touch arch/i386 or x86-64,
you should get in touch with
On Mon, 2007-10-01 at 14:30 -0700, Andrew Morton wrote:
On Mon, 1 Oct 2007 13:55:29 -0700 (PDT)
Christoph Lameter [EMAIL PROTECTED] wrote:
On Sat, 29 Sep 2007, Andrew Morton wrote:
atomic allocations. And with SLUB using higher order pages, atomic !0
order allocations will be very
Hello,
Mark Lord wrote:
Mmm.. $66 for open box. But the drive itself has been discontinued by
Seagate,
Couldn't find any in SUSE and I don't think I can't find any vendor who
still carries the drive here.
and once claimed to be World's first SATA desktop drive with NCQ..
Probably buggy
On Tuesday 02 October 2007 11:17:02 Thomas Gleixner wrote:
This is also a good time to warn about the fact that we're doing the x86
merge very soon (as in the next day or two) after 2.6.23 is out, so if you
have pending patches for the next series that touch arch/i386 or x86-64,
you
On Mon, Oct 01, 2007 at 10:43:56AM +0200, Jarek Poplawski wrote:
...
etc., if we know (after testing) eg. average expedition time of such
No new theory - it's only my reverse Polish translation. Should be:
etc., if we know (after testing) eg. average dispatch time of such.
Sorry,
Jarek P.
-
To
Alexander Sabourenkov schrieb:
Hardware: Athlon64, Asus A8V, Promise SATA300 TX4, 2xSeagate 7200.10
320G, jumper-limited to SATA150.
Kernel : 2.6.22.9 amd64
Problem:
Heavy load causes errors and triggers oops.
History:
Problems were first encountered on kernel 2.6.19, both i686 (old
On Tue, Oct 02, 2007 at 09:01:10AM +0200, Andi Kleen wrote:
x86_64-sparsemem_vmemmap-2m-page-size-support.patch
x86_64-sparsemem_vmemmap-vmemmap-x86_64-convert-to-new-helper-based-initialisation.patch
Look like these two should be merged together
Also I'm concerned about a third
Hi Arnd,
Updated patch below. I kept the code in compat_ioctl.c, to me it seems
like the cleanest approach. I need the BLKTRACESETUP32 define both in
compat_ioctl.c and blktrace.c if I move it, and I need to hard-core the
struct size or define it in both places. And guard the code in
blktrace.c
On Monday 01 October 2007 20:04, Davide Libenzi wrote:
They don't even need to read in parallel, just having shared fd is enough.
Think about pipes, sockets and terminals. A real-world scenario:
* a process started from shell (interactive or shell script)
* it sets O_NONBLOCK and does a
Hi!
...should they be changed to 200? Or perhaps file should be readable?
No, mode 644 is fine. No reason to prevent other people from
reading the alarm time (is there?) and if you write a legal value,
that will work. So $SUBJECT is no problem at all.
Yep, agreed. I was confused by
Hi!
Venki sent me an initial patch, but it has issues with the notify
ordering. Find below my cache the broadcast flags version for testing.
Hmmpf, the flag is still cleared when the cpu goes offline. Need to take
a closer look.
I finally tracked it down. There were several ways
Clemens Koller wrote:
Okay, I have no idea about any bugs there.
You have several options: Find a 100% working vanilla kernel for your
problem (minimal configuration, skip i.e. the sound stuff, ...).
And then git bisect with a known bad kernel.
I'm afraid there is no 100% working kernel.
diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
index 0079b2c..d8fb795 100644
--- a/fs/ext2/inode.c
+++ b/fs/ext2/inode.c
...
+
+ raw_inode = ext2_get_inode(inode-i_sb, ino, bh);
if (IS_ERR(raw_inode))
goto bad_inode;
Hmm, why don't you use the return value from
On Tue, 2 October 2007 07:18:52 +0200, Ingo Molnar wrote:
ah, this is even nicer than the raw_printk() thing i suggested, and it
also nicely documents the intention of the author. Patch attached below.
KERN_CONT was brought up in the linux-tiny discussion. Not sure if you
want to get
diff --git a/fs/ext3/ialloc.c b/fs/ext3/ialloc.c
index e45dbd6..c2f0a0d 100644
--- a/fs/ext3/ialloc.c
+++ b/fs/ext3/ialloc.c
@@ -646,7 +646,7 @@ struct inode *ext3_orphan_get(struct super_block *sb,
unsigned long ino)
unsigned long block_group;
int bit;
struct
On Mon, 1 Oct 2007, Cedric Le Goater wrote:
got it !
r3-06.test.meiosys.com login: WARNING: at
/home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314
tcp_fastretrans_alert()
Call Trace:
IRQ [8040fdc3] tcp_ack+0xcd6/0x18af
[...snip...]
TCP 0
Hmm, so it's SACK
And one more thing...
diff --git a/fs/ext3/ialloc.c b/fs/ext3/ialloc.c
index e45dbd6..c2f0a0d 100644
--- a/fs/ext3/ialloc.c
+++ b/fs/ext3/ialloc.c
@@ -646,7 +646,7 @@ struct inode *ext3_orphan_get(struct super_block *sb,
unsigned long ino)
unsigned long block_group;
int
On 10/2/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
On Tue, 2007-10-02 at 01:31 -0700, Andrew Morton wrote:
On Tue, 02 Oct 2007 10:17:05 +0200 Peter Zijlstra [EMAIL PROTECTED] wrote:
On Mon, 2007-10-01 at 14:22 -0700, Andrew Morton wrote:
nfs-remove-congestion_end.patch
It seems that patches 1-3 are missing.
I'd also suggest making all of the patches a reply to the first email, so
they can be threaded.
- James
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Andi Kleen wrote:
On Tuesday 02 October 2007 11:17:02 Thomas Gleixner wrote:
This is also a good time to warn about the fact that we're doing the x86
merge very soon (as in the next day or two) after 2.6.23 is out, so if you
have pending patches for the next series that touch arch/i386 or
netconsole, pritty nice debunging system... but (yes, there is always
a but) it does not get to run.
the method was well implemented, adding the acpi=off it sends the
information to the receiving machine (I can even see passing a
netconsole probing message in the machine under testing), but
On Tue, 2007-10-02 at 12:31 +0200, Kay Sievers wrote:
What would be the point in another top-level tree for device
information? All devices you are exporting information for, are
already in the sysfs tree, right?
Never did find NFS mounts/servers/superblocks or whatever constitutes a
BDI for
Signed-off-by: Dmitry Baryshkov [EMAIL PROTECTED]
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index ae98818..c70a87d 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -38,6 +38,7 @@
#include linux/times.h
#include linux/net.h
#include linux/in.h
+#include linux/igmp.h
#include
On Tue, Oct 02, 2007 at 12:44:21PM +0200, Peter Zijlstra wrote:
On Tue, 2007-10-02 at 12:31 +0200, Kay Sievers wrote:
What would be the point in another top-level tree for device
information? All devices you are exporting information for, are
already in the sysfs tree, right?
Never did
On Tuesday 02 October 2007 12:37:55 Jeff Garzik wrote:
Andi Kleen wrote:
On Tuesday 02 October 2007 11:17:02 Thomas Gleixner wrote:
This is also a good time to warn about the fact that we're doing the x86
merge very soon (as in the next day or two) after 2.6.23 is out, so if
you
have
Greetings everybody;
After seeing a message indicating that rc8 no longer did a powerdown, I
thought I'd check that since I needed to, my tv card wasn't even showing up
in the lspci report. It was partially backed out of the pci slot, this case
seems to encourage that.
Indeed it went to the
On Tue, 2 Oct 2007 00:43:24 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
On Tue, 2 Oct 2007 16:36:24 +0900 KAMEZAWA Hiroyuki [EMAIL PROTECTED]
Don't think so. A node is a lump of circuitry which can have zero or
more
CPUs, IO and memory.
It may initially have been
It seems that patches 1-3 are missing.
I'd also suggest making all of the patches a reply to the first email, so
they can be threaded.
Thanks a lot for your suggestions.
Actually we did just as you wrote, but somehow 0-3 parts are missing.
Unfortunately, the parent message [00/15] is in
1 - 100 of 860 matches
Mail list logo
