Re: [PATCH] Export current_is_keventd() for libphy

[Andrew Morton]

On Wed, 6 Dec 2006 22:42:07 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:

> But I wouldn't want to think about an implementation as long as we have
> that WORK_STRUCT_NOAUTOREL horror in there.  Can we just nuke that?  Only
> three drivers need it and I bet they can be modified to use the usual
> mechanisms.

I guess I don't understand exactly what problem the noautorel stuff is
trying to solve.  It _seems_ to me that in all cases we can simply stuff
the old `data' field in alongside the controlling work_struct or
delayed_work which wants to operate on it.

Bridge is the simple case..

diff -puN net/bridge/br_private.h~bridge-avoid-using-noautorel-workqueues 
net/bridge/br_private.h
--- a/net/bridge/br_private.h~bridge-avoid-using-noautorel-workqueues
+++ a/net/bridge/br_private.h
@@ -83,6 +83,7 @@ struct net_bridge_port
struct timer_list   message_age_timer;
struct kobject  kobj;
struct delayed_work carrier_check;
+   struct net_device   *carrier_check_dev;
struct rcu_head rcu;
 };
 
diff -puN net/bridge/br_if.c~bridge-avoid-using-noautorel-workqueues 
net/bridge/br_if.c
--- a/net/bridge/br_if.c~bridge-avoid-using-noautorel-workqueues
+++ a/net/bridge/br_if.c
@@ -83,14 +83,11 @@ static void port_carrier_check(struct wo
struct net_device *dev;
struct net_bridge *br;
 
-   dev = container_of(work, struct net_bridge_port,
-  carrier_check.work)->dev;
-   work_release(work);
-
+   p = container_of(work, struct net_bridge_port, carrier_check.work);
+   dev = p->carrier_check_dev;
rtnl_lock();
-   p = dev->br_port;
-   if (!p)
-   goto done;
+   if (!dev->br_port)
+   goto done;  /* Can this happen? */
br = p->br;
 
if (netif_carrier_ok(dev))
@@ -280,7 +277,8 @@ static struct net_bridge_port *new_nbp(s
p->port_no = index;
br_init_port(p);
p->state = BR_STATE_DISABLED;
-   INIT_DELAYED_WORK_NAR(>carrier_check, port_carrier_check);
+   p->carrier_check_dev = dev;
+   INIT_DELAYED_WORK(>carrier_check, port_carrier_check);
br_stp_port_timer_init(p);
 
kobject_init(>kobj);
_


What am I missing?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6.19] drivers/char/vt.c: check kmalloc() return value.

[Amit Choudhary]

Description: Check the return value of kmalloc() in function con_init(), in 
file drivers/char/vt.c.

Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>

diff --git a/drivers/char/vt.c b/drivers/char/vt.c
index 87587b4..6aa08cb 100644
--- a/drivers/char/vt.c
+++ b/drivers/char/vt.c
@@ -2640,6 +2640,15 @@ static int __init con_init(void)
 */
for (currcons = 0; currcons < MIN_NR_CONSOLES; currcons++) {
vc_cons[currcons].d = vc = alloc_bootmem(sizeof(struct 
vc_data));
+   if (!vc_cons[currcons].d) {
+   for (--currcons; currcons >= 0; currcons--) {
+   kfree(vc_cons[currcons].d);
+   vc_cons[currcons].d = NULL;
+   }
+   release_console_sem();
+   return -ENOMEM;
+   }
+
visual_init(vc, currcons, 1);
vc->vc_screenbuf = (unsigned short 
*)alloc_bootmem(vc->vc_screenbuf_size);
vc->vc_kmalloced = 0;
-
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: CPUFREQ-CPUHOTPLUG: Possible circular locking dependency

[Gautham R Shenoy]

Hi Venki,
On Wed, Dec 06, 2006 at 10:27:01AM -0800, Pallipadi, Venkatesh wrote:

> But, if we make cpufreq more affected_cpus aware and have a per_cpu
> target()
> call by moving set_cpus_allowed() from driver into cpufreq core and
> define
> the target function to be atomic/non-sleeping type, then we really don't
> need a hotplug lock for the driver any more. Driver can have
> get_cpu/put_cpu
> pair to disable preemption and then change the frequency.

Well, we would still need to keep the affected_cpus map in sync with the
cpu_online map. That would still require hotplug protection, right?

Besides, I would love to see a way of implementing target function to be
atomic/non-sleeping type. But as of now, the target functions call
cpufreq_notify_transition which might sleep.

That's not the last of my worries. The ondemand-workqueue interaction
in the cpu_hotplug callback path can cause a deadlock if we go for
per-subsystem hotcpu mutexes. Can you think of a way by which we can 
avoid destroying the kondemand workqueue from the cpu-hotplug callback
path ? Please see http://lkml.org/lkml/2006/11/30/9 for the
culprit-callpath.

Thanks and Regards
gautham.
-- 
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
-
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: Possible Bug in VM accounting (Committed_AS) on x86_64 architecture ?

[Kunal Trivedi]

Hi Alan,
Sorry for late followup on this.

I did found the problem. It was 32 bit binary running on 64 bit arch.
Actually main kernel had fixed this problem in 2.6.14
(http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2fd4ef85e0db9ed75c98e13953257a967ea55e03)
But apparently CentOS has not ported it yet.

Thanks for your reply

-Kunal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: D-cache aliasing issue in cow_user_page

[David Miller]

From: "Matt Reimer" <[EMAIL PROTECTED]>
Date: Wed, 6 Dec 2006 22:20:22 -0800

> Ok, good to know, since that's what we're doing with ARM drivers
> presently. What's the preferred method going forward?

There are multiple ways provided to solve the problem so that
platforms can use whichever variant works best.
-
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: dentry cache grows to really large number on 64bit machine

[Kunal Trivedi]

Hi,
Another piece of information...
If i do on shell.

# while 1
# ./grow_dentry
# end
(grow_dentry is C code I've posted in previous msg.)

Then dentry_cache grows really fast.

But if within 'C' code if I write while(1), then everything is okay.
(No substantial growth ).

Thanks
-Kunal

On 12/6/06, Kunal Trivedi <[EMAIL PROTECTED]> wrote:

Hi,
I am running 2.6.18 kernel on 64 bit AMD machine. (procinfo attached
at the end of the mail). One of the things I have noticed that
dentry_cache grows really fast under certain code path.
So, far I have not seen any problems, but I would like to get some
more input on this subject. Is it okay for dentry_cache to grow that
much ?

I've run following program for an ~1.00 hour. And my slabinfo shows following.

# cat /proc/slabinfo | grep dentry
dentry_cache  5228333 5228333224   171 : tunables  120
608 : slabdata 307549 307549  0


# cat /proc/meminfo
MemTotal:  8173080 kB
MemFree:   6787852 kB
Buffers: 42048 kB
Cached:  72616 kB
SwapCached:  0 kB
Active:  88608 kB
Inactive:29796 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:  8173080 kB
LowFree:   6787852 kB
SwapTotal: 2096472 kB
SwapFree:  2096472 kB
Dirty:  48 kB
Writeback:   0 kB
AnonPages:3716 kB
Mapped:   3336 kB
Slab:  1251292 kB
PageTables:192 kB
NFS_Unstable:0 kB
Bounce:  0 kB
CommitLimit:  10269552 kB
Committed_AS:11500 kB
VmallocTotal: 34359738367 kB
VmallocUsed:  1272 kB
VmallocChunk: 34359737015 kB
HugePages_Total: 0
HugePages_Free:  0
HugePages_Rsvd:  0
Hugepagesize: 2048 kB


int
main()
{
int fd;
char fname[] = "/tmp/proc-output-XX";

fd = mkstemp(fname);
close(fd);
unlink(fname);
return 0;
}

Please advice,

Thanks
-Kunal


-
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: Obtaining a list of memory address ranges allocated to processes

[Arjan van de Ven]

On Wed, 2006-12-06 at 17:56 -0600, Stephen Torri wrote:
> I am trying to create a custom ELF and Windows PE loader for the purpose
> of security research. I am having a difficult time finding how to
> allocate memory for a binary at the desired address in memory
> (especially if its non-relocatable). I would like to see why I cannot
> get memory allocated at the exact address request in the binary headers.
> Is there a program or system call that allows me to see a list of memory
> address ranges allocated to the running processes on a system?

Hi,

check the /proc//maps and /proc//smaps files... they have
exactly what you need

Greetings,
   Arjan van de Ven

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6.19] net/wanrouter/wanmain.c: check kmalloc() return value.

[Amit Choudhary]

Description: Check the return value of kmalloc() in function dbg_kmalloc(), in 
file net/wanrouter/wanmain.c.

Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>

diff --git a/net/wanrouter/wanmain.c b/net/wanrouter/wanmain.c
index 316211d..263450c 100644
--- a/net/wanrouter/wanmain.c
+++ b/net/wanrouter/wanmain.c
@@ -67,6 +67,8 @@ static void * dbg_kmalloc(unsigned int s
int i = 0;
void * v = kmalloc(size+sizeof(unsigned int)+2*KMEM_SAFETYZONE*8,prio);
char * c1 = v;
+   if (!v)
+   return NULL;
c1 += sizeof(unsigned int);
*((unsigned int *)v) = size;
 
-
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: workqueue deadlock

[Srivatsa Vaddagiri]

On Thu, Dec 07, 2006 at 11:47:01AM +0530, Srivatsa Vaddagiri wrote:
>   - Make it rw-sem

I think rw-sems also were shown to hit deadlocks (recursive read-lock
attempt deadlocks when a writer comes between the two read attempts by the same
thread). So below suggestion only seems to makes sense ..

>   - Make it per-cpu mutex, which could be either:
> 
>   http://lkml.org/lkml/2006/11/30/110 - Ingo's suggestion
>   http://lkml.org/lkml/2006/10/26/65 - Gautham's work based on RCU
> 
> In Ingo's suggestion, I really dont know if the task_struct
> modifications is a good thing (to support recursive requirements).
> Gautham's patches avoid modifications to task_struct, is fast but can
> starve writers (who want to bring down/up a CPU).

-- 
Regards,
vatsa
-
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] Export current_is_keventd() for libphy

[Andrew Morton]

On Wed, 6 Dec 2006 17:21:50 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:

> 
> 
> On Wed, 6 Dec 2006, Linus Torvalds wrote:
> > 
> > How about something like this?
> 
> I didn't get any answers on this. I'd like to get this issue resolved, but 
> since I don't even use libphy on my main machine, I need somebody else to 
> test it for me.
> 
> Just to remind you all, here's the patch again. This is identical to the 
> previous version except for the trivial cleanup to use "work_pending()" 
> instead of open-coding it in two places.
> 
>   Linus
> 
> ...
>
> +static int __run_work(struct cpu_workqueue_struct *cwq, struct work_struct 
> *work)
> +{
> + int ret = 0;
> + unsigned long flags;
> +
> + spin_lock_irqsave(>lock, flags);
> + /*
> +  * We need to re-validate the work info after we've gotten
> +  * the cpu_workqueue lock. We can run the work now iff:
> +  *
> +  *  - the wq_data still matches the cpu_workqueue_struct
> +  *  - AND the work is still marked pending
> +  *  - AND the work is still on a list (which will be this
> +  *workqueue_struct list)
> +  *
> +  * All these conditions are important, because we
> +  * need to protect against the work being run right
> +  * now on another CPU (all but the last one might be
> +  * true if it's currently running and has not been
> +  * released yet, for example).
> +  */
> + if (get_wq_data(work) == cwq
> + && work_pending(work)
> + && !list_empty(>entry)) {
> + work_func_t f = work->func;
> + list_del_init(>entry);
> + spin_unlock_irqrestore(>lock, flags);
> +
> + if (!test_bit(WORK_STRUCT_NOAUTOREL, >management))
> + work_release(work);
> + f(work);
> +
> + spin_lock_irqsave(>lock, flags);
> + cwq->remove_sequence++;
> + wake_up(>work_done);
> + ret = 1;
> + }
> + spin_unlock_irqrestore(>lock, flags);
> + return ret;
> +}
> +
> +/**
> + * run_scheduled_work - run scheduled work synchronously
> + * @work: work to run
> + *
> + * This checks if the work was pending, and runs it
> + * synchronously if so. It returns a boolean to indicate
> + * whether it had any scheduled work to run or not.
> + *
> + * NOTE! This _only_ works for normal work_structs. You
> + * CANNOT use this for delayed work, because the wq data
> + * for delayed work will not point properly to the per-
> + * CPU workqueue struct, but will change!
> + */
> +int fastcall run_scheduled_work(struct work_struct *work)
> +{
> + for (;;) {
> + struct cpu_workqueue_struct *cwq;
> +
> + if (!work_pending(work))
> + return 0;

But this will return to the caller if the callback is presently running on
a different CPU.  The whole point here is to be able to reliably kill off
the pending work so that the caller can free resources.

> + if (list_empty(>entry))
> + return 0;
> + /* NOTE! This depends intimately on __queue_work! */
> + cwq = get_wq_data(work);
> + if (!cwq)
> + return 0;
> + if (__run_work(cwq, work))
> + return 1;
> + }
> +}
> +EXPORT_SYMBOL(run_scheduled_work);

Also, I worry that this code can run the callback on the caller's CPU. 
Users of per-cpu workqueues can legitimately assume that each callback runs
on the right CPU.  I doubt if many callers _do_ do that - there's
schedule_delayed_work_on(), but that's a bit different.

A solution to both problems is of course to block the caller if the
callback is running.  We can perhaps borrow cwq->work_done for that.


But I wouldn't want to think about an implementation as long as we have
that WORK_STRUCT_NOAUTOREL horror in there.  Can we just nuke that?  Only
three drivers need it and I bet they can be modified to use the usual
mechanisms.

-
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: workqueue deadlock

[Srivatsa Vaddagiri]

On Wed, Dec 06, 2006 at 05:26:14PM -0700, Bjorn Helgaas wrote:
> loadkeys is holding the cpu_hotplug lock (acquired in flush_workqueue())
> and waiting in flush_cpu_workqueue() until the cpu_workqueue drains.
> 
> But events/4 is responsible for draining it, and it is blocked waiting
> to acquire the cpu_hotplug lock.
> 
> In current upstream, the cpu_hotplug lock has been replaced with
> workqueue_mutex, but it looks to me like the same deadlock is still
> possible.

Yes I think so too.

> Is there some rule that workqueue functions shouldn't try to
> flush a workqueue?  

In general, workqueue functions wanting to flush workqueue seems wierd
to me. But in this case, I think the requirement is to block until all
queued work is complete, which is what flush_workqueue is supposed to
do. Hence I dont see any way to avoid it ..

> Or should flush_workqueue() be smarter by
> releasing the workqueue_mutex once in a while?

IMHO, rehauling lock_cpu_hotplug() to support scenarios like this is a
better approach. 

- Make it rw-sem
- Make it per-cpu mutex, which could be either:

http://lkml.org/lkml/2006/11/30/110 - Ingo's suggestion
http://lkml.org/lkml/2006/10/26/65 - Gautham's work based on RCU

In Ingo's suggestion, I really dont know if the task_struct
modifications is a good thing (to support recursive requirements).
Gautham's patches avoid modifications to task_struct, is fast but can
starve writers (who want to bring down/up a CPU).

-- 
Regards,
vatsa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: D-cache aliasing issue in cow_user_page

[Matt Reimer]

On 12/6/06, David Miller <[EMAIL PROTECTED]> wrote:

From: "Matt Reimer" <[EMAIL PROTECTED]>
Date: Wed, 6 Dec 2006 13:19:41 -0800

> On 12/5/06, David Miller <[EMAIL PROTECTED]> wrote:
> > From: "Matt Reimer" <[EMAIL PROTECTED]>
> > Date: Tue, 5 Dec 2006 16:57:12 -0800
> >
> > > Right, but isn't he declaring that each architecture needs to take
> > > care of this? So, say, on ARM we'd need to make kunmap() not a NOP and
> > > call flush_dcache_page() ?
> >
> > No.  He is only solving a problem that occurs on HIGHMEM
> > configurations on systems which can have D-cache aliasing
> > issues.
>
> Are you sure? James specifically mentions "non-highmem architectures,"
> and "all architectures with coherence issues," which would seem to
> include ARM (which is my concern).
>
> For your convenience I quote the whole commit message below.

Ok, I see.

He's providing it an alternative way to solve the coherency
issues.

You can still solve it the traditional way via cache flushing
in flush_dcache_page() and {copy,clear}_user_page().


Ok, good to know, since that's what we're doing with ARM drivers
presently. What's the preferred method going forward?

If architectures with coherency problems have to take care of this in
their kmap() implementations, wouldn't commits like [1] below result
in a pessmization for these architectures, since effectively the flush
would happen twice (once by architecture-specific kunmap, and once by
the flush_dcache_page() being added in this commit)?

Matt

[1] 
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c4ec7b0de4bc18ccb4380de638550984d9a65c25
-
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: Oops in pata_pdc2027x

[Stephen Rothwell]

On Thu, 07 Dec 2006 11:56:32 +0800 Albert Lee <[EMAIL PROTECTED]> wrote:
>
> It seems the opps occurred in the ata_exec_internal(). Could you please
> try the attached patch and see if the older ata_exec_internal() works?
> This can help to narrow it down.

This worked much better:

Waiting for /dev to be fully populated...pata_pdc2027x 0001:cc:01.0: PLL input 
clock 32721 kHz
ata1: PATA max UDMA/133 cmd 0xD800801457C0 ctl 0xD80080145FDA bmdma 
0xD80080145000 irq 324
ata2: PATA max UDMA/133 cmd 0xD800801455C0 ctl 0xD80080145DDA bmdma 
0xD80080145008 irq 324
scsi1 : pata_pdc2027x
ata1.00: ATAPI, max UDMA/66
ata1.00: configured for UDMA/66
scsi2 : pata_pdc2027x
ATA: abnormal status 0x8 on port 0xD800801455DF
scsi 1:0:0:0: CD-ROMIBM  DROM00205L1   H0 P533 PQ: 0 ANSI: 2
sr0: scsi3-mmc drive: 24x/24x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 1:0:0:0: Attached scsi generic sg4 type 5
done.

--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpkYlxmPpTXF.pgp
Description: PGP signature

Re: [PATCH 2/3] x86: remove duplicated parser for "pci=noacpi"

[Yinghai Lu]

so first hunk of the patch doesn't have nothing in common with second ,
and it is different disable acpi_irqs than disable all acpi,
callacpi_disable_pci () is acpi=off.


pci=noacpi mean it will not use acpi for pci bus scan and irq routing setting.
acpi=noirq mean it will only not use irq routing setting.

the problem is that old code in acpi is processing pci= for pci subsystem.

YH
-
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] eCryptfs: Public key; packet management

[Andrew Morton]

On Wed, 6 Dec 2006 17:12:37 -0600
Michael Halcrow <[EMAIL PROTECTED]> wrote:

> Public key support code. This reads and writes packets in the header
> that contain public key encrypted file keys. It calls the messaging
> code in the previous patch to send and receive encryption and
> decryption request packets from the userspace daemon.
> 
> ...
>
> + memset(auth_tok_list_item, 0,
> +sizeof(struct ecryptfs_auth_tok_list_item));
> + kmem_cache_free(ecryptfs_auth_tok_list_item_cache,
> + auth_tok_list_item);
>
> ...
>
> + memset(auth_tok_list_item, 0,
> +sizeof(struct ecryptfs_auth_tok_list_item));
> + kmem_cache_free(ecryptfs_auth_tok_list_item_cache,
> + auth_tok_list_item);

That's a bit wasteful of cycles.  Or is this done to minimise the exposure
of sensitive data?  If so, a comment would be in order.
-
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/2] eCryptfs: Public key; transport mechanism

[Andrew Morton]

On Wed, 6 Dec 2006 17:06:38 -0600
Michael Halcrow <[EMAIL PROTECTED]> wrote:

> This is a re-submission of the same public key patches (updated for
> 2.6.19-rc6-mm2) that were submitted for review a while back.

I made a number of comments last time around, some temperate, some not.
I trust the temperate ones were addressed?

Is there really no way in which any other kernel subsystem will ever want
functionality of this nature?

> This is the transport code for public key functionality in
> eCryptfs. It manages encryption/decryption request queues with a
> transport mechanism. Currently, netlink is the only implemented
> transport.

I wouldn't view this as an adequate changelog for this sort of work,
frankly.  Not by a long shot.  You've told us very briefly what the patches
do.  You haven't told us why they do it, nor how they do it.

What design decisions went into this?  What options were considered and
eliminated and why?  etc.

It's just a great lump of code dumped in our laps.


>From a quick scan (and I cannot review in more depth because the code is a
complete mystery to this reviewer):


> + mutex_init(_msg_ctx_lists_mux);
> + mutex_lock(_msg_ctx_lists_mux);

That's a bizarre thing to do.  If there's really any other process which
can take that mutex, the mutex_init() just trashed it.  If there is no
other such process, the mutex_lock() is unneeded.  There should never be
a need to runtime-initialise a static mutex - just use DEFINE_MUTEX.


ecryptfs now has a dependency upon netlink.  There's no CONFIG_NETLINK.  If
CONFIG_NET=n && CONFIG_ECRYPTFS=y is possible, it won't build.


-
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] Add retain_initrd boot option

[Michael Neuling]

Add retain_initrd option to control freeing of initrd memory after
extraction.  By default, free memory as previously. 

The first boot will need to hold a copy of the in memory fs for the
second boot.  This image can be large (much larger than the kernel),
hence we can save time when the memory loader is slow.  Also, it reduces
the memory footprint while extracting the first boot since you don't
need another copy of the fs.

Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
Updated to work when CONFIG_KEXEC=n, as spotted by Randy Dunlap.

 Documentation/kernel-parameters.txt |2 ++
 init/initramfs.c|   17 -
 2 files changed, 18 insertions(+), 1 deletion(-)

Index: linux-2.6-ozlabs/Documentation/kernel-parameters.txt
===
--- linux-2.6-ozlabs.orig/Documentation/kernel-parameters.txt
+++ linux-2.6-ozlabs/Documentation/kernel-parameters.txt
@@ -1366,6 +1366,8 @@ and is between 256 and 4096 characters. 
resume= [SWSUSP]
Specify the partition device for software suspend
 
+   retain_initrd   [RAM] Keep initrd memory after extraction
+
rhash_entries=  [KNL,NET]
Set number of hash buckets for route cache
 
Index: linux-2.6-ozlabs/init/initramfs.c
===
--- linux-2.6-ozlabs.orig/init/initramfs.c
+++ linux-2.6-ozlabs/init/initramfs.c
@@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
return message;
 }
 
+static int do_retain_initrd;
+
+static int __init retain_initrd_param(char *str)
+{
+   if (*str)
+   return 0;
+   do_retain_initrd = 1;
+   return 1;
+}
+__setup("retain_initrd", retain_initrd_param);
+
 extern char __initramfs_start[], __initramfs_end[];
 #ifdef CONFIG_BLK_DEV_INITRD
 #include 
@@ -497,7 +508,11 @@ static void __init free_initrd(void)
 #ifdef CONFIG_KEXEC
unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
unsigned long crashk_end   = (unsigned long)__va(crashk_res.end);
+#endif
+   if (do_retain_initrd)
+   goto skip;
 
+#ifdef CONFIG_KEXEC
/*
 * If the initrd region is overlapped with crashkernel reserved region,
 * free only memory that is not part of crashkernel region.
@@ -515,7 +530,7 @@ static void __init free_initrd(void)
} else
 #endif
free_initrd_mem(initrd_start, initrd_end);
-
+skip:
initrd_start = 0;
initrd_end = 0;
 }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Add retain_initrd boot option

[Michael Neuling]

> > -#ifdef CONFIG_KEXEC
> > unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
> > unsigned long crashk_end   = (unsigned long)__va(crashk_res.end);
> 
> I'm still not seeing how using crashk_res is valid here when
> CONFIG_KEXEC=n.  Can you explain that, please?
> You did test this with KEXEC=y and KEXEC=n, right?

Yeah, you'd think I would but apparently not.  Sorry, re-sending.

Mikey
-
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/

Kernel 2.6 SMP very slow with ServerWorks LE Chipset

[Bob]

Hi I have a dual PIII Motherboard based on a ServerWorks LE chipset,
the motherboard is from an HP Netserver E 800 which is a customised 
ASUS CUR-DLS.


in UP config everything is OK in SMP the system slows right down, 
I've been searching and recompiling my kernel for days looking for 
the problem option without success, please help.


I'm using Sarge and I've tried the precompiled kernel 2.6.8-3-686-smp 
and 2.6.18.2 from Sid and I've downloaded and compiled the sources 
for 2.6.18 and 2.6.19 in dozens of different permutations, all with the 
same result that the system crawls, I've seen other people have the 
same problem but no fixes. (there are more)

http://forums.whirlpool.net.au/forum-replies.cfm?t=565813

As a test of raw CPU power I've been decompressing the kernel tree, with 
a UP 2.6 kernel this takes about 1m 15s, I don't know if bz2 is 
multithreaded but even if it's not I would expect a slight speed increase 
but in fact with a SMP 2.6 kernel it take 13 ~ 26m, with a SMP 2.4 
kernel it takes 1m 28s and with a 2.4 UP 1m 35s. 

Below is some useful output, the hdpram -tT examples below are 
under the smp kernel, the same commands under a uniprocessor 
kernel yeld fairly consistent results around

Timing cached reads:   744 MB in  2.01 seconds = 370.35 MB/sec
Timing buffered disk reads:  222 MB in  3.02 seconds =  73.48 MB/sec

I'm sorry this is so long but I'm trying to include all the relevant info,
any help greatly appreciated, I'm not subscribed but I lurk on Usenet.

Thank you

nas:~# uname -a
Linux nas 2.6.18.1.smp.1.0.HP_E800_SMP #1 SMP Thu Nov 16 15:26:09 SGT 2006 i686 
GNU/Linux

nas:~# hdparm -tT /dev/hda

/dev/hda:
Timing cached reads:   740 MB in  2.01 seconds = 369.02 MB/sec
Timing buffered disk reads:   10 MB in  3.32 seconds =   3.01 MB/sec
nas:~# hdparm -tT /dev/sda

/dev/sda:
Timing cached reads:   744 MB in  2.01 seconds = 370.35 MB/sec
Timing buffered disk reads:   32 MB in  3.14 seconds =  10.21 MB/sec
nas:~# hdparm -tT /dev/sdb

/dev/sdb:
Timing cached reads:40 MB in  2.17 seconds =  18.43 MB/sec
Timing buffered disk reads:   10 MB in  3.15 seconds =   3.18 MB/sec
nas:~# hdparm -tT /dev/sdc

/dev/sdc:
Timing cached reads:36 MB in  2.01 seconds =  17.91 MB/sec
Timing buffered disk reads:   66 MB in  3.02 seconds =  21.88 MB/sec

###
nas:~# lspci
:00:00.0 Host bridge: ServerWorks CNB20LE Host Bridge (rev 06)
:00:00.1 Host bridge: ServerWorks CNB20LE Host Bridge (rev 06)
:00:02.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 
08)
:00:04.0 Ethernet controller: Intel Corp.: Unknown device 107c (rev 05)
:00:05.0 Unknown mass storage controller: Silicon Image, Inc. (formerly CMD 
Technology Inc) PCI0680 Ultra ATA-133 Host Controller (rev 02)
:00:07.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
:00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 50)
:00:0f.1 IDE interface: ServerWorks OSB4 IDE Controller
:00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller (rev 04)
:05:02.0 Unknown mass storage controller: Silicon Image, Inc. (formerly CMD 
Technology Inc): Unknown device 3124 (rev 01)
:05:05.0 SCSI storage controller: LSI Logic / Symbios Logic 53C896/897 (rev 
07)
:05:05.1 SCSI storage controller: LSI Logic / Symbios Logic 53C896/897 (rev 
07)

###
nas:~# cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 8
model name  : Pentium III (Coppermine)
stepping: 3
cpu MHz : 666.711
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 mmx fxsr sse
bogomips: 1334.30

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 8
model name  : Pentium III (Coppermine)
stepping: 3
cpu MHz : 666.711
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 mmx fxsr sse
bogomips: 1334.52

###
nas:~# cat /proc/interrupts
  CPU0   CPU1
 0: 169863 161890IO-APIC-edge  timer
 1:  8  1IO-APIC-edge  i8042
 2:  0  0  XT-PIC  cascade
12:102  1IO-APIC-edge  i8042
129:   1426  1   IO-APIC-level  eth0
137:   4818434   

workqueue cmpxchg() breakage

[Paul Mundt]

The changes in 365970a1ea76d81cb1ad2f652acb605f06dae256 result in
cmpxchg() being invoked with bogus sizes with gcc-4.1 on SH, particularly
when kernel/workqueue.c:set_wq_data() is left inlined:

  LD  .tmp_vmlinux1
kernel/built-in.o: In function `__cmpxchg':
/home/pmundt/devel/git/sh-2.6/include/asm/system.h:247: undefined reference to 
`__cmpxchg_called_with_bad_pointer'
make: *** [.tmp_vmlinux1] Error 1

If I add a handler for the u64 case, that catches one of the inlined
references, but the other call site generates something completely different,
it's garbage in either case.

Taking set_wq_data() out of line fixes this, but is likely not the right fix.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Add retain_initrd boot option

[Randy Dunlap]

Michael Neuling wrote:

Add retain_initrd option to control freeing of initrd memory after
extraction.  By default, free memory as previously. 


The first boot will need to hold a copy of the in memory fs for the
second boot.  This image can be large (much larger than the kernel),
hence we can save time when the memory loader is slow.  Also, it reduces
the memory footprint while extracting the first boot since you don't
need another copy of the fs.

Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
Removed unnecessary init of do_retain_initrd as suggested by Randy
Dunlap.

 Documentation/kernel-parameters.txt |2 ++
 init/initramfs.c|   18 --
 2 files changed, 18 insertions(+), 2 deletions(-)

Index: linux-2.6-ozlabs/Documentation/kernel-parameters.txt
===
--- linux-2.6-ozlabs.orig/Documentation/kernel-parameters.txt
+++ linux-2.6-ozlabs/Documentation/kernel-parameters.txt
@@ -1366,6 +1366,8 @@ and is between 256 and 4096 characters. 
 	resume=		[SWSUSP]

Specify the partition device for software suspend
 
+	retain_initrd	[RAM] Keep initrd memory after extraction

+
rhash_entries=  [KNL,NET]
Set number of hash buckets for route cache
 
Index: linux-2.6-ozlabs/init/initramfs.c

===
--- linux-2.6-ozlabs.orig/init/initramfs.c
+++ linux-2.6-ozlabs/init/initramfs.c
@@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
return message;
 }
 
+static int do_retain_initrd;

+
+static int __init retain_initrd_param(char *str)
+{
+   if (*str)
+   return 0;
+   do_retain_initrd = 1;
+   return 1;
+}
+__setup("retain_initrd", retain_initrd_param);
+
 extern char __initramfs_start[], __initramfs_end[];
 #ifdef CONFIG_BLK_DEV_INITRD
 #include 
@@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
 
 static void __init free_initrd(void)

 {
-#ifdef CONFIG_KEXEC
unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
unsigned long crashk_end   = (unsigned long)__va(crashk_res.end);


I'm still not seeing how using crashk_res is valid here when
CONFIG_KEXEC=n.  Can you explain that, please?
You did test this with KEXEC=y and KEXEC=n, right?


+   if (do_retain_initrd)
+   goto skip;
+
+#ifdef CONFIG_KEXEC
/*
 * If the initrd region is overlapped with crashkernel reserved region,
 * free only memory that is not part of crashkernel region.
@@ -515,7 +529,7 @@ static void __init free_initrd(void)
} else
 #endif
free_initrd_mem(initrd_start, initrd_end);
-
+skip:
initrd_start = 0;
initrd_end = 0;
 }



--
~Randy
-
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: vmscan.c:196: bad pmd (kernel 2.4.25)

[Willy Tarreau]

Hi,

On Wed, Dec 06, 2006 at 09:22:29AM +0100, Jesper Juhl wrote:
> The following messages just showed up in dmesg on one of my servers.
> The server seems to be running fine but I would like to know if
> there's a real problem here or if the message is just noise.
>
> The server is running 2.4.25
> 
> vmscan.c:196: bad pmd 01e3.
> vmscan.c:196: bad pmd 004001e3.
...
> vmscan.c:196: bad pmd 378001e3.
> vmscan.c:196: bad pmd 37c001e3.

I may be wrong, but to me it looks either like memory corruption
affecting one pgd, and by extension all of its pmds, or an old
bug in 2.4.25, but I don't recall seeing such a thing.

Anyway, I would personally reboot the server after such a thing, as I
really don't like it when VM is going mad.

Regards,
Willy

-
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] Add retain_initrd boot option

[Michael Neuling]

Add retain_initrd option to control freeing of initrd memory after
extraction.  By default, free memory as previously. 

The first boot will need to hold a copy of the in memory fs for the
second boot.  This image can be large (much larger than the kernel),
hence we can save time when the memory loader is slow.  Also, it reduces
the memory footprint while extracting the first boot since you don't
need another copy of the fs.

Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
Removed unnecessary init of do_retain_initrd as suggested by Randy
Dunlap.

 Documentation/kernel-parameters.txt |2 ++
 init/initramfs.c|   18 --
 2 files changed, 18 insertions(+), 2 deletions(-)

Index: linux-2.6-ozlabs/Documentation/kernel-parameters.txt
===
--- linux-2.6-ozlabs.orig/Documentation/kernel-parameters.txt
+++ linux-2.6-ozlabs/Documentation/kernel-parameters.txt
@@ -1366,6 +1366,8 @@ and is between 256 and 4096 characters. 
resume= [SWSUSP]
Specify the partition device for software suspend
 
+   retain_initrd   [RAM] Keep initrd memory after extraction
+
rhash_entries=  [KNL,NET]
Set number of hash buckets for route cache
 
Index: linux-2.6-ozlabs/init/initramfs.c
===
--- linux-2.6-ozlabs.orig/init/initramfs.c
+++ linux-2.6-ozlabs/init/initramfs.c
@@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
return message;
 }
 
+static int do_retain_initrd;
+
+static int __init retain_initrd_param(char *str)
+{
+   if (*str)
+   return 0;
+   do_retain_initrd = 1;
+   return 1;
+}
+__setup("retain_initrd", retain_initrd_param);
+
 extern char __initramfs_start[], __initramfs_end[];
 #ifdef CONFIG_BLK_DEV_INITRD
 #include 
@@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
 
 static void __init free_initrd(void)
 {
-#ifdef CONFIG_KEXEC
unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
unsigned long crashk_end   = (unsigned long)__va(crashk_res.end);
 
+   if (do_retain_initrd)
+   goto skip;
+
+#ifdef CONFIG_KEXEC
/*
 * If the initrd region is overlapped with crashkernel reserved region,
 * free only memory that is not part of crashkernel region.
@@ -515,7 +529,7 @@ static void __init free_initrd(void)
} else
 #endif
free_initrd_mem(initrd_start, initrd_end);
-
+skip:
initrd_start = 0;
initrd_end = 0;
 }
-
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] usb/hid: The HID Simple Driver Interface 0.4.1 (core)

[Liyu]

Jiri Kosina wrote:
> Do you think that you could wait a little bit more, after the split has 
> been done? (it's currently planned approximately after 2.6.20-rc1). It 
> seems to me that your patches will apply almost cleanly on top of the 
> split patches (you will have to change the pathnames, of course).  
Of course, I interest to wait this. If they have other weakless, tell me
too.
I also think the HID split plan is a great idea.

Dmitry wrote:
> I still have the same objection - the "simple'" code will have to be
> compiled into the driver instead of being a separate module and
> eventyally will lead to a monster-size HID module. We have this issue
> with psmouse to a degree but with HID the growth potential is much
> bigger IMO.

As you guess;), I do not agree with your words very much. We can image,
there
are many devices use some HID base layer, however they even do not merge
into
mainstream kernel source tree for some reasons. and in fact, I do not
like the
mainstream kernel source tree include every drivers. For such devices
out of core,
we should have such feature that let developer write such driver
quickly. I think
it allows many monster-size driver modules is a better means than
all-in-one.But we
need resolve /dev/input/event? switching problem in principle first,
else we still
encounter same problem when new hidraw come.

Good luck.

-Li Yu
www.co-create.com.cn

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] x86: remove duplicated parser for "pci=noacpi"

[Sergio Monteiro Basto]

On Sun, 2006-11-26 at 15:23 -0800, Yinghai Lu wrote:
[PATCH 2/3] x86: remove duplicated parser for "pci=noacpi" 

Remove "pci=noacpi" parse in acpi/boot.c, because it is duplicated 
with that in pci/common.c.

Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>

diff --git a/arch/i386/kernel/acpi/boot.c b/arch/i386/kernel/acpi/boot.c
index d12fb97..6d62dd1 100644
--- a/arch/i386/kernel/acpi/boot.c
+++ b/arch/i386/kernel/acpi/boot.c
@@ -1285,15 +1293,6 @@ static int __init parse_acpi(char *arg)
 }
 early_param("acpi", parse_acpi);
 
-/* FIXME: Using pci= for an ACPI parameter is a travesty. */
-static int __init parse_pci(char *arg)
-{
-   if (arg && strcmp(arg, "noacpi") == 0)
-   acpi_disable_pci();
-   return 0;
-}
-early_param("pci", parse_pci);
-
 #ifdef CONFIG_X86_IO_APIC
 static int __init parse_acpi_skip_timer_override(char *arg)
 {
diff --git a/arch/i386/pci/common.c b/arch/i386/pci/common.c
index cdfcf97..6d5b70a 100644
--- a/arch/i386/pci/common.c
+++ b/arch/i386/pci/common.c
@@ -294,7 +294,7 @@ char * __devinit  pcibios_setup(char *str)
}
 #endif
else if (!strcmp(str, "noacpi")) {
-   acpi_noirq_set();
+   acpi_disable_pci();
return NULL;
}
else if (!strcmp(str, "noearly")) {


/include/asm-x86_64/acpi.h (and asm-i386)
acpi_disable_pci : 

#ifdef CONFIG_ACPI
static inline void acpi_noirq_set(void) { acpi_noirq = 1; }
static inline void acpi_disable_pci(void)
{
acpi_pci_disabled = 1;
acpi_noirq_set();
}
#else   /* !CONFIG_ACPI */
#define acpi_ioapic 0
static inline void acpi_noirq_set(void) { }
static inline void acpi_disable_pci(void) { }

so first hunk of the patch doesn't have nothing in common with second ,
and it is different disable acpi_irqs than disable all acpi,
callacpi_disable_pci () is acpi=off.

My main goal when I read this mail was delete acpi=noirq or pci=noacpi
because is a redundant boot option which just make confusions.  

I have to go (sleep) 

Thanks,

-- 
Sérgio M.B.


smime.p7s
Description: S/MIME cryptographic signature

[git pull] DRM patches for 2.6.20

[Dave Airlie]

Hi Linus,

This tree has mainly driver updates for the i915 vblank + DRM drawable 
changes, along with some minor bugfixes.


Please pull from the 'drm-patches' branch:
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-patches
(or from master if the mirroring is still fubar..)

 drivers/char/drm/drm.h  |   33 
 drivers/char/drm/drmP.h |   23 +++
 drivers/char/drm/drm_bufs.c |   10 +
 drivers/char/drm/drm_core.h |8 +
 drivers/char/drm/drm_drawable.c |  294 ++-
 drivers/char/drm/drm_drv.c  |   14 ++
 drivers/char/drm/drm_irq.c  |  155 +
 drivers/char/drm/drm_lock.c |   11 +
 drivers/char/drm/drm_sman.c |1
 drivers/char/drm/drm_stub.c |2
 drivers/char/drm/drm_vm.c   |   16 ++
 drivers/char/drm/i915_dma.c |2
 drivers/char/drm/i915_drm.h |   19 +++
 drivers/char/drm/i915_drv.c |4 -
 drivers/char/drm/i915_drv.h |   22 +++
 drivers/char/drm/i915_irq.c |  265 ++-
 16 files changed, 822 insertions(+), 57 deletions(-)
commit d942625c2d5f5d29cd3bb4fad8a4aadd59024317
Author: Andrew Morton <[EMAIL PROTECTED]>
Date:   Thu Dec 7 16:11:44 2006 +1100

Fix http://bugzilla.kernel.org/show_bug.cgi?id=7606

WARNING: "drm_sman_set_manager" [drivers/char/drm/sis.ko] undefined!

Cc: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>

commit 3417f33e762bf7d4277031a655e3ad07e73ce0be
Author: George Sapountzis <[EMAIL PROTECTED]>
Date:   Tue Oct 24 12:03:04 2006 -0700

drm: add flag for mapping PCI DMA buffers read-only.

Add DRM_PCI_BUFFER_RO flag for mapping PCI DMA buffer read-only. An 
additional
flag is needed, since PCI DMA buffers do not have an associated map.

Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>

commit 5c2df2bfb121a77d925dba580f53da08b4020528
Author: Dave Airlie <[EMAIL PROTECTED]>
Date:   Tue Oct 24 11:36:59 2006 -0700

drm: fix up irqflags in drm_lock.c

Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>

commit 2228ed67223f3f22ea09df8854e6a31ea06d5619
Author: =?utf-8?q?Michel_D=C3=A4nzer?= <[EMAIL PROTECTED]>
Date:   Wed Oct 25 01:05:09 2006 +1000

drm: i915 updates

Add support for DRM_VBLANK_NEXTONMISS.
Bump minor for swap scheduling ioctl and secondary vblank support.
Avoid mis-counting vblank interrupts when they're only enabled for pipe A.
Only schedule vblank tasklet if there are scheduled swaps pending.

Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>

commit a0b136bb696cfa744a79c4dd0c8f9f30fe3f
Author: =?utf-8?q?Michel_D=C3=A4nzer?= <[EMAIL PROTECTED]>
Date:   Wed Oct 25 00:12:52 2006 +1000

drm: i915: fix up irqflags arg

Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>

commit 21fa60ed4eab5b3b28d05930bb086615ecc191b1
Author: =?utf-8?q?Michel_D=C3=A4nzer?= <[EMAIL PROTECTED]>
Date:   Wed Oct 25 00:10:59 2006 +1000

drm: i915: Only return EBUSY after we've established we need to schedule a 
new swap.

Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>

commit 2dbb232c4d6b6c89fc367f7566c7c87dd3b56cd7
Author: =?utf-8?q?Michel_D=C3=A4nzer?= <[EMAIL PROTECTED]>
Date:   Wed Oct 25 00:10:24 2006 +1000

drm: i915: Fix 'sequence has passed' condition in i915_vblank_swap().

Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>

commit 376642cf2eb0f32d8502b0a2c4efd96a3f13a8b8
Author: =?utf-8?q?Michel_D=C3=A4nzer?= <[EMAIL PROTECTED]>
Date:   Wed Oct 25 00:09:35 2006 +1000

drm: i915: Add SAREA fileds for determining which pipe to sync window 
buffer swaps to.

Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>

commit 5b51694aff705c465ef5941a99073036f3e444d9
Author: =?utf-8?q?Michel_D=C3=A4nzer?= <[EMAIL PROTECTED]>
Date:   Wed Oct 25 00:08:23 2006 +1000

drm: Make handling of dev_priv->vblank_pipe more robust.

Initialize it to default value if it hasn't been set by the X server yet.

In i915_vblank_pipe_set(), only update dev_priv->vblank_pipe and call
i915_enable_interrupt() if the argument passed from userspace is valid to 
avoid
corrupting dev_priv->vblank_pipe on invalid arguments.

Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>

commit 541f29aad766b6c7b911a7d900d952744369bf53
Author: =?utf-8?q?Michel_D=C3=A4nzer?= <[EMAIL PROTECTED]>
Date:   Tue Oct 24 23:38:54 2006 +1000

drm: DRM_I915_VBLANK_SWAP ioctl: Take drm_vblank_seq_type_t instead

of pipe number.

Handle relative as well as absolute target sequence numbers.

Return error if target sequence has already passed, so userspace can deal 
with
this situation as it sees fit.

On success, return the sequence number of the vertical blank when the buffer
swap is expected to take place.

Also add DRM_IOCTL_I915_VBLANK_SWAP definition for userspace code that may 
want
to use ioctl() instead of drmCommandWriteRead().

Re: [PATCH] usb/hid: The HID Simple Driver Interface 0.4.1 (core)

[Greg KH]

On Wed, Dec 06, 2006 at 04:18:37PM +0100, Marcel Holtmann wrote:
> Hi Dmitry,
> 
> > > > > I still have the same objection - the "simple'" code will have to be
> > > > > compiled into the driver instead of being a separate module and
> > > > > eventyally will lead to a monster-size HID module. We have this issue
> > > > > with psmouse to a degree but with HID the growth potential is much
> > > > > bigger IMO.
> > >
> > > I guess that this paragraph wasn't for me, but rather for the author of
> > > the HID Simple Driver proposal, am I right?
> > 
> > Yes, mainly for him but also for you because we need to be able to do
> > what Li Yu is trying to do and be able to tweak HID interfaces.
> > 
> > ...
> > 
> > > This split is quite painful, as there are many things happening in USB all
> > > the time, so the best way seem to be just to perform big split (with
> > > needed changes) at once, and then develop other things on top of it (like
> > > hidraw).
> > 
> > Is there any reason why we can't mecanically move everything into
> > drivers/hid right now? Then Greg could simply forward all patches he
> > gets for HID your way and you won't have hard time merging your work
> > with others...
> 
> I fully agree. Lets move and split the transports now and start the work
> on top of it. My only concern is to have a clean Git tree to the full
> history of HID changes stay intact and will trackable. Some quirk
> decisions and other stuff is not obvious and I assume will never be when
> it comes to broken HID devices.
> 
> So do you have pending HID patches. If yes, please sync them with Linus
> and Jiri can setup a clean tree for the move.

I have no pending HID patches in my queue right now.  Jiri, feel free to
respin your patches against Linus's tree and send them to me now.  I can
handle the git stuff and send them to Linus.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] free initrds boot option

[Randy Dunlap]

On Thu, 07 Dec 2006 14:42:57 +1100 Michael Neuling wrote:

> Index: linux-2.6-ozlabs/init/initramfs.c
> ===
> --- linux-2.6-ozlabs.orig/init/initramfs.c
> +++ linux-2.6-ozlabs/init/initramfs.c
> @@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
>   return message;
>  }
>  
> +static int do_retain_initrd = 0;

Don't init that to 0.  That's done for us and it's a bit
wasteful in the object file(s), so we try not to do that.


> +static int __init retain_initrd_param(char *str)
> +{
> + if (*str)
> + return 0;
> + do_retain_initrd = 1;
> + return 1;
> +}
> +__setup("retain_initrd", retain_initrd_param);

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6.19] drivers/media/video/cpia2/cpia2_usb.c: Free previously allocated memory (in array elements) if kmalloc() returns NULL.

[Amit Choudhary]

Description: Free previously allocated memory (in array elements) if kmalloc() 
returns NULL, in function submit_urbs(), in file 
drivers/media/video/cpia2/cpia2_usb.c. If the system is low on memory, then 
previously allocated memory in the same array should be freed up to help the 
system recover.

Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>

diff --git a/drivers/media/video/cpia2/cpia2_usb.c 
b/drivers/media/video/cpia2/cpia2_usb.c
index 28dc6a1..c938638 100644
--- a/drivers/media/video/cpia2/cpia2_usb.c
+++ b/drivers/media/video/cpia2/cpia2_usb.c
@@ -640,6 +640,10 @@ static int submit_urbs(struct camera_dat
cam->sbuf[i].data =
kmalloc(FRAMES_PER_DESC * FRAME_SIZE_PER_DESC, GFP_KERNEL);
if (!cam->sbuf[i].data) {
+   for (--i; i >= 0; i--) {
+   kfree(cam->sbuf[i].data);
+   cam->sbuf[i].data = NULL;
+   }
return -ENOMEM;
}
}
-
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] free initrds boot option

[Randy Dunlap]

On Thu, 07 Dec 2006 14:42:57 +1100 Michael Neuling wrote:

> Add retain_initrd option to control freeing of initrd memory after
> extraction.  By default, free memory as previously.
> 
> Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
> ---
> Updated based on comments from akpm.  
> Added documentation and changed option name to "retain_initrd"
> Tested on POWERPC with CPIOs
> 
>  Documentation/kernel-parameters.txt |2 ++
>  init/initramfs.c|   18 --
>  2 files changed, 18 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6-ozlabs/init/initramfs.c
> ===
> --- linux-2.6-ozlabs.orig/init/initramfs.c
> +++ linux-2.6-ozlabs/init/initramfs.c
> @@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
>   return message;
>  }
>  
> +static int do_retain_initrd = 0;
> +
> +static int __init retain_initrd_param(char *str)
> +{
> + if (*str)
> + return 0;
> + do_retain_initrd = 1;
> + return 1;
> +}
> +__setup("retain_initrd", retain_initrd_param);
> +
>  extern char __initramfs_start[], __initramfs_end[];
>  #ifdef CONFIG_BLK_DEV_INITRD
>  #include 
> @@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
>  
>  static void __init free_initrd(void)
>  {
> -#ifdef CONFIG_KEXEC
>   unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
>   unsigned long crashk_end   = (unsigned long)__va(crashk_res.end);

How does this work when CONFIG_KEXEC=n ??

Tested?

> + if (do_retain_initrd)
> + goto skip;
> +
> +#ifdef CONFIG_KEXEC
>   /*
>* If the initrd region is overlapped with crashkernel reserved region,
>* free only memory that is not part of crashkernel region.
> @@ -515,7 +529,7 @@ static void __init free_initrd(void)
>   } else
>  #endif
>   free_initrd_mem(initrd_start, initrd_end);
> -
> +skip:
>   initrd_start = 0;
>   initrd_end = 0;
>  }
> -

---
~Randy
-
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] ACPI, i686, x86_64: fix laptop bootup hang in init_acpi()

[Karsten Wiese]

Am Donnerstag, 7. Dezember 2006 03:28 schrieb Sergio Monteiro Basto:
> On Wed, 2006-12-06 at 23:30 +0100, Ingo Molnar wrote:
> > Subject: [patch] ACPI, i686, x86_64: fix laptop bootup hang in init_acpi()
> > From: Ingo Molnar <[EMAIL PROTECTED]>
> Hi Ingo,
> Just curiosity ,have we this patch on 2.6.19-1.rt6 ?

No, its in rt7.

  Karsten
-
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: Oops in pata_pdc2027x

[Albert Lee]

Stephen Rothwell wrote:
> Hi all,
> 
> I get an oops during initialisation of the pata_pdc2027x module on a
> POWER 285 machine.  This is on a very recent Linus kernel tree
> (ff51a98799931256b555446b2f5675db08de6229) with Paulus' powerpc tree
> (that has now been merged). The oops looks like this:
> 
> 
> Synthesizing the initial hotplug events...done.
> Waiting for /dev to be fully populated...pata_pdc2027x 0001:cc:01.0: PLL 
> input clock 32721 kHz
> ata1: PATA max UDMA/133 cmd 0xD800801457C0 ctl 0xD80080145FDA bmdma 
> 0xD80080145000 irq 324
> ata2: PATA max UDMA/133 cmd 0xD800801455C0 ctl 0xD80080145DDA bmdma 
> 0xD80080145008 irq 324
> scsi1 : pata_pdc2027x
> ata1.00: ATAPI, max UDMA/66
> Unable to handle kernel paging request for data at address 0xc001007e8d80
> Faulting instruction address: 0xd007b660
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=128 NUMA
> Modules linked in: pata_pdc2027x dm_mirror dm_snapshot ipr libata
> NIP: D007B660 LR: D007B628 CTR: 
> REGS: c000f4e3b5a0 TRAP: 0300   Not tainted  (2.6.19comb)
> MSR: 80009032   CR: 2480  XER: 2009
> DAR: C001007E8D80, DSISR: 4001
> TASK = c7001040[3393] 'scsi_eh_1' THREAD: c000f4e38000 CPU: 2
> GPR00: 0001 C000F4E3B820 D00A95C0 CFA946E8
> GPR04: C000F4E3B960  0003 C000F4E3B890
> GPR08: 0001 C07E8D80 D80080145110 C0033A34
> GPR12:  C056FF80  C04751C8
> GPR16: 41C0 C0473B90  0035D800
> GPR20: 0213AF30 C053AF30 C000F4E3BB10 0001
> GPR24: 0002  C000F4E3B960 CFA946E8
> GPR28: 0003 4000 D00A7980 
> NIP [D007B660] .ata_exec_internal+0x8c/0xf8 [libata]
> LR [D007B628] .ata_exec_internal+0x54/0xf8 [libata]
> Call Trace:
> [C000F4E3B820] [D00A7980] .ipr_store_update_fw+0x100/0x6f0 [ipr] 
> (unreliable)
> [C000F4E3B8F0] [D007C15C] .ata_set_mode+0x4dc/0x6d0 [libata]
> [C000F4E3B9D0] [D00860E0] .ata_do_eh+0x1538/0x1930 [libata]
> [C000F4E3BC20] [D0083774] .ata_bmdma_drive_eh+0x1f8/0x2e8 [libata]
> [C000F4E3BCD0] [D00C17B4] .pdc2027x_error_handler+0x28/0x40 
> [pata_pdc2027x]
> [C000F4E3BD50] [D0086DC0] .ata_scsi_error+0x32c/0x660 [libata]
> [C000F4E3BE00] [C0312F7C] .scsi_error_handler+0xc8/0x80c
> [C000F4E3BEE0] [C006A0F4] .kthread+0x124/0x174
> [C000F4E3BF90] [C0024D68] .kernel_thread+0x4c/0x68
> Instruction dump:
> 57ac053e e93e8020 7f63db78 7f44d378 780007c6 7f25cb78 7f86e378 38e10070
> 7fbd0214 3901 7ba0f860 78001f24 <7d69002a> 7ba0a302 7bbd4602 3920
>  done.
> 
> 
> (The reference to ipr_store_update_fw is certainly not real)
> 
> The config, lspci and full boot dmesg output are available at
> http://ozlabs.org/~sfr/{config,lspci,dmesg}
> 
> This machine has a only cdrom drive attached to the pdc controller.
> 

It seems the opps occurred in the ata_exec_internal(). Could you please
try the attached patch and see if the older ata_exec_internal() works?
This can help to narrow it down.

--
albert

--- pdc2027x_ozlab/drivers/ata/libata-core.c2006-12-06 15:01:13.0 
+0800
+++ exec_internal/drivers/ata/libata-core.c 2006-12-07 11:49:08.0 
+0800
@@ -1334,7 +1334,7 @@ unsigned ata_exec_internal_sg(struct ata
 }
 
 /**
- * ata_exec_internal_sg - execute libata internal command
+ * ata_exec_internal - execute libata internal command
  * @dev: Device to which the command is sent
  * @tf: Taskfile registers for the command and the result
  * @cdb: CDB for packet command
@@ -1342,8 +1342,11 @@ unsigned ata_exec_internal_sg(struct ata
  * @buf: Data buffer of the command
  * @buflen: Length of data buffer
  *
- * Wrapper around ata_exec_internal_sg() which takes simple
- * buffer instead of sg list.
+ * Executes libata internal command with timeout.  @tf contains
+ * command on entry and result on return.  Timeout and error
+ * conditions are reported via return value.  No recovery action
+ * is taken after a command times out.  It's caller's duty to
+ * clean up after timeout.
  *
  * LOCKING:
  * None.  Should be called with kernel context, might sleep.
@@ -1355,11 +1358,141 @@ unsigned ata_exec_internal(struct ata_de
   struct ata_taskfile *tf, const u8 *cdb,
   int dma_dir, void *buf, unsigned int buflen)
 {
-   struct scatterlist sg;
+   struct ata_port *ap = dev->ap;
+   u8 command = tf->command;

Re: [PATCH] free initrds boot option

[Haren Myneni]

Michael Neuling wrote:


Add free_initrd= option to control freeing of initrd memory after
extraction.  By default, free memory as previously.

Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
Useful for kexec when you want to reuse the same initrd.  Testing on
POWERPC with CPIOs
 

  
This option (free_initrd) will not work if the user loads the kdump 
kernel and does the normal kexec boot later on powerpc. The reason is 
initrd will be loaded by yaboot at 36MB and kdump image at 32M (Right 
now it is fixed). It could be possible that we will end up overwriting 
initrd.



init/initramfs.c |   18 --
1 file changed, 16 insertions(+), 2 deletions(-)

Index: linux-2.6-ozlabs/init/initramfs.c
===
--- linux-2.6-ozlabs.orig/init/initramfs.c
+++ linux-2.6-ozlabs/init/initramfs.c
@@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
return message;
}

+static int do_free_initrd = 1;
+
+int __init free_initrd_param(char *p)
+{
+   if (p && strncmp(p, "0", 1) == 0)
+   do_free_initrd = 0;
+
+   return 0;
+}
+early_param("free_initrd", free_initrd_param);
+
extern char __initramfs_start[], __initramfs_end[];
#ifdef CONFIG_BLK_DEV_INITRD
#include 
@@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr

static void __init free_initrd(void)
{
-#ifdef CONFIG_KEXEC
unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
unsigned long crashk_end   = (unsigned long)__va(crashk_res.end);

+   if (!do_free_initrd)
+   goto skip;
+
+#ifdef CONFIG_KEXEC
/*
 * If the initrd region is overlapped with crashkernel reserved region,
 * free only memory that is not part of crashkernel region.
@@ -515,7 +529,7 @@ static void __init free_initrd(void)
} else
#endif
free_initrd_mem(initrd_start, initrd_end);
-
+skip:
initrd_start = 0;
initrd_end = 0;
}
-
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/
 



-
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/5] Update Documentation/pci.txt

[Grant Grundler]

On Tue, Dec 05, 2006 at 11:26:51PM -0800, Greg KH wrote:
> > If this looks good, I'll post a diff for gregkh.
> 
> This looks very good, thanks for doing this work.

welcome - feels like the most significant contribution I've made
to kernel in a long time.

> I do have a few minor comments:

I'll fix up the comments and post a diff in a few days.
Try to answer your questions below.

...
> > save_state  Save a device's state before it is suspended.
> 
> There is no such callback.  We have "suspend", "suspend_late",
> "resume_early", and "resume".  You might want to update this.

I'll review all the callbacks and verify we aren't missing any too.
Definitely want to update this. I'll add them but ask someone
else whose used those entry points rewrite my crap with a
seperate patch. I don't want to rathole on this patch.


...
> > driver_data Data private to the driver.
> > Most drivers don't need to use driver_data field.
> > Best practice is to use driver_data as an index
> > into a static list of equivalent device types,
> > instead of using it as a pointer.
> 
> Perhaps mention the PCI_DEVICE() and PCI_DEVICE_CLASS() macros to set
> these fields properly?

Yes. Will add that.

> > Have a table entry {PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID}
> 
> PCI_DEVICE(PCI_ANY_ID, PCI_ANY_ID) is a bit smaller :)

ditto.

> > All fields are passed in as hexadecimal values (no leading 0x).
> > Users need pass only as many fields as necessary:
> > ovendor, device, subvendor, and subdevice fields default
> > to PCI_ANY_ID (),
> > oclass and classmask fields default to 0
> > odriver_data defaults to 0UL.
> 
> What's with the "o"s here?

Those are supposed to be bullets.

Cute Story: I lost the first blank space on _every_ line when I messed up
my attempt to remove trailing whitespace in vi with ":1,$ s/ *//".
I left out the "$". :(
I didn't realize the mistake until a few minutes later and had to
hand edit every line to fix it up again. *ouch*
Lesson is to be more careful and save state before making global changes.



> 
> > Once added, the driver probe routine will be invoked for any unclaimed
> > PCI devices listed in its (newly updated) pci_ids list.
> > 
> > Device drivers must initialize use_driver_data in the dynids struct
> > in their pci_driver struct prior to calling pci_register_driver in order
> > for the driver_data field to get passed to the driver. Otherwise, only a
> > 0 (zero) is passed in that field.
> 
> Note that _no one_ uses this field, so it might go away soon...

When it's removed, the patch can remove that paragraph.
This is a seperate issue.


...
> > o If the driver is not a hotplug driver then use only
> >   __init/__exit and __initdata/__exitdata.
> 
> No, don't say this, pci drivers are not "hotplug drivers", and since
> CONFIG_HOTPLUG is really hard to turn off these days, don't confuse
> people with the devinit stuff.  Everyone gets it wrong...

Yeah. I'll drop the "is not a hotplug driver" bullet item.

> > o Pointers to functions marked as __devexit must be created using
> >   __devexit_p(function_name).  That will generate the function
> >   name or NULL if the __devexit function will be discarded.
> 
> I really recommend just not using any of these for almost all PCI
> drivers, as the space savings just really isn't there...

Ok.  fgrep found 321 instances of __devexit_p and thus I think we should
document it's use at a minimum. I'll just add "Most PCI drivers don't need
to use __devexit."

thanks for the comments!
Expect the next rev this weekend sometime.

grant
-
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] free initrds boot option

[Michael Neuling]

Add retain_initrd option to control freeing of initrd memory after
extraction.  By default, free memory as previously.

Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
Updated based on comments from akpm.  
Added documentation and changed option name to "retain_initrd"
Tested on POWERPC with CPIOs

 Documentation/kernel-parameters.txt |2 ++
 init/initramfs.c|   18 --
 2 files changed, 18 insertions(+), 2 deletions(-)

Index: linux-2.6-ozlabs/Documentation/kernel-parameters.txt
===
--- linux-2.6-ozlabs.orig/Documentation/kernel-parameters.txt
+++ linux-2.6-ozlabs/Documentation/kernel-parameters.txt
@@ -1366,6 +1366,8 @@ and is between 256 and 4096 characters. 
resume= [SWSUSP]
Specify the partition device for software suspend
 
+   retain_initrd   [RAM] Keep initrd memory after extraction
+
rhash_entries=  [KNL,NET]
Set number of hash buckets for route cache
 
Index: linux-2.6-ozlabs/init/initramfs.c
===
--- linux-2.6-ozlabs.orig/init/initramfs.c
+++ linux-2.6-ozlabs/init/initramfs.c
@@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
return message;
 }
 
+static int do_retain_initrd = 0;
+
+static int __init retain_initrd_param(char *str)
+{
+   if (*str)
+   return 0;
+   do_retain_initrd = 1;
+   return 1;
+}
+__setup("retain_initrd", retain_initrd_param);
+
 extern char __initramfs_start[], __initramfs_end[];
 #ifdef CONFIG_BLK_DEV_INITRD
 #include 
@@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
 
 static void __init free_initrd(void)
 {
-#ifdef CONFIG_KEXEC
unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
unsigned long crashk_end   = (unsigned long)__va(crashk_res.end);
 
+   if (do_retain_initrd)
+   goto skip;
+
+#ifdef CONFIG_KEXEC
/*
 * If the initrd region is overlapped with crashkernel reserved region,
 * free only memory that is not part of crashkernel region.
@@ -515,7 +529,7 @@ static void __init free_initrd(void)
} else
 #endif
free_initrd_mem(initrd_start, initrd_end);
-
+skip:
initrd_start = 0;
initrd_end = 0;
 }
-
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] free initrds boot option

[Michael Neuling]

> I would have to agree with this; it also seems a bit odd to me to have
> this at all (kexec provides a new kernel image, surely it also
> provides a new initrd image???)

The first boot will need to hold a copy of the in memory fs for the
second boot.  This image can be large (much larger than the kernel),
hence we can save time when the memory loader is slow.  Also, it reduces
the memory footprint while extracting the first boot since you don't
need another copy of the fs.

New patch on it's way.  

Mikey
-
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 2/2] x86_64: earlyprintk usb debug device support.

[Lu, Yinghai]

Greg,

I wonder why the netconsole could print all boot log from beginning with
buffer. But your usb serial console can not.

YH


-
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: Areca driver 2.6.19 on x86_64

[Areca Support]

Dear Sir,

This is Kevin Wang from Areca Technology, Tech-Support Team.
regarding your problem, please trying to disable ACPI in kernel loader.
if the problem happen as soon as driver loaded, it should be the IRQ
releated issue.
the motherboard bios didn't assigned a correct IRQ to controller, it makes
the driver can't initialize controller.
and in our experience, disable ACPI in kernel loader can solved this ussue
in some distro.


Best Regards,


Kevin Wang

Areca Technology Tech-support Division
Tel : 886-2-87974060 Ext. 223
Fax : 886-2-87975970
Http://www.areca.com.tw
Ftp://ftp.areca.com.tw

- Original Message - 
From: "Bron Gondwana" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; ;
<[EMAIL PROTECTED]>
Sent: Thursday, December 07, 2006 7:09 AM
Subject: Re: Areca driver 2.6.19 on x86_64


> On Wed, Dec 06, 2006 at 05:51:32PM +0100, [EMAIL PROTECTED] wrote:
> > OS distro used:
> > CentOS 4.4 x86_64
> > Kernel 2.6.19 with hand-crafted config, that we are
> > able to use successfully with kernel 2.6.16.20.
>
> What patches were you applying to 2.6.16.20, since that didn't
> have an Areca driver in it I presume you're at least using that.
>
> > Have you any suggestions to resolve this issue ?
>
> 32 bit kernel?  I'm somewhat serious here, depending what applications
> you're running on the machine.
>
> Otherwise, no clue sorry - we're running 32 bit kernels everywhere
> even on the couple of new Core machines we have.
>
> Bron.

-
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] ACPI, i686, x86_64: fix laptop bootup hang in init_acpi()

[Sergio Monteiro Basto]

On Wed, 2006-12-06 at 23:30 +0100, Ingo Molnar wrote:
> Subject: [patch] ACPI, i686, x86_64: fix laptop bootup hang in init_acpi()
> From: Ingo Molnar <[EMAIL PROTECTED]>
Hi Ingo,
Just curiosity ,have we this patch on 2.6.19-1.rt6 ?

Thanks,
-- 
Sérgio M.B.


smime.p7s
Description: S/MIME cryptographic signature

Re: [GIT] Please pull the NFS client update for 2.6.19

[Linus Torvalds]

On Wed, 6 Dec 2006, Trond Myklebust wrote:
> 
> Hmm... Have the workqueue updates been pushed out yet? I can't seem to
> pull them from git.kernel.org.

The kernel.org mirroring has been really flaky lately.

If you have an account, you can use master.kernel.org to get things 
without mirroring delays.

And if not, I'd be happy to push to other places too, but the reason 
kernel.org tends to occasionally get slow at mirroring is probably because 
it does get a lot of traffic. So..

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: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it

[Douglas McNaught]

Matthew Wilcox <[EMAIL PROTECTED]> writes:

> On Wed, Dec 06, 2006 at 05:36:29PM -0800, Linus Torvalds wrote:
>> Or are you saying that gcc aligns normal 32-bit entities at 
>> 16-bit alignment? Neither of those sound very likely.
>
> alignof(u32) is 2 on m68k.  Crazy, huh?

The original 68000 had a 16-bit bus (but 32-bit registers), which is
probably why it's that way.

-Doug
-
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] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it

[Roman Zippel]

Hi,

On Wed, 6 Dec 2006, Linus Torvalds wrote:

> > m68060 produces a trap for unaligned atomic access, unfortunately standard 
> > alignment is smaller than this.
> 
> Umm. on 68060, since it's 32-bit, you'd only have the 32-bit case. Are you 
> saying that you can't do a 32-bit atomic access at any 32-bit aligned 
> boundary? Or are you saying that gcc aligns normal 32-bit entities at 
> 16-bit alignment? Neither of those sound very likely.

The latter.
And yes, I'm starting to hate it too, especially after I've seen all the 
weird bugs this causes in userspace, which then only trigger on m68k.
I'm thinking of changing it when switching to proper TLS support, but it's 
not there yet.
BTW there is another reason I actually like the atomic type - 
documentation. It makes it more clear that this intended to be used as 
atomic value, so an unhealthy mixture of different accesses is less likely 
and if they pile up at some place it's a good indicator to maybe switch 
back to spinlocks.

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: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

[David Brownell]

On Wednesday 06 December 2006 1:24 pm, Andi Kleen wrote:
> >   - Host, to which that console connects (through the debug device);
> > runs usb_debug, much like any other usb-serial device
> 
> My understanding was that the client could run in user 
> space only on top of libusb.

I suppose it could, if you didn't want to use it like a normal
serial consoe.


> > It's analagous to debugging an embedded box using a serial console
> > with a Linux host ... except the target here is a PC, not an ARM
> > (or PPC, MIPS, etc) custom board.
> > 
> > 
> > Once the coexistence issues between the debug port and normal EHCI
> > driver get worked, there's no reason not to keep using that debug
> > port as a system console.  
> 
> One reason is the one I covered in my last mail -- locking of the PCI
> type 1 ports.

That'd be part of coexistence.  The debug port is _designed_ to share
two different drivers like that ... EHCI can see, as it comes up,
whether the debug port is in use, and could then ignore it.  (At least,
unless/until the debug device gets removed.)

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Bulk] Re: [patch 2.6.19-rc6] fix hotplug for legacy platform drivers

[David Brownell]

> > First, for reference, I refer to hotplugging using the trivial ASH scripts
> > from [1], updated by removing no-longer-needed special cases for 
> > platform_bus
> > (that original logic didn't work sometimes) and pcmcia. ...
> 
> Ah, so for the platform devices, doing a
>   modprobe /sys/devices/platform/*
> would load all of the proper modules for the specific platform devices
> that are already present due to the MODULE_ALIAS() stuff?

That's sort of how that original "coldplug" script worked, but it didn't
work except in some trivial cases.  For example, it fails in a common case
when platform_device.id != -1; and for platform devices that are children
of other devices.  And of course there's the syntax issue ... only one
module name at a time (so modprobe in a loop).

The MODULE_ALIAS() stuff only kicks in when the driver name isn't the
same as its module name.  Normally, developers just stick to one name.


> > That should make it clear how accepting that pushback would break hotplug:
> > "modprobe $MODALIAS" would no longer load the right module.  Likewise
> > the more significant case of coldplug; "modprobe $(cat modalias)" would
> > likewise no longer work.
> 
> But, I don't understand why a module would have an alias with the same
> name as itself?  What is that achieving here?  Shouldn't redundancy like
> that be eliminated?

To repeat, I am _not_ the one who has made that proposal.  I'm the one
pointing out that all names for a module (aliases vs. what "ls" shows)
should be treated the same ... introducing a new rule about how hotplug
(or coldplug) must only refer to aliases promotes fragility.


> > The $SUBJECT patch makes those legacy drivers NOT use the $MODALIAS
> > mechanism ... you seem to be overlooking that.
> 
> No, I'm not overlooking that, I think it's a good thing.  I'm just
> wondering if it could be done a different way.  Perhaps in the platform
> device itself instead of the driver core code?

Marco was overlooking it.

I thought about moving that bit elsewhere, but three things came to mind:

 * Space-wise, there are already unused bits there, so this is free;
   but there are no such bits in platform_device.

 * Given that this is a "legacy style" issue, not all such driver
   code is (or will be) on the platform bus.

 * Hey, not all devices and busses support hotplugging, and it'd be
   worth having discussion on that.  The flag is explicitly about
   the _driver_ not supporting hotplug ... a device node creation
   problem.  When the _device_ is physically not hotpluggable, a
   different approach might help rid the kernel of probe()/remove()
   infrastructure.

Given those points, I thought this was probably the best place to
put it; at least as an initial proposal.

Another proposal, which I dislike, is just not to have platform_bus
do hotplug (via $MODALIAS).  That'd be OK for some current embedded
systems, since the devices get created during board startup and are
not added/removed later, but that's exactly the sort of idiosyncratic
restriction I've observed will invariably cause pain later on.  It's
too easy to think of counterexamples, like devices appearing when a
board gets powered up.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 2.6.19-git] RTC Kconfig sorted by type

[David Brownell]

This reorders the RTC driver menu into separate sections, splitting out
the SOC, I2C, and SPI support to help make the menu easier to navigate.
(We got some feedback a while ago that it was "a mess" and hard to make
sense of...)

Signed-off-by: David Brownell <[EMAIL PROTECTED]>

---
Assumes the rtc-omap patch has been merged, and no other RTC drivers
have been added to this Kconfig menu.

Index: at91/drivers/rtc/Kconfig
===
--- at91.orig/drivers/rtc/Kconfig   2006-12-05 03:25:20.0 -0800
+++ at91/drivers/rtc/Kconfig2006-12-05 03:46:53.0 -0800
@@ -1,4 +1,4 @@
-\#
+#
 # RTC class/drivers configuration
 #
 
@@ -20,6 +20,8 @@ config RTC_CLASS
  This driver can also be built as a module. If so, the module
  will be called rtc-class.
 
+if RTC_CLASS != n
+
 config RTC_HCTOSYS
bool "Set system time from RTC on startup"
depends on RTC_CLASS = y
@@ -45,11 +47,10 @@ config RTC_DEBUG
  and individual RTC drivers.
 
 comment "RTC interfaces"
-   depends on RTC_CLASS
 
 config RTC_INTF_SYSFS
tristate "sysfs"
-   depends on RTC_CLASS && SYSFS
+   depends on SYSFS
default RTC_CLASS
help
  Say yes here if you want to use your RTCs using sysfs interfaces,
@@ -60,7 +61,7 @@ config RTC_INTF_SYSFS
 
 config RTC_INTF_PROC
tristate "proc"
-   depends on RTC_CLASS && PROC_FS
+   depends on PROC_FS
default RTC_CLASS
help
  Say yes here if you want to use your first RTC through the proc
@@ -72,7 +73,6 @@ config RTC_INTF_PROC
 
 config RTC_INTF_DEV
tristate "dev"
-   depends on RTC_CLASS
default RTC_CLASS
help
  Say yes here if you want to use your RTCs using the /dev
@@ -92,129 +92,121 @@ config RTC_INTF_DEV_UIE_EMUL
  driver does not expose RTC_UIE ioctls.  Those requests generate
  once-per-second update interrupts, used for synchronization.
 
+##
+
 comment "RTC drivers"
-   depends on RTC_CLASS
 
-config RTC_DRV_X1205
-   tristate "Xicor/Intersil X1205"
-   depends on RTC_CLASS && I2C
+config RTC_DRV_DS1553
+   tristate "Dallas DS1553"
help
  If you say yes here you get support for the
- Xicor/Intersil X1205 RTC chip.
+ Dallas DS1553 timekeeping chip.
 
  This driver can also be built as a module. If so, the module
- will be called rtc-x1205.
+ will be called rtc-ds1553.
 
-config RTC_DRV_DS1307
-   tristate "Dallas/Maxim DS1307 and similar I2C RTC chips"
-   depends on RTC_CLASS && I2C
+config RTC_DRV_DS1742
+   tristate "Dallas DS1742"
help
- If you say yes here you get support for various compatible RTC
- chips (often with battery backup) connected with I2C.  This driver
- should handle DS1307, DS1337, DS1338, DS1339, DS1340, ST M41T00,
- and probably other chips.  In some cases the RTC must already
- have been initialized (by manufacturing or a bootloader).
-
- The first seven registers on these chips hold an RTC, and other
- registers may add features such as NVRAM, a trickle charger for
- the RTC/NVRAM backup power, and alarms.  This driver may not
- expose all those available chip features.
+ If you say yes here you get support for the
+ Dallas DS1742 timekeeping chip.
 
  This driver can also be built as a module. If so, the module
- will be called rtc-ds1307.
+ will be called rtc-ds1742.
 
-config RTC_DRV_DS1553
-   tristate "Dallas DS1553"
-   depends on RTC_CLASS
+config RTC_DRV_V3020
+   tristate "EM Microelectronic V3020"
help
- If you say yes here you get support for the
- Dallas DS1553 timekeeping chip.
+ If you say yes here you will get support for the
+ EM Microelectronic v3020 RTC chip.
 
  This driver can also be built as a module. If so, the module
- will be called rtc-ds1553.
+ will be called rtc-v3020.
 
-config RTC_DRV_ISL1208
-   tristate "Intersil 1208"
-   depends on RTC_CLASS && I2C
+config RTC_DRV_M48T86
+   tristate "ST M48T86/Dallas DS12887"
help
- If you say yes here you get support for the
- Intersil 1208 RTC chip.
+ If you say Y here you will get support for the
+ ST M48T86 and Dallas DS12887 RTC chips.
 
  This driver can also be built as a module. If so, the module
- will be called rtc-isl1208.
+ will be called rtc-m48t86.
 
-config RTC_DRV_DS1672
-   tristate "Dallas/Maxim DS1672"
-   depends on RTC_CLASS && I2C
+config RTC_DRV_TEST
+   tristate "Test driver/device"
help
  If you say yes here you get support for the
- Dallas/Maxim DS1672 timekeeping chip.
+ RTC test 

Re: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it

[Matthew Wilcox]

On Wed, Dec 06, 2006 at 05:36:29PM -0800, Linus Torvalds wrote:
> Or are you saying that gcc aligns normal 32-bit entities at 
> 16-bit alignment? Neither of those sound very likely.

alignof(u32) is 2 on m68k.  Crazy, huh?
-
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] Please pull the NFS client update for 2.6.19

[Trond Myklebust]

On Wed, 2006-12-06 at 20:34 -0500, Trond Myklebust wrote:
> On Wed, 2006-12-06 at 17:16 -0800, Linus Torvalds wrote:
> > 
> > On Wed, 6 Dec 2006, Trond Myklebust wrote:
> > > 
> > >git pull git://git.linux-nfs.org/pub/linux/nfs-2.6.git
> > > 
> > > This will update the following files through the appended changesets.
> > 
> > Well, right now it conflicts with the workqueue cleanups. Can you fix up 
> > the conflicts and push again? Quite frankly, I could try, but since I 
> > don't even run NFS, I _really_ don't think you want me to do so.
> 
> OK. I'll fix it up and resend.

Hmm... Have the workqueue updates been pushed out yet? I can't seem to
pull them from git.kernel.org.

Trond

-
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: Kernel panic at boot with recent pci quirks patch

[Frank Sorenson]

Remi Colinet wrote:

Frank Sorenson <[EMAIL PROTECTED]> wrote:


The latest -git tree panics at boot for me.  git-bisect traced the

offending commit to:

368c73d4f689dae0807d0a2aa74c61fd2b9b075f is first bad commit
commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f
Author: Alan Cox <[EMAIL PROTECTED]>
Date:   Wed Oct 4 00:41:26 2006 +0100

PCI: quirks: fix the festering mess that claims to handle IDE quirks

Hardware is a Dell Inspiron E1705 laptop running FC6 x86_64.



Could you try the following patch (already included in mm tree)?

http://www.uwsg.indiana.edu/hypermail/linux/kernel/0611.1/1568.html

Remi


Yes, that patch does seem to fix the problem.  Is it the right fix?

Frank

-
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 RFC] use of activate_mm in fs/aio.c:use_mm()?

[Jeremy Fitzhardinge]

Jeremy Fitzhardinge wrote:
> I'm wondering if activate_mm() is the right thing to be using in
> use_mm(); shouldn't this be switch_mm()?
>
> On normal x86, they're synonymous, but for the Xen patches I'm adding a
> hook which assumes that activate_mm is only used the first time a new mm
> is used after creation (I have another hook for dealing with dup_mm).  I
> think this use of activate_mm() is the only place where it could be used
> a second time on an mm.
>
> From a quick look at the other architectures I think this is OK (most
> simply implement one in terms of the other), but some are doing some
> subtly different stuff between the two.
>
> Thanks,
> J
>
>
>   
Er, lets try that again:

diff -r 455b71ed4525 fs/aio.c
--- a/fs/aio.c  Wed Dec 06 13:16:42 2006 -0800
+++ b/fs/aio.c  Wed Dec 06 17:17:43 2006 -0800
@@ -588,7 +588,7 @@ static void use_mm(struct mm_struct *mm)
 * Note that on UML this *requires* PF_BORROWED_MM to be set, otherwise
 * it won't work. Update it accordingly if you change it here
 */
-   activate_mm(active_mm, mm);
+   switch_mm(active_mm, mm, tsk);
task_unlock(tsk);
 
mmdrop(active_mm);


-
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.19: OOPS in cat /proc/fs/nfs/exports

[Neil Brown]

On Tuesday December 5, [EMAIL PROTECTED] wrote:
> 
> strace on exportfs shows this:nfsservctl(0x3, 0xbf875824, 0)  =
> - -1 ENOMEM

What version of nfs-utils are you running?  We haven't been using
nfsservctl(3, ...) on 2.6 kernels for ages - which probably explains
why exp_export() has suffered so much bit-rot.  When I convinced
exportfs to use that nfsservctl I got a very similar oops.


This patch fixes it for me.  Does it fix it for you too?

Thanks,
NeilBrown



diff .prev/fs/nfsd/export.c ./fs/nfsd/export.c
--- .prev/fs/nfsd/export.c  2006-12-06 14:57:24.0 +1100
+++ ./fs/nfsd/export.c  2006-12-07 12:36:28.0 +1100
@@ -983,6 +983,9 @@ exp_export(struct nfsctl_export *nxp)
 
dprintk("nfsd: creating export entry %p for client %p\n", exp, clp);
 
+   new.ex_path = kstrdup(nxp->ex_path, GFP_KERNEL);
+   if (!new.ex_path)
+   goto finish;
new.h.expiry_time = NEVER;
new.h.flags = 0;
new.ex_client = clp;
@@ -992,6 +995,9 @@ exp_export(struct nfsctl_export *nxp)
new.ex_anon_uid = nxp->ex_anon_uid;
new.ex_anon_gid = nxp->ex_anon_gid;
new.ex_fsid = nxp->ex_dev;
+   new.ex_fslocs.locations = NULL;
+   new.ex_fslocs.locations_count = 0;
+   new.ex_fslocs.migrated = 0;
 
exp = svc_export_lookup();
if (exp)
@@ -1007,8 +1013,10 @@ exp_export(struct nfsctl_export *nxp)
cache_flush();
err = -ENOMEM;
}
-
+   err = 0;
 finish:
+   if (new.ex_path)
+   kfree(new.ex_path);
if (exp)
exp_put(exp);
if (fsid_key && !IS_ERR(fsid_key))

-
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] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it

[Linus Torvalds]

On Thu, 7 Dec 2006, Roman Zippel wrote:
>
> m68060 produces a trap for unaligned atomic access, unfortunately standard 
> alignment is smaller than this.

Umm. on 68060, since it's 32-bit, you'd only have the 32-bit case. Are you 
saying that you can't do a 32-bit atomic access at any 32-bit aligned 
boundary? Or are you saying that gcc aligns normal 32-bit entities at 
16-bit alignment? Neither of those sound very likely.

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: [GIT] Please pull the NFS client update for 2.6.19

[Trond Myklebust]

On Wed, 2006-12-06 at 17:16 -0800, Linus Torvalds wrote:
> 
> On Wed, 6 Dec 2006, Trond Myklebust wrote:
> > 
> >git pull git://git.linux-nfs.org/pub/linux/nfs-2.6.git
> > 
> > This will update the following files through the appended changesets.
> 
> Well, right now it conflicts with the workqueue cleanups. Can you fix up 
> the conflicts and push again? Quite frankly, I could try, but since I 
> don't even run NFS, I _really_ don't think you want me to do so.

OK. I'll fix it up and resend.

Trond

-
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] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it

[Roman Zippel]

Hi,

On Wed, 6 Dec 2006, Linus Torvalds wrote:

> > > Any _real_ CPU will simply never care about _anything_ else than just the 
> > > size of the datum in question.
> > 
> > ..or alignment which a dedicated atomic type would allow to be attached.
> 
> Can you give any example of a real CPU where alignment matters?
> 
> Sure, it needs to be naturally aligned, but that's true of _any_ type in 
> the kernel. We don't do unaligneds without "get_unaligned()" and friends.

m68060 produces a trap for unaligned atomic access, unfortunately standard 
alignment is smaller than this.

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/

[PATCH RFC] use of activate_mm in fs/aio.c:use_mm()?

[Jeremy Fitzhardinge]

I'm wondering if activate_mm() is the right thing to be using in
use_mm(); shouldn't this be switch_mm()?

On normal x86, they're synonymous, but for the Xen patches I'm adding a
hook which assumes that activate_mm is only used the first time a new mm
is used after creation (I have another hook for dealing with dup_mm).  I
think this use of activate_mm() is the only place where it could be used
a second time on an mm.

>From a quick look at the other architectures I think this is OK (most
simply implement one in terms of the other), but some are doing some
subtly different stuff between the two.

Thanks,
J

diff -r 455b71ed4525 fs/aio.c
--- a/fs/aio.c  Wed Dec 06 13:16:42 2006 -0800
+++ b/fs/aio.c  Wed Dec 06 17:17:43 2006 -0800
@@ -588,7 +588,7 @@ static void use_mm(struct mm_struct *mm)
 * Note that on UML this *requires* PF_BORROWED_MM to be set, otherwise
 * it won't work. Update it accordingly if you change it here
 */
-   activate_mm(active_mm, mm);
+   switch_mm(active_mm, mm);
task_unlock(tsk);
 
mmdrop(active_mm);


-
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/1] Char: isicom, fix card locking

[Jiri Slaby]

Eric Fox wrote:
> Patch works if I disable SMP in kernel.

Aha, and it didn't work without the patch with SMP disabled?

> strace setserial -g /dev/ttyM0
> execve("/bin/setserial", ["setserial", "-g", "/dev/ttyM0"], [/* 17 vars
> */]) = 0
> uname({sys="Linux", node="dialin-0.vab.com", ...}) = 0
> brk(0)  = 0x804d000
> access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or
> directory)
> open("/etc/ld.so.cache", O_RDONLY)  = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=19713, ...}) = 0
> old_mmap(NULL, 19713, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f58000
> close(3)= 0
> open("/lib/tls/libc.so.6", O_RDONLY)= 3
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\36"..., 512) =
> 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=1454802, ...}) = 0
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7f57000
> old_mmap(0x39d000, 1223900, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
> 3, 0) = 0x39d000
> old_mmap(0x4c2000, 16384, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x124000) = 0x4c2000
> old_mmap(0x4c6000, 7388, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4c6000
> close(3)= 0
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7f56000
> mprotect(0x4c2000, 4096, PROT_READ) = 0
> mprotect(0x399000, 4096, PROT_READ) = 0
> set_thread_area({entry_number:-1 -> 6, base_addr:0xb7f566c0, limit:1048575,
> seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
> seg_not_present:0, 0munmap(0xb7f58000, 19713)   = 0


> open("/dev/ttyM0", O_RDWR|O_NONBLOCK)   = 3
> ioctl(3, TIOCGSERIAL, 0xbf81c280)   = 0

In one of these two there should lie the problem in SMP mode. The latter is OK
(no locking), but the former -- hmm, it gets stuck: I guess, we have a recursive
locking example here (I can see one of many in the driver now):
isicom_open()
{
...
isicom_setup_port()
...
}

isicom_setup_port()
{
...
spin_lock_irqsave(>card_lock, flags);
...
isicom_config_port();
...
spin_unlock_irqrestore(>card_lock, flags);
}

isicom_config_port()
{
...
lock_card()
...
unlock_card()
...
}

lock_card()
{
...
spin_lock_irqsave(>card_lock, card->flags);
...
}

unlock_card()
{
spin_unlock_irqrestore(>card_lock, card->flags);
}

Going to fix these.

thanks,
-- 
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E
-
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] Export current_is_keventd() for libphy

[Linus Torvalds]

On Wed, 6 Dec 2006, Linus Torvalds wrote:
> 
> How about something like this?

I didn't get any answers on this. I'd like to get this issue resolved, but 
since I don't even use libphy on my main machine, I need somebody else to 
test it for me.

Just to remind you all, here's the patch again. This is identical to the 
previous version except for the trivial cleanup to use "work_pending()" 
instead of open-coding it in two places.

Linus


diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 4044bb1..e175f39 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -587,8 +587,7 @@ int phy_stop_interrupts(struct phy_device *phydev)
 * Finish any pending work; we might have been scheduled
 * to be called from keventd ourselves, though.
 */
-   if (!current_is_keventd())
-   flush_scheduled_work();
+   run_scheduled_work(>phy_queue);
 
free_irq(phydev->irq, phydev);
 
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 4a3ea83..a601ed5 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -160,6 +160,7 @@ extern int queue_delayed_work_on(int cpu, struct 
workqueue_struct *wq,
 extern void FASTCALL(flush_workqueue(struct workqueue_struct *wq));
 
 extern int FASTCALL(schedule_work(struct work_struct *work));
+extern int FASTCALL(run_scheduled_work(struct work_struct *work));
 extern int FASTCALL(schedule_delayed_work(struct delayed_work *work, unsigned 
long delay));
 
 extern int schedule_delayed_work_on(int cpu, struct delayed_work *work, 
unsigned long delay);
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 8d1e7cb..36f9b78 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -103,6 +103,79 @@ static inline void *get_wq_data(struct work_struct *work)
return (void *) (work->management & WORK_STRUCT_WQ_DATA_MASK);
 }
 
+static int __run_work(struct cpu_workqueue_struct *cwq, struct work_struct 
*work)
+{
+   int ret = 0;
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+   /*
+* We need to re-validate the work info after we've gotten
+* the cpu_workqueue lock. We can run the work now iff:
+*
+*  - the wq_data still matches the cpu_workqueue_struct
+*  - AND the work is still marked pending
+*  - AND the work is still on a list (which will be this
+*workqueue_struct list)
+*
+* All these conditions are important, because we
+* need to protect against the work being run right
+* now on another CPU (all but the last one might be
+* true if it's currently running and has not been
+* released yet, for example).
+*/
+   if (get_wq_data(work) == cwq
+   && work_pending(work)
+   && !list_empty(>entry)) {
+   work_func_t f = work->func;
+   list_del_init(>entry);
+   spin_unlock_irqrestore(>lock, flags);
+
+   if (!test_bit(WORK_STRUCT_NOAUTOREL, >management))
+   work_release(work);
+   f(work);
+
+   spin_lock_irqsave(>lock, flags);
+   cwq->remove_sequence++;
+   wake_up(>work_done);
+   ret = 1;
+   }
+   spin_unlock_irqrestore(>lock, flags);
+   return ret;
+}
+
+/**
+ * run_scheduled_work - run scheduled work synchronously
+ * @work: work to run
+ *
+ * This checks if the work was pending, and runs it
+ * synchronously if so. It returns a boolean to indicate
+ * whether it had any scheduled work to run or not.
+ *
+ * NOTE! This _only_ works for normal work_structs. You
+ * CANNOT use this for delayed work, because the wq data
+ * for delayed work will not point properly to the per-
+ * CPU workqueue struct, but will change!
+ */
+int fastcall run_scheduled_work(struct work_struct *work)
+{
+   for (;;) {
+   struct cpu_workqueue_struct *cwq;
+
+   if (!work_pending(work))
+   return 0;
+   if (list_empty(>entry))
+   return 0;
+   /* NOTE! This depends intimately on __queue_work! */
+   cwq = get_wq_data(work);
+   if (!cwq)
+   return 0;
+   if (__run_work(cwq, work))
+   return 1;
+   }
+}
+EXPORT_SYMBOL(run_scheduled_work);
+
 /* Preempt must be disabled. */
 static void __queue_work(struct cpu_workqueue_struct *cwq,
 struct work_struct *work)
-
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] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it

[Linus Torvalds]

On Thu, 7 Dec 2006, Roman Zippel wrote:
> > 
> > Any _real_ CPU will simply never care about _anything_ else than just the 
> > size of the datum in question.
> 
> ..or alignment which a dedicated atomic type would allow to be attached.

Can you give any example of a real CPU where alignment matters?

Sure, it needs to be naturally aligned, but that's true of _any_ type in 
the kernel. We don't do unaligneds without "get_unaligned()" and friends.

Btw, if you want to leave out 8-bit and 16-bit data, that's fine. So 
generally you'd only need to handle 32-bit (and 64-bit on a 64-bit 
architecture) accesses anyway.

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: [GIT] Please pull the NFS client update for 2.6.19

[Linus Torvalds]

On Wed, 6 Dec 2006, Trond Myklebust wrote:
> 
>git pull git://git.linux-nfs.org/pub/linux/nfs-2.6.git
> 
> This will update the following files through the appended changesets.

Well, right now it conflicts with the workqueue cleanups. Can you fix up 
the conflicts and push again? Quite frankly, I could try, but since I 
don't even run NFS, I _really_ don't think you want me to do so.

Did you see the explanation of the split? Appended here just in case.

Linus
---
From: David Howells <[EMAIL PROTECTED]>

 (1) Any work_struct struct that has one of the following called upon it:

queue_delayed_work()
queue_delayed_work_on()
schedule_delayed_work()
schedule_delayed_work_on()
cancel_rearming_delayed_work()
cancel_rearming_delayed_workqueue()
cancel_delayed_work()

 needs changing into a delayed_work struct.

 Note that cancel_delayed_work() is often called where it'll be ineffective
 - I think people misunderstand what it does.

 (2) A delayed_work struct must be initialised with:

__DELAYED_WORK_INITIALIZER
DECLARE_DELAYED_WORK
INIT_DELAYED_WORK

 Rather than:

__WORK_INITIALIZER
DECLARE_WORK
INIT_WORK

 Those only apply to work_struct (non-delayable work).

 (3) The initialisation functions no longer take a data argument, and this
 should be deleted.

 (4) Anywhere one of the following is called on a delayed_work struct:

queue_work()
queue_work_on()
schedule_work()
schedule_work_on()

 it must be converted to the equivalent one of:

queue_delayed_work()
queue_delayed_work_on()
schedule_delayed_work()
schedule_delayed_work_on()

 and given a 0 timeout argument as an additional argument.  This just
 queues the work item and doesn't set the timer.

 (5) Anywhere the work item's pending flag is examined directly with:

test_bit(0, >pending)

 This should be replaced with the appropriate one of:

work_pending(work)
delayed_work_pending(work)

 (6) The work function _must_ be changed to conform to the following prototype:

void foo_work_func(struct work_struct *work)
{
...
}

 This applies to both work_struct and delayed_work handlers.

 (a) If the arbitary datum previously passed to the initialiser was NULL,
 then the work argument should just be ignored.

 (b) If the datum was the address of the structure containing the
 work_struct, then something like the following should be used:

struct foo {
struct work_struct worker;
...
};

void foo_work_func(struct work_struct *work)
{
struct foo *foo = container_of(work, struct foo, worker);
...
}

 If the work_struct can be placed at the beginning of the containing
 structure this will eliminate the subtraction instruction
 container_of() might otherwise require.

 (c) If the datum was the address of the structure containing the
 delayed_work, then something like the following should be used:

struct foo {
struct delayed_work worker;
...
};

void foo_work_func(struct work_struct *work)
{
struct foo *foo = container_of(work, struct foo, worker.work);
...
}

 NOTE!  There's an extra ".work" in the container_of() because the
 work_struct pointed to is embedded within the delayed_work.

 (d) If the datum is not a pointer to the container, but the container is
 guaranteed to exist whilst the work handler runs, then the datum can
 be stored in an extra variable in the container.

 The handler would then be formed as for (b) or (c), and the extra
 variable accessed after the container_of() line.

 Quite often there's a linked pair of structures, with a work_struct in
 one being initialised with the address of the other as its datum.  The
 typical case is struct net_device and the private data.  In this case
 just adding a back pointer from the private data to the net_device
 struct seems to work.

 (e) If the auxiliary datum is totally unrelated and can't be stored in an
 extra variable because the container might go away, then the
 work_struct or delayed_work should be initialised with one of these
 instead:

DECLARE_WORK_NAR
DECLARE_DELAYED_WORK_NAR
INIT_WORK_NAR
INIT_DELAYED_WORK_NAR
__WORK_INITIALIZER_NAR
__DELAYED_WORK_INITIALIZER_NAR

 These take the same arguments as the normal initialisers, but set a
 flag in the work_struct to indicate that the pending flag is not to be
 cleared before the work function is called.

  

Re: [PATCH 2/5] PCI : Move pci_fixup_device and is_enabled

[Greg KH]

On Wed, Nov 22, 2006 at 11:09:01AM -0700, Grant Grundler wrote:
> On Wed, Nov 22, 2006 at 05:06:07PM +0900, Hidetoshi Seto wrote:
> > --- linux-2.6.19-rc6.orig/drivers/pci/pci.c
> > +++ linux-2.6.19-rc6/drivers/pci/pci.c
> > @@ -558,12 +558,18 @@
> >  {
> > int err;
> > 
> > +   if (dev->is_enabled)
> > +   return 0;
> 
> This is unfortunately going to collide with the previous
> patch posted by [EMAIL PROTECTED]:
> 
> Subject: [patch 0/2] pci: make pci_{enable,disable}_device() be nested

Grant, you were right.  This has changed the logic around this area, and
the pci_enable_device() stuff conflicts with this.

Hidetoshi, I tried to merge things together, but I think I got it wrong,
as the logic is different now.  Can you please respin this patch and
resend all of them?

Sorry for the delay,

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [DLM] Fix DLM config [46/70]

[Adrian Bunk]

On Wed, Dec 06, 2006 at 04:03:42PM -0800, Randy Dunlap wrote:
> On Thu, 30 Nov 2006 12:20:42 + Steven Whitehouse wrote:
> 
> > >From b98c95af01c10827e3443157651eb469071391a3 Mon Sep 17 00:00:00 2001
> > From: Patrick Caulfield <[EMAIL PROTECTED]>
> > Date: Wed, 15 Nov 2006 12:29:24 -0500
> > Subject: [PATCH] [DLM] Fix DLM config
> > 
> > The attached patch fixes the DLM config so that it selects the chosen 
> > network
> > transport. It should fix the bug where DLM can be left selected when NET 
> > gets
> > unselected. This incorporates all the comments received about this patch.
> > 
> > ---
> >  fs/dlm/Kconfig |3 ++-
> >  1 files changed, 2 insertions(+), 1 deletions(-)
> > 
> > diff --git a/fs/dlm/Kconfig b/fs/dlm/Kconfig
> > index c5985b8..b5654a2 100644
> > --- a/fs/dlm/Kconfig
> > +++ b/fs/dlm/Kconfig
> > @@ -1,10 +1,11 @@
> >  menu "Distributed Lock Manager"
> > -   depends on INET && IP_SCTP && EXPERIMENTAL
> > +   depends on EXPERIMENTAL && INET
> >  
> >  config DLM
> > tristate "Distributed Lock Manager (DLM)"
> > depends on IPV6 || IPV6=n
> 
> What does that "depends on" (above) mean???
>...

It's coming from the select'ed IP_SCTP:

SCTP has optional IPV6 support, and this handles IPV6=m, IP_SCTP=y by 
making it an illegal configuration.

> Thanks.
> ~Randy

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: single bit errors on files stored on USB-HDDs via USB2/usb_storage

[Robert Hancock]

Matthias Schniedermeyer wrote:

Hi


I'm using a Bunch auf HDDs in USB-Enclosures for storing files.
(currently 38 HDD, with a total capacity of 9,5 TB of which 8,5 TB is used)


All the same enclosure type?


This time i kept the defective files and used "vbindiff" to show me the
difference. Strangly in EVERY case the difference is a single bit in a
sequence of "0xff"-Bytes inside a block of varing bit-values that
changed a "0xff" into a "0xf7".
Also interesting is that each error is at a 0xXXX5-Position

Attached is a file with 5 of the 6 differences named 1-5. Of each of the
5 2x3 lines-blocks the first 3 lines are the original the following 3
lines contain the error in the middle row 6th value.

NEVER did i see any messages in syslog regarding erros or an aborting
program due to errors passed down from the kernel or something like that.


The fact that the corruption seems data dependent would seem to me to 
point to some kind of hardware problem. I would tend to suspect the 
USB-to-IDE converters in the enclosures as being faulty or something 
like that..


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

-
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] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it

[David Miller]

From: Al Viro <[EMAIL PROTECTED]>
Date: Wed, 6 Dec 2006 19:08:28 +

> On Wed, Dec 06, 2006 at 11:05:22AM -0800, Linus Torvalds wrote:
> > 
> > 
> > On Wed, 6 Dec 2006, Christoph Lameter wrote:
> > >
> > > I'd really appreciate a cmpxchg that is generically available for 
> > > all arches. It will allow lockless implementation for various performance 
> > > criticial portions of the kernel.
> > 
> > I suspect ARM may have been the last one without one, no?
> 
> No.  sparc32 doesn't have one, for instance.

That's correct.  It has an atomic swap, but not a cmpxchg.
-
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] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it

[Roman Zippel]

Hi,

On Wed, 6 Dec 2006, Linus Torvalds wrote:

> > > To be honest, it'd be much easier if we only defined these operations on
> > > atomic_t's.  We have all the infrastructure in place for them, and
> > > they're fairly well understood.  If you need different sizes, I'm OK
> > > with an atomic_pointer_t, or whatever.
> > 
> > FWIW Seconded.
> 
> I disagree.
> 
> Any _real_ CPU will simply never care about _anything_ else than just the 
> size of the datum in question.

..or alignment which a dedicated atomic type would allow to be attached.

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: 2.6.19-rt3: compilation failure

[Jonathan Woithe]

Hi

> On Thu, 2006-12-07 at 10:58 +1030, Jonathan Woithe wrote:
> > Upon an attempt to compile 2.6.19-rt3 I encountered the following compile
> > error:
> 
> This was fix in -rt5 or 6 I think . The !PREEMPT_RT case. Current
> version is -rt7

Ah right, good.  I did grab rt6 yesterday but forgot to bring it home.
That'll learn me. :)

Regards
  jonathan
-
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] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it

[Linus Torvalds]

On Thu, 7 Dec 2006, Roman Zippel wrote:
> On Wed, 6 Dec 2006, Matthew Wilcox wrote:
> 
> > To be honest, it'd be much easier if we only defined these operations on
> > atomic_t's.  We have all the infrastructure in place for them, and
> > they're fairly well understood.  If you need different sizes, I'm OK
> > with an atomic_pointer_t, or whatever.
> 
> FWIW Seconded.

I disagree.

Any _real_ CPU will simply never care about _anything_ else than just the 
size of the datum in question. There's absolutely no point to only allow 
it on certain types, especially as we _know_ those certain types are 
already going to be more than one, and we also know that they are going to 
be different sizes. In other words, in reality, we have to handle a 
sizeable subset of the whole generic situation, and the "on certain types 
only" situation is only going to be awkward and irritating.

For example, would we have a different "cmpxchg_ptr()" function for the 
atomic pointer thing? With any reasonable CPU just depending on the _size_ 
of the type, I don't see what the problem is with just doing the 
bog-standard "cmpxchg_8/16/32/64" and having the bog-standard case- 
statement in a header file to do it all automatically for you, and then we 
don't need to worry about it.

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: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it

[Ralf Baechle]

On Wed, Dec 06, 2006 at 11:16:55AM -0800, Christoph Lameter wrote:

> But then its also just requires disable/enable interrupts on UP which may 
> be cheaper than an atomic operation.
> 
> > For CPUs with load locked + store conditional, it is expensive.
> 
> Because it locks the bus? I am not that familiar with those architectures 
> but it seems that those will have a general problem anyways.

On a decent implementation ll/sc will have the same cost as ordinary
non-atomic load and store instructions.  A likely uniprocessor
implementation uses a single flip-flop ("llbit") in the CPU which is set
by ll and cleared by any exception handler, especially interrupt.  A later
store conditional will then simply fail if that bit is cleared.  That
is extremly trivial stuff.  On SMP it's somewhat more complex; A
processor will have to remember the address used with ll and start
snooping the bus for writes to it.  The store conditional will then
go and upgrade the cache line to exclusive state if the llbit is still
set and perform the store.  The llbit would be cleared if the processor
has snooped any other write to the cacheline.  Details are fun but that's
bascially how it's implemented.

Of course load linked / store conditional are typically used in loops
so there is a little extra overhead from that especially where when the
branch is misspredicted.

Also note there is no locked cycle required to implement load linked /
store conditional.

  Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: D-cache aliasing issue in cow_user_page

[David Miller]

From: "Matt Reimer" <[EMAIL PROTECTED]>
Date: Wed, 6 Dec 2006 13:19:41 -0800

> On 12/5/06, David Miller <[EMAIL PROTECTED]> wrote:
> > From: "Matt Reimer" <[EMAIL PROTECTED]>
> > Date: Tue, 5 Dec 2006 16:57:12 -0800
> >
> > > Right, but isn't he declaring that each architecture needs to take
> > > care of this? So, say, on ARM we'd need to make kunmap() not a NOP and
> > > call flush_dcache_page() ?
> >
> > No.  He is only solving a problem that occurs on HIGHMEM
> > configurations on systems which can have D-cache aliasing
> > issues.
> 
> Are you sure? James specifically mentions "non-highmem architectures,"
> and "all architectures with coherence issues," which would seem to
> include ARM (which is my concern).
> 
> For your convenience I quote the whole commit message below.

Ok, I see.

He's providing it an alternative way to solve the coherency
issues.

You can still solve it the traditional way via cache flushing
in flush_dcache_page() and {copy,clear}_user_page().
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] CPEI gets warning at kernel/irq/migration.c:27/move_masked_irq()

[Hidetoshi Seto]

Arjan van de Ven wrote:
>> It'd be nice if we could just teach the userspace balancer to not try to
>> move perpcu IRQs?
>>
>> otoh, the patch is super-cheap.   Arjan?
> 
> I can fix irqbalance no problem, however I like the kernel approach as
> well, since it's not just irqbalance that moves irqs, sysadmins tend to
> do it as well  so how about both?

Thanks for positive comments.

> One thing we probably should do, and that would help irqbalance
> immensely, is to export a bitmask for which cpus an interrupt CAN go to,
> next to where the current binding interface is. I'll check into that
> 
> Hidetoshi: would it be possible to send me a /proc/interrupts file of
> that machine?

Here you are.
This machine is not special. I guess all ia64 machine will show
few or more but almost same lines. CPEI is #30.

$ cat /proc/interrupts
   CPU0   CPU1
 28:  0  0  LSAPIC  cpe_poll
 29:  0  0  LSAPIC  cmc_poll
 30:  0  0  IO-SAPIC-level  cpe_hndlr
 31:  0  0  LSAPIC  cmc_hndlr
 34:   46431881067   IO-SAPIC-edge  ide0
 39:  0  0  IO-SAPIC-level  acpi
 45:148560   IO-SAPIC-edge  serial
 48:  0  0  IO-SAPIC-level  uhci_hcd
 49:  0  0  IO-SAPIC-level  uhci_hcd
 50:  0  0  IO-SAPIC-level  ehci_hcd
 51:  211311257790  IO-SAPIC-level  eth0
 53:  21778 458314  IO-SAPIC-level  ioc0
 54:  0 44  IO-SAPIC-level  ioc1
232:  0  0  LSAPIC  mca_rdzv
238:  0  0  LSAPIC  perfmon
239:  214832233  214832003  LSAPIC  timer
240:  0  0  LSAPIC  mca_wkup
254: 209193611  LSAPIC  IPI
ERR:  0

Thanks,
H.Seto

-
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.19-rt3: compilation failure

[Daniel Walker]

On Thu, 2006-12-07 at 10:58 +1030, Jonathan Woithe wrote:
> Upon an attempt to compile 2.6.19-rt3 I encountered the following compile
> error:
> 

This was fix in -rt5 or 6 I think . The !PREEMPT_RT case. Current
version is -rt7

http://people.redhat.com/~mingo/realtime-preempt/patch-2.6.19-rt7

Daniel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] New firewire stack

[Kristian Høgsberg]

Ben Collins wrote:
...

I would like to see new development efforts take cleanliness WRT host
byte order and 64bit architectures into account from the ground up. (I
understand though why Kristian made the announcement in this early
phase, and I agree with him that this kind of development has to go into
the open early.)


And yet endianness is not the focus from the ground up in Kristian's
work. That was my point.


I don't know what you base this on, it's not true.  Everything outside 
fw-ohci.c is endian aware and I know the two things I need to look into for 
fw-ohci: DMA programs and IEEE1394 headers.  My plan was to develop the stack 
towards feature completeness and then test on big-endian and 64-bit platforms.


If you're thinking of the bitfield problem BenH pointed out, that doesn't 
imply I didn't have endianess in mind when writing the code.  As Stefan 
already mentioned, we use bitfields for wire data in the current stack.  We 
have to sets of structs, one for big endian architectures and one for little 
endian architectures.  My plan was to write big endian versions of these 
structs and then test on various architectures.


So my bitfield approach doesn't work and I haven't gotten around to doing the 
big-endian testing yet, but don't mistake that for lack of endianess 
awareness.  Of course, big endian and 64-bit architectures *must* work, but I 
contend that it can impact the overall design of the stack.  It's a detail 
that you need to get right, not a design principle.  But let's not argue this 
further, I'll post a new set of patches in a few days that work on big-endian 
and 64-bit.


cheers,
Kristian
-
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] free initrds boot option

[H. Peter Anvin]

Andrew Morton wrote:


I'd have thought that an option `retain_initrd' would make more sense.

Please always update Documentation/kernel-parameters.txt when adding boot
options.



I would have to agree with this; it also seems a bit odd to me to have 
this at all (kexec provides a new kernel image, surely it also provides 
a new initrd image???)


-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/

Re: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it

[Roman Zippel]

Hi,

On Wed, 6 Dec 2006, Matthew Wilcox wrote:

> To be honest, it'd be much easier if we only defined these operations on
> atomic_t's.  We have all the infrastructure in place for them, and
> they're fairly well understood.  If you need different sizes, I'm OK
> with an atomic_pointer_t, or whatever.

FWIW Seconded.

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/

2.6.19-rt3: compilation failure

[Jonathan Woithe]

Upon an attempt to compile 2.6.19-rt3 I encountered the following compile
error:

> make -j 2
  CHK include/linux/version.h
  CHK include/linux/utsrelease.h
  CC  arch/i386/kernel/asm-offsets.s
In file included from include/linux/time.h:7,
 from include/linux/timex.h:57,
 from include/linux/sched.h:50,
 from include/linux/module.h:9,
 from include/linux/crypto.h:21,
 from arch/i386/kernel/asm-offsets.c:7:
include/linux/seqlock.h: In function _read_seqretry':
include/linux/seqlock.h:139: error: syntax error before "do"
include/linux/seqlock.h:139: error: syntax error before "else"
In file included from include/linux/module.h:9,
 from include/linux/crypto.h:21,
 from arch/i386/kernel/asm-offsets.c:7:
