Linux v2.6.16

Linux v2.6.16

[Linus Torvalds]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 6722 bytes --]


Ok, it's being mirrored out right now, the git tree should already be all 
there, the tar-file and patches are still uploading.

Not a lot of changes since -rc6, but there's various random one-liners 
here and there (a number of Coverity bugs found, for example), and there 
are small MIPS and PowerPC updates.

Appended is the shortlog from 2.6.16-rc6, the full log (from 2.6.15) is on 
the web/ftp-sites. 

It looks like both Fedora and SuSE end up using a kernel that is pretty 
close to this 2.6.16 release, so let's all hope it's good. Give it a good 
testing, please,

		Linus

---
Adrian Bunk:
      [TG3] tg3_bus_string(): remove dead code
      SUNRPC: fix a NULL pointer dereference in net/sunrpc/clnt.c
      fs/namespace.c:dup_namespace(): fix a use after free

Al Viro:
      Fix ext2 readdir f_pos re-validation logic

Albrecht Dreß:
      [ARM] 3358/1: [S3C2410] add missing SPI DMA resources

Alessandro Zummo:
      [ARM] 3354/1: NAS100d: fix power led handling
      [ARM] 3355/1: NSLU2: remove propmt depends
      [ARM] 3350/1: Enable 1-wire on ARM

Alexey Kuznetsov:
      [NET]: Fix race condition in sk_wait_event().

Andi Kleen:
      x86-64: Fix up handling of non canonical user RIPs

Andrea Arcangeli:
      Remove obsolete CREDITS address

Andreas Herrmann:
      [SCSI] zfcp: correctly set this_id for hosts
      [SCSI] scsi_transport_fc: fix FC_HOST_NUM_ATTRS
      [SCSI] zfcp: fix device registration issues

Atsushi Nemoto:
      [MIPS] local_r4k_flush_cache_page fix

Ben Dooks:
      [ARM] 3363/1: [cleanup] process.c - fix warnings
      [ARM] 3364/1: [cleanup] warning fix - definitions for enable_hlt and disable_hlt
      [ARM] 3365/1: [cleanup] header for compat.c exported functions
      [ARM] 3362/1: [cleanup] - duplicate decleration of mem_fclk_21285

Benjamin Herrenschmidt:
      macintosh: correct AC Power info in /proc/pmu/info
      powerpc: enable NAP only on cpus who support it to avoid memory corruption

Brian Haley:
      [IPV6]: fix ipv6_saddr_score struct element

Catalin Marinas:
      [ARM] 3356/1: Workaround for the ARM1136 I-cache invalidation problem

Christoph Lameter:
      page migration: fail if page is in a vma flagged VM_LOCKED
      Page migration documentation update
      Consistent capabilites associated with MPOL_MOVE_ALL
      page migration: Fail with error if swap not setup
      time_interpolator: add __read_mostly
      fix race in pagevec_strip?

Dave Jones:
      [TUN]: Fix leak in tun_get_user()

Dave Kleikamp:
      JFS: Take logsync lock before testing mp->lsn

Dave Peterson:
      EDAC: disable sysfs interface

David Brownell:
      mtd_dataflash, fix block vs page erase

David S. Miller:
      [TCP]: Fix tcp_tso_should_defer() when limit>=65536
      e1000 endianness bugs

Dominik Brodowski:
      [SCSI] scsi: aha152x pcmcia driver needs spi transport

Eric Van Hensbergen:
      v9fs: fix overzealous dropping of dentry which breaks dcache

Eric W. Biederman:
      unshare: Use rcu_assign_pointer when setting sighand

GOTO Masanori:
      Fix sigaltstack corruption among cloned threads

Greg Smith:
      "s390: multiple subchannel sets support" fix

Gregor Maier:
      [NETFILTER]: Fix wrong option spelling in Makefile for CONFIG_BRIDGE_EBT_ULOG

Herbert Xu:
      [TCP]: Fix zero port problem in IPv6

Hong Liu:
      ieee80211: Fix QoS is not active problem

Hugh Dickins:
      fix free swap cache latency

Jesse Brandeburg:
      e100: fix eeh on pseries during ethtool -t

John Rose:
      powerpc: properly configure DDR/P5IOC children devs

Kevin Corry:
      dm stripe: Fix bounds

Linus Torvalds:
      Revert "x86-64: Fix up handling of non canonical user RIPs"
      Linux 2.6.16

