Re: [patch] block: fix blktrace timestamps
* Jens Axboe <[EMAIL PROTECTED]> wrote: > > - Fact: feature CONFIG_CPU_IDLE=y did not exist in 64-bit x86 in v2.6.23. > > It has known bugs but they are not flagged 'regressions' (because the > > feature did not exist before and the option is default-disabled) hence > > the feature can stay. Some fixes to it are too dangerous or too > > unproven and are delayed to v2.6.25. > > > > > and now apply the same rule to CONFIG_NO_HZ: > > > > - Fact: feature CONFIG_NO_HZ=y did not exist in 64-bit x86 in v2.6.23. > > It has known bugs but they are not flagged 'regressions' (because the > > feature did not exist before and the option is default-disabled) hence > > the feature can stay. Some fixes to it are too dangerous or too > > unproven and are delayed to v2.6.25. > > Forget about this unrelated feature, it has nothing to do with this > situation. [...] why "forget" about a perfectly valid example right from v2.6.24 that demonstrates our definition for regressions and demonstrates the rules we are applying? Because it does not fit your argument? :) > [...] What if some (eg) sata driver broke because someone enabled > CONFIG_NO_HZ. Would you say that's not a regression because it worked > before that option was there? [...] as long as it's the same situation as have here (i.e. that NO_HZ appeared on an architecture where it wasnt offered before): yes, exactly, it's _NOT_ a regression in that sata driver [the sata driver might not even have been touched], and it's _NOT_ a regression in CONFIG_NO_HZ either because a regression can only be something that "something breaks that worked before". In that case it's a _bug_ in the newly introduced NO_HZ code. > [...] That's crap, no user would buy that argument. As far as the user > is concerned, it IS a regression. the user enabled a newly introduced kernel feature and that new feature might be not perfect. It might break a whole lot of unrelated code. We consider them bugs (of course), and work on fixing them, but still we dont consider such bugs a regression and dont revert a new feature if it's not fixed. It's a special-case. We apply that special case to all sorts of new kernel features, such as the new iwl3945 driver in 2.6.24, which has a number of unfixed bugs. We applied that to new kernel features as well, such as containers/control-groups in 2.6.23, etc. This is nothing new, we did this numerous times ever since the new-style development model was introduced around 2.6.12. _You_ might not know about it but that does not change the situation. because a perfectly working system is: "a user's .config that worked before should work with the new kernel too" not: "a user's .config that worked before should work now too, with random new kernel features enabled as well." the latter appears to be the rule you are applying, but it's not the regression rule we are using. > Since we obviously disagree on this, lets agree to not debate it any > further. It doesn't matter anyway, since the issue is resolved. this is not a matter of opinion or "disagreement", this is a matter of fact. You were the one telling me: "go fix that regression", so this issue might come up anytime in the future. Better clear it once and for all, we all have got better things to do than to rehash the same issue again and again. Ingo -- 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] CRIS v10: Correct do_signal to fix oops and clean up signal handling in general.
On Fri, Jan 11, 2008 at 03:45:13PM -0800, Andrew Morton wrote: > On Fri, 11 Jan 2008 19:59:24 +0100 > Jesper Nilsson <[EMAIL PROTECTED]> wrote: > > > CRIS v10: Correct do_signal to fix oops and clean up signal handling in > > general. > > > > This fixes a kernel panic on boot due to do_signal not being compatible > > with it's callers. > > Please sequence-number patches even if they are unrelated. That will make > emails like this one easier. Yes, sorry about that, they should have been sequenced. > 1: CRIS v10: Correct do_signal to fix oops and clean up signal handling in > general. > 2: CRIS: Define __ARCH_WANT_SYS_RT_SIGSUSPEND in unistd.h for CRIS > 3: CRIS v10: kernel/time.c needs to include linux/vmstat.h to compile. > 4: CRIS v10: Driver for ds1302 needs to include cris-specific i2c.h > > Patches 3 and 4 were missing your signed-off-by:. I added it. > > I queued patches 1, 3 and 4 for 2.6.24 and patch 2 for 2.6.25. Do you agree? All four should be queued for 2.6.24 since patch 2 is needed if patch 1 is included, otherwise sys_rt_sigsuspend will be undefined causing a link error. Thanks! /^JN - Jesper Nilsson -- Jesper Nilsson -- [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: [PATCH] Fix kprobes on ia64
On Sun, Jan 13, 2008 at 07:24:24PM -0700, Matthew Wilcox wrote: > If CONFIG_KPROBES is set, we get the error during build: > > kernel/kprobes.c:1057: error: __ksymtab_jprobe_return causes a section > type conflict > > This is because ia64 defines a static inline jprobe_return which kprobes > attempts to EXPORT_SYMBOL. Given that jprobe_return is defined in the arch-specific kprobes.c file it would be better to export it there instead of in kernel/kprobe.c, or in case of ia64 not export it at all. -- 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] watchdog on gpio
On Friday 11 January 2008, Florian Fainelli wrote:
> Hello Marc,
>
> Your patch looks good to me, and I have been waiting for something like
> this :). Other comments below.
>
> Le jeudi 10 janvier 2008, Marc Pignat a écrit :
> > +#include
> > +#include
>
> At first sight, this will only work with the platforms which have implemented
> gpiolib, some (like MIPS) still use the old generic GPIO API. So I think the
> include will not work here for anything than ARM, correct me if I am wrong.
find arch -name "Kconfig" -exec grep -q "GENERIC_GPIO" {} \; -print
arch/arm/Kconfig
arch/mips/Kconfig
arch/avr32/Kconfig
arch/blackfin/Kconfig
It seems that no only arm are using GENERIC_GPIO, even some mips chips.
I probably missed wirting the subject right, should be "watchdog on
GENERIC_GPIO" :)
...
>
> Did you look into hooking into Wim's uniform watchdog driver :
>
> http://git.kernel.org/?p=linux/kernel/git/wim/linux-2.6-watchdog-experimental.git;a=commit;h=732c54027e6c866f98857c4a6d1c6c466459dcd5
Now yes, interesting!
Regards
Marc
--
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: The ext3 way of journalling
On 2008-01-13 18:11 -0500, Theodore Tso wrote: > It's much more likely that this early in your boot cycle, your clock is > sometimes incorrect. I doubt it. I get this nearly _always_ when the system crashes, which accounts for the vast majority of the times I boot it. (I wish swsusp didn't suck so much..) > Is the "9192" number roughly constant, or is it always changing? No. That's the number I got last time, but typically I've got something in the 3 range. > If your machine is on the network, then the "ntpdate" > program could be setting your time so that it looks correct, but > that's after e2fsck is run. ntpdate isn't run by any of the init scripts. ntpd is, but like I already mentioned, I doubt it would correct vastly incorrect time, not even being able to track and correct when it advances fast. -- Tuomo -- 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: [Bluez-devel] Oops involving RFCOMM and sysfs
On Jan 12, 2008 7:09 AM, Gabor Gombas <[EMAIL PROTECTED]> wrote: > On Thu, Jan 10, 2008 at 09:11:17AM +0800, Dave Young wrote: > > > For bluetooth device_move, the only child device of hci_conn dev is > > the rfcomm tty_dev. How about the following patch, please verify : > > There is now no oops, instead the keyboard becomes almost completely > unresponsible when I switch off & on the phone. The mouse still works > (tested both with X and with the VGA console), but terminal input and VT > switching is dead. On the VGA console, even scrolling using Shift+PgUp > stops working. > > Alt+SysRq+w works, trace is below. Ctrl+Alt+Del also works, but then > init complains about hung processes and that it can not umount the file > systems and cannot stop the RAID arrays. Once it still rebooted though, > the second time it got hung after trying to umount the filesystems, and > I had to use Alt+SysRq+b. > > If I can choose then I prefer the Oops... > > Jan 11 23:46:35 twister kernel: SysRq : Emergency Sync > Jan 11 23:46:35 twister kernel: Emergency Sync complete > Jan 11 23:46:42 twister kernel: SysRq : Show Blocked State > Jan 11 23:46:42 twister kernel: taskPC stack pid > father > Jan 11 23:46:42 twister kernel: events/0 D 80487190 0 5 > 2 > Jan 11 23:46:42 twister kernel: 8100bf84fd40 0046 > 8100ae7f2600 8100bf84fd00 > Jan 11 23:46:42 twister kernel: 8100bf84a830 8100bd872000 > 80652ae0 00010100 > Jan 11 23:46:42 twister kernel: 7fff > 7fff 0002 > Jan 11 23:46:42 twister kernel: Call Trace: > Jan 11 23:46:42 twister kernel: [] > schedule_timeout+0x1e/0xad > Jan 11 23:46:42 twister kernel: [] dput+0x26/0x103 > Jan 11 23:46:42 twister kernel: [] > sysfs_move_dir+0x1ee/0x1fd > Jan 11 23:46:42 twister kernel: [] > wait_for_common+0xc4/0x129 > Jan 11 23:46:42 twister kernel: [] > default_wake_function+0x0/0xe > Jan 11 23:46:42 twister kernel: [] klist_del+0x15/0x2e > Jan 11 23:46:42 twister kernel: [] device_move+0x80/0x111 > Jan 11 23:46:42 twister kernel: [] > :bluetooth:hci_conn_move_child+0x0/0xf > Jan 11 23:46:42 twister kernel: [] > :bluetooth:hci_conn_move_child+0xb/0xf > Jan 11 23:46:42 twister kernel: [] > device_for_each_child+0x22/0x4d > Jan 11 23:46:42 twister kernel: [] > :bluetooth:del_conn+0x0/0x22 > Jan 11 23:46:42 twister kernel: [] > :bluetooth:del_conn+0x19/0x22 > Jan 11 23:46:42 twister kernel: [] run_workqueue+0x74/0xee > Jan 11 23:46:42 twister kernel: [] worker_thread+0x0/0xe7 > Jan 11 23:46:42 twister kernel: [] worker_thread+0xda/0xe7 > Jan 11 23:46:42 twister kernel: [] > autoremove_wake_function+0x0/0x2e > Jan 11 23:46:42 twister kernel: [] worker_thread+0x0/0xe7 > Jan 11 23:46:42 twister kernel: [] kthread+0x47/0x73 > Jan 11 23:46:42 twister kernel: [] child_rip+0xa/0x12 > Jan 11 23:46:42 twister kernel: [] kthread+0x0/0x73 > Jan 11 23:46:42 twister kernel: [] child_rip+0x0/0x12 > Jan 11 23:46:42 twister kernel: > Jan 11 23:46:42 twister kernel: cat D 7fff 0 3978 > 3965 > Jan 11 23:46:42 twister kernel: 81009e857ce8 0086 > 8100ae7f2900 81009e857ca8 > Jan 11 23:46:42 twister kernel: 8100bd872000 8100bf9e7060 > 80652ae0 000100c0 > Jan 11 23:46:42 twister kernel: 7fff > 7fff 0002 > Jan 11 23:46:42 twister kernel: Call Trace: > Jan 11 23:46:42 twister kernel: [] > schedule_timeout+0x1e/0xad > Jan 11 23:46:42 twister kernel: [] > __dequeue_entity+0x1c/0x32 > Jan 11 23:46:42 twister kernel: [] > set_next_entity+0x23/0x73 > Jan 11 23:46:42 twister kernel: [] > wait_for_common+0xc4/0x129 > Jan 11 23:46:42 twister kernel: [] > default_wake_function+0x0/0xe > Jan 11 23:46:42 twister kernel: [] > flush_cpu_workqueue+0x50/0x58 > Jan 11 23:46:42 twister kernel: [] wq_barrier_func+0x0/0x9 > Jan 11 23:46:42 twister kernel: [] flush_workqueue+0x9/0x12 > Jan 11 23:46:42 twister kernel: [] release_dev+0x47c/0x5e2 > Jan 11 23:46:42 twister kernel: [] > do_page_fault+0x2ff/0x65a > Jan 11 23:46:42 twister kernel: [] tty_release+0xc/0x10 > Jan 11 23:46:42 twister kernel: [] __fput+0xb1/0x16f > Jan 11 23:46:42 twister kernel: [] filp_close+0x5d/0x65 > Jan 11 23:46:42 twister kernel: [] sys_close+0x73/0xa6 > Jan 11 23:46:42 twister kernel: [] tracesys+0xdc/0xe1 > Jan 11 23:46:42 twister kernel: > > If I'm not mistaken the "cat" above is the "cat /dev/zero > > /dev/rfcomm0" command. > Any idea about this? Add marcel and davem in cc-list. > > Gabor > > -- > - > MTA SZTAKI Computer and Automation Research Institute > Hungarian Academy of Sciences > - > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Re: [PATCH 3/7] Move rcutorture to tests/
On Thu, Jan 10, 2008 at 03:14:48PM -0800, Josh Triplett wrote: > On Thu, 2008-01-10 at 17:27 +0530, Ananth N Mavinakayanahalli wrote: > > From: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]> > > > > Move the rcutorture infrastructure to tests/ > > > > Signed-off-by: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]> > > Fine by me. > Acked-by: Josh Triplett <[EMAIL PROTECTED]> And me. Acked-by: Paul E. McKenney <[EMAIL PROTECTED]> Thanx, 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/7] driver-core : add class iteration api
On Jan 14, 2008 2:58 PM, Jarek Poplawski <[EMAIL PROTECTED]> wrote: > On Mon, Jan 14, 2008 at 09:36:04AM +0800, Dave Young wrote: > > On Jan 13, 2008 4:11 AM, Jarek Poplawski <[EMAIL PROTECTED]> wrote: > ... > > > Probably some tiny oversight, but I see this comment to struct class > > > doesn't mention devices list, so maybe this needs to be updated BTW?: > > > > > > (from include/linux/device.h) > > > "struct semaphoresem;/* locks both the children and > > > interfaces lists */" > > > > Sorry for my lazy, I think so too. > > IMHO, it should be updated after the comments. > > As a matter of fact, only later I've found this question is 'fixed' in > 7/7. But, actually, I was more concerned if this patch changed the > 'official' policy of this sem (then it would be nice to mention about > this in a changelog) or this comment was simply incomplete. It was just "killed" because I thought it's not true. I means I will update the correct comment after comments. > > Thanks, > Jarek P. > -- 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/7] driver-core : add class iteration api
On Mon, Jan 14, 2008 at 09:36:04AM +0800, Dave Young wrote: > On Jan 13, 2008 4:11 AM, Jarek Poplawski <[EMAIL PROTECTED]> wrote: ... > > Probably some tiny oversight, but I see this comment to struct class > > doesn't mention devices list, so maybe this needs to be updated BTW?: > > > > (from include/linux/device.h) > > "struct semaphoresem;/* locks both the children and > > interfaces lists */" > > Sorry for my lazy, I think so too. > IMHO, it should be updated after the comments. As a matter of fact, only later I've found this question is 'fixed' in 7/7. But, actually, I was more concerned if this patch changed the 'official' policy of this sem (then it would be nice to mention about this in a changelog) or this comment was simply incomplete. Thanks, Jarek P. -- 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] hotplug cpu move tasks in empty cpusets - possible refinements
Query for Cliff:
1) Can we narrow the scope of callback_mutex in scan_for_empty_cpusets()?
2) Can we avoid rewriting the cpus, mems of cpusets except when it is
likely that we'll be changing them?
3) Should not remove_tasks_in_empty_cpuset() also check for empty mems?
-pj
---
kernel/cpuset.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
--- 2.6.24-rc6-mm1.orig/kernel/cpuset.c 2008-01-12 22:04:08.027821401 -0800
+++ 2.6.24-rc6-mm1/kernel/cpuset.c 2008-01-12 22:10:30.701745078 -0800
@@ -1751,7 +1751,8 @@ static void remove_tasks_in_empty_cpuset
* has online cpus, so can't be empty).
*/
parent = cs->parent;
- while (cpus_empty(parent->cpus_allowed))
+ while (cpus_empty(parent->cpus_allowed) ||
+ nodes_empty(parent->mems_allowed))
parent = parent->parent;
move_member_tasks_to_cpuset(cs, parent);
@@ -1783,7 +1784,6 @@ static void scan_for_empty_cpusets(const
list_add_tail((struct list_head *)>stack_list, );
- mutex_lock(_mutex);
while (!list_empty()) {
cp = container_of(queue.next, struct cpuset, stack_list);
list_del(queue.next);
@@ -1792,19 +1792,24 @@ static void scan_for_empty_cpusets(const
list_add_tail(>stack_list, );
}
cont = cp->css.cgroup;
+
+ /* Continue past cpusets with all cpus, mems online */
+ if (cpus_subset(cp->cpus_allowed, cpu_online_map) &&
+ nodes_subset(cp->mems_allowed, node_states[N_HIGH_MEMORY]))
+ continue;
+
/* Remove offline cpus and mems from this cpuset. */
+ mutex_lock(_mutex);
cpus_and(cp->cpus_allowed, cp->cpus_allowed, cpu_online_map);
nodes_and(cp->mems_allowed, cp->mems_allowed,
node_states[N_HIGH_MEMORY]);
+ mutex_unlock(_mutex);
+
+ /* Move tasks from the empty cpuset to a parent */
if (cpus_empty(cp->cpus_allowed) ||
-nodes_empty(cp->mems_allowed)) {
- /* Move tasks from the empty cpuset to a parent */
- mutex_unlock(_mutex);
+nodes_empty(cp->mems_allowed))
remove_tasks_in_empty_cpuset(cp);
- mutex_lock(_mutex);
- }
}
- mutex_unlock(_mutex);
}
/*
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373
--
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/3] hotplug cpu move tasks in empty cpusets to parent various other fixes
From: Paul Jackson <[EMAIL PROTECTED]>
Various minor formatting and comment tweaks to Cliff Wickman's
[PATCH_3_of_3]_cpusets__update_cpumask_revision.patch
I had had "iff", meaning "if and only if" in a comment.
However, except for ancient mathematicians, the abbreviation
"iff" was a tad too cryptic. Cliff changed it to "if",
presumably figuring that the "iff" was a typo. However, it
was the "only if" half of the conjunction that was most
interesting. Reword to emphasis the "only if" aspect.
The locking comment for remove_tasks_in_empty_cpuset() was wrong;
it said callback_mutex had to be held on entry. The opposite
is true.
Several mentions of attach_task() in comments needed to be
changed to cgroup_attach_task().
A comment about notify_on_release was no longer relevant,
as the line of code it had commented, namely:
set_bit(CS_RELEASED_RESOURCE, >flags);
is no longer present in that place in the cpuset.c code.
Similarly a comment about notify_on_release before the
scan_for_empty_cpusets() routine was no longer relevant.
Removed extra parentheses and unnecessary return statement.
Renamed attach_task() to cpuset_attach() in various comments.
Removed comment about not needing memory migration, as it
seems the migration is done anyway, via the cpuset_attach()
callback from cgroup_attach_task().
Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
Cc: Cliff Wickman <[EMAIL PROTECTED]>
Cc: Paul Menage <[EMAIL PROTECTED]>
---
Andrew - this collides with Paul Menage's recent patch:
[PATCH] Update comments in cpuset.c
If you don't want to futz with the collisions, then feel
free to kick one of these back at us to deal with. -pj
kernel/cpuset.c | 53 +
1 file changed, 21 insertions(+), 32 deletions(-)
--- 2.6.24-rc6-mm1.orig/kernel/cpuset.c 2008-01-12 23:19:21.357921853 -0800
+++ 2.6.24-rc6-mm1/kernel/cpuset.c 2008-01-12 23:21:08.571542697 -0800
@@ -167,7 +167,7 @@ static inline int is_spread_slab(const s
* number, and avoid having to lock and reload mems_allowed unless
* the cpuset they're using changes generation.
*
- * A single, global generation is needed because attach_task() could
+ * A single, global generation is needed because cpuset_attach() could
* reattach a task to a different cpuset, which must not have its
* generation numbers aliased with those of that tasks previous cpuset.
*
@@ -218,7 +218,7 @@ static struct cpuset top_cpuset = {
* Any task can increment and decrement the count field without lock.
* So in general, code holding manage_mutex or callback_mutex can't rely
* on the count field not changing. However, if the count goes to
- * zero, then only attach_task(), which holds both mutexes, can
+ * zero, then only cpuset_attach(), which holds both mutexes, can
* increment it again. Because a count of zero means that no tasks
* are currently attached, therefore there is no way a task attached
* to that cpuset can fork (the other way to increment the count).
@@ -255,18 +255,18 @@ static struct cpuset top_cpuset = {
*
* The task_lock() exception
*
- * The need for this exception arises from the action of attach_task(),
+ * The need for this exception arises from the action of cpuset_attach(),
* which overwrites one tasks cpuset pointer with another. It does
* so using both mutexes, however there are several performance
* critical places that need to reference task->cpuset without the
* expense of grabbing a system global mutex. Therefore except as
- * noted below, when dereferencing or, as in attach_task(), modifying
+ * noted below, when dereferencing or, as in cpuset_attach(), modifying
* a tasks cpuset pointer we use task_lock(), which acts on a spinlock
* (task->alloc_lock) already in the task_struct routinely used for
* such matters.
*
* P.S. One more locking exception. RCU is used to guard the
- * update of a tasks cpuset pointer by attach_task() and the
+ * update of a tasks cpuset pointer by cpuset_attach() and the
* access of task->cpuset->mems_generation via that pointer in
* the routine cpuset_update_task_memory_state().
*/
@@ -368,7 +368,7 @@ static void guarantee_online_mems(const
*
* Reading current->cpuset->mems_generation doesn't need task_lock
* to guard the current->cpuset derefence, because it is guarded
- * from concurrent freeing of current->cpuset by attach_task(),
+ * from concurrent freeing of current->cpuset by cpuset_attach(),
* using RCU.
*
* The rcu_dereference() is technically probably not needed,
@@ -790,7 +790,7 @@ static int update_cpumask(struct cpuset
trialcs = *cs;
/*
-* An empty cpus_allowed is ok if there are no tasks in the cpuset.
+* An empty cpus_allowed is ok only if the cpuset has no tasks.
* Since cpulist_parse() fails on an empty mask, we special case
* that parsing. The validate_change() call ensures that cpusets
* with
[PATCH 3/3] cpusets: update_cpumask documentation fix
From: Paul Jackson <[EMAIL PROTECTED]> Update cpuset documentation to match the October 2007 "Fix cpusets update_cpumask" changes that now apply changes to a cpusets 'cpus' allowed mask immediately to the cpus_allowed of the tasks in that cpuset. Signed-off-by: Paul Jackson <[EMAIL PROTECTED]> Cc: Paul Menage <[EMAIL PROTECTED]> --- Documentation/cpusets.txt | 23 --- 1 file changed, 8 insertions(+), 15 deletions(-) --- 2.6.24-rc6-mm1.orig/Documentation/cpusets.txt 2008-01-12 18:52:43.312404390 -0800 +++ 2.6.24-rc6-mm1/Documentation/cpusets.txt2008-01-12 23:02:38.166224878 -0800 @@ -523,21 +523,14 @@ from one cpuset to another, then the ker memory placement, as above, the next time that the kernel attempts to allocate a page of memory for that task. -If a cpuset has its CPUs modified, then each task using that -cpuset does _not_ change its behavior automatically. In order to -minimize the impact on the critical scheduling code in the kernel, -tasks will continue to use their prior CPU placement until they -are rebound to their cpuset, by rewriting their pid to the 'tasks' -file of their cpuset. If a task had been bound to some subset of its -cpuset using the sched_setaffinity() call, and if any of that subset -is still allowed in its new cpuset settings, then the task will be -restricted to the intersection of the CPUs it was allowed on before, -and its new cpuset CPU placement. If, on the other hand, there is -no overlap between a tasks prior placement and its new cpuset CPU -placement, then the task will be allowed to run on any CPU allowed -in its new cpuset. If a task is moved from one cpuset to another, -its CPU placement is updated in the same way as if the tasks pid is -rewritten to the 'tasks' file of its current cpuset. +If a cpuset has its 'cpus' modified, then each task in that cpuset +will have its allowed CPU placement changed immediately. Similarly, +if a tasks pid is written to a cpusets 'tasks' file, in either its +current cpuset or another cpuset, then its allowed CPU placement is +changed immediately. If such a task had been bound to some subset +of its cpuset using the sched_setaffinity() call, the task will be +allowed to run on any CPU allowed in its new cpuset, negating the +affect of the prior sched_setaffinity() call. In summary, the memory placement of a task whose cpuset is changed is updated by the kernel, on the next allocation of a page for that task, -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373 -- 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/3] hotplug cpu move tasks in empty cpusets to parent node_online_map fix
From: Paul Jackson <[EMAIL PROTECTED]>
As of the October 2007 kernel/cpuset.c patch "Memoryless nodes:
Use N_HIGH_MEMORY for cpusets", cpuset nodes are relative to
the nodes with (HIGH) memory, not relative to all nodes in
node_online_map.
Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
Cc: Cliff Wickman <[EMAIL PROTECTED]>
---
kernel/cpuset.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
--- 2.6.24-rc6-mm1.orig/kernel/cpuset.c 2008-01-12 18:52:43.480406969 -0800
+++ 2.6.24-rc6-mm1/kernel/cpuset.c 2008-01-12 19:07:44.330236260 -0800
@@ -1817,7 +1817,8 @@ static void scan_for_empty_cpusets(const
cont = cp->css.cgroup;
/* Remove offline cpus and mems from this cpuset. */
cpus_and(cp->cpus_allowed, cp->cpus_allowed, cpu_online_map);
- nodes_and(cp->mems_allowed, cp->mems_allowed, node_online_map);
+ nodes_and(cp->mems_allowed, cp->mems_allowed,
+ node_states[N_HIGH_MEMORY]);
if ((cpus_empty(cp->cpus_allowed) ||
nodes_empty(cp->mems_allowed))) {
/* Move tasks from the empty cpuset to a parent */
@@ -1832,8 +1833,8 @@ static void scan_for_empty_cpusets(const
/*
* The cpus_allowed and mems_allowed nodemasks in the top_cpuset track
- * cpu_online_map and node_online_map. Force the top cpuset to track
- * whats online after any CPU or memory node hotplug or unplug event.
+ * cpu_online_map and node_states[N_HIGH_MEMORY]. Force the top cpuset to
+ * track what's online after any CPU or memory node hotplug or unplug event.
*
* Since there are two callers of this routine, one for CPU hotplug
* events and one for memory node hotplug events, we could have coded
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373
--
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: [GIT PATCH] Update to Chinese documents
On Thu, Jan 10, 2008 at 12:48:56AM +0800, Bryan Wu wrote: >On Jan 9, 2008 7:54 PM, Sam Ravnborg <[EMAIL PROTECTED]> wrote: >> > > >> > > What is generally seen as a showstopper is the amount of work needed >> > > to do the translation - and keeping it up-to-date. >> > >> > Sure. The key is to have more participants to involve. The work can't >> > be done without a large contributor base. >> >> I already got positive feedback from Bryan Wu and WANG Cong so a Chinese >> translation is well within reach if we get the infrastructure adapted so >> we have better .po files support. >> > >Thanks. >As Leo said, we can host this project in zh-kernel.org and invite some >Chinese developers to boost up the translation. >WANG Cong is good to maintain this, -:)) Yes, I would like to do that work. Thank you. And I will also find some guys here to help me to do this. Please feel free to Cc me if you have any suggestions. Regards. Cong -- 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] driver: ip27-rtc - convert ioctl to unlocked_ioctl
This patch converts ioctl call to unlocked_ioctl form. It's possible due to rtl_lock spinlock protection. Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]> --- The patch is *not* tested but the patch does not bring _much_ changes so it wouldn't break the compilation procedure. If there is problem with attachment - i could send it as inline form today evening. Andi, Jiri, Alexey the only thing I do complain about - is time set/read from several user threads that uses same (duplicated) file descriptor. Could there be useless thread spins instead of sleep (in case if this unlocked_ioctl were protected by mutex)? ip27-rtc-unlocked-ioctl.patch Description: Binary data
Re: [PATCH 002 of 6] md: Fix use-after-free bug when dropping an rdev from an md array.
On Monday January 14, [EMAIL PROTECTED] wrote:
>
> Thanks. I'll see what I can some up with.
How about this, against current -mm
On both the read and write path for an rdev attribute, we
call mddev_lock, first checking that mddev is not NULL.
Once we get the lock, we check again.
If rdev->mddev is not NULL, we know it will stay that way as it only
gets cleared under the same lock.
While in the rdev show/store routines, we know that the mddev cannot
get freed, do to the kobject relationships.
rdev_size_store is awkward because it has to drop the lock. So we
take a copy of rdev->mddev before the drop, and we are safe...
Comments?
NeilBrown
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./drivers/md/md.c | 35 ++-
1 file changed, 26 insertions(+), 9 deletions(-)
diff .prev/drivers/md/md.c ./drivers/md/md.c
--- .prev/drivers/md/md.c 2008-01-14 12:26:15.0 +1100
+++ ./drivers/md/md.c 2008-01-14 17:05:53.0 +1100
@@ -1998,9 +1998,11 @@ rdev_size_store(mdk_rdev_t *rdev, const
char *e;
unsigned long long size = simple_strtoull(buf, , 10);
unsigned long long oldsize = rdev->size;
+ mddev_t *my_mddev = rdev->mddev;
+
if (e==buf || (*e && *e != '\n'))
return -EINVAL;
- if (rdev->mddev->pers)
+ if (my_mddev->pers)
return -EBUSY;
rdev->size = size;
if (size > oldsize && rdev->mddev->external) {
@@ -2013,7 +2015,7 @@ rdev_size_store(mdk_rdev_t *rdev, const
int overlap = 0;
struct list_head *tmp, *tmp2;
- mddev_unlock(rdev->mddev);
+ mddev_unlock(my_mddev);
for_each_mddev(mddev, tmp) {
mdk_rdev_t *rdev2;
@@ -2033,7 +2035,7 @@ rdev_size_store(mdk_rdev_t *rdev, const
break;
}
}
- mddev_lock(rdev->mddev);
+ mddev_lock(my_mddev);
if (overlap) {
/* Someone else could have slipped in a size
* change here, but doing so is just silly.
@@ -2045,8 +2047,8 @@ rdev_size_store(mdk_rdev_t *rdev, const
return -EBUSY;
}
}
- if (size < rdev->mddev->size || rdev->mddev->size == 0)
- rdev->mddev->size = size;
+ if (size < my_mddev->size || my_mddev->size == 0)
+ my_mddev->size = size;
return len;
}
@@ -2067,10 +2069,21 @@ rdev_attr_show(struct kobject *kobj, str
{
struct rdev_sysfs_entry *entry = container_of(attr, struct
rdev_sysfs_entry, attr);
mdk_rdev_t *rdev = container_of(kobj, mdk_rdev_t, kobj);
+ mddev_t *mddev = rdev->mddev;
+ ssize_t rv;
if (!entry->show)
return -EIO;
- return entry->show(rdev, page);
+
+ rv = mddev ? mddev_lock(mddev) : -EBUSY;
+ if (!rv) {
+ if (rdev->mddev == NULL)
+ rv = -EBUSY;
+ else
+ rv = entry->show(rdev, page);
+ mddev_unlock(mddev);
+ }
+ return rv;
}
static ssize_t
@@ -2079,15 +2092,19 @@ rdev_attr_store(struct kobject *kobj, st
{
struct rdev_sysfs_entry *entry = container_of(attr, struct
rdev_sysfs_entry, attr);
mdk_rdev_t *rdev = container_of(kobj, mdk_rdev_t, kobj);
- int rv;
+ ssize_t rv;
+ mddev_t *mddev = rdev->mddev;
if (!entry->store)
return -EIO;
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
- rv = mddev_lock(rdev->mddev);
+ rv = mddev ? mddev_lock(mddev): -EBUSY;
if (!rv) {
- rv = entry->store(rdev, page, length);
+ if (rdev->mddev == NULL)
+ rv = -EBUSY;
+ else
+ rv = entry->store(rdev, page, length);
mddev_unlock(rdev->mddev);
}
return rv;
--
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: (Try #3) [Patch 2/8] MIPS: Remove 'TOPDIR' from Makefiles
On Fri, Jan 11, 2008 at 06:02:04PM +0100, Sam Ravnborg wrote: >On Fri, Jan 11, 2008 at 02:17:54PM +, Ralf Baechle wrote: >> On Wed, Jan 02, 2008 at 02:21:36PM +0800, WANG Cong wrote: >> >> > >> Shouldn't that use $(LINUXINCLUDE), or $(KBUILD_CPPFLAGS)? >> > >It would be better to use $(LINUXINCLUDE) as we then pull in all config >> > >symbols too and do not have to hardcode kbuild internal names (include2). >> > >> > OK. Refine this patch. >> >> LDSCRIPT also needed fixing to get builds in a separate object directory >> working again. >> >> I've applied below fix. > >Great - I will drop it from my tree. > >See small comment below. > > Sam > > >> Ralf >> >> From 8babf06e1265214116fb8ffc634c04df85597c52 Mon Sep 17 00:00:00 2001 >> From: WANG Cong <[EMAIL PROTECTED]> >> Date: Wed, 2 Jan 2008 14:21:36 +0800 >> Subject: [PATCH] [MIPS] Lasat: Fix built in separate object directory. >> >> Signed-off-by: WANG Cong <[EMAIL PROTECTED]> >> >> [Ralf: The LDSCRIPT script needed fixing, too] >> >> Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]> >> >> diff --git a/arch/mips/lasat/image/Makefile b/arch/mips/lasat/image/Makefile >> index 5332449..7ccd40d 100644 >> --- a/arch/mips/lasat/image/Makefile >> +++ b/arch/mips/lasat/image/Makefile >> @@ -12,11 +12,11 @@ endif >> >> MKLASATIMG = mklasatimg >> MKLASATIMG_ARCH = mq2,mqpro,sp100,sp200 >> -KERNEL_IMAGE = $(TOPDIR)/vmlinux >> +KERNEL_IMAGE = vmlinux >> KERNEL_START = $(shell $(NM) $(KERNEL_IMAGE) | grep " _text" | cut -f1 -d\ ) >> KERNEL_ENTRY = $(shell $(NM) $(KERNEL_IMAGE) | grep kernel_entry | cut -f1 >> -d\ ) >> >> -LDSCRIPT= -L$(obj) -Tromscript.normal >> +LDSCRIPT= -L$(srctree)/$(obj) -Tromscript.normal > >This needs to read: >> +LDSCRIPT= -L$(srctree)/$(src) -Tromscript.normal > > >(There is no difference between src and obj in normal cases but to be >consistent >it shuld be like above). Agreed. Thank you! -- 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 deleting (or reading) files not counted as IO-Wait in top?
On Wed, Jan 02, 2008 at 08:35:03PM +0100, Matthias Schniedermeyer wrote: > Hi > > > Currently i'm deleting about 500.000 files on a XFS-filesystem which > takes a few minutes, as i had a top open i saw that 'wa' is shown as > 0.0% (Nothing else running currently) and everything except 'id' is near > the bottom too. Kernel is 2.6.23.11. Simply because the only I/O that XFS does during a delete is to the log and the log does async I/O and hence the process never blocks in I/O. Instead, it blocks in a far more complex space reservation that may or may not be related to I/O wait > So, as 'rm -rf' is essentially a IO (or seek, to be more correct)-bound > task, shouldn't that count as "Waiting for IO"? rm -rf is not seek bound on XFS - it's generally determined by the sequential write speed of the block device or how fast your CPU is > The man-page of top says: > 'Amount of time the CPU has been waiting for I/O to complete.' Async I/O means that typically your CPU does not get held up waiting for I/O to complete 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: fixed a bug of adma in rhel4u5 with HDS7250SASUN500G.
Robert Hancock wrote: > As I mentioned, this doesn't seem to resolve the problem we're seeing > with rapidly intermixed NCQ commands and cache flushes (at > least, if I > take out the arbitrary 20usec delay from the driver and add > this patch, > the problem still shows up). It could be a similar problem, > though, of > commands being issued before the controller is really ready > for them. If > you or others at NVIDIA could assist in tracking down that problem it > would be appreciated.. > Ok , i will track down that problem. --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- -- 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: sparc oops in ip_fast_csum
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Mon, 14 Jan 2008 07:09:22 +0100 > But I agree to your suggestion, that will allow us to properly > handle packets with IP options. I'll take care of this. Thanks a lot Patrick. -- 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: sparc oops in ip_fast_csum
Herbert Xu wrote: Patrick, please have a look at the former. In fact it's not just that ihl may be bogus (which might be harmless as long as the REJECT hook only gets called from within the IP stack), I think REJECT would also do the wrong thing if the packet had IP options. So perhaps we should just make it create a packet from scratch rather than being too clever in reusing the old one. We currently silently drop packets with IP options in the reject target. The length check should be fine since its only called through the IP stack or bridge netfilter, which replicates the IP stack checks. But I agree to your suggestion, that will allow us to properly handle packets with IP options. I'll take care of this. -- 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: [git pull] Input updates for 2.6.24-rc3
On Monday 14 January 2008, Dmitry Torokhov wrote: > Hi Linus, > > Please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus > or > master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus > > to receive updates for the input subsystem. > The subject should read "Input updates for 2.6.24-rc7" of course... -- 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: Is it possible to change IRQ for certain device?
On Jan 14, 2008 12:30 AM, Bryan Donlan <[EMAIL PROTECTED]> wrote: > > On Jan 13, 2008 10:57 PM, Lee Revell <[EMAIL PROTECTED]> wrote: > > On Jan 11, 2008 11:57 AM, Jan Marek <[EMAIL PROTECTED]> wrote: > > Why is a shared IRQ a problem for you? IRQ handlers are supposed to > > be fast enough that disabling an IRQ line for the duration of the > > handler execution should not be a problem even if the IRQ is shared. > > VGA interrupts in particular should only fire once per frame and only > > need to flip some bits to wake up any processes waiting on vsync. > > > > If you have issues with a shared VGA interrupt then the bug is that > > some IRQ handler runs for too long and should be deferring work to a > > bottom half. > > Jan is apparently using the nvidia binary driver, so I doubt it will > be possible to fix the bug that prevents it from sharing IRQs. > Ah, of course, stupid me. Thought I was on linux-audio-user where this is a FAQ (for completely different reasons) and not LKML. But this is strange - I'm sure I've seen people using that driver with a shared IRQ before. Jan, maybe you can blacklist ohci-hcd as a workaround? In any case let's take this discussion off LKML so as not to spam the list with binary only driver issues. Lee -- 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 kprobes on ia64
On Sun, Jan 13, 2008 at 07:24:24PM -0700, Matthew Wilcox wrote: > > If CONFIG_KPROBES is set, we get the error during build: > > kernel/kprobes.c:1057: error: __ksymtab_jprobe_return causes a section > type conflict > > This is because ia64 defines a static inline jprobe_return which kprobes > attempts to EXPORT_SYMBOL. The better fix is to let jprobe_return be a normal function that can be exported. Then we avoid this arch specific ifdef for the cost of nothing. Sam -- 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/
[git pull] Input updates for 2.6.24-rc3
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus or master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. Changelog: - Dmitry Baryshkov (1): Input: Handle EV_PWR type of input caps in input_set_capability. Ivan Kokshaysky (1): gameport: don't export functions that are static inline Kristoffer Ericson (2): Input: jornada680_kbd - fix default keymap Input: improve Kconfig help entries for HP Jornada devices Richard Purdie (2): Input: spitzkbd - fix suspend key handling Input: pass EV_PWR events to event handlers Diffstat: drivers/input/gameport/gameport.c |2 - drivers/input/input.c |8 ++ drivers/input/keyboard/Kconfig | 12 drivers/input/keyboard/jornada680_kbd.c | 40 +++--- drivers/input/keyboard/spitzkbd.c |1 + drivers/input/touchscreen/Kconfig |8 ++ 6 files changed, 38 insertions(+), 33 deletions(-) -- 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: kconfig: support option env="" [Was: kconfig: use $K64BIT to set 64BIT with all*config targets]
On Mon, Jan 14, 2008 at 04:49:48AM +0100, Roman Zippel wrote: > Hi, > > On Sun, 6 Jan 2008, Sam Ravnborg wrote: > > > Please get back to me so we can finsih this patch and have it applied. > > I will split the patch in two btw. > > I reworked the patch a little and split it into three. Thanks Roman. I will test and apply tonight. Removal of KERNELVERSION in patch #3 is wrong as the frontend uses KERNELVERSION to display the kernel version in their title. I will drop the deletion before I apply the patch. > > > > + if (sym->flags & SYMBOL_AUTO) > > > + sym->flags &= ~SYMBOL_WRITE; > > > + > > > > Why is this change needed? > > It is non-obvious to me so please explain and I will add a comment. > > Automatically generated symbols are not saved, this was previously not > needed as they weren't in the menu structure. OK > > > I did it like this: > > menu_warn(current_entry, > > "config %s: redefining environment symbol > > from '%s' to '%s'", > > sym->name, env, sym2->name); > > I omitted the prefix, it's inconsistent with other warnings. OK Thanks, Sam -- 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: Is it possible to change IRQ for certain device?
On Jan 13, 2008 10:57 PM, Lee Revell <[EMAIL PROTECTED]> wrote: > On Jan 11, 2008 11:57 AM, Jan Marek <[EMAIL PROTECTED]> wrote: > > I suppose, that VGA card does not need unique IRQ, but programmers, > > which wrote driver, want it. I can imagine, that VGA card have many > > interrupts, especially in the OpenGL games, but I cannot assign unique > > IRQ for VGA card at all :-( > > > > But thank you for advice: I will try to send e-mail to Gigabyte and ask > > they, if it possible to do change in the BIOS. > > > > BTW: it is interesting: I had a Biostar TA690G motherboard and it behave > > similar as Gigabyte: I cannnot assign unique IRQ to the external > > graphics card... Chipsets of this motherboards are the same... > > > > I've tried to solve this problem by bought of new motherboard: Gigabyte > > MA790FX-DS5. I will see, if this board will behave as previous board... > > Why is a shared IRQ a problem for you? IRQ handlers are supposed to > be fast enough that disabling an IRQ line for the duration of the > handler execution should not be a problem even if the IRQ is shared. > VGA interrupts in particular should only fire once per frame and only > need to flip some bits to wake up any processes waiting on vsync. > > If you have issues with a shared VGA interrupt then the bug is that > some IRQ handler runs for too long and should be deferring work to a > bottom half. Jan is apparently using the nvidia binary driver, so I doubt it will be possible to fix the bug that prevents it from sharing IRQs. -- 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 v2] Make PCI extended config space (MMCONFIG) a driver opt-in
On Mon, 14 Jan 2008, Alan Cox wrote: > > > > As someone gently pointed out to me, you are in a position to know this, > > so I probably am wrong. > > I suspect Arjan is wrong. It might be some Intel agenda but I still see > fairly new driver reference code that is hardcoding port accesses even > when designed for Redmond products. Agreed. I suspect that the likelihood of conf1 accesses going away in the next five years is slim to none. Linus -- 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: fixed a bug of adma in rhel4u5 with HDS7250SASUN500G.
Kuan Luo wrote: Robert hancock wrote: What problem does this resolve? I tested it against the cache flush/NCQ write switching problem we've been trying to solve, and it doesn't look like it fixes that one - if I apply this patch and then remove the udelay(20) in sata_nv.c that I added which prevented me from seeing this problem before, it shows up. First thank davide to help to send the attachment. Robert, The patch is to solve the error message "ata1: CPB flags CMD err, flags=0x11" when testing HDS7250SASUN500G in rhel4u5. I tested this hd in 2.6.24-rc7 which needed to remove the mask in blacklist to run the ncq and the same error also showed up. I traced the bug and found that the interrupt finished a command (for example, tag=0) when the driver got that adma status is NV_ADMA_STAT_DONE and cpb->resp_flags is NV_CPB_RESP_DONE. However, For this hd, the drive maybe didn't clear bit 0 at this moment. It meaned the hardware had not completely finished the command. If at the same time the driver freed the command(tag 0) and sended another command (tag 0), the error happened. The notifier register is 32-bit register containing notifier value. Value is bit vector containing one bit per tag number (0-31) in corresponding bit positions (bit 0 is for tag 0, etc). When bit is set then ADMA indicates that command with corresponding tag number completed execution. So i added the check notifier code. Sometimes i saw that the notifier reg set some bits , but the adma status set NV_ADMA_STAT_CMD_COMPLETE ,not NV_ADMA_STAT_DONE. So i added the NV_ADMA_STAT_CMD_COMPLETE check code. That looks like a good fix then. (Though a possible optimization would be to and the check_commands value with the notifier clear value rather than testing against the notifier on each loop. That's fairly minor though.) As I mentioned, this doesn't seem to resolve the problem we're seeing with rapidly intermixed NCQ commands and cache flushes (at least, if I take out the arbitrary 20usec delay from the driver and add this patch, the problem still shows up). It could be a similar problem, though, of commands being issued before the controller is really ready for them. If you or others at NVIDIA could assist in tracking down that problem it would be appreciated.. -- 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 v2] Make PCI extended config space (MMCONFIG) a driver opt-in
On Sun, 13 Jan 2008 22:29:23 -0500 Tony Camuso <[EMAIL PROTECTED]> wrote: > . There is no need to provide different PCI config access >mechanisms at device granularity, since the PCI config access >mechanism between the CPU and the Northbridge is opaque to >the devices. PCI config mechanisms only need to differ at >the Northbridge level. This ignores the "lets make it not matter for the 99% of the users" case. > > . If the system is capable of conf1, then PCI config access >at offsets < 256 should be confined to conf1. This solution >is most effective for existing and legacy systems. not "conf1" but "what the platform thinks is the best method for < 256". We have this nice abstraction for the platform to select the best method... we should use it. And still, it's another attempt to get this fixed (well.. it's been 2 years in the coming so far, maybe this will be the last one, maybe it will not be... we'll see I suppose, but it sucks to be a user who doesn't need any of the functionality that the extended config space provides in theory but gets to suffer more of the issues) I'm all in favor of making this more reliable, but really.. we've thought it was fixed time and time again over the last two years. Please consider limiting the scope of the damage as well. -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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 002 of 6] md: Fix use-after-free bug when dropping an rdev from an md array.
On Monday January 14, [EMAIL PROTECTED] wrote: > On Mon, Jan 14, 2008 at 02:21:45PM +1100, Neil Brown wrote: > > > Maybe it isn't there any more > > > > Once upon a time, when I > >echo remove > /sys/block/mdX/md/dev-YYY/state > > Egads. And just what will protect you from parallel callers > of state_store()? buffer->mutex does *not* do that - it only > gives you exclusion on given struct file. Run the command > above from several shells and you've got independent open > from each redirect => different struct file *and* different > buffer for each => no exclusion whatsoever. well in -mm, rdev_attr_store gets a lock on rdev->mddev->reconfig_mutex. It doesn't test is rdev->mddev is NULL though, so if the write happens after unbind_rdev_from_array, we lose. A test for NULL would be easy enough. And I think that the mddev won't actually disappear until the rdevs are all gone (you subsequent comment about kobject_del ordering seems to confirm that) so a simple test for NULL should be sufficient. > > And _that_ is present right in the mainline tree - it's unrelated > to -mm kobject changes. > > BTW, yes, you do have a deadlock there - kobject_del() will try to evict > children, which will include waiting for currently running ->store() > to finish, which will include the caller since .../state *is* a child of > that sucker. > > The real problem is the lack of any kind of exclusion considerations in > md.c itself, AFAICS. Fun with ordering is secondary (BTW, yes, it is > a problem - will sysfs ->store() to attribute between export_rdev() and > kobject_del() work correctly?) Probably not. The possibility that rdev->mddev could be NULL would break a lot of these. Maybe I should delay setting rdev->mddev to NULL until after the kobject_del. Then audit them all. Thanks. I'll see what I can some up with. NeilBrown -- 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: Is it possible to change IRQ for certain device?
On Jan 11, 2008 11:57 AM, Jan Marek <[EMAIL PROTECTED]> wrote: > I suppose, that VGA card does not need unique IRQ, but programmers, > which wrote driver, want it. I can imagine, that VGA card have many > interrupts, especially in the OpenGL games, but I cannot assign unique > IRQ for VGA card at all :-( > > But thank you for advice: I will try to send e-mail to Gigabyte and ask > they, if it possible to do change in the BIOS. > > BTW: it is interesting: I had a Biostar TA690G motherboard and it behave > similar as Gigabyte: I cannnot assign unique IRQ to the external > graphics card... Chipsets of this motherboards are the same... > > I've tried to solve this problem by bought of new motherboard: Gigabyte > MA790FX-DS5. I will see, if this board will behave as previous board... Why is a shared IRQ a problem for you? IRQ handlers are supposed to be fast enough that disabling an IRQ line for the duration of the handler execution should not be a problem even if the IRQ is shared. VGA interrupts in particular should only fire once per frame and only need to flip some bits to wake up any processes waiting on vsync. If you have issues with a shared VGA interrupt then the bug is that some IRQ handler runs for too long and should be deferring work to a bottom half. Lee -- 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: regression: 100% io-wait with 2.6.24-rcX
On Sun, Jan 13, 2008 at 07:59:33PM +0800, Fengguang Wu wrote: > On Sun, Jan 13, 2008 at 10:49:31AM +0100, Joerg Platte wrote: > > register_jprobe(ext2_writepage) = 0 > > register_jprobe(requeue_io) = 0 > > register_kprobe(submit_bio) = 0 > > requeue_io: > > inode 114019(sda7/.kde) count 2,2 size 0 pages 1 > > 0 2 0 U > > requeue_io: > > inode 114025(sda7/cache-ibm) count 2,1 size 0 pages 1 > > 0 2 0 U > > requeue_io: > > inode 114029(sda7/socket-ibm) count 2,3 size 0 pages 1 > > 0 2 0 U > > requeue_io: > > inode 114017(sda7/0266584877) count 3,6 size 0 pages 1 > > 0 2 0 U > > It helps. Thank you, Joerg! > > The .kde/cache-ibm/socket-ibm/0266584877 above are directories. > It's weird that dirs would have their own mappings in ext2. In Oh, ext2 dirs have their own mapping pages. Not the same with ext3. > particular this bug is triggered because the dir mapping page has > PAGECACHE_TAG_DIRTY set and PG_dirty cleared, staying in an > inconsistent state. Just found that a deleted dir will enter that inconsistent state when someone still have reference to it... -- 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/3] environment symbol support
Add the possibility to import a value from the environment into kconfig
via the option syntax. Beside flexibility this has the advantage
providing proper dependencies.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
Documentation/kbuild/kconfig-language.txt | 21 ++
scripts/kconfig/expr.h|3 +-
scripts/kconfig/lkc.h |5 +++
scripts/kconfig/menu.c|5 ++-
scripts/kconfig/qconf.cc | 16 +++---
scripts/kconfig/symbol.c | 45 ++
scripts/kconfig/util.c| 23 ++-
scripts/kconfig/zconf.gperf |1
scripts/kconfig/zconf.hash.c_shipped | 45 --
9 files changed, 129 insertions(+), 35 deletions(-)
Index: linux-2.6/Documentation/kbuild/kconfig-language.txt
===
--- linux-2.6.orig/Documentation/kbuild/kconfig-language.txt
+++ linux-2.6/Documentation/kbuild/kconfig-language.txt
@@ -127,6 +127,27 @@ applicable everywhere (see syntax).
used to help visually separate configuration logic from help within
the file as an aid to developers.
+- misc options: "option" [=]
+ Various less common options can be defined via this option syntax,
+ which can modify the behaviour of the menu entry and its config
+ symbol. These options are currently possible:
+
+ - "defconfig_list"
+This declares a list of default entries which can be used when
+looking for the default configuration (which is used when the main
+.config doesn't exists yet.)
+
+ - "modules"
+This declares the symbol to be used as the MODULES symbol, which
+enables the third modular state for all config symbols.
+
+ - "env"=
+This imports the environment variable into Kconfig. It behaves like
+a default, except that the value comes from the environment, this
+also means that the behaviour when mixing it with normal defaults is
+undefined at this point. The symbol is currently not exported back
+to the build environment (if this is desired, it can be done via
+another symbol).
Menu dependencies
-
Index: linux-2.6/scripts/kconfig/expr.h
===
--- linux-2.6.orig/scripts/kconfig/expr.h
+++ linux-2.6/scripts/kconfig/expr.h
@@ -108,7 +108,8 @@ struct symbol {
#define SYMBOL_HASHMASK0xff
enum prop_type {
- P_UNKNOWN, P_PROMPT, P_COMMENT, P_MENU, P_DEFAULT, P_CHOICE, P_SELECT,
P_RANGE
+ P_UNKNOWN, P_PROMPT, P_COMMENT, P_MENU, P_DEFAULT, P_CHOICE,
+ P_SELECT, P_RANGE, P_ENV
};
struct property {
Index: linux-2.6/scripts/kconfig/lkc.h
===
--- linux-2.6.orig/scripts/kconfig/lkc.h
+++ linux-2.6/scripts/kconfig/lkc.h
@@ -44,6 +44,7 @@ extern "C" {
#define T_OPT_MODULES 1
#define T_OPT_DEFCONFIG_LIST 2
+#define T_OPT_ENV 3
struct kconf_id {
int name;
@@ -74,6 +75,7 @@ void kconfig_load(void);
/* menu.c */
void menu_init(void);
+void menu_warn(struct menu *menu, const char *fmt, ...);
struct menu *menu_add_menu(void);
void menu_end_menu(void);
void menu_add_entry(struct symbol *sym);
@@ -103,6 +105,8 @@ void str_printf(struct gstr *gs, const c
const char *str_get(struct gstr *gs);
/* symbol.c */
+extern struct expr *sym_env_list;
+
void sym_init(void);
void sym_clear_all_valid(void);
void sym_set_all_changed(void);
@@ -110,6 +114,7 @@ void sym_set_changed(struct symbol *sym)
struct symbol *sym_check_deps(struct symbol *sym);
struct property *prop_alloc(enum prop_type type, struct symbol *sym);
struct symbol *prop_get_symbol(struct property *prop);
+struct property *sym_get_env_prop(struct symbol *sym);
static inline tristate sym_get_tristate_value(struct symbol *sym)
{
Index: linux-2.6/scripts/kconfig/menu.c
===
--- linux-2.6.orig/scripts/kconfig/menu.c
+++ linux-2.6/scripts/kconfig/menu.c
@@ -15,7 +15,7 @@ static struct menu **last_entry_ptr;
struct file *file_list;
struct file *current_file;
-static void menu_warn(struct menu *menu, const char *fmt, ...)
+void menu_warn(struct menu *menu, const char *fmt, ...)
{
va_list ap;
va_start(ap, fmt);
@@ -172,6 +172,9 @@ void menu_add_option(int token, char *ar
else if (sym_defconfig_list != current_entry->sym)
zconf_error("trying to redefine defconfig symbol");
break;
+ case T_OPT_ENV:
+ prop_add_env(arg);
+ break;
}
}
Index: linux-2.6/scripts/kconfig/qconf.cc
===
--- linux-2.6.orig/scripts/kconfig/qconf.cc
+++ linux-2.6/scripts/kconfig/qconf.cc
@@ -1083,7 +1083,11 @@ QString
[PATCH 3/3] use environment option
Use the environment option to provide the ARCH symbol.
Remove the unused KERNELVERSION symbol.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
init/Kconfig |4
scripts/kconfig/symbol.c | 14 --
2 files changed, 4 insertions(+), 14 deletions(-)
Index: linux-2.6/init/Kconfig
===
--- linux-2.6.orig/init/Kconfig
+++ linux-2.6/init/Kconfig
@@ -1,3 +1,7 @@
+config ARCH
+ string
+ option env="ARCH"
+
config DEFCONFIG_LIST
string
depends on !UML
Index: linux-2.6/scripts/kconfig/symbol.c
===
--- linux-2.6.orig/scripts/kconfig/symbol.c
+++ linux-2.6/scripts/kconfig/symbol.c
@@ -56,20 +56,6 @@ void sym_init(void)
uname();
- sym = sym_lookup("ARCH", 0);
- sym->type = S_STRING;
- sym->flags |= SYMBOL_AUTO;
- p = getenv("ARCH");
- if (p)
- sym_add_default(sym, p);
-
- sym = sym_lookup("KERNELVERSION", 0);
- sym->type = S_STRING;
- sym->flags |= SYMBOL_AUTO;
- p = getenv("KERNELVERSION");
- if (p)
- sym_add_default(sym, p);
-
sym = sym_lookup("UNAME_RELEASE", 0);
sym->type = S_STRING;
sym->flags |= SYMBOL_AUTO;
--
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] Default keyboard LEDs
Samuel Thibault wrote: In many cases, one prefers to have e.g. the NumLock on by default. In many cases, one doesn't want to have it by default, e.g. on laptops. Distributions actually have a very hard time trying to set this correctly after the kernel boot, and that doesn't work for new consoles that are created via the openvt(1) command anyway. This hence adds a keyboard.default_leds boot parameter that permits to configure the default keyboard LEDs. Signed-off-by: Samuel Thibault <[EMAIL PROTECTED]> Actually, what would be perfect would be to use the configuration that the BIOS sets at boot by default. That is device-dependent, however. It is, but it can be read out either by INT calls at initialization time, or by reading out the byte at physical address 0x417: K-M00400017-- MEM 0040h:0017h - KEYBOARD - STATUS FLAGS 1 Size: BYTE SeeAlso: MEM 0040h:0018h,INT 16/AH=02h,MEM 0040h:0096h Bitfields for keyboard status flags 1: Bit(s) Description (Table M0010) 7 INSert active 6 Caps Lock active 5 Num Lock active 4 Scroll Lock active 3 either Alt pressed 2 either Ctrl pressed 1 Left Shift pressed 0 Right Shift pressed SeeAlso: #M0011,#00587 The same information is available through INT 16h, AH=02h. -hpa -- 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/3] explicitly introduce expression list
Rename E_CHOICE to E_LIST to explicitly add support for expression
lists. Add a helper macro expr_list_for_each_sym to more easily iterate
over the list.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
scripts/kconfig/confdata.c |8
scripts/kconfig/expr.c | 16
scripts/kconfig/expr.h |5 -
scripts/kconfig/menu.c |2 +-
scripts/kconfig/symbol.c | 13 +++--
5 files changed, 24 insertions(+), 20 deletions(-)
Index: linux-2.6/scripts/kconfig/confdata.c
===
--- linux-2.6.orig/scripts/kconfig/confdata.c
+++ linux-2.6/scripts/kconfig/confdata.c
@@ -316,7 +316,7 @@ load:
int conf_read(const char *name)
{
- struct symbol *sym;
+ struct symbol *sym, *choice_sym;
struct property *prop;
struct expr *e;
int i, flags;
@@ -357,9 +357,9 @@ int conf_read(const char *name)
*/
prop = sym_get_choice_prop(sym);
flags = sym->flags;
- for (e = prop->expr; e; e = e->left.expr)
- if (e->right.sym->visible != no)
- flags &= e->right.sym->flags;
+ expr_list_for_each_sym(prop->expr, e, choice_sym)
+ if (choice_sym->visible != no)
+ flags &= choice_sym->flags;
sym->flags &= flags | ~SYMBOL_DEF_USER;
}
Index: linux-2.6/scripts/kconfig/expr.c
===
--- linux-2.6.orig/scripts/kconfig/expr.c
+++ linux-2.6/scripts/kconfig/expr.c
@@ -87,7 +87,7 @@ struct expr *expr_copy(struct expr *org)
break;
case E_AND:
case E_OR:
- case E_CHOICE:
+ case E_LIST:
e->left.expr = expr_copy(org->left.expr);
e->right.expr = expr_copy(org->right.expr);
break;
@@ -217,7 +217,7 @@ int expr_eq(struct expr *e1, struct expr
expr_free(e2);
trans_count = old_count;
return res;
- case E_CHOICE:
+ case E_LIST:
case E_RANGE:
case E_NONE:
/* panic */;
@@ -648,7 +648,7 @@ struct expr *expr_transform(struct expr
case E_EQUAL:
case E_UNEQUAL:
case E_SYMBOL:
- case E_CHOICE:
+ case E_LIST:
break;
default:
e->left.expr = expr_transform(e->left.expr);
@@ -932,7 +932,7 @@ struct expr *expr_trans_compare(struct e
break;
case E_SYMBOL:
return expr_alloc_comp(type, e->left.sym, sym);
- case E_CHOICE:
+ case E_LIST:
case E_RANGE:
case E_NONE:
/* panic */;
@@ -1000,9 +1000,9 @@ int expr_compare_type(enum expr_type t1,
if (t2 == E_OR)
return 1;
case E_OR:
- if (t2 == E_CHOICE)
+ if (t2 == E_LIST)
return 1;
- case E_CHOICE:
+ case E_LIST:
if (t2 == 0)
return 1;
default:
@@ -1053,11 +1053,11 @@ void expr_print(struct expr *e, void (*f
fn(data, NULL, " && ");
expr_print(e->right.expr, fn, data, E_AND);
break;
- case E_CHOICE:
+ case E_LIST:
fn(data, e->right.sym, e->right.sym->name);
if (e->left.expr) {
fn(data, NULL, " ^ ");
- expr_print(e->left.expr, fn, data, E_CHOICE);
+ expr_print(e->left.expr, fn, data, E_LIST);
}
break;
case E_RANGE:
Index: linux-2.6/scripts/kconfig/expr.h
===
--- linux-2.6.orig/scripts/kconfig/expr.h
+++ linux-2.6/scripts/kconfig/expr.h
@@ -32,7 +32,7 @@ typedef enum tristate {
} tristate;
enum expr_type {
- E_NONE, E_OR, E_AND, E_NOT, E_EQUAL, E_UNEQUAL, E_CHOICE, E_SYMBOL,
E_RANGE
+ E_NONE, E_OR, E_AND, E_NOT, E_EQUAL, E_UNEQUAL, E_LIST, E_SYMBOL,
E_RANGE
};
union expr_data {
@@ -49,6 +49,9 @@ struct expr {
#define E_AND(dep1, dep2) (((dep1)<(dep2))?(dep1):(dep2))
#define E_NOT(dep) (2-(dep))
+#define expr_list_for_each_sym(l, e, s) \
+ for (e = (l); e && (s = e->right.sym); e = e->left.expr)
+
struct expr_value {
struct expr *expr;
tristate tri;
Index: linux-2.6/scripts/kconfig/menu.c
===
--- linux-2.6.orig/scripts/kconfig/menu.c
+++ linux-2.6/scripts/kconfig/menu.c
@@ -331,7 +331,7 @@ void menu_finalize(struct menu *parent)
prop = sym_get_choice_prop(sym);
for (ep = >expr; *ep; ep = &(*ep)->left.expr)
;
- *ep =
Re: kconfig: support option env="" [Was: kconfig: use $K64BIT to set 64BIT with all*config targets]
Hi, On Sun, 6 Jan 2008, Sam Ravnborg wrote: > Please get back to me so we can finsih this patch and have it applied. > I will split the patch in two btw. I reworked the patch a little and split it into three. > > + if (sym->flags & SYMBOL_AUTO) > > + sym->flags &= ~SYMBOL_WRITE; > > + > > Why is this change needed? > It is non-obvious to me so please explain and I will add a comment. Automatically generated symbols are not saved, this was previously not needed as they weren't in the menu structure. > I did it like this: > menu_warn(current_entry, > "config %s: redefining environment symbol > from '%s' to '%s'", > sym->name, env, sym2->name); I omitted the prefix, it's inconsistent with other warnings. bye, Roman -- 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 002 of 6] md: Fix use-after-free bug when dropping an rdev from an md array.
On Mon, Jan 14, 2008 at 02:21:45PM +1100, Neil Brown wrote: > Maybe it isn't there any more > > Once upon a time, when I >echo remove > /sys/block/mdX/md/dev-YYY/state Egads. And just what will protect you from parallel callers of state_store()? buffer->mutex does *not* do that - it only gives you exclusion on given struct file. Run the command above from several shells and you've got independent open from each redirect => different struct file *and* different buffer for each => no exclusion whatsoever. And _that_ is present right in the mainline tree - it's unrelated to -mm kobject changes. BTW, yes, you do have a deadlock there - kobject_del() will try to evict children, which will include waiting for currently running ->store() to finish, which will include the caller since .../state *is* a child of that sucker. The real problem is the lack of any kind of exclusion considerations in md.c itself, AFAICS. Fun with ordering is secondary (BTW, yes, it is a problem - will sysfs ->store() to attribute between export_rdev() and kobject_del() work correctly?) -- 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 v2] Make PCI extended config space (MMCONFIG) a driver opt-in
To all ... Well, here is what I perceive we've got so far. . Some PCI Northbridges do not work with MMCONFIG. . Some PCI BARs can overlap the MMCONFIG area during bus sizing. It is hoped that new BIOSes will locate MMCONFIG in an area safely out of the way of bus sizing code, but there can be no guarantees. . conf1 is going away in newer x86 implementations in the not too distant future. . The PCI express spec requires platforms to provide access to the extended config area, and there are express devices today using that area for AER. . There is no need to provide different PCI config access mechanisms at device granularity, since the PCI config access mechanism between the CPU and the Northbridge is opaque to the devices. PCI config mechanisms only need to differ at the Northbridge level. . We have a flurry of patches all claiming to solve all or some of these problems. Arjan, I realize it may not be possible for you to answer this question, but I feel compelled to ask it anyway. Is it possible that future x86 architectures will be implementing a SAL-like interface to abstract PCI config access altogether? Or can we condense these patches down to a set that does the following? . If the system is capable of conf1, then PCI config access at offsets < 256 should be confined to conf1. This solution is most effective for existing and legacy systems. . If the system does not support MMCONFIG, of if MMCONFIG is not working, then accesses to offsets > 256 return -1 and an error status. . For systems, where the conf1 mechanism is NOT available, then MMCONFIG should be the PCI access mechanism for all offsets. For such systems, we must assume that the BIOS has become smart enough to locate MMCONFIG in a region safe from encroachment by bus sizing 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: [PATCH] [MEMSTICK] Initial commit for Sony MemoryStick support
--- Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 2 Jan 2008 17:42:24 +1100 [EMAIL PROTECTED] wrote:
>
> > From: Alex Dubov <[EMAIL PROTECTED]>
> >
> > Sony MemoryStick cards are used in many products manufactured by Sony. They
> > are available both as storage and as IO expansion cards. Currently, only
> > MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick
> > interface.
> >
>
> Will you be running a git tree for this? If so, please send me the link.
>
> Will this enable that thus-far useless slot on my Vaio?
>
> Where did the info come from which enabled this driver to be written? I
> thought Sony were super-secretive about this stuff?
>
I'm going to set-up git tree, yes.
It should support some vaios (newer ones for sure), as far as I know.
The primary reference for the driver is this one:
http://zeniv.linux.org.uk/~winbond/ (link is somewhat slow, but works). Winbond
developed GPLv2
driver for linux and there was enough info in their source code for my
implementation (totally
different from their's). Some reverse engineering of the windows driver was
needed too (for the TI
registers and such).
>
> > @@ -0,0 +1,26 @@
> > +#
> > +# MemoryStick subsystem configuration
> > +#
> > +
> > +menuconfig MEMSTICK
> > + tristate "Sony MemoryStick card support (EXPERIMENTAL)"
> > + help
> > + Sony MemoryStick is a proprietary storage/extension card protocol.
> > +
> > + If you want MemoryStick support, you should say Y here and also
> > + to the specific driver for your MMC interface.
>
> Are you sure this has enough dependencies? CONFIG_TIFM_* for a start?
This is supposed to be a generic layer, akin to mmc. I have a jmicron backend
in the works, and
windbond backend will be possible, too.
>
>
>
> We can create a config which has CONFIG_TIFM_CORE=m, CONFIG_MEMSTICK=y.
> That might not work?
>
> Anyway, please have a think about that.
Considering the previous point this should be ok.
>
> > ...
> >
> > +
> > +struct mspro_sys_attr {
> > + size_t size;
> > + unsigned char *data;
> > + unsigned char id;
> > + charname[32];
> > + struct device_attribute sys_attr;
> > +};
> > +
> > +struct mspro_attr_entry {
> > + unsigned int address;
> > + unsigned int size;
> > + unsigned char id;
> > + unsigned char reserved[3];
> > +} __attribute__((packed));
> > +
> > +struct mspro_attribute {
> > + unsigned short signature;
> > + unsigned short version;
> > + unsigned char count;
> > + unsigned char reserved[11];
> > + struct mspro_attr_entry entries[];
> > +} __attribute__((packed));
>
> Why are these packed? Do they map onto something whcih hardware knows
> about?
Yes, of course; all structures with "packed" attribute correspond to
appropriate protocol ones
(the endianness is tweaked as needed - most, but not all fields, are
big-endian).
> >
> > ...
> >
> > +struct mspro_block_data {
> > + struct memstick_dev *card;
> > + unsigned int usage_count;
> > + struct gendisk*disk;
> > + struct request_queue *queue;
> > + spinlock_tq_lock;
> > + wait_queue_head_t q_wait;
> > + struct task_struct*q_thread;
> > +
> > + unsigned shortpage_size;
> > + unsigned shortcylinders;
> > + unsigned shortheads;
> > + unsigned shortsectors_per_track;
> > +
> > + unsigned char system;
> > + unsigned char read_only:1,
> > + active:1,
> > + has_request:1,
> > + data_dir:1;
>
> You're aware that these four fields occupy the same machine word and that
> the compiler provides no locking? So if one thread attempts to modify
> "read_only" while another modifies "has_request", one can corrupt the work
> of the other?
>
> If this is indeed safe then a comment here whcih clearly explains that
> would be useful.
The access to these fields should be exclusively under q_lock (I'll check the
locking again, just
to make sure). After all, the same applies to old fashioned bit masks.
>
> > +}
> > +
> > +static ssize_t mspro_block_attr_show_modelname(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buffer)
> > +{
> > + struct mspro_sys_attr *x_attr = container_of(attr,
> > +struct mspro_sys_attr,
> > +sys_attr);
> > +
> > + return snprintf(buffer, PAGE_SIZE, "%s", x_attr->data);
> > +}
> >
> > ...
> >
> > +static int mspro_block_sysfs_register(struct memstick_dev *card)
> > +{
> > + struct mspro_block_data *msb = memstick_get_drvdata(card);
> > + int cnt, rc = 0;
> > +
> > + for (cnt = 0; cnt < msb->attr_count; cnt++) {
> > + rc = device_create_file(>dev,
>
Re: [PATCH 002 of 6] md: Fix use-after-free bug when dropping an rdev from an md array.
On Monday January 14, [EMAIL PROTECTED] wrote: > On Mon, Jan 14, 2008 at 12:45:31PM +1100, NeilBrown wrote: > > > > Due to possible deadlock issues we need to use a schedule work to > > kobject_del an 'rdev' object from a different thread. > > > > A recent change means that kobject_add no longer gets a refernce, and > > kobject_del doesn't put a reference. Consequently, we need to > > explicitly hold a reference to ensure that the last reference isn't > > dropped before the scheduled work get a chance to call kobject_del. > > > > Also, rename delayed_delete to md_delayed_delete to that it is more > > obvious in a stack trace which code is to blame. > > I don't know... You still get kobject_del() and export_rdev() > in unpredictable order; sure, it won't be freed under you, but... I cannot see that that would matter. kobject_del deletes the object from the kobj tree and free sysfs. export_rdev disconnects the objects from md structures and releases the connection with the device. They are quite independent. > > What is that deadlock problem, anyway? I don't see anything that > would look like an obvious candidate in the stuff you are delaying... Maybe it isn't there any more Once upon a time, when I echo remove > /sys/block/mdX/md/dev-YYY/state sysfs_write_file would hold buffer->sem while calling my store handler. When my store handler tried to delete the relevant kobject, it would eventually call orphan_all_buffers which would try to take buf->sem and deadlock. orphan_all_buffers doesn't exist any more, so maybe the deadlock is gone too. However the comment at the top of sysfs_schedule_callback in sysfs/file.c says: * * sysfs attribute methods must not unregister themselves or their parent * kobject (which would amount to the same thing). Attempts to do so will * deadlock, since unregistration is mutually exclusive with driver * callbacks. * so I'm included to leave the code as it is ofcourse the comment could be well out of date. NeilBrown -- 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: Netperf TCP_RR(loopback) 10% regression in 2.6.24-rc6, comparing with 2.6.22
On Fri, 2008-01-11 at 09:56 -0800, Rick Jones wrote: > >>The test command is: > >>#sudo taskset -c 7 ./netserver > >>#sudo taskset -c 0 ./netperf -t TCP_RR -l 60 -H 127.0.0.1 -i 50,3 -I 99,5 > >>-- -r 1,1 > > A couple of comments/questions on the command lines: Thanks for your kind comments. > > *) netperf/netserver support CPU affinity within themselves with the > global -T option to netperf. Is the result with taskset much different? >The equivalent to the above would be to run netperf with: > > ./netperf -T 0,7 .. I checked the source codes and didn't find this option. I use netperf V2.3 (I found the number in the makefile). > . > > The one possibly salient difference between the two is that when done > within netperf, the initial process creation will take place wherever > the scheduler wants it. > > *) The -i option to set the confidence iteration count will silently cap > the max at 30. Indeed, you are right. -yanmin -- 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] Reset ACPI backlight on resume
Some machines seem to need the backlight brightness to be reset on
resume. Add support for doing so to the video module.
Signed-off-by: Matthew Garrett <[EMAIL PROTECTED]>
---
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index b8ce6dc..09a85eb 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -74,6 +74,7 @@ MODULE_LICENSE("GPL");
static int acpi_video_bus_add(struct acpi_device *device);
static int acpi_video_bus_remove(struct acpi_device *device, int type);
+static int acpi_video_resume(struct acpi_device *device);
static const struct acpi_device_id video_device_ids[] = {
{ACPI_VIDEO_HID, 0},
@@ -88,6 +89,7 @@ static struct acpi_driver acpi_video_bus = {
.ops = {
.add = acpi_video_bus_add,
.remove = acpi_video_bus_remove,
+ .resume = acpi_video_resume,
},
};
@@ -1896,6 +1900,25 @@ static void acpi_video_device_notify(acpi_handle handle,
u32 event, void *data)
}
static int instance;
+static int acpi_video_resume(struct acpi_device *device)
+{
+ struct acpi_video_bus *video;
+ struct acpi_video_device *video_device;
+ int i;
+
+ if (!device || !acpi_driver_data(device))
+ return -EINVAL;
+
+ video = acpi_driver_data(device);
+
+ for (i=0; iattached_count; i++) {
+ video_device = video->attached_array[i].bind_info;
+ if (video_device && video_device->backlight)
+ acpi_video_set_brightness(video_device->backlight);
+ }
+ return AE_OK;
+}
+
static int acpi_video_bus_add(struct acpi_device *device)
{
acpi_status status;
--
Matthew Garrett | [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: fixed a bug of adma in rhel4u5 with HDS7250SASUN500G.
Robert hancock wrote: > What problem does this resolve? I tested it against the cache > flush/NCQ > write switching problem we've been trying to solve, and it > doesn't look > like it fixes that one - if I apply this patch and then remove the > udelay(20) in sata_nv.c that I added which prevented me from > seeing this > problem before, it shows up. > First thank davide to help to send the attachment. Robert, The patch is to solve the error message "ata1: CPB flags CMD err, flags=0x11" when testing HDS7250SASUN500G in rhel4u5. I tested this hd in 2.6.24-rc7 which needed to remove the mask in blacklist to run the ncq and the same error also showed up. I traced the bug and found that the interrupt finished a command (for example, tag=0) when the driver got that adma status is NV_ADMA_STAT_DONE and cpb->resp_flags is NV_CPB_RESP_DONE. However, For this hd, the drive maybe didn't clear bit 0 at this moment. It meaned the hardware had not completely finished the command. If at the same time the driver freed the command(tag 0) and sended another command (tag 0), the error happened. The notifier register is 32-bit register containing notifier value. Value is bit vector containing one bit per tag number (0-31) in corresponding bit positions (bit 0 is for tag 0, etc). When bit is set then ADMA indicates that command with corresponding tag number completed execution. So i added the check notifier code. Sometimes i saw that the notifier reg set some bits , but the adma status set NV_ADMA_STAT_CMD_COMPLETE ,not NV_ADMA_STAT_DONE. So i added the NV_ADMA_STAT_CMD_COMPLETE check code. --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- -- 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/2] [SERIAL] avoid stalling suspend if serial port won't drain
Hi. Alan Cox wrote: >>> Is printk() enough for 'we've just lost your data' condition? Maybe we >>> should abort suspend if we can't drain fifo? >> No way. Think about this from a users' perspective. No one wants suspend >> to ram or hibernate functionality that works sometimes and not others. >> They want it to work reliably so they don't have to worry about their >> laptop overheating while they're getting on the bus or airplane. >> Aborting isn't an option. > > Dumb question on the printk however - what if the port that is sticking > is the console - don't we recurse and die ? I don't know, but I'd argue that we shouldn't die. Things should be as robust as possible. Regards, Nigel -- 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] Fix kprobes on ia64
If CONFIG_KPROBES is set, we get the error during build: kernel/kprobes.c:1057: error: __ksymtab_jprobe_return causes a section type conflict This is because ia64 defines a static inline jprobe_return which kprobes attempts to EXPORT_SYMBOL. Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]> diff --git a/kernel/kprobes.c b/kernel/kprobes.c index e3a5d81..ecc25b3 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -1053,11 +1053,11 @@ EXPORT_SYMBOL_GPL(register_kprobe); EXPORT_SYMBOL_GPL(unregister_kprobe); EXPORT_SYMBOL_GPL(register_jprobe); EXPORT_SYMBOL_GPL(unregister_jprobe); + #ifdef CONFIG_KPROBES +#ifndef __ia64__ /* It's static inline */ EXPORT_SYMBOL_GPL(jprobe_return); #endif - -#ifdef CONFIG_KPROBES EXPORT_SYMBOL_GPL(register_kretprobe); EXPORT_SYMBOL_GPL(unregister_kretprobe); #endif -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- 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 002 of 6] md: Fix use-after-free bug when dropping an rdev from an md array.
On Mon, Jan 14, 2008 at 12:45:31PM +1100, NeilBrown wrote: > > Due to possible deadlock issues we need to use a schedule work to > kobject_del an 'rdev' object from a different thread. > > A recent change means that kobject_add no longer gets a refernce, and > kobject_del doesn't put a reference. Consequently, we need to > explicitly hold a reference to ensure that the last reference isn't > dropped before the scheduled work get a chance to call kobject_del. > > Also, rename delayed_delete to md_delayed_delete to that it is more > obvious in a stack trace which code is to blame. I don't know... You still get kobject_del() and export_rdev() in unpredictable order; sure, it won't be freed under you, but... What is that deadlock problem, anyway? I don't see anything that would look like an obvious candidate in the stuff you are delaying... -- 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: Lenovo ThinkPads need acpi_osi="Linux"
On Sun, Jan 13, 2008 at 11:57:18PM -0200, Henrique de Moraes Holschuh wrote: > On Mon, 14 Jan 2008, Matthew Garrett wrote: > > not going to want the low-level ACPI code to do anything video-related > > on a lot of hardware. The in-kernel modesetting code for Intel machines > > will be able to handle this significantly more effectively. > > Yeah, but we have a ton of machines (thinkpads among them) with ATI, and > other GPUs. The ATI case is certainly more of an issue, but I'm becoming more optimistic about that being workable in the near future - certainly on machines with ATOM-based BIOSes. > Whitelists would need to be reasonably specific, anyway (not "all > thinkpads"), so it just means "don't do it on certain R50e", or whatever. I'd prefer not to push this policy into the kernel, since the right thing to do depends on which graphics drivers you're using and so on. Userspace is in a better position to make this determination. Of course, this also means not passing the Linux OSI to the firmware. Our hardware interaction is sufficiently in flux that any attempt to work around it in the firmware is just going to lead to bizarre breakage down the road. -- Matthew Garrett | [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: [PATCH 2/7] ieee1394 : use class iteration api
On Jan 12, 2008 7:10 PM, Stefan Richter <[EMAIL PROTECTED]> wrote:
> Dave Young wrote:
> > +++ linux.new/drivers/ieee1394/nodemgr.c 2008-01-12 15:20:27.0
> > +0800
> ...
>
> > static void nodemgr_remove_uds(struct node_entry *ne)
> > {
> > struct device *dev;
> > - struct unit_directory *tmp, *ud;
> > + struct unit_directory *ud;
> >
> > - /* Iteration over nodemgr_ud_class.devices has to be protected by
> > - * nodemgr_ud_class.sem, but device_unregister() will eventually
> > - * take nodemgr_ud_class.sem too. Therefore pick out one ud at a time,
> > - * release the semaphore, and then unregister the ud. Since this code
> > - * may be called from other contexts besides the knodemgrds, protect
> > the
> > - * gap after release of the semaphore by nodemgr_serialize_remove_uds.
> > + /* Use class_find device to iterate the devices. Since this code
> > + * may be called from other contexts besides the knodemgrds,
> > + * protect it by nodemgr_serialize_remove_uds.
> >*/
> > mutex_lock(_serialize_remove_uds);
> > - for (;;) {
> > - ud = NULL;
> > - down(_ud_class.sem);
> > - list_for_each_entry(dev, _ud_class.devices, node) {
> > - tmp = container_of(dev, struct unit_directory,
> > -unit_dev);
> > - if (tmp->ne == ne) {
> > - ud = tmp;
> > - break;
> > - }
> > - }
> > - up(_ud_class.sem);
> > - if (ud == NULL)
> > - break;
> > - device_unregister(>unit_dev);
> > - device_unregister(>device);
> > + dev = class_find_device(_ud_class, ne, __match_ne);
> > + if (!dev) {
> > + mutex_unlock(_serialize_remove_uds);
> > + return;
> > }
> > + ud = container_of(dev, struct unit_directory, unit_dev);
> > + device_unregister(>unit_dev);
> > + device_unregister(>device);
> > mutex_unlock(_serialize_remove_uds);
> > }
>
> A quick response on this change, without having checked the rest yet:
>
> This doesn't work. Each "ne" may have zero or more "ud". The purpose
> of nodemgr_remove_uds is to kill all of the uds of one ne. After your
> change, only the first ud of a ne would be gone.
>
> You need to keep the loop which takes care that all of the uds of the ne
> are removed
My wrong, will fix.
>
> Furthermore, I usually try to use "goto" or "break" constructs with
> single unlock + return path instead of multiple unlock + return paths.
> However, if these unlock + return paths are as visually close together
> as they are here, it doesn't really matter (to me) which of the styles
> is used.
I will update as your style in this patch, thanks for review.
>
> BTW, you don't need to CC <[EMAIL PROTECTED]> on drivers/ieee1394/ patches
> (CONFIG_IEEE1394). He only looks after drivers/firewire/
> (CONFIG_FIREWIRE). I know, these are details, and everybody confuses
> them. :-) I should try to clarify this in MAINTAINERS.
Ok.
> --
> Stefan Richter
> -=-==--- ---= -==--
> http://arcgraph.de/sr/
>
--
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: Lenovo ThinkPads need acpi_osi="Linux"
On Mon, 14 Jan 2008, Matthew Garrett wrote: > On Mon, Jan 14, 2008 at 12:35:54AM +, Matthew Garrett wrote: > > No. This breaks on the R50e, at least - I suspect it'd also have > > problems on any nvidia based machines, but I don't have one to hand at > > the moment. It can be set at runtime already. > > Just to clarify this further, in the relatively near-term future we're > not going to want the low-level ACPI code to do anything video-related > on a lot of hardware. The in-kernel modesetting code for Intel machines > will be able to handle this significantly more effectively. Yeah, but we have a ton of machines (thinkpads among them) with ATI, and other GPUs. Whitelists would need to be reasonably specific, anyway (not "all thinkpads"), so it just means "don't do it on certain R50e", or whatever. It is no easy problem, and the fix might not be as simple as one could wish, either. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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] Rationalise ACPI backlight implementation
Len, I've had no feedback on this - the backlight maintainer thinks it's the right way to go, so I'd like to get it queued for .25 at least. -- Matthew Garrett | [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: Lenovo ThinkPads need acpi_osi="Linux"
On Mon, Jan 14, 2008 at 12:35:54AM +, Matthew Garrett wrote: > No. This breaks on the R50e, at least - I suspect it'd also have > problems on any nvidia based machines, but I don't have one to hand at > the moment. It can be set at runtime already. Just to clarify this further, in the relatively near-term future we're not going to want the low-level ACPI code to do anything video-related on a lot of hardware. The in-kernel modesetting code for Intel machines will be able to handle this significantly more effectively. -- Matthew Garrett | [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/
[PATCH 006 of 6] md: Change ITERATE_RDEV_GENERIC to rdev_for_each_list, and remove ITERATE_RDEV_PENDING.
Finish ITERATE_ to for_each conversion.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./drivers/md/md.c |8
./include/linux/raid/md_k.h | 14 --
2 files changed, 8 insertions(+), 14 deletions(-)
diff .prev/drivers/md/md.c ./drivers/md/md.c
--- .prev/drivers/md/md.c 2008-01-14 12:26:10.0 +1100
+++ ./drivers/md/md.c 2008-01-14 12:26:15.0 +1100
@@ -3767,7 +3767,7 @@ static void autorun_devices(int part)
printk(KERN_INFO "md: considering %s ...\n",
bdevname(rdev0->bdev,b));
INIT_LIST_HEAD();
- ITERATE_RDEV_PENDING(rdev,tmp)
+ rdev_for_each_list(rdev, tmp, pending_raid_disks)
if (super_90_load(rdev, rdev0, 0) >= 0) {
printk(KERN_INFO "md: adding %s ...\n",
bdevname(rdev->bdev,b));
@@ -3810,7 +3810,7 @@ static void autorun_devices(int part)
mddev_unlock(mddev);
} else {
printk(KERN_INFO "md: created %s\n", mdname(mddev));
- ITERATE_RDEV_GENERIC(candidates,rdev,tmp) {
+ rdev_for_each_list(rdev, tmp, candidates) {
list_del_init(>same_set);
if (bind_rdev_to_array(rdev, mddev))
export_rdev(rdev);
@@ -3821,7 +3821,7 @@ static void autorun_devices(int part)
/* on success, candidates will be empty, on error
* it won't...
*/
- ITERATE_RDEV_GENERIC(candidates,rdev,tmp)
+ rdev_for_each_list(rdev, tmp, candidates)
export_rdev(rdev);
mddev_put(mddev);
}
@@ -4936,7 +4936,7 @@ static void status_unused(struct seq_fil
seq_printf(seq, "unused devices: ");
- ITERATE_RDEV_PENDING(rdev,tmp) {
+ rdev_for_each_list(rdev, tmp, pending_raid_disks) {
char b[BDEVNAME_SIZE];
i++;
seq_printf(seq, "%s ",
diff .prev/include/linux/raid/md_k.h ./include/linux/raid/md_k.h
--- .prev/include/linux/raid/md_k.h 2008-01-14 12:26:10.0 +1100
+++ ./include/linux/raid/md_k.h 2008-01-14 12:26:15.0 +1100
@@ -313,23 +313,17 @@ static inline char * mdname (mddev_t * m
* iterates through some rdev ringlist. It's safe to remove the
* current 'rdev'. Dont touch 'tmp' though.
*/
-#define ITERATE_RDEV_GENERIC(head,rdev,tmp)\
+#define rdev_for_each_list(rdev, tmp, list)\
\
- for ((tmp) = (head).next; \
+ for ((tmp) = (list).next; \
(rdev) = (list_entry((tmp), mdk_rdev_t, same_set)), \
- (tmp) = (tmp)->next, (tmp)->prev != &(head) \
+ (tmp) = (tmp)->next, (tmp)->prev != &(list) \
; )
/*
* iterates through the 'same array disks' ringlist
*/
#define rdev_for_each(rdev, tmp, mddev)\
- ITERATE_RDEV_GENERIC((mddev)->disks,rdev,tmp)
-
-/*
- * Iterates through 'pending RAID disks'
- */
-#define ITERATE_RDEV_PENDING(rdev,tmp) \
- ITERATE_RDEV_GENERIC(pending_raid_disks,rdev,tmp)
+ rdev_for_each_list(rdev, tmp, (mddev)->disks)
typedef struct mdk_thread_s {
void(*run) (mddev_t *mddev);
--
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: regression: 100% io-wait with 2.6.24-rcX
On Sun, Jan 13, 2008 at 10:49:31AM +0100, Joerg Platte wrote: > register_jprobe(ext2_writepage) = 0 > register_jprobe(requeue_io) = 0 > register_kprobe(submit_bio) = 0 > requeue_io: > inode 114019(sda7/.kde) count 2,2 size 0 pages 1 > 0 2 0 U > requeue_io: > inode 114025(sda7/cache-ibm) count 2,1 size 0 pages 1 > 0 2 0 U > requeue_io: > inode 114029(sda7/socket-ibm) count 2,3 size 0 pages 1 > 0 2 0 U > requeue_io: > inode 114017(sda7/0266584877) count 3,6 size 0 pages 1 > 0 2 0 U It helps. Thank you, Joerg! The .kde/cache-ibm/socket-ibm/0266584877 above are directories. It's weird that dirs would have their own mappings in ext2. In particular this bug is triggered because the dir mapping page has PAGECACHE_TAG_DIRTY set and PG_dirty cleared, staying in an inconsistent state. Fengguang -- 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 005 of 6] md: Change ITERATE_RDEV to rdev_for_each
as this is morein line with common practice in the kernel.
Also swap the args around to be more like list_for_each.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./drivers/md/bitmap.c |4 +-
./drivers/md/faulty.c |2 -
./drivers/md/linear.c |2 -
./drivers/md/md.c | 64 ++--
./drivers/md/multipath.c|2 -
./drivers/md/raid0.c|8 ++---
./drivers/md/raid1.c|2 -
./drivers/md/raid10.c |2 -
./drivers/md/raid5.c|6 ++--
./include/linux/raid/md_k.h |2 -
10 files changed, 47 insertions(+), 47 deletions(-)
diff .prev/drivers/md/bitmap.c ./drivers/md/bitmap.c
--- .prev/drivers/md/bitmap.c 2008-01-11 15:01:13.0 +1100
+++ ./drivers/md/bitmap.c 2008-01-14 12:26:10.0 +1100
@@ -231,7 +231,7 @@ static struct page *read_sb_page(mddev_t
if (!page)
return ERR_PTR(-ENOMEM);
- ITERATE_RDEV(mddev, rdev, tmp) {
+ rdev_for_each(rdev, tmp, mddev) {
if (! test_bit(In_sync, >flags)
|| test_bit(Faulty, >flags))
continue;
@@ -255,7 +255,7 @@ static int write_sb_page(struct bitmap *
struct list_head *tmp;
mddev_t *mddev = bitmap->mddev;
- ITERATE_RDEV(mddev, rdev, tmp)
+ rdev_for_each(rdev, tmp, mddev)
if (test_bit(In_sync, >flags)
&& !test_bit(Faulty, >flags)) {
int size = PAGE_SIZE;
diff .prev/drivers/md/faulty.c ./drivers/md/faulty.c
--- .prev/drivers/md/faulty.c 2008-01-11 15:01:13.0 +1100
+++ ./drivers/md/faulty.c 2008-01-14 12:26:10.0 +1100
@@ -294,7 +294,7 @@ static int run(mddev_t *mddev)
}
conf->nfaults = 0;
- ITERATE_RDEV(mddev, rdev, tmp)
+ rdev_for_each(rdev, tmp, mddev)
conf->rdev = rdev;
mddev->array_size = mddev->size;
diff .prev/drivers/md/linear.c ./drivers/md/linear.c
--- .prev/drivers/md/linear.c 2008-01-11 15:01:13.0 +1100
+++ ./drivers/md/linear.c 2008-01-14 12:26:10.0 +1100
@@ -122,7 +122,7 @@ static linear_conf_t *linear_conf(mddev_
cnt = 0;
conf->array_size = 0;
- ITERATE_RDEV(mddev,rdev,tmp) {
+ rdev_for_each(rdev, tmp, mddev) {
int j = rdev->raid_disk;
dev_info_t *disk = conf->disks + j;
diff .prev/drivers/md/md.c ./drivers/md/md.c
--- .prev/drivers/md/md.c 2008-01-14 12:26:04.0 +1100
+++ ./drivers/md/md.c 2008-01-14 12:26:10.0 +1100
@@ -311,7 +311,7 @@ static mdk_rdev_t * find_rdev_nr(mddev_t
mdk_rdev_t * rdev;
struct list_head *tmp;
- ITERATE_RDEV(mddev,rdev,tmp) {
+ rdev_for_each(rdev, tmp, mddev) {
if (rdev->desc_nr == nr)
return rdev;
}
@@ -323,7 +323,7 @@ static mdk_rdev_t * find_rdev(mddev_t *
struct list_head *tmp;
mdk_rdev_t *rdev;
- ITERATE_RDEV(mddev,rdev,tmp) {
+ rdev_for_each(rdev, tmp, mddev) {
if (rdev->bdev->bd_dev == dev)
return rdev;
}
@@ -944,7 +944,7 @@ static void super_90_sync(mddev_t *mddev
sb->state |= (1= 0 && test_bit(In_sync, >flags)
@@ -1297,7 +1297,7 @@ static void super_1_sync(mddev_t *mddev,
}
max_dev = 0;
- ITERATE_RDEV(mddev,rdev2,tmp)
+ rdev_for_each(rdev2, tmp, mddev)
if (rdev2->desc_nr+1 > max_dev)
max_dev = rdev2->desc_nr+1;
@@ -1306,7 +1306,7 @@ static void super_1_sync(mddev_t *mddev,
for (i=0; idev_roles[i] = cpu_to_le16(0xfffe);
- ITERATE_RDEV(mddev,rdev2,tmp) {
+ rdev_for_each(rdev2, tmp, mddev) {
i = rdev2->desc_nr;
if (test_bit(Faulty, >flags))
sb->dev_roles[i] = cpu_to_le16(0xfffe);
@@ -1344,8 +1344,8 @@ static int match_mddev_units(mddev_t *md
struct list_head *tmp, *tmp2;
mdk_rdev_t *rdev, *rdev2;
- ITERATE_RDEV(mddev1,rdev,tmp)
- ITERATE_RDEV(mddev2, rdev2, tmp2)
+ rdev_for_each(rdev, tmp, mddev1)
+ rdev_for_each(rdev2, tmp2, mddev2)
if (rdev->bdev->bd_contains ==
rdev2->bdev->bd_contains)
return 1;
@@ -1518,7 +1518,7 @@ static void export_array(mddev_t *mddev)
struct list_head *tmp;
mdk_rdev_t *rdev;
- ITERATE_RDEV(mddev,rdev,tmp) {
+ rdev_for_each(rdev, tmp, mddev) {
if (!rdev->mddev) {
MD_BUG();
continue;
@@ -1602,11 +1602,11 @@ static void md_print_devices(void)
bitmap_print_sb(mddev->bitmap);
else
printk("%s: ", mdname(mddev));
-
[PATCH 002 of 6] md: Fix use-after-free bug when dropping an rdev from an md array.
Due to possible deadlock issues we need to use a schedule work to
kobject_del an 'rdev' object from a different thread.
A recent change means that kobject_add no longer gets a refernce, and
kobject_del doesn't put a reference. Consequently, we need to
explicitly hold a reference to ensure that the last reference isn't
dropped before the scheduled work get a chance to call kobject_del.
Also, rename delayed_delete to md_delayed_delete to that it is more
obvious in a stack trace which code is to blame.
Cc: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./drivers/md/md.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff .prev/drivers/md/md.c ./drivers/md/md.c
--- .prev/drivers/md/md.c 2008-01-14 12:23:53.0 +1100
+++ ./drivers/md/md.c 2008-01-14 12:24:17.0 +1100
@@ -1421,10 +1421,11 @@ static int bind_rdev_to_array(mdk_rdev_t
return err;
}
-static void delayed_delete(struct work_struct *ws)
+static void md_delayed_delete(struct work_struct *ws)
{
mdk_rdev_t *rdev = container_of(ws, mdk_rdev_t, del_work);
kobject_del(>kobj);
+ kobject_put(>kobj);
}
static void unbind_rdev_from_array(mdk_rdev_t * rdev)
@@ -1443,7 +1444,8 @@ static void unbind_rdev_from_array(mdk_r
/* We need to delay this, otherwise we can deadlock when
* writing to 'remove' to "dev/state"
*/
- INIT_WORK(>del_work, delayed_delete);
+ INIT_WORK(>del_work, md_delayed_delete);
+ kobject_get(>kobj);
schedule_work(>del_work);
}
@@ -3688,7 +3690,7 @@ static int do_md_stop(mddev_t * mddev, i
sysfs_remove_link(>kobj, nm);
}
- /* make sure all delayed_delete calls have finished */
+ /* make sure all md_delayed_delete calls have finished */
flush_scheduled_work();
export_array(mddev);
--
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 003 of 6] md: Change a few 'int' to 'size_t' in md
As suggested by Andrew Morton.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./drivers/md/md.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff .prev/drivers/md/md.c ./drivers/md/md.c
--- .prev/drivers/md/md.c 2008-01-14 12:24:17.0 +1100
+++ ./drivers/md/md.c 2008-01-14 12:24:31.0 +1100
@@ -1802,7 +1802,7 @@ static ssize_t
state_show(mdk_rdev_t *rdev, char *page)
{
char *sep = "";
- int len=0;
+ size_t len = 0;
if (test_bit(Faulty, >flags)) {
len+= sprintf(page+len, "%sfaulty",sep);
@@ -2320,7 +2320,7 @@ level_show(mddev_t *mddev, char *page)
static ssize_t
level_store(mddev_t *mddev, const char *buf, size_t len)
{
- int rv = len;
+ ssize_t rv = len;
if (mddev->pers)
return -EBUSY;
if (len == 0)
@@ -2807,7 +2807,7 @@ metadata_store(mddev_t *mddev, const cha
return len;
}
if (strncmp(buf, "external:", 9) == 0) {
- int namelen = len-9;
+ size_t namelen = len-9;
if (namelen >= sizeof(mddev->metadata_type))
namelen = sizeof(mddev->metadata_type)-1;
strncpy(mddev->metadata_type, buf+9, namelen);
--
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 004 of 6] md: Change INTERATE_MDDEV to for_each_mddev
As this is more consistent with kernel style.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./drivers/md/md.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff .prev/drivers/md/md.c ./drivers/md/md.c
--- .prev/drivers/md/md.c 2008-01-14 12:24:54.0 +1100
+++ ./drivers/md/md.c 2008-01-14 12:26:04.0 +1100
@@ -195,7 +195,7 @@ static DEFINE_SPINLOCK(all_mddevs_lock);
* Any code which breaks out of this loop while own
* a reference to the current mddev and must mddev_put it.
*/
-#define ITERATE_MDDEV(mddev,tmp) \
+#define for_each_mddev(mddev,tmp) \
\
for (({ spin_lock(_mddevs_lock);\
tmp = all_mddevs.next; \
@@ -1596,7 +1596,7 @@ static void md_print_devices(void)
printk("md: **\n");
printk("md: * *\n");
printk("md: **\n");
- ITERATE_MDDEV(mddev,tmp) {
+ for_each_mddev(mddev, tmp) {
if (mddev->bitmap)
bitmap_print_sb(mddev->bitmap);
@@ -2014,7 +2014,7 @@ rdev_size_store(mdk_rdev_t *rdev, const
struct list_head *tmp, *tmp2;
mddev_unlock(rdev->mddev);
- ITERATE_MDDEV(mddev, tmp) {
+ for_each_mddev(mddev, tmp) {
mdk_rdev_t *rdev2;
mddev_lock(mddev);
@@ -5464,7 +5464,7 @@ void md_do_sync(mddev_t *mddev)
set_bit(MD_RECOVERY_INTR, >recovery);
goto skip;
}
- ITERATE_MDDEV(mddev2,tmp) {
+ for_each_mddev(mddev2, tmp) {
if (mddev2 == mddev)
continue;
if (mddev2->curr_resync &&
@@ -5912,7 +5912,7 @@ static int md_notify_reboot(struct notif
printk(KERN_INFO "md: stopping all md devices.\n");
- ITERATE_MDDEV(mddev,tmp)
+ for_each_mddev(mddev, tmp)
if (mddev_trylock(mddev)) {
do_md_stop (mddev, 1);
mddev_unlock(mddev);
@@ -6046,7 +6046,7 @@ static __exit void md_exit(void)
unregister_reboot_notifier(_notifier);
unregister_sysctl_table(raid_table_header);
remove_proc_entry("mdstat", NULL);
- ITERATE_MDDEV(mddev,tmp) {
+ for_each_mddev(mddev, tmp) {
struct gendisk *disk = mddev->gendisk;
if (!disk)
continue;
--
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 001 of 6] md: Fix an occasional deadlock in raid5
raid5's 'make_request' function calls generic_make_request on
underlying devices and if we run out of stripe heads, it could end up
waiting for one of those requests to complete.
This is bad as recursive calls to generic_make_request go on a queue
and are not even attempted until make_request completes.
So: don't make any generic_make_request calls in raid5 make_request
until all waiting has been done. We do this by simply setting
STRIPE_HANDLE instead of calling handle_stripe().
If we need more stripe_heads, raid5d will get called to process the
pending stripe_heads which will call generic_make_request from a
different thread where no deadlock will happen.
This change by itself causes a performance hit. So add a change so
that raid5_activate_delayed is only called at unplug time, never in
raid5. This seems to bring back the performance numbers. Calling it
in raid5d was sometimes too soon...
Cc: "Dan Williams" <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./drivers/md/raid5.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff .prev/drivers/md/raid5.c ./drivers/md/raid5.c
--- .prev/drivers/md/raid5.c2008-01-11 15:01:14.0 +1100
+++ ./drivers/md/raid5.c2008-01-14 12:24:07.0 +1100
@@ -3157,7 +3157,8 @@ static void raid5_activate_delayed(raid5
atomic_inc(>preread_active_stripes);
list_add_tail(>lru, >handle_list);
}
- }
+ } else
+ blk_plug_device(conf->mddev->queue);
}
static void activate_bit_delay(raid5_conf_t *conf)
@@ -3547,7 +3548,7 @@ static int make_request(struct request_q
goto retry;
}
finish_wait(>wait_for_overlap, );
- handle_stripe(sh, NULL);
+ set_bit(STRIPE_HANDLE, >state);
release_stripe(sh);
} else {
/* cannot get stripe for read-ahead, just give-up */
@@ -3890,7 +3891,7 @@ static int retry_aligned_read(raid5_con
* During the scan, completed stripes are saved for us by the interrupt
* handler, so that they will not have to wait for our next wakeup.
*/
-static void raid5d (mddev_t *mddev)
+static void raid5d(mddev_t *mddev)
{
struct stripe_head *sh;
raid5_conf_t *conf = mddev_to_conf(mddev);
@@ -3915,12 +3916,6 @@ static void raid5d (mddev_t *mddev)
activate_bit_delay(conf);
}
- if (list_empty(>handle_list) &&
- atomic_read(>preread_active_stripes) < IO_THRESHOLD &&
- !blk_queue_plugged(mddev->queue) &&
- !list_empty(>delayed_list))
- raid5_activate_delayed(conf);
-
while ((bio = remove_bio_from_retry(conf))) {
int ok;
spin_unlock_irq(>device_lock);
--
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 000 of 6] md: various fixes for md
Following are 6 patches for md which are suitable for 2.6.25-rc1. The first fixes a bug which could make it a candidate for 24-final. However it is a deadlock that seems to occur very rarely, and has been in mainline since 2.6.22. So letting it into one more release shouldn't be a big problem. While the fix is fairly simple, it could have some unexpected consequences, so I'd rather go for the next cycle. The second patch fixes a bug which only affect -mm at the moment but will probably affect 2.6.25 unless fixed. The rest are cleanups with no functional change (I hope). Thanks, NeilBrown [PATCH 001 of 6] md: Fix an occasional deadlock in raid5 [PATCH 002 of 6] md: Fix use-after-free bug when dropping an rdev from an md array. [PATCH 003 of 6] md: Change a few 'int' to 'size_t' in md [PATCH 004 of 6] md: Change INTERATE_MDDEV to for_each_mddev [PATCH 005 of 6] md: Change ITERATE_RDEV to rdev_for_each [PATCH 006 of 6] md: Change ITERATE_RDEV_GENERIC to rdev_for_each_list, and remove ITERATE_RDEV_PENDING. -- 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/
EXPORTS_SYMBOLs that are in assembly?
Hi guys, Just wondering what the proper way to export a symbol that is defined in assembly? Or is there some kind of annotation I can add in comment form that will let checkpatch know the variable is not in C? Here's what I'm getting: ./scripts/checkpatch.pl patches/`quilt top` WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable #197: FILE: lib/tracing/mcount.c:42: +EXPORT_SYMBOL_GPL(mcount); total: 0 errors, 1 warnings, 316 lines checked Your patch has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. Thanks, -- Steve -- 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] Default keyboard LEDs
On Jan 14 2008 00:52, Samuel Thibault wrote: > >In many cases, one prefers to have e.g. the NumLock on by default. In >many cases, one doesn't want to have it by default, e.g. on laptops. > >Distributions actually have a very hard time trying to set this >correctly after the kernel boot, and that doesn't work for new consoles >that are created via the openvt(1) command anyway. This hence adds a >keyboard.default_leds boot parameter that permits to configure the >default keyboard LEDs. Apart from openvt being able to find the first unused tty, what is openvt good for? (Read: I could just as well run `bash /dev/tty8 2>/dev/tty8`) -- 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: Top 10 kernel oopses for the week ending January 5th, 2008
On Thursday January 10, [EMAIL PROTECTED] wrote: > On Thu, Jan 10, 2008 at 03:13:48PM +1100, Neil Brown wrote: > > > What guarantees that it doesn't happen before we get to callback? AFAICS, > > > nothing whatsoever... > > > > Yes, that's bad isn't it :-) > > > > I think I should be using sysfs_schedule_callback here. That makes the > > required 'get' and 'put' calls but it can fail with -ENOMEM. I > > wonder what I do if -ENOMEM??? Maybe I'll just continue to roll my > > one :-( > > How about this instead (completely untested) > > * split failure exits > * switch to kick_rdev_from_array() > * fold unbind_rdev_from_array() into it (no other callers anymore) > * take export_rdev() into failure case in bind_rdev_to_array() > * in kick_rdev_from_array() do what export_rdev() does sans > kobject_put() and do that before schedule_work(). Take kobject_put() into > delayed_delete(). While there are probably some good ideas in there, I think fixing this particular bug is much simpler. Just take a reference to the object before scheduling the worker, and drop it when the worker has done its work. I have a closer look at the idea of no required export_rdev after a failed bind_rdev_to_array. On the surface it does seem to make the code nicer. Thanks, NeilBrown -- 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/7] driver-core : add class iteration api
On Jan 13, 2008 4:11 AM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
>
> On Sat, Jan 12, 2008 at 05:47:54PM +0800, Dave Young wrote:
> > Add the following class iteration functions for driver use:
> > class_for_each_device
> > class_find_device
> > class_for_each_child
> > class_find_child
> >
> > Signed-off-by: Dave Young <[EMAIL PROTECTED]>
> >
> > ---
> > drivers/base/class.c | 159
> > +
> > include/linux/device.h |8 ++
> > 2 files changed, 167 insertions(+)
> >
> > diff -upr linux/drivers/base/class.c linux.new/drivers/base/class.c
> > --- linux/drivers/base/class.c2008-01-12 14:42:24.0 +0800
> > +++ linux.new/drivers/base/class.c2008-01-12 14:42:24.0 +0800
> > @@ -798,6 +798,165 @@ void class_device_put(struct class_devic
> > kobject_put(_dev->kobj);
> > }
> >
> > +/**
> > + * class_for_each_device - device iterator
> > + * @class: the class we're iterating
> > + * @data: data for the callback
> > + * @fn: function to be called for each device
> > + *
> > + * Iterate over @class's list of devices, and call @fn for each,
> > + * passing it @data.
> > + *
> > + * We check the return of @fn each time. If it returns anything
> > + * other than 0, we break out and return that value.
> > + */
> > +int class_for_each_device(struct class *class, void *data,
> > +int (*fn)(struct device *, void *))
> > +{
> > + struct device *dev;
> > + int error = 0;
> > +
> > + if (!class)
> > + return -EINVAL;
> > + down(>sem);
> > + list_for_each_entry(dev, >devices, node) {
>
> Probably some tiny oversight, but I see this comment to struct class
> doesn't mention devices list, so maybe this needs to be updated BTW?:
>
> (from include/linux/device.h)
> "struct semaphoresem;/* locks both the children and
> interfaces lists */"
Sorry for my lazy, I think so too.
IMHO, it should be updated after the comments.
>
> Regards,
> Jarek P.
>
--
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 v2] Make PCI extended config space (MMCONFIG) a driver opt-in
On Mon, 14 Jan 2008 00:54:34 + Alan Cox <[EMAIL PROTECTED]> wrote: > On Sun, 13 Jan 2008 16:28:08 -0500 > Tony Camuso <[EMAIL PROTECTED]> wrote: > > > Arjan van de Ven wrote: > > > > >> The PCI spec provides for conf1 as an architected solution. It's > > >> not going away, and especially not in x86 land where Port IO is > > >> built-in to the CPU. > > > I suspect Arjan is wrong. It might be some Intel agenda but I still > see fairly new driver reference code that is hardcoding port accesses > even when designed for Redmond products. I find it hard to believe that even they have their drivers do PCI config access via ports directly from the drivers, and especially in driver reference code... -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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/7] driver-core : add class iteration api
On Jan 12, 2008 6:50 PM, Stefan Richter <[EMAIL PROTECTED]> wrote:
> Dave Young wrote:
> > Add the following class iteration functions for driver use:
>
> Thanks Dave. I will check the ieee1394 part in detail later.
>
> ...
> > +/**
> > + * class_find_device - device iterator for locating a particular device
> > + * @class: the class we're iterating
> > + * @data: data for the match function
> > + * @match: function to check device
> > + *
> > + * This is similar to the class_for_each_dev() function above, but it
> > + * returns a reference to a device that is 'found' for later use, as
> > + * determined by the @match callback.
>
> Maybe add "Drop the reference with put_device() after use." for the
> really slow driver programmers like me?
Sounds good, thanks.
>
> > + *
> > + * The callback should return 0 if the device doesn't match and non-zero
> > + * if it does. If the callback returns non-zero, this function will
> > + * return to the caller and not iterate over any more devices.
> > + */
> > +struct device *class_find_device(struct class *class, void *data,
> > +int (*match)(struct device *, void *))
> > +{
>
> A general comment on the linux/device.h API (not a direct comment on
> your patch):
>
> The match argument in bus_find_device(), driver_find_device(),
> device_find_child(), class_find_device(), class_find_child() could be
> changed to
>
> bool (*match)(struct device *, void *)).
>
> Then the semantics are IMO a little bit clearer. Ditto for the
> dr_match_t type and the struct bus_type.match member.
Yes, from semantics side it's better.
But IMHO int is good as well, although it need a little bit more
understanding of the api.
>
> I don't know though whether the churn of doing such a change everywhere
> would be justified by the result.
>
>
> A comment on patch 2/7...6/7:
>
> You can bring most or all of the various __match implementations into a
> slightly terser but IMO easy to read form, like this:
>
> static int __match_ne(struct device *dev, void *data)
> {
> struct unit_directory *ud;
> struct node_entry *ne = (struct node_entry *)data;
>
> ud = container_of(dev, struct unit_directory, unit_dev);
> - if (ud->ne == ne)
> - return 1;
> - return 0;
> + return ud->ne == ne;
> }
>
> Here it is also easy to see that readability would improve if the return
> type was bool rather than int.
Ok, thanks.
> --
> Stefan Richter
> -=-==--- ---= -==--
> http://arcgraph.de/sr/
>
--
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: [CALL FOR TESTING] Make Ext3 fsck way faster [2.6.23.13]
On Sunday 13 January 2008 01:14, Michael Gerdau wrote: > This patch does not apply to a clean 2.6.23.13 tree using either of > patch -p1patch -p1 -l http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
In article <[EMAIL PROTECTED]> you wrote: > Just to clarify, I had about 60 days of uptime, and hence at least > 60 days since the last FS check/mount/etc., when Linux crashed those > few days ago, and wanted to start checking disks with "9192 days since > last file system check". This, however sounds like a typical "RTC has forgotten time" problem which is typical for some motherboards. 9192days is very close to 1984. I never see any coruption like that, but broken BIOS clocks quite often. Gruss Bernd -- 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] Default keyboard LEDs
In many cases, one prefers to have e.g. the NumLock on by default. In
many cases, one doesn't want to have it by default, e.g. on laptops.
Distributions actually have a very hard time trying to set this
correctly after the kernel boot, and that doesn't work for new consoles
that are created via the openvt(1) command anyway. This hence adds a
keyboard.default_leds boot parameter that permits to configure the
default keyboard LEDs.
Signed-off-by: Samuel Thibault <[EMAIL PROTECTED]>
---
Actually, what would be perfect would be to use the configuration that
the BIOS sets at boot by default. That is device-dependent, however.
--- linux/drivers/char/keyboard.c.orig 2008-01-14 00:26:12.0 +
+++ linux/drivers/char/keyboard.c 2008-01-14 00:33:03.0 +
@@ -67,6 +67,9 @@
#define KBD_DEFLOCK 0
+unsigned char default_leds = KBD_DEFLEDS;
+module_param(default_leds, byte, S_IRUGO | S_IWUSR);
+
void compute_shiftstate(void);
/*
@@ -1405,8 +1408,8 @@
int error;
for (i = 0; i < MAX_NR_CONSOLES; i++) {
- kbd_table[i].ledflagstate = KBD_DEFLEDS;
- kbd_table[i].default_ledflagstate = KBD_DEFLEDS;
+ kbd_table[i].ledflagstate = default_leds;
+ kbd_table[i].default_ledflagstate = default_leds;
kbd_table[i].ledmode = LED_SHOW_FLAGS;
kbd_table[i].lockstate = KBD_DEFLOCK;
kbd_table[i].slockstate = 0;
--- linux/include/linux/kbd_kern.h.orig 2008-01-14 00:32:36.0 +
+++ linux/include/linux/kbd_kern.h 2008-01-14 00:32:48.0 +
@@ -13,6 +13,7 @@
extern char func_buf[];
extern char *funcbufptr;
extern int funcbufsize, funcbufleft;
+extern unsigned char default_leds;
/*
* kbd->xxx contains the VC-local things (flag settings etc..)
--- linux/Documentation/kernel-parameters.txt.orig 2008-01-14
00:38:40.0 +
+++ linux/Documentation/kernel-parameters.txt 2008-01-14 00:41:21.0
+
@@ -550,6 +550,15 @@
Set system-wide default UTF-8 mode for all tty's.
Default is 0 and by setting to 1, it enables UTF-8
mode for all newly opened or allocated terminals.
+
+ keyboard.default_leds=
+ [KEYBOARD]
+ Format=
+ Mask of the leds to activate on consoles by default.
+ ScrollLock: 1
+ NumLock: 2
+ CapsLock: 4
+ KanaLock: 8
dhash_entries= [KNL]
Set number of hash buckets for dentry cache.
--
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 v2] Make PCI extended config space (MMCONFIG) a driver opt-in
On Sun, 13 Jan 2008 16:28:08 -0500 Tony Camuso <[EMAIL PROTECTED]> wrote: > Arjan van de Ven wrote: > > >> The PCI spec provides for conf1 as an architected solution. It's not > >> going away, and especially not in x86 land where Port IO is built-in > >> to the CPU. > > > > again sadly you're wrong. > > > > As someone gently pointed out to me, you are in a position to know this, > so I probably am wrong. I suspect Arjan is wrong. It might be some Intel agenda but I still see fairly new driver reference code that is hardcoding port accesses even when designed for Redmond products. Alan -- 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.22.15: kernel processes stuck in D state
On Sat, Jan 12, 2008 at 09:15:16AM +1100, CaT wrote: > On Fri, Jan 11, 2008 at 12:20:58PM +0100, Stefan Richter wrote: > > CaT wrote: > > > Not sure what other info to provide > > > > Is the bug present in 2.6.24-rc7? > > Can't rightly say. I didn't try it before because 2.6.23 fails to > compile under debian sarge. 2.6.24-rc7 did compile but it has failed to > come back up. Don't know why as the box is remote (though it wasn't in > use again yet due to the afore mentioned problems so this is merely an > annoyance). I'll find out more on Monday. Ok. Not sure why it didn't boot the first time (black screen) but it booted the second time. This time both CPUs got initialised and are in use, no kernel oops during init and no kernel processes stuck in D state. Should've tried .24 earlier but .23 failed to compile under sarge due to a buggy binutils so I figured .24 would too. -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby -- 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/2] [SERIAL] avoid stalling suspend if serial port won't drain
> > Is printk() enough for 'we've just lost your data' condition? Maybe we > > should abort suspend if we can't drain fifo? > > No way. Think about this from a users' perspective. No one wants suspend > to ram or hibernate functionality that works sometimes and not others. > They want it to work reliably so they don't have to worry about their > laptop overheating while they're getting on the bus or airplane. > Aborting isn't an option. Dumb question on the printk however - what if the port that is sticking is the console - don't we recurse and die ? -- 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: Lenovo ThinkPads need acpi_osi="Linux"
On Sun, Jan 13, 2008 at 09:41:29PM -0200, Henrique de Moraes Holschuh wrote: > On Sun, 13 Jan 2008, Pavel Machek wrote: > > When linux calls video BIOS with lcall (acpi_sleep=s3_bios), they > > should turn on backlight and put video into text mode. They should > > also make sure mode setting works after that. > > IMHO, in that case, we should probably be whitelist-enabling that on > thinkpads (and allow for acpi_sleep=none to override it), or letting > userspace change it at runtime. No. This breaks on the R50e, at least - I suspect it'd also have problems on any nvidia based machines, but I don't have one to hand at the moment. It can be set at runtime already. -- Matthew Garrett | [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: [PATCH: 2/2] [SERIAL] avoid stalling suspend if serial port won't drain
On Fri, Jan 11, 2008 at 10:17:21AM +, Pavel Machek wrote: > On Tue 2008-01-08 11:57:03, Russell King wrote: > > + if (!tries) > > + printk(KERN_ERR "%s%s%s%d: Unable to drain > > transmitter\n", > > + port->dev ? port->dev->bus_id : "", > > + port->dev ? ": " : "", > > + drv->dev_name, port->line); > > > > ops->shutdown(port); > > } > > > > Is printk() enough for 'we've just lost your data' condition? Maybe we > should abort suspend if we can't drain fifo? That would mean that a port set for hardware flow control, with hardware implemented flow control, has CTS deasserted, you'll never suspend. If you're suspending because your battery is almost dead what would you prefer - the system being prevented from suspending and losing complete power unexpectedly, resulting in complete data loss, or losing the characters in the serial port and suspending? Which is the lesser of two evils? -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- 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: [RFD] Incremental fsck
Hi Ted, On Saturday 12 January 2008 06:51, Theodore Tso wrote: > What is very hard to check is whether or not the link count on the > inode is correct. Suppose the link count is 1, but there are > actually two directory entries pointing at it. Now when someone > unlinks the file through one of the directory hard entries, the link > count will go to zero, and the blocks will start to get reused, even > though the inode is still accessible via another pathname. Oops. > Data Loss. > > This is why doing incremental, on-line fsck'ing is *hard*. You're > not going to find this while doing each directory one at a time, and > if the filesystem is changing out from under you, it gets worse. And > it's not just the hard link count. There is a similar issue with the > block allocation bitmap. Detecting the case where two files are > simultaneously can't be done if you are doing it incrementally, and > if the filesystem is changing out from under you, it's impossible, > unless you also have the filesystem telling you every single change > while it is happening, and you keep an insane amount of bookkeeping. In this case I am listening to Chicken Little carefully and really do believe the sky will fall if we fail to come up with an incremental online fsck some time in the next few years. I realize the challenge verges on insane, but I have been slowly chewing away at this question for some time. Val proposes to simplify the problem by restricting the scope of block pointers and hard links. Best of luck with that, the concept of fault isolation domains has a nice ring to it. I prefer to stick close to tried and true Ext3 and not change the basic algorithms. Rather than restricting pointers, I propose to add a small amount of new metadata to accelerate global checking. The idea is to be able to build per-group reverse maps very quickly, to support mapping physical blocks back to inodes that own them, and mapping inodes back to the directories that reference them. I see on-the-fly filesystem reverse mapping as useful for more than just online fsck. For example it would be nice to be able to work backwards efficiently from a list of changed blocks such as ddsnap produces to a list of file level changes. The amount of metadata required to support efficient on-the-fly reverse mapping is surprisingly small: 2K per block group per terabyte, in a fixed location at the base of each group. This is consistent with my goal of producing code that is mergable for Ext4 and backportable to Ext3. Building a block reverse map for a given group is easy and efficient. The first pass walks across the inode table and already maps most of the physical blocks for typical usage patterns, because most files only have direct pointers. Index blocks discovered in the first pass go onto a list to be processed by subsequent passes, which may discover additional index blocks. Just keep pushing the index blocks back onto the list and the algorithm terminates when the list is empty. This builds a reverse map for the group including references to external groups. Note that the recent metadata clustering patch from Abhishek Rai will speed up this group mapping algorithm significantly because (almost) all the index blocks can be picked up in one linear read. This should only take a few milliseconds. One more reason why I think his patch is an Important Patch[tm]. A data block may be up to four groups removed from its home group, therefore the reverse mapping process must follow pointers across groups and map each file entirely to be sure that all pointers to the group being checked have been discovered. It is possible to construct a case where a group contains a lot of inodes of big files that are mostly stored in other groups. Mapping such a group could possibly require examining all the index blocks on the entire volume. That would be about 2**18 index blocks per terabyte, which is still within the realm of practicality. To generate the inode reverse map for, walk each directory in the group, decoding the index blocks by hand. Strictly speaking, directories ought to pass block level checking before being reverse mapped, but there could be many directories in the same group spilling over into a lot of external groups, so getting all the directory inodes to pass block level checks at the same time could be difficult with filesystem writing going on between fsck episodes. Instead, just go ahead and assume a directory file is ok, and if this is not the case the directory walk will fail or a block level check will eventually pick up the problem. The worst case for directory mapping is much worse than the worst case for block mapping. A single directory could fill an entire volume. For such a large directory, reverse mapping is not possible without keeping the filesystem suspended for an unreasonable time. Either make the reverse map incremental and maintained on the fly
Re: Lenovo ThinkPads need acpi_osi="Linux"
A bit more on this issue. I have received a report that on a X61, it actually works the opposite from the T61 and you need acpi_osi="!Linux" to get the "mute" key to work. Well, I am asking the users to track down exactly *where* the mute key is comming from in each case (ACPI or keyboard controller). When I have the results, I will send an update to this thread. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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.24-rc7
J.A. Magallón wrote: > I'm still pending to pysically remove the disks (or at least unplug the > cable...), but I have realized a cusious thing: after some errors, the > kernel is lowering the disk speed (UDMA/133, then 100, then 33): That's the standard error handling behavior. Timeouts are likely to indicate transmission problems so libata puts it into slower gear. > Perhaps this gives a clue. > Or I just had bad luck and 2 of my 4 disks broke at the same time. As I said, the first thing I would try is to connect the drives to a separate PSU and re-seating cables as you're seeing problems on two drives simultaneously. -- 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/
Re: [PATCH 3/5] NLM: Have lockd call try_to_freeze
On Sunday, 13 of January 2008, Neil Brown wrote:
> On Sunday January 13, [EMAIL PROTECTED] wrote:
> > On Thu, 10 Jan 2008 13:01:34 -0500
> > Jeff Layton <[EMAIL PROTECTED]> wrote:
> >
> > > lockd makes itself freezable, but never calls try_to_freeze(). Have it
> > > call try_to_freeze() within the main loop.
> > >
> > > Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
> > > ---
> > > fs/lockd/svc.c |3 +++
> > > 1 files changed, 3 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
> > > index 82e2192..6ee8bed 100644
> > > --- a/fs/lockd/svc.c
> > > +++ b/fs/lockd/svc.c
> > > @@ -155,6 +155,9 @@ lockd(struct svc_rqst *rqstp)
> > > long timeout = MAX_SCHEDULE_TIMEOUT;
> > > char buf[RPC_MAX_ADDRBUFLEN];
> > >
> > > + if (try_to_freeze())
> > > + continue;
> > > +
> > > if (signalled()) {
> > > flush_signals(current);
> > > if (nlmsvc_ops) {
> >
> >
> > I was looking over svc_recv today and noticed that it calls
> > try_to_freeze a couple of times. Given that, the above patch may be
> > unnecessary. I don't think it hurts anything though. Should we keep
> > this patch or drop it?
>
> I would suggest dropping it.
> Having unnecessary code is likely to be confusing.
But adding a comment instead of it won't hurt, IMHO. :-)
Greetings,
Rafael
--
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: Lenovo ThinkPads need acpi_osi="Linux"
On Sun, 13 Jan 2008, Pavel Machek wrote: > > The reason it shoudl be turned off is that backlight enabling > > backlight from a native graphics driver is much faster than running > > through the video BIOS POST. So if we keep the OSI(Linux) > > video BIOS POST workaround in place permanently, it would > > put Linux at a permanent performance disadvantage to Windows. > > Hmm, they should not need to do anything. > > When linux calls video BIOS with lcall (acpi_sleep=s3_bios), they > should turn on backlight and put video into text mode. They should > also make sure mode setting works after that. IMHO, in that case, we should probably be whitelist-enabling that on thinkpads (and allow for acpi_sleep=none to override it), or letting userspace change it at runtime. > I don't see how ACPI fits into this picture, and I think it can work > well without ACPI tricks. It fits because Lenovo did it in ACPI (or used to do it in ACPI, whatever). We can ask them to not do it, I suppose. But without some sort of autodetection on our part, I doubt they will remove it. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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] leds: Add support for the 3rd LED on the PCEngines WRAP
On Thu, 2007-12-27 at 14:31 +0100, Michael Loeffler wrote: > The 3rd LED on this board is something like a power-led, it is on all the > time. With this change to the leds-wrap driver it is possible to use this > LED too. > > Signed-off-by: Michael Loeffler <[EMAIL PROTECTED]> > --- > Hi > > I wonder why there was no support for this LED. This LED and the GPIO > line is documented in the first commit message (0d75565f) for this > file. > > I use this changed version for five weeks and it just works. I think > this patch can be included in 2.6.25. I've queued it up in the LED tree, thanks. Richard -- 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.24-rc7
On Thu, 10 Jan 2008 22:10:08 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
> Hi,
>
> J.A. Magallón wrote:
> > It reproduces also with 2.6.23.13.
> > Finally I think the problematic disk is sdc:
>
> Okay, then, it's less likely a regression and more likely a newly
> developed hardware problem.
>
> > ICH5 PATA -> sda
> > ICH5 SATA0 -> sdb
> > ICH5 SATA1 -> sdc
> > Promise SATA -> sdd
> >
> > The problem is that even I have commented out the entry for sdc in fstab,
> > the system is still giving me errors. An my guess is that errors in sdc
> > makes
> > the ICH5 sata controller go nuts, and then I get errors also in sdb.
> > Just a couple questions...
>
> I've never seen ICHs or any other SATA controllers act that way.
>
> > - Can I say to ata_piix something like 'please, detect first SATA ports
> > before
> > ATA', so my system disk (sdb) becomes sda ?
>
> You do that using LABEL, UUID or device ID. Just run 'ls -l
> /dev/disk/by-*/' and see the result.
>
> > - Can I say 'plz, ignore port 1', so it does not try to detect/start/spin
> > sdc ?
> > So I ban be sure it is the one to blame, before start to remove
> > hardware...
>
> Unfortunately not but you can boot into single mode where there's
> nothing trying to access the disk without your explicit command and
> verify access to each hard disk.
>
> Hmm... You are seeing timeouts from multiple harddisks. The first thing
> I would try is to reseat the cables and connect the SATA hard drives to
> a separate power supply and see whether that changes anything.
>
I'm still pending to pysically remove the disks (or at least unplug the
cable...), but I have realized a cusious thing: after some errors, the
kernel is lowering the disk speed (UDMA/133, then 100, then 33):
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd c8/00:08:07:81:3f/00:00:00:00:00/e0 tag 0 dma 4096 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/133
ata3: EH complete
...
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd c8/00:48:05:73:33/00:00:00:00:00/ef tag 0 dma 36864 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/133
ata3: EH complete
...
(one more 133)
...
ata3.00: limiting speed to UDMA/100:PIO4
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd c8/00:40:8d:9c:84/00:00:00:00:00/eb tag 0 dma 32768 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/100
...
(3 more 100)
...
ata3.00: limiting speed to UDMA/33:PIO4
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd ca/00:08:9f:00:1a/00:00:00:00:00/e2 tag 0 dma 4096 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33
...
Perhaps this gives a clue.
Or I just had bad luck and 2 of my 4 disks broke at the same time.
--
J.A. Magallon \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT
--
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: The ext3 way of journalling
On Mon, Jan 14, 2008 at 12:23:10AM +0200, Tuomo Valkonen wrote: > On 2008-01-14 00:13 +0200, Tuomo Valkonen wrote: > > Also, I must say that e2fsck is brain-damaged, if it can be confused > > by/do the stupid then when the system clock has warped by just a few > > hours, not the _days_ that a file system check interval typically is, > > and users need to specifically kludge around such misbehaviour in > > e2fsck. > > Just to clarify, I had about 60 days of uptime, and hence at least > 60 days since the last FS check/mount/etc., when Linux crashed those > few days ago, and wanted to start checking disks with "9192 days since > last file system check". Well, let's see. 9192 days is a little over 25 years, so that means the filesystem was marked as having done an fsck in 2008-25 or roughly 1983. If you're not seeing any other corruption when e2fsck runs, it's highly unlikely that the superblock is getting corrupted. It's much more likely that this early in your boot cycle, your clock is sometimes incorrect. My suggestion to you is to rig your init scripts to print out the the current time/date using "/bin/date" and to print out the superblock information using "dumpe2fs -h /dev/hdXX" and record the information someplace useful. A simple way to do this would be via the following command inserted into /etc/init.d/checkroot.sh: (date; /sbin/dumpe2fs -h /dev/XXX) | logsave -a /var/log/boot-debug - where you've replaced /dev/XXX with the block device of the filesystem which keeps on getting checked erroneously. All I can say is that most people aren't see what you're seeing, so there is something unique about your system which is causing this problem to show up. 9192 days means it's not the time going backwards scenario; somehow the last checked value is getting set to some very bogus value. Normally the only way this could happen is for the time to be set to a bogus value (i.e., 1982) when the filesystem check takes place. Is the "9192" number roughly constant, or is it always changing? I wonder if the battery-backed hardware clock in your system is busted, and so you're always starting the system with some completely bogus time. If your machine is on the network, then the "ntpdate" program could be setting your time so that it looks correct, but that's after e2fsck is run. If you really, really, can't guarantee that the time on your system is correct in early boot, about the only thing you really *can* do is to use the command "tune2fs -i 0 /dev/XXX" and disable time-based checks altogether. Regards and best of luck, - Ted -- 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] driver: ip27-rtc - convert ioctl to unlocked_ioctl
On Sunday 13 January 2008 21:32:23 Cyrill Gorcunov wrote: > This patch converts ioctl call to unlocked_ioctl form with > explicit big-kernel-lock. > Also it makes a bit of cleanup > converting miscdevice structure initialization to C99 form. First please always send cleanup patches separately. I think you have more than just the C99 conversion. Were you even able to compile it? Since ip27 is ia64 only that would need an IA64 cross compiler or a native ia64 machine. It's probably better to focus on drivers only that actually build on x86 :- see http://www.halobates.de/allyes for a compile log showing all buildable files for x86-64 and i386. Other than that the patch looks ok to me, but I haven't tried to compile it either. -Andi -- 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/2] [SERIAL] avoid stalling suspend if serial port won't drain
On Fri, 2008-01-11 at 10:17 +, Pavel Machek wrote: > Is printk() enough for 'we've just lost your data' condition? Maybe we > should abort suspend if we can't drain fifo? YUCK ! 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: 2.6.24-rc7-rt1
On Jan 13, 2008 11:00 AM, Steven Rostedt <[EMAIL PROTECTED]> wrote: > We are pleased to announce the 2.6.24-rc7-rt1 tree, which can be > downloaded from the location: > > http://rt.et.redhat.com/download/ > Up and running here. No significant testing but no problems building it and no obvious regressions from 2.6.24-rc2-rt1. [EMAIL PROTECTED] ~ $ uname -a Linux lightning 2.6.24-rc7-rt1 #1 PREEMPT RT Sun Jan 13 14:41:21 PST 2008 x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux [EMAIL PROTECTED] ~ $ - Mark -- 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: CONFIG_NO_HZ breaks blktrace timestamps
Hi. Ingo Molnar wrote: > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Just out of curiosity, could you try the appended cumulative patch > and report .clock_warps, .clock_overflows and .clock_underflows as > you did. With those patches, CONFIG_NO_HZ works just fine. >> Could these patches also help with hibernation issues? I'm trying >> x86_64+NO_HZ, and seeing activity delayed during the atomic copy and >> afterwards until I manually generate interrupts (by pressing keys). > > i dont think that should be related to cpu_clock() use. Does the patch > below make any difference? (or could you try x86.git to get the whole > stack of x86 changes that we have at the moment.) Here's the coordinates > for x86.git: Sorry for the delay in replying. Something seems to help, but I haven't managed to identify what yet. I don't think it was the patch appended because I'm on UP. If you care, I'll see if I can find the time to look more carefully. Nigel -- 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 device reset, shoud I be concerned?
Hello, During heavy disk load on my laptop, sometimes the IDE disk will pause for a second and then continue. I get this in my kernel log: [ 9031.028000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen [ 9031.028000] ata1.00: cmd c8/00:08:90:ca:ce/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in [ 9031.028000] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 9036.068000] ata1: port is slow to respond, please be patient (Status 0xd0) [ 9041.052000] ata1: device not ready (errno=-16), forcing hardreset [ 9041.052000] ata1: soft resetting port [ 9041.232000] ata1.00: configured for UDMA/100 [ 9041.232000] ata1: EH complete [ 9041.248000] sd 0:0:0:0: [sda] 78140160 512-byte hardware sectors (40008 MB) [ 9041.248000] sd 0:0:0:0: [sda] Write Protect is off [ 9041.248000] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 9041.248000] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA My question: What is this telling me, and do I need to be concerned? Everything continues to work normally after the message: no I/O errors, no fsck errors, etc. I've seen some similar reports on the mailing list, but they include slightly different messages. I would appreciate any information! uname -a (on Kubuntu Gutsy, CPU is a single-core 32-bit Pentium M): Linux superfly 2.6.22-14-386 #1 Tue Dec 18 07:34:24 UTC 2007 i686 GNU/Linux lspci: 00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 03) 00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81) 00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01) 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) 01:00.0 VGA compatible controller: nVidia Corporation NV28 [GeForce4 Ti 4200 Go AGP 8x] (rev a1) 02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5705M Gigabit Ethernet (rev 01) 02:01.0 CardBus bridge: Texas Instruments PCI7510 PC card Cardbus Controller (rev 01) 02:01.2 FireWire (IEEE 1394): Texas Instruments PCI7410,7510,7610 OHCI-Lynx Controller 02:01.3 System peripheral: Texas Instruments PCI7410,7510,7610 PCI Firmware Loading Function 02:03.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01) Thanks! -- 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/2] [SERIAL] avoid stalling suspend if serial port won't drain
Hi.
Pavel Machek wrote:
> On Tue 2008-01-08 11:57:03, Russell King wrote:
>> Some ports seem to be unable to drain their transmitters on shut down.
>> Such a problem can occur if the port is programmed for hardware imposed
>> flow control, characters are in the FIFO but the CTS signal is inactive.
>>
>> Normally, this isn't a problem because most places where we wait for the
>> transmitter to drain have a time-out. However, there is no timeout in
>> the suspend path.
>>
>> Give a port 30ms to drain; this is an arbitary value chosen to avoid
>> long delays if there are many such ports in the system, while giving a
>> reasonable chance for a single port to drain. Should a port not drain
>> within this timeout, issue a warning.
>>
>> Signed-off-by: Russell King <[EMAIL PROTECTED]>
>>
>> diff --git a/drivers/serial/serial_core.c b/drivers/serial/serial_core.c
>> index 3bb5d24..4ce219c 100644
>> --- a/drivers/serial/serial_core.c
>> +++ b/drivers/serial/serial_core.c
>> @@ -1977,6 +1977,7 @@ int uart_suspend_port(struct uart_driver *drv, struct
>> uart_port *port)
>>
>> if (state->info && state->info->flags & UIF_INITIALIZED) {
>> const struct uart_ops *ops = port->ops;
>> +int tries;
>>
>> state->info->flags = (state->info->flags & ~UIF_INITIALIZED)
>> | UIF_SUSPENDED;
>> @@ -1990,9 +1991,14 @@ int uart_suspend_port(struct uart_driver *drv, struct
>> uart_port *port)
>> /*
>> * Wait for the transmitter to empty.
>> */
>> -while (!ops->tx_empty(port)) {
>> +for (tries = 3; !ops->tx_empty(port) && tries; tries--) {
>> msleep(10);
>> }
>> +if (!tries)
>> +printk(KERN_ERR "%s%s%s%d: Unable to drain
>> transmitter\n",
>> + port->dev ? port->dev->bus_id : "",
>> + port->dev ? ": " : "",
>> + drv->dev_name, port->line);
>>
>> ops->shutdown(port);
>> }
>>
>
> Is printk() enough for 'we've just lost your data' condition? Maybe we
> should abort suspend if we can't drain fifo?
No way. Think about this from a users' perspective. No one wants suspend
to ram or hibernate functionality that works sometimes and not others.
They want it to work reliably so they don't have to worry about their
laptop overheating while they're getting on the bus or airplane.
Aborting isn't an option.
Regards,
Nigel
--
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] [MEMSTICK] Initial commit for Sony MemoryStick support
This happens when trying to compile memory stick support inside the kernel.
drivers/memstick/core/mspro_block.o: In function `memstick_priv':
mspro_block.c:(.text+0x0): multiple definition of `memstick_priv'
drivers/memstick/core/memstick.o:memstick.c:(.text+0x0): first defined here
drivers/memstick/core/mspro_block.o: In function `memstick_get_drvdata':
mspro_block.c:(.text+0x6): multiple definition of `memstick_get_drvdata'
drivers/memstick/core/memstick.o:memstick.c:(.text+0x6): first defined here
drivers/memstick/core/mspro_block.o: In function `memstick_set_drvdata':
mspro_block.c:(.text+0xd): multiple definition of `memstick_set_drvdata'
drivers/memstick/core/memstick.o:memstick.c:(.text+0xd): first defined here
This is because those three functions are not defined as static in
"include/linux/memstick.h".
Signed-off-by: Miguel Botón <[EMAIL PROTECTED]>
diff --git a/include/linux/memstick.h b/include/linux/memstick.h
index dc5ac9d..53a8741 100644
--- a/include/linux/memstick.h
+++ b/include/linux/memstick.h
@@ -271,17 +271,17 @@ void memstick_new_req(struct memstick_host *host);
int memstick_set_rw_addr(struct memstick_dev *card);
-inline void *memstick_priv(struct memstick_host *host)
+static inline void *memstick_priv(struct memstick_host *host)
{
return (void *)host->private;
}
-inline void *memstick_get_drvdata(struct memstick_dev *card)
+static inline void *memstick_get_drvdata(struct memstick_dev *card)
{
return dev_get_drvdata(>dev);
}
-inline void memstick_set_drvdata(struct memstick_dev *card, void *data)
+static inline void memstick_set_drvdata(struct memstick_dev *card, void *data)
{
dev_set_drvdata(>dev, data);
}
---
Miguel Botón
--
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/
checkpatch: add filename before the summary line
With the patch applied the output of checkpatch.pl is as follow:
./arch/arm/mach-footbridge/ebsa285-pci.c
total: 1 errors, 0 warnings, 48 lines checked
Adding the file name allowed me to collects stats running:
find . -name *.c |xargs ./scripts/checkpatch.pl --file |grep -B 1 total
but I though it might me useful for other purposes to add the file name
after the list of errors and warnings and before the summary,
when the list is long I find handy to print out the filename as a reminder.
Signed-off-by: Paolo Ciarrocchi <[EMAIL PROTECTED]>
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 579f50f..079c73c 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1580,6 +1580,7 @@ sub process {
print report_dump();
if ($summary) {
+ print "$filename \n";
print "total: $cnt_error errors, $cnt_warn warnings, " .
(($check)? "$cnt_chk checks, " : "") .
"$cnt_lines lines checked\n";
--
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] NLM: Have lockd call try_to_freeze
On Sunday January 13, [EMAIL PROTECTED] wrote:
> On Thu, 10 Jan 2008 13:01:34 -0500
> Jeff Layton <[EMAIL PROTECTED]> wrote:
>
> > lockd makes itself freezable, but never calls try_to_freeze(). Have it
> > call try_to_freeze() within the main loop.
> >
> > Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
> > ---
> > fs/lockd/svc.c |3 +++
> > 1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
> > index 82e2192..6ee8bed 100644
> > --- a/fs/lockd/svc.c
> > +++ b/fs/lockd/svc.c
> > @@ -155,6 +155,9 @@ lockd(struct svc_rqst *rqstp)
> > long timeout = MAX_SCHEDULE_TIMEOUT;
> > char buf[RPC_MAX_ADDRBUFLEN];
> >
> > + if (try_to_freeze())
> > + continue;
> > +
> > if (signalled()) {
> > flush_signals(current);
> > if (nlmsvc_ops) {
>
>
> I was looking over svc_recv today and noticed that it calls
> try_to_freeze a couple of times. Given that, the above patch may be
> unnecessary. I don't think it hurts anything though. Should we keep
> this patch or drop it?
I would suggest dropping it.
Having unnecessary code is likely to be confusing.
NeilBrown
--
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: The ext3 way of journalling
On 2008-01-14 00:13 +0200, Tuomo Valkonen wrote: > Also, I must say that e2fsck is brain-damaged, if it can be confused > by/do the stupid then when the system clock has warped by just a few > hours, not the _days_ that a file system check interval typically is, > and users need to specifically kludge around such misbehaviour in > e2fsck. Just to clarify, I had about 60 days of uptime, and hence at least 60 days since the last FS check/mount/etc., when Linux crashed those few days ago, and wanted to start checking disks with "9192 days since last file system check". -- Tuomo -- 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: The ext3 way of journalling
On 2008-01-12 10:06 -0500, Theodore Tso wrote: > So running the "date" command after the boot sequence is completely > finished. That doesn't mean that system clock was correct at the time > when fsck is run. Unless ntpd has managed to change it by that time, it was correct, in the local time zone. But judging from the "too big difference, refusing to correct" behaviour of ntpd while the system is up, I doubt ntpd would correct the time at boot, if it were considerably wrong. This rapidly advancing system clock is A COMPLETELY DIFFERENT PROBLEM that started with switch from 2.6.7 to 2.6.14. Before that it worked just fine. > Unfortunately Ubuntu users in Europe fit this > demographic hugely, and Ubuntu refuses to fix this problem[1], so it's > been personally very vexing, because the users complain to *me*, and I > can't fix the problem, because it's a distribution init script issue. FYI, I'm not running Ubuntu. This system once used to by Debian, but since Etch is already obsolete wrt. many non-base software, and I'm not going to suffer stable/unstable anymore, and megafrozen megadistros with everything between the earth and skies suck anyway, largely consists of self-installed software by now. Maybe they broke time initialisations for etch. Also, I must say that e2fsck is brain-damaged, if it can be confused by/do the stupid then when the system clock has warped by just a few hours, not the _days_ that a file system check interval typically is, and users need to specifically kludge around such misbehaviour in e2fsck. -- Tuomo -- 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] serial: remove "too much work for irq" printk
On Sat 2008-01-12 21:24:57, Alan Cox wrote: > On Sat, 12 Jan 2008 15:15:43 -0500 > Benjamin LaHaise <[EMAIL PROTECTED]> wrote: > > > When using kvm with a serial console, the serial driver will print out > > "too much work for irq4" on any heavy activity (ie vi on a file repainting > > the terminal). This message is entirely spurious, as output continues to > > work fine. Remove the message as it corrupts screen output and is far too > > easy to trigger. > > NAK. This is a qemu/kvm emulation bug. The real check is there to catched > jammed IRQs and combined with the IRQ bug handling nowdays does actually > do the intended job. > > Our serial port code (correctly) interprets a continuous stream of bytes > at an impossible bit rate as an error. KVM should be emulating to some > extent at least the timing on serial interfaces or using a virtualised > interface. How can you tell apart impossible bit rate from really slow CPU, or maybe just an SMI storm, or heavy busmaster DMA? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
[EMAIL PROTECTED] wrote:
>
> Any ideas?
Please provide a packet dump on both sides (or at least the sender
side).
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.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: [PATCH 0/4] __cpuinitconst and __devinitconst
> And I found another small buglet too. I hope to post a complete
> solution later today.
The modpost bits turned out to take longer than expected so
they are not done yet. The problem was the modpost structure
were not prepared for adding such additional chacks.
So I reworked those bits and the patch has been sent out for review.
What follows here is the changes for init.h + all linker scripts
to show the idea.
Next step is to beat modpost in shape and to post this on linux-arch.
Note - in -mm there are changes to init.h so the logic
to decide type of __meminit notation is much simpler.
Sam
arch/alpha/kernel/vmlinux.lds.S |8 +--
arch/arm/kernel/vmlinux.lds.S | 10 ++--
arch/avr32/kernel/vmlinux.lds.S |8 +--
arch/blackfin/kernel/vmlinux.lds.S |8 +--
arch/cris/arch-v10/vmlinux.lds.S|8 +--
arch/cris/arch-v32/vmlinux.lds.S|8 +--
arch/frv/kernel/vmlinux.lds.S | 14 +++---
arch/h8300/kernel/vmlinux.lds.S |8 +--
arch/ia64/kernel/vmlinux.lds.S |8 +--
arch/m32r/kernel/vmlinux.lds.S | 12 ++---
arch/m68k/kernel/vmlinux-std.lds|8 +--
arch/m68k/kernel/vmlinux-sun3.lds |8 +--
arch/m68knommu/kernel/vmlinux.lds.S |8 +--
arch/mips/kernel/vmlinux.lds.S |8 +--
arch/parisc/kernel/vmlinux.lds.S|8 +--
arch/powerpc/kernel/vmlinux.lds.S | 10 ++--
arch/ppc/kernel/vmlinux.lds.S |8 +--
arch/s390/kernel/vmlinux.lds.S |8 +--
arch/sh/kernel/vmlinux.lds.S|8 +--
arch/sh64/kernel/vmlinux.lds.S |8 +--
arch/sparc/kernel/vmlinux.lds.S |8 +--
arch/sparc64/kernel/vmlinux.lds.S |8 +--
arch/um/kernel/dyn.lds.S|4 -
arch/um/kernel/uml.lds.S|4 -
arch/v850/kernel/vmlinux.lds.S | 10 ++--
arch/x86/kernel/vmlinux_32.lds.S| 14 --
arch/x86/kernel/vmlinux_64.lds.S| 19 ++--
arch/xtensa/kernel/vmlinux.lds.S|9 ++--
include/asm-generic/vmlinux.lds.h | 77 +++-
include/linux/init.h| 56 +-
30 files changed, 229 insertions(+), 154 deletions(-)
diff --git a/arch/alpha/kernel/vmlinux.lds.S b/arch/alpha/kernel/vmlinux.lds.S
index 55c05b5..f13249b 100644
--- a/arch/alpha/kernel/vmlinux.lds.S
+++ b/arch/alpha/kernel/vmlinux.lds.S
@@ -46,11 +46,11 @@ SECTIONS
__init_begin = .;
.init.text : {
_sinittext = .;
- *(.init.text)
+ INIT_TEXT
_einittext = .;
}
.init.data : {
- *(.init.data)
+ INIT_DATA
}
. = ALIGN(16);
@@ -136,8 +136,8 @@ SECTIONS
/* Sections to be discarded */
/DISCARD/ : {
- *(.exit.text)
- *(.exit.data)
+ EXIT_TEXT
+ EXIT_DATA
*(.exitcall.exit)
}
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 5ff5406..52221ef 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -30,7 +30,7 @@ SECTIONS
}
.init : { /* Init code and data */
- *(.init.text)
+ INIT_TEXT
_einittext = .;
__proc_info_begin = .;
*(.proc.info.init)
@@ -70,15 +70,15 @@ SECTIONS
__per_cpu_end = .;
#ifndef CONFIG_XIP_KERNEL
__init_begin = _stext;
- *(.init.data)
+ INIT_DATA
. = ALIGN(4096);
__init_end = .;
#endif
}
/DISCARD/ : { /* Exit code and data */
- *(.exit.text)
- *(.exit.data)
+ EXIT_TEXT
+ EXIT_DATA
*(.exitcall.exit)
#ifndef CONFIG_MMU
*(.fixup)
@@ -129,7 +129,7 @@ SECTIONS
#ifdef CONFIG_XIP_KERNEL
. = ALIGN(4096);
__init_begin = .;
- *(.init.data)
+ INIT_DATA
. = ALIGN(4096);
__init_end = .;
#endif
diff --git a/arch/avr32/kernel/vmlinux.lds.S b/arch/avr32/kernel/vmlinux.lds.S
index 11f08e3..481cfd4 100644
--- a/arch/avr32/kernel/vmlinux.lds.S
+++ b/arch/avr32/kernel/vmlinux.lds.S
@@ -27,19 +27,19 @@ SECTIONS
__init_begin = .;
_sinittext = .;
*(.text.reset)
- *(.init.text)
+ INIT_TEXT
/*
* .exit.text is discarded at runtime, not
* link time, to deal with references from
* __bug_table
*/
- *(.exit.text)
+ EXIT_TEXT
_einittext = .;
. = ALIGN(4);
[PATCH] kbuild: simplify section mismatch check in modpost
In another thread I mentioned the idea to introduce additional
sections for all the __init markers.
Introducing checks for all the new combinations in modpost
turned out to be difficult so I decided to clean up
what we have today by introducing a table based approach.
The patch below is the result of this effort.
I have pushed out kbuild.git with this change so grab it there
if you like to play with it.
Comments are welcome.
The pattern_cmp() includes support for "*foo*" but that is not
yet used. I know it has a memory leak...
If someone has a better implmentation that does not pull
in any regexp library let me know.
Sam
>From 94fb89c040d3a8557b00f042a05901f362bf4c1c Mon Sep 17 00:00:00 2001
From: Sam Ravnborg <[EMAIL PROTECTED]>
Date: Sun, 13 Jan 2008 22:21:31 +0100
Subject: [PATCH] kbuild: simplify section mismatch check in modpost
Change the logic in modpost so we identify all the
bad combinations of sections that refer to other
sections.
Compared to the previous approach we are much less
dependent on knowledge of what additional sections
the tool chain uses and thus we can keep the false
positives low.
The implmentation is changed to use a table based
lookup and we now check all combinations in first
pass so we no longer need separate passed for init
and exit sections.
Tested that the same warnings are generated for
a allyesconfig build without CONFIG_HOTPLUG.
Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
Cc: Randy Dunlap <[EMAIL PROTECTED]>
Cc: Adrian Bunk <[EMAIL PROTECTED]>
---
scripts/mod/modpost.c | 292 +++--
1 files changed, 137 insertions(+), 155 deletions(-)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 696d2a5..4521eef 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -606,6 +606,138 @@ static int strrcmp(const char *s, const char *sub)
}
/*
+ * Simple pattern matching.
+ * If sym matches one of the patterns then return 1 - otherwise 0.
+ * The patterns most be terminated with a NULL.
+ * Simple wildcard functionality is implemented.
+ * A '*' may be used as wildcard in start and/or end of string
+ * to match anything.
+ */
+static int pattern_cmp(const char *sym, const char * const pat[])
+{
+ const char *p;
+ while (*pat) {
+ p = *pat++;
+ const char *endp = p + strlen(p) - 1;
+
+ /* "*foo" */
+ if (*p == '*') {
+ if (strrcmp(sym, p + 1) == 0)
+ return 1;
+ }
+ /* "foo*" */
+ else if (*endp == '*') {
+ if (strncmp(sym, p, strlen(p) - 1) == 0)
+ return 1;
+ }
+ /* "*foo*" */
+ else if ((*p == '*') && (*endp == '*')) {
+ char *str = strdup(p + 1);
+ int len = strlen(str);
+ if (len)
+ *(str + len - 1) = '\0';
+ if (strstr(sym, str))
+ return 1;
+ }
+ /* no wildcards */
+ else {
+ if (strcmp(p, sym) == 0)
+ return 1;
+ }
+ }
+ /* no match */
+ return 0;
+}
+
+
+struct sectioncheck {
+ const char *fromsec[10];
+ const char *tosec[10];
+};
+
+const struct sectioncheck sectioncheck[] = {
+/* Do not reference init/exit code/data from
+ * normal code and data
+ */
+{
+ .fromsec = {
+ ".text",
+ ".text.*",
+ ".data",
+ ".data.*",
+ NULL
+ },
+ .tosec = {
+ "*init.text",
+ "*init.data",
+ "*exit.text",
+ "*exit.data",
+ NULL
+ },
+},
+/* Do not use exit code/data from init code */
+{
+ .fromsec = {
+ ".init.text",
+ ".init.data",
+ NULL
+ },
+ .tosec = {
+ ".exit.text",
+ ".exit.data",
+ NULL
+ },
+},
+/* Do not use init code/data from exit code */
+{
+ .fromsec = {
+ ".exit.text",
+ ".exit.data",
+ NULL
+ },
+ .tosec = {
+ ".init.text",
+ ".init.data",
+ NULL
+ },
+},
+/* Do not export init/exit functions or data */
+{
+ .fromsec = {
+ "__ksymtab*",
+ NULL
+ },
+ .tosec = {
+ ".init.*",
+ ".exit*",
+ NULL
+ },
+}
+};
+
+/*
+ * Check if the reference fromsec => tosec is a potential
+ * candidate for a section mismatch.
+ * Find only the combinations we know are candidates and ignore
+ * the others.
+ * Returns 1 if we have found a potential section mismatch reference.
+ */
+static int
Re: [PATCH] driver: ip27-rtc - convert ioctl to unlocked_ioctl
Thanks Jiri. Will do that all tomorrow. -- 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 v2] Make PCI extended config space (MMCONFIG) a driver opt-in
Arjan van de Ven wrote: The PCI spec provides for conf1 as an architected solution. It's not going away, and especially not in x86 land where Port IO is built-in to the CPU. again sadly you're wrong. As someone gently pointed out to me, you are in a position to know this, so I probably am wrong. -- 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/