include/linux/sched.h: In function equeue_signal_lock':
include/linux/sched.h:1479: error: syntax error before "do"
include/linux/sched.h:1479: error: syntax error before "else"
make[1]: *** [arch/i386/kernel/asm-offsets.s] Error 1
make: *** [prepare0] Error 2

This was on a Slackware 10.2-based system, so gcc is 3.3.6, binutils is 
version 2.15.92.0.2.

The kernel .config file follows.  Note that this error also occured when
I tried to compile 2.6.19-rt1.  I piped the same config into an unpatched
2.6.19 "make menuconfig", saved and then tried to compile; it worked.

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.19-rt3
# Wed Dec  6 18:37:45 2006
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
# CONFIG_RELAY is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# Block layer
#
CONFIG_BLOCK=y
CONFIG_LBD=y
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"

#
# Processor type and features
#
# CONFIG_HIGH_RES_TIMERS is not set
# CONFIG_SMP is not set
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
CONFIG_MPENTIUMM=y
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT_DESKTOP=y
# CONFIG_PREEMPT_RT is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
# 

Re: [PATCH] free initrds boot option

[Andrew Morton]

On Thu, 07 Dec 2006 11:18:43 +1100
Michael Neuling <[EMAIL PROTECTED]> wrote:

> Add free_initrd= option to control freeing of initrd memory after
> extraction.  By default, free memory as previously.
> 
> Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
> ---
> Useful for kexec when you want to reuse the same initrd.  Testing on
> POWERPC with CPIOs 
> 
> --- linux-2.6-ozlabs.orig/init/initramfs.c
> +++ linux-2.6-ozlabs/init/initramfs.c
> @@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
>   return message;
>  }
>  
> +static int do_free_initrd = 1;
> +
> +int __init free_initrd_param(char *p)
> +{
> + if (p && strncmp(p, "0", 1) == 0)
> + do_free_initrd = 0;
> +
> + return 0;
> +}
> +early_param("free_initrd", free_initrd_param);
> +
>  extern char __initramfs_start[], __initramfs_end[];
>  #ifdef CONFIG_BLK_DEV_INITRD
>  #include 
> @@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
>  
>  static void __init free_initrd(void)
>  {
> -#ifdef CONFIG_KEXEC
>   unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
>   unsigned long crashk_end   = (unsigned long)__va(crashk_res.end);
>  
> + if (!do_free_initrd)
> + goto skip;
> +
> +#ifdef CONFIG_KEXEC
>   /*
>* If the initrd region is overlapped with crashkernel reserved region,
>* free only memory that is not part of crashkernel region.
> @@ -515,7 +529,7 @@ static void __init free_initrd(void)
>   } else
>  #endif
>   free_initrd_mem(initrd_start, initrd_end);
> -
> +skip:
>   initrd_start = 0;
>   initrd_end = 0;
>  }

I'd have thought that an option `retain_initrd' would make more sense.

Please always update Documentation/kernel-parameters.txt when adding boot
options.

-
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/

workqueue deadlock

[Bjorn Helgaas]

I'm seeing a workqueue-related deadlock.  This is on an ia64
box running SLES10, but it looks like the same problem should
be possible in current upstream on any architecture.

Here are the two tasks involved:

  events/4:
schedule
__down
__lock_cpu_hotplug
lock_cpu_hotplug
flush_workqueue
kblockd_flush
blk_sync_queue
cfq_shutdown_timer_wq
cfq_exit_queue
elevator_exit
blk_cleanup_queue
scsi_free_queue
scsi_device_dev_release_usercontext
run_workqueue

  loadkeys:
schedule
flush_cpu_workqueue
flush_workqueue
flush_scheduled_work
release_dev
tty_release

loadkeys is holding the cpu_hotplug lock (acquired in flush_workqueue())
and waiting in flush_cpu_workqueue() until the cpu_workqueue drains.

But events/4 is responsible for draining it, and it is blocked waiting
to acquire the cpu_hotplug lock.

In current upstream, the cpu_hotplug lock has been replaced with
workqueue_mutex, but it looks to me like the same deadlock is still
possible.

Is there some rule that workqueue functions shouldn't try to
flush a workqueue?  Or should flush_workqueue() be smarter by
releasing the workqueue_mutex once in a while?
-
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] free initrds boot option

[Randy Dunlap]

On Thu, 07 Dec 2006 11:18:43 +1100 Michael Neuling wrote:

> Add free_initrd= option to control freeing of initrd memory after
> extraction.  By default, free memory as previously.

Please add doc. for this in Documentation/kernel-parameters.txt.

> Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
> ---
> Useful for kexec when you want to reuse the same initrd.  Testing on
> POWERPC with CPIOs 
> 
>  init/initramfs.c |   18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6-ozlabs/init/initramfs.c
> ===
> --- linux-2.6-ozlabs.orig/init/initramfs.c
> +++ linux-2.6-ozlabs/init/initramfs.c
> @@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
>   return message;
>  }
>  
> +static int do_free_initrd = 1;
> +
> +int __init free_initrd_param(char *p)
> +{
> + if (p && strncmp(p, "0", 1) == 0)
> + do_free_initrd = 0;
> +
> + return 0;
> +}
> +early_param("free_initrd", free_initrd_param);
> +
>  extern char __initramfs_start[], __initramfs_end[];
>  #ifdef CONFIG_BLK_DEV_INITRD
>  #include 
> @@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
>  
>  static void __init free_initrd(void)
>  {
> -#ifdef CONFIG_KEXEC
>   unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
>   unsigned long crashk_end   = (unsigned long)__va(crashk_res.end);
>  
> + if (!do_free_initrd)
> + goto skip;
> +
> +#ifdef CONFIG_KEXEC
>   /*
>* If the initrd region is overlapped with crashkernel reserved region,
>* free only memory that is not part of crashkernel region.
> @@ -515,7 +529,7 @@ static void __init free_initrd(void)
>   } else
>  #endif
>   free_initrd_mem(initrd_start, initrd_end);
> -
> +skip:
>   initrd_start = 0;
>   initrd_end = 0;
>  }
> -

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 2.6.19-rc6] fix hotplug for legacy platform drivers

[Marco d'Itri]

On Dec 06, David Brownell <[EMAIL PROTECTED]> wrote:

> > Please explain in more details how hotplugging would be broken, possibly
> > with examples.
> First, for reference, I refer to hotplugging using the trivial ASH scripts
> from [1], updated by removing no-longer-needed special cases for platform_bus
> (that original logic didn't work sometimes) and pcmcia.  See the (short)
I.e. a quick hack which has never been used by any distribution.
And anyway some kernel component is supposed to provide the aliases
pointing from the $MODALIAS values to the drivers, so modprobe $MODALIAS
would still work.

> Those scripts have supported hotplug and coldplug on several embedded boards
> for some time now.
Can you mention some?

> Second, note that you're asking me to construct a straw man for you and
> then break it down, since nobody arguing with the $SUBJECT patch has ever
> provided a complete counter-proposal (much less respond to the points
> I've made about legacy driver bugginess -- which is suggestive).
I am asking what is the point for a module to provide its own name in
$MODALIAS. You say that not doing this would break your custom hotplug
subsystem, but you still have not explained how this would happen since
$MODALIAS is available only *after* the module has been loaded by
something else.

> And "udev" was from day one supposed to solve  a different problem
> than "loading modules".  There was to be a clear and strong separation
> of roles between hotplug (load modules, don't rely on sysfs, use other
> components for the rest of device setup) and udev (make /dev nodes,
> ok to rely on sysfs).  That is, "udev" wouldn't do any loading.
Who cares? It does now, and for many good reasons.

-- 
ciao,
Marco
-
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] free initrds boot option

[Michael Neuling]

Add free_initrd= option to control freeing of initrd memory after
extraction.  By default, free memory as previously.

Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
Useful for kexec when you want to reuse the same initrd.  Testing on
POWERPC with CPIOs 

 init/initramfs.c |   18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

Index: linux-2.6-ozlabs/init/initramfs.c
===
--- linux-2.6-ozlabs.orig/init/initramfs.c
+++ linux-2.6-ozlabs/init/initramfs.c
@@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
return message;
 }
 
+static int do_free_initrd = 1;
+
+int __init free_initrd_param(char *p)
+{
+   if (p && strncmp(p, "0", 1) == 0)
+   do_free_initrd = 0;
+
+   return 0;
+}
+early_param("free_initrd", free_initrd_param);
+
 extern char __initramfs_start[], __initramfs_end[];
 #ifdef CONFIG_BLK_DEV_INITRD
 #include 
@@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
 
 static void __init free_initrd(void)
 {
-#ifdef CONFIG_KEXEC
unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
unsigned long crashk_end   = (unsigned long)__va(crashk_res.end);
 
+   if (!do_free_initrd)
+   goto skip;
+
+#ifdef CONFIG_KEXEC
/*
 * If the initrd region is overlapped with crashkernel reserved region,
 * free only memory that is not part of crashkernel region.
@@ -515,7 +529,7 @@ static void __init free_initrd(void)
} else
 #endif
free_initrd_mem(initrd_start, initrd_end);
-
+skip:
initrd_start = 0;
initrd_end = 0;
 }
-
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] A few small additions and corrections to README

[Jesper Juhl]

On Thursday 07 December 2006 01:07, Ben Nizette wrote:
> Jesper Juhl wrote:
[...]
> > @@ -22,15 +22,17 @@ ON WHAT HARDWARE DOES IT RUN?
> >  
> >Although originally developed first for 32-bit x86-based PCs (386 or 
> > higher),
> >today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and
> > -  UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH,
> > +  UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, 
> > Cell,
> >   
> And AVR32 as of 2.6.19 :)

Well, the list does say "(at least)" ;-)   But sure, find an add-on patch below.

> >IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS,
> > -  and Renesas M32R architectures.
> > +  Cris, Xtensa and Renesas M32R architectures.


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

diff --git a/README b/README
index b656f00..c055615 100644
--- a/README
+++ b/README
@@ -24,7 +24,7 @@ ON WHAT HARDWARE DOES IT RUN?
   today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and
   UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell,
   IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS,
-  Cris, Xtensa and Renesas M32R architectures.
+  Cris, Xtensa, AVR32 and Renesas M32R architectures.
 
   Linux is easily portable to most general-purpose 32- or 64-bit architectures
   as long as they have a paged memory management unit (PMMU) and a port of the


-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.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: [PATCH] A few small additions and corrections to README

[Ben Nizette]

Jesper Juhl wrote:

Hi,

here's a small patch which 


 - adds a few archs to the current list of supported platforms.
 - adds a few missing slashes at the end of URLs.
 - adds a few references to additional documentation.
 - adds "make config" to the list of possible configuration targets.
 - makes a few other minor changes.

Please consider for inclusion.


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

 README |   17 +++--
 1 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
diff --git a/README b/README
index 3e26472..b656f00 100644
--- a/README
+++ b/README
@@ -1,4 +1,4 @@
-   Linux kernel release 2.6.xx 
+   Linux kernel release 2.6.xx 
 
 These are the release notes for Linux version 2.6.  Read them carefully,

 as they tell you what this is all about, explain how to install the
@@ -22,15 +22,17 @@ ON WHAT HARDWARE DOES IT RUN?
 
   Although originally developed first for 32-bit x86-based PCs (386 or higher),

   today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and
-  UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH,
+  UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell,
  

And AVR32 as of 2.6.19 :)

   IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS,
-  and Renesas M32R architectures.
+  Cris, Xtensa and Renesas M32R architectures.
 
   Linux is easily portable to most general-purpose 32- or 64-bit architectures

   as long as they have a paged memory management unit (PMMU) and a port of the
   GNU C compiler (gcc) (part of The GNU Compiler Collection, GCC). Linux has
   also been ported to a number of architectures without a PMMU, although
   functionality is then obviously somewhat limited.
+  Linux has also been ported to itself. You can now run the kernel as a
+  userspace application - this is called UserMode Linux (UML).
 
 DOCUMENTATION:
 
@@ -113,6 +115,7 @@ INSTALLING the kernel:

version 2.6.12.2 and want to jump to 2.6.12.3, you must first
reverse the 2.6.12.2 patch (that is, patch -R) _before_ applying
the 2.6.12.3 patch.
+   You can read more on this in Documentation/applying-patches.txt
 
  - Make sure you have no stale .o files and dependencies lying around:
 
@@ -161,6 +164,7 @@ CONFIGURING the kernel:

only ask you for the answers to new questions.
 
  - Alternate configuration commands are:

+   "make config"  Plain text interface.
"make menuconfig"  Text based color menus, radiolists & dialogs.
"make xconfig" X windows (Qt) based configuration tool.
"make gconfig" X windows (Gtk) based configuration tool.
@@ -303,8 +307,9 @@ IF SOMETHING GOES WRONG:
 
  - If you compiled the kernel with CONFIG_KALLSYMS you can send the dump

as is, otherwise you will have to use the "ksymoops" program to make
-   sense of the dump.  This utility can be downloaded from
-   ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops.
+   sense of the dump (but compiling with CONFIG_KALLSYMS is usually preferred).
+   This utility can be downloaded from
+   ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops/ .
Alternately you can do the dump lookup by hand:
 
  - In debugging dumps like the above, it helps enormously if you can

@@ -336,7 +341,7 @@ IF SOMETHING GOES WRONG:
 
If you for some reason cannot do the above (you have a pre-compiled

kernel image or similar), telling me as much about your setup as
-   possible will help. 
+   possible will help.  Please read the REPORTING-BUGS document for details.
 
  - Alternately, you can use gdb on a running kernel. (read-only; i.e. you

cannot change values or set break points.) To do this, first compile the



-
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/

  


-
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: Obtaining a list of memory address ranges allocated to processes

[Remi Colinet]

Selon Stephen Torri <[EMAIL PROTECTED]>:

> I am trying to create a custom ELF and Windows PE loader for the purpose
> of security research. I am having a difficult time finding how to
> allocate memory for a binary at the desired address in memory
> (especially if its non-relocatable).

Use mmap system call.
Anyway, the address is only going to be a hint.

> I would like to see why I cannot
> get memory allocated at the exact address request in the binary headers.

address should be page aligned.

> Is there a program or system call that allows me to see a list of memory
> address ranges allocated to the running processes on a system?
>

pmap pid_of_your_program will give you the memory map.

> Stephen
>

Remi

> -
> 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/
>


-
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: [DLM] Fix DLM config [46/70]

[Randy Dunlap]

On Thu, 30 Nov 2006 12:20:42 + Steven Whitehouse wrote:

> >From b98c95af01c10827e3443157651eb469071391a3 Mon Sep 17 00:00:00 2001
> From: Patrick Caulfield <[EMAIL PROTECTED]>
> Date: Wed, 15 Nov 2006 12:29:24 -0500
> Subject: [PATCH] [DLM] Fix DLM config
> 
> The attached patch fixes the DLM config so that it selects the chosen network
> transport. It should fix the bug where DLM can be left selected when NET gets
> unselected. This incorporates all the comments received about this patch.
> 
> ---
>  fs/dlm/Kconfig |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/fs/dlm/Kconfig b/fs/dlm/Kconfig
> index c5985b8..b5654a2 100644
> --- a/fs/dlm/Kconfig
> +++ b/fs/dlm/Kconfig
> @@ -1,10 +1,11 @@
>  menu "Distributed Lock Manager"
> - depends on INET && IP_SCTP && EXPERIMENTAL
> + depends on EXPERIMENTAL && INET
>  
>  config DLM
>   tristate "Distributed Lock Manager (DLM)"
>   depends on IPV6 || IPV6=n

What does that "depends on" (above) mean???

>   select CONFIGFS_FS
> + select IP_SCTP if DLM_SCTP
>   help
>   A general purpose distributed lock manager for kernel or userspace
>   applications.
> -- 

Thanks.
---
~Randy
-
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/

Obtaining a list of memory address ranges allocated to processes

[Stephen Torri]

I am trying to create a custom ELF and Windows PE loader for the purpose
of security research. I am having a difficult time finding how to
allocate memory for a binary at the desired address in memory
(especially if its non-relocatable). I would like to see why I cannot
get memory allocated at the exact address request in the binary headers.
Is there a program or system call that allows me to see a list of memory
address ranges allocated to the running processes on a system?

Stephen

-
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] ACPI, i686, x86_64: fix laptop bootup hang in init_acpi()

[Len Brown]

On Wednesday 06 December 2006 17:30, Ingo Molnar wrote:
> Subject: [patch] ACPI, i686, x86_64: fix laptop bootup hang in init_acpi()
> From: Ingo Molnar <[EMAIL PROTECTED]>
> 
> during kernel bootup, a new T60 laptop (CoreDuo, 32-bit) hangs about 
> 10%-20% of the time in acpi_init():
> 
>  Calling initcall 0xc055ce1a: topology_init+0x0/0x2f()
>  Calling initcall 0xc055d75e: mtrr_init_finialize+0x0/0x2c()
>  Calling initcall 0xc05664f3: param_sysfs_init+0x0/0x175()
>  Calling initcall 0xc014cb65: pm_sysrq_init+0x0/0x17()
>  Calling initcall 0xc0569f99: init_bio+0x0/0xf4()
>  Calling initcall 0xc056b865: genhd_device_init+0x0/0x50()
>  Calling initcall 0xc056c4bd: fbmem_init+0x0/0x87()
>  Calling initcall 0xc056dd74: acpi_init+0x0/0x1ee()
> 
> it's a hard hang that not even an NMI could punch through! 
> Frustratingly, adding printks or function tracing to the ACPI code made 
> the hangs go away ...
> 
> after some time an additional detail emerged: disabling the NMI watchdog 
> made these occasional hangs go away.
> 
> So i spent the better part of today trying to debug this and trying out 
> various theories when i finally found the likely reason for the hang: if 
> acpi_ns_initialize_devices() executes an _INI AML method and an NMI 
> happens to hit that AML execution in the wrong moment, the machine would 
> hang.  (my theory is that this must be some sort of chipset setup method 
> doing stores to chipset mmio registers?)
> 
> Unfortunately given the characteristics of the hang it was sheer 
> impossible to figure out which of the numerous AML methods is impacted 
> by this problem.
> 
> as a workaround i wrote an interface to disable chipset-based NMIs while 
> executing _INI sections - and indeed this fixed the hang. I did a 
> boot-loop of 100 separate reboots and none hung - while without the 
> patch it would hang every 5-10 attempts. Out of caution i did not touch 
> the nmi_watchdog=2 case (it's not related to the chipset anyway and 
> didnt hang).
> 
> I implemented this for both x86_64 and i686, tested the i686 laptop both 
> with nmi_watchdog=1 [which triggered the hangs] and nmi_watchdog=2, and 
> tested an Athlon64 box with the 64-bit kernel as well. Everything builds 
> and works with the patch applied.

Good work root-causing this failure!

Personally I have never been a big fan of having the NMI watchdog
running by default on all systems -- but Andi insists that it helps him
debug failures, so tick it does...

Clearly this laptop was validated with Windows, and Windows doesn't
have this problem -- suggesting that we may be somewhat out on a limb...

Some alternatives to consider...
a. don't enable NMI watchdog by default
b. enable NMI watchdog, but later during kernel boot
(assumption here that the issue is only during _INI)
c. disable the NMI whenever the ACPI interpeter is running
   (who knows, maybe this isn't limited to the _INI case, but
could cause a hang at some other time -- only the
BIOS AML writers knows)

thoughts?
-Len

> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
> ---
>  arch/i386/kernel/nmi.c  |   28 
>  arch/x86_64/kernel/nmi.c|   27 +++
>  drivers/acpi/namespace/nsinit.c |9 +
>  include/linux/nmi.h |9 -
>  4 files changed, 72 insertions(+), 1 deletion(-)
> 
> Index: linux/arch/i386/kernel/nmi.c
> ===
> --- linux.orig/arch/i386/kernel/nmi.c
> +++ linux/arch/i386/kernel/nmi.c
> @@ -376,6 +376,34 @@ void enable_timer_nmi_watchdog(void)
>   }
>  }
>  
> +static void __acpi_nmi_disable(void *__unused)
> +{
> + apic_write_around(APIC_LVT0, APIC_DM_NMI | APIC_LVT_MASKED);
> +}
> +
> +/*
> + * Disable timer based NMIs on all CPUs:
> + */
> +void acpi_nmi_disable(void)
> +{
> + if (atomic_read(_active) && nmi_watchdog == NMI_IO_APIC)
> + on_each_cpu(__acpi_nmi_disable, NULL, 0, 1);
> +}
> +
> +static void __acpi_nmi_enable(void *__unused)
> +{
> + apic_write_around(APIC_LVT0, APIC_DM_NMI);
> +}
> +
> +/*
> + * Enable timer based NMIs on all CPUs:
> + */
> +void acpi_nmi_enable(void)
> +{
> + if (atomic_read(_active) && nmi_watchdog == NMI_IO_APIC)
> + on_each_cpu(__acpi_nmi_enable, NULL, 0, 1);
> +}
> +
>  #ifdef CONFIG_PM
>  
>  static int nmi_pm_active; /* nmi_active before suspend */
> Index: linux/arch/x86_64/kernel/nmi.c
> ===
> --- linux.orig/arch/x86_64/kernel/nmi.c
> +++ linux/arch/x86_64/kernel/nmi.c
> @@ -360,6 +360,33 @@ void enable_timer_nmi_watchdog(void)
>   }
>  }
>  
> +static void __acpi_nmi_disable(void *__unused)
> +{
> + apic_write(APIC_LVT0, APIC_DM_NMI | APIC_LVT_MASKED);
> +}
> +
> +/*
> + * Disable timer based NMIs on all CPUs:
> + */
> +void acpi_nmi_disable(void)
> +{
> + if (atomic_read(_active) && nmi_watchdog == NMI_IO_APIC)
> + 

Re: [PATCH 0/3] New firewire stack

[Stefan Richter]

Kristian Høgsberg wrote:
> Stefan Richter wrote:
>> You have to look at the matter not only from the POV of API design but
>> also of deployment and support.
> 
> My POV here *is* about deployment and support, but from the kernel side
> of things.  If you commit yourself to long time support for the firewire
> stack, would you prefer 4 slightly different streaming drivers with
> different user space interfaces, or just one userspace driver with one
> userspace interface, that enables the 4 different types of streaming to
> be done in userspace?

My own preference certainly came across during in the recent thread on
linux1394-devel about deprecation dates... :-)

