* Re: PROBLEM: Booting Kernel 2.6.15 let the machine freeze completely
From: Jason Brian Friedrich @ 2006-03-10 17:09 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: linux-kernel
In-Reply-To: <20060310003213.GA7789@mipter.zuzino.mipt.ru>
Alexey Dobriyan wrote:
> Brave Fedora users comment more:
I do not know what you exactly mean with this phrase, but it sounds a
bit odd. This is a problem just related to Fedora. After i read the
comments you posted (thanks for that), i assume that it is also related
to Ubuntu, Gentoo, OpenSuSE and any other distribution using 2.6.15 as
default kernel for the installation.
Or did i misunderstand you in this point?
> [Comments from users describing the same problem]
> -----------------------------------------------------------------------
> Try these boot options at startup:
> noapic acpi=off nofb
> -----------------------------------------------------------------------
> It Worked!
> -----------------------------------------------------------------------
Nope. I added the option 'nofb' to the parameters i already mentioned in
my last message. But the problem still exists, no change so far.
Regards,
Jason
^ permalink raw reply
* Re: Query MLS info outside of SELinux/LSM?
From: Stephen Smalley @ 2006-03-10 17:11 UTC (permalink / raw)
To: Paul Moore; +Cc: SELinux List
In-Reply-To: <4411AFCB.60401@hp.com>
On Fri, 2006-03-10 at 11:56 -0500, Paul Moore wrote:
> Is there a way to query the number of MLS sensitivity levels and
> categories outside of the SELinux LSM? I haven't seen anything, but
> thought I would ask before I started looking at alternatives ... which
> brings me to my next question - would anyone have an objection to adding
> this functionality?
The goal is to keep information about the specific security models
encapsulated in the security server (security/selinux/ss/*.c). The rest
of the SELinux code then remains policy-independent, as does the rest of
the kernel.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: Fix race in the accessed/dirty bit handlers
From: Zoltan Menyhart @ 2006-03-10 17:11 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <Pine.LNX.4.64.0603071901420.2463@schroedinger.engr.sgi.com>
Luck, Tony wrote:
>> itc.d r25
>> ;;
>> srlz.d
>> ld8 r18 = [r17]
>
> But it does not matter to the "ld8 r18 = [r17]" whether the "itc.d"
> is visible or not. r17 cannot be in the virtual address range that
> will be affected by the itc.d, so the serialization here would just
> slow things down, and have no effect at all.
I did say:
>> No, we are not going to use the freshly inserted translation for the next "ld". <<
Please consider the second issue I mentioned about the "itc":
Making sure that an external purge request will not be missed by our new
translation. See also on page 3:127:
"The visibility of the itc instruction to generated purges (ptc.g, ptc.ga) must occur before subsequent memory operations. From a software perspective, this is similar to acquire semantics. Serialization is still required to observe the side-effects of the translation being present."
How to tell if this "visibility of the itc instruction to generated purges"
has already been established?
I think a ";;" is not enough, this is why I propose this sequence:
itc.d r25
;;
srlz.d
ld8 r18 = [r17]
Thanks,
Zoltan
^ permalink raw reply
* Re: 2.6 device mapper performance?
From: Ming Zhang @ 2006-03-10 17:11 UTC (permalink / raw)
To: ken.hwang; +Cc: device-mapper development
In-Reply-To: <1142009962.20484.83.camel@localhost.localdomain>
On Fri, 2006-03-10 at 11:59 -0500, Ming Zhang wrote:
> u have too many chances here. so hard to blame any one. suggest u to
> test it one by one if possible.
sorry, typo. should be "too many changes"
>
> for example, have same box run 2.4 and 2.6, test performance on volume
> first before run xfs, and samba.
>
> ming
>
> On Wed, 2006-03-08 at 16:49 -0800, Ken Hwang wrote:
> > Hi,
> >
> > I'm not sure I should ask this question here, if this is not the place then
> > I apologize. I have a home made NAS with Linux. I use evms to create volume,
> > put xfs on top of it, and then use samba to share it with Windows clients.
> > When I was using kernel 2.4 with all the needed patches I could get netbench
> > 106Mbps with 4 clients, and 95Mbps with 8 clients. Recently I upgraded the
> > same hardware to kernel 2.6 (I also upgraded the related application such as
> > samba, xfs utility, and dmsetup accordingly). Then I ran netbench again and
> > got 80Mbps with 4 clients, 53Mbps with 8 clients. Which drop almost 80% (95
> > vs 53) in 8 clients case.
> >
> > I then make and mount xfs on another raid5 (which uses the same disk but on
> > different partitions) and found it got better performance (95Mbps with 4
> > clients, 85Mbps with 8 clients). In brief:
> > xfs volume on raid5 md/md1 on sda6/sdb6/sdc6/sdd6 netbench: 95/85Mbps
> > xfs volume on EVMS volume /dev/evms/volume1 on raid5 md/md3 on
> > sda8/sdb8/sdc8/sdd8: 80/53Mbps
> >
> > Do you think the slow down (85 to 53Mbps) was caused by device mapper?
> > Please advice.
> >
> > Ken
> >
> > --
> > No virus found in this outgoing message.
> > Checked by AVG Free Edition.
> > Version: 7.1.375 / Virus Database: 268.2.0/276 - Release Date: 3/7/2006
> >
> > --
> > dm-devel mailing list
> > dm-devel@redhat.com
> > https://www.redhat.com/mailman/listinfo/dm-devel
>
^ permalink raw reply
* Re: [PATCH] EDAC: core EDAC support code
From: Arjan van de Ven @ 2006-03-10 17:11 UTC (permalink / raw)
To: Doug Thompson; +Cc: tim, greg, bluesmoke-devel, dsp, linux-kernel
In-Reply-To: <44114D5702000036000014DE@zoot.lnxi.com>
> > and maybe even something as funky as firmware version.
> > So it for sure is a per device (not per ID) property, and something that
> > needs a global quirk table kind of thing with the option to do per
> > driver overrides
>
> Very definitely, this non-conforming misfeature of PCI compliance is a
> per PCI device attribute. At the very least it is tied to VENDOR:DEVICE
> tuple, and probably a subsystem vendor/device tuple as well. As to
> firmware, that is also likely. Mellanox promised a new firmware update
> to their board that supposely fixes this issue. Yet, I find no firmware
> value in the PCI spec, just the Revision ID, which could be used as
> firmware identifier. THis is up to the vendor.
exactly. So this is why a device driver needs to be able to override.
Eg for such device turn it off with a global quirk, and then let the
driver say "eh it's ok for THIS case"
> So in order to be sure I understand, if this PARITY Non-Conformance
> attribute was "moved" to the per device directory of sysfs
> (/sys/devices/pci0000:00/0000:00:06.0 for an example), then we would
> need a userland attribute file created here and then stored in the
> 'pci_dev' structure
yes. Well to some degree I'm not even sure it needs to be exposed to
userland like this. At least normally the kernel should know this
internally and automatically. (after all the kernel has the job to
abstract the hardware for the rest of the system; dealing with broken
hardware is part of that)
> or the mentioned quirk structure. This field then
> could be set by userland script(s), then EDAC-PCI could example that
> data in its iteration of pci devices. Is that correct?
that sounds way way way too complex. If this is "just" a field in the
pci device... why would userland need to get involved? Your kernel side
should be able to see that directly just fine.
> If the above is correct, then who would we need to contact for said
> modification or approval for such? Is that you Greg KH, since you are
> listed as the PCI SUBSYSTEM maintainer?
Greg needs to OK the addition to the pci struct, but I don't forsee a
problem personally since this is a more or less obvious and logical
thing to add, and useful for more than one architecture
^ permalink raw reply
* Re: [Patch 2/4] Basic reorder infrastructure - makes linking very slow
From: Andi Kleen @ 2006-03-10 9:45 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: sam, linux-kernel, torvalds, akpm
In-Reply-To: <1141060775.2992.149.camel@laptopd505.fenrus.org>
On Monday 27 February 2006 18:19, Arjan van de Ven wrote:
> On Mon, 2006-02-27 at 17:31 +0100, sam@ravnborg.org wrote:
> > > This patch puts the infrastructure in place to allow for a reordering of
> > > functions based inside the vmlinux.
> >
> > Can we make this general instead of x86_64 only?
> > Then we can use Kconfig to enable it for the architectures where we want it.
>
> Actually Linus had pretty good arguments to make this per-architecture:
> the list will be different on each architecture.
>
> (eg my first patch had it more generic; but Linus asked it to be per
> arch, and I agree with the reasons he gave)
>
> Also I doubt it can be enabled "blindly" for all architectures; I expect
> more to need hacks similar to the x86_64 entry.S fix before it can
> work...
Hi,
I just discovered that this patch is the reason why my compiles slowed
down so dramatically (thanks to Michael M. for the hint)
The SUSE 10.0 ld goes from running in seconds to more than a minute.
I think I will drop this patch for now because I doubt the
runtime improvement is worth the compile slowdown.
If there is some binutils release that handles this without dramatic
slowdown we can test for it in the Makefile, but i don't want it
to be enabled by default.
-Andi
^ permalink raw reply
* Re: Time went backwards
From: Keir Fraser @ 2006-03-10 17:14 UTC (permalink / raw)
To: Rik van Riel; +Cc: xen-devel
In-Reply-To: <Pine.LNX.4.63.0603101157290.23847@cuia.boston.redhat.com>
On 10 Mar 2006, at 17:00, Rik van Riel wrote:
> I am very frequently seeing these Time went backwards messages
> on my test systems. Running a 2 VCPU guest on a single CPU
> computer seems to be effective at triggering this ;)
That's interesting, particularly if you can trigger on a single
physical CPU. In that case cpu_delta should definitely *never* be
negative. Maybe the steal_time logic, which does mess with per-cpu
processed_system_time, is not quite right? :-)
When did you start seeing the messages?
-- Keir
^ permalink raw reply
* [PATCH] pidhash: Refactor the pid hash table.
From: Eric W. Biederman @ 2006-03-10 17:14 UTC (permalink / raw)
To: Andrew Morton; +Cc: Oleg Nesterov, linux-kernel
This splits the current struct pid into two structures, struct pid and struct
pid_link, and reduces our number of hash tables from PIDTYPE_MAX to just one.
struct pid_link is the per process linkage into the hash tables and lives in
struct task_struct. struct pid is given an indepedent lifetime, and holds
pointers to each of the pid types.
The independent life of struct pid simplifies attach_pid, and detach_pid,
because we are always manipulating the list of pids and not the hash table.
In addition in giving struct pid an indpendent life it makes the concept
much more powerful.
Kernel data structurs can now embed a struct pid * instead of a pid_t and
not suffer from pid wrap around problems or from keeping unnecessarily
large amounts of memory allocated.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
Andrew this patch is largely indepedent of previous work
but it does have a couple of dependencies.
Oleg's pids-kill-pidtype_tgid, pidhash-dont-count-idle-threads
My make-setsid-more-robust, and kill-switch_exec_pids
This patch conflicts with and obsoletes:
tref-fix-task_ref-reference-counting-ensure-the-references-is-always-on-the-first-task
tref-fix-task_ref-reference-counting-fix
tref-fix-task_ref-reference-counting
tref-implement-task-references-kill-init_tref
tref-implement-task-references
Sorry to for sending you a patch that falls in the middle of a stack
like this but it seems the only sane way to implement this.
include/linux/pid.h | 90 +++++++++++++++++----
include/linux/sched.h | 4 -
kernel/fork.c | 16 ++--
kernel/pid.c | 213 ++++++++++++++++++++++++++++++++++---------------
4 files changed, 233 insertions(+), 90 deletions(-)
f841047af05e375118496679f34cb5942a91a53e
diff --git a/include/linux/pid.h b/include/linux/pid.h
index 5b9082c..8d64799 100644
--- a/include/linux/pid.h
+++ b/include/linux/pid.h
@@ -1,6 +1,8 @@
#ifndef _LINUX_PID_H
#define _LINUX_PID_H
+#include <linux/rcupdate.h>
+
enum pid_type
{
PIDTYPE_PID,
@@ -9,18 +11,61 @@ enum pid_type
PIDTYPE_MAX
};
+/* What is struct pid?
+ *
+ * A struct pid is the kernels internal notion of a process identier.
+ * It refers to individual tasks, process groups, and sessions. While
+ * there are processes attached to it the struct pid lives in a hash
+ * table, so it and then the processes that it refers to it can be found
+ * quickly from the numeric pid value. The attached processes may be
+ * quickly access by following pointers from struct pid.
+ *
+ * Storing pid_t values in the kernel and refering to them later has a
+ * problem. The process originally with that pid may have exited the
+ * pid allocator wrapped, and another process could have come along
+ * and been assigned that pid.
+ *
+ * Refering to user space process by holding a reference to struct
+ * task_struct has a problem. When the user space process exit
+ * the now useless task_struct still kept. A task_struct plus a
+ * stack consumes around 10K of low kernel memory. More precisely
+ * this is THREAD_SIZE + sizeof(struct task_struct). By comparison
+ * a struct pid is about 64 bytes.
+ *
+ * Holding a reference to struct pid solves both of these problems.
+ * It is small so holding a reference does not consume a lot of
+ * resources, and since a new struct pid is allocated when the numeric
+ * pid value is reused when don't mistakenly refer to new process.
+ */
+
struct pid
{
+ atomic_t count;
/* Try to keep pid_chain in the same cacheline as nr for find_pid */
int nr;
struct hlist_node pid_chain;
- /* list of pids with the same nr, only one of them is in the hash */
- struct list_head pid_list;
+ /* lists of tasks that use this pid */
+ struct hlist_head tasks[PIDTYPE_MAX];
+ struct rcu_head rcu;
};
-#define pid_task(elem, type) \
- list_entry(elem, struct task_struct, pids[type].pid_list)
+struct pid_link
+{
+ struct hlist_node node;
+ struct pid *pid;
+};
+static inline struct pid *get_pid(struct pid *pid)
+{
+ if (pid)
+ atomic_inc(&pid->count);
+ return pid;
+}
+
+extern void FASTCALL(put_pid(struct pid *pid));
+extern struct task_struct *FASTCALL(pid_task(struct pid *pid, enum pid_type));
+extern struct task_struct *FASTCALL(get_pid_task(struct pid *pid, enum pid_type));
+
/*
* attach_pid() and detach_pid() must be called with the tasklist_lock
* write-held.
@@ -31,23 +76,40 @@ extern void FASTCALL(detach_pid(struct t
/*
* look up a PID in the hash table. Must be called with the tasklist_lock
- * held.
+ * or rcu_read_lock() held.
*/
-extern struct pid *FASTCALL(find_pid(enum pid_type, int));
+extern struct pid *FASTCALL(find_pid(int nr));
-extern int alloc_pidmap(void);
-extern void FASTCALL(free_pidmap(int));
+/*
+ * Lookup a PID in the hash table, and return with it's count elevated.
+ */
+extern struct pid *find_get_pid(int nr);
+
+extern struct pid *alloc_pid(void);
+extern void FASTCALL(free_pid(struct pid *pid));
+
+#define pid_next(task, type) \
+ ((task)->pids[(type)].node.next)
+#define pid_next_task(task, type) \
+ hlist_entry(pid_next(task, type), struct task_struct, pids[(type)].node)
+
+
+/* We could use hlist_for_each_entry_rcu here but it takes more arguments
+ * than the do_each_task_pid/while_each_task_pid. So we roll our own
+ * to preserve the existing interface.
+ */
#define do_each_task_pid(who, type, task) \
if ((task = find_task_by_pid_type(type, who))) { \
- prefetch((task)->pids[type].pid_list.next); \
+ prefetch(pid_next(task, type)); \
do {
#define while_each_task_pid(who, type, task) \
- } while (task = pid_task((task)->pids[type].pid_list.next,\
- type), \
- prefetch((task)->pids[type].pid_list.next), \
- hlist_unhashed(&(task)->pids[type].pid_chain)); \
- } \
+ } while (pid_next(task, type) && ({ \
+ task = pid_next_task(task, type); \
+ rcu_dereference(task); \
+ prefetch(pid_next(task, type)); \
+ 1; }) ); \
+ }
#endif /* _LINUX_PID_H */
diff --git a/include/linux/sched.h b/include/linux/sched.h
index db26557..23e0309 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -764,7 +764,7 @@ struct task_struct {
struct task_struct *group_leader; /* threadgroup leader */
/* PID/PID hash table linkage. */
- struct pid pids[PIDTYPE_MAX];
+ struct pid_link pids[PIDTYPE_MAX];
struct list_head thread_group;
struct completion *vfork_done; /* for vfork() */
@@ -902,7 +902,7 @@ static inline pid_t process_group(struct
*/
static inline int pid_alive(struct task_struct *p)
{
- return p->pids[PIDTYPE_PID].nr != 0;
+ return p->pids[PIDTYPE_PID].pid != NULL;
}
extern void free_task(struct task_struct *tsk);
diff --git a/kernel/fork.c b/kernel/fork.c
index 2ac5bd1..af3c5eb 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1304,17 +1304,19 @@ long do_fork(unsigned long clone_flags,
{
struct task_struct *p;
int trace = 0;
- long pid = alloc_pidmap();
+ struct pid *pid = alloc_pid();
+ long nr;
- if (pid < 0)
+ if (!pid)
return -EAGAIN;
+ nr = pid->nr;
if (unlikely(current->ptrace)) {
trace = fork_traceflag (clone_flags);
if (trace)
clone_flags |= CLONE_PTRACE;
}
- p = copy_process(clone_flags, stack_start, regs, stack_size, parent_tidptr, child_tidptr, pid);
+ p = copy_process(clone_flags, stack_start, regs, stack_size, parent_tidptr, child_tidptr, nr);
/*
* Do this prior waking up the new thread - the thread pointer
* might get invalid after that point, if the thread exits quickly.
@@ -1341,7 +1343,7 @@ long do_fork(unsigned long clone_flags,
p->state = TASK_STOPPED;
if (unlikely (trace)) {
- current->ptrace_message = pid;
+ current->ptrace_message = nr;
ptrace_notify ((trace << 8) | SIGTRAP);
}
@@ -1351,10 +1353,10 @@ long do_fork(unsigned long clone_flags,
ptrace_notify ((PTRACE_EVENT_VFORK_DONE << 8) | SIGTRAP);
}
} else {
- free_pidmap(pid);
- pid = PTR_ERR(p);
+ free_pid(pid);
+ nr = PTR_ERR(p);
}
- return pid;
+ return nr;
}
#ifndef ARCH_MIN_MMSTRUCT_ALIGN
diff --git a/kernel/pid.c b/kernel/pid.c
index a9f2dfd..8d49f2c 100644
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -28,8 +28,9 @@
#include <linux/hash.h>
#define pid_hashfn(nr) hash_long((unsigned long)nr, pidhash_shift)
-static struct hlist_head *pid_hash[PIDTYPE_MAX];
+static struct hlist_head *pid_hash;
static int pidhash_shift;
+static kmem_cache_t *pid_cachep;
int pid_max = PID_MAX_DEFAULT;
int last_pid;
@@ -60,9 +61,21 @@ typedef struct pidmap {
static pidmap_t pidmap_array[PIDMAP_ENTRIES] =
{ [ 0 ... PIDMAP_ENTRIES-1 ] = { ATOMIC_INIT(BITS_PER_PAGE), NULL } };
+/* Note: disable interrupts while the pidmap_lock is held as an
+ * interrupt might come in and do read_lock(&tasklist_lock).
+ *
+ * If we don't disable interrupts there is a nasty deadlock between
+ * detach_pid()->free_pid() and another cpu that does
+ * spin_lock(&pidmap_lock) followed by an interrupt routing that does
+ * read_lock(&tasklist_lock);
+ *
+ * After we clean up the tasklist_lock and know there are no
+ * irq handlers that take it we can leave the interrupts enabled.
+ * For now it is easier to be safe than to prove it can't happen.
+ */
static __cacheline_aligned_in_smp DEFINE_SPINLOCK(pidmap_lock);
-fastcall void free_pidmap(int pid)
+static fastcall void free_pidmap(int pid)
{
pidmap_t *map = pidmap_array + pid / BITS_PER_PAGE;
int offset = pid & BITS_PER_PAGE_MASK;
@@ -71,7 +84,7 @@ fastcall void free_pidmap(int pid)
atomic_inc(&map->nr_free);
}
-int alloc_pidmap(void)
+static int alloc_pidmap(void)
{
int i, offset, max_scan, pid, last = last_pid;
pidmap_t *map;
@@ -89,12 +102,12 @@ int alloc_pidmap(void)
* Free the page if someone raced with us
* installing it:
*/
- spin_lock(&pidmap_lock);
+ spin_lock_irq(&pidmap_lock);
if (map->page)
free_page(page);
else
map->page = (void *)page;
- spin_unlock(&pidmap_lock);
+ spin_unlock_irq(&pidmap_lock);
if (unlikely(!map->page))
break;
}
@@ -131,13 +144,73 @@ int alloc_pidmap(void)
return -1;
}
-struct pid * fastcall find_pid(enum pid_type type, int nr)
+fastcall void put_pid(struct pid *pid)
+{
+ if (!pid)
+ return;
+ if ((atomic_read(&pid->count) == 1) ||
+ atomic_dec_and_test(&pid->count))
+ kmem_cache_free(pid_cachep, pid);
+}
+
+static void delayed_put_pid(struct rcu_head *rhp)
+{
+ struct pid *pid = container_of(rhp, struct pid, rcu);
+ put_pid(pid);
+}
+
+fastcall void free_pid(struct pid *pid)
+{
+ /* We can be called with write_lock_irq(&tasklist_lock) held */
+ unsigned long flags;
+
+ spin_lock_irqsave(&pidmap_lock, flags);
+ hlist_del_rcu(&pid->pid_chain);
+ spin_unlock_irqrestore(&pidmap_lock, flags);
+
+ free_pidmap(pid->nr);
+ call_rcu(&pid->rcu, delayed_put_pid);
+}
+
+struct pid *alloc_pid(void)
+{
+ struct pid *pid;
+ enum pid_type type;
+ int nr = -1;
+
+ pid = kmem_cache_alloc(pid_cachep, GFP_KERNEL);
+ if (!pid)
+ goto out;
+
+ nr = alloc_pidmap();
+ if (nr < 0)
+ goto out_free;
+
+ atomic_set(&pid->count, 1);
+ pid->nr = nr;
+ for (type = 0; type < PIDTYPE_MAX; ++type)
+ INIT_HLIST_HEAD(&pid->tasks[type]);
+
+ spin_lock_irq(&pidmap_lock);
+ hlist_add_head_rcu(&pid->pid_chain, &pid_hash[pid_hashfn(pid->nr)]);
+ spin_unlock_irq(&pidmap_lock);
+
+out:
+ return pid;
+
+out_free:
+ kmem_cache_free(pid_cachep, pid);
+ pid = NULL;
+ goto out;
+}
+
+struct pid * fastcall find_pid(int nr)
{
struct hlist_node *elem;
struct pid *pid;
hlist_for_each_entry_rcu(pid, elem,
- &pid_hash[type][pid_hashfn(nr)], pid_chain) {
+ &pid_hash[pid_hashfn(nr)], pid_chain) {
if (pid->nr == nr)
return pid;
}
@@ -146,77 +219,82 @@ struct pid * fastcall find_pid(enum pid_
int fastcall attach_pid(task_t *task, enum pid_type type, int nr)
{
- struct pid *pid, *task_pid;
-
- task_pid = &task->pids[type];
- pid = find_pid(type, nr);
- task_pid->nr = nr;
- if (pid == NULL) {
- INIT_LIST_HEAD(&task_pid->pid_list);
- hlist_add_head_rcu(&task_pid->pid_chain,
- &pid_hash[type][pid_hashfn(nr)]);
- } else {
- INIT_HLIST_NODE(&task_pid->pid_chain);
- list_add_tail_rcu(&task_pid->pid_list, &pid->pid_list);
- }
-
- return 0;
-}
-
-static fastcall int __detach_pid(task_t *task, enum pid_type type)
-{
- struct pid *pid, *pid_next;
- int nr = 0;
+ struct pid_link *link;
+ struct pid *pid;
- pid = &task->pids[type];
- if (!hlist_unhashed(&pid->pid_chain)) {
+ WARN_ON(!task->pid); /* to be removed soon */
+ WARN_ON(!nr); /* to be removed soon */
- if (list_empty(&pid->pid_list)) {
- nr = pid->nr;
- hlist_del_rcu(&pid->pid_chain);
- } else {
- pid_next = list_entry(pid->pid_list.next,
- struct pid, pid_list);
- /* insert next pid from pid_list to hash */
- hlist_replace_rcu(&pid->pid_chain,
- &pid_next->pid_chain);
- }
- }
-
- list_del_rcu(&pid->pid_list);
- pid->nr = 0;
+ link = &task->pids[type];
+ link->pid = pid = find_pid(nr);
+ hlist_add_head_rcu(&link->node, &pid->tasks[type]);
- return nr;
+ return 0;
}
void fastcall detach_pid(task_t *task, enum pid_type type)
{
- int tmp, nr;
+ struct pid_link *link;
+ struct pid *pid;
+ int tmp;
- nr = __detach_pid(task, type);
- if (!nr)
- return;
+ link = &task->pids[type];
+ pid = link->pid;
+
+ hlist_del_rcu(&link->node);
+ link->pid = NULL;
for (tmp = PIDTYPE_MAX; --tmp >= 0; )
- if (tmp != type && find_pid(tmp, nr))
+ if (!hlist_empty(&pid->tasks[tmp]))
return;
- free_pidmap(nr);
+ free_pid(pid);
}
+struct task_struct * fastcall pid_task(struct pid *pid, enum pid_type type)
+{
+ struct task_struct *result = NULL;
+ if (pid) {
+ struct hlist_node *first;
+ first = rcu_dereference(pid->tasks[type].first);
+ if (first)
+ result = hlist_entry(first, struct task_struct, pids[(type)].node);
+ }
+ return result;
+}
+
+/*
+ * Must be called under rcu_read_lock() or with tasklist_lock read-held.
+ */
task_t *find_task_by_pid_type(int type, int nr)
{
- struct pid *pid;
+ return pid_task(find_pid(nr), type);
+}
- pid = find_pid(type, nr);
- if (!pid)
- return NULL;
+EXPORT_SYMBOL(find_task_by_pid_type);
- return pid_task(&pid->pid_list, type);
+struct task_struct *fastcall get_pid_task(struct pid *pid, enum pid_type type)
+{
+ struct task_struct *result;
+ rcu_read_lock();
+ result = pid_task(pid, type);
+ if (result)
+ get_task_struct(result);
+ rcu_read_unlock();
+ return result;
}
-EXPORT_SYMBOL(find_task_by_pid_type);
+struct pid *find_get_pid(pid_t nr)
+{
+ struct pid *pid;
+
+ rcu_read_lock();
+ pid = get_pid(find_pid(nr));
+ rcu_read_unlock();
+ return pid;
+}
+
/*
* The pid hash table is scaled according to the amount of memory in the
* machine. From a minimum of 16 slots up to 4096 slots at one gigabyte or
@@ -224,7 +302,7 @@ EXPORT_SYMBOL(find_task_by_pid_type);
*/
void __init pidhash_init(void)
{
- int i, j, pidhash_size;
+ int i, pidhash_size;
unsigned long megabytes = nr_kernel_pages >> (20 - PAGE_SHIFT);
pidhash_shift = max(4, fls(megabytes * 4));
@@ -233,16 +311,13 @@ void __init pidhash_init(void)
printk("PID hash table entries: %d (order: %d, %Zd bytes)\n",
pidhash_size, pidhash_shift,
- PIDTYPE_MAX * pidhash_size * sizeof(struct hlist_head));
+ pidhash_size * sizeof(struct hlist_head));
- for (i = 0; i < PIDTYPE_MAX; i++) {
- pid_hash[i] = alloc_bootmem(pidhash_size *
- sizeof(*(pid_hash[i])));
- if (!pid_hash[i])
- panic("Could not alloc pidhash!\n");
- for (j = 0; j < pidhash_size; j++)
- INIT_HLIST_HEAD(&pid_hash[i][j]);
- }
+ pid_hash = alloc_bootmem(pidhash_size * sizeof(*(pid_hash)));
+ if (!pid_hash)
+ panic("Could not alloc pidhash!\n");
+ for (i = 0; i < pidhash_size; i++)
+ INIT_HLIST_HEAD(&pid_hash[i]);
}
void __init pidmap_init(void)
@@ -251,4 +326,8 @@ void __init pidmap_init(void)
/* Reserve PID 0. We never call free_pidmap(0) */
set_bit(0, pidmap_array->page);
atomic_dec(&pidmap_array->nr_free);
+
+ pid_cachep = kmem_cache_create("pid", sizeof(struct pid),
+ __alignof__(struct pid),
+ SLAB_PANIC, NULL, NULL);
}
--
1.2.2.g709a-dirty
^ permalink raw reply related
* Re: How to quickly write cleanmarkers to jffs2 partitions?
From: Jaap-Jan Boor @ 2006-03-10 17:10 UTC (permalink / raw)
To: linuxppc
In-Reply-To: <200603080938.35299.david.jander@protonic.nl>
[-- Attachment #1: Type: text/plain, Size: 658 bytes --]
On Wed, 2006-03-08 at 09:38 +0100, David Jander wrote:
>
> Thanks to all for the suggestions.
> Is "cleanmark" an open-source tool?
well, I think so, as it's a minimal modified flash_eraseall.c from mtd
> Would you share it?
sure, a gzipped version is attached. Put it in the mtd/util directory
and add it to the Makefile there (to TARGETS) and:
cleanmark: crc32.o cleanmark.o
$(CC) $(LDFLAGS) -o $@ $^
best regards,
Jaap-Jan
>
> Greetings,
>
> --
> David Jander
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: cleanmark.c.gz --]
[-- Type: application/x-gzip, Size: 2567 bytes --]
^ permalink raw reply
* [ALSA - driver 0001841]: Mixer not working / fujitsu laptop V2060 with HDA intel & AD1986A
From: bugtrack @ 2006-03-10 17:17 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1841>
======================================================================
Reported By: fchevalier
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 1841
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution:
Kernel Version:
======================================================================
Date Submitted: 02-11-2006 14:13 CET
Last Modified: 03-10-2006 18:17 CET
======================================================================
Summary: Mixer not working / fujitsu laptop V2060 with HDA
intel & AD1986A
Description:
Hi all,
I am unable to use mixer settings on my laptop.
Basically ALSA correctly detects HDA intel, Analog device chip. Mixer
settings are there but changing volume, muting/unmuting does not make any
difference. Playing mp3 file with xmms sometimes i can hear some sound,
but not loud enough.
I tried with the latest ALSA version available, still not luck :-(
Can anyone help ?
Fabien
======================================================================
----------------------------------------------------------------------
tiwai - 03-09-06 18:43
----------------------------------------------------------------------
Forgot to add: the patch is to the latest ALSA CVS version. Don't try it
with 1.0.11rc3.
----------------------------------------------------------------------
kratz00 - 03-10-06 18:17
----------------------------------------------------------------------
i have the same hardware (see bugid 1714) and i can confirm the patch
works
sound is better with "model=2ch" than "model=3stack"
with "model=3stack" the sound is really scratchy
Issue History
Date Modified Username Field Change
======================================================================
02-11-06 14:13 fchevalier New Issue
03-09-06 17:01 fchevalier Note Added: 0008392
03-09-06 18:23 tiwai Note Added: 0008393
03-09-06 18:24 tiwai File Added: ad1986a-fix.diff
03-09-06 18:25 tiwai Note Added: 0008394
03-09-06 18:43 tiwai Note Added: 0008395
03-10-06 18:17 kratz00 Note Added: 0008406
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: Time went backwards
From: Rik van Riel @ 2006-03-10 17:17 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel
In-Reply-To: <5cee5f1c21deb3039d4a63748ae45b54@cl.cam.ac.uk>
On Fri, 10 Mar 2006, Keir Fraser wrote:
> On 10 Mar 2006, at 17:00, Rik van Riel wrote:
>
> > I am very frequently seeing these Time went backwards messages
> > on my test systems. Running a 2 VCPU guest on a single CPU
> > computer seems to be effective at triggering this ;)
>
> That's interesting, particularly if you can trigger on a single physical
> CPU. In that case cpu_delta should definitely *never* be negative. Maybe
> the steal_time logic, which does mess with per-cpu
> processed_system_time, is not quite right? :-)
My current suspicion is that the per-cpu processed_system_time
gets incremented twice during one timer irq handling, and then
we notice it was incremented too far during the _next_ timer
interrupt.
> When did you start seeing the messages?
They became frequent after the new steal time code went in.
--
All Rights Reversed
^ permalink raw reply
* Re: [PATCH] Fix shrink_dcache_parent() against shrink_dcache_memory() race (3rd updated patch)]
From: Balbir Singh @ 2006-03-10 17:17 UTC (permalink / raw)
To: Jan Blunck
Cc: Neil Brown, Kirill Korotaev, akpm, viro, olh, bsingharora,
linux-kernel
In-Reply-To: <20060310123153.GN4243@hasse.suse.de>
On Fri, Mar 10, 2006 at 01:31:53PM +0100, Jan Blunck wrote:
> On Fri, Mar 10, Neil Brown wrote:
>
> > -static void prune_dcache(int count)
> > +static void prune_dcache(int count, struct super_block *sb)
> > {
> > spin_lock(&dcache_lock);
> > for (; count ; count--) {
> > @@ -417,8 +425,10 @@ static void prune_dcache(int count)
> > spin_unlock(&dentry->d_lock);
> > continue;
> > }
> > - /* If the dentry was recently referenced, don't free it. */
> > - if (dentry->d_flags & DCACHE_REFERENCED) {
> > + /* If the dentry was recently referenced, or is for
> > + * a unmounting filesystem, don't free it. */
> > + if ((dentry->d_flags & DCACHE_REFERENCED) ||
> > + (dentry->d_sb != sb && dentry->d_sb->s_root == NULL)) {
> > dentry->d_flags &= ~DCACHE_REFERENCED;
> > list_add(&dentry->d_lru, &dentry_unused);
> > dentry_stat.nr_unused++;
>
> You have to down_read the rw-semaphore sb->s_umount since sb->s_root is
> protected by it :(
<snip>
Please do not beat me up for suggesting this. I was wondering if it
makes sense to add a PF_SHRINKER flag and set it in shrink_slab().
Use my solution, instead of PF_MEMALLOC check against PF_SHRINKER.
I think PF_SHRINKER might be a good idea, it might help us detect
races between the shrinker and other subsystems too - not only dcache.
It might be well worth adding in. If there is sufficient interest I can
send create and send out a patch.
Balbir
^ permalink raw reply
* Re: Time went backwards
From: Keir Fraser @ 2006-03-10 17:19 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel
In-Reply-To: <5cee5f1c21deb3039d4a63748ae45b54@cl.cam.ac.uk>
On 10 Mar 2006, at 17:14, Keir Fraser wrote:
>> I am very frequently seeing these Time went backwards messages
>> on my test systems. Running a 2 VCPU guest on a single CPU
>> computer seems to be effective at triggering this ;)
>
> That's interesting, particularly if you can trigger on a single
> physical CPU. In that case cpu_delta should definitely *never* be
> negative. Maybe the steal_time logic, which does mess with per-cpu
> processed_system_time, is not quite right? :-)
To that end, it would be interesting to see if after the first do-while
loop in timer_interrupt(), you can end up with sched_time >
(processed_system_time + delta).
If so, we could end up running per-cpu processed_system_time ahead of
current system time and so get -ve delta the *next* time we run
timer_interrupt().
-- Keir
^ permalink raw reply
* Re: Error in Masquerade ??
From: Leandro Silva @ 2006-03-10 17:20 UTC (permalink / raw)
To: netfilter
Thanks all !
Is there a bug in netfilter ? It's working fine but some packets are
leaving the server without being masqueraded. Although it's working
now, maybe one day somebody is going to use something that can have
problems ...
Leandro
^ permalink raw reply
* RE: Fix race in the accessed/dirty bit handlers
From: Chen, Kenneth W @ 2006-03-10 17:22 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <Pine.LNX.4.64.0603071901420.2463@schroedinger.engr.sgi.com>
Zoltan Menyhart wrote on Friday, March 10, 2006 1:47 AM
> > CPU A CPU B | CPU A CPU B | cpu A cpu B
> > ----- ----- | ----- ----- | ----- -----
> > change pte | |
> > | |
> > read pte |read pte |read pte
> > insert TLB | change pte |insert
> > re-read |insert |re-read
> > |re-read | change pte
> > |ptc.l
>
> These scenarii assume that the sequence:
>
> insert TLB
> ;;
> re-read
>
> is executed in the same order for everyone as it is coded.
Just for the record, itc has acquire semantics, though this is not
immediately relevant in this discussion with respect to external
ptc.g.
- Ken
^ permalink raw reply
* Re: 2.6.16-rc5 pppd oops on disconnects
From: Paul Fulghum @ 2006-03-10 17:22 UTC (permalink / raw)
To: Bob Copeland; +Cc: paulus, Linux Kernel list
In-Reply-To: <b6c5339f0603100625k3410897fy3515d93fa1918c9@mail.gmail.com>
On Fri, 2006-03-10 at 09:25 -0500, Bob Copeland wrote:
> Unable to handle kernel paging request at virtual address 6b6b6bfb
> printing eip:
> c027a4f6
> *pde = 00000000
> Oops: 0000 [#1]
> ...
> CPU: 0
> EIP: 0060:[<c027a4f6>] Not tainted VLI
> EFLAGS: 00210046 (2.6.16-rc5 #16)
> EIP is at __mutex_lock_slowpath+0x70/0x286
> eax: cf549e20 ebx: cf548000 ecx: 00000000 edx: 00000054
> esi: 6b6b6bdb edi: cea6f030 ebp: c017592e esp: cf549e20
> ds: 007b es: 007b ss: 0068
> Process pppd (pid: 4076, threadinfo=cf548000 task=cea6f030)
> Stack: <0>cf549e20 cf549e20 11111111 11111111 cf549e20 cce32c60
> cf609cc4 cf609ccc
> cf609c60 c017592e ccabf7a0 cce5466c 6b6b6b6b cce32c60 cf609cc4 cf609ccc
> cf609c60 c01e756e cce5466c ccabf7a0 cd619aac c029fd21 00000000 ccabf7a0
> Call Trace:
> [<c017592e>] sysfs_hash_and_remove+0x34/0x10a
> [<c01e756e>] class_device_del+0xa0/0x11c
> [<c01e75f5>] class_device_unregister+0xb/0x16
> [<d01f81f3>] acm_tty_unregister+0x1d/0x63 [cdc_acm]
This looks more like
http://bugzilla.kernel.org/show_bug.cgi?id=5876
The offset from 6b6b6b6b looks like slab poisoning on
the dentry in sysfs_hash_and_remove.
--
Paul Fulghum
Microgate Systems, Ltd
^ permalink raw reply
* Re: Query MLS info outside of SELinux/LSM?
From: Paul Moore @ 2006-03-10 17:22 UTC (permalink / raw)
To: Stephen Smalley; +Cc: SELinux List
In-Reply-To: <1142010664.25454.128.camel@moss-spartans.epoch.ncsc.mil>
Stephen Smalley wrote:
> On Fri, 2006-03-10 at 11:56 -0500, Paul Moore wrote:
>
>>Is there a way to query the number of MLS sensitivity levels and
>>categories outside of the SELinux LSM? I haven't seen anything, but
>>thought I would ask before I started looking at alternatives ... which
>>brings me to my next question - would anyone have an objection to adding
>>this functionality?
>
> The goal is to keep information about the specific security models
> encapsulated in the security server (security/selinux/ss/*.c). The rest
> of the SELinux code then remains policy-independent, as does the rest of
> the kernel.
>
The only concern I have with the above statement is that in some cases,
i.e. labeled networking, some of that security model information such as
MLS limits is important outside the security server.
--
paul moore
linux security @ hp
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: [XenPPC] Re: IRQs delivery.
From: Michal Ostrowski @ 2006-03-10 17:23 UTC (permalink / raw)
To: Olof Johansson
Cc: Tristan Gingold, xen-devel, Hollis Blanchard, xen-ppc-devel
In-Reply-To: <20060310170004.GA31080@pb15.lixom.net>
On Fri, 2006-03-10 at 11:00 -0600, Olof Johansson wrote:
> On Fri, Mar 10, 2006 at 09:30:38AM -0600, Hollis Blanchard wrote:
> > On Friday 10 March 2006 04:07, Tristan Gingold wrote:
> > >
> > > How xen/ppc delivers interrupts ?
> >
> > Ignoring hypervisors for a moment, the PPC model for external interrupts is
> > this: the hardware resets the PC to a fixed entry point (0x500) and changes
> > the MSR to put the processor into real (untranslated) mode. (The old PC and
> > MSR are saved into a pair of supervisor-only registers, SRR0 and SRR1.) The
> > exception handler is then responsible for querying the interrupt
> > controller(s) to get the interrupt vector, and then call the appropriate
> > driver.
> >
> > The IBM Research hypervisor (rhype) virtualized the PIC, so that instead of
> > querying hardware, the kernel makes an hcall to find the incoming vector. If
> > the interrupt is not in fact for this domain, the hypervisor queues the
> > interrupt for later and tells the current domain "nothing was pending after
> > all". Note that in this model, interrupts are delivered by the hardware
> > directly to the current domain without hypervisor involvement.
>
Acutally, rhype handles all 0x500 exceptions directly and then simulates
0x500 exceptions to partitions when they are to actually see an
interrupt. Thus if an interrupt occurs for a partition that is not
currently running, the partition does not see the exception. PHYP
implements it differently; 0x500 exceptions are always seen by the
currently running partitions even if the interrupt is not for them.
> Not that you have a choice on PPC970, but there's a drawback to this: If
> you let all interrupts be delivered directly to the domain, then it can
> hold the PIC "hostage" by disabling the delivery (keeping MSR_EE off),
> causing interrupts to other domains to be delayed.
>
PPC970 gives you the choice of where external exceptions are directed
to; hypervisor or partition (e.g. do external interrupts turn on
MSR.HV?).
> Some PPC processors have a feature called "mediated external interrupts",
> where they will be delivered to the hypervisor instead, and if the domain
> can't service it then (MSR_EE off), the HV can request to be notified
> when the domain can take it. The extra code path for re-delivering to a
> domain can be made short.
>
> rHype has some support for this already, but it's unclear which hardware
> has it. If I had to guess I would say at least Cell, since those parts
> of rhype are ripped out in the sources but some of the infrastructure
> is still in there.
>
rhype interrupt handling code has been design with mediated interrupts
in mind. If there are no mediated interrupts certain branches are never
taken and certain things become no-ops.
--
Michal Ostrowski <mostrows@watson.ibm.com>
^ permalink raw reply
* [ALSA - driver 0001841]: Mixer not working / fujitsu laptop V2060 with HDA intel & AD1986A
From: bugtrack @ 2006-03-10 17:25 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1841>
======================================================================
Reported By: fchevalier
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 1841
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution:
Kernel Version:
======================================================================
Date Submitted: 02-11-2006 14:13 CET
Last Modified: 03-10-2006 18:25 CET
======================================================================
Summary: Mixer not working / fujitsu laptop V2060 with HDA
intel & AD1986A
Description:
Hi all,
I am unable to use mixer settings on my laptop.
Basically ALSA correctly detects HDA intel, Analog device chip. Mixer
settings are there but changing volume, muting/unmuting does not make any
difference. Playing mp3 file with xmms sometimes i can hear some sound,
but not loud enough.
I tried with the latest ALSA version available, still not luck :-(
Can anyone help ?
Fabien
======================================================================
----------------------------------------------------------------------
kratz00 - 03-10-06 18:17
----------------------------------------------------------------------
i have the same hardware (see bugid 1714) and i can confirm the patch
works
sound is better with "model=2ch" than "model=3stack"
with "model=3stack" the sound is really scratchy
----------------------------------------------------------------------
tiwai - 03-10-06 18:25
----------------------------------------------------------------------
Good to hear that something gets better.
Please provide the output of "lspci -nv" (only for the corresponding
device) to choose this model for your laptop as default.
Issue History
Date Modified Username Field Change
======================================================================
02-11-06 14:13 fchevalier New Issue
03-09-06 17:01 fchevalier Note Added: 0008392
03-09-06 18:23 tiwai Note Added: 0008393
03-09-06 18:24 tiwai File Added: ad1986a-fix.diff
03-09-06 18:25 tiwai Note Added: 0008394
03-09-06 18:43 tiwai Note Added: 0008395
03-10-06 18:17 kratz00 Note Added: 0008406
03-10-06 18:25 tiwai Note Added: 0008407
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [Bluez-devel] PIN helper
From: Dave Mielke @ 2006-03-10 17:25 UTC (permalink / raw)
To: bluez-devel
In-Reply-To: <20060310082859.57eaf23b.fotopiper@o2.pl>
[-- Attachment #1: Type: text/plain, Size: 837 bytes --]
[quoted lines by Radek Rurarz on 2006/03/10 at 08:28 +0100]
>iPAQs or rather Familiar in general have a BusyBox all in one
>executable, at least for the basic comands.
>Bash is not present, it could be instaled, but at great expense of free
>space (or even not passible, doto lack of space).
>The executable has only sh, and I'm not sure is it a 100% full
>implementation.
Please try the attached updated script. I think I've removed all the bashisms.
My /bin/sh, however, supports more than it should so it's hard for me to be
sure.
--
Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the
Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me
EMail: dave@mielke.cc | Canada K2A 1H7 | if you're concerned about Hell.
http://FamilyRadio.com/ | http://Mielke.cc/bible/
[-- Attachment #2: bluepin --]
[-- Type: text/plain, Size: 6731 bytes --]
#!/bin/sh
# This script has been written by Dave Mielke <dave@mielke.cc>. It's a light
# weight, text mode, Bluetooth PIN helper script.
#
# Step 1: The PINs file, /etc/bluetooth/pins (can be changed with the -f
# option), is searched for a line which corresponds to the Bluetooth address of
# the device. Each line in this file should contain the address of a device and
# its PIN, in that order, separated by space. Any additional data on the line
# is ignored and can be used as a comment to help identify the device. For
# example, if the address of your cell phone is 01:23:45:67:89:AB, and if its
# PIN is 12345, then its line would look like this:
#
# 01:23:45:67:89:AB 12345 my cell phone
#
# If the address is found within the PINs file then the corresponding PIN is
# returned.
#
# Step 2: If the -c option has been specified then its operand is interpreted
# as the command which is to be used to prompt the user for the PIN. If it is
# appropriately quoted so that it can contain space then options may be
# specified after the command name. It must interpret its positional parameters
# and return its response as if it were being directly invoked as a Bluetooth
# PIN helper. If it returns a PIN then that PIN is returned.
#
# Step 3: If the -n option has not been specified then the user is prompted for
# the PIN via a text-mode dialog in a free virtual terminal. The console
# automatically returns to the original virtual terminal as soon as the user
# responds to the dialog. If the response contains at least one character then
# the entire response is returned as the PIN.
#
# Step 4: Return the fact that the PIN could not be determined.
#
# Error messages are written to the system log (syslog) if "logger" is in the
# command search path ($PATH) and if standard output is not a terminal (tty or
# pty). If any of these conditions is not satisfied then errors are written to
# standard error.
#
# Invoke this script with the -h option to see its usage summary.
configurationDirectory="/etc/bluetooth"
defaultPinCommand=""
defaultPinsFile="${configurationDirectory}/pins"
defaultAcceptableModes="600"
programName="${0##*/}"
programMessage() {
echo >&2 "${programName}: ${1}"
}
programError() {
programMessage "${2}" error
exit "${1}"
}
syntaxError() {
programError 2 "${1}"
}
findCommand() {
variable="${1}"
shift
command="${1}"
while [ "${#}" -gt 0 ]
do
path="`which "${1}" 2>/dev/null`"
[ -n "${path}" ] && {
eval "${variable}"'="${path}"'
return 0
}
shift
done
programMessage "command not found: ${command}"
return 1
}
respondWithPin() {
echo "PIN:${1}"
exit 0
}
[ ! -t 1 ] && {
findCommand loggerPath logger && {
programMessage() {
"${loggerPath}" -t "${programName}[${$}]" -p "daemon.${2:-warning}" -- "${1}"
}
}
}
showUsage=false
pinCommand="${defaultPinCommand}"
pinsFile="${defaultPinsFile}"
acceptableModes="${defaultAcceptableModes}"
promptUser=true
pinLimit=16
while getopts ":c:f:hm:n" option
do
case "${option}"
in
c) pinCommand="${OPTARG}";;
f) pinsFile="${OPTARG}";;
h) showUsage=true;;
m) acceptableModes="${OPTARG}";;
n) promptUser=false;;
\?) syntaxError "invalid option: -${OPTARG}";;
:) syntaxError "missing operand: -${OPTARG}";;
*) syntaxError "unimplemented option: -${option}";;
esac
done
shift `expr "${OPTIND}" - 1`
"${showUsage}" && {
cat <<END_USAGE
Usage: ${programName} [-option ...] connection-direction device-address [device-name]
-c command The command to prompt for a PIN not in the PINs file.${defaultPinCommand:+ [${defaultPinCommand}]}
-f file The PINs file.${defaultPinsFile:+ [${defaultPinsFile}]}
-h This command usage summary.
-m modes The modes (in octal) that the PINs file may have.${defaultAcceptableModes:+ [${defaultAcceptableModes}]}
-n Do not prompt for the PIN.
END_USAGE
exit 0
}
[ "${#}" -eq 0 ] && syntaxError "connection direction not supplied"
connectionDirection="${1}"
shift
if [ "${connectionDirection}" = "out" ]
then
connectionAdjective="outgoing"
connectionPreposition="to"
else
[ "${connectionDirection}" = "in" ] || programMessage "unexpected connection direction: ${connectionDirection}"
connectionAdjective="incoming"
connectionPreposition="from"
fi
[ "${#}" -eq 0 ] && syntaxError "device address not supplied"
deviceAddress="${1}"
shift
if [ "${#}" -eq 0 ]
then
deviceName=""
else
deviceName="${1}"
shift
fi
[ `expr " ${acceptableModes}" : ' [0-7]*$'` -eq 4 ] || syntaxError "invalid file permission modes: ${acceptableModes}"
[ "${acceptableModes#0}" = "${acceptableModes}" ] && acceptableModes="0${acceptableModes}"
[ -n "${pinsFile}" -a -f "${pinsFile}" ] && {
if [ ! -r "${pinsFile}" ]
then
programMessage "file not readable: ${pinsFile}"
else
if [ -z "${acceptableModes}" ]
then
safeModes=true
else
safeModes=false
if findCommand statPath stat
then
actualModes="`"${statPath}" -c '%a' -- "${pinsFile}"`"
[ "${actualModes#0}" = "${actualModes}" ] && actualModes="0${actualModes}"
# if ((actualModes & ~acceptableModes))
if false
then
programMessage "unsafe file permission modes: ${pinsFile}: ${actualModes} > ${acceptableModes}"
else
safeModes=true
fi
else
programMessage "file permission modes not verifiable: ${pinsFile}"
fi
fi
"${safeModes}" && {
exec <"${pinsFile}"
while read address pin comment
do
[ "${address}" = "${deviceAddress}" ] && respondWithPin "${pin}"
done
exec <&-
}
fi
}
[ `expr " ${pinCommand}" : ' *[^ ]'` -gt 0 ] && {
set -- ${pinCommand} "${connectionDirection}" "${deviceAddress}"
[ -n "${deviceName}" ] && set -- "${@}" "${deviceName}"
response="`"${@}" | head -1`"
pin="${response#PIN:}"
[ "${pin}" != "${response}" ] && respondWithPin "${pin}"
}
"${promptUser}" && {
findCommand openPath open openvt && {
dialogTitle="Bluetooth PIN Prompt"
dialogTime="`date '+%Y-%m-%d@%H:%M:%S'`"
dialogPrompt="Enter PIN for ${connectionAdjective} Bluetooth connection ${connectionPreposition} ${deviceName}[${deviceAddress}]"
findCommand dialogPath dialog && {
pin="`"${openPath}" 3>&1 -s -w -- "${dialogPath}" --output-fd 3 --clear --title "${dialogTitle}" --cr-wrap --max-input "${pinLimit}" --inputbox "${dialogTime}\n\n${dialogPrompt}" 0 0 ""`"
[ -n "${pin}" ] && respondWithPin "${pin}"
}
}
}
echo "ERR"
exit 0
^ permalink raw reply
* [ALSA - driver 0001714]: Intel HDA (AD1986A) no sound
From: bugtrack @ 2006-03-10 17:26 UTC (permalink / raw)
To: alsa-devel
The following issue has been RESOLVED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1714>
======================================================================
Reported By: kratz00
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 1714
Category: 1_OTHERS
Reproducibility: always
Severity: major
Priority: normal
Status: resolved
Distribution: LFS
Kernel Version: 2.6.15
Resolution: duplicate
Duplicate: 1841
Fixed in Version:
======================================================================
Date Submitted: 01-04-2006 18:04 CET
Last Modified: 03-10-2006 18:26 CET
======================================================================
Summary: Intel HDA (AD1986A) no sound
Description:
It's a Samsung M50 Notebook.
I also tried Alsa 1.0.10 but the problem is the same.
There are no specific module options for the AD1986A chip, right?
00:1b.0 Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) High Definition Audio Controller (rev 03)
Subsystem: Samsung Electronics Co Ltd Unknown device c01e
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at 80000000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0
Enable-
Capabilities: [70] Express Unknown type IRQ 0
Capabilities: [100] Virtual Channel
Capabilities: [130] Unknown (5)
loaded modules:
snd_pcm_oss 47136 0
snd_mixer_oss 16512 1 snd_pcm_oss
snd_hda_intel 14224 0
snd_hda_codec 122624 1 snd_hda_intel
snd_pcm 75912 3 snd_pcm_oss,snd_hda_intel,snd_hda_codec
snd_timer 19844 1 snd_pcm
snd 46144 6
snd_pcm_oss,snd_mixer_oss,snd_hda_intel,snd_hda_codec,snd_pcm,snd_timer
snd_page_alloc 8328 2 snd_hda_intel,snd_pcm
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
duplicate of 0001841 Mixer not working / fujitsu laptop V20...
======================================================================
----------------------------------------------------------------------
kratz00 - 01-30-06 13:40
----------------------------------------------------------------------
tried alsa-driver-1.0.11rc3 and still no luck :/
----------------------------------------------------------------------
tiwai - 03-10-06 18:26
----------------------------------------------------------------------
The patch is in #1841.
Issue History
Date Modified Username Field Change
======================================================================
01-04-06 18:04 kratz00 New Issue
01-04-06 18:04 kratz00 Distribution => LFS
01-04-06 18:04 kratz00 Kernel Version => 2.6.15
01-30-06 13:40 kratz00 Note Added: 0007837
02-07-06 00:48 gerick Issue Monitored: gerick
02-08-06 13:13 simonckenyon Issue Monitored: simonckenyon
03-10-06 18:26 tiwai Relationship added duplicate of 0001841
03-10-06 18:26 tiwai Duplicate ID 0 => 1841
03-10-06 18:26 tiwai Status new => resolved
03-10-06 18:26 tiwai Resolution open => duplicate
03-10-06 18:26 tiwai Assigned To => tiwai
03-10-06 18:26 tiwai Note Added: 0008408
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: Re: IRQs delivery.
From: Hollis Blanchard @ 2006-03-10 17:27 UTC (permalink / raw)
To: Tristan Gingold; +Cc: xen-devel, xen-ppc-devel
In-Reply-To: <200603101647.46590.Tristan.Gingold@bull.net>
Tristan Gingold wrote:
>On ia64, PIC is part of the processor and is already fully-virtualized.
>We are considering to switch to event channel.
>
>
What do you mean by "already fully virtualized" -- you mean before Xen,
this was already part of the architecture? Could you elaborate on that?
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* RE: Fix race in the accessed/dirty bit handlers
From: Luck, Tony @ 2006-03-10 17:28 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <Pine.LNX.4.64.0603071901420.2463@schroedinger.engr.sgi.com>
> Please consider the second issue I mentioned about the "itc":
> Making sure that an external purge request will not be missed by our new
> translation. See also on page 3:127:
While this is true, I'm still not seeing how this can cause
a problem (but I didn't see the problem that Christoph just
found that started this whole thread in six years of looking
at this code, so I'm willing to accept that I may be missing
something).
If another processor has a purge floating out there on the
bus at this time, it would be because that other processor
was making some change to this mapping. In which case it
would have executed:
*pte = new_value
ptc
Are you saying that these events may become visible to the
processor that is executing the dirty_bit handler in either
order, so that you are worried we'll see the old *pte value
when we do the load, but miss the purge because we didn't
wait for the itc.d to complete before we did the load?
-Tony
^ permalink raw reply
* Re: [Patch]: adding physdev_op to hypercall.h
From: Muli Ben-Yehuda @ 2006-03-10 17:29 UTC (permalink / raw)
To: Tristan Gingold; +Cc: xen-devel
In-Reply-To: <200603101723.56105.Tristan.Gingold@bull.net>
On Fri, Mar 10, 2006 at 05:23:56PM +0100, Tristan Gingold wrote:
> Declare do_physdev_op.
What are the intended semantics of do_physdev_op?
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
^ permalink raw reply
* RE: Fix race in the accessed/dirty bit handlers
From: Chen, Kenneth W @ 2006-03-10 17:29 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <Pine.LNX.4.64.0603071901420.2463@schroedinger.engr.sgi.com>
Zoltan Menyhart wrote on Friday, March 10, 2006 9:12 AM
> Please consider the second issue I mentioned about the "itc":
> Making sure that an external purge request will not be missed by our new
> translation. See also on page 3:127:
>
> "The visibility of the itc instruction to generated purges (ptc.g, ptc.ga) must occur > before subsequent memory operations. From
a software perspective, this is similar to > acquire semantics. Serialization is still required to observe the side-effects of the >
translation being present."
>
> How to tell if this "visibility of the itc instruction to generated purges"
> has already been established?
>
> I think a ";;" is not enough, this is why I propose this sequence:
>
> itc.d r25
> ;;
> srlz.d
> ld8 r18 = [r17]
Thinking wild, I think we need a release semantics on the load. But such
thing isn't available.
- Ken
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.