Maneesh Soni:
      Plug kdump shutdown race window

Markus Rechberger:
      Fixed em28xx based system lockup

Matej Kupljen:
      [MIPS] Simple patch to power off DBAU1200

Matthew Wilcox:
      [SCSI] Add Brownie to blacklist

Michael Chan:
      [TG3]: 40-bit DMA workaround part 2

Michael Ellerman:
      powerpc: Clarify wording for CRASH_DUMP Kconfig option

Michael Hunold:
      Restore tuning capabilities in V4L2 MXB driver

Michael Krufky:
      Kconfig: swap VIDEO_CX88_ALSA and VIDEO_CX88_DVB

Michael Neuling:
      powerpc: RTC memory corruption

Nathan Scott:
      Fix a direct I/O locking issue revealed by the new mutex code.

Olaf Hering:
      powerpc: correct cacheflush loop in zImage
      powerpc/64: enable CONFIG_BLK_DEV_SL82C105
      powerpc: remove duplicate EXPORT_SYMBOLS

Oleg Nesterov:
      disable unshare(CLONE_VM) for now

Patrick McHardy:
      [NETFILTER]: nfnetlink_queue: fix possible NULL-ptr dereference
      [NET_SCHED]: act_api: fix skb leak in error path
      [XFRM]: Fix leak in ah6_input
      [NETLINK]: Fix use-after-free in netlink_recvmsg
      [TCP]: tcp_highspeed: fix AIMD table out-of-bounds access
      [IPV4/6]: Fix UFO error propagation
      [NETFILTER]: arp_tables: fix NULL pointer dereference

Paul Mackerras:
      powerpc: Disallow lparcfg being a module
      powerpc: Fix problem with time going backwards
      powerpc: update defconfigs

Pavel Machek:
      [ARM] 3357/1: enable frontlight on collie

Peter Staubach:
      nfsservctl(): remove user-triggerable printk

Ralf Baechle:
      Update MAINTAINERS entry for MIPS.
      [MIPS] Get rid of the IP22-specific code in arclib.
      [MIPS] SB1: Fix interrupt disable hazard.
      [MIPS] Work around bad code generation for <asm/io.h>.
      [MIPS] Protect more of timer_interrupt() by xtime_lock.
      [MIPS] Sibyte: Fix M_SCD_TIMER_INIT and M_SCD_TIMER_CNT wrong field width.
      [MIPS] Sibyte: Fix interrupt timer off by one bug.
      [MIPS] Sibyte: Fix race in sb1250_gettimeoffset().
      [MIPS] SB1: Check for -mno-sched-prolog if building corelis debug kernel.

Ralf Baechle DL5RB:
      [AX.25]: Fix potencial memory hole.

Roman Zippel:
      posix-timers: fix requeue accounting when signal is ignored

Russell King:
      [ARM] Fix muldi3.S
      [ARM] iwmmxt thread state alignment
      [ARM] Fix "thead" typo

Sam Ravnborg:
      kbuild: fix buffer overflow in modpost

Scott Bardone:
      [netdrvr] fix array overflows in Chelsio driver

Sergei Shtylylov:
      [MIPS] Fix DBAu1550 software power off.

Srivatsa Vaddagiri:
      x86: check for online cpus before bringing them up

Tejun Heo:
      ahci: fix NULL pointer dereference detected by Coverity

Trond Myklebust:
      NFS: Fix a potential panic in O_DIRECT
      NFSv4: fix mount segfault on errors returned that are < -1000
      SUNRPC: Fix potential deadlock in RPC code
      NLM: Ensure we do not Oops in the case of an unlock

Zhu Yi:
      ieee80211: Fix CCMP decryption problem when QoS is enabled

Re: Linux v2.6.16

[Joe Korty]

Git patch 52dfa9a64cfb3dd01fa1ee1150d589481e54e28e

	[PATCH] move rtc_interrupt() prototype to rtc.h

broke strace(1) builds.  The below moves the kernel-only additions lower,
under the already provided #ifdef __KERNEL__ statement.


 2.6.16-jak/include/linux/rtc.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff -puNa include/linux/rtc.h~patch include/linux/rtc.h
--- 2.6.16/include/linux/rtc.h~patch	2006-03-20 12:07:07.000000000 -0500
+++ 2.6.16-jak/include/linux/rtc.h	2006-03-20 12:07:07.000000000 -0500
@@ -11,8 +11,6 @@
 #ifndef _LINUX_RTC_H_
 #define _LINUX_RTC_H_
 
-#include <linux/interrupt.h>
-
 /*
  * The struct used to pass data via the following ioctl. Similar to the
  * struct tm in <time.h>, but it needs to be here so that the kernel 
@@ -95,6 +93,8 @@ struct rtc_pll_info {
 
 #ifdef __KERNEL__
 
+#include <linux/interrupt.h>
+
 typedef struct rtc_task {
 	void (*func)(void *private_data);
 	void *private_data;

_

Re: Linux v2.6.16

[Jeff Garzik]

Joe Korty wrote:
> Git patch 52dfa9a64cfb3dd01fa1ee1150d589481e54e28e
> 
> 	[PATCH] move rtc_interrupt() prototype to rtc.h
> 
> broke strace(1) builds.  The below moves the kernel-only additions lower,
> under the already provided #ifdef __KERNEL__ statement.
> 
> 
>  2.6.16-jak/include/linux/rtc.h |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)

strace should be using sanitized versions of the kernel headers, not 
directly including them verbatim...

	Jeff

Re: Linux v2.6.16

[Jan Engelhardt]

>
> strace should be using sanitized versions of the kernel headers, not directly
> including them verbatim...
>
Now, would not it be good for everyone if the in-kernel headers get
every bit of sanitation? Especially those who are stuck with outdated 
versions of sanitized headers (thinking of FC3 and FC4) often do the
magic symlinking (/usr/include/linux -> /usr/src/linux/include/linux).


Jan Engelhardt
-- 

Re: Linux v2.6.16

[Joe Korty]

On Mon, Mar 20, 2006 at 08:25:21PM +0100, Jan Engelhardt wrote:
> >
> > strace should be using sanitized versions of the kernel headers, not directly
> > including them verbatim...
> >
> Now, would not it be good for everyone if the in-kernel headers get
> every bit of sanitation? Especially those who are stuck with outdated 
> versions of sanitized headers (thinking of FC3 and FC4) often do the
> magic symlinking (/usr/include/linux -> /usr/src/linux/include/linux).

Also, if the policy is that only kernel code can reference the kernel
headers, this intent should be more strongly enforced by removing all
occurances of #ifdef __KERNEL__ in said headers.

Joe

Re: Linux v2.6.16

[Linus Torvalds]

On Mon, 20 Mar 2006, Jan Engelhardt wrote:
> >
> > strace should be using sanitized versions of the kernel headers, not directly
> > including them verbatim...
> >
> Now, would not it be good for everyone if the in-kernel headers get
> every bit of sanitation?

Yes, we should strive for fairly sanitized headers. That said, Jeff is 
also right - people really generally shouldn't use the kernel headers 
directly.

So the rigt answer is to do both: make sure that people don't use kernel 
headers, but also try to keep them reasonably clean.

		Linus

Re: Linux v2.6.16

[Andreas Schwab]

Linus Torvalds <torvalds@osdl.org> writes:

> So the rigt answer is to do both: make sure that people don't use kernel 
> headers, but also try to keep them reasonably clean.

strace is kind of special, since it needs to operate very close to the
kernel (interpreting syscall arguments below all libc wrappers).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Linux v2.6.16

[Matthias Andree]

On Mon, 20 Mar 2006, Linus Torvalds wrote:

> 
> 
> On Mon, 20 Mar 2006, Jan Engelhardt wrote:
> > >
> > > strace should be using sanitized versions of the kernel headers, not directly
> > > including them verbatim...
> > >
> > Now, would not it be good for everyone if the in-kernel headers get
> > every bit of sanitation?
> 
> Yes, we should strive for fairly sanitized headers. That said, Jeff is 
> also right - people really generally shouldn't use the kernel headers 
> directly.

It appears this message hasn't spread wide enough yet. When reporting an
inotify-related build failure, I heard back from the GNOMES I shouldn't
be using outdated glibc headers but kernel headers instead... apparently
there's more need for discussion.

(Not that I'd find gamin particularly sensible, since it's undocumented,
and attracted WAY too much attention because of its flaws like SIGSEGV
in applications, 100% CPU loops and other shortcomings not only in Linux
environments, but also on FreeBSD.)

-- 
Matthias Andree

Re: Linux v2.6.16

[Peter Williams]

Linus Torvalds wrote:
> Ok, it's being mirrored out right now, the git tree should already be all 
> there, the tar-file and patches are still uploading.
> 
> Not a lot of changes since -rc6, but there's various random one-liners 
> here and there (a number of Coverity bugs found, for example), and there 
> are small MIPS and PowerPC updates.
> 
> Appended is the shortlog from 2.6.16-rc6, the full log (from 2.6.15) is on 
> the web/ftp-sites. 
> 
> It looks like both Fedora and SuSE end up using a kernel that is pretty 
> close to this 2.6.16 release, so let's all hope it's good. Give it a good 
> testing, please,

I've just noticed some strange error messages that were printed during 
boot but don't seem to have any adverse effects when running.

Mar 22 16:10:31 heathwren kernel: ACPI: PM-Timer IO Port: 0x1008
Mar 22 16:10:31 heathwren kernel: ACPI: LAPIC (acpi_id[0x00] 
lapic_id[0x00] enabled)
Mar 22 16:10:31 heathwren kernel: Processor #0 15:3 APIC version 20

### First CPU seen.

Mar 22 16:10:31 heathwren kernel: ACPI: LAPIC (acpi_id[0x01] 
lapic_id[0x01] enabled)
Mar 22 16:10:31 heathwren kernel: Processor #1 15:3 APIC version 20

### Second CPU seen.

Mar 22 16:10:31 heathwren kernel: ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl 
lint[0x1])
Mar 22 16:10:31 heathwren kernel: ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl 
lint[0x1])
Mar 22 16:10:31 heathwren kernel: ACPI: IOAPIC (id[0x02] 
address[0xfec00000] gsi_base[0])
Mar 22 16:10:31 heathwren kernel: IOAPIC[0]: apic_id 2, version 20, 
address 0xfec00000, GSI 0-23
Mar 22 16:10:31 heathwren kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 0 
global_irq 2 dfl dfl)
Mar 22 16:10:31 heathwren kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 
global_irq 9 dfl dfl)
Mar 22 16:10:31 heathwren kernel: Enabling APIC mode:  Flat.  Using 1 
I/O APICs
Mar 22 16:10:31 heathwren kernel: More than 8 CPUs detected and 
CONFIG_X86_PC cannot handle it.

### No more CPUs seen but something in there thinks there's more than 8 
of them.

Mar 22 16:10:31 heathwren kernel: Use CONFIG_X86_GENERICARCH or 
CONFIG_X86_BIGSMP.
Mar 22 16:10:31 heathwren kernel: Using ACPI (MADT) for SMP 
configuration information

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

Re: Linux v2.6.16

[Ashok Raj]

On Tue, Mar 21, 2006 at 09:22:41PM -0800, Peter Williams wrote:
> 
>    I/O APICs
>    Mar 22 16:10:31 heathwren kernel: More than 8 CPUs detected and
>    CONFIG_X86_PC cannot handle it.
> 
>    ###  No more CPUs seen but something in there thinks there's more than
>    8
>    of them.
> 
>    Mar 22 16:10:31 heathwren kernel: Use CONFIG_X86_GENERICARCH or
>    CONFIG_X86_BIGSMP.
> 


This was disussed here,  

http://marc.theaimsgroup.com/?l=linux-kernel&m=114228068804099&w=2

but we didnt yet close out on it, Andrew didnt feel comfortable
making CONFIG_HOTPLUG_CPU depend on !X86_PC, and making it depend on CONFIG_GENERICARCH
or CONFIG_BIGSMP this late in the process.

The warning is bogus, when BIGSMP was first introduced it was solely to handle >8 CPUS
using custer mode configuration. We switched bigsmp to use flat physical mode just like 
what we do for x86_64, because some chipsets have ill effects with cpu hotplug.
when we wakeup a new cpu. Details here

http://marc.theaimsgroup.com/?l=linux-kernel&m=113261865814107&w=2

Hence we switched to bigsmp, but the error message was not reworked, better yet is
to have the right config depends so we dont run into any race and instability issues.


-- 
Cheers,
Ashok Raj
- Open Source Technology Center

Re: Linux v2.6.16

[Ashok Raj]

On Tue, Mar 21, 2006 at 10:31:20PM -0800, Ashok Raj wrote:
> On Tue, Mar 21, 2006 at 09:22:41PM -0800, Peter Williams wrote:
> > 
> >    I/O APICs
> >    Mar 22 16:10:31 heathwren kernel: More than 8 CPUs detected and
> >    CONFIG_X86_PC cannot handle it.
> > 
> >    ###  No more CPUs seen but something in there thinks there's more than
> >    8
> >    of them.
> > 
> >    Mar 22 16:10:31 heathwren kernel: Use CONFIG_X86_GENERICARCH or
> >    CONFIG_X86_BIGSMP.
> > 
> 
> 

Hi Andrew

Please consider for inclusion... resending with changelog per Andrew.


-- 
Cheers,
Ashok Raj
- Open Source Technology Center


This patch makes CONFIG_HOTPLUG_CPU depend on !X86_PC, so we need to turn on 
either CONFIG_GENERICARCH, CONFIG_BIGSMP or any other subarch except X86_PC when
CONFIG_HOTPLUG_CPU=y

With 2.6.15+ kernels when CONFIG_HOTPLUG_CPU is turned on we switch to bigsmp mode for
sending IPI's and ioapic configurations that caused the following error message.

>> More than 8 CPUs detected and CONFIG_X86_PC cannot handle it.
>> Use CONFIG_X86_GENERICARCH or CONFIG_X86_BIGSMP.

Originally bigsmp was added just to handle >8 cpus, but now with hotplug cpu support
we need to use bigsmp mode (why? see below), that cause the above error message even 
if there were less than 8 cpus in the system.

The message is bogus, but we are cannot use logical flat mode due to issues with
broadcast IPI can confuse a CPU just comming up. We use flat physical mode just like x86_64
case. More details on why bigsmp now uses flat physical mode (vs. cluster mode)
in following link.

http://marc.theaimsgroup.com/?l=linux-kernel&m=113261865814107&w=2


Signed-off-by: Ashok Raj <ashok.raj@intel.com>
---------------------------------------------------------

 arch/i386/Kconfig |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.16-rc6-mm1/arch/i386/Kconfig
===================================================================
--- linux-2.6.16-rc6-mm1.orig/arch/i386/Kconfig
+++ linux-2.6.16-rc6-mm1/arch/i386/Kconfig
@@ -760,7 +760,7 @@ config PHYSICAL_START
 
 config HOTPLUG_CPU
 	bool "Support for hot-pluggable CPUs (EXPERIMENTAL)"
-	depends on SMP && HOTPLUG && EXPERIMENTAL && !X86_VOYAGER
+	depends on SMP && HOTPLUG && EXPERIMENTAL && !X86_VOYAGER && !X86_PC
 	---help---
 	  Say Y here to experiment with turning CPUs off and on.  CPUs
 	  can be controlled through /sys/devices/system/cpu.

Re: Linux v2.6.16

[Michal Piotrowski]

Hi,

On 22/03/06, Ashok Raj <ashok.raj@intel.com> wrote:
> On Tue, Mar 21, 2006 at 10:31:20PM -0800, Ashok Raj wrote:
> > On Tue, Mar 21, 2006 at 09:22:41PM -0800, Peter Williams wrote:
> > >
> > >    I/O APICs
> > >    Mar 22 16:10:31 heathwren kernel: More than 8 CPUs detected and
> > >    CONFIG_X86_PC cannot handle it.
> > >
> > >    ###  No more CPUs seen but something in there thinks there's more than
> > >    8
> > >    of them.
> > >
> > >    Mar 22 16:10:31 heathwren kernel: Use CONFIG_X86_GENERICARCH or
> > >    CONFIG_X86_BIGSMP.
> > >
> >
> >
>
> Hi Andrew
>
> Please consider for inclusion... resending with changelog per Andrew.
>

SOFTWARE_SUSPEND depends on HOTPLUG_CPU.

It maybe useful for modern laptops, dual core desktops etc.

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: Linux v2.6.16

[Rafael J. Wysocki]

On Wednesday 22 March 2006 14:08, Ashok Raj wrote:
> On Tue, Mar 21, 2006 at 10:31:20PM -0800, Ashok Raj wrote:
> > On Tue, Mar 21, 2006 at 09:22:41PM -0800, Peter Williams wrote:
> > > 
> > >    I/O APICs
> > >    Mar 22 16:10:31 heathwren kernel: More than 8 CPUs detected and
> > >    CONFIG_X86_PC cannot handle it.
> > > 
> > >    ###  No more CPUs seen but something in there thinks there's more than
> > >    8
> > >    of them.
> > > 
> > >    Mar 22 16:10:31 heathwren kernel: Use CONFIG_X86_GENERICARCH or
> > >    CONFIG_X86_BIGSMP.
> > > 
> > 
> > 
> 
> Hi Andrew
> 
> Please consider for inclusion... resending with changelog per Andrew.

Please don't apply this patch.

CPU hotplug is used by swsusp for disabling the nonboot CPUs.  Software
suspend won't work on SMP without CPU hotplugging.

Greetings,
Rafael

Re: Linux v2.6.16

[Ashok Raj]

On Wed, Mar 22, 2006 at 06:39:41PM +0100, Rafael J. Wysocki wrote:
> > 
> > Please consider for inclusion... resending with changelog per Andrew.
> 
> Please don't apply this patch.
> 
> CPU hotplug is used by swsusp for disabling the nonboot CPUs.  Software
> suspend won't work on SMP without CPU hotplugging.
> 

Hi Rafael,

what part of this is not suitable for swsusp? All we do is just use flat physical mode
for IPI processing. The only difference is moving from logical flat mode to using
flat physical mode.

Have you tested swsusp with CONFIG_GENERICARCH and CONFIG_HOTPLUG_CPU=y ?

It might help to explain why this would break your swsusp with SMP work?

-- 
Cheers,
Ashok Raj
- Open Source Technology Center

Re: Linux v2.6.16

[Rafael J. Wysocki]

Hi,

On Wednesday 22 March 2006 18:54, Ashok Raj wrote:
> On Wed, Mar 22, 2006 at 06:39:41PM +0100, Rafael J. Wysocki wrote:
> > > 
> > > Please consider for inclusion... resending with changelog per Andrew.
> > 
> > Please don't apply this patch.
> > 
> > CPU hotplug is used by swsusp for disabling the nonboot CPUs.  Software
> > suspend won't work on SMP without CPU hotplugging.
> > 
> 
> Hi Rafael,
> 
> what part of this is not suitable for swsusp? All we do is just use flat physical mode
> for IPI processing. The only difference is moving from logical flat mode to using
> flat physical mode.
> 
> Have you tested swsusp with CONFIG_GENERICARCH and CONFIG_HOTPLUG_CPU=y ?
> 
> It might help to explain why this would break your swsusp with SMP work?

On SMP systems swsusp (suspend in general, AFAICT) uses the disable_nonboot_cpus()
function defined in kernel/power/smp.c, which calls cpu_down() that is only
defined if CONFIG_HOTPLUG_CPU is set.  We can't suspend and resume SMP systems
reliably without it.

Greetings,
Rafael

Re: Linux v2.6.16

[Ashok Raj]

On Wed, Mar 22, 2006 at 07:11:05PM +0100, Rafael J. Wysocki wrote:
> > It might help to explain why this would break your swsusp with SMP work?
> 
> On SMP systems swsusp (suspend in general, AFAICT) uses the disable_nonboot_cpus()
> function defined in kernel/power/smp.c, which calls cpu_down() that is only
> defined if CONFIG_HOTPLUG_CPU is set.  We can't suspend and resume SMP systems
> reliably without it.
> 
I understand the needs of swsusp, but no one took away CONFIG_HOTPLUG_CPU away... 
just that you need to also enable CONFIG_GENERICARCH to get it to work reliably, and
not see that printk... nothing else..

Iam still confused why you think swsusp wont work...

with that patch, try

CONFIG_X86_PC=n
CONFIG_GENERICARCH=y
CONFIG_HOTPLUG_CPU=y
...

<whatever swssusp needs>=y

and see if thinks work out for you?

-- 
Cheers,
Ashok Raj
- Open Source Technology Center

Re: Linux v2.6.16

[Rafael J. Wysocki]

On Wednesday 22 March 2006 19:27, Ashok Raj wrote:
> On Wed, Mar 22, 2006 at 07:11:05PM +0100, Rafael J. Wysocki wrote:
> > > It might help to explain why this would break your swsusp with SMP work?
> > 
> > On SMP systems swsusp (suspend in general, AFAICT) uses the disable_nonboot_cpus()
> > function defined in kernel/power/smp.c, which calls cpu_down() that is only
> > defined if CONFIG_HOTPLUG_CPU is set.  We can't suspend and resume SMP systems
> > reliably without it.
> > 
> I understand the needs of swsusp, but no one took away CONFIG_HOTPLUG_CPU away... 
> just that you need to also enable CONFIG_GENERICARCH to get it to work reliably, and
> not see that printk... nothing else..
> 
> Iam still confused why you think swsusp wont work...
> 
> with that patch, try
> 
> CONFIG_X86_PC=n
> CONFIG_GENERICARCH=y
> CONFIG_HOTPLUG_CPU=y

Well, there's nothing like CONFIG_GENERICARCH on x86_64 or I'm obviously
missing something. :-)

On x86_64 I can choose between X86_PC and X86_VSMP and I'm not sure I'd like
to set X86_VSMP just in order to be able to suspend a box with a dual-core CPU.
IMHO that would be over the top.

Greetings,
Rafael

Re: Linux v2.6.16

[Ashok Raj]

On Wed, Mar 22, 2006 at 09:40:00PM +0100, Rafael J. Wysocki wrote:
> > 
> > with that patch, try
> > 
> > CONFIG_X86_PC=n
> > CONFIG_GENERICARCH=y
> > CONFIG_HOTPLUG_CPU=y
> 
> Well, there's nothing like CONFIG_GENERICARCH on x86_64 or I'm obviously
> missing something. :-)
> 
> On x86_64 I can choose between X86_PC and X86_VSMP and I'm not sure I'd like
> to set X86_VSMP just in order to be able to suspend a box with a dual-core CPU.
> IMHO that would be over the top.
> 

This change is only for i386.. check the patch, its introduced only for arch/i386/Kconfig

There is no change to x86_64, we anyway choose physflat mode in x86_64 which is exactly 
same as bigsmp in i386.

We didnt change anything in x86_64...Why this speculation :(

Iam attaching that patch for your reference here... in case you lost it and looking at 
some other patch. :-)

Could you _please_ really check this and tell me if there is real concern... its pretty
simple patch... no other arch is affected...


This patch makes CONFIG_HOTPLUG_CPU depend on !X86_PC, so we need to turn on 
either CONFIG_GENERICARCH, CONFIG_BIGSMP or any other subarch except X86_PC

With 2.6.15+ kernels when CONFIG_HOTPLUG_CPU is turned on we switch to bigsmp mode for
sending IPI's and ioapic configurations that caused the following error message.

>> More than 8 CPUs detected and CONFIG_X86_PC cannot handle it.
>> Use CONFIG_X86_GENERICARCH or CONFIG_X86_BIGSMP.

Originally bigsmp was added just to handle >8 cpus, but now with hotplug cpu support
we need to use bigsmp mode (why? see below), that cause the above error message even 
if there were less than 8 cpus in the system.

The message is bogus, but we are cannot use logical flat mode due to issues with
broadcast IPI can confuse a CPU just comming up. We use flat physical mode just like x86_64
case. More details on why bigsmp now uses flat physical mode (vs. cluster mode)
in following link.

http://marc.theaimsgroup.com/?l=linux-kernel&m=113261865814107&w=2


Signed-off-by: Ashok Raj <ashok.raj@intel.com>
---------------------------------------------------------

 arch/i386/Kconfig |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.16-rc6-mm1/arch/i386/Kconfig
===================================================================
--- linux-2.6.16-rc6-mm1.orig/arch/i386/Kconfig
+++ linux-2.6.16-rc6-mm1/arch/i386/Kconfig
@@ -760,7 +760,7 @@ config PHYSICAL_START
 
 config HOTPLUG_CPU
 	bool "Support for hot-pluggable CPUs (EXPERIMENTAL)"
-	depends on SMP && HOTPLUG && EXPERIMENTAL && !X86_VOYAGER
+	depends on SMP && HOTPLUG && EXPERIMENTAL && !X86_VOYAGER && !X86_PC
 	---help---
 	  Say Y here to experiment with turning CPUs off and on.  CPUs
 	  can be controlled through /sys/devices/system/cpu.

Re: Linux v2.6.16

[Rafael J. Wysocki]

On Wednesday 22 March 2006 22:00, Ashok Raj wrote:
> On Wed, Mar 22, 2006 at 09:40:00PM +0100, Rafael J. Wysocki wrote:
> > > 
> > > with that patch, try
> > > 
> > > CONFIG_X86_PC=n
> > > CONFIG_GENERICARCH=y
> > > CONFIG_HOTPLUG_CPU=y
> > 
> > Well, there's nothing like CONFIG_GENERICARCH on x86_64 or I'm obviously
> > missing something. :-)
> > 
> > On x86_64 I can choose between X86_PC and X86_VSMP and I'm not sure I'd like
> > to set X86_VSMP just in order to be able to suspend a box with a dual-core CPU.
> > IMHO that would be over the top.
> > 
> 
> This change is only for i386.. check the patch, its introduced only for arch/i386/Kconfig

Of course you're right, sorry.

> There is no change to x86_64, we anyway choose physflat mode in x86_64 which is exactly 
> same as bigsmp in i386.
> 
> We didnt change anything in x86_64...Why this speculation :(
> 
> Iam attaching that patch for your reference here... in case you lost it and looking at 
> some other patch. :-)
> 
> Could you _please_ really check this and tell me if there is real concern... 

No, there's not.  [Except I think we'll need to document that CONFIG_GENERICARCH
is needed for suspend on i386 SMP machines.]

> its pretty simple patch... no other arch is affected...

OK

Rafael

Re: Linux v2.6.16

[Peter Williams]

Ashok Raj wrote:
> On Tue, Mar 21, 2006 at 09:22:41PM -0800, Peter Williams wrote:
> 
>>   I/O APICs
>>   Mar 22 16:10:31 heathwren kernel: More than 8 CPUs detected and
>>   CONFIG_X86_PC cannot handle it.
>>
>>   ###  No more CPUs seen but something in there thinks there's more than
>>   8
>>   of them.
>>
>>   Mar 22 16:10:31 heathwren kernel: Use CONFIG_X86_GENERICARCH or
>>   CONFIG_X86_BIGSMP.
>>
> 
> 
> 
> This was disussed here,  
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=114228068804099&w=2
> 
> but we didnt yet close out on it, Andrew didnt feel comfortable
> making CONFIG_HOTPLUG_CPU depend on !X86_PC, and making it depend on CONFIG_GENERICARCH
> or CONFIG_BIGSMP this late in the process.
> 
> The warning is bogus,

That's what I thought but I thought I should still report it as bogus 
messages can cause people to become inured and ignore real ones.

> when BIGSMP was first introduced it was solely to handle >8 CPUS
> using custer mode configuration. We switched bigsmp to use flat physical mode just like 
> what we do for x86_64, because some chipsets have ill effects with cpu hotplug.
> when we wakeup a new cpu. Details here
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=113261865814107&w=2
> 
> Hence we switched to bigsmp, but the error message was not reworked, better yet is
> to have the right config depends so we dont run into any race and instability issues.
> 
> 

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

Re: Linux v2.6.16

[Bodo Eggert]

Ashok Raj <ashok.raj@intel.com> wrote:
> On Tue, Mar 21, 2006 at 10:31:20PM -0800, Ashok Raj wrote:
>> On Tue, Mar 21, 2006 at 09:22:41PM -0800, Peter Williams wrote:

>> >    I/O APICs
>> >    Mar 22 16:10:31 heathwren kernel: More than 8 CPUs detected and
>> >    CONFIG_X86_PC cannot handle it.
>> > 
>> >    ###  No more CPUs seen but something in there thinks there's more than
>> >    8
>> >    of them.
>> > 
>> >    Mar 22 16:10:31 heathwren kernel: Use CONFIG_X86_GENERICARCH or
>> >    CONFIG_X86_BIGSMP.

> Please consider for inclusion... resending with changelog per Andrew.

You should rather change the message, since AFAIR from the thread
HOTPLUG_CPU is required for suspending.

Something like:
"CONFIG_X86_PC (PC-compatible) can handle up to 8 CPUs. Reconfigure and
 recompile your kernel if you intend to use more CPUs."


BTW: The help text is confusing: If (CONFIG_X86_BIGSMP)
"This option is needed for the systems that have more than 8 CPUs
 and if the system is not of any sub-arch type above.",
no option allowing more than 8 CPUs should follow, but CONFIG_X86_GENERICARCH
does follow and it's suggested for that case. Maybe BIGSMP should be moved
down to the end, only CONFIG_X86_GENERICARCH being below with the help text
changed to "Supports all Subarchitectures above".

-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.