powernow-k8: Let cpufreq driver handle affected CPUs

Let the cpufreq driver manage AMD Dual-Core CPUs being tied together.

Since cpufreq driver's affected CPUs data, cpufreq_policy->cpus, already
knows about which cores are tied together, powernow driver does not have
keep its internal data for every core.  (even a pointer.. it will never
be called on)  Telling cpufreq driver about cpu_core_map at init time is
sufficient.
Signed-off-by: NJacob Shin <jacob.shin@amd.com>
Signed-off-by: NDave Jones <davej@redhat.com>

Signed-off-by: NDave Jones <davej@redhat.com>

We already have one of these declared, so use it, instead
of declaring a second one for no good reason.
Signed-off-by: NDave Jones <davej@redhat.com>

Signed-off-by: NDave Jones <davej@redhat.com>

obscure corruption case

SGI-PV: 942658
SGI-Modid: xfs-linux-melb:xfs-kern:207119a
Signed-off-by: NEric Sandeen <sandeen@sgi.com>
Signed-off-by: NNathan Scott <nathans@sgi.com>

regressed recently via the fix for inherited quota inode attributes.

SGI-PV: 947312
SGI-Modid: xfs-linux-melb:xfs-kern:25318a
Signed-off-by: NNathan Scott <nathans@sgi.com>

fix.  Noticed by Roger Willcocks.

SGI-PV: 949821
SGI-Modid: xfs-linux-melb:xfs-kern:25257a
Signed-off-by: NNathan Scott <nathans@sgi.com>

In 295f7324 I moved defer_accept from
tcp_sock to request_queue and mistakingly reset it at reqsl_queue_alloc, causing
calls to setsockopt(TCP_DEFER_ACCEPT ) to be lost after bind, the fix is to
remove the zeroing of rskq_defer_accept from reqsl_queue_alloc.

Thanks to Alexandra N. Kossovsky <Alexandra.Kossovsky@oktetlabs.ru> for
reporting and testing the suggested fix.
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The nfnetlink_log infrastructure changes broke compatiblity of the LOG
targets. They currently use whatever log backend was registered first,
which means that if ipt_ULOG was loaded first, no messages will be printed
to the ring buffer anymore.

Restore compatiblity by using the old log functions by default and only use
the nf_log backend if the user explicitly said so.
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The comparison wants to find out if the last list iteration reached the
end of the list. It needs to compare the iterator with the list head to
do this, not the element it is looking for.
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The only point of registering a queue handler is to provide an outfn,
so there is no need to check for it.
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Packets should be rerouted when they come back from userspace, not before.
Also move the queue_rerouters to RCU to avoid taking the queue_handler_lock
for each reinjected packet.
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Every rerouter needs to provide a save and a reroute function, we don't
need to check for them. But we do need to check if a rerouter is registered
at all for the current family, with bridging for example packets of
unregistered families can hit nf_queue.
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use the registered data structure instead of copying it.
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The only reason post_input exists at all is that it gives us the
potential to adjust the checksums incrementally in future which
we ought to do.

However, after thinking about it for a bit we can adjust the
checksums without using this post_input stuff at all.  The crucial
point is that only the inner-most NAT-T SA needs to be considered
when adjusting checksums.  What's more, the checksum adjustment
comes down to a single u32 due to the linearity of IP checksums.

We just happen to have a spare u32 lying around in our skb structure :)
When ip_summed is set to CHECKSUM_NONE on input, the value of skb->csum
is currently unused.  All we have to do is to make that the checksum
adjustment and voila, there goes all the post_input and decap structures!

I've left in the decap data structures for now since it's intricately
woven into the sec_path stuff.  We can kill them later too.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We used to keep sg on the stack which is why the extra block was useful.
We've long since stopped doing that so let's kill the block and save
some indentation.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Some Sun parts don't have PCI_VENDOR_ID_SUN in the subsystem
vendor ID.  So add another fallback test, which is the name
of the OBP firmware device tree node.  If it's a Sun part we'll
get "network", else it will be named "ethernet".
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

    
Not just cleanup but also fixes O32 readdir(2) emulation.
Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

    
Reported and initial fix by Thomas Koeller <thomas.koeller@baslerweb.com>,
rewritten by me.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

    
A recent change requires cpu_possible_map to be initialized before
smp_sched_init() but most MIPS platforms were initializing their
processors in the prom_prepare_cpus callback of smp_prepare_cpus.  The
simple fix of calling prom_prepare_cpus from one of the earlier SMP
initialization hooks doesn't work well either since IPIs may require
init_IRQ() to have completed, so bit the bullet and split
prom_prepare_cpus into two initialization functions, plat_smp_setup
which is called early from setup_arch and plat_prepare_cpus called where
prom_prepare_cpus used to be called.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