> The design of the streaming interfaces have been
> focused on enabling all these ad-hoc, in-kernel drivers to move to
> userspace, to make it feasible to actually support the stack.

-- 
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: Kernel panic at boot with recent pci quirks patch

[Remi Colinet]

Frank Sorenson <[EMAIL PROTECTED]> wrote:

> The latest -git tree panics at boot for me.  git-bisect traced the
offending commit to:
>
> 368c73d4f689dae0807d0a2aa74c61fd2b9b075f is first bad commit
> commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f
> Author: Alan Cox <[EMAIL PROTECTED]>
> Date:   Wed Oct 4 00:41:26 2006 +0100
>
> PCI: quirks: fix the festering mess that claims to handle IDE quirks
>
> Hardware is a Dell Inspiron E1705 laptop running FC6 x86_64.
>

Could you try the following patch (already included in mm tree)?

http://www.uwsg.indiana.edu/hypermail/linux/kernel/0611.1/1568.html

Remi
-
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] A few small additions and corrections to README

[Jesper Juhl]

Hi,

here's a small patch which 

 - adds a few archs to the current list of supported platforms.
 - adds a few missing slashes at the end of URLs.
 - adds a few references to additional documentation.
 - adds "make config" to the list of possible configuration targets.
 - makes a few other minor changes.

