Re: [PATCH -mm] Revoke core code: fix nommu arch compiling error bug
On Tue, 27 Mar 2007, Wu, Bryan wrote: > Agree. MPU of Blackfin can provide some processes protection. But maybe > at this moment just disable revoke for NOMMU is easier for further > development. When we provide the MPU stuff, maybe we can enable the > revoke for NOMMU but MPU arch. Yeah, MPU should be sufficient for revoke(). Note that mmap() and mummap() suffers from the same problem on NOMMU so perhaps we really should do CONFIG_MPU. Pekka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch resend v4] update ctime and mtime for mmaped write
> > > > This patch makes writing to shared memory mappings update st_ctime and > > > > st_mtime as defined by SUSv3: > > > > > > Boy this is complicated. > > > > You tell me? > > > > > Is there a simpler way of doing all this? Say, we define a new page flag > > > PG_dirtiedbywrite and we do SetPageDirtiedByWrite() inside write() and > > > ClearPageDirtiedByWrite() whenever we propagate pte-dirtiness into > > > page-dirtiness. Then, when performing writeback we look to see if any of > > > the dirty pages are !PageDirtiedByWrite() and, if so, we update [mc]time > > > to > > > current-time. > > > > I don't think a page flag gains anything over the address_space flag > > that this patch already has. > > > > The complexity is not about keeping track of the "data modified > > through mmap" state, but about msync() guarantees, that POSIX wants. > > > > And these requirements do in fact make some sense: msync() basically > > means: > > > > "I want the data written through mmaps to be visible to the world" > > > > And that obviously includes updating the timestamps. > > > > So how do we know if the data was modified between two msync() > > invocations? The only sane way I can think of is to walk the page > > tables in msync() and test/clear the pte dirty bit. > > clear_page_dirty_for_io() already does that. > > So we should be able to test PageDirtiedByWrite() after running > clear_page_dirty_for_io() to discover whether this page was dirtied via > MAP_SHARED, and then update the inode times if so. What do you need the page flag for? The "modified through mmap" info is there in the ptes. And from the ptes it can be transfered to a per-address_space flag. Nobody is interested through which page was the file modified. Anyway, that's just MS_SYNC. MS_ASYNC doesn't walk the pages, yet it should update the timestamp. That's the difficult one. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
looking to reach chiropractors?
Just completed - 100,000 American Chiropractor's Offices FIELDS: Office Name, Full Address, Phone, Fax, Email and Website Special Promotional Price: $199 (valid until March 30) contact [EMAIL PROTECTED] for more info. For exclusion from future emails please send an email with "exclude" in the subject - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH]: Fix bogus softlockup warning with sysrq-t
> I could easy add a "global disable" function, which would allow long > sysrq messages, and it would help Thilo with his long flash update freezes. A "global disable" and "reenable" functions pair which works during irq disabled, would be a perfect solution for me. Thx Jeremy for your effort :) Ciao Thilo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
About Linux Socket Filter
Hi: I am writing a socket filter program and using "tcpdump -dd vlan and arp" to filter out the arp packet whose protocol field is 8100(vlan). Everything is fine if I call recvfrom to receive the packet. However, if I open two packet socket in parallel (and use the select to demultiplex among them, then the program will sacrifice the arp protocol handling! My program get arp request/reply as usual, but the kernel cannot get any arp request anymore. And the linux kernel no longer receives any packet if I flush the arp table since kernel cannot get arp request. I insert debug information (printk) next to the ptype handling loop, netif_receive_skb (ret = pt_prev->func(skb, skb->dev, pt_prev)), and the kernel exactly print out the information. Does that mean the packet is exactly inserted into the queue of the socket and kernel path returns to the processing loop? How could user space program steal the packet? (Note that the two interface involved are the member of the bridge, but I think the ptype looping is after the handle bridge and should not sacrifice the arp handling.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix race between attach_task and cpuset_exit
Quoting Paul Jackson <[EMAIL PROTECTED]>: vatsa wrote: Well, someone may have attached to this cpuset while we were waiting on the mutex_lock(). So we need to do a atomic_read again to ensure it is still unused. I don't see how this could happen. If we hold the task lock that now (thanks to your good work) guards this pointer, and if we decrement to zero the reference count on the cpuset to which it points and then -overwrite- this last remaining visible pointer to that cpuset with a pointer to a different cpuset, then aren't we guaranteed to be holding the last remaining reference to the old cpuset in our local variable, making it impossible for anyone else to attach to it in any way? Yes, but the cpuset is not made invisible to userspace (in filesystem) yet. So as cpuset_exit() discovers that cpuset B has zero refcount now and blocks on mutex_lock(_mutex) [ to do a check_for_release later ], someone could have done a attach_task to that cpuset. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: forced umount?
On Mon, 26 Mar 2007, Phillip Susi wrote: > Is this revoke system supported for the filesystem as a whole? I thought it > was just to force specific files closed, not the whole filesystem. What if > the filesystem itself has pending IO to say, update inodes or block bitmaps? > Can these be aborted? We never want to _abort_ pending updates only pending reads. So, even with revoke(), we need to be careful which is why we do do_fsync() in generic_revoke_file() to make sure pending updates are flushed before we declare the inode revoked. But, I haven't looked at forced unmount that much so there may be other issues I am not aware of. Pekka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21-rc5
On Mon, Mar 26, 2007 at 10:17:31PM -0800, Andrew Morton wrote: > > I have a few fixes here which belong to subsystem trees, which were missed > by the maintainers and which we probably want to get into 2.6.21. > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/pci-set-pci=bfsort-for-poweredge-r900.patch Already in Linus's tree. > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/fix-sysfs-rom-file-creation-for-bios-rom-shadows.patch I'd prefer to wait until 2.6.22 for this one, I've had too many odd reports of problems in this area, and since no one has reported this issue, it's not a real rush at all. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fbdev sysfs imrovements
On Tue, 27 Mar 2007 16:14:21 +1000 Paul Mackerras <[EMAIL PROTECTED]> wrote: > Andrew Morton writes: > > > http://userweb.kernel.org/~akpm/s5000489.jpg (the oops is the usual powerpc > > mess) > > Why do you have xmon enabled if you don't have any way to talk to it? > gawd knows - I've been dragging that config along for over a year. Maybe I subconsciously like seeing the mess it makes? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm1
From: Andrew Morton <[EMAIL PROTECTED]> Date: Mon, 26 Mar 2007 20:57:06 -0800 > - I dropped davem's net development tree due to a large collision with > git-wireless. I figured git-wireless would need more debugging ;) I sent some email to John Linville in order to discuss ways to resolve this so you can import all of our work. I believe John is away for a few days so whenever he gets back to reading email we'll work this out. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21-rc5
I have a few fixes here which belong to subsystem trees, which were missed by the maintainers and which we probably want to get into 2.6.21. ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/make-aout-executables-work-again.patch ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/revert-ac97-fix-microphone-and-line_in-selection-logic.patch ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/drivers-mfd-sm501c-fix-an-off-by-one.patch ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/pci-set-pci=bfsort-for-poweredge-r900.patch ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/fix-sudden-warps-in-mousedev.patch ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/fix-sysfs-rom-file-creation-for-bios-rom-shadows.patch Maintainers are cc'ed. Please promptly ack, nack or otherwise quack, else I'll be making my own decisions ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fbdev sysfs imrovements
Andrew Morton writes: > http://userweb.kernel.org/~akpm/s5000489.jpg (the oops is the usual powerpc > mess) Why do you have xmon enabled if you don't have any way to talk to it? Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why is NCQ enabled by default by libata? (2.6.20)
Justin Piszcz wrote: Without NCQ, performance is MUCH better on almost every operation, with the exception of 2-3 items. Variables to take into account: * the drive (NCQ performance wildly varies) * the IO scheduler * the filesystem (if not measuring direct to blkdev) * application workload (or in your case, benchmark tool) * in particular, the threaded-ness of the apps For the overwhelming majority of combinations, NCQ should not /hurt/ performance. For the majority of combinations, NCQ helps (though it may not be often that you use more than 4-8 tags). In some cases, NCQ firmware may be broken. There is a Maxtor firmware id, and some Hitachi ids that people are leaning towards recommending be added to the libata 'horkage' list. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ATA ACPI (was Re: Linux 2.6.21-rc5)
Jeff Garzik wrote: Linus Torvalds wrote: There's various fixes here, ranging from some architecture updates (ia64, ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers. And random one-liners. But probably more important, and likely much more visible to most people is the fixes for the fallout from the hrtimers and no-HZ changes, and some of the ACPI regressions. Those timer changes ended up much more painful than anybody wished for, but big thanks to Thomas Gleixner for being on it like a weasel on a dead rat, and the regression list has kept shrinking. So if you have reported a regression in the 2.6.21-rc series, please check 2.6.21-rc5, and update your report as appropriate (whether fixed or "still problems with xyzzy"). Linus [just got back from vacation, or would have sent this earlier] FWIW, I'm still leaning towards disabling libata ACPI support by default for 2.6.21. Upstream has Alan's fix for the worst PATA problems, but for different reasons, I think PATA ACPI and SATA ACPI support in libata does not feel quite ready for prime time in 2.6.21. Scream now, or hold your peace until 2.6.22... :) I second disabling ACPI for 2.6.21. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ATA ACPI (was Re: Linux 2.6.21-rc5)
Linus Torvalds wrote: There's various fixes here, ranging from some architecture updates (ia64, ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers. And random one-liners. But probably more important, and likely much more visible to most people is the fixes for the fallout from the hrtimers and no-HZ changes, and some of the ACPI regressions. Those timer changes ended up much more painful than anybody wished for, but big thanks to Thomas Gleixner for being on it like a weasel on a dead rat, and the regression list has kept shrinking. So if you have reported a regression in the 2.6.21-rc series, please check 2.6.21-rc5, and update your report as appropriate (whether fixed or "still problems with xyzzy"). Linus [just got back from vacation, or would have sent this earlier] FWIW, I'm still leaning towards disabling libata ACPI support by default for 2.6.21. Upstream has Alan's fix for the worst PATA problems, but for different reasons, I think PATA ACPI and SATA ACPI support in libata does not feel quite ready for prime time in 2.6.21. Scream now, or hold your peace until 2.6.22... :) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2/2] percpu enable flag for softlockup watchdog
On a NO_HZ system, there may be an arbitrarily long delay between
ticks on a CPU. When we're disabling ticks for a CPU, also disable
the softlockup watchdog timer.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PROTECTED]>
Cc: john stultz <[EMAIL PROTECTED]>
Cc: Zachary Amsden <[EMAIL PROTECTED]>
Cc: James Morris <[EMAIL PROTECTED]>
Cc: Dan Hecht <[EMAIL PROTECTED]>
Cc: Paul Mackerras <[EMAIL PROTECTED]>
Cc: Martin Schwidefsky <[EMAIL PROTECTED]>
---
include/linux/sched.h|8
kernel/softlockup.c | 23 +++
kernel/time/tick-sched.c | 34 +++---
3 files changed, 42 insertions(+), 23 deletions(-)
===
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -232,10 +232,18 @@ extern void scheduler_tick(void);
#ifdef CONFIG_DETECT_SOFTLOCKUP
extern void softlockup_tick(void);
+extern void softlockup_enable(void);
+extern void softlockup_disable(void);
extern void spawn_softlockup_task(void);
extern void touch_softlockup_watchdog(void);
#else
static inline void softlockup_tick(void)
+{
+}
+static inline void softlockup_enable(void)
+{
+}
+static inline void softlockup_disable(void)
{
}
static inline void spawn_softlockup_task(void)
===
--- a/kernel/softlockup.c
+++ b/kernel/softlockup.c
@@ -20,6 +20,7 @@ static DEFINE_PER_CPU(unsigned long long
static DEFINE_PER_CPU(unsigned long long, touch_timestamp);
static DEFINE_PER_CPU(unsigned long long, print_timestamp);
static DEFINE_PER_CPU(struct task_struct *, watchdog_task);
+static DEFINE_PER_CPU(int, enabled);
static int did_panic = 0;
@@ -41,6 +42,18 @@ void touch_softlockup_watchdog(void)
}
EXPORT_SYMBOL(touch_softlockup_watchdog);
+void softlockup_enable(void)
+{
+ touch_softlockup_watchdog();
+ wmb(); /* update timestamp before enable */
+ __get_cpu_var(enabled) = 1;
+}
+
+void softlockup_disable(void)
+{
+ __get_cpu_var(enabled) = 0;
+}
+
/*
* This callback runs from the timer interrupt, and checks
* whether the watchdog thread has hung or not:
@@ -51,8 +64,8 @@ void softlockup_tick(void)
unsigned long long touch_timestamp = per_cpu(touch_timestamp, this_cpu);
unsigned long long now;
- /* watchdog task hasn't updated timestamp yet */
- if (touch_timestamp == 0)
+ /* return if not enabled */
+ if (!__get_cpu_var(enabled))
return;
/* report at most once a second */
@@ -95,8 +108,8 @@ static int watchdog(void * __bind_cpu)
sched_setscheduler(current, SCHED_FIFO, );
current->flags |= PF_NOFREEZE;
- /* initialize timestamp */
- touch_softlockup_watchdog();
+ /* enable on this cpu */
+ softlockup_enable();
/*
* Run briefly once per second to reset the softlockup timestamp.
@@ -109,6 +122,8 @@ static int watchdog(void * __bind_cpu)
touch_softlockup_watchdog();
schedule();
}
+
+ softlockup_disable();
return 0;
}
===
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -228,6 +228,8 @@ void tick_nohz_stop_sched_tick(void)
ts->idle_tick = ts->sched_timer.expires;
ts->tick_stopped = 1;
ts->idle_jiffies = last_jiffies;
+
+ softlockup_disable();
}
/*
* calculate the expiry time for the next timer wheel
@@ -255,6 +257,7 @@ void tick_nohz_stop_sched_tick(void)
cpu_clear(cpu, nohz_cpu_mask);
}
raise_softirq_irqoff(TIMER_SOFTIRQ);
+
out:
ts->next_jiffies = next_jiffies;
ts->last_jiffies = last_jiffies;
@@ -311,6 +314,8 @@ void tick_nohz_restart_sched_tick(void)
ts->tick_stopped = 0;
hrtimer_cancel(>sched_timer);
ts->sched_timer.expires = ts->idle_tick;
+
+ softlockup_enable();
while (1) {
/* Forward the time to expire in the future */
@@ -355,17 +360,12 @@ static void tick_nohz_handler(struct clo
tick_do_update_jiffies64(now);
/*
-* When we are idle and the tick is stopped, we have to touch
-* the watchdog as we might not schedule for a really long
-* time. This happens on complete idle SMP systems while
-* waiting on the login prompt. We also increment the "start
-* of idle" jiffy stamp so the idle accounting adjustment we
-* do when we go busy again does not account too much ticks.
-*/
- if (ts->tick_stopped) {
- touch_softlockup_watchdog();
+* Increment the "start of idle" jiffy stamp so the idle
+* accounting adjustment
[patch 0/2] softlockup watchdog improvements
Here's couple of patches to improve the softlockup watchdog. The first changes the softlockup timer from using jiffies to sched_clock() as a timebase. Xen and VMI implement sched_clock() as counting unstolen time, so time stolen by the hypervisor won't cause the watchdog to bite. The second adds per-cpu enable flags for the watchdog timer. This allows the timer to be disabled when the CPU goes into a (potentially unbounded) tickless sleep. I know this conflicts with fix-bogus-softlockup-warning-with-sysrq-t.patch in -mm2. I think that patch incorrectly changes the behaviour of the softlockup watchdog, and a better solution is to temporarily disable the watchdog while doing something known to be cpu-consuming, like a long sysreq output. J -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/2] Ignore stolen time in the softlockup watchdog
The softlockup watchdog is currently a nuisance in a virtual machine,
since the whole system could have the CPU stolen from it for a long
period of time. While it would be unlikely for a guest domain to be
denied timer interrupts for over 10s, it could happen and any softlockup
message would be completely spurious.
Earlier I proposed that sched_clock() return time in unstolen
nanoseconds, which is how Xen and VMI currently implement it. If the
softlockup watchdog uses sched_clock() to measure time, it would
automatically ignore stolen time, and therefore only report when the
guest itself locked up. When running native, sched_clock() returns
real-time nanoseconds, so the behaviour would be unchanged.
Note that sched_clock() used this way is inherently per-cpu, so this
patch makes sure that the per-processor watchdog thread initialized
its own timestamp.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PROTECTED]>
Cc: john stultz <[EMAIL PROTECTED]>
Cc: Zachary Amsden <[EMAIL PROTECTED]>
Cc: James Morris <[EMAIL PROTECTED]>
Cc: Dan Hecht <[EMAIL PROTECTED]>
Cc: Paul Mackerras <[EMAIL PROTECTED]>
Cc: Martin Schwidefsky <[EMAIL PROTECTED]>
Cc: Prarit Bhargava <[EMAIL PROTECTED]>
Cc: Chris Lalancette <[EMAIL PROTECTED]>
Cc: Rick Lindsley <[EMAIL PROTECTED]>
---
kernel/softlockup.c | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
===
--- a/kernel/softlockup.c
+++ b/kernel/softlockup.c
@@ -17,8 +17,8 @@
static DEFINE_SPINLOCK(print_lock);
-static DEFINE_PER_CPU(unsigned long, touch_timestamp);
-static DEFINE_PER_CPU(unsigned long, print_timestamp);
+static DEFINE_PER_CPU(unsigned long long, touch_timestamp);
+static DEFINE_PER_CPU(unsigned long long, print_timestamp);
static DEFINE_PER_CPU(struct task_struct *, watchdog_task);
static int did_panic = 0;
@@ -37,7 +37,7 @@ static struct notifier_block panic_block
void touch_softlockup_watchdog(void)
{
- __raw_get_cpu_var(touch_timestamp) = jiffies;
+ __raw_get_cpu_var(touch_timestamp) = sched_clock();
}
EXPORT_SYMBOL(touch_softlockup_watchdog);
@@ -48,10 +48,15 @@ void softlockup_tick(void)
void softlockup_tick(void)
{
int this_cpu = smp_processor_id();
- unsigned long touch_timestamp = per_cpu(touch_timestamp, this_cpu);
+ unsigned long long touch_timestamp = per_cpu(touch_timestamp, this_cpu);
+ unsigned long long now;
- /* prevent double reports: */
- if (per_cpu(print_timestamp, this_cpu) == touch_timestamp ||
+ /* watchdog task hasn't updated timestamp yet */
+ if (touch_timestamp == 0)
+ return;
+
+ /* report at most once a second */
+ if (per_cpu(print_timestamp, this_cpu) < (touch_timestamp +
NSEC_PER_SEC) ||
did_panic ||
!per_cpu(watchdog_task, this_cpu))
return;
@@ -62,12 +67,14 @@ void softlockup_tick(void)
return;
}
+ now = sched_clock();
+
/* Wake up the high-prio watchdog task every second: */
- if (time_after(jiffies, touch_timestamp + HZ))
+ if (now > (touch_timestamp + NSEC_PER_SEC))
wake_up_process(per_cpu(watchdog_task, this_cpu));
/* Warn about unreasonable 10+ seconds delays: */
- if (time_after(jiffies, touch_timestamp + 10*HZ)) {
+ if (now > (touch_timestamp + 10ull*NSEC_PER_SEC)) {
per_cpu(print_timestamp, this_cpu) = touch_timestamp;
spin_lock(_lock);
@@ -87,6 +94,9 @@ static int watchdog(void * __bind_cpu)
sched_setscheduler(current, SCHED_FIFO, );
current->flags |= PF_NOFREEZE;
+
+ /* initialize timestamp */
+ touch_softlockup_watchdog();
/*
* Run briefly once per second to reset the softlockup timestamp.
@@ -120,7 +130,7 @@ cpu_callback(struct notifier_block *nfb,
printk("watchdog for %i failed\n", hotcpu);
return NOTIFY_BAD;
}
- per_cpu(touch_timestamp, hotcpu) = jiffies;
+ per_cpu(touch_timestamp, hotcpu) = 0;
per_cpu(watchdog_task, hotcpu) = p;
kthread_bind(p, hotcpu);
break;
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: Fix bogus softlockup warning with sysrq-t
Prarit Bhargava wrote: > There are some situations when soft lockup warnings are expected in the > kernel. For example, when doing an alt-sysrq-t on a large number of > processes, > the dump to console can take a long time and the tasklist_lock is held over > that period. This results in a bogus soft lockup warning. > Wouldn't it be better to just temporarily disable softlockups for the duration? > This patch reworks touch_softlockup_watchdog to touch ALL cpu's > touch_timestamp. It also introduces touch_cpu_softlockup_watchdog to touch > a single cpu's touch_timestamp. Doesn't this mean that if one CPU gets locked up, it will be undetected so long as some other CPU is making progress? I have another pair of softlockup patches in which I try to address: * ignoring time stolen by hypervisors * threads going to sleep tickless for long periods of time I could easy add a "global disable" function, which would allow long sysrq messages, and it would help Thilo with his long flash update freezes. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] Blackfin arch: add kdebug header file
On Mon, 2007-03-26 at 22:27 -0700, Randy Dunlap wrote: > On Tue, 27 Mar 2007 01:17:06 -0400 Mike Frysinger wrote: > > > On 3/27/07, Paul Mundt <[EMAIL PROTECTED]> wrote: > > > On Tue, Mar 27, 2007 at 12:34:25AM -0400, Mike Frysinger wrote: > > > > On 3/26/07, Paul Mundt <[EMAIL PROTECTED]> wrote: > > > > >You should really consider the latter for getting updates merged in the > > > > >future > > > > > > > > we're planning for this, but the short term it isnt doable for us > > > > > > If you think mangling patches by hand is a more effective use of time, no > > > one is stopping you -- some people even prefer that. On the other hand, if > > > you're struggling with an effective methodology before things are merged, > > > what reason is there to suspect that things will get better afterwards? > > > > we have a lot of infrastructure that the SCM is part of and at the > > moment, git is not a supported SCM > > > > i'm not saying the current system is easy, just that we cant integrate > > git in the short term, so we'll continue spanking Bryan with the > > overhead :/ > > In that case, Bryan may like to know that git, mercurial (IIRC), > and quilt have patchbomb tools. Also GregKH has one somewhere (he > can tell you where). And Paul Jacksone has one at > http://www.speakeasy.org/~pj99/sgi/sendpatchset > Thanks for this guide line information. I will dig into it. But in my experience, it is difficult to find right patch email receivers, even in the MAINTAINERS file. If there are 20 patch emails, we should find 20 email receivers at least and manually add them to the emails. This is terrible, right? Any idea? Best Regards, -Bryan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] Blackfin arch: add kdebug header file
On Tue, 2007-03-27 at 01:17 -0400, Mike Frysinger wrote: > On 3/27/07, Paul Mundt <[EMAIL PROTECTED]> wrote: > > On Tue, Mar 27, 2007 at 12:34:25AM -0400, Mike Frysinger wrote: > > > On 3/26/07, Paul Mundt <[EMAIL PROTECTED]> wrote: > > > >You should really consider the latter for getting updates merged in the > > > >future > > > > > > we're planning for this, but the short term it isnt doable for us > > > > If you think mangling patches by hand is a more effective use of time, no > > one is stopping you -- some people even prefer that. On the other hand, if > > you're struggling with an effective methodology before things are merged, > > what reason is there to suspect that things will get better afterwards? > > we have a lot of infrastructure that the SCM is part of and at the > moment, git is not a supported SCM > I hope git will one of it. You know, with git kernel development will be much easier. > i'm not saying the current system is easy, just that we cant integrate > git in the short term, so we'll continue spanking Bryan with the > overhead :/ Cool, That's my duty. -Bryan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] Blackfin arch: add kdebug header file
On Tue, 27 Mar 2007 01:17:06 -0400 Mike Frysinger wrote: > On 3/27/07, Paul Mundt <[EMAIL PROTECTED]> wrote: > > On Tue, Mar 27, 2007 at 12:34:25AM -0400, Mike Frysinger wrote: > > > On 3/26/07, Paul Mundt <[EMAIL PROTECTED]> wrote: > > > >You should really consider the latter for getting updates merged in the > > > >future > > > > > > we're planning for this, but the short term it isnt doable for us > > > > If you think mangling patches by hand is a more effective use of time, no > > one is stopping you -- some people even prefer that. On the other hand, if > > you're struggling with an effective methodology before things are merged, > > what reason is there to suspect that things will get better afterwards? > > we have a lot of infrastructure that the SCM is part of and at the > moment, git is not a supported SCM > > i'm not saying the current system is easy, just that we cant integrate > git in the short term, so we'll continue spanking Bryan with the > overhead :/ In that case, Bryan may like to know that git, mercurial (IIRC), and quilt have patchbomb tools. Also GregKH has one somewhere (he can tell you where). And Paul Jacksone has one at http://www.speakeasy.org/~pj99/sgi/sendpatchset --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC: 2.6.21 patch] let PCI_MSI depend on EXPERIMENTAL
Eric W. Biederman wrote: aka. Drivers have started supporting MSI, People have started using and testing MSI, and there has been MSI maintenance. People care. Agreed, well put. The most recent regressions involving MSI have been fixes propagating their way through the kernel, and I can't think of a one of them that was MSI specific. Just that the bug didn't happen to show up clearly without MSI enabled. Yep. So default it to off, although I suspect we are approaching the point where it would actually be safe to default it to on. We need a kernel release that doesn't have msi issues yet. Now that we are finally getting a handle on the MSI bumps-in-the-road, IMO it would be counterproductive to default it to 'off' now. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][ 3/5] sched: implement staircase deadline cpu scheduler
On Mon, 2007-03-26 at 20:47 -0800, Andrew Morton wrote: > Nobody puts the description of the fields _below_ those fields. There are also some instances of if (foo = bar()). Maybe someone who isn't buried in work (as you always are) can find time to review. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21-rc5-mm2
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/ - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU scheduler has been added. Boilerplate: - See the `hot-fixes' directory for any important updates to this patchset. - To fetch an -mm tree using git, use (for example) git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1 git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1 - -mm kernel commit activity can be reviewed by subscribing to the mm-commits mailing list. echo "subscribe mm-commits" | mail [EMAIL PROTECTED] - If you hit a bug in -mm and it is not obvious which patch caused it, it is most valuable if you can perform a bisection search to identify which patch introduced the bug. Instructions for this process are at http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt But beware that this process takes some time (around ten rebuilds and reboots), so consider reporting the bug first and if we cannot immediately identify the faulty patch, then perform the bisection search. - When reporting bugs, please try to Cc: the relevant maintainer and mailing list on any email. - When reporting bugs in this kernel via email, please also rewrite the email Subject: in some manner to reflect the nature of the bug. Some developers filter by Subject: when looking for messages to read. - Occasional snapshots of the -mm lineup are uploaded to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on the mm-commits list. Changes since 2.6.21-rc5-mm1: +sched-dont-renice-kernel-threads.patch +sched-remove-sleepavg-from-proc.patch +sched-implement-staircase-deadline-cpu-scheduler.patch +sched-remove-noninteractive-flag.patch +sched-document-sd-cpu-scheduler.patch scheduler-of-the-day. All 1082 patches: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/patch-series - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] Blackfin arch: add kdebug header file
On 3/27/07, Paul Mundt <[EMAIL PROTECTED]> wrote: On Tue, Mar 27, 2007 at 12:34:25AM -0400, Mike Frysinger wrote: > On 3/26/07, Paul Mundt <[EMAIL PROTECTED]> wrote: > >You should really consider the latter for getting updates merged in the > >future > > we're planning for this, but the short term it isnt doable for us If you think mangling patches by hand is a more effective use of time, no one is stopping you -- some people even prefer that. On the other hand, if you're struggling with an effective methodology before things are merged, what reason is there to suspect that things will get better afterwards? we have a lot of infrastructure that the SCM is part of and at the moment, git is not a supported SCM i'm not saying the current system is easy, just that we cant integrate git in the short term, so we'll continue spanking Bryan with the overhead :/ -mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] genirq: do not mask interrupts by default
> I missed that one ... thanks for not telling/CC'ing me and not fixing > powerpc :-( (I know, everybody is supposed to have the bandwidth to read > all of lkml... I don't). > > We need to audit all of our PICs to make sure they can deal with > disabling an already ack'ed interrupt, which isn't clear.. in fact, that > might cause some to lose it when re-enabling later on. This is a major > semantic change and now I just discover it while we are at -rc5 ! > > I'm concerned that quite a few PICs will not re-emit the interrupt once > re-enabled. Note that I'm not opposed to the change at all, I think it's a good idea, I'm just worried I'm discovering it a bit late and I've seen PICs broken in some many colorful ways that I'm a bit worried... Oh well... Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/7] Add IRQF_IRQPOLL_IRQ flag to allow irqpoll
On Tue, 27 Mar 2007 07:01:44 +0200 (CEST) Guennadi Liakhovetski <[EMAIL PROTECTED]> wrote: > On Sun, 25 Mar 2007, Bernhard Walle wrote: > > > * Guennadi Liakhovetski <[EMAIL PROTECTED]> [2007-03-24 00:21]: > > > On Fri, 23 Mar 2007, Bernhard Walle wrote: > > > > > > > * Guennadi Liakhovetski <[EMAIL PROTECTED]> [2007-03-23 23:15]: > > > > > On Fri, 23 Mar 2007, Bernhard Walle wrote: > > > > > > > > > > > irqpoll is broken on some architectures that don't use the IRQ 0 > > > > > > for the timer > > > > > > interrupt like IA64. This patch adds a IRQF_IRQPOLL_IRQ flag. > > > > > > > > > > emn, please, cannot we come up with a better name - one that doesn't > > > > > have > > > > > "IRQ" 3 (!) times in it?... > > > > > > > > Well, it was suggested by Andrew. What's your suggestion? > > > > > > Purely esthetically (ehm, am I saying that?...) your original suggestion > > > to use IRQF_IRQPOLL looks better to me. Or even IRQF_POLL, but, maybe, > > > it's a bit too much of a simplification. > > > > I personally don't care very much about the naming. So I think it's > > Andrews final decision ... > > Sure. And for him to have a better chance to do this, I'll fix his email > address too:-) > I don't think I went as daringly far as to suggest the full name, but I must admit that IRQF_IRQPOLL_IRQ is actually logical. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata-vsc broken on SGI Prism
Andrew Morton wrote: On Sat, 24 Mar 2007 10:17:24 +0100 Andreas Schwab <[EMAIL PROTECTED]> wrote: commit 7cbaa86b937b0b1fab95c159989f6a3c00bbcf78 Author: Dan Wolstenholme <[EMAIL PROTECTED]> Date: Tue Jan 9 05:59:21 2007 -0500 [libata] sata_vsc: support PCI MSI Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> It seems that little of that patch remains present in current mainline. An unfortunately illusion of further changes. The "turn MSI on" stuff is still here, but Tejun's cleanups made some of that housekeeping code go away. But, as Andreas was guessing, the problem here is the platform's MSI support, with this as an unfortunate symptom. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] genirq: do not mask interrupts by default
On Fri, 2007-02-16 at 17:59 +, Linux Kernel Mailing List wrote: > Gitweb: > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=76d2160147f43f982dfe881404cfde9fd0a9da21 > Commit: 76d2160147f43f982dfe881404cfde9fd0a9da21 > Parent: 1f2ea0837dbc263ce2a2512c4e73c83df68a6a55 > Author: Ingo Molnar <[EMAIL PROTECTED]> > AuthorDate: Fri Feb 16 01:28:24 2007 -0800 > Committer: Linus Torvalds <[EMAIL PROTECTED]> > CommitDate: Fri Feb 16 08:14:00 2007 -0800 > > [PATCH] genirq: do not mask interrupts by default > > Never mask interrupts immediately upon request. Disabling interrupts in > high-performance codepaths is rare, and on the other hand this change > could > recover lost edges (or even other types of lost interrupts) by > conservatively > only masking interrupts after they happen. (NOTE: with this change the > highlevel irq-disable code still soft-disables this IRQ line - and if > such an > interrupt happens then the IRQ flow handler keeps the IRQ masked.) > > Mark i8529A controllers as 'never loses an edge'. I missed that one ... thanks for not telling/CC'ing me and not fixing powerpc :-( (I know, everybody is supposed to have the bandwidth to read all of lkml... I don't). We need to audit all of our PICs to make sure they can deal with disabling an already ack'ed interrupt, which isn't clear.. in fact, that might cause some to lose it when re-enabling later on. This is a major semantic change and now I just discover it while we are at -rc5 ! I'm concerned that quite a few PICs will not re-emit the interrupt once re-enabled. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] scheduler: strange behavor with massive interactive processes
On Tue, 2007-03-27 at 10:34 +0900, Satoru Takeuchi wrote: > Hi Ingo and all, Hi, > When I was executing massive interactive processes, I found that some of them > occupy CPU time and the others hardly run. > > It seems that some of processes which occupy CPU time always has max effective > prio (default+5) and the others have max - 1. What happen here is... > > 1. If there are moderate number of max interactive processes, they can be > re-inserted into active queue without falling down its priority again and > again. > 2. In this case, the others seldom run, and can't get max effective priority > at next exhausting because scheduler considers them to sleep too long. > 3. Goto 1, OOPS! Ah, that's a new twist. Cool testcase. A mechanism which was put in specifically to prevent tasks from jumping straight to max interactive, and thus hurting truly interactive tasks, is starving these not truly interactive (but nothing says they couldn't be) tasks. One way to prevent this may be to do something very simple like (I did this here a while back) upon timeslice completion (or possibly better, round-robin interval [whenever]), promote a task from a lower priority queue. Tasks are then always crawling up the ladder, and _will_ be inserted into the stream no matter what is going on in the system. The lower the task's priority, the longer it takes to crawl up, but it will get there. I'll try this again, and see how it handles your testcase, and how it affects interactivity. There are many others ways of course, limiting queue runtime etc etc. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/7] Add IRQF_IRQPOLL_IRQ flag to allow irqpoll
On Sun, 25 Mar 2007, Bernhard Walle wrote: > * Guennadi Liakhovetski <[EMAIL PROTECTED]> [2007-03-24 00:21]: > > On Fri, 23 Mar 2007, Bernhard Walle wrote: > > > > > * Guennadi Liakhovetski <[EMAIL PROTECTED]> [2007-03-23 23:15]: > > > > On Fri, 23 Mar 2007, Bernhard Walle wrote: > > > > > > > > > irqpoll is broken on some architectures that don't use the IRQ 0 for > > > > > the timer > > > > > interrupt like IA64. This patch adds a IRQF_IRQPOLL_IRQ flag. > > > > > > > > emn, please, cannot we come up with a better name - one that doesn't > > > > have > > > > "IRQ" 3 (!) times in it?... > > > > > > Well, it was suggested by Andrew. What's your suggestion? > > > > Purely esthetically (ehm, am I saying that?...) your original suggestion > > to use IRQF_IRQPOLL looks better to me. Or even IRQF_POLL, but, maybe, > > it's a bit too much of a simplification. > > I personally don't care very much about the naming. So I think it's > Andrews final decision ... Sure. And for him to have a better chance to do this, I'll fix his email address too:-) Thanks Guennadi --- Guennadi Liakhovetski - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HPA patches
Matthew Garrett wrote: On Fri, Mar 23, 2007 at 07:13:21PM +, Alan Cox wrote: +static int ata_ignore_hpa = 0; +module_param_named(ignore_hpa, ata_ignore_hpa, int, 0644); +MODULE_PARM_DESC(ignore_hpa, "Ignore HPA (0=off 1=on)"); I'm not sure I like the language here. "Ignore HPA" appears to mean "Explicitly disable the HPA", which I guess is one interpretation of "ignore" - however, naively I'd expect "Ignore HPA" to mean "Don't touch the HPA" with the result that it would remain inaccessible to userspace. "ignore" sounds more appropriate to me. We're not just making it inaccessible, we are actively ignoring all traces of its existence everywhere, when that setting is enabled. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21-rc5-mm1
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm1/ - The RSDL CPU scheduler is dropped again. I'll do rc5-mm2 with it re-added. - You may see this: init/missing_syscalls.c:5:27: error: linux/compile.h: No such file or directory during compilation. It's probably a parallel-build bug in Sam's tree. Just type make again. - I dropped davem's net development tree due to a large collision with git-wireless. I figured git-wireless would need more debugging ;) - The IDE tree has been dropped because of a general mess against the recent IDE merge into mainline. I'll restore it when Bart fixes it up. Boilerplate: - See the `hot-fixes' directory for any important updates to this patchset. - To fetch an -mm tree using git, use (for example) git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1 git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1 - -mm kernel commit activity can be reviewed by subscribing to the mm-commits mailing list. echo "subscribe mm-commits" | mail [EMAIL PROTECTED] - If you hit a bug in -mm and it is not obvious which patch caused it, it is most valuable if you can perform a bisection search to identify which patch introduced the bug. Instructions for this process are at http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt But beware that this process takes some time (around ten rebuilds and reboots), so consider reporting the bug first and if we cannot immediately identify the faulty patch, then perform the bisection search. - When reporting bugs, please try to Cc: the relevant maintainer and mailing list on any email. - When reporting bugs in this kernel via email, please also rewrite the email Subject: in some manner to reflect the nature of the bug. Some developers filter by Subject: when looking for messages to read. - Occasional snapshots of the -mm lineup are uploaded to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on the mm-commits list. Changes since 2.6.21-rc4-mm1: origin.patch git-acpi.patch git-alsa.patch git-agpgart.patch git-arm.patch git-avr32.patch git-cpufreq.patch git-powerpc.patch git-drm.patch git-dvb.patch git-gfs2-nmw.patch git-hid.patch git-ia64.patch git-ieee1394.patch git-infiniband.patch git-input.patch git-kbuild.patch git-kvm.patch git-leds.patch git-libata-all.patch git-md-accel.patch git-mips.patch git-mmc.patch git-mtd.patch git-ubi.patch git-netdev-all.patch git-ioat.patch git-ocfs2.patch git-parisc.patch git-r8169.patch git-selinux.patch git-pciseg.patch git-s390.patch git-scsi-misc.patch git-scsi-rc-fixes.patch git-unionfs.patch git-watchdog.patch git-wireless.patch git-wireless-fixup.patch git-ipwireless_cs.patch git-gccbug.patch git trees -drivers-char-agp-convert-to-generic-boolean.patch -jdelvare-i2c-i2c-amd8111-missed-cleanup.patch -jdelvare-i2c-i2c-i801-restore-initial-state.patch -jdelvare-i2c-ds1374-check-for-workqueue-creation.patch -cxgb3-add-sw-lro-support.patch -8139too-fix-irq-problem-with-napi-netpoll.patch -div64_64-common-code.patch -allow-pktgen-to-work-with-loopback-devices.patch -remove-unused-header-file-drivers-net-wan-lmc-lmc_mediah.patch -smc-superio-chip-lpc47n227-not-identified-properly.patch -mpt-fusion-handle-pci-layer-error-on-resume.patch -mpt-fusion-handle-mpt_resume-failure-while-resuming.patch -fusion-kernel-doc-warning-fixes.patch -unionfs-sioq-not-__exit.patch -gregkh-usb-usb-fix-usb-serial-regression.patch -gregkh-usb-usb-two-more-device-ids-for-dm9601-usbnet-driver.patch -gregkh-usb-usb-razr-v3i-unusual_devs.patch -gregkh-usb-usb-necessary-update-for-mos7720-driver.patch -gregkh-usb-airprime-usb-id-for-novatel-ev620-mini-pci-e-card.patch -gregkh-usb-usb-fix-gadget-serial-response-on-usb_cdc_req_set_line_coding.patch -usb-serial-io_edgeport-convert-to-generic-boolean.patch -make-xfs-workqueues-nonfreezable.patch -uhci-fix-problem-caused-by-lack-of-terminating-qh.patch -blackfin-blackfin-i2c-driver-update-2.patch -remove-unused-header-file-arch-um-kernel-tt-include-mode_kern-tth.patch -complain-about-missing-system-calls.patch -complain-about-missing-system-calls-update.patch -ptrace-needs-proc_fs.patch Merged into mainline or a subsystem tree. +knfsd-allow-nfsd-readdir-to-return-64bit-cookies.patch +knfsd-nfsd4-fix-inheritance-flags-on-v4-ace-derived-from-posix-default-ace.patch +knfsd-nfsd4-demote-clientid-in-use-printk-to-a-dprintk.patch +knfsd-nfsd4-remove-superfluous-cancel_delayed_work-call.patch +md-allow-raid4-arrays-to-be-reshaped.patch +md-clear-the-congested_fn-when-stopping-a-raid5.patch +md-convert-compile-time-warnings-into-runtime-warnings.patch +generic_serial-fix-decoding-of-baud-rate.patch +correct-slow-acpi_pm-rating.patch +isdn-fix-bchannel_bh-call-from-isar_bh.patch +uml-fix-epoll.patch +tty-minor-merge-correction.patch
Re: [PATCH -mm] Blackfin arch: add kdebug header file
On Tue, Mar 27, 2007 at 12:34:25AM -0400, Mike Frysinger wrote: > On 3/26/07, Paul Mundt <[EMAIL PROTECTED]> wrote: > >You should really consider the latter for getting updates merged in the > >future > > we're planning for this, but the short term it isnt doable for us > If you think mangling patches by hand is a more effective use of time, no one is stopping you -- some people even prefer that. On the other hand, if you're struggling with an effective methodology before things are merged, what reason is there to suspect that things will get better afterwards? Going by Bryan's post, it's clear that the current system isn't working for you at least. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][ 3/5] sched: implement staircase deadline cpu scheduler
On Tue, 27 Mar 2007 13:10:39 +1100 Con Kolivas <[EMAIL PROTECTED]> wrote: > + DECLARE_BITMAP(bitmap, PRIO_RANGE + 1); > + /* > + * This bitmap shows what priorities this task has received quota > + * from for this major priority rotation on its current runqueue. > + */ > struct prio_array *array; > + unsigned long rotation; > + /* Which major runqueue rotation did this task run */ > > unsigned short ioprio; > #ifdef CONFIG_BLK_DEV_IO_TRACE > unsigned int btrace_seq; > #endif > - unsigned long sleep_avg; > unsigned long long timestamp, last_ran; > unsigned long long sched_time; /* sched_clock time spent running */ > - enum sleep_type sleep_type; > > unsigned long policy; > cpumask_t cpus_allowed; > - unsigned int time_slice, first_time_slice; > + int time_slice; > + /* > + * How much this task is entitled to run at the current priority > + * before being requeued at a lower priority. > + */ > + unsigned int first_time_slice; > + /* Is this the very first time_slice this task has ever run. */ > + int quota; > + /* How much this task receives at each priority level */ This is nuts. Nobody puts the description of the fields _below_ those fields. I fixed it in my copy (while fixing the usual reject storm). Please fix it in your tree, wherever it occurs. Weird. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] Blackfin arch: add kdebug header file
On 3/26/07, Paul Mundt <[EMAIL PROTECTED]> wrote: You should really consider the latter for getting updates merged in the future we're planning for this, but the short term it isnt doable for us now that most of the initial troubles are resolved. i would say initial troubles are resolved once we're in Linus' tree :) -mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] cache pipe buf page address for non-highmem arch
On Fri, 23 Mar 2007 17:48:29 -0700 "Ken Chen" <[EMAIL PROTECTED]> wrote: > It is really sad that we always call kmap and friends for every pipe > buffer page on 64-bit arch that doesn't use HIGHMEM, or on > configuration that doesn't turn on HIGHMEM. > > The effect of calling kmap* is visible in the execution profile when > pipe code is being stressed. It is especially true on amd's x86-64 > platform where kmap() has to traverse through numa node index > calculation in order to convert struct page * to kernel virtual > address. It is fairly pointless to perform that calculation repeatly > on system with no highmem (i.e., 64-bit arch like x86-64). This patch > caches kernel pipe buffer page's kernel vaddr to speed up pipe buffer > mapping functions. LTP's vmsplice01 triggers the below: VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 200k freed Unable to find swap-space signature Unable to handle kernel NULL pointer dereference at 0130 RIP: [] pipe_to_file+0x1f3/0x2a6 PGD 10389d067 PUD 10107b067 PMD 0 Oops: [1] PREEMPT SMP last sysfs file: devices/pci:00/:00:1d.7/usb1/dev CPU 3 Modules linked in: pcmcia firmware_class yenta_socket rsrc_nonstatic pcmcia_core Pid: 18708, comm: vmsplice01 Not tainted 2.6.21-rc5-mm1 #2 RIP: 0010:[] [] pipe_to_file+0x1f3/0x2a6 RSP: 0018:81010448dd48 EFLAGS: 00010286 RAX: RBX: RCX: 0ed0 RDX: 81010448dfd8 RSI: 0130 RDI: 810170149000 RBP: 81010448dda8 R08: 0004 R09: 810102657d40 R10: 1000 R11: 002da01c R12: 810006c05240 R13: 0ed0 R14: 810103c56bb0 R15: 0ed0 FS: 2af6b3d96b00() GS:810100090b90() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0130 CR3: 00010384a000 CR4: 06e0 Process vmsplice01 (pid: 18708, threadinfo 81010448c000, task 8101045d58f0) Stack: 000e 81010448ddc8 810103c56b48 810101168df0 81010edf9660 03c56b48 810103c56bb0 810103c56b48 804f8380 Call Trace: [] __splice_from_pipe+0x6d/0x1ea [] pipe_to_file+0x0/0x2a6 [] pipe_to_file+0x0/0x2a6 [] splice_from_pipe+0x54/0x75 [] generic_file_splice_write+0x8a/0xfc [] do_splice_from+0x72/0x7e [] sys_splice+0x105/0x216 [] system_call+0x7e/0x83 Code: f3 a4 bf 01 00 00 00 e8 0b a9 f8 ff 65 48 8b 04 25 10 00 00 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] Blackfin arch: add kdebug header file
On Tue, Mar 27, 2007 at 11:40:37AM +0800, Wu, Bryan wrote: > Thanks Arnd. I posted almost ten patches yesterday. Converting ten > patches to preformatted Emails is terrible manually, you know. > > How does a kernel guru to do this, send out dozens of patch emails a > day? Is there any convenient tools to help this? > Most people either have patch-bombing scripts or just use git to take care of it. You should really consider the latter for getting updates merged in the future, now that most of the initial troubles are resolved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fbdev sysfs imrovements
On Tue, 20 Mar 2007 14:25:49 + (GMT) James Simmons <[EMAIL PROTECTED]> wrote: > This patch does several things to allow the underlying hardware to be > shared amount many devices. The most important thing is the use of > the created device via device_create instead of the hardware device. No > longer should fbdev drivers use the xxx_set_drvdata with the parent > bus device. The second change is having a bus independent power management > for the framebuffer driver. The final change is using the release method > to cleanup the device. The reason again is to make the fbdev driver > independent of the bus parent device. Feedback is welcomed. Causes an early crash on the powermac G5. http://userweb.kernel.org/~akpm/s5000489.jpg (the oops is the usual powerpc mess) config at http://userweb.kernel.org/~akpm/config-g5.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC: 2.6.21 patch] let PCI_MSI depend on EXPERIMENTAL
On Mon, 2007-03-26 at 21:13 -0600, Eric W. Biederman wrote: > David Miller <[EMAIL PROTECTED]> writes: > > > From: Adrian Bunk <[EMAIL PROTECTED]> > > Date: Tue, 27 Mar 2007 03:02:47 +0200 > > > >> We had during the last months have quite a few MSI bugs and even > >> regressions due to: > >> - core kernel bugs, > >> - device driver bugs and > >> - hardware bugs >- architecture bugs >- MSI enabled on hardware that does not support it. > > aka. Drivers have started supporting MSI, People have started using > and testing MSI, and there has been MSI maintenance. People care. > > The most recent regressions involving MSI have been fixes propagating > their way through the kernel, and I can't think of a one of them > that was MSI specific. Just that the bug didn't happen to show > up clearly without MSI enabled. > > Finding that pci_save_state/pci_restore_state had serious resources > leaks was nasty. > > Finding that pci_enable_device isn't suspend/resume safe as > implemented on x86 and ia64 is very nasty. Currently on x86 it is > only really safe to call pci_enable_device exactly once. But the bugs > are small enough we don't generally notice. > > Personally I prefer glaring outstanding bugs to little subtle once > that only bite you on the second Tuesday of the month. > > The recent MSI maintenance has shifted the code around enough that > problems became visible. I'm not happy with this but I don't expect > this to be an on-going state of affairs. > > >> OTOH, MSI doesn't bring any real advantages for most users. > > So default it to off, although I suspect we are approaching the > point where it would actually be safe to default it to on. We > need a kernel release that doesn't have msi issues yet. > > >> Let's therefore mark PCI_MSI as EXPERIMENTAL. > >> > >> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > > > This is a good way to ensure that the code doesn't get tested > > enough to ever fix the problems. > > Dave I agreed. PCI_MSI is not the problem. > > I think marking PCI_MSI as EXPERIMENTAL now would be closing the > barn door after the horses have fled. I don't know of a core MSI > code path that hasn't been scrutinized lately. I wouldn't say they > are perfect but they are junk either. Especially given that the > code is not good enough where non x86 architectures can support > MSI. > > There is one big remaining real world problem and that is we enable > MSI optimistically. Resulting in it being enabled on chipsets that > don't support MSI. We still need to change that behavior. I have > been buried in the guts of things so I haven't had the free cycles to > worry about that yet, nor have there been enough people complaining > that it has crossed my pain threshold to just fix the thing. > > I think where we are honestly at is that today MSI works on most new > chipsets. MSI is supported by the hardware. MSI is supported by the > OS. With a little more maturity devices and device drivers will start > taking advantage of in ways that matter to users now that it works. .. and we will start to see more and more hardware that _only_ uses MSI. So we need to get it fixed, rather than sweeping the bugs under the carpet 'til later. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part
Re: [PATCH 3/3][RFC] Containers: Pagecache controller reclaim
On 3/6/07, Vaidyanathan Srinivasan <[EMAIL PROTECTED]> wrote:
The reclaim code is similar to RSS memory controller. Scan control is
slightly different since we are targeting different type of pages.
Additionally no mapped pages are touched when scanning for pagecache pages.
RSS memory controller and pagecache controller share common code in reclaim
and hence pagecache controller patches are dependent on RSS memory controller
patch even though the features are independently configurable at compile time.
--- linux-2.6.20.orig/mm/vmscan.c
+++ linux-2.6.20/mm/vmscan.c
@@ -43,6 +43,7 @@
#include
#include
+#include
#include "internal.h"
@@ -70,6 +71,8 @@ struct scan_control {
struct container *container;/* Used by containers for reclaiming */
/* pages when the limit is exceeded */
+ int reclaim_pagecache_only; /* Set when called from
+ pagecache controller */
};
/*
@@ -474,6 +477,15 @@ static unsigned long shrink_page_list(st
goto keep;
VM_BUG_ON(PageActive(page));
+ /* Take it easy if we are doing only pagecache pages */
+ if (sc->reclaim_pagecache_only) {
+ /* Check if this is a pagecache page they are not
mapped */
+ if (page_mapped(page))
+ goto keep_locked;
+ /* Check if this container has exceeded pagecache limit
*/
+ if (!pagecache_acct_page_overlimit(page))
+ goto keep_locked;
+ }
sc->nr_scanned++;
@@ -522,7 +534,8 @@ static unsigned long shrink_page_list(st
}
if (PageDirty(page)) {
- if (referenced)
+ /* Reclaim even referenced pagecache pages if over
limit */
+ if (!pagecache_acct_page_overlimit(page) && referenced)
goto keep_locked;
if (!may_enter_fs)
goto keep_locked;
@@ -869,6 +882,13 @@ force_reclaim_mapped:
cond_resched();
page = lru_to_page(_hold);
list_del(>lru);
+ /* While reclaiming pagecache make it easy */
+ if (sc->reclaim_pagecache_only) {
+ if (page_mapped(page) ||
!pagecache_acct_page_overlimit(page)) {
+ list_add(>lru, _active);
+ continue;
+ }
+ }
Please correct me if I'm wrong.
Here, if page type is mapped or not overlimit, why add it back to active list?
Did shrink_page_list() is called by shrink_inactive_list()?
-Aubrey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: revoke: no revoke for nommu
On Mon, 2007-03-26 at 13:25 +0100, David Howells wrote: > Pekka J Enberg <[EMAIL PROTECTED]> wrote: > > > There's just no sane way to revoke shared memory mappings for NOMMU so lets > > disable the thing completely when CONFIG_MMU=n. > > I think that's reasonable for now - we can always add support as far as > possible later. > Yes, we can test this on Blackfin arch and maybe add support later with Blackfin MPU. Thanks -Bryan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] Blackfin arch: add kdebug header file
On Mon, 2007-03-26 at 23:45 +0200, Arnd Bergmann wrote: > I can see nothing wrong with your patches, but you should make the > patch descriptions a little clearer: > Thanks Arnd. I posted almost ten patches yesterday. Converting ten patches to preformatted Emails is terrible manually, you know. How does a kernel guru to do this, send out dozens of patch emails a day? Is there any convenient tools to help this? > On Monday 26 March 2007, Wu, Bryan wrote: > > Hi folks, > > No need for this line, if it's there, Andrew just needs to remove > it from the changelog. > > > This patch adds kdebug.h header file to blackfin architecture. > > This line is completely redundant, as it states the same information > as the subject. You should give some background information here, > like: > > kdebug.h is needed for kprobes. > > For trivial patches where the subject already tells the whole story > (e.g. 'remove redundant declaration of foo'), just leave out the > description entirely except for the Signed-off-by. > > Arnd <>< > you can even leave out the description I really appreciate your warmly advice. Best Regards, Bryan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] wistron_btns: More keymaps, take 2
On Sunday 18 March 2007 17:10, Éric Piel wrote: > Hello, > > This is a new version of my patch to add support for more laptops to the > wistron_btns driver. Modifications from the previous version: > * sends lid close/open event as a switch event (not a key event) > * Display on/off is KEY_SCREEN and Display selection is > KEY_SWITCHVIDEOMODE, from the discussion they seemed the "less bad" > keycodes. > * keymaps are now declared initdata in order to save some memory > Everyting applied to the input tree. Used new KEY_DISPLAYTOGGLE instead of KEY_SCREEN. Thank you Eric. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
Adrian Bunk wrote:
On Wed, Mar 21, 2007 at 06:42:58PM -0700, Randy Dunlap wrote:
On Thu, 22 Mar 2007 01:32:36 + Sid Boyce wrote:
...
There's not a lot of docs out there.
The man-page: http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
Linus's email doc:
http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bisect.txt
I worked on something over last weekend, but it doesn't really add
much to the references above.
...
FWIW:
My standard instructions for users who are asked to bisect are [1]:
<-- snip -->
# install git and cogito on your computer
# clone Linus' tree:
cg-clone \
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
# start bisecting:
cd linux-2.6
git bisect start
git bisect bad 86a71dbd3e81e8870d0f0e56b87875f57e58222b
git bisect good ac98695d6c1508b724f246f38ce57fb4e3cec356
# start round
cp /path/to/.config .
make oldconfig
make
# install kernel, check whether it's good or bad, then:
git bisect [bad|good]
# start next round
After at about 8 reboots, you'll have found the guilty commit
("... is first bad commit").
More information on git bisecting:
man git-bisect
<-- snip -->
~Randy
cu
Adrian
[1] the start and end commits and the number of reboots are variable,
but the rest of the text is generic
This is what I've got so far on the first boot, I shall have to check
the manpage for git-bisect again to see if there is anything else to be
added, nothing enlightening seen so far - further reboots to be done.
barrabas:/usr/src/GIT/linux-2.6 # git bisect bad
Bisecting: 22 revisions left to test after this
[3fc605a2aa38899c12180ca311f1eeb61a6d867e] knfsd: allow the server to
provide a gid list when using AUTH_UNIX authentication
rrabas:/usr/src/GIT/linux-2.6 # git bisect bad
Bisecting: 11 revisions left to test after this
[ed8b4d4d7a31923db32f4684535944d69eb43677] qconf: hide empty list items
barrabas:/usr/src/GIT/linux-2.6 #
rrabas:/usr/src/GIT/linux-2.6 # git bisect bad
Bisecting: 6 revisions left to test after this
[66e7c7230fed159e138fc1292ee662b8bbdb74d6] qconf: relocate Search Command
barrabas:/usr/src/GIT/linux-2.6 #
barrabas:/usr/src/GIT/linux-2.6 # git bisect bad
Bisecting: 3 revisions left to test after this
[895a39a084e5478121a74752a291165c4502378f] Make mkcompile_h use LANG=C
and LC_ALL=C for $CC -v
barrabas:/usr/src/GIT/linux-2.6 # git bisect bad
Bisecting: 2 revisions left to test after this
[8c7e4498adfdb4aea5a0d056590ec18d099ba062] search a little harder for
mkimage
barrabas:/usr/src/GIT/linux-2.6 # git bisect bad
Bisecting: 1 revisions left to test after this
[b7de8e7e3c7b79a72c20c7fd58bd65df3d146b13] ia64: fix noncoherent DMA API
so devres builds
# git bisect bad
b7de8e7e3c7b79a72c20c7fd58bd65df3d146b13 is first bad commit
commit b7de8e7e3c7b79a72c20c7fd58bd65df3d146b13
Author: Roland Dreier <[EMAIL PROTECTED]>
Date: Wed Feb 14 00:32:53 2007 -0800
[PATCH] ia64: fix noncoherent DMA API so devres builds
On ia64, drivers/base/dma-mapping.c doesn't build because it calls
dma_alloc_noncoherent() and dma_free_noncoherent(), which appear to be
terminally broken; the calls end up generating errors like
drivers/base/dma-mapping.c: In function 'dmam_noncoherent_release':
drivers/base/dma-mapping.c:32: error: 'struct
ia64_machine_vector' has no member named 'platform_dma_free_coherent'
because the multiple levels of macro expansion in
and
end up turning a call to dma_free_noncoherent() into
ia64_mv.platform_dma_free_coherent (instead of the intended
ia64_mv.dma_free_coherent).
This patch fixes this by converting dma_{alloc,free}_noncoherent() into
inline functions that call the corresponding coherent functions,
instead of
trying to do this with macros.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
Acked-by: Tony Luck <[EMAIL PROTECTED]>
Cc: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
:04 04 ac36019577dc1846a5655918cf9d6b2541c398cf
ba536f54303cc9495b7839763ed1121d3a22154c M include
barrabas:/usr/src/GIT/linux-2.6 # git bisect bad
86a71dbd3e81e8870d0f0e56b87875f57e58222b
Bisecting: 44 revisions left to test after this
[208367eeec8d6f6fcee1a0672af2149aeee7b658] sysctl: cdrom: remove
unnecessary insert_at_head flag
barrabas:/usr/src/GIT/linux-2.6 # git bisect good
ac98695d6c1508b724f246f38ce57fb4e3cec356
Bisecting: 44 revisions left to test after this
[208367eeec8d6f6fcee1a0672af2149aeee7b658] sysctl: cdrom: remove
unnecessary insert_at_head flag
Regards
Sid.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist,
Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
[PATCH] ipcns: fix stupid !CONFIG_IPC error
Sorry, I broke CONFIG_IPC=n. This is a port of the patch Andrew
used to fix it in -mm
Here is a question... When CONFIG_IPC_NS=n and the user asks for
a new IPC namespace, we want to return -EINVAL to let them know
we couldn't oblige. But if CONFIG_IPC=n is it ok to just return 0?
If not, then we'll need a somewhat different fix, as we can't
#include sched.h in ipc.h.
thanks,
-serge
From: Serge E. Hallyn <[EMAIL PROTECTED]>
Subject: [PATCH] ipcns: fix stupid !CONFIG_IPC error
Andrew Morton pointed out my patch to fix CLONE_NEWIPC behavior
when CONFIG_IPC_NS=n broke compilation when CONFIG_IPC=n.
Make sure copy_ipcs() is always defined.
Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]>
---
include/linux/ipc.h |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
d731d029f908b76af52d2abd9ab199fa931d2c98
diff --git a/include/linux/ipc.h b/include/linux/ipc.h
index 5c05c88..6da6772 100644
--- a/include/linux/ipc.h
+++ b/include/linux/ipc.h
@@ -92,11 +92,13 @@ extern struct ipc_namespace init_ipc_ns;
#ifdef CONFIG_SYSVIPC
#define INIT_IPC_NS(ns).ns = _ipc_ns,
+extern int copy_ipcs(unsigned long flags, struct task_struct *tsk);
#else
#define INIT_IPC_NS(ns)
+static inline int copy_ipcs(unsigned long flags, struct task_struct *tsk)
+{ return 0; }
#endif
-extern int copy_ipcs(unsigned long flags, struct task_struct *tsk);
#ifdef CONFIG_IPC_NS
extern void free_ipc_ns(struct kref *kref);
extern int unshare_ipcs(unsigned long flags, struct ipc_namespace **ns);
--
1.3.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/5] i386-gdt-pda Update lguest to initialize gdt without pda
On Mon, 2007-03-26 at 17:21 -0700, Jeremy Fitzhardinge wrote:
> plain text document attachment (lguest-use-percpu.patch)
Thanks for the fixup Jeremy!
Unfortunately that doesn't quite work. But it turns out we don't need
to load the GDT at all: we can run off the Host-supplied one until we
load the gdt naturally.
So I prefer this patch:
===
Lguest now doesn't need to touch the GDT at all: it can run on the
Host-supplied boot gdt until it reloads later in the boot process.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
---
arch/i386/lguest/lguest.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff -r 3349222e5f58 arch/i386/lguest/lguest.c
--- a/arch/i386/lguest/lguest.c Tue Mar 27 12:57:46 2007 +1000
+++ b/arch/i386/lguest/lguest.c Tue Mar 27 13:28:20 2007 +1000
@@ -34,7 +34,6 @@
#include
#include
#include
-#include
#include
#include
@@ -448,10 +447,6 @@ static void lguest_power_off(void)
{
hcall(LHCALL_CRASH, __pa("Power down"), 0, 0);
}
-
-/* From head.S */
-extern void setup_pda(void);
-extern struct Xgt_desc_struct early_gdt_descr;
static __attribute_used__ __init void lguest_init(void)
{
@@ -513,11 +508,6 @@ static __attribute_used__ __init void lg
/* We use top of mem for initial pagetables. */
init_pg_tables_end = __pa(pg0);
- /* set up PDA descriptor */
- setup_pda();
- load_gdt(_gdt_descr);
- asm volatile ("mov %0, %%fs" : : "r" (__KERNEL_PDA) : "memory");
-
reserve_top_address(lguest_data.reserve_mem);
cpu_detect(_cpu_data);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] Revoke core code: fix nommu arch compiling error bug
On Mon, 2007-03-26 at 16:21 -0400, Mike Frysinger wrote: > On 3/26/07, David Howells <[EMAIL PROTECTED]> wrote: > > [*] The FRV, for example, does have some limited protection capability - but > > it is really limited and not really useful in this case. > Sorry for late response. > how so ? the Blackfin processor lacks a MMU but it does have a MPU > (memory protection unit) which allows granularity down to 1k page > sizes ... so for future releases, we plan on integrating optional > support for this so that you could have processes protected from each > other and the kernel protected from all the processes ... so in our > case, we might actually be able to support revoking of maps because we > would have that region of memory ear marked as unaccessible ... > Agree. MPU of Blackfin can provide some processes protection. But maybe at this moment just disable revoke for NOMMU is easier for further development. When we provide the MPU stuff, maybe we can enable the revoke for NOMMU but MPU arch. > note that the Blackfin processor manuals confusingly call this aspect > of the chip an "MMU" ... dont be fooled ! > -mike Thanks -Bryan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3/5] 2.6.21-rc4: known regressions (v2)
"Luck, Tony" <[EMAIL PROTECTED]> writes: >> What I'm proposing we do is move the irq allocation code out of >> pci_enable_device and the irq freeing code out of pci_disable_device >> in the future. > > Sounds rational ... in a world that wasn't dominated by PCI it would > seem to be the logical approach (since the irq code would have much > more utility independent of the PCI code). Right. We can even do this earlier in the pci code. Just doing this on demand when the device driver needs it is problematic. As devices drivers like to keep the requested over a pci_disable_device pci_enable_device pair. The big practical issue is that we will like wind up allocating an irq number to all usable irqs on ia64. Which means we will like need many more irq numbers... Although I guess if we keep it at the pci layer we should be fairly safe. I was afraid there was some hotplug reason for waiting until pci_enable_device to allocate the irq numbers. >> Tony, Len before we merge any fixes for 2.6.21-rcX I'd like to at >> least get an ack on the long term direction. > > Long-term-direction-acked-by: Tony Luck <[EMAIL PROTECTED]> Thanks. Then small surgery will happen now, and I will start queuing up the major surgery patches. Although I won't be able to do more than compile test and code review the ia64 changes. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][Patch 1/4] kprobe fast unregistration
Hi Anil, Keshavamurthy, Anil S wrote: > On Mon, Mar 26, 2007 at 12:17:49PM +0900, Masami Hiramatsu wrote: >> Hi Christoph and Anil, >> >> Thank you for your comments. >> >> Christoph Hellwig wrote: >>> Speeding up the unregistration is a very good idea, but this interface >>> is rather horrible. It's almost a receipe for users to get it wrong. >> Keshavamurthy, Anil S wrote: >>> I agree with Christop that the interface is horrible and error prone. >> OK, I agree. I had chosen a confusable name. > Keep in mind that the the sequence of unregistering a > probe should be same irrespecitve of whether user wants > to unregister a single probe or user want to > unregister more that one probe, i.e. you can not say > use this call (unregister_kprobe() ) for unregistering > a probe which is b.t.w slow and use this set of calls if you > have more than one kprobes to unregister for faster unregistration. Would you mean that we should integrate unregistration interface? Or, would you mean that you prefer "disable_kprobe()" since that name provides another meaning? Thanks, -- Masami HIRAMATSU Linux Technology Center Hitachi, Ltd., Systems Development Laboratory E-mail: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC: 2.6.21 patch] let PCI_MSI depend on EXPERIMENTAL
David Miller <[EMAIL PROTECTED]> writes: > From: Adrian Bunk <[EMAIL PROTECTED]> > Date: Tue, 27 Mar 2007 03:02:47 +0200 > >> We had during the last months have quite a few MSI bugs and even >> regressions due to: >> - core kernel bugs, >> - device driver bugs and >> - hardware bugs - architecture bugs - MSI enabled on hardware that does not support it. aka. Drivers have started supporting MSI, People have started using and testing MSI, and there has been MSI maintenance. People care. The most recent regressions involving MSI have been fixes propagating their way through the kernel, and I can't think of a one of them that was MSI specific. Just that the bug didn't happen to show up clearly without MSI enabled. Finding that pci_save_state/pci_restore_state had serious resources leaks was nasty. Finding that pci_enable_device isn't suspend/resume safe as implemented on x86 and ia64 is very nasty. Currently on x86 it is only really safe to call pci_enable_device exactly once. But the bugs are small enough we don't generally notice. Personally I prefer glaring outstanding bugs to little subtle once that only bite you on the second Tuesday of the month. The recent MSI maintenance has shifted the code around enough that problems became visible. I'm not happy with this but I don't expect this to be an on-going state of affairs. >> OTOH, MSI doesn't bring any real advantages for most users. So default it to off, although I suspect we are approaching the point where it would actually be safe to default it to on. We need a kernel release that doesn't have msi issues yet. >> Let's therefore mark PCI_MSI as EXPERIMENTAL. >> >> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > This is a good way to ensure that the code doesn't get tested > enough to ever fix the problems. Dave I agreed. PCI_MSI is not the problem. I think marking PCI_MSI as EXPERIMENTAL now would be closing the barn door after the horses have fled. I don't know of a core MSI code path that hasn't been scrutinized lately. I wouldn't say they are perfect but they are junk either. Especially given that the code is not good enough where non x86 architectures can support MSI. There is one big remaining real world problem and that is we enable MSI optimistically. Resulting in it being enabled on chipsets that don't support MSI. We still need to change that behavior. I have been buried in the guts of things so I haven't had the free cycles to worry about that yet, nor have there been enough people complaining that it has crossed my pain threshold to just fix the thing. I think where we are honestly at is that today MSI works on most new chipsets. MSI is supported by the hardware. MSI is supported by the OS. With a little more maturity devices and device drivers will start taking advantage of in ways that matter to users now that it works. I can guess how they will take advantage of it and make it matter to users but that would just be speculation on my part. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Correct bad CONFIG names in drivers/usb/input/Makefile.
On Monday 26 March 2007 18:08, Robert P. J. Day wrote:
> Correct the incorrect CONFIG_ variables currently in
> drivers/usb/input/Makefile that prevent three of the touchscreen
> source files from being built.
>
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
>
NAK. These modules should just go away.
--
Dmitry
Input: remove old USB touchscreen drivers
itmtoch, mtouchusb and touchkitusb have been replaced with
composite usbtouchscreen driver and can be removed now.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/usb/input/itmtouch.c| 271 ---
drivers/usb/input/mtouchusb.c | 332 -
drivers/usb/input/touchkitusb.c | 392
drivers/usb/input/Makefile |3
4 files changed, 998 deletions(-)
Index: work/drivers/usb/input/Makefile
===
--- work.orig/drivers/usb/input/Makefile
+++ work/drivers/usb/input/Makefile
@@ -38,9 +38,6 @@ obj-$(CONFIG_USB_KBD) += usbkbd.o
obj-$(CONFIG_USB_KBTAB)+= kbtab.o
obj-$(CONFIG_USB_KEYSPAN_REMOTE) += keyspan_remote.o
obj-$(CONFIG_USB_MOUSE)+= usbmouse.o
-obj-$(CONFIG_USB_MTOUCH) += mtouchusb.o
-obj-$(CONFIG_USB_ITMTOUCH) += itmtouch.o
-obj-$(CONFIG_USB_EGALAX) += touchkitusb.o
obj-$(CONFIG_USB_TOUCHSCREEN) += usbtouchscreen.o
obj-$(CONFIG_USB_POWERMATE)+= powermate.o
obj-$(CONFIG_USB_WACOM)+= wacom.o
Index: work/drivers/usb/input/itmtouch.c
===
--- work.orig/drivers/usb/input/itmtouch.c
+++ /dev/null
@@ -1,271 +0,0 @@
-/**
- * itmtouch.c -- Driver for ITM touchscreen panel
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- *
- * Based upon original work by Chris Collins <[EMAIL PROTECTED]>.
- *
- * Kudos to ITM for providing me with the datasheet for the panel,
- * even though it was a day later than I had finished writing this
- * driver.
- *
- * It has meant that I've been able to correct my interpretation of the
- * protocol packets however.
- *
- * CC -- 2003/9/29
- *
- * History
- * 1.0 & 1.1 2003 (CC) [EMAIL PROTECTED]
- * Original version for 2.4.x kernels
- *
- * 1.2 02/03/2005 (HCE) [EMAIL PROTECTED]
- * Complete rewrite to support Linux 2.6.10, thanks to mtouchusb.c for hints.
- * Unfortunately no calibration support at this time.
- *
- * 1.2.1 09/03/2005 (HCE) [EMAIL PROTECTED]
- * Code cleanup and adjusting syntax to start matching kernel standards
- *
- * 1.2.2 10/05/2006 (MJA) [EMAIL PROTECTED]
- * Flag for detecting if the screen was being touch was incorrectly
- * inverted, so no touch events were being detected.
- *
- */
-
-#include
-#include
-#include
-#include
-#include
-
-/* only an 8 byte buffer necessary for a single packet */
-#define ITM_BUFSIZE8
-#define PATH_SIZE 64
-
-#define USB_VENDOR_ID_ITMINC 0x0403
-#define USB_PRODUCT_ID_TOUCHPANEL 0xf9e9
-
-#define DRIVER_AUTHOR "Hans-Christian Egtvedt <[EMAIL PROTECTED]>"
-#define DRIVER_VERSION "v1.2.2"
-#define DRIVER_DESC "USB ITM Inc Touch Panel Driver"
-#define DRIVER_LICENSE "GPL"
-
-MODULE_AUTHOR( DRIVER_AUTHOR );
-MODULE_DESCRIPTION( DRIVER_DESC );
-MODULE_LICENSE( DRIVER_LICENSE );
-
-struct itmtouch_dev {
- struct usb_device *usbdev; /* usb device */
- struct input_dev*inputdev; /* input device */
- struct urb *readurb; /* urb */
- charrbuf[ITM_BUFSIZE]; /* data */
- int users;
- char name[128];
- char phys[64];
-};
-
-static struct usb_device_id itmtouch_ids [] = {
- { USB_DEVICE(USB_VENDOR_ID_ITMINC, USB_PRODUCT_ID_TOUCHPANEL) },
- { }
-};
-
-static void itmtouch_irq(struct urb *urb)
-{
- struct itmtouch_dev *itmtouch = urb->context;
- unsigned char *data = urb->transfer_buffer;
- struct input_dev *dev = itmtouch->inputdev;
- int retval;
-
- switch (urb->status) {
- case 0:
- /* success */
Re: [RFC: 2.6.21 patch] let PCI_MSI depend on EXPERIMENTAL
On Mon, Mar 26, 2007 at 06:24:22PM -0700, David Miller wrote: > From: Adrian Bunk <[EMAIL PROTECTED]> > Date: Tue, 27 Mar 2007 03:02:47 +0200 > > > We had during the last months have quite a few MSI bugs and even > > regressions due to: > > - core kernel bugs, > > - device driver bugs and > > - hardware bugs > > > > OTOH, MSI doesn't bring any real advantages for most users. > > > > Let's therefore mark PCI_MSI as EXPERIMENTAL. > > > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > This is a good way to ensure that the code doesn't get tested > enough to ever fix the problems. I agree, we need to leave it as it is. Now that Vista is out with support for MSI, we will start to get more hardware that actually works properly with it... thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.21-rc5] MSI: read-flush MSI-X table
Greg KH <[EMAIL PROTECTED]> writes: > How well does this play with the MSI core changes that Michael Ellerman > has proposed on the linux-pci mailing list? The patch looks reasonable and it is independent of those changes. This just modifies the helper code for using the msi capability itself as an interrupt controller. Other architectures that mask/unmask the interrupt at an architecture specific interrupt controller won't be affected. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][ 5/5] sched: document sd cpu scheduler
Add comprehensive documentation of the Staircase Deadline cpu scheduler design. Signed-off-by: Con Kolivas <[EMAIL PROTECTED]> --- Documentation/sched-design.txt | 240 +++-- 1 file changed, 234 insertions(+), 6 deletions(-) Index: linux-2.6.21-rc5-sd/Documentation/sched-design.txt === --- linux-2.6.21-rc5-sd.orig/Documentation/sched-design.txt 2006-11-30 11:30:31.0 +1100 +++ linux-2.6.21-rc5-sd/Documentation/sched-design.txt 2007-03-27 11:52:55.0 +1000 @@ -1,11 +1,14 @@ - Goals, Design and Implementation of the - new ultra-scalable O(1) scheduler + Goals, Design and Implementation of the ultra-scalable O(1) scheduler by + Ingo Molnar and theStaircase Deadline cpu scheduler policy designed by + Con Kolivas. - This is an edited version of an email Ingo Molnar sent to - lkml on 4 Jan 2002. It describes the goals, design, and - implementation of Ingo's new ultra-scalable O(1) scheduler. - Last Updated: 18 April 2002. + This was originally an edited version of an email Ingo Molnar sent to + lkml on 4 Jan 2002. It describes the goals, design, and implementation + of Ingo's ultra-scalable O(1) scheduler. It now contains a description + of the Staircase Deadline priority scheduler that was built on this + design. + Last Updated: Tue Mar 27 2007 Goal @@ -163,3 +166,228 @@ certain code paths and data constructs. code is smaller than the old one. Ingo + + +Staircase Deadline cpu scheduler policy + + +Design summary +== + +A novel design which incorporates a foreground-background descending priority +system (the staircase) via a bandwidth allocation matrix according to nice +level. + + +Features + + +A starvation free, strict fairness O(1) scalable design with interactivity +as good as the above restrictions can provide. There is no interactivity +estimator, no sleep/run measurements and only simple fixed accounting. +The design has strict enough a design and accounting that task behaviour +can be modelled and maximum scheduling latencies can be predicted by +the virtual deadline mechanism that manages runqueues. The prime concern +in this design is to maintain fairness at all costs determined by nice level, +yet to maintain as good interactivity as can be allowed within the +constraints of strict fairness. + + +Design description +== + +SD works off the principle of providing each task a quota of runtime that it is +allowed to run at a number of priority levels determined by its static priority +(ie. its nice level). If the task uses up its quota it has its priority +decremented to the next level determined by a priority matrix. Once every +runtime quota has been consumed of every priority level, a task is queued on the +"expired" array. When no other tasks exist with quota, the expired array is +activated and fresh quotas are handed out. This is all done in O(1). + +Design details +== + +Each task keeps a record of its own entitlement of cpu time. Most of the rest of +these details apply to non-realtime tasks as rt task management is straight +forward. + +Each runqueue keeps a record of what major epoch it is up to in the +rq->prio_rotation field which is incremented on each major epoch. It also +keeps a record of the current prio_level for each static priority task. + +Each task keeps a record of what major runqueue epoch it was last running +on in p->rotation. It also keeps a record of what priority levels it has +already been allocated quota from during this epoch in a bitmap p->bitmap. + +The only tunable that determines all other details is the RR_INTERVAL. This +is set to 8ms, and is scaled gently upwards with more cpus. This value is +tunable via a /proc interface. + +All tasks are initially given a quota based on RR_INTERVAL. This is equal to +RR_INTERVAL between nice values of -6 and 0, half that size above nice 0, and +progressively larger for nice values from -1 to -20. This is assigned to +p->quota and only changes with changes in nice level. + +As a task is first queued, it checks in recalc_task_prio to see if it has run at +this runqueue's current priority rotation. If it has not, it will have its +p->prio level set according to the first slot in a "priority matrix" and will be +given a p->time_slice equal to the p->quota, and has its allocation bitmap bit +set in p->bitmap for this prio level. It is then queued on the current active +priority array. + +If a task has already been running during this major epoch, and it has +p->time_slice left and the rq->prio_quota for the task's p->prio still +has quota, it will be placed back on the active array, but no more quota +will be added. + +If a task has been running during this major epoch, but does not have +p->time_slice left, it will find the next lowest
[PATCH][ 4/5] sched: remove noninteractive flag
Remove the TASK_NONINTERACTIVE flag as it will no longer be used.
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
---
fs/pipe.c |7 +--
include/linux/sched.h |3 +--
2 files changed, 2 insertions(+), 8 deletions(-)
Index: linux-2.6.21-rc5-sd/fs/pipe.c
===
--- linux-2.6.21-rc5-sd.orig/fs/pipe.c 2007-03-26 11:03:31.0 +1000
+++ linux-2.6.21-rc5-sd/fs/pipe.c 2007-03-27 11:52:55.0 +1000
@@ -41,12 +41,7 @@ void pipe_wait(struct pipe_inode_info *p
{
DEFINE_WAIT(wait);
- /*
-* Pipes are system-local resources, so sleeping on them
-* is considered a noninteractive wait:
-*/
- prepare_to_wait(>wait, ,
- TASK_INTERRUPTIBLE | TASK_NONINTERACTIVE);
+ prepare_to_wait(>wait, , TASK_INTERRUPTIBLE);
if (pipe->inode)
mutex_unlock(>inode->i_mutex);
schedule();
Index: linux-2.6.21-rc5-sd/include/linux/sched.h
===
--- linux-2.6.21-rc5-sd.orig/include/linux/sched.h 2007-03-27
11:52:55.0 +1000
+++ linux-2.6.21-rc5-sd/include/linux/sched.h 2007-03-27 11:52:55.0
+1000
@@ -149,8 +149,7 @@ extern unsigned long weighted_cpuload(co
#define EXIT_ZOMBIE16
#define EXIT_DEAD 32
/* in tsk->state again */
-#define TASK_NONINTERACTIVE64
-#define TASK_DEAD 128
+#define TASK_DEAD 64
#define __set_task_state(tsk, state_value) \
do { (tsk)->state = (state_value); } while (0)
--
-ck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH][ 2/5] sched: remove sleepavg from proc
Remove the sleep_avg field from proc output as it will be removed from the task_struct. Signed-off-by: Con Kolivas <[EMAIL PROTECTED]> --- fs/proc/array.c |2 -- 1 file changed, 2 deletions(-) Index: linux-2.6.21-rc5-sd/fs/proc/array.c === --- linux-2.6.21-rc5-sd.orig/fs/proc/array.c2007-03-26 11:03:31.0 +1000 +++ linux-2.6.21-rc5-sd/fs/proc/array.c 2007-03-27 11:52:55.0 +1000 @@ -165,7 +165,6 @@ static inline char * task_state(struct t rcu_read_lock(); buffer += sprintf(buffer, "State:\t%s\n" - "SleepAVG:\t%lu%%\n" "Tgid:\t%d\n" "Pid:\t%d\n" "PPid:\t%d\n" @@ -173,7 +172,6 @@ static inline char * task_state(struct t "Uid:\t%d\t%d\t%d\t%d\n" "Gid:\t%d\t%d\t%d\t%d\n", get_task_state(p), - (p->sleep_avg/1024)*100/(102000/1024), p->tgid, p->pid, pid_alive(p) ? rcu_dereference(p->real_parent)->tgid : 0, pid_alive(p) && p->ptrace ? rcu_dereference(p->parent)->pid : 0, -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][ 1/5] sched: dont renice kernel threads
The practice of renicing kernel threads to negative nice values is of questionable benefit at best, and at worst leads to larger latencies when kernel threads are busy on behalf of other tasks. Signed-off-by: Con Kolivas <[EMAIL PROTECTED]> --- kernel/workqueue.c |2 -- 1 file changed, 2 deletions(-) Index: linux-2.6.21-rc5-sd/kernel/workqueue.c === --- linux-2.6.21-rc5-sd.orig/kernel/workqueue.c 2007-03-26 11:03:31.0 +1000 +++ linux-2.6.21-rc5-sd/kernel/workqueue.c 2007-03-27 11:52:54.0 +1000 @@ -355,8 +355,6 @@ static int worker_thread(void *__cwq) if (!cwq->freezeable) current->flags |= PF_NOFREEZE; - set_user_nice(current, -5); - /* Block and flush all signals */ sigfillset(); sigprocmask(SIG_BLOCK, , NULL); -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][ 0/5] Staircase deadline v0.36
What follows is a clean major iteration of the (now) Staircase Deadline cpu scheduler. Changes from RSDL v0.33: - All accounting is moved to tasks in nanosecond resolution removing requirement for Rotation component entirely - list_splice_tail is no longer required; dropped - Nicer nice with smaller rr_intervals if HZ tolerates it - Reworked SCHED_BATCH to keep same cpu bandwidith but lax latency - Updated documentation Patches that follow are for 2.6.21-rc5 Andrew please use these to replace the RSDL patches. -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[5/5] 2.6.21-rc5: known regressions
This email lists some known regressions in Linus' tree compared to 2.6.20. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: MacMini doesn't come out of suspend to ram (i386 clockevents) (CONFIG_HPET_TIMER) References : http://lkml.org/lkml/2007/3/21/374 Submitter : Frédéric Riss <[EMAIL PROTECTED]> Tino Keitel <[EMAIL PROTECTED]> Caused-By : Thomas Gleixner <[EMAIL PROTECTED]> commit e9e2cdb412412326c4827fc78ba27f410d837e6e Status : unknown Subject: MacBook Core Duo: suspend to disk hangs References : http://bugzilla.kernel.org/show_bug.cgi?id=8224 Submitter : Mike Harris <[EMAIL PROTECTED]> Status : unknown Subject: Dynticks and High resolution Timer hang boot during IDE detection workaround: clocksource=acpi_pm References : http://lkml.org/lkml/2007/3/7/504 Submitter : Stephane Casset <[EMAIL PROTECTED]> Caused-By : John Stultz <[EMAIL PROTECTED]> commit 6bb74df481223731af6c7e0ff3adb31f6442cfcd Handled-By : John Stultz <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/3/22/287 Status : workaround-patch available Subject: after resume: X hangs after drawing a couple of windows workaround: clocksource=acpi_pm References : http://lkml.org/lkml/2007/3/8/117 http://lkml.org/lkml/2007/3/25/20 http://lkml.org/lkml/2007/3/26/151 Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]> Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> Status : problem is being debugged Subject: first disk access after resume takes several minutes resume from RAM broken 'date' does not advance after resume from RAM (CONFIG_HPET_TIMER) References : http://lkml.org/lkml/2007/3/8/117 http://lkml.org/lkml/2007/3/25/20 http://lkml.org/lkml/2007/3/26/18 Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]> Jeff Chua <[EMAIL PROTECTED]> Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> Ingo Molnar <[EMAIL PROTECTED]> Status : problem is being debugged Subject: system doesn't come out of suspend (CONFIG_NO_HZ) References : http://lkml.org/lkml/2007/2/22/391 Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]> Soeren Sonnenburg <[EMAIL PROTECTED]> Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> Ingo Molnar <[EMAIL PROTECTED]> Tejun Heo <[EMAIL PROTECTED]> Rafael J. Wysocki <[EMAIL PROTECTED]> Status : unknown Subject: suspend to disk hangs (CONFIG_NO_HZ) References : http://lkml.org/lkml/2007/3/25/217 Submitter : Jeff Chua <[EMAIL PROTECTED]> Status : unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[3/5] 2.6.21-rc5: known regressions
This email lists some known regressions in Linus' tree compared to 2.6.20. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: Oops when changing DVB-T adapter References : http://lkml.org/lkml/2007/3/9/212 Submitter : CIJOML <[EMAIL PROTECTED]> Status : unknown Subject: snd_intel8x0: divide error: References : http://lkml.org/lkml/2007/3/5/252 Submitter : Michal Piotrowski <[EMAIL PROTECTED]> Status : unknown Subject: USB: iPod doesn't work (CONFIG_USB_SUSPEND) References : http://lkml.org/lkml/2007/3/21/320 Submitter : Tino Keitel <[EMAIL PROTECTED]> Caused-By : Marcelo Tosatti <[EMAIL PROTECTED]> commit 1d619f128ba911cd3e6d6ad3475f146eb92f5c27 Handled-By : Oliver Neukum <[EMAIL PROTECTED]> Status : problem is being debuggged - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2/5] 2.6.21-rc5: known regressions
This email lists some known regressions in Linus' tree compared to 2.6.20. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: x86_64 SMP kernel: maxcpus=1 crash in cpufreq References : http://lkml.org/lkml/2007/3/26/54 Submitter : Ingo Molnar <[EMAIL PROTECTED]> Handled-By : Venki Pallipadi <[EMAIL PROTECTED]> Status : problem is being debugged Subject: kernels fail to boot with drives on ATIIXP controller (ACPI/IRQ related) References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621 http://lkml.org/lkml/2007/3/4/257 Submitter : Michal Jaegermann <[EMAIL PROTECTED]> Status : unknown Subject: NCQ problem with ahci and Hitachi drive (ACPI related) References : http://lkml.org/lkml/2007/3/4/178 http://lkml.org/lkml/2007/3/9/475 http://lkml.org/lkml/2007/2/22/8 Submitter : Mathieu Bérard <[EMAIL PROTECTED]> Handled-By : Tejun Heo <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/2/22/8 Status : possible patch available Subject: libata: PATA UDMA/100 configured as UDMA/33 References : http://lkml.org/lkml/2007/2/20/294 http://www.mail-archive.com/linux-ide@vger.kernel.org/msg04115.html http://bugzilla.kernel.org/show_bug.cgi?id=8133 http://bugzilla.kernel.org/show_bug.cgi?id=8164 http://lkml.org/lkml/2007/3/21/330 Submitter : Fabio Comolli <[EMAIL PROTECTED]> Plamen Petrov <[EMAIL PROTECTED]> Laurent Riffard <[EMAIL PROTECTED]> Lukas Hejtmanek <[EMAIL PROTECTED]> Handled-By : Tejun Heo <[EMAIL PROTECTED]> Patch : http://thread.gmane.org/gmane.linux.ide/17444 Status : patch available - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[4/5] 2.6.21-rc5: known regressions
This email lists some known regressions in Linus' tree compared to 2.6.20. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: ThinkPad X60: resume no longer works (PCI related?) References : http://lkml.org/lkml/2007/3/13/3 Submitter : Dave Jones <[EMAIL PROTECTED]> Jeremy Fitzhardinge <[EMAIL PROTECTED]> Caused-By : PCI merge commit 78149df6d565c36675463352d0bfeb02b7a7 Handled-By : Eric W. Biederman <[EMAIL PROTECTED]> Rafael J. Wysocki <[EMAIL PROTECTED]> Status : problem is being debugged Subject: second suspend to disk in a row results in an oops (MSI) References : http://lkml.org/lkml/2007/3/17/43 http://lkml.org/lkml/2007/3/22/150 http://lkml.org/lkml/2007/3/26/205 http://lkml.org/lkml/2007/3/26/76 Submitter : Thomas Meyer <[EMAIL PROTECTED]> Frédéric Riss <[EMAIL PROTECTED]> Marcus Better <[EMAIL PROTECTED]> Handled-By : Eric W. Biederman <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/3/24/136 Status : patch was suggested Subject: Suspend to RAM doesn't work anymore (ACPI?) References : http://lkml.org/lkml/2007/3/19/128 http://bugzilla.kernel.org/show_bug.cgi?id=8247 Submitter : Tobias Doerffel <[EMAIL PROTECTED]> Handled-By : Rafael J. Wysocki <[EMAIL PROTECTED]> Len Brown <[EMAIL PROTECTED]> Status : problem is being debugged Subject: s2ram autowake regression (ACPI?) References : http://lkml.org/lkml/2007/3/20/96 Submitter : Pavel Machek <[EMAIL PROTECTED]> Handled-By : Len Brown <[EMAIL PROTECTED]> Status : submitter was asked to test a patch Subject: SATA breakage on resume References : http://lkml.org/lkml/2007/3/7/233 Submitter : Thomas Gleixner <[EMAIL PROTECTED]> Soeren Sonnenburg <[EMAIL PROTECTED]> Status : unknown Subject: suspend to disk: keypress required for power down References : http://lkml.org/lkml/2007/3/25/78 Submitter : Thomas Meyer <[EMAIL PROTECTED]> Status : unknown Subject: resume from RAM corrupts vesafb console References : http://lkml.org/lkml/2007/3/26/76 Submitter : Marcus Better <[EMAIL PROTECTED]> Handled-By : Pavel Machek <[EMAIL PROTECTED]> Status : problem is being debugged Subject: suspend to disk: non-boot cpus are disabled again References : http://lkml.org/lkml/2007/3/25/78 Submitter : Thomas Meyer <[EMAIL PROTECTED]> Handled-By : Rafael J. Wysocki <[EMAIL PROTECTED]> Eric W. Biederman <[EMAIL PROTECTED]> Status : problem is being debugged Subject: ThinkPad doesn't resume from suspend to RAM References : http://lkml.org/lkml/2007/2/27/80 http://lkml.org/lkml/2007/2/28/348 Submitter : Jens Axboe <[EMAIL PROTECTED]> Jeff Chua <[EMAIL PROTECTED]> Status : unknown Subject: suspend to disk hangs (microcode driver) References : http://lkml.org/lkml/2007/3/16/126 Submitter : Maxim Levitsky <[EMAIL PROTECTED]> Caused-By : Rafael J. Wysocki <[EMAIL PROTECTED]> commit e3c7db621bed4afb8e231cb005057f2feb5db557 commit ed746e3b18f4df18afa3763155972c5835f284c5 commit 259130526c267550bc365d3015917d90667732f1 Handled-By : Rafael J. Wysocki <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/3/23/179 Status : patch available - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[1/5] 2.6.21-rc5: known regressions
This email lists some known regressions in Linus' tree compared to 2.6.20. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: crashes in KDE References : http://bugzilla.kernel.org/show_bug.cgi?id=8157 Submitter : Oliver Pinter <[EMAIL PROTECTED]> Status : unknown Subject: kwin dies silently (sysctl related?) References : http://lkml.org/lkml/2007/2/28/112 Submitter : Sid Boyce <[EMAIL PROTECTED]> Boris Mogwitz <[EMAIL PROTECTED]> Status : submitter was asked to bisect further Subject: problem with sockets References : http://lkml.org/lkml/2007/3/21/248 Submitter : Jose Alberto Reguero <[EMAIL PROTECTED]> Status : unknown Subject: e1000 resume weirdness References : http://lkml.org/lkml/2007/3/26/91 Submitter : Ingo Molnar <[EMAIL PROTECTED]> Handled-By : Jesse Brandeburg <[EMAIL PROTECTED]> Auke Kok <[EMAIL PROTECTED]> Status : problem is being debugged Subject: forcedeth: sporadic under-load crashes References : http://lkml.org/lkml/2007/3/26/63 Submitter : Ingo Molnar <[EMAIL PROTECTED]> Handled-By : Ingo Molnar <[EMAIL PROTECTED]> Ayaz Abdulla <[EMAIL PROTECTED]> Status : problem is being debugged Subject: forcedeth: skb_over_panic References : http://bugzilla.kernel.org/show_bug.cgi?id=8058 Submitter : Albert Hopkins <[EMAIL PROTECTED]> Handled-By : Ayaz Abdulla <[EMAIL PROTECTED]> Patch : http://bugzilla.kernel.org/show_bug.cgi?id=8058 Status : patch available - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [QUICKLIST 1/5] Quicklists for page table pages V4
From: William Lee Irwin III <[EMAIL PROTECTED]> Date: Mon, 26 Mar 2007 18:06:24 -0700 > On Mon, Mar 26, 2007 at 10:26:51AM -0800, Andrew Morton wrote: > > b) we understand why the below simple modification crashes i386. > > Full eager zeroing patches not dependent on quicklist code don't crash, > so there is no latent use-after-free issue covered up by caching. I'll > help out more on the i386 front as-needed. I've looked into this a few times and I am quite mystified as to why that simple test patch crashes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] scheduler: strange behavor with massive interactive processes
Hi Ingo and all,
When I was executing massive interactive processes, I found that some of them
occupy CPU time and the others hardly run.
It seems that some of processes which occupy CPU time always has max effective
prio (default+5) and the others have max - 1. What happen here is...
1. If there are moderate number of max interactive processes, they can be
re-inserted into active queue without falling down its priority again and
again.
2. In this case, the others seldom run, and can't get max effective priority
at next exhausting because scheduler considers them to sleep too long.
3. Goto 1, OOPS!
Unfortunately I haven't been able to make the patch resolving this problem
yet. Any idea?
I also attach the test program which easily recreates this problem.
Test program flow:
1. First process starts child proesses and wait for 5 minutes.
2. Each child process executes "work 8 msec and sleep 1 msec" loop
continuously.
3. After 3 minits have passed, each child processes prints the # of loops
which executed.
What expected:
Each child processes execute nearly equal # of loops.
Test environment:
- kernel: 2.6.20(*1)
- # of CPUs: 1 or 2
- # of child processes: 200 or 400
- nice value:0 or 20(*2)
*1) I confirmed that 2.6.21-rc5 has no change regarding this problem.
*2) If a process have nice 20, scheduler never regards it as interactive.
Test results:
---++--+
# of CPUs | # of processes | nice | result
---++--+
|| 20 | looks good
1(i386) |+--+
||0 | 4 processes occupy 98% of CPU time
---+200 +--+
|| 20 | looks good
|+--+
||0 | 8 processes occupy 72% of CPU time
2(ia64) ++--+
|400 | 20 | looks good
|+--+
||0 | 8 processes occupy 98% of CPU time
---++--+
FYI. 2.6.21-rc3-mm1 (enabling RSDL scheduler) works fine in the all casees :-)
Thanks,
Satoru
---
/*
* massive_intr - run @nproc interactive processes and print the number of
*loops(*1) each process executes in @runtime secs.
*
**1) "work 8 msec and sleep 1msec" loop
*
* Usage: massive_intr
*
* @nproc: number of processes
* @runtime: execute time[sec]
*
* ex) If you want to run 300 processes for 5 mins, issue the
* command as follows:
*
* $ massive_intr 300 300
*
* How to build:
*
* cc -o massive_intr massive_intr.c -lrt
*
*
* Copyright (C) 2007 Satoru Takeuchi <[EMAIL PROTECTED]>
*
* ~~
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or (at
* your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
*
* ~~
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define WORK_MSECS 8
#define SLEEP_MSECS 1
#define MAX_PROC1024
#define SAMPLE_COUNT10
#define USECS_PER_SEC 100
#define USECS_PER_MSEC 1000
#define NSECS_PER_MSEC 100
#define SHMEMSIZE 4096
static const char *shmname = "/sched_interactive_shmem";
static void *shmem;
static sem_t *printsem;
static int nproc;
static int runtime;
static int fd;
static time_t *first;
static pid_t pid[MAX_PROC];
static int return_code;
static void cleanup_resources(void)
{
if (sem_destroy(printsem) < 0)
warn("sem_destroy() failed");
if (munmap(shmem, SHMEMSIZE) < 0)
warn("munmap() failed");
if
Re: [RFC: 2.6.21 patch] let PCI_MSI depend on EXPERIMENTAL
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Tue, 27 Mar 2007 03:02:47 +0200 > We had during the last months have quite a few MSI bugs and even > regressions due to: > - core kernel bugs, > - device driver bugs and > - hardware bugs > > OTOH, MSI doesn't bring any real advantages for most users. > > Let's therefore mark PCI_MSI as EXPERIMENTAL. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> This is a good way to ensure that the code doesn't get tested enough to ever fix the problems. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [QUICKLIST 1/5] Quicklists for page table pages V4
On Mon, 26 Mar 2007, William Lee Irwin III wrote: > Not that clameter really needs my help, but I agree with his position > on several fronts, and advocate accordingly, so here is where I'm at. Yes thank you. I386 is not my field, I have no interest per se in improving i386 performance and without your help I would have to drop this and keep the special casing in SLUB for i386. Generic tlb.h changes may also help to introduce quicklists to x86_64. The current quicklist patches can only work on higher levels due to the freeing of ptes via tlb_remove_page(). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix sudden warps in mousedev
On Monday 26 March 2007 17:42, Pete Zaitcev wrote: > On Mon, 26 Mar 2007 15:30:42 -0400, "Dmitry Torokhov" <[EMAIL PROTECTED]> > wrote: > > > Regarding the synaptics driver and scroll problem. Yesterday I > > scrolled twice through entire Remarque's "Spark of Life" off lib.ru > > (once with 0.14.2 and once with latest git pull) and did not see any > > scrollbar getting "stuck". Could it be newer xorg problem instead of > > individual driver problem? I am using whatever xorg was installed in > > FC3 which is somewhat dated... Also, could it be that the scroll issue > > happens only in a certain application? > > It's not a "scroll" issue. The issue is that the "up" event is getting > lost. It can be observed with any GUI elements, such as buttons. > However, since the event is delivered upon any motion, there's no > harm done with a button. Needless to say, this is not application > specific. It may be GNOME specific though. Could be as I am KDE user. > > FC-3 is far too old to be a good reference. I don't even know if it > has a usable synaptics module in its pre-modular X. You may be looking > at very different software stack. > See above. _My_ box certainly has usable synaptics module. > I don't think that you need to concern yourself with this too much > at present. If X11 people (e.g. Kristian) present evidence that kernel > fails to deliver an event, then we'll look at it. However it might > help if evtest continued to work when X11 reads from /dev/input/eventN. > It was an unpleasant surprise that it doesn't. > The driver grabs tochpad with EVIOCGRAB ioctl to prevent input events from bveing delivered to X through /dev/input/mice which is still in whidespread use. That's why evtest does not work. We could as Peter (CCed) to implement an option to turn off grabbing so users who don't use mousedev multiplexor can use evtest and other commands. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [QUICKLIST 1/5] Quicklists for page table pages V4
On Mon, Mar 26, 2007 at 10:26:51AM -0800, Andrew Morton wrote: > a) it has been demonstrated that this patch is superior to simply removing >the quicklists and Not that clameter really needs my help, but I agree with his position on several fronts, and advocate accordingly, so here is where I'm at. >From prior experience, I believe I know how to extract positive results, and that's primarily by PTE caching because they're the most frequently zeroed pagetable nodes. The upper levels of pagetables will remain in the noise until the leaf level bottleneck is dealt with. PTE's need a custom tlb.h to deal with the TLB issues noted above; the asm-generic variant will not suffice. Results above the noise level need PTE caching. Sparse fault handling (esp. after execve() is done) is one place in particular where improvements should be most readily demonstrable, as only single cachelines on each allocated node should be touched. lmbench should have a fault handling latency test for this. On Mon, Mar 26, 2007 at 10:26:51AM -0800, Andrew Morton wrote: > b) we understand why the below simple modification crashes i386. Full eager zeroing patches not dependent on quicklist code don't crash, so there is no latent use-after-free issue covered up by caching. I'll help out more on the i386 front as-needed. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] remove the broken PCI_MULTITHREAD_PROBE option
This patch removes the PCI_MULTITHREAD_PROBE option that had already
been marked as broken.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
Documentation/pci.txt|4 ---
drivers/base/dd.c| 41 ++-
drivers/pci/Kconfig | 25 ---
drivers/pci/pci-driver.c | 15 --
include/linux/device.h |1
5 files changed, 3 insertions(+), 83 deletions(-)
--- linux-2.6.21-rc4-mm1/drivers/pci/Kconfig.old2007-03-26
21:14:09.0 +0200
+++ linux-2.6.21-rc4-mm1/drivers/pci/Kconfig2007-03-26 21:14:17.0
+0200
@@ -17,31 +17,6 @@
If you don't know what to do here, say N.
-config PCI_MULTITHREAD_PROBE
- bool "PCI Multi-threaded probe (EXPERIMENTAL)"
- depends on PCI && EXPERIMENTAL && BROKEN
- help
- Say Y here if you want the PCI core to spawn a new thread for
- every PCI device that is probed. This can cause a huge
- speedup in boot times on multiprocessor machines, and even a
- smaller speedup on single processor machines.
-
- But it can also cause lots of bad things to happen. A number
- of PCI drivers cannot properly handle running in this way,
- some will just not work properly at all, while others might
- decide to blow up power supplies with a huge load all at once,
- so use this option at your own risk.
-
- It is very unwise to use this option if you are not using a
- boot process that can handle devices being created in any
- order. A program that can create persistent block and network
- device names (like udev) is a good idea if you wish to use
- this option.
-
- Again, use this option at your own risk, you have been warned!
-
- When in doubt, say N.
-
config PCI_DEBUG
bool "PCI Debugging"
depends on PCI && DEBUG_KERNEL
--- linux-2.6.21-rc4-mm1/Documentation/pci.txt.old 2007-03-26
21:33:53.0 +0200
+++ linux-2.6.21-rc4-mm1/Documentation/pci.txt 2007-03-26 21:34:01.0
+0200
@@ -124,10 +124,6 @@
err_handler See Documentation/pci-error-recovery.txt
- multithread_probe Enable multi-threaded probe/scan. Driver must
- provide its own locking/syncronization for init
- operations if this is enabled.
-
The ID table is an array of struct pci_device_id entries ending with an
all-zero entry. Each entry consists of:
--- linux-2.6.21-rc4-mm1/include/linux/device.h.old 2007-03-26
21:33:30.0 +0200
+++ linux-2.6.21-rc4-mm1/include/linux/device.h 2007-03-26 21:33:39.0
+0200
@@ -80,7 +80,6 @@
int (*resume)(struct device * dev);
unsigned int drivers_autoprobe:1;
- unsigned int multithread_probe:1;
};
extern int __must_check bus_register(struct bus_type * bus);
--- linux-2.6.21-rc4-mm1/drivers/pci/pci-driver.c.old 2007-03-26
21:29:05.0 +0200
+++ linux-2.6.21-rc4-mm1/drivers/pci/pci-driver.c 2007-03-26
21:31:00.0 +0200
@@ -14,20 +14,6 @@
#include "pci.h"
/*
- * Registration of PCI drivers and handling of hot-pluggable devices.
- */
-
-/* multithreaded probe logic */
-static int pci_multithread_probe =
-#ifdef CONFIG_PCI_MULTITHREAD_PROBE
- 1;
-#else
- 0;
-#endif
-__module_param_call("", pci_multithread_probe, param_set_bool, param_get_bool,
_multithread_probe, 0644);
-
-
-/*
* Dynamic device IDs are disabled for !CONFIG_HOTPLUG
*/
@@ -569,7 +555,6 @@
static int __init pci_driver_init(void)
{
- pci_bus_type.multithread_probe = pci_multithread_probe;
return bus_register(_bus_type);
}
--- linux-2.6.21-rc4-mm1/drivers/base/dd.c.old 2007-03-26 21:35:00.0
+0200
+++ linux-2.6.21-rc4-mm1/drivers/base/dd.c 2007-03-26 21:38:58.0
+0200
@@ -226,12 +226,10 @@
*
* Walk the list of drivers that the bus has and call
* driver_probe_device() for each pair. If a compatible
- * pair is found, break out and return. If the bus specifies
- * multithreaded probing, walking the list of drivers is done
- * on a probing thread.
+ * pair is found, break out and return.
*
* Returns 1 if the device was bound to a driver;
- * 0 if no matching device was found or multithreaded probing is done;
+ * 0 if no matching device was found;
* -ENODEV if the device is not registered.
*
* When called for a USB interface, @dev->parent->sem must be held.
@@ -239,7 +237,6 @@
int device_attach(struct device * dev)
{
int ret = 0;
- struct task_struct *probe_task = ERR_PTR(-ENOMEM);
down(>sem);
if (dev->driver) {
@@ -251,12 +248,7 @@
ret = 0;
}
} else {
- if (dev->bus->multithread_probe)
- probe_task = kthread_run(device_probe_drivers, dev,
-
[RFC: 2.6 patch] drivers/mtd/maps/nettel.c: possible cleanups
This patch contains the following possible cleanups:
- make 2 needlessly global functions static
- #if 0 the unused nettel_eraseconfig()
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/mtd/maps/nettel.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
--- linux-2.6.21-rc4-mm1/drivers/mtd/maps/nettel.c.old 2007-03-26
16:04:25.0 +0200
+++ linux-2.6.21-rc4-mm1/drivers/mtd/maps/nettel.c 2007-03-26
16:09:39.0 +0200
@@ -158,6 +158,8 @@
nettel_reboot_notifier, NULL, 0
};
+#if 0
+
/*
* Erase the configuration file system.
* Used to support the software reset button.
@@ -208,18 +210,22 @@
return(0);
}
+#endif /* 0 */
+
#else
+#if 0
int nettel_eraseconfig(void)
{
return(0);
}
+#endif /* 0 */
#endif
//
-int __init nettel_init(void)
+static int __init nettel_init(void)
{
volatile unsigned long *amdpar;
unsigned long amdaddr, maxsize;
@@ -477,7 +483,7 @@
//
-void __exit nettel_cleanup(void)
+static void __exit nettel_cleanup(void)
{
#ifdef CONFIG_MTD_CFI_INTELEXT
unregister_reboot_notifier(_notifier_block);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC: 2.6.21 patch] let PCI_MSI depend on EXPERIMENTAL
We had during the last months have quite a few MSI bugs and even regressions due to: - core kernel bugs, - device driver bugs and - hardware bugs OTOH, MSI doesn't bring any real advantages for most users. Let's therefore mark PCI_MSI as EXPERIMENTAL. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- --- linux-2.6.21-rc4-mm1/drivers/pci/Kconfig.old2007-03-26 21:04:11.0 +0200 +++ linux-2.6.21-rc4-mm1/drivers/pci/Kconfig2007-03-26 21:04:29.0 +0200 @@ -2,8 +2,8 @@ # PCI configuration # config PCI_MSI - bool "Message Signaled Interrupts (MSI and MSI-X)" - depends on PCI + bool "Message Signaled Interrupts (MSI and MSI-X) (EXPERIMENTAL)" + depends on PCI && EXPERIMENTAL depends on (X86_LOCAL_APIC && X86_IO_APIC) || IA64 || (PPC_MERGE && PPC_RTAS) || SPARC64 help This allows device drivers to enable MSI (Message Signaled - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] arch/i386/kernel/i8253.c should #include
Every file should include the headers containing the prototypes for it's global functions. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- --- linux-2.6.21-rc4-mm1/arch/i386/kernel/i8253.c.old 2007-03-26 15:58:48.0 +0200 +++ linux-2.6.21-rc4-mm1/arch/i386/kernel/i8253.c 2007-03-26 15:59:01.0 +0200 @@ -13,6 +13,7 @@ #include #include #include +#include #include "io_ports.h" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] include/linux/kprobes.h: always offer show_registers()
Allow gcc to perform show_registers() type checking also with
CONFIG_KPROBES=n.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/linux/kprobes.h |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- linux-2.6.21-rc4-mm1/include/linux/kprobes.h.old2007-03-26
15:28:27.0 +0200
+++ linux-2.6.21-rc4-mm1/include/linux/kprobes.h2007-03-26
15:32:23.0 +0200
@@ -163,7 +163,6 @@
extern void arch_arm_kprobe(struct kprobe *p);
extern void arch_disarm_kprobe(struct kprobe *p);
extern int arch_init_kprobes(void);
-extern void show_registers(struct pt_regs *regs);
extern kprobe_opcode_t *get_insn_slot(void);
extern void free_insn_slot(kprobe_opcode_t *slot, int dirty);
extern void kprobes_inc_nmissed_count(struct kprobe *p);
@@ -241,4 +240,7 @@
{
}
#endif /* CONFIG_KPROBES */
+
+void show_registers(struct pt_regs *regs);
+
#endif /* _LINUX_KPROBES_H */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] make arch/i386/kernel/setup.c:remapped_pgdat_init() static
This patch makes the needlessly global remapped_pgdat_init() static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
--- linux-2.6.21-rc4-mm1/arch/i386/kernel/setup.c.old 2007-03-26
15:53:44.0 +0200
+++ linux-2.6.21-rc4-mm1/arch/i386/kernel/setup.c 2007-03-26
15:54:00.0 +0200
@@ -476,7 +476,7 @@
*
* This should all compile down to nothing when NUMA is off.
*/
-void __init remapped_pgdat_init(void)
+static void __init remapped_pgdat_init(void)
{
int nid;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] add file position info to proc
On Sat, 24 Mar 2007 23:04:09 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote: > This patch adds support for finding out the current file position, > open flags and possibly other info in the future. fs/proc/base.c: In function 'proc_lookupfdinfo': fs/proc/base.c:1584: warning: passing argument 3 of 'proc_lookupfd_common' from incompatible pointer type fs/proc/base.c: In function 'proc_readfdinfo': fs/proc/base.c:1590: warning: passing argument 4 of 'proc_readfd_common' from incompatible pointer type If taken, that callback into proc_lookupfd_common() will crash the kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dead CONFIG variables in kernel Makefiles
On Mon, Mar 26, 2007 at 07:32:00PM -0400, Robert P. J. Day wrote: > > the output from a short script i wrote, locating all CONFIG_ > variables in makefiles that don't appear to exist in any Kconfig file > anywhere in the source tree. > > first, from the drivers/ directory: >... > = RADIO_MIROPCM20 = > ./drivers/media/radio/Makefile:obj-$(CONFIG_RADIO_MIROPCM20) += miropcm20.o > = RADIO_MIROPCM20_RDS = > ./drivers/media/radio/Makefile:obj-$(CONFIG_RADIO_MIROPCM20_RDS) += > miropcm20-rds.o >... Part of an OSS driver removal, patch for 2.6.22 already submitted. > rday cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/3] fix illogical behavior in balance_dirty_pages()
On Mon, Mar 26, 2007 at 03:30:27PM +0200, Peter Zijlstra wrote: > On Mon, 2007-03-26 at 02:08 -0800, Andrew Morton wrote: > > On Mon, 26 Mar 2007 11:32:47 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > > > > Stopping writers which have idle queues is completely unproductive, > > > and that is basically what the current algorithm does. > > > > This is because the kernel permits all of its allotment of dirty+writeback > > pages to be dirty+writeback against a single device. > > > > A good way of solving the one-device-starves-another-one problem is to > > dynamically adjust the per-device dirty+writeback levels so that (for > > example) if two devices are being written to, each gets 50% of the > > allotment. > > This is exactly what happens with my patch if both devices write at the > same speed. (Or at least, that is what is supposed to happen ;-) The testing that I did of Peter's patch showed that this cache splitting works as advertised for multiple devices writing at the same speed. (http://marc.info/?l=linux-kernel=117437686328396=2) Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
Badari Pulavarty writes: > Patch causing the problem in -mm: > ibmebus-uevent-support.patch > > I don't see where $,1rx(Bof_device_uevent$,1ry(B is defined :( That patch depends on another one from Sylvain Munaut that I haven't yet managed to get Ben H. to express an opinion on, and which isn't in -mm. I thought I mentioned that to Andrew, but maybe I only intended to... Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/3] fix illogical behavior in balance_dirty_pages()
On Mon, Mar 26, 2007 at 01:01:24AM -0800, Andrew Morton wrote: > On Mon, 26 Mar 2007 10:26:18 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > Ditto for the case, when there are no more dirty pages destined for > > this queue. > > > > I understand, that this can fill up the memory with under writeback > > pages, but only if the data sitting in all the device queues is > > comparable to the total memory. I don't know what the realistic > > chance of that is but David Chinner convinced me, that it's not > > something that happens in real life. Quoting him from an earlier > > mail: > > > > | Right, and most ppl don't have enough devices in their system for > > | this to be a problem. Even those of us that do have enough devices > > | for this to potentially be a problem usually have enough RAM in > > | the machine so that it is not a problem > > > > David is overoptimistic ;) My excuse is that I have trouble thinking in units of memory smaller than a GB. ;) Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.21-rc5] MSI: read-flush MSI-X table
On Mon, Mar 26, 2007 at 04:18:22PM -0700, Mitch Williams wrote: > This patch fixes a kernel bug which is triggered when using the > irqbalance daemon with MSI-X hardware. > > Because both MSI-X interrupt messages and MSI-X table writes are posted, > it's possible for them to cross while in-flight. This results in > interrupts being received long after the kernel thinks they're disabled, > and in interrupts being sent to stale vectors after rebalancing. > > This patch performs a read flush after writes to the MSI-X table for > enable/disable and rebalancing operations. Because this is an expensive > operation, we do not perform the read flush after mask/unmask > operations. Hardware which supports MSI-X typically also supports some > sort of interrupt moderation, so a read-flush is not necessary for > mask/unmask operations. > > This patch has been validated with (unreleased) network hardware which > uses MSI-X. How well does this play with the MSI core changes that Michael Ellerman has proposed on the linux-pci mailing list? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/3] only allow nonlinear vmas for ram backed filesystems
On Sat, 2007-03-24 at 23:09 +0100, Miklos Szeredi wrote: >>> Dirty page accounting/limiting doesn't work for nonlinear mappings, so >>> for non-ram backed filesystems emulate with linear mappings. This >>> retains ABI compatibility with previous kernels at minimal code cost. >>> All known users of nonlinear mappings actually use tmpfs, so this >>> shouldn't have any negative effect. On Sun, Mar 25, 2007 at 02:12:32PM +0200, Peter Zijlstra wrote: On Sun, Mar 25, 2007 at 10:51:27AM -0500, Matt Mackall wrote: > They do? I thought the whole point of nonlinear mappings was for > mapping files bigger than the address space (eg. databases). Is Oracle > instead using this to map >3G files on a tmpfs?? It's used for > 3GB files on tmpfs and also ramfs, sometimes substantially larger than 3GB. It's not used for the database proper. It's used for the buffer pool, which is the in-core destination and source of direct I/O, the on-disk source and destination of the I/O being the database. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] Blackfin: rtc fix rtc_update_irq augument
On 3/26/07, Wu, Bryan <[EMAIL PROTECTED]> wrote: Replacing class_dev to directly using rtc_dev. Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]> -mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dead CONFIG variables in kernel Makefiles
From: "Robert P. J. Day" <[EMAIL PROTECTED]> Date: Mon, 26 Mar 2007 19:32:00 -0400 (EDT) > > the output from a short script i wrote, locating all CONFIG_ > variables in makefiles that don't appear to exist in any Kconfig file > anywhere in the source tree. > > first, from the drivers/ directory: > > = DRM_FFB = > ./drivers/char/drm/Makefile:obj-$(CONFIG_DRM_FFB) += ffb.o I'll take care of this one, thanks Robert. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH update/RFC] ieee1394: eth1394: don't autoload by hotplug when ohci1394 starts
I wrote:
> - add a new kernel config option which brings back the old behavior
> for those who liked it. We don't re-use the old config option
> because then nobody would notice that there is a choice now. This
> new option is scheduled to be removed soon.
...
> Instead of keeping this until the proposed date of removal (June 2007),
> should I kill CONFIG_IEEE1394_AUTOLOAD_ETH1394 right away?
>
>
> Documentation/feature-removal-schedule.txt |9 +++
> drivers/ieee1394/Kconfig | 49 -
> drivers/ieee1394/config_roms.c | 47 +++-
> drivers/ieee1394/config_roms.h | 10
> drivers/ieee1394/eth1394.c |9 +++
> 5 files changed, 91 insertions(+), 33 deletions(-)
If I skip the feature-removal-schedule procedure, the resulting code is
a lot nicer. I prefer this updated patch and I consider it a candidate
for before 2.6.22-rc1.
From: Stefan Richter <[EMAIL PROTECTED]>
Subject: ieee1394: eth1394: don't autoload by hotplug when ohci1394 starts
Until now, ieee1394 put an IP-over-1394 capability entry into each new
host's config ROM. As soon as the controller was initialized --- i.e.
right after modprobe ohci1394 --- this entry triggered a hotplug event
which typically caused auto-loading of eth1394.
This irritated or annoyed many users and distributors. Of course they
could blacklist eth1394, but then ieee1394 wrongly advertized IP-over-
1394 capability to the FireWire bus.
Therefore
- remove the offending kernel config option
IEEE1394_CONFIG_ROM_IP1394,
- let eth1394 add the ROM entry by itself, i.e. only after eth1394 was
loaded.
This fixes http://bugzilla.kernel.org/show_bug.cgi?id=7793 .
Autoloading of eth1394 when an _external_ IP-over-1394 capable device is
discovered is _not_ affected by this patch.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/ieee1394/Kconfig | 29 +++-
drivers/ieee1394/config_roms.c | 76 ++---
drivers/ieee1394/config_roms.h |7 ++-
drivers/ieee1394/eth1394.c |7 ++-
drivers/ieee1394/hosts.c |3 -
5 files changed, 36 insertions(+), 86 deletions(-)
Index: linux/drivers/ieee1394/Kconfig
===
--- linux.orig/drivers/ieee1394/Kconfig
+++ linux/drivers/ieee1394/Kconfig
@@ -36,23 +36,6 @@ config IEEE1394_VERBOSEDEBUG
Say Y if you really want or need the debugging output, everyone
else says N.
-config IEEE1394_EXTRA_CONFIG_ROMS
- bool "Build in extra config rom entries for certain functionality"
- depends on IEEE1394
- help
- Some IEEE1394 functionality depends on extra config rom entries
- being available in the host adapters CSR. These options will
- allow you to choose which ones.
-
-config IEEE1394_CONFIG_ROM_IP1394
- bool "IP-1394 Entry"
- depends on IEEE1394_EXTRA_CONFIG_ROMS && IEEE1394
- help
- Adds an entry for using IP-over-1394. If you want to use your
- IEEE1394 bus as a network for IP systems (including interacting
- with MacOSX and WinXP IP-over-1394), enable this option and the
- eth1394 option below.
-
comment "Device Drivers"
depends on IEEE1394
@@ -122,11 +105,15 @@ config IEEE1394_SBP2_PHYS_DMA
This option is buggy and currently broken on some architectures.
If unsure, say N.
+config IEEE1394_ETH1394_ROM_ENTRY
+ depends on IEEE1394
+ bool
+ default n
+
config IEEE1394_ETH1394
- tristate "Ethernet over 1394"
+ tristate "IP over 1394"
depends on IEEE1394 && EXPERIMENTAL && INET
- select IEEE1394_CONFIG_ROM_IP1394
- select IEEE1394_EXTRA_CONFIG_ROMS
+ select IEEE1394_ETH1394_ROM_ENTRY
help
This driver implements a functional majority of RFC 2734: IPv4 over
1394. It will provide IP connectivity with implementations of RFC
@@ -135,6 +122,8 @@ config IEEE1394_ETH1394
This driver is still considered experimental. It does not yet support
MCAP, therefore multicast support is significantly limited.
+ The module is called eth1394 although it does not emulate Ethernet.
+
config IEEE1394_DV1394
tristate "OHCI-DV I/O support (deprecated)"
depends on IEEE1394 && IEEE1394_OHCI1394
Index: linux/drivers/ieee1394/config_roms.c
===
--- linux.orig/drivers/ieee1394/config_roms.c
+++ linux/drivers/ieee1394/config_roms.c
@@ -26,12 +26,6 @@ struct hpsb_config_rom_entry {
/* Base initialization, called at module load */
int (*init)(void);
- /* Add entry to specified host */
- int (*add)(struct hpsb_host *host);
-
- /* Remove entry from specified host */
- void (*remove)(struct hpsb_host *host);
-
/* Cleanup called at
Re: dead CONFIG variables in kernel Makefiles
> = IPATH_CORE = > ./drivers/Makefile:obj-$(CONFIG_IPATH_CORE) += infiniband/ Thanks, I was just noticing that myself. I'll remove it for 2.6.22. - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
dead CONFIG variables in kernel Makefiles
the output from a short script i wrote, locating all CONFIG_ variables in makefiles that don't appear to exist in any Kconfig file anywhere in the source tree. first, from the drivers/ directory: = DRM_FFB = ./drivers/char/drm/Makefile:obj-$(CONFIG_DRM_FFB) += ffb.o = INPUT_POWER = ./drivers/input/Makefile:obj-$(CONFIG_INPUT_POWER) += power.o = IPATH_CORE = ./drivers/Makefile:obj-$(CONFIG_IPATH_CORE) += infiniband/ = L7200_KEYB = ./drivers/acorn/char/Makefile:obj-$(CONFIG_L7200_KEYB) += defkeymap-l7200.o keyb_l7200.o = RADIO_MIROPCM20 = ./drivers/media/radio/Makefile:obj-$(CONFIG_RADIO_MIROPCM20) += miropcm20.o = RADIO_MIROPCM20_RDS = ./drivers/media/radio/Makefile:obj-$(CONFIG_RADIO_MIROPCM20_RDS) += miropcm20-rds.o = SCSI_FD_8xx = ./drivers/scsi/Makefile:obj-$(CONFIG_SCSI_FD_8xx) += seagate.o = USB_EGALAX = ./drivers/usb/input/Makefile:obj-$(CONFIG_USB_EGALAX) += touchkitusb.o = USB_ITMTOUCH = ./drivers/usb/input/Makefile:obj-$(CONFIG_USB_ITMTOUCH) += itmtouch.o = USB_MTOUCH = ./drivers/usb/Makefile:obj-$(CONFIG_USB_MTOUCH) += input/ ./drivers/usb/input/Makefile:obj-$(CONFIG_USB_MTOUCH) += mtouchusb.o = USB_OHCI_AT91 = ./drivers/usb/Makefile:obj-$(CONFIG_USB_OHCI_AT91) += host/ = ZS = ./drivers/tc/Makefile:obj-$(CONFIG_ZS) += zs.o and from the fs/ directory: = NLS_ABC = ./fs/nls/Makefile:obj-$(CONFIG_NLS_ABC) += nls_abc.o = NLS_ISO8859_10 = ./fs/nls/Makefile:obj-$(CONFIG_NLS_ISO8859_10) += nls_iso8859-10.o rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, Mar 26, 2007 at 09:35:48PM +0200, Jean Delvare wrote: > > Greg, please update your copy with this version of the patch. The only > change is that sound/ppc/beep.c is removed from the patch. Done. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.21-rc5] MSI: read-flush MSI-X table
This patch fixes a kernel bug which is triggered when using the
irqbalance daemon with MSI-X hardware.
Because both MSI-X interrupt messages and MSI-X table writes are posted,
it's possible for them to cross while in-flight. This results in
interrupts being received long after the kernel thinks they're disabled,
and in interrupts being sent to stale vectors after rebalancing.
This patch performs a read flush after writes to the MSI-X table for
enable/disable and rebalancing operations. Because this is an expensive
operation, we do not perform the read flush after mask/unmask
operations. Hardware which supports MSI-X typically also supports some
sort of interrupt moderation, so a read-flush is not necessary for
mask/unmask operations.
This patch has been validated with (unreleased) network hardware which
uses MSI-X.
Generated from 2.6.21-rc4; applies cleanly to 2.6.21-rc5.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.21-rc4-clean/arch/i386/kernel/io_apic.c
linux-2.6.21-rc4/arch/i386/kernel/io_apic.c
--- linux-2.6.21-rc4-clean/arch/i386/kernel/io_apic.c 2007-03-19
16:16:30.0 -0700
+++ linux-2.6.21-rc4/arch/i386/kernel/io_apic.c 2007-03-19 16:24:05.0
-0700
@@ -2594,6 +2594,8 @@ static void set_msi_irq_affinity(unsigne
*/
static struct irq_chip msi_chip = {
.name = "PCI-MSI",
+ .enable = enable_msi_irq,
+ .disable= disable_msi_irq,
.unmask = unmask_msi_irq,
.mask = mask_msi_irq,
.ack= ack_ioapic_irq,
diff -urpN -X dontdiff linux-2.6.21-rc4-clean/arch/ia64/kernel/msi_ia64.c
linux-2.6.21-rc4/arch/ia64/kernel/msi_ia64.c
--- linux-2.6.21-rc4-clean/arch/ia64/kernel/msi_ia64.c 2007-03-19
16:16:30.0 -0700
+++ linux-2.6.21-rc4/arch/ia64/kernel/msi_ia64.c2007-03-19
16:24:05.0 -0700
@@ -121,6 +121,8 @@ static int ia64_msi_retrigger_irq(unsign
*/
static struct irq_chip ia64_msi_chip = {
.name = "PCI-MSI",
+ .enable = enable_msi_irq,
+ .disable= disable_msi_irq,
.mask = mask_msi_irq,
.unmask = unmask_msi_irq,
.ack= ia64_ack_msi_irq,
diff -urpN -X dontdiff linux-2.6.21-rc4-clean/arch/ia64/sn/kernel/msi_sn.c
linux-2.6.21-rc4/arch/ia64/sn/kernel/msi_sn.c
--- linux-2.6.21-rc4-clean/arch/ia64/sn/kernel/msi_sn.c 2007-03-19
16:16:30.0 -0700
+++ linux-2.6.21-rc4/arch/ia64/sn/kernel/msi_sn.c 2007-03-19
16:24:05.0 -0700
@@ -224,6 +224,8 @@ static int sn_msi_retrigger_irq(unsigned
static struct irq_chip sn_msi_chip = {
.name = "PCI-MSI",
+ .enable = enable_msi_irq,
+ .disable= disable_msi_irq,
.mask = mask_msi_irq,
.unmask = unmask_msi_irq,
.ack= sn_ack_msi_irq,
diff -urpN -X dontdiff linux-2.6.21-rc4-clean/arch/x86_64/kernel/io_apic.c
linux-2.6.21-rc4/arch/x86_64/kernel/io_apic.c
--- linux-2.6.21-rc4-clean/arch/x86_64/kernel/io_apic.c 2007-03-19
16:16:31.0 -0700
+++ linux-2.6.21-rc4/arch/x86_64/kernel/io_apic.c 2007-03-21
12:44:51.0 -0700
@@ -1942,6 +1942,7 @@ static void set_msi_irq_affinity(unsigne
if (cpus_empty(tmp))
return;
+ msix_flush_writes(irq);
if (assign_irq_vector(irq, mask))
return;
@@ -1956,6 +1957,7 @@ static void set_msi_irq_affinity(unsigne
msg.address_lo |= MSI_ADDR_DEST_ID(dest);
write_msi_msg(irq, );
+ msix_flush_writes(irq);
irq_desc[irq].affinity = mask;
}
#endif /* CONFIG_SMP */
@@ -1966,6 +1968,8 @@ static void set_msi_irq_affinity(unsigne
*/
static struct irq_chip msi_chip = {
.name = "PCI-MSI",
+ .enable = enable_msi_irq,
+ .disable= disable_msi_irq,
.unmask = unmask_msi_irq,
.mask = mask_msi_irq,
.ack= ack_apic_edge,
diff -urpN -X dontdiff linux-2.6.21-rc4-clean/drivers/pci/msi.c
linux-2.6.21-rc4/drivers/pci/msi.c
--- linux-2.6.21-rc4-clean/drivers/pci/msi.c2007-03-19 16:16:32.0
-0700
+++ linux-2.6.21-rc4/drivers/pci/msi.c 2007-03-21 12:44:51.0 -0700
@@ -68,6 +68,29 @@ static void msix_set_enable(struct pci_d
}
}
+void msix_flush_writes(unsigned int irq)
+{
+ struct msi_desc *entry;
+
+ entry = get_irq_msi(irq);
+ BUG_ON(!entry || !entry->dev);
+ switch (entry->msi_attrib.type) {
+ case PCI_CAP_ID_MSI:
+ /* nothing to do */
+ break;
+ case PCI_CAP_ID_MSIX:
+ {
+ int offset = entry->msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE +
+ PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET;
+ readl(entry->mask_base + offset);
+ break;
+ }
+ default:
+ BUG();
+ break;
+ }
+}
+
static
[PATCH] ieee1394: eth1394: don't autoload by hotplug when ohci1394 starts
Until now, ieee1394 put an IP-over-1394 capability entry into each new host's config ROM. As soon as the controller was initialized --- i.e. right after modprobe ohci1394 --- this entry triggered a hotplug event which typically caused auto-loading of eth1394. This irritated or annoyed many users and distributors. Of course they could blacklist eth1394, but then ieee1394 wrongly advertized IP-over- 1394 capability to the FireWire bus. Therefore - remove the offending kernel config option IEEE1394_CONFIG_ROM_IP1394, - let eth193 add the ROM entry by itself, i.e. only after eth1394 was loaded, - add a new kernel config option which brings back the old behavior for those who liked it. We don't re-use the old config option because then nobody would notice that there is a choice now. This new option is scheduled to be removed soon. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=7793 . Autoloading of eth1394 when an _external_ IP-over-1394 capable device is discovered is _not_ affected by this patch. Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> --- Instead of keeping this until the proposed date of removal (June 2007), should I kill CONFIG_IEEE1394_AUTOLOAD_ETH1394 right away? Documentation/feature-removal-schedule.txt |9 +++ drivers/ieee1394/Kconfig | 49 - drivers/ieee1394/config_roms.c | 47 +++- drivers/ieee1394/config_roms.h | 10 drivers/ieee1394/eth1394.c |9 +++ 5 files changed, 91 insertions(+), 33 deletions(-) Index: linux/Documentation/feature-removal-schedule.txt === --- linux.orig/Documentation/feature-removal-schedule.txt +++ linux/Documentation/feature-removal-schedule.txt @@ -29,6 +29,15 @@ Who: Adrian Bunk <[EMAIL PROTECTED]> --- +What: eth1394 autoloading (CONFIG_IEEE1394_AUTOLOAD_ETH1394) +When: June 2007 +Why: Can be emulated by adding the following lines to /etc/modprobe.conf: + install ohci1394 /sbin/modprobe eth1394; \ +/sbin/modprobe --ignore-install ohci1394" +Who: Stefan Richter <[EMAIL PROTECTED]> + +--- + What: raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN When: June 2007 Why: Deprecated in favour of the more efficient and robust rawiso interface. Index: linux/drivers/ieee1394/Kconfig === --- linux.orig/drivers/ieee1394/Kconfig +++ linux/drivers/ieee1394/Kconfig @@ -36,23 +36,6 @@ config IEEE1394_VERBOSEDEBUG Say Y if you really want or need the debugging output, everyone else says N. -config IEEE1394_EXTRA_CONFIG_ROMS - bool "Build in extra config rom entries for certain functionality" - depends on IEEE1394 - help - Some IEEE1394 functionality depends on extra config rom entries - being available in the host adapters CSR. These options will - allow you to choose which ones. - -config IEEE1394_CONFIG_ROM_IP1394 - bool "IP-1394 Entry" - depends on IEEE1394_EXTRA_CONFIG_ROMS && IEEE1394 - help - Adds an entry for using IP-over-1394. If you want to use your - IEEE1394 bus as a network for IP systems (including interacting - with MacOSX and WinXP IP-over-1394), enable this option and the - eth1394 option below. - comment "Device Drivers" depends on IEEE1394 @@ -122,11 +105,15 @@ config IEEE1394_SBP2_PHYS_DMA This option is buggy and currently broken on some architectures. If unsure, say N. +config IEEE1394_ETH1394_ROM_ENTRY + depends on IEEE1394 + bool + default n + config IEEE1394_ETH1394 - tristate "Ethernet over 1394" + tristate "IP over 1394" depends on IEEE1394 && EXPERIMENTAL && INET - select IEEE1394_CONFIG_ROM_IP1394 - select IEEE1394_EXTRA_CONFIG_ROMS + select IEEE1394_ETH1394_ROM_ENTRY help This driver implements a functional majority of RFC 2734: IPv4 over 1394. It will provide IP connectivity with implementations of RFC @@ -135,6 +122,28 @@ config IEEE1394_ETH1394 This driver is still considered experimental. It does not yet support MCAP, therefore multicast support is significantly limited. + The module is called eth1394 although it does not emulate Ethernet. + +config IEEE1394_AUTOLOAD_ETH1394 + bool "Autoload IP over 1394 (deprecated)" + depends on IEEE1394_ETH1394 + help + This lets the ieee1394 base driver include an IP-over-1394 in the + configuration ROM of each FireWire controller even before eth1394 was + loaded. As a result, a hotplug event will follow after initialization + of the controller which will typically cause eth1394 to be
Re: [PATCH 2.6.16.44] ieee1394: dv1394: fix CardBus card ejection
On Sun, Mar 25, 2007 at 09:26:05PM +0200, Stefan Richter wrote: > Fix NULL pointer dereference on hot ejection of a FireWire card while > dv1394 was loaded. http://bugzilla.kernel.org/show_bug.cgi?id=7121 > I did not test card ejection with open /dev/dv1394 files yet. >... Thanks, applied. > Stefan Richter cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, 2007-03-26 at 15:22 -0700, Andrew Morton wrote:
..
> > Unable to handle kernel NULL pointer dereference at 0020
> > RIP:
> > [] __sched_text_start+0x460/0x889
> > PGD 1c1898067 PUD 1c1897067 PMD 0
> > Oops: [1] SMP
> > last sysfs file: block/hda/range
> > CPU 3
> > Modules linked in:
> > Pid: 900, comm: boot Not tainted 2.6.21-rc4-mm1 #1
> > RIP: 0010:[] [] __sched_text_start
>
> This is a very popular oops, caused by the rsdl scheduler. I don't _think_
> we yet know exactly why it is happening. Con, did you get to the bottom
> of this?
>
> We don't know why it confused kallsyms either.
>
> I'll try to shove rc5-mm1 out the door this evening, minus rsdl. And
> -mm2, with rsdl.
Okay, my ppc64 box hangs on boot. It could be different. I will wait
till rc5-mm1 for debugging that one.
Thanks,
Badari
...
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
ReiserFS: sda2: found reiserfs format "3.6" with standard journal
ReiserFS: sda2: using ordered data mode
ReiserFS: sda2: journal params: device sda2, size 8192, journal first
block 18, max trans len 1024, max batch 900, max commit age 30, max
trans age 30
ReiserFS: sda2: checking transaction log (sda2)
ReiserFS: sda2: Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 272k freed
Warning: unable to open an initial console.
ioctl32(showconsole:1020): Unknown cmd fd(0) cmd(40045432){00} arg
(ffecdb48) on /dev/tty0
ioctl32(showconsole:1048): Unknown cmd fd(0) cmd(40045432){00} arg
(ffb4aad8) on /dev/tty0
PDC20275: IDE controller at PCI slot 0002:d0:01.0
PDC20275: chipset revision 1
PDC20275: PLL input clock is 32814 kHz
PDC20275: 100% native mode on irq 119
ide2: BM-DMA at 0x2eec00-0x2eec07, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0x2eec08-0x2eec0f, BIOS settings: hdg:pio, hdh:pio
scsi 0:0:15:0: Attached scsi generic sg0 type 13
scsi 0:255:255:255: Attached scsi generic sg1 type 31
sd 1:0:4:0: Attached scsi generic sg2 type 0
sd 1:0:5:0: Attached scsi generic sg3 type 0
scsi 1:0:15:0: Attached scsi generic sg4 type 13
scsi 1:255:255:255: Attached scsi generic sg5 type 31
hde: IBM DROM00205, ATAPI CD/DVD-ROM drive
ide2 at 0x2ee400-0x2ee407,0x2edc02 on irq 119
hde: ATAPI 24X DVD-ROM drive, 256kB Cache
Uniform CD-ROM driver Revision: 3.20
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-
[EMAIL PROTECTED]
ioctl32(showconsole:1918): Unknown cmd fd(0) cmd(40045432){00} arg
(fff00ad8) on /dev/tty0
loop: loaded (max 8 devices)
ioctl32(showconsole:2091): Unknown cmd fd(0) cmd(40045432){00} arg
(fff71ae8) on /dev/tty0
Adding 1050616k swap on /dev/sdb2. Priority:-1 extents:1
across:1050616k
ioctl32(showconsole:2137): Unknown cmd fd(0) cmd(40045432){00} arg
(ffdd7b28) on /dev/tty0
e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX
audit(1174945021.442:2): audit_pid=2735 old=0 by auid=4294967295
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] Blackfin: spi driver cleanup and coding style fixing
On Monday 26 March 2007 3:14 am, Wu, Bryan wrote:
> Hi folks,
>
> This patch cleanup blackfin SPI driver code and fix some coding style
> problems.
Good, thanks. I'll forward the current state of my review, after
I cross-check it against these two patches.
That'll mean I need to re-start that review ... at that point it'd
be better to start with a single clean patch.
> -#ifdef DEBUG
> -#define ASSERT(expr) \
> - if (!(expr)) { \
> - printk(KERN_DEBUG "assertion failed! %s[%d]: %s\n", \
> -__FUNCTION__, __LINE__, #expr); \
> - panic(KERN_DEBUG "%s", __FUNCTION__); \
> - }
> -#else
> -#define ASSERT(expr)
> -#endif
Yes, that was certainly in the "remove that" category.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] possible USB regression with 2.6.21-rc4: iPod doesn't work
On Tue, Mar 27, 2007 at 00:21:24 +0200, Tino Keitel wrote: [...] > this is the bisect result: > > $ git bisect good > 1d619f128ba911cd3e6d6ad3475f146eb92f5c27 is first bad commit > commit 1d619f128ba911cd3e6d6ad3475f146eb92f5c27 I just tested 2.6.21-rc5 with this commit reverted and the iPod was regognized with CONFIG_USB_SUSPEND enabled. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch resend v4] update ctime and mtime for mmaped write
On Mon, 26 Mar 2007 23:43:08 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > > This patch makes writing to shared memory mappings update st_ctime and > > > st_mtime as defined by SUSv3: > > > > Boy this is complicated. > > You tell me? > > > Is there a simpler way of doing all this? Say, we define a new page flag > > PG_dirtiedbywrite and we do SetPageDirtiedByWrite() inside write() and > > ClearPageDirtiedByWrite() whenever we propagate pte-dirtiness into > > page-dirtiness. Then, when performing writeback we look to see if any of > > the dirty pages are !PageDirtiedByWrite() and, if so, we update [mc]time to > > current-time. > > I don't think a page flag gains anything over the address_space flag > that this patch already has. > > The complexity is not about keeping track of the "data modified > through mmap" state, but about msync() guarantees, that POSIX wants. > > And these requirements do in fact make some sense: msync() basically > means: > > "I want the data written through mmaps to be visible to the world" > > And that obviously includes updating the timestamps. > > So how do we know if the data was modified between two msync() > invocations? The only sane way I can think of is to walk the page > tables in msync() and test/clear the pte dirty bit. clear_page_dirty_for_io() already does that. So we should be able to test PageDirtiedByWrite() after running clear_page_dirty_for_io() to discover whether this page was dirtied via MAP_SHARED, and then update the inode times if so. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.21-rc5 1/3] parport->dev driver model support
On Monday 26 March 2007 2:59 pm, Andrew Morton wrote: > On Mon, 26 Mar 2007 09:06:19 -0700 > David Brownell <[EMAIL PROTECTED]> wrote: > > > Currently a parport_driver can't get a handle on the device node for the > > underlying parport (PNPACPI, PCI, etc). That prevents correct placement > > of sysfs child nodes, which can affect things like power management. > > > > This patch adds a field to "struct parport" pointing to that device node, > > and updates non-legacy port drivers to initialize that device pointer. > > That field replaces the analagous PCI-only support in parport_pc. > > > > Signed-off-by: David Brownell <[EMAIL PROTECTED]> > > --- > > NOTE this depends on an earlier patch to make pnp devices set up DMA, > > parport is the primary user of legacy i8237 dma infrastructure. > > Confusion reigns. > > To which "earlier patch" do you refer? The one named "init-dma-masks-in-pnp_dev.patch" in 2.6.21-rc4-mm1 ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch resend v4] update ctime and mtime for mmaped write
On Mon, 26 Mar 2007 16:10:09 -0500 Matt Mackall <[EMAIL PROTECTED]> wrote: > On Mon, Mar 26, 2007 at 02:00:36PM -0700, Andrew Morton wrote: > > On Sun, 25 Mar 2007 23:10:21 +0200 > > Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > > > > This patch makes writing to shared memory mappings update st_ctime and > > > st_mtime as defined by SUSv3: > > > > Boy this is complicated. > > > > Is there a simpler way of doing all this? Say, we define a new page flag > > PG_dirtiedbywrite and we do SetPageDirtiedByWrite() inside write() and > > ClearPageDirtiedByWrite() whenever we propagate pte-dirtiness into > > page-dirtiness. Then, when performing writeback we look to see if any of > > the dirty pages are !PageDirtiedByWrite() and, if so, we update [mc]time to > > current-time. > > > > Or something like that - I'm just thinking out loud and picking holes in > > the above doesn't shut me up ;) We're adding complexity and some overhead > > and we're losing our recent msync() simplifications and this all hurts. Is > > there some other way? I think burning a page flag to avoid this additional > > complexity would be worthwhile. > > Aren't we basically out of those? Rafael has liberated a couple of the flags which swsusp was using. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, 26 Mar 2007 13:57:57 -0800 Badari Pulavarty <[EMAIL PROTECTED]> wrote: > On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote: > > Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ > > > > Will appear later at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ > > > > > Panics my x86-64 box. 2.6.21-rc4 works fine. > Ideas on where to start ? Bisect ? > > Thanks, > Badari > > .. > ReiserFS: hda2: found reiserfs format "3.6" with standard journal > ReiserFS: hda2: using ordered data mode > ReiserFS: hda2: journal params: device hda2, size 8192, journal first > block 18, max trans len 1024, max batch 900, max commit age 30, max > trans age 30 > ReiserFS: hda2: checking transaction log (hda2) > ReiserFS: hda2: Using r5 hash to sort names > VFS: Mounted root (reiserfs filesystem) readonly. > Freeing unused kernel memory: 376k freed > INIT: version 2.86 booting > Unable to handle kernel NULL pointer dereference at 0020 > RIP: > [] __sched_text_start+0x460/0x889 > PGD 1c1898067 PUD 1c1897067 PMD 0 > Oops: [1] SMP > last sysfs file: block/hda/range > CPU 3 > Modules linked in: > Pid: 900, comm: boot Not tainted 2.6.21-rc4-mm1 #1 > RIP: 0010:[] [] __sched_text_start This is a very popular oops, caused by the rsdl scheduler. I don't _think_ we yet know exactly why it is happening. Con, did you get to the bottom of this? We don't know why it confused kallsyms either. I'll try to shove rc5-mm1 out the door this evening, minus rsdl. And -mm2, with rsdl. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