With the latest kernels, I experienced some strange corruption, some
'*****' being randomly inserted in the character flow, like this:

	ashes:~#
	ashes:~#
	a*******shes:~#
	ashes:~#
	ashes:~#

Further investigation shows that the problem was introduced during
Alan's "TTY layer buffering revamp" patch, the amount of data to be
copied being reduced after buffer allocation.  Moving the count fixup
around solves the problem.
Signed-off-by: NMarc Zyngier <maz@misterjones.org>
Approved-by: NRogier Wolff <R.E.Wolff@BitWizard.nl>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Commit 9ec4b1f3 made kprobes not compile
without module support, so just make that clear in the Kconfig file.

Also, since it's marked EXPERIMENTAL, make that dependency explicit too.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The change to kernel/sched.c's init code to use for_each_cpu()
requires that the cpu_possible_map be setup much earlier.

Set it up via setup_arch(), constrained to NR_CPUS, and later
constrain it to max_cpus in smp_prepare_cpus().

This fixes SMP booting on sparc64.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 9c869eda broke voyager again
rather subtly because it already had its own topology exporting
functions, so now each CPU gets registered twice.

I think we can actually use the generic ones, so I don't propose
reverting it.  The attached should eliminate the voyager topology
functions in favour of the generic ones.

I also added a define to ensure voyager is never hotplug CPU (we don't
have the support in the SMP harness).
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The commit e2c03888 added
setup_additional_cpus to setup.c but this is only defined if
CONFIG_HOTPLUG_CPU is set.  This patch changes the #ifdef to reflect that.
Signed-off-by: NBrian Magnuson <magnuson@rcn.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

RTC_IRQP_SET/RTC_EPOCH_SET don't take a pointer to an argument, but the
argument itself.  This actually simplifies the code and makes it work.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The previous experiment for using apicmaintimer on ATI systems didn't
work out very well.  In particular laptops with C2/C3 support often
don't let it tick during idle, which makes it useless.  There were also
some other bugs that made the apicmaintimer often not used at all.

I tried some other experiments - running timer over RTC and some other
things but they didn't really work well neither.

I rechecked the specs now and it turns out this simple change is
actually enough to avoid the double ticks on the ATI systems.  We just
turn off IRQ 0 in the 8254 and only route it directly using the IO-APIC.

I tested it on a few ATI systems and it worked there.  In fact it worked
on all chipsets (NVidia, Intel, AMD, ATI) I tried it on.

According to the ACPI spec routing should always work through the
IO-APIC so I think it's the correct thing to do anyways (and most of the
old gunk in check_timer should be thrown away for x86-64).

But for 2.6.16 it's best to do a fairly minimal change:
 - Use the known to be working everywhere-but-ATI IRQ0 both over 8254
   and IO-APIC setup everywhere
 - Except on ATI disable IRQ0 in the 8254
 - Remove the code to select apicmaintimer on ATI chipsets
 - Add some boot options to allow to override this (just paranoia)

In 2.6.17 I hope to switch the default over to this for everybody.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

SMP time selection originally ran after all CPUs were brought up because
it needed to know the number of CPUs to decide if it needs an MP safe
timer or not.

This is not needed anymore because we know present CPUs early.

This fixes a couple of problems:
 - apicmaintimer didn't always work because it relied on state that was
   set up time_init_gtod too late.
 - The output for the used timer in early kernel log was misleading
   because time_init_gtod could actually change it later.  Now always
   print the final timer choice
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

It didn't set up the CPU possible map early enough, so the
option didn't actually work.

Noticed by Heiko Carstens
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

ACPI is initialized very early on x86-64, before the DMI code is
initialized.  This means it would often discover a 0 year and then turn
off ACPI because it thought the BIOS was too old.  Some systems don't
boot without ACPI so this was a problem.

I have a full fix by adding new very early DMI detection, but it needs
more testing before it can be merged.  For 2.6.16 let's just turn the
check off.  It never made much sense anyways because there are no x86-64
systems older than 2002 or so and they generally all have working ACPI.

Cc: len.brown@intel.com
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

[description from AK]

Old check for the IO-APIC watchdog during the timer check was wrong -
it obviously should only drop into this if the IO-APIC watchdog is used.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>