Please consider for inclusion.


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

 README |   17 +++--
 1 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
diff --git a/README b/README
index 3e26472..b656f00 100644
--- a/README
+++ b/README
@@ -1,4 +1,4 @@
-   Linux kernel release 2.6.xx 
+   Linux kernel release 2.6.xx 
 
 These are the release notes for Linux version 2.6.  Read them carefully,
 as they tell you what this is all about, explain how to install the
@@ -22,15 +22,17 @@ ON WHAT HARDWARE DOES IT RUN?
 
   Although originally developed first for 32-bit x86-based PCs (386 or higher),
   today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and
-  UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH,
+  UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell,
   IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS,
-  and Renesas M32R architectures.
+  Cris, Xtensa and Renesas M32R architectures.
 
   Linux is easily portable to most general-purpose 32- or 64-bit architectures
   as long as they have a paged memory management unit (PMMU) and a port of the
   GNU C compiler (gcc) (part of The GNU Compiler Collection, GCC). Linux has
   also been ported to a number of architectures without a PMMU, although
   functionality is then obviously somewhat limited.
+  Linux has also been ported to itself. You can now run the kernel as a
+  userspace application - this is called UserMode Linux (UML).
 
 DOCUMENTATION:
 
@@ -113,6 +115,7 @@ INSTALLING the kernel:
version 2.6.12.2 and want to jump to 2.6.12.3, you must first
reverse the 2.6.12.2 patch (that is, patch -R) _before_ applying
the 2.6.12.3 patch.
+   You can read more on this in Documentation/applying-patches.txt
 
  - Make sure you have no stale .o files and dependencies lying around:
 
@@ -161,6 +164,7 @@ CONFIGURING the kernel:
only ask you for the answers to new questions.
 
  - Alternate configuration commands are:
+   "make config"  Plain text interface.
"make menuconfig"  Text based color menus, radiolists & dialogs.
"make xconfig" X windows (Qt) based configuration tool.
"make gconfig" X windows (Gtk) based configuration tool.
@@ -303,8 +307,9 @@ IF SOMETHING GOES WRONG:
 
  - If you compiled the kernel with CONFIG_KALLSYMS you can send the dump
as is, otherwise you will have to use the "ksymoops" program to make
-   sense of the dump.  This utility can be downloaded from
-   ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops.
+   sense of the dump (but compiling with CONFIG_KALLSYMS is usually preferred).
+   This utility can be downloaded from
+   ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops/ .
Alternately you can do the dump lookup by hand:
 
  - In debugging dumps like the above, it helps enormously if you can
@@ -336,7 +341,7 @@ IF SOMETHING GOES WRONG:
 
If you for some reason cannot do the above (you have a pre-compiled
kernel image or similar), telling me as much about your setup as
-   possible will help. 
+   possible will help.  Please read the REPORTING-BUGS document for details.
 
  - Alternately, you can use gdb on a running kernel. (read-only; i.e. you
cannot change values or set break points.) To do this, first compile the



-
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: -mm merge plans for 2.6.20

[Andrew Morton]

On Tue, 5 Dec 2006 21:34:16 + (GMT)
James Simmons <[EMAIL PROTECTED]> wrote:

> Here you go. This patch places the backlight before the framebuffers. You
> will now be able to select using the backlight with various framebuffer 
> drivers.

This doesn't work right for me.  x86_64 allmodconfig enables
CONFIG_FB_ATY_BACKLIGHT but fails to enable FB_BACKLIGHT so things won't
build.

drivers/video/aty/atyfb_base.c: In function 'aty_bl_get_level_brightness':
drivers/video/aty/atyfb_base.c:2130: error: 'struct fb_info' has no member 
named 'bl_curve'

I'm not sure how to fix it, either.  Are things like
CONFIG_FB_ATY_BACKLIGHT _really_ supposed to be pmac-only?

menuconfig says:

 Symbol: FB_BACKLIGHT [=FB_BACKLIGHT]
Selected by: PMAC_BACKLIGHT && (PPC || MAC) && ADB_PMU && FB=y && 
(BROKEN || !PPC64)
 

Surely CONFIG_FB_ATY_BACKLIGHT should depend upon FB_BACKLIGHT?

How come I have CONFIG_BACKLIGHT_CLASS_DEVICE and things like that but
CONFIG_FB_BACKLIGHT=n?

And a `make oldconfig' says

drivers/macintosh/Kconfig:126:warning: 'select' used by config symbol 
'PMAC_BACKLIGHT' refer to undefined symbol 'FB_BACKLIGHT'


Here's what allmodconfig gave:

akpm2:/usr/src/25> grep BACKL .config
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=m
CONFIG_BACKLIGHT_DEVICE=y
CONFIG_FB_NVIDIA_BACKLIGHT=y
CONFIG_FB_RIVA_BACKLIGHT=y
CONFIG_FB_RADEON_BACKLIGHT=y
CONFIG_FB_ATY128_BACKLIGHT=y
CONFIG_FB_ATY_BACKLIGHT=y


Anyway, it seems all screwed up - I'll drop the patch.
-
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.19: OOPS in cat /proc/fs/nfs/exports

[Olaf Titz]

> Will try your patch tomorrow.

...which does not change anything. (As expected.)

Olaf
-
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] optimize o_direct on block device - v3

[Chen, Kenneth W]

This patch implements block device specific .direct_IO method instead
of going through generic direct_io_worker for block device.

direct_io_worker is fairly complex because it needs to handle O_DIRECT
on file system, where it needs to perform block allocation, hole detection,
extents file on write, and tons of other corner cases. The end result is
that it takes tons of CPU time to submit an I/O.

For block device, the block allocation is much simpler and a tight triple
loop can be written to iterate each iovec and each page within the iovec
in order to construct/prepare bio structure and then subsequently submit
it to the block layer.  This significantly speeds up O_D on block device.


Signed-off-by: Ken Chen <[EMAIL PROTECTED]>


---
This is v3 of the patch, I have addressed all the comments from Andrew,
Christoph, and Zach.  Too many to list here for v2->v3 changes.  I've
created 34 test cases specifically for corner cases and tested this patch.
(my monkey test code is on http://kernel-perf.sourceforge.net/diotest).



diff -Nurp linux-2.6.19/fs/block_dev.c linux-2.6.19.ken/fs/block_dev.c
--- linux-2.6.19/fs/block_dev.c 2006-11-29 13:57:37.0 -0800
+++ linux-2.6.19.ken/fs/block_dev.c 2006-12-06 13:16:43.0 -0800
@@ -129,43 +129,188 @@ blkdev_get_block(struct inode *inode, se
return 0;
 }
 
-static int
-blkdev_get_blocks(struct inode *inode, sector_t iblock,
-   struct buffer_head *bh, int create)
+static int blk_end_aio(struct bio *bio, unsigned int bytes_done, int error)
 {
-   sector_t end_block = max_block(I_BDEV(inode));
-   unsigned long max_blocks = bh->b_size >> inode->i_blkbits;
+   struct kiocb *iocb = bio->bi_private;
+   atomic_t *bio_count = >ki_bio_count;
 
-   if ((iblock + max_blocks) > end_block) {
-   max_blocks = end_block - iblock;
-   if ((long)max_blocks <= 0) {
-   if (create)
-   return -EIO;/* write fully beyond EOF */
-   /*
-* It is a read which is fully beyond EOF.  We return
-* a !buffer_mapped buffer
-*/
-   max_blocks = 0;
-   }
+   if (bio_data_dir(bio) == READ)
+   bio_check_pages_dirty(bio);
+   else {
+   bio_release_pages(bio);
+   bio_put(bio);
+   }
+
+   /* iocb->ki_nbytes stores error code from LLDD */
+   if (error)
+   iocb->ki_nbytes = -EIO;
+
+   if (atomic_dec_and_test(bio_count)) {
+   if (iocb->ki_nbytes < 0)
+   aio_complete(iocb, iocb->ki_nbytes, 0);
+   else
+   aio_complete(iocb, iocb->ki_left, 0);
}
 
-   bh->b_bdev = I_BDEV(inode);
-   bh->b_blocknr = iblock;
-   bh->b_size = max_blocks << inode->i_blkbits;
-   if (max_blocks)
-   set_buffer_mapped(bh);
return 0;
 }
 
+#define VEC_SIZE   16
+struct pvec {
+   unsigned short nr;
+   unsigned short idx;
+   struct page *page[VEC_SIZE];
+};
+
+#define PAGES_SPANNED(addr, len)   \
+   (DIV_ROUND_UP((addr) + (len), PAGE_SIZE) - (addr) / PAGE_SIZE);
+
+/*
+ * get page pointer for user addr, we internally cache struct page array for
+ * (addr, count) range in pvec to avoid frequent call to get_user_pages.  If
+ * internal page list is exhausted, a batch count of up to VEC_SIZE is used
+ * to get next set of page struct.
+ */
+static struct page *blk_get_page(unsigned long addr, size_t count, int rw,
+struct pvec *pvec)
+{
+   int ret, nr_pages;
+   if (pvec->idx == pvec->nr) {
+   nr_pages = PAGES_SPANNED(addr, count);
+   nr_pages = min(nr_pages, VEC_SIZE);
+   down_read(>mm->mmap_sem);
+   ret = get_user_pages(current, current->mm, addr, nr_pages,
+rw == READ, 0, pvec->page, NULL);
+   up_read(>mm->mmap_sem);
+   if (ret < 0)
+   return ERR_PTR(ret);
+   pvec->nr = ret;
+   pvec->idx = 0;
+   }
+   return pvec->page[pvec->idx++];
+}
+
 static ssize_t
 blkdev_direct_IO(int rw, struct kiocb *iocb, const struct iovec *iov,
-   loff_t offset, unsigned long nr_segs)
+loff_t pos, unsigned long nr_segs)
 {
-   struct file *file = iocb->ki_filp;
-   struct inode *inode = file->f_mapping->host;
+   struct inode *inode = iocb->ki_filp->f_mapping->host;
+   unsigned blkbits = blksize_bits(bdev_hardsect_size(I_BDEV(inode)));
+   unsigned blocksize_mask = (1<< blkbits) - 1;
+   unsigned long seg = 0;  /* iov segment iterator */
+   unsigned long nvec; /* number of bio vec needed */
+   unsigned long cur_off;  /* offset into current page */
+   unsigned long cur_len;  /* I/O len of current page, 

Re: Kernel panic at boot with recent pci quirks patch

[Alan]

On Wed, 06 Dec 2006 13:50:35 -0600
Frank Sorenson <[EMAIL PROTECTED]> wrote:

> The latest -git tree panics at boot for me.  git-bisect traced the offending 
> commit to:
> 
> 368c73d4f689dae0807d0a2aa74c61fd2b9b075f is first bad commit
> commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f
> Author: Alan Cox <[EMAIL PROTECTED]>
> Date:   Wed Oct 4 00:41:26 2006 +0100
> 
> PCI: quirks: fix the festering mess that claims to handle IDE quirks
> 
> Hardware is a Dell Inspiron E1705 laptop running FC6 x86_64.
> 
> I've attached a netcconsole dump of the panic, as well as lspci output.
> 
> Is there any additional information I can provide?

None needed - there is a patch outstanding for libata which is needed to
go with the PCI updates. Once both hit Linus tree the combined mode
problem you see will vanish. Just quirks went via gregkh pci tree and
libata fixes via libata tree. 


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/

[patch] ACPI, i686, x86_64: fix laptop bootup hang in init_acpi()

[Ingo Molnar]

Subject: [patch] ACPI, i686, x86_64: fix laptop bootup hang in init_acpi()
From: Ingo Molnar <[EMAIL PROTECTED]>

during kernel bootup, a new T60 laptop (CoreDuo, 32-bit) hangs about 
10%-20% of the time in acpi_init():

 Calling initcall 0xc055ce1a: topology_init+0x0/0x2f()
 Calling initcall 0xc055d75e: mtrr_init_finialize+0x0/0x2c()
 Calling initcall 0xc05664f3: param_sysfs_init+0x0/0x175()
 Calling initcall 0xc014cb65: pm_sysrq_init+0x0/0x17()
 Calling initcall 0xc0569f99: init_bio+0x0/0xf4()
 Calling initcall 0xc056b865: genhd_device_init+0x0/0x50()
 Calling initcall 0xc056c4bd: fbmem_init+0x0/0x87()
 Calling initcall 0xc056dd74: acpi_init+0x0/0x1ee()

it's a hard hang that not even an NMI could punch through! 
Frustratingly, adding printks or function tracing to the ACPI code made 
the hangs go away ...

after some time an additional detail emerged: disabling the NMI watchdog 
made these occasional hangs go away.

So i spent the better part of today trying to debug this and trying out 
various theories when i finally found the likely reason for the hang: if 
acpi_ns_initialize_devices() executes an _INI AML method and an NMI 
happens to hit that AML execution in the wrong moment, the machine would 
hang.  (my theory is that this must be some sort of chipset setup method 
doing stores to chipset mmio registers?)

Unfortunately given the characteristics of the hang it was sheer 
impossible to figure out which of the numerous AML methods is impacted 
by this problem.

as a workaround i wrote an interface to disable chipset-based NMIs while 
executing _INI sections - and indeed this fixed the hang. I did a 
boot-loop of 100 separate reboots and none hung - while without the 
patch it would hang every 5-10 attempts. Out of caution i did not touch 
the nmi_watchdog=2 case (it's not related to the chipset anyway and 
didnt hang).

I implemented this for both x86_64 and i686, tested the i686 laptop both 
with nmi_watchdog=1 [which triggered the hangs] and nmi_watchdog=2, and 
tested an Athlon64 box with the 64-bit kernel as well. Everything builds 
and works with the patch applied.

Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
 arch/i386/kernel/nmi.c  |   28 
 arch/x86_64/kernel/nmi.c|   27 +++
 drivers/acpi/namespace/nsinit.c |9 +
 include/linux/nmi.h |9 -
 4 files changed, 72 insertions(+), 1 deletion(-)

Index: linux/arch/i386/kernel/nmi.c
===
--- linux.orig/arch/i386/kernel/nmi.c
+++ linux/arch/i386/kernel/nmi.c
@@ -376,6 +376,34 @@ void enable_timer_nmi_watchdog(void)
}
 }
 
+static void __acpi_nmi_disable(void *__unused)
+{
+   apic_write_around(APIC_LVT0, APIC_DM_NMI | APIC_LVT_MASKED);
+}
+
+/*
+ * Disable timer based NMIs on all CPUs:
+ */
+void acpi_nmi_disable(void)
+{
+   if (atomic_read(_active) && nmi_watchdog == NMI_IO_APIC)
+   on_each_cpu(__acpi_nmi_disable, NULL, 0, 1);
+}
+
+static void __acpi_nmi_enable(void *__unused)
+{
+   apic_write_around(APIC_LVT0, APIC_DM_NMI);
+}
+
+/*
+ * Enable timer based NMIs on all CPUs:
+ */
+void acpi_nmi_enable(void)
+{
+   if (atomic_read(_active) && nmi_watchdog == NMI_IO_APIC)
+   on_each_cpu(__acpi_nmi_enable, NULL, 0, 1);
+}
+
 #ifdef CONFIG_PM
 
 static int nmi_pm_active; /* nmi_active before suspend */
Index: linux/arch/x86_64/kernel/nmi.c
===
--- linux.orig/arch/x86_64/kernel/nmi.c
+++ linux/arch/x86_64/kernel/nmi.c
@@ -360,6 +360,33 @@ void enable_timer_nmi_watchdog(void)
}
 }
 
+static void __acpi_nmi_disable(void *__unused)
+{
+   apic_write(APIC_LVT0, APIC_DM_NMI | APIC_LVT_MASKED);
+}
+
+/*
+ * Disable timer based NMIs on all CPUs:
+ */
+void acpi_nmi_disable(void)
+{
+   if (atomic_read(_active) && nmi_watchdog == NMI_IO_APIC)
+   on_each_cpu(__acpi_nmi_disable, NULL, 0, 1);
+}
+
+static void __acpi_nmi_enable(void *__unused)
+{
+   apic_write(APIC_LVT0, APIC_DM_NMI);
+}
+
+/*
+ * Enable timer based NMIs on all CPUs:
+ */
+void acpi_nmi_enable(void)
+{
+   if (atomic_read(_active) && nmi_watchdog == NMI_IO_APIC)
+   on_each_cpu(__acpi_nmi_enable, NULL, 0, 1);
+}
 #ifdef CONFIG_PM
 
 static int nmi_pm_active; /* nmi_active before suspend */
Index: linux/drivers/acpi/namespace/nsinit.c
===
--- linux.orig/drivers/acpi/namespace/nsinit.c
+++ linux/drivers/acpi/namespace/nsinit.c
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define _COMPONENT  ACPI_NAMESPACE
 ACPI_MODULE_NAME("nsinit")
@@ -537,7 +538,15 @@ acpi_ns_init_one_device(acpi_handle obj_
info->parameter_type = ACPI_PARAM_ARGS;
info->flags = ACPI_IGNORE_RETURN_VALUE;
 
+   /*
+* Some hardware relies on this being executed as atomically
+

[PATCH][resend] Clean up 'make help' output for documentation targets.

[Jesper Juhl]

Here's a patch that cleans up the "make help" output a bit for the 
documentation targets.

Currently the documentation targets are listed completely different than 
all the other targets : 

  Documentation targets:
Linux kernel internal documentation in different formats:
xmldocs (XML DocBook), psdocs (Postscript), pdfdocs (PDF)
htmldocs (HTML), mandocs (man pages, use installmandocs to install)

with this patch they are more in line with the rest of the output : 

  Documentation targets:
   Linux kernel internal documentation in different formats:
htmldocs- HTML
installmandocs  - install man pages generated by mandocs
mandocs - man pages
pdfdocs - PDF
psdocs  - Postscript
xmldocs - XML DocBook


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
Acked-by: Randy Dunlap <[EMAIL PROTECTED]>
---

 Documentation/DocBook/Makefile |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index db9499a..36526a1 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -190,9 +190,13 @@ # Rule to convert a .c file to inline XM
 ###
 # Help targets as used by the top-level makefile
 dochelp:
-   @echo  '  Linux kernel internal documentation in different formats:'
-   @echo  '  xmldocs (XML DocBook), psdocs (Postscript), pdfdocs (PDF)'
-   @echo  '  htmldocs (HTML), mandocs (man pages, use installmandocs to 
install)'
+   @echo  ' Linux kernel internal documentation in different formats:'
+   @echo  '  htmldocs- HTML'
+   @echo  '  installmandocs  - install man pages generated by mandocs'
+   @echo  '  mandocs - man pages'
+   @echo  '  pdfdocs - PDF'
+   @echo  '  psdocs  - Postscript'
+   @echo  '  xmldocs - XML DocBook'
 
 ###
 # Temporary files left by various tools


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] eCryptfs: Public key; packet management

[Michael Halcrow]

Public key support code. This reads and writes packets in the header
that contain public key encrypted file keys. It calls the messaging
code in the previous patch to send and receive encryption and
decryption request packets from the userspace daemon.

Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]>
---

 fs/ecryptfs/Makefile  |2 
 fs/ecryptfs/ecryptfs_kernel.h |7 
 fs/ecryptfs/keystore.c|  784 +
 fs/ecryptfs/main.c|   49 ++-
 fs/ecryptfs/messaging.c   |   10 -
 fs/ecryptfs/mmap.c|   91 -
 fs/ecryptfs/netlink.c |4 
 7 files changed, 777 insertions(+), 170 deletions(-)

9979020958c5ee2d0d671cf47144a4a93def964d
diff --git a/fs/ecryptfs/Makefile b/fs/ecryptfs/Makefile
index ca65624..1f11072 100644
--- a/fs/ecryptfs/Makefile
+++ b/fs/ecryptfs/Makefile
@@ -4,4 +4,4 @@ #
 
 obj-$(CONFIG_ECRYPT_FS) += ecryptfs.o
 
-ecryptfs-objs := dentry.o file.o inode.o main.o super.o mmap.o crypto.o 
keystore.o debug.o
+ecryptfs-objs := dentry.o file.o inode.o main.o super.o mmap.o crypto.o 
keystore.o messaging.o netlink.o debug.o
diff --git a/fs/ecryptfs/ecryptfs_kernel.h b/fs/ecryptfs/ecryptfs_kernel.h
index 2bae036..3d78107 100644
--- a/fs/ecryptfs/ecryptfs_kernel.h
+++ b/fs/ecryptfs/ecryptfs_kernel.h
@@ -32,6 +32,7 @@ #include 
 #include 
 #include 
 #include 
+#include 
 
 /* Version verification for shared data structures w/ userspace */
 #define ECRYPTFS_VERSION_MAJOR 0x00
@@ -46,7 +47,8 @@ #define ECRYPTFS_VERSIONING_PUBKEY 0x000
 #define ECRYPTFS_VERSIONING_PLAINTEXT_PASSTHROUGH 0x0004
 #define ECRYPTFS_VERSIONING_POLICY 0x0008
 #define ECRYPTFS_VERSIONING_MASK (ECRYPTFS_VERSIONING_PASSPHRASE \
-  | ECRYPTFS_VERSIONING_PLAINTEXT_PASSTHROUGH)
+  | ECRYPTFS_VERSIONING_PLAINTEXT_PASSTHROUGH \
+  | ECRYPTFS_VERSIONING_PUBKEY)
 
 #define ECRYPTFS_MAX_PASSWORD_LENGTH 64
 #define ECRYPTFS_MAX_PASSPHRASE_BYTES ECRYPTFS_MAX_PASSWORD_LENGTH
@@ -561,7 +563,8 @@ int ecryptfs_close_lower_file(struct fil
 
 int ecryptfs_process_helo(unsigned int transport, uid_t uid, pid_t pid);
 int ecryptfs_process_quit(uid_t uid, pid_t pid);
-int ecryptfs_process_response(struct ecryptfs_message *msg, pid_t pid, u32 
seq);
+int ecryptfs_process_response(struct ecryptfs_message *msg, uid_t uid,
+ pid_t pid, u32 seq);
 int ecryptfs_send_message(unsigned int transport, char *data, int data_len,
  struct ecryptfs_msg_ctx **msg_ctx);
 int ecryptfs_wait_for_response(struct ecryptfs_msg_ctx *msg_ctx,
diff --git a/fs/ecryptfs/keystore.c b/fs/ecryptfs/keystore.c
index c3746f5..84e9907 100644
--- a/fs/ecryptfs/keystore.c
+++ b/fs/ecryptfs/keystore.c
@@ -7,6 +7,7 @@
  * Copyright (C) 2004-2006 International Business Machines Corp.
  *   Author(s): Michael A. Halcrow <[EMAIL PROTECTED]>
  *  Michael C. Thompson <[EMAIL PROTECTED]>
+ *  Trevor S. Highland <[EMAIL PROTECTED]>
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License as
@@ -64,26 +65,6 @@ int process_request_key_err(long err_cod
return rc;
 }
 
-static void wipe_auth_tok_list(struct list_head *auth_tok_list_head)
-{
-   struct list_head *walker;
-   struct ecryptfs_auth_tok_list_item *auth_tok_list_item;
-
-   walker = auth_tok_list_head->next;
-   while (walker != auth_tok_list_head) {
-   auth_tok_list_item =
-   list_entry(walker, struct ecryptfs_auth_tok_list_item,
-  list);
-   walker = auth_tok_list_item->list.next;
-   memset(auth_tok_list_item, 0,
-  sizeof(struct ecryptfs_auth_tok_list_item));
-   kmem_cache_free(ecryptfs_auth_tok_list_item_cache,
-   auth_tok_list_item);
-   }
-}
-
-struct kmem_cache *ecryptfs_auth_tok_list_item_cache;
-
 /**
  * parse_packet_length
  * @data: Pointer to memory containing length at offset
@@ -102,12 +83,12 @@ static int parse_packet_length(unsigned 
(*size) = 0;
if (data[0] < 192) {
/* One-byte length */
-   (*size) = data[0];
+   (*size) = (unsigned char)data[0];
(*length_size) = 1;
} else if (data[0] < 224) {
/* Two-byte length */
-   (*size) = ((data[0] - 192) * 256);
-   (*size) += (data[1] + 192);
+   (*size) = (((unsigned char)(data[0]) - 192) * 256);
+   (*size) += ((unsigned char)(data[1]) + 192);
(*length_size) = 2;
} else if (data[0] == 255) {
/* Five-byte length; we're not supposed to see this */
@@ -154,6 +135,499 @@ static int write_packet_length(char *des
return rc;
 }
 
+static int
+write_tag_64_packet(char *signature, 

Re: Areca driver 2.6.19 on x86_64

[Bron Gondwana]

On Wed, Dec 06, 2006 at 05:51:32PM +0100, [EMAIL PROTECTED] wrote:
> OS distro used:
> CentOS 4.4 x86_64
> Kernel 2.6.19 with hand-crafted config, that we are
> able to use successfully with kernel 2.6.16.20.

What patches were you applying to 2.6.16.20, since that didn't
have an Areca driver in it I presume you're at least using that.

> Have you any suggestions to resolve this issue ?

32 bit kernel?  I'm somewhat serious here, depending what applications
you're running on the machine.

Otherwise, no clue sorry - we're running 32 bit kernels everywhere
even on the couple of new Core machines we have.

Bron.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] eCryptfs: Public key; transport mechanism

[Michael Halcrow]

This is a re-submission of the same public key patches (updated for
2.6.19-rc6-mm2) that were submitted for review a while back.

This is the transport code for public key functionality in
eCryptfs. It manages encryption/decryption request queues with a
transport mechanism. Currently, netlink is the only implemented
transport.

Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]>
---

 fs/ecryptfs/ecryptfs_kernel.h |  101 
 fs/ecryptfs/messaging.c   |  505 +
 fs/ecryptfs/netlink.c |  255 +
 include/linux/netlink.h   |1 
 4 files changed, 859 insertions(+), 3 deletions(-)
 create mode 100644 fs/ecryptfs/messaging.c
 create mode 100644 fs/ecryptfs/netlink.c

fa0a4f8f4601b6c005fcaa628f2d74c6466ec54d
diff --git a/fs/ecryptfs/ecryptfs_kernel.h b/fs/ecryptfs/ecryptfs_kernel.h
index 870a65b..2bae036 100644
--- a/fs/ecryptfs/ecryptfs_kernel.h
+++ b/fs/ecryptfs/ecryptfs_kernel.h
@@ -6,6 +6,8 @@
  * Copyright (C) 2001-2003 Stony Brook University
  * Copyright (C) 2004-2006 International Business Machines Corp.
  *   Author(s): Michael A. Halcrow <[EMAIL PROTECTED]>
+ *  Trevor S. Highland <[EMAIL PROTECTED]>
+ *  Tyler Hicks <[EMAIL PROTECTED]>
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License as
@@ -34,7 +36,7 @@ #include 
 /* Version verification for shared data structures w/ userspace */
 #define ECRYPTFS_VERSION_MAJOR 0x00
 #define ECRYPTFS_VERSION_MINOR 0x04
-#define ECRYPTFS_SUPPORTED_FILE_VERSION 0x01
+#define ECRYPTFS_SUPPORTED_FILE_VERSION 0x02
 /* These flags indicate which features are supported by the kernel
  * module; userspace tools such as the mount helper read
  * ECRYPTFS_VERSIONING_MASK from a sysfs handle in order to determine
@@ -59,10 +61,24 @@ #define ECRYPTFS_PASSWORD_SIG_SIZE ECRYP
 #define ECRYPTFS_MAX_KEY_BYTES 64
 #define ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES 512
 #define ECRYPTFS_DEFAULT_IV_BYTES 16
-#define ECRYPTFS_FILE_VERSION 0x01
+#define ECRYPTFS_FILE_VERSION 0x02
 #define ECRYPTFS_DEFAULT_HEADER_EXTENT_SIZE 8192
 #define ECRYPTFS_DEFAULT_EXTENT_SIZE 4096
 #define ECRYPTFS_MINIMUM_HEADER_EXTENT_SIZE 8192
+#define ECRYPTFS_DEFAULT_MSG_CTX_ELEMS 32
+#define ECRYPTFS_DEFAULT_SEND_TIMEOUT HZ
+#define ECRYPTFS_MAX_MSG_CTX_TTL (HZ*3)
+#define ECRYPTFS_NLMSG_HELO 100
+#define ECRYPTFS_NLMSG_QUIT 101
+#define ECRYPTFS_NLMSG_REQUEST 102
+#define ECRYPTFS_NLMSG_RESPONSE 103
+#define ECRYPTFS_MAX_PKI_NAME_BYTES 16
+#define ECRYPTFS_DEFAULT_NUM_USERS 4
+#define ECRYPTFS_MAX_NUM_USERS 32768
+#define ECRYPTFS_TRANSPORT_NETLINK 0
+#define ECRYPTFS_TRANSPORT_CONNECTOR 1
+#define ECRYPTFS_TRANSPORT_RELAYFS 2
+#define ECRYPTFS_DEFAULT_TRANSPORT ECRYPTFS_TRANSPORT_NETLINK
 
 #define RFC2440_CIPHER_DES3_EDE 0x02
 #define RFC2440_CIPHER_CAST_5 0x03
@@ -76,6 +92,7 @@ #define RFC2440_CIPHER_CAST_6 0x0b
 #define ECRYPTFS_SET_FLAG(flag_bit_vector, flag) (flag_bit_vector |= (flag))
 #define ECRYPTFS_CLEAR_FLAG(flag_bit_vector, flag) (flag_bit_vector &= ~(flag))
 #define ECRYPTFS_CHECK_FLAG(flag_bit_vector, flag) (flag_bit_vector & (flag))
+#define RFC2440_CIPHER_RSA 0x01
 
 /**
  * For convenience, we may need to pass around the encrypted session
@@ -113,6 +130,14 @@ #define ECRYPTFS_SESSION_KEY_ENCRYPTION_
 
 enum ecryptfs_token_types {ECRYPTFS_PASSWORD, ECRYPTFS_PRIVATE_KEY};
 
+struct ecryptfs_private_key {
+   u32 key_size;
+   u32 data_len;
+   u8 signature[ECRYPTFS_PASSWORD_SIG_SIZE + 1];
+   char pki_type[ECRYPTFS_MAX_PKI_NAME_BYTES + 1];
+   u8 data[];
+};
+
 /* May be a password or a private key */
 struct ecryptfs_auth_tok {
u16 version; /* 8-bit major and 8-bit minor */
@@ -122,7 +147,7 @@ struct ecryptfs_auth_tok {
u8 reserved[32];
union {
struct ecryptfs_password password;
-   /* Private key is in future eCryptfs releases */
+   struct ecryptfs_private_key private_key;
} token;
 } __attribute__ ((packed));
 
@@ -177,8 +202,13 @@ #define ECRYPTFS_DEFAULT_CIPHER "aes"
 #define ECRYPTFS_DEFAULT_KEY_BYTES 16
 #define ECRYPTFS_DEFAULT_CHAINING_MODE CRYPTO_TFM_MODE_CBC
 #define ECRYPTFS_DEFAULT_HASH "md5"
+#define ECRYPTFS_TAG_1_PACKET_TYPE 0x01
 #define ECRYPTFS_TAG_3_PACKET_TYPE 0x8C
 #define ECRYPTFS_TAG_11_PACKET_TYPE 0xED
+#define ECRYPTFS_TAG_64_PACKET_TYPE 0x40
+#define ECRYPTFS_TAG_65_PACKET_TYPE 0x41
+#define ECRYPTFS_TAG_66_PACKET_TYPE 0x42
+#define ECRYPTFS_TAG_67_PACKET_TYPE 0x43
 #define MD5_DIGEST_SIZE 16
 
 /**
@@ -271,6 +301,45 @@ struct ecryptfs_auth_tok_list_item {
struct ecryptfs_auth_tok auth_tok;
 };
 
+struct ecryptfs_message {
+   u32 index;
+   u32 data_len;
+   u8 data[];
+};
+
+struct ecryptfs_msg_ctx {
+#define ECRYPTFS_MSG_CTX_STATE_FREE  0x0001
+#define ECRYPTFS_MSG_CTX_STATE_PENDING   0x0002
+#define ECRYPTFS_MSG_CTX_STATE_DONE  0x0003
+   u32 state;
+   

[PATCH 2.6.19-git7] sata_promise: new EH conversion, take 2

[Mikael Pettersson]

This patch converts sata_promise to use new-style libata error
handling on Promise SATA chips, for both SATA and PATA ports.

* ATA_FLAG_SRST is no longer set
* ->phy_reset is no longer set as it is unused when ->error_handler
   is present, and pdc_sata_phy_reset() has been removed
* pdc_freeze() masks interrupts and halts DMA via PDC_CTLSTAT
* pdc_thaw() clears interrupt status in PDC_INT_SEQMASK and then
  unmasks interrupts in PDC_CTLSTAT
* pdc_error_handler() reinitialises the port if it isn't frozen,
  and then invokes ata_do_eh() with standard {s,}ata reset methods
* pdc_post_internal_cmd() resets the port in case of errors
* the PATA-only 20619 chip continues to use old-style EH:
  not by necessity but simply because I don't have documentation
  for it or any way to test it

Since the previous version pdc_error_handler() has been rewritten
and it now mostly matches ahci and sata_sil24. In case anyone
wonders: the call to pdc_reset_port() isn't a heavy-duty reset,
it's a light-weight reset to quickly put a port into a sane state.

The discussion about the PCI flushes in pdc_freeze() and pdc_thaw()
seemed to end with a consensus that the flushes are OK and not
obviously redundant, so I decided to keep them for now.

This patch was prepared against 2.6.19-git7, but it also applies
to 2.6.19 + libata #upstream, with or without the revised sata_promise
cleanup patch I recently submitted.

This patch does conflict with the #promise-sata-pata patch:
this patch removes pdc_sata_phy_reset() while #promise-sata-pata
modifies it. The correct patch resolution is to remove the function.

Tested on 2037x and 2057x chips, with PATA patches on top and disks
on both SATA and PATA ports.

Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>

--- linux-2.6.19-git7/drivers/ata/sata_promise.c.~1~2006-12-06 
23:29:14.0 +0100
+++ linux-2.6.19-git7/drivers/ata/sata_promise.c2006-12-06 
23:29:43.0 +0100
@@ -72,9 +72,12 @@ enum {
 
PDC_HAS_PATA= (1 << 1), /* PDC20375/20575 has PATA */
 
+   /* PDC_CTLSTAT bit definitions */
+   PDC_DMA_ENABLE  = (1 << 7),
+   PDC_IRQ_DISABLE = (1 << 10),
PDC_RESET   = (1 << 11), /* HDMA reset */
 
-   PDC_COMMON_FLAGS= ATA_FLAG_NO_LEGACY | ATA_FLAG_SRST |
+   PDC_COMMON_FLAGS= ATA_FLAG_NO_LEGACY |
  ATA_FLAG_MMIO | ATA_FLAG_NO_ATAPI |
  ATA_FLAG_PIO_POLLING,
 
@@ -101,13 +104,16 @@ static void pdc_eng_timeout(struct ata_p
 static int pdc_port_start(struct ata_port *ap);
 static void pdc_port_stop(struct ata_port *ap);
 static void pdc_pata_phy_reset(struct ata_port *ap);
-static void pdc_sata_phy_reset(struct ata_port *ap);
 static void pdc_qc_prep(struct ata_queued_cmd *qc);
 static void pdc_tf_load_mmio(struct ata_port *ap, const struct ata_taskfile 
*tf);
 static void pdc_exec_command_mmio(struct ata_port *ap, const struct 
ata_taskfile *tf);
 static void pdc_irq_clear(struct ata_port *ap);
 static unsigned int pdc_qc_issue_prot(struct ata_queued_cmd *qc);
 static void pdc_host_stop(struct ata_host *host);
+static void pdc_freeze(struct ata_port *ap);
+static void pdc_thaw(struct ata_port *ap);
+static void pdc_error_handler(struct ata_port *ap);
+static void pdc_post_internal_cmd(struct ata_queued_cmd *qc);
 
 
 static struct scsi_host_template pdc_ata_sht = {
@@ -136,11 +142,12 @@ static const struct ata_port_operations 
.exec_command   = pdc_exec_command_mmio,
.dev_select = ata_std_dev_select,
 
-   .phy_reset  = pdc_sata_phy_reset,
-
.qc_prep= pdc_qc_prep,
.qc_issue   = pdc_qc_issue_prot,
-   .eng_timeout= pdc_eng_timeout,
+   .freeze = pdc_freeze,
+   .thaw   = pdc_thaw,
+   .error_handler  = pdc_error_handler,
+   .post_internal_cmd  = pdc_post_internal_cmd,
.data_xfer  = ata_mmio_data_xfer,
.irq_handler= pdc_interrupt,
.irq_clear  = pdc_irq_clear,
@@ -198,7 +205,7 @@ static const struct ata_port_info pdc_po
/* board_20619 */
{
.sht= _ata_sht,
-   .flags  = PDC_COMMON_FLAGS | ATA_FLAG_SLAVE_POSS,
+   .flags  = PDC_COMMON_FLAGS | ATA_FLAG_SRST | 
ATA_FLAG_SLAVE_POSS,
.pio_mask   = 0x1f, /* pio0-4 */
.mwdma_mask = 0x07, /* mwdma0-2 */
.udma_mask  = 0x7f, /* udma0-6 ; FIXME */
@@ -366,12 +373,6 @@ static void pdc_reset_port(struct ata_po
readl(mmio);/* flush */
 }
 
-static void pdc_sata_phy_reset(struct ata_port *ap)
-{
-   pdc_reset_port(ap);
-   sata_phy_reset(ap);
-}
-
 static void pdc_pata_cbl_detect(struct ata_port *ap)
 {
u8 tmp;
@@ -439,6 +440,61 @@ static void pdc_qc_prep(struct ata_queue
}

dentry cache grows to really large number on 64bit machine

[Kunal Trivedi]

Hi,
I am running 2.6.18 kernel on 64 bit AMD machine. (procinfo attached
at the end of the mail). One of the things I have noticed that
dentry_cache grows really fast under certain code path.
So, far I have not seen any problems, but I would like to get some
more input on this subject. Is it okay for dentry_cache to grow that
much ?

I've run following program for an ~1.00 hour. And my slabinfo shows following.

# cat /proc/slabinfo | grep dentry
dentry_cache  5228333 5228333224   171 : tunables  120
608 : slabdata 307549 307549  0


# cat /proc/meminfo
MemTotal:  8173080 kB
MemFree:   6787852 kB
Buffers: 42048 kB
Cached:  72616 kB
SwapCached:  0 kB
Active:  88608 kB
Inactive:29796 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:  8173080 kB
LowFree:   6787852 kB
SwapTotal: 2096472 kB
SwapFree:  2096472 kB
Dirty:  48 kB
Writeback:   0 kB
AnonPages:3716 kB
Mapped:   3336 kB
Slab:  1251292 kB
PageTables:192 kB
NFS_Unstable:0 kB
Bounce:  0 kB
CommitLimit:  10269552 kB
Committed_AS:11500 kB
VmallocTotal: 34359738367 kB
VmallocUsed:  1272 kB
VmallocChunk: 34359737015 kB
HugePages_Total: 0
HugePages_Free:  0
HugePages_Rsvd:  0
Hugepagesize: 2048 kB


int
main()
{
   int fd;
   char fname[] = "/tmp/proc-output-XX";

   fd = mkstemp(fname);
   close(fd);
   unlink(fname);
   return 0;
}

Please advice,

Thanks
-Kunal
-
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/

usage of linux/types.h wrt to install_headers

[Mike Frysinger]

there are a plethora of headers that cannot be included straight due
to the usage of __ types (like __u32) without first including
linux/types.h ... so the question is, should all of these headers be
fixed to properly pull in linux/types.h first or are users expected to
"just know" the correct order of headers ?  in my mind, pretty much
every header is fair game for straight "#include " usage and
requiring a list of headers to be pulled in properly is ignoring the
problem ...
-mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] OMAP: I2C driver for TI OMAP boards #3

[Tony Lindgren]

Hi,

* Jean Delvare <[EMAIL PROTECTED]> [061204 09:49]:
> Hi Tony, all,
> 
> On Thu, 10 Aug 2006 16:19:26 +0300, Tony Lindgren wrote:
> > * Jean Delvare <[EMAIL PROTECTED]> [060810 11:30]:
> > > I've now taken Komal's patch (#4). Here is a proposed patch which brings
> > > the prescaler computation formula in line with your comment and table
> > > above. It could be applied on top of Komal's patch unless it causes a
> > > problem on some of the OMAP systems. For XOR = 13 MHz, it changes the
> > > prescaler from 0 to 1. For XOR = 19.2 MHz it changes the prescaler from
> > > 2 to 1.
> > 
> > OK cool. As far as I'm concerned, I'm fine with it too:
> > Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
> >  
> > > I don't have any hardware to test it, though. If it happens to be
> > > better to be slightly over 12 MHz than slightly below 7 MHz, the
> > > "> 1200" condition below can be replaced with "> 1400".
> > 
> > Thanks, we'll test it on various omaps and let you know if it works.
> 
> Any news on this? I still have this patch in my local tree. Should I
> push it into Linux 2.6.20?
> 
> i2c: Fix OMAP clock prescaler to match the comment
> 
> Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
> Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
> ---
>  drivers/i2c/busses/i2c-omap.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> --- linux-2.6.18-rc4.orig/drivers/i2c/busses/i2c-omap.c   2006-08-10 
> 09:56:54.0 +0200
> +++ linux-2.6.18-rc4/drivers/i2c/busses/i2c-omap.c2006-08-10 
> 10:12:03.0 +0200
> @@ -231,8 +231,8 @@
>* 13   2   1
>* 19.2 2   1
>*/
> - if (fclk_rate > 1600)
> - psc = (fclk_rate + 800) / 1200;
> + if (fclk_rate > 1200)
> + psc = fclk_rate / 1200;
>   }
>  
>   /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */

Sorry for the delay in replying. Yes, it's safe to push. When the original
code was done, the max limit of 12MHz was ignored.

Regards,

Tony
-
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/