Re: [RFC][PATCH 00/30] Read-only bind mounts (-mm resend)
On Fri, Feb 08, 2008 at 02:26:41PM -0800, Dave Hansen wrote: > This is against current Linus git > (a4ffc0a0b240a29cbe489f6db9dae112a49ef1c1). > > This rolls up all the -mm bugfixes that were accumulated, and > addresses some new review comments from Al. Also contains some > reworking from hch and a patch from Jeff Dike. > > Just posting here to let everyone have a sniff before we resend > it back to -mm. ACKed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.24 REGRESSION] BUG: Soft lockup - with VFS
On Tue, 5 Feb 2008 14:05:06 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > http://students.zipernowsky.hu/~oliverp/kernel/regression_2624/
> I think ub.c is basically abandoned in favour of usb-storage.
> If so, perhaps we should remove or disble ub.c?
Looks like it's just Tomo or Jens made a mistake when converting to
the new s/g API. Nothing to be too concerned about. I know I should've
reviewed their patch closer, but it seemed too simple...
-- Pete
Fix up the conversion to sg_init_table().
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
--- a/drivers/block/ub.c
+++ b/drivers/block/ub.c
@@ -657,7 +657,6 @@ static int ub_request_fn_1(struct ub_lun *lun, struct
request *rq)
if ((cmd = ub_get_cmd(lun)) == NULL)
return -1;
memset(cmd, 0, sizeof(struct ub_scsi_cmd));
- sg_init_table(cmd->sgv, UB_MAX_REQ_SG);
blkdev_dequeue_request(rq);
@@ -668,6 +667,7 @@ static int ub_request_fn_1(struct ub_lun *lun, struct
request *rq)
/*
* get scatterlist from block layer
*/
+ sg_init_table(&urq->sgv[0], UB_MAX_REQ_SG);
n_elem = blk_rq_map_sg(lun->disk->queue, rq, &urq->sgv[0]);
if (n_elem < 0) {
/* Impossible, because blk_rq_map_sg should not hit 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: [Scst-devel] Integration of SCST in the mainstream Linux kernel
--- On Fri, 2/8/08, Nicholas A. Bellinger <[EMAIL PROTECTED]> wrote: > > Is there an open iSCSI Target implementation which > does NOT > > issue commands to sub-target devices via the SCSI > mid-layer, but > > bypasses it completely? > > > >Luben > > > > Hi Luben, > > I am guessing you mean futher down the stack, which I > don't know this to Yes, that's what I meant. > be the case. Going futher up the layers is the design of > v2.9 LIO-SE. > There is a diagram explaining the basic concepts from a > 10,000 foot > level. > > http://linux-iscsi.org/builds/user/nab/storage-engine-concept.pdf Thanks! Luben -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] latency tracer
* Andrew Morton <[EMAIL PROTECTED]> wrote: > On Fri, 8 Feb 2008 22:45:22 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > Linus, please pull the latency tracer tree from: > > > >git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched.git > > > > Find the shortlog below. > > > > This is the latency tracer from -rt > > I've never seen any of this code before and googling several of the > patch titles turns up this email and nothing else. there might be some confusion here. Google for "mcount tracing utility" - there's 2270 hits. There's been 8 full series posted to lkml in the past month: Date: Thu, 03 Jan 2008 02:16:09 -0500 Subject: [RFC PATCH 00/11] mcount tracing utility Date: Wed, 09 Jan 2008 18:29:14 -0500 Subject: [RFC PATCH 00/22 -v2] mcount and latency tracing utility -v2 Date: Tue, 15 Jan 2008 15:49:07 -0500 Subject: [RFC PATCH 00/30 v3] mcount and latency tracing utility -v3 Date: Mon, 21 Jan 2008 10:22:31 -0500 Subject: [RFC PATCH 00/23 -v4] mcount and latency tracing utility -v4 Date: Wed, 23 Jan 2008 11:02:36 -0500 Subject: [PATCH 00/20 -v5] mcount and latency tracing utility -v5 Date: Fri, 25 Jan 2008 23:21:52 -0500 Subject: [PATCH 00/23 -v6] mcount and latency tracing utility -v6 Date: Tue, 29 Jan 2008 22:15:21 -0500 Subject: [PATCH 00/22 -v7] mcount and latency tracing utility -v7 Date: Wed, 30 Jan 2008 16:03:57 -0500 Subject: [PATCH 00/23 -v8] mcount and latency tracing utility -v8 it derives from the same latency tracer code that we wrote for -rt that has been around for years: http://people.redhat.com/mingo/latency-tracing-patches/ we renamed the concept to 'ftrace' during pre-merge cleanups, perhaps that is what caused you to not recognize this? (mcount is a confusing name and ties it to a gcc feature while there's nothing gcc specific about this concept.) Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Integration of SCST in the mainstream Linux kernel
--- On Fri, 2/8/08, Vladislav Bolkhovitin <[EMAIL PROTECTED]> wrote: > > Is there an open iSCSI Target implementation which > does NOT > > issue commands to sub-target devices via the SCSI > mid-layer, but > > bypasses it completely? > > What do you mean? To call directly low level backstorage > SCSI drivers > queuecommand() routine? What are advantages of it? Yes, that's what I meant. Just curious. Thanks, Luben -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix up kerneldoc in fs/ioctl.c a little bit
On Sat, Feb 09, 2008 at 02:19:27AM -0500, Erez Zadok wrote: > > * Invokes filesystem specific ->unlocked_ioctl, if one exists; otherwise > > * invokes * filesystem specific ->ioctl method. If neither method exists, > ^ > > I also think this extra '*' in the last comment line above is spurious, > perhaps the result of a paragraph reformatting command that mixed comment > *'s with text. Indeed. Updated patch below: Index: linux-2.6/fs/ioctl.c === --- linux-2.6.orig/fs/ioctl.c 2008-02-09 07:51:31.0 +0100 +++ linux-2.6/fs/ioctl.c2008-02-09 08:21:30.0 +0100 @@ -18,12 +18,12 @@ /** * vfs_ioctl - call filesystem specific ioctl methods - * @filp: [in] open file to invoke ioctl method on - * @cmd: [in] ioctl command to execute - * @arg: [in/out] command-specific argument for ioctl + * @filp: open file to invoke ioctl method on + * @cmd: ioctl command to execute + * @arg: command-specific argument for ioctl * * Invokes filesystem specific ->unlocked_ioctl, if one exists; otherwise - * invokes * filesystem specific ->ioctl method. If neither method exists, + * invokes filesystem specific ->ioctl method. If neither method exists, * returns -ENOTTY. * * Returns 0 on success, -errno on error. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] latency tracer
On Fri, 8 Feb 2008 22:45:22 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > Linus, please pull the latency tracer tree from: > >git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched.git > > Find the shortlog below. > > This is the latency tracer from -rt I've never seen any of this code before and googling several of the patch titles turns up this email and nothing else. Could we get the patches out for review in the usual way please? Bear in mind that people will actually want to understand how this code works. Particularly architecture maintainers. (I assume it's portable to non-x86?). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix up kerneldoc in fs/ioctl.c a little bit
In message <[EMAIL PROTECTED]>, Christoph Hellwig writes: > - remove non-standard in/out markers > - use tabs for formatting > > > Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]> > > Index: linux-2.6/fs/ioctl.c > === > --- linux-2.6.orig/fs/ioctl.c 2008-02-09 07:49:02.0 +0100 > +++ linux-2.6/fs/ioctl.c 2008-02-09 07:49:20.0 +0100 > @@ -18,9 +18,9 @@ > > /** > * vfs_ioctl - call filesystem specific ioctl methods > - * @filp: [in] open file to invoke ioctl method on > - * @cmd: [in] ioctl command to execute > - * @arg: [in/out] command-specific argument for ioctl > + * @filp:open file to invoke ioctl method on > + * @cmd: ioctl command to execute > + * @arg: command-specific argument for ioctl > * > * Invokes filesystem specific ->unlocked_ioctl, if one exists; otherwise > * invokes * filesystem specific ->ioctl method. If neither method exists, ^ I also think this extra '*' in the last comment line above is spurious, perhaps the result of a paragraph reformatting command that mixed comment *'s with text. Erez. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix up kerneldoc in fs/ioctl.c a little bit
- remove non-standard in/out markers - use tabs for formatting Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]> Index: linux-2.6/fs/ioctl.c === --- linux-2.6.orig/fs/ioctl.c 2008-02-09 07:49:02.0 +0100 +++ linux-2.6/fs/ioctl.c2008-02-09 07:49:20.0 +0100 @@ -18,9 +18,9 @@ /** * vfs_ioctl - call filesystem specific ioctl methods - * @filp: [in] open file to invoke ioctl method on - * @cmd: [in] ioctl command to execute - * @arg: [in/out] command-specific argument for ioctl + * @filp: open file to invoke ioctl method on + * @cmd: ioctl command to execute + * @arg: command-specific argument for ioctl * * Invokes filesystem specific ->unlocked_ioctl, if one exists; otherwise * invokes * filesystem specific ->ioctl method. If neither method exists, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] latency tracer
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > It does include one very interesting new feature that deserves to be > mentioned outside of the shortlog: 'dynamic ftrace' - which is a > transparent kernel-image-patcher mechanism that lazily patches out > mcount callsites from all functions that get executed. [if tracing is > disabled] These patched out callsites are remembered, and are patched > back in when tracing is enabled. > > This technique does not just accelelerate the "tracing disabled" case > enormously, we were in fact unable to measure _any_ performance > difference (within noise) between an mcount-enabled dyn-ftrace [but > tracing-disabled] and a vanilla kernel (!), on modern CPUs. hot off the presses: Steve has just finished doing a complete set of lmbench and hbackbench runs (on 2.8GHz Xeons, dual socket). The comparison results are at: http://rostedt.homelinux.com/dyn-ftrace-lmbench/lmbench-table the results show zero lmbench/hackbench overhead from dyn-ftrace (with thousands of functions instrumented) apart of the usual lmbench jitter. The core kernel results for example [these used to be rather sensitive on mcount overhead]: Host OS Mhz null null open slct sig sig fork exec sh call I/O stat clos TCP inst hndl proc proc proc - - ftrace-jm Linux 2.6.24 2783 0.65 0.74 4.74 6.96 5.28 0.76 4.29 290. 866. 2626 ftrace-no Linux 2.6.24 2784 0.65 0.74 4.75 7.14 5.31 0.76 3.92 282. 837. 2591 no-patche Linux 2.6.24 2786 0.64 0.71 4.86 7.10 5.34 0.78 3.89 283. 829. 2572 patched-n Linux 2.6.24 2784 0.64 0.71 4.72 6.98 5.35 0.78 3.94 284. 832. 2582 "ftrace-jm": dyn-ftrace, 2-byte JMPs patched in the mcount callsite "ftrace-no": dyn-ftrace, 5-byte NOPs patched in (devel patch, not in this pull request) "no-patche": no patches [vanilla Linus -git kernel] "patched-n": patched with the ftrace tree, all tracer options off i can see an outlier in the "Create" results - that's noise i think because the patched+options-off kernel is in essence the same as vanilla. "File reread" is noisy and unreliable as ever. 16-task ctx-switch results are noisy too (especially the 64k working set ones) - this is a HT system hence the multi-threaded results are fundamentally noisy due to sibling interaction. The hackbench results look good too. enabling full tracing of all the tens of thousands of kernel functions makes things measurably slower - but that is expected. (filtered patching of a user-selected list of function names is an upcoming feature) the full raw results are at: http://rostedt.homelinux.com/dyn-ftrace-lmbench/ Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] kgdb core and rs232 I/O drivers
On Sat, Feb 09, 2008 at 12:39:41AM -0600, Jason Wessel wrote: > The kgdb tree has been collapsed review. It includes > the kgdb core, the x86 arch, the kgdb8250 uart driver > and the kgdb console sharing driver. > > Since the last time the kgdb patches were posted to LKML > several months ago, the kgdb core has undergone some > significant cleanup, as well as the kgdb I/O driver > interface. > > All the kgdb hooks are initialized dynamically only when a > kgdb I/O module is configured. When not configured > kgdb will not exist in any kernel execution path. > > Further comments are certainly welcome. Any chance you could post actual patches for reviewing it? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.24.1 - kernel does not boot; IRQ trouble?
On Fri, Feb 08, 2008 at 11:31:24PM +, Chris Rankin wrote: > Hi, > > I've just tried booting the 2.6.24.1 kernel, except without > nmi_watchdog being enabled. It looks like there are IRQs still not > being enabled. Does 2.6.24 work? Is this a 2.6.24.1 regression? 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/
[git pull] kgdb core and rs232 I/O drivers
The kgdb tree has been collapsed review. It includes the kgdb core, the x86 arch, the kgdb8250 uart driver and the kgdb console sharing driver. Since the last time the kgdb patches were posted to LKML several months ago, the kgdb core has undergone some significant cleanup, as well as the kgdb I/O driver interface. All the kgdb hooks are initialized dynamically only when a kgdb I/O module is configured. When not configured kgdb will not exist in any kernel execution path. Further comments are certainly welcome. Thanks, Jason. git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git for_linus Ingo Molnar (1): pid, kgdb: add pid_max prototype Jason Wessel (7): kgdb: core API and gdb protocol handler kgdb, modules: Always allow module sect info for KGDB kgdb: COPTIMIZE flag kgdb, x86: Add arch specfic kgdb support kgdb, sysrq_bugfix kgdb: exclusive use kgdb8250 uart I/O driver kgdb: kgdboc 8250 I/O module Documentation/DocBook/Makefile |2 +- Documentation/DocBook/kgdb.tmpl | 214 Documentation/kernel-parameters.txt |5 + MAINTAINERS |7 + Makefile|8 +- arch/x86/kernel/Makefile|1 + arch/x86/kernel/kgdb.c | 533 + arch/x86/kernel/setup_32.c |2 + arch/x86/kernel/setup_64.c |4 + arch/x86/kernel/traps_32.c | 14 +- arch/x86/kernel/traps_64.c | 17 +- drivers/char/keyboard.c |1 + drivers/char/tty_io.c |8 + drivers/serial/8250.c | 91 ++ drivers/serial/8250_kgdb.c | 489 + drivers/serial/Kconfig |5 +- drivers/serial/Makefile |2 + drivers/serial/kgdboc.c | 182 drivers/serial/serial_core.c| 89 ++- include/asm-generic/kgdb.h | 105 ++ include/asm-x86/kgdb.h | 79 ++ include/asm-x86/system.h|3 + include/linux/clocksource.h |1 + include/linux/kgdb.h| 268 + include/linux/module.h |9 +- include/linux/pid.h |2 + include/linux/sched.h |1 + include/linux/serial_8250.h |2 + include/linux/serial_core.h |4 + include/linux/tty_driver.h | 11 + kernel/Makefile |1 + kernel/kgdb.c | 2018 +++ kernel/module.c | 34 +- kernel/sched.c |3 +- kernel/softlockup.c |7 +- kernel/sysctl.c |2 +- kernel/time/clocksource.c | 12 + lib/Kconfig.debug |2 + lib/Kconfig.kgdb| 62 ++ 39 files changed, 4268 insertions(+), 32 deletions(-) create mode 100644 Documentation/DocBook/kgdb.tmpl create mode 100644 arch/x86/kernel/kgdb.c create mode 100644 drivers/serial/8250_kgdb.c create mode 100644 drivers/serial/kgdboc.c create mode 100644 include/asm-generic/kgdb.h create mode 100644 include/asm-x86/kgdb.h create mode 100644 include/linux/kgdb.h create mode 100644 kernel/kgdb.c create mode 100644 lib/Kconfig.kgdb -- 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/8] LinuxPPS core support.
On Fri, Feb 08, 2008 at 07:00:37PM +0100, Rodolfo Giometti wrote:
> This patch adds the kernel side of the PPS support currently named
> "LinuxPPS".
>
> PPS means "pulse per second" and a PPS source is just a device which
> provides a high precision signal each second so that an application
> can use it to adjust system clock time.
>
> Common use is the combination of the NTPD as userland program with a
> GPS receiver as PPS source to obtain a wallclock-time with
> sub-millisecond synchronisation to UTC.
>
> To obtain this goal the userland programs shoud use the PPS API
> specification (RFC 2783 - Pulse-Per-Second API for UNIX-like Operating
> Systems, Version 1.0) which in part is implemented by this patch. It
> provides a set of chars devices, one per PPS source, which can be used
> to get the time signal. The RFC's functions can be implemented by
> accessing to these char devices.
>
> Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>
> ---
> MAINTAINERS |7 +
> drivers/Kconfig |2 +
> drivers/Makefile |1 +
> drivers/pps/Kconfig | 32 +
> drivers/pps/Makefile | 10 ++
> drivers/pps/kapi.c | 272 +++
> drivers/pps/pps.c| 342
> ++
> drivers/pps/sysfs.c | 142 +
As you are adding sysfs files, please also describe them in
Documentation/ABI/ in this same series of patches.
> +void pps_sysfs_remove_source_entry(struct pps_device *pps)
> +{
> + /* Delete info files */
> + if (pps->info.mode & PPS_CAPTUREASSERT)
> + device_remove_file(pps->dev, &dev_attr_assert);
> +
> + if (pps->info.mode & PPS_CAPTURECLEAR)
> + device_remove_file(pps->dev, &dev_attr_clear);
> +
> + device_remove_file(pps->dev, &dev_attr_mode);
> + device_remove_file(pps->dev, &dev_attr_echo);
> + device_remove_file(pps->dev, &dev_attr_name);
> + device_remove_file(pps->dev, &dev_attr_path);
> +}
> +
> +int pps_sysfs_create_source_entry(struct pps_device *pps)
> +{
> + int ret;
> +
> + /* Create file "assert" and "clear" according to source capability */
> + if (pps->info.mode & PPS_CAPTUREASSERT) {
> + ret = device_create_file(pps->dev, &dev_attr_assert);
> + if (ret)
> + dev_err(pps->dev, "unable to create \"assert\" "
> + "sysfs entry");
> + }
> +
> + if (pps->info.mode & PPS_CAPTURECLEAR) {
> + ret = device_create_file(pps->dev, &dev_attr_clear);
> + if (ret)
> + dev_err(pps->dev, "unable to create \"clear\" "
> + "sysfs entry");
> + }
> +
> + ret = device_create_file(pps->dev, &dev_attr_mode);
> + if (ret)
> + dev_err(pps->dev, "unable to create \"mode\" sysfs entry");
> + ret = device_create_file(pps->dev, &dev_attr_echo);
> + if (ret)
> + dev_err(pps->dev, "unable to create \"echo\" sysfs entry");
> + ret = device_create_file(pps->dev, &dev_attr_name);
> + if (ret)
> + dev_err(pps->dev, "unable to create \"name\" sysfs entry");
> + ret = device_create_file(pps->dev, &dev_attr_path);
> + if (ret)
> + dev_err(pps->dev, "unable to create \"path\" sysfs entry");
Why not use a default attribute group?
That way the files are created before the uevent is issued, and the
amount of code you have to write is much smaller.
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: [RFC][PATCH 00/30] Read-only bind mounts (-mm resend)
On Fri, Feb 08, 2008 at 02:26:41PM -0800, Dave Hansen wrote: > This is against current Linus git > (a4ffc0a0b240a29cbe489f6db9dae112a49ef1c1). > > This rolls up all the -mm bugfixes that were accumulated, and > addresses some new review comments from Al. Also contains some > reworking from hch and a patch from Jeff Dike. > > Just posting here to let everyone have a sniff before we resend > it back to -mm. Except for the comment snafu in patch 8 this looks good to me. Feel free to add Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]> as after all the reshuffling and tweaking I should share my fair share of blame if things go wrong after all. Do we really want to do another detour to -mm? I think we should be heading towards Linus' tree ASAP with this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.25-rc0
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> one of these caused a build failure in x86.git overnight randconfig
> testing:
>
> drivers/built-in.o: In function `acpi_fan_remove':
> fan.c:(.text+0x361d5): undefined reference to
> `thermal_cooling_device_unregister'
> drivers/built-in.o: In function `acpi_fan_add':
> fan.c:(.text+0x3625e): undefined reference to
> `thermal_cooling_device_register'
>
> i suspect it might be this one:
>
> > ACPI: register ACPI thermal zone as generic thermal zone devices
>
> config attached.
yep, reverting 05a83d972293f3 fixes the build failure.
Ingo
-->
commit 05a83d972293f39a66bc2aa409a5e7996bba585d
Author: Zhang Rui <[EMAIL PROTECTED]>
Date: Thu Jan 17 15:51:24 2008 +0800
ACPI: register ACPI Fan as generic thermal cooling device
Register ACPI Fan as thermal cooling device.
Signed-off-by: Zhang Rui <[EMAIL PROTECTED]>
Signed-off-by: Thomas Sujith <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c
index a6e149d..f6e8165 100644
--- a/drivers/acpi/fan.c
+++ b/drivers/acpi/fan.c
@@ -30,7 +30,7 @@
#include
#include
#include
-
+#include
#include
#include
@@ -68,9 +68,55 @@ static struct acpi_driver acpi_fan_driver = {
},
};
+/* thermal cooling device callbacks */
+static int fan_get_max_state(struct thermal_cooling_device *cdev, char *buf)
+{
+ /* ACPI fan device only support two states: ON/OFF */
+ return sprintf(buf, "1\n");
+}
+
+static int fan_get_cur_state(struct thermal_cooling_device *cdev, char *buf)
+{
+ struct acpi_device *device = cdev->devdata;
+ int state;
+ int result;
+
+ if (!device)
+ return -EINVAL;
+
+ result = acpi_bus_get_power(device->handle, &state);
+ if (result)
+ return result;
+
+ return sprintf(buf, "%s\n", state == ACPI_STATE_D3 ? "0" :
+(state == ACPI_STATE_D0 ? "1" : "unknown"));
+}
+
+static int
+fan_set_cur_state(struct thermal_cooling_device *cdev, unsigned int state)
+{
+ struct acpi_device *device = cdev->devdata;
+ int result;
+
+ if (!device || (state != 0 && state != 1))
+ return -EINVAL;
+
+ result = acpi_bus_set_power(device->handle,
+ state ? ACPI_STATE_D0 : ACPI_STATE_D3);
+
+ return result;
+}
+
+static struct thermal_cooling_device_ops fan_cooling_ops = {
+ .get_max_state = fan_get_max_state,
+ .get_cur_state = fan_get_cur_state,
+ .set_cur_state = fan_set_cur_state,
+};
+
/* --
FS Interface (/proc)
--
*/
+#ifdef CONFIG_ACPI_PROCFS
static struct proc_dir_entry *acpi_fan_dir;
@@ -171,7 +217,17 @@ static int acpi_fan_remove_fs(struct acpi_device *device)
return 0;
}
+#else
+static int acpi_fan_add_fs(struct acpi_device *device)
+{
+ return 0;
+}
+static int acpi_fan_remove_fs(struct acpi_device *device)
+{
+ return 0;
+}
+#endif
/* --
Driver Interface
--
*/
@@ -179,9 +235,8 @@ static int acpi_fan_remove_fs(struct acpi_device *device)
static int acpi_fan_add(struct acpi_device *device)
{
int result = 0;
- struct acpi_fan *fan = NULL;
int state = 0;
-
+ struct thermal_cooling_device *cdev;
if (!device)
return -EINVAL;
@@ -199,6 +254,25 @@ static int acpi_fan_add(struct acpi_device *device)
acpi_bus_set_power(device->handle, state);
device->flags.force_power_state = 0;
+ cdev = thermal_cooling_device_register("Fan", device,
+ &fan_cooling_ops);
+ if (cdev)
+ printk(KERN_INFO PREFIX
+ "%s is registered as cooling_device%d\n",
+ device->dev.bus_id, cdev->id);
+ else
+ goto end;
+ acpi_driver_data(device) = cdev;
+ result = sysfs_create_link(&device->dev.kobj, &cdev->device.kobj,
+ "thermal_cooling");
+ if (result)
+ return result;
+
+ result = sysfs_create_link(&cdev->device.kobj, &device->dev.kobj,
+ "device");
+if (result)
+return result;
+
result = acpi_fan_add_fs(device);
if (result)
goto end;
@@ -208,18 +282,20 @@ static int acpi_fan_add(struct acpi_device *device)
!device->power.state ? "on" : "off");
end:
- if (result)
- kfree(fan);
-
return result;
}
static int
Re: [GIT PATCH] ACPI patches for 2.6.25-rc0
* Len Brown <[EMAIL PROTECTED]> wrote: > Hi Linus, > > please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release one of these caused a build failure in x86.git overnight randconfig testing: drivers/built-in.o: In function `acpi_fan_remove': fan.c:(.text+0x361d5): undefined reference to `thermal_cooling_device_unregister' drivers/built-in.o: In function `acpi_fan_add': fan.c:(.text+0x3625e): undefined reference to `thermal_cooling_device_register' i suspect it might be this one: > ACPI: register ACPI thermal zone as generic thermal zone devices config attached. Ingo # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24 # Sat Feb 9 07:15:30 2008 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y # CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set CONFIG_ARCH_HAS_CPU_RELAX=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_X86_32_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y # CONFIG_SYSVIPC is not set CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y # CONFIG_TASK_DELAY_ACCT is not set CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=20 CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set # CONFIG_CGROUP_NS is not set CONFIG_CPUSETS=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set # CONFIG_CGROUP_CPUACCT is not set # CONFIG_RESOURCE_COUNTERS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_PROC_PID_CPUSET=y CONFIG_RELAY=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_COMPAT_BRK=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set CONFIG_MARKERS=y CONFIG_HAVE_OPROFILE=y CONFIG_HAVE_KPROBES=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_MODULES is not set CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_LBD is not set CONFIG_BLK_DEV_IO_TRACE=y # CONFIG_LSF is not set CONFIG_BLK_DEV_BSG=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set CONFIG_DEFAULT_NOOP=y CONFIG_DEFAULT_IOSCHED="noop" CONFIG_CLASSIC_RCU=y # CONFIG_PREEMPT_RCU is not set # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y # CONFIG_X86_PC is not set # 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=y # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_X86_RDC321X is not set # CONFIG_X86_VSMP is not set # CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER is not set # CONFIG_PARAVIRT_GUEST 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_M
struct page vs page_link
Regarding: commit 18dabf473e15850c0dbc8ff13ac1e2806d542c15 This actually breaks the 802.11 subsystem (http://80211.sf.net) which relies on the page struct. (ieee80211_crypt_wep.c, line 190) Can anyone suggest an alternative kernel function or method? As of 2.6.24, the 802.11 subsystem cannot compile. Mark Tuttle -- 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: Integration of SCST in the mainstream Linux kernel
On Fri, 8 Feb 2008, Vladislav Bolkhovitin wrote: 2. I think, everybody will agree that Linux iSCSI target should work over some standard SCSI target framework. Hence the choice gets narrower: SCST vs STGT. I don't think there's a way for a dedicated iSCSI target (i.e. PyX/LIO) in the mainline, because of a lot of code duplication. Nicholas could decide to move to either existing framework (although, frankly, I don't think there's a possibility for in-kernel iSCSI target and user space SCSI target framework) and if he decide to go with SCST, I'll be glad to offer my help and support and wouldn't care if LIO-SCST eventually replaced iSCSI-SCST. The better one should win. why should linux as an iSCSI target be limited to passthrough to a SCSI device. the most common use of this sort of thing that I would see is to load up a bunch of 1TB SATA drives in a commodity PC, run software RAID, and then export the resulting volume to other servers via iSCSI. not a 'real' SCSI device in sight. David, your question surprises me a lot. From where have you decided that SCST supports only pass-through backstorage? Does the RAM disk, which Bart has been using for performance tests, look like a SCSI device? I was responding to the start of item #2 that I left in the quote above. it asn't saying that SCST didn't support that, but was stating that any implementation of a iSCSI target should use the SCSI framework. I read this to mean that this would only be able to access things that the SCSI framework can access, and that would not be things like ramdisks, raid arrays, etc. David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.25-rc0 (#2)
(Carlos Cc:-ed too) * Ingo Molnar <[EMAIL PROTECTED]> wrote: > * Len Brown <[EMAIL PROTECTED]> wrote: > > > Len Brown (6): > > ACPI: add newline to printk > > ACPI: build WMI on X86 only > > acer-wmi, tc1100-wmi: select ACPI_WMI > > hm, this new WMI code caused a bootup crash in the overnight x86.git > tests: > > initcall 0x40cffbd0 ran for 0 msecs: msi_init+0x0/0x150() > Calling initcall 0x40cffd20: tc1100_init+0x0/0x70() > BUG: unable to handle kernel NULL pointer dereference at > IP: [<404b96a2>] find_guid+0x132/0x150 > *pde = > Oops: [#1] SMP > > Pid: 1, comm: swapper Not tainted (2.6.24 #34) > EIP: 0060:[<404b96a2>] EFLAGS: 00010247 CPU: 1 > EIP is at find_guid+0x132/0x150 > EAX: 05a572d4 EBX: 5f81af54 ECX: EDX: > ESI: EDI: 5f81af54 EBP: 5f81af80 ESP: 5f81af48 > DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 > Process swapper (pid: 1, ti=5f81a000 task=5f815410 task.ti=5f81a000) > Stack: 5f81af74 0005 c364ac71 495a36db 39b49484 05a572d4 > 71ac64c3 >5a49db36 39b49484 05a572d4 ffed 5f81af88 > 404b96cf >5f81af94 40cffd33 5f81afe0 40cdb5d3 2c7b1366 0001 > > Call Trace: > [<404b96cf>] ? wmi_has_guid+0xf/0x20 > [<40cffd33>] ? tc1100_init+0x13/0x70 > [<40cdb5d3>] ? kernel_init+0x123/0x2f0 > [<40cdb4b0>] ? kernel_init+0x0/0x2f0 > [<401053d7>] ? kernel_thread_helper+0x7/0x10 > === > Code: 0c 41 8d 7d d4 eb 24 8d 46 08 b9 10 00 00 00 89 fa e8 e3 88 f6 ff 85 c0 > 75 0f b0 01 83 7d c8 00 74 19 8b 55 c8 89 32 eb 12 89 de <8b> 1e 0f 18 03 90 > 81 fe 90 c1 0c 41 75 ce 31 c0 83 c4 2c 5b 5e > EIP: [<404b96a2>] find_guid+0x132/0x150 SS:ESP 0068:5f81af48 > ---[ end trace 5d95b7a12e9c31b7 ]--- > Kernel panic - not syncing: Attempted to kill init! > Press any key to enter the menu > > config and crashlog attached. -- 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: REPOST: [PATCH] Add iSCSI iBFT support (v0.4.7)
On Fri, 2008-02-08 at 23:10 -0400, Konrad Rzeszutek wrote:
> + if (hdr->id == id_nic) {
> + pci_dev = pci_get_bus_and_slot((nic->pci_bdf & 0xff00) >> 8,
> + (nic->pci_bdf & 0xff));
> + if (pci_dev) {
> + rc = sysfs_create_link(&ibft_kobj->kobj,
> + &pci_dev->dev.kobj, "device");
> + pci_dev_put(pci_dev);
> + }
pci_get_bus_and_slot fails in the presence of PCI domains, which are
getting to be fairly common even in medium sized servers ... what
happens in that case?
James
--
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: REPOST: [PATCH] Add iSCSI iBFT support (v0.4.7)
On Fri, 2008-02-08 at 23:10 -0400, Konrad Rzeszutek wrote: > + ibft_device = kmalloc(len, GFP_KERNEL); > + if (!ibft_device) > + return -ENOMEM; > + > + memcpy(ibft_device, hdr, len); This piece looks a bit odd. you're making ibft_device an exact duplicate of ibft_addr (which is reserved in bootmem and lives as long as the kernel does). I can't seem to find anywhere you actually modify ibft_device, so why not just use the original ibft_addr here instead of making a copy? James -- 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: REPOST: [PATCH] Add iSCSI iBFT support (v0.4.7)
On Fri, 2008-02-08 at 23:10 -0400, Konrad Rzeszutek wrote: > +/* > + * Physical location of iSCSI Boot Format Table. This is now the Virtual address, isn't it? So just drop the Physical. > + */ > +unsigned long ibft_addr; > +EXPORT_SYMBOL(ibft_addr); And since it is the virtual address, there's no point in keeping it unsigned long and doing all the casting. It should be struct ibft_table_hdr *, shouldn't it? James -- 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] correct inconsistent ntp interval/tick_length usage
On Sat, 9 Feb 2008 05:47:18 +0100 (CET) Roman Zippel <[EMAIL PROTECTED]> wrote: > Hi, > > On Fri, 8 Feb 2008, john stultz wrote: > > > > > clock = clocksource_get_next(); > > - clocksource_calculate_interval(clock, > > - (unsigned long)(current_tick_length()>>TICK_LENGTH_SHIFT)); > > + clocksource_calculate_interval(clock, NTP_INTERVAL_LENGTH); > > clock->cycle_last = clocksource_read(clock); > > > > Only now I noticed that the first patch had been merged without any > further question. :-( > What point is there in reviewing patches, if everything is merged anyway. :-( > oops, mistake, sorry. There's plenty of time to fix it though. -- 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: kobject must be initialized before calling kobject_init()?!
On Fri, Feb 08, 2008 at 08:24:25PM -0800, Roland Dreier wrote:
> So I was perusing the code in lib/kobject.c, and I saw this:
>
> void kobject_init(struct kobject *kobj, struct kobj_type *ktype)
> {
> // [a couple of of parameter checks...]
> if (kobj->state_initialized) {
> /* do not error out as sometimes we can recover */
> printk(KERN_ERR "kobject (%p): tried to init an
> initialized "
> "object, something is seriously wrong.\n", kobj);
> dump_stack();
> }
>
> in other words the first thing you do is check a member of the
> structure you're supposed to be initializing -- if someone just
> kmalloc()s a struct kobject and passes it into this function, there's
> a good chance that state_initialized won't be zero. In fact, with
> slab debugging on, it's guaranteed to be poisoned with a non-zero
> value.
>
> So are users supposed to be zeroing out struct kobjects before
> initializing them?
Yes. See also the check about the non-zero reference count when
initializing the kref, that too will trip.
> If so, this should probably be documented.
You're right. Patches gladly accepted :)
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: [RFC][PATCH 06/30] make open_namei() return a filp
On Fri, Feb 08, 2008 at 02:26:54PM -0800, Dave Hansen wrote: > > open_namei() will, in the future, need to take mount write counts > over its creation and truncation (via may_open()) operations. It > needs to keep these write counts until any potential filp that is > created gets __fput()'d. > > This gets complicated in the error handling and becomes very murky > as to how far open_namei() actually got, and whether or not that > mount write count was taken. > > Creating the filps inside of open_namei() lets us shift the write > count to be taken and released along with the filp. We can hold > a temporary write count during those creation and truncation > operations, then release them once the write for the filp has > been established. > > Any caller who gets a 'struct file' back must consider that filp > instantiated and fput() it normally. The callers no longer > have to worry about ever manually releasing a mnt write count. This patch description is not correct anymore, open_namei is actually gone with this patch as it got merged into do_filp_open. -- 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] correct inconsistent ntp interval/tick_length usage
Hi, On Fri, 8 Feb 2008, john stultz wrote: > > clock = clocksource_get_next(); > - clocksource_calculate_interval(clock, > - (unsigned long)(current_tick_length()>>TICK_LENGTH_SHIFT)); > + clocksource_calculate_interval(clock, NTP_INTERVAL_LENGTH); > clock->cycle_last = clocksource_read(clock); > Only now I noticed that the first patch had been merged without any further question. :-( What point is there in reviewing patches, if everything is merged anyway. :-( 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] Input: i8042 - Fix warning on non-x86 builds
Commit c18bab80 ("Input: i8042 - non-x86 build fix") introduced the
following warning on non-x86 builds:
drivers/input/serio/i8042.c: In function 'i8042_probe':
drivers/input/serio/i8042.c:1154: warning: unused variable 'param'
Fix this by moving the parameter variable declaration into the #ifdef too.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index 2763394..65a74cf 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -1151,7 +1151,6 @@ static int __devinit i8042_setup_kbd(void)
static int __devinit i8042_probe(struct platform_device *dev)
{
int error;
- char param;
error = i8042_controller_selftest();
if (error)
@@ -1174,7 +1173,7 @@ static int __devinit i8042_probe(struct platform_device
*dev)
}
#ifdef CONFIG_X86
if (i8042_dritek) {
- param = 0x90;
+ char param = 0x90;
error = i8042_command(¶m, 0x1059);
if (error)
goto out_fail;
--
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] Input: i8042 -
Commit c18bab80 ("Input: i8042 - non-x86 build fix") introduced the
following warning on non-x86 builds:
drivers/input/serio/i8042.c: In function 'i8042_probe':
drivers/input/serio/i8042.c:1154: warning: unused variable 'param'
Fix this by moving the parameter variable declaration into the #ifdef too.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index 2763394..65a74cf 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -1151,7 +1151,6 @@ static int __devinit i8042_setup_kbd(void)
static int __devinit i8042_probe(struct platform_device *dev)
{
int error;
- char param;
error = i8042_controller_selftest();
if (error)
@@ -1174,7 +1173,7 @@ static int __devinit i8042_probe(struct platform_device
*dev)
}
#ifdef CONFIG_X86
if (i8042_dritek) {
- param = 0x90;
+ char param = 0x90;
error = i8042_command(¶m, 0x1059);
if (error)
goto out_fail;
--
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] docbook: drop z85230 library from kernel-api
From: Randy Dunlap <[EMAIL PROTECTED]> cc: Alan Cox <[EMAIL PROTECTED]> Drop z85230 support library info from kernel-api since it's duplicated in the Z85230 book. Alan, is this OK with you? (This is one of several patches that I have my queue for reducing the size of kernel-api.* .) Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- Documentation/DocBook/kernel-api.tmpl |5 - 1 file changed, 5 deletions(-) --- linux-2.6.24-git19.orig/Documentation/DocBook/kernel-api.tmpl +++ linux-2.6.24-git19/Documentation/DocBook/kernel-api.tmpl @@ -449,11 +449,6 @@ X!Isound/sound_firmware.c !Edrivers/serial/8250.c - - Z85230 Support Library -!Edrivers/net/wan/z85230.c - - Frame Buffer Library -- 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/
kobject must be initialized before calling kobject_init()?!
So I was perusing the code in lib/kobject.c, and I saw this:
void kobject_init(struct kobject *kobj, struct kobj_type *ktype)
{
// [a couple of of parameter checks...]
if (kobj->state_initialized) {
/* do not error out as sometimes we can recover */
printk(KERN_ERR "kobject (%p): tried to init an
initialized "
"object, something is seriously wrong.\n", kobj);
dump_stack();
}
in other words the first thing you do is check a member of the
structure you're supposed to be initializing -- if someone just
kmalloc()s a struct kobject and passes it into this function, there's
a good chance that state_initialized won't be zero. In fact, with
slab debugging on, it's guaranteed to be poisoned with a non-zero
value.
So are users supposed to be zeroing out struct kobjects before
initializing them? If so, this should probably be documented.
And also the code in kobject_init() that sets other fields to be zero
can also be removed:
kobj->state_in_sysfs = 0;
kobj->state_add_uevent_sent = 0;
kobj->state_remove_uevent_sent = 0;
Let me know if the intention is that everyone should zero out their
kobjects when they initialize them, and I'll send a patch updating the
documentation.
There's another similar booby-trap in kobject_init_and_add(), which
ends up calling into kobject_set_name_vargs(), which does
/* Free the old name, if necessary. */
kfree(kobj->name);
which is generally a bad thing if kobj->name has not been initialized.
Thanks,
Roland
--
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] keyboard notifier documentation
On Sat, 9 Feb 2008 01:33:22 + Samuel Thibault wrote:
> Document the keyboard notifier.
>
> Signed-off-by: Samuel Thibault <[EMAIL PROTECTED]>
>
> --- /dev/null 2008-02-09 01:22:34.790011677 +
> +++ linux/Documentation/input/notifier.txt2008-02-09 01:28:12.0
> +
> @@ -0,0 +1,52 @@
> +Keyboard notifier
> +
> +One can use register_keyboard_notifier to get called back on keyboard
> +events (see kbd_keycode() function for details). The passed structure is
> +keyboard_notifier_param:
> +
> +- 'vc' always provide the VC for which the keyboard event applies ;
> +- 'down' is 1 for a key press event, 0 for a key release ;
> +- 'shift' is the current modifier state, mask bit indexes are KG_* ;
No space before the ';' (3 times).
> +- 'value' depends on the type of event.
> +
> +- KBD_KEYCODE events are always sent before other events, value is the
> keycode.
> +- KBD_UNBOUND_KEYCODE events are sent if the keycode is not bound to a
> keysym.
> + value is the keycode.
> +- KBD_UNICODE events are sent if the keycode -> keysym translation produced a
> + unicode character. value is the unicode value.
> +- KBD_KEYSYM events are sent if the keycode -> keysym translation produced a
> + non-unicode character. value is the keysym.
> +- KBD_POST_KEYSYM events are sent after the treatment of non-unicode keysyms.
> + That permits to inspect the resulting LEDs for instance.
That permits (some object word here, like: you, one, code, etc.) to
inspect ...
> +
> +For each kind of event but the last, the callback may return NOTIFY_STOP in
> +order to "eat" the event: the notify loop is stopped and the keyboard event
> is
> +dropped.
> +
> +I a rough C snippet, we have:
In a rough (?)
> +
> +kbd_keycode(keycode) {
> + ...
> + params.value = keycode;
> + if (notifier_call_chain(KBD_KEYCODE,¶ms) == NOTIFY_STOP)
> + || !bound) {
> + notifier_call_chain(KBD_UNBOUND_KEYCODE,¶ms);
> + return;
> + }
> +
> + if (unicode) {
> + param.value = unicode;
> + if (notifier_call_chain(KBD_UNICODE,¶ms) == NOTIFY_STOP)
> + return;
> + emit unicode;
> + return;
> + }
> +
> + params.value = keysym;
> + if (notifier_call_chain(KBD_KEYSYM,¶ms) == NOTIFY_STOP)
> + return;
> + apply keysym;
> + notifier_call_chain(KBD_POST_KEYSYM,¶ms);
> +}
> +
> +NOTE: This notifier is usually called from interrupt context.
> --
---
~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] x86 (Linux Tiny): configure out support for some processors
On 2/8/08, Michael Opdenacker <[EMAIL PROTECTED]> wrote: > +config CPU_SUP_INTEL > + default y > + bool "Support Intel processors" if PROCESSOR_SELECT > + help > + This enables extended support for Intel processors > -obj-$(CONFIG_X86_32) += intel.o > +obj-$(CONFIG_CPU_SUP_INTEL)+= intel.o This config option should probably depend on X86_32. -- Taral <[EMAIL PROTECTED]> "Please let me know if there's any further trouble I can give you." -- Unknown -- 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/
REPOST: [PATCH] Add iSCSI iBFT support (v0.4.7)
Whoops. I've attached an incorrect patch in the previous e-mail (http://lkml.org/lkml/2008/2/8/350) that didn't take in to account the 'reserve_bootmem' parameters changes. Here is fresher copy which has been tested on 2.6.24-git19 on a machine with iBFT and without. This patch (v0.4.7) adds /sysfs/firmware/ibft/[initiator|targetX|ethernetX] directories along with text properties which export the the iSCSI Boot Firmware Table (iBFT) structure. What is iSCSI Boot Firmware Table? It is a mechanism for the iSCSI tools to extract from the machine NICs the iSCSI connection information so that they can automagically mount the iSCSI share/target. Currently the iSCSI information is hard-coded in the initrd. The /sysfs entries are read-only one-name-and-value fields. The usual set of data exposed is: # for a in `find /sys/firmware/ibft/ -type f -print`; do echo -n "$a: "; cat $a; done /sys/firmware/ibft/target0/target-name: iqn.2007.com.intel-sbx44:storage-10gb /sys/firmware/ibft/target0/nic-assoc: 0 /sys/firmware/ibft/target0/chap-type: 0 /sys/firmware/ibft/target0/lun: /sys/firmware/ibft/target0/port: 3260 /sys/firmware/ibft/target0/ip-addr: 192.168.79.116 /sys/firmware/ibft/target0/flags: 3 /sys/firmware/ibft/target0/index: 0 /sys/firmware/ibft/ethernet0/mac: 00:11:25:9d:8b:01 /sys/firmware/ibft/ethernet0/vlan: 0 /sys/firmware/ibft/ethernet0/gateway: 192.168.79.254 /sys/firmware/ibft/ethernet0/origin: 0 /sys/firmware/ibft/ethernet0/subnet-mask: 255.255.252.0 /sys/firmware/ibft/ethernet0/ip-addr: 192.168.77.41 /sys/firmware/ibft/ethernet0/flags: 7 /sys/firmware/ibft/ethernet0/index: 0 /sys/firmware/ibft/initiator/initiator-name: iqn.2007-07.com:konrad.initiator /sys/firmware/ibft/initiator/flags: 3 /sys/firmware/ibft/initiator/index: 0 For full details of the IBFT structure please take a look at: ftp://ftp.software.ibm.com/systems/support/system_x_pdf/ibm_iscsi_boot_firmware_table_v1.02.pdf Signed-off-by: Konrad Rzeszutek <[EMAIL PROTECTED]> Cc: Mike Christie <[EMAIL PROTECTED]> Cc: Peter Jones <[EMAIL PROTECTED]> Cc: James Bottomley <[EMAIL PROTECTED]> Cc: Greg KH <[EMAIL PROTECTED]> Documentation/ABI/testing/sysfs-ibft | 23 arch/x86/kernel/setup_32.c |3 arch/x86/kernel/setup_64.c |4 drivers/firmware/Kconfig | 20 drivers/firmware/Makefile|2 drivers/firmware/iscsi_ibft.c| 985 +++ drivers/firmware/iscsi_ibft_find.c | 82 ++ include/linux/iscsi_ibft.h | 38 + 8 files changed, 1157 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-ibft b/Documentation/ABI/testing/sysfs-ibft new file mode 100644 index 000..062c009 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-ibft @@ -0,0 +1,23 @@ +What: /sys/firmware/ibft/initiator +Date: November 2007 +Contact: Konrad Rzeszutek <[EMAIL PROTECTED]> +Description: The /sys/firmware/ibft/initiator directory will contain + files that expose the iSCSI Boot Firmware Table initiator data. + Usually this contains the Initiator name. + +What: /sys/firmware/ibft/targetX +Date: November 2007 +Contact: Konrad Rzeszutek <[EMAIL PROTECTED]> +Description: The /sys/firmware/ibft/targetX directory will contain + files that expose the iSCSI Boot Firmware Table target data. + Usually this contains the target's IP address, boot LUN, + target name, and what NIC it is associated with. It can also + contain the CHAP name (and password), the reverse CHAP + name (and password) + +What: /sys/firmware/ibft/ethernetX +Date: November 2007 +Contact: Konrad Rzeszutek <[EMAIL PROTECTED]> +Description: The /sys/firmware/ibft/ethernetX directory will contain + files that expose the iSCSI Boot Firmware Table NIC data. + This can this can the IP address, MAC, and gateway of the NIC. diff --git a/arch/x86/kernel/setup_32.c b/arch/x86/kernel/setup_32.c index d1d8c34..9bd9482 100644 --- a/arch/x86/kernel/setup_32.c +++ b/arch/x86/kernel/setup_32.c @@ -39,6 +39,7 @@ #include #include #include +#include #include #include #include @@ -651,6 +652,8 @@ void __init setup_bootmem_allocator(void) #endif numa_kva_reserve(); reserve_crashkernel(); + + reserve_ibft_region(); } /* diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c index c0d8208..8efab8f 100644 --- a/arch/x86/kernel/setup_64.c +++ b/arch/x86/kernel/setup_64.c @@ -33,6 +33,7 @@ #include #include #include +#include #include #include #include @@ -425,6 +426,9 @@ void __init setup_arch(char **cmdline_p) } #endif reserve_crashkernel(); + + reserve_ibft_region(); + paging_init(); map_vsyscall(); diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig index 05f02a3..40ffd76 100644 --- a
Re: [PATCH] affs: fix shadowed variable sparse warnings
On Fri, 2008-02-08 at 18:53 -0800, Harvey Harrison wrote:
> diff --git a/fs/affs/file.c b/fs/affs/file.c
> index 6e0c939..ac05dc2 100644
> --- a/fs/affs/file.c
> +++ b/fs/affs/file.c
> @@ -570,11 +570,11 @@ affs_extent_file_ofs(struct inode *inode, u32 newsize)
> bh->b_state &= ~(1UL << BH_New);
> mark_buffer_dirty_inode(bh, inode);
> if (prev_bh) {
> - u32 tmp = be32_to_cpu(AFFS_DATA_HEAD(prev_bh)->next);
> - if (tmp)
> - affs_warning(sb, "extent_file_ofs", "next block
> already set for %d (%d)", bidx, tmp);
> + u32 _tmp = be32_to_cpu(AFFS_DATA_HEAD(prev_bh)->next);
Perhaps u32 next = be32_to_cpu(AFFS_DATA_HEAD(prev_bh)->next);
--
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] affs: fix shadowed variable sparse warnings
Introduce _tmp in the small if-blocks where this is shadowed.
fs/affs/file.c:573:8: warning: symbol 'tmp' shadows an earlier one
fs/affs/file.c:530:6: originally declared here
fs/affs/file.c:714:9: warning: symbol 'tmp' shadows an earlier one
fs/affs/file.c:661:6: originally declared here
fs/affs/file.c:746:9: warning: symbol 'tmp' shadows an earlier one
fs/affs/file.c:661:6: originally declared here
Remove declaration and assign to original variable as we are going
to return from the function at this point anyway.
fs/affs/file.c:831:7: warning: symbol 'size' shadows an earlier one
fs/affs/file.c:813:6: originally declared here
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
Roman, any interest?
fs/affs/file.c | 26 +-
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/fs/affs/file.c b/fs/affs/file.c
index 6e0c939..ac05dc2 100644
--- a/fs/affs/file.c
+++ b/fs/affs/file.c
@@ -570,11 +570,11 @@ affs_extent_file_ofs(struct inode *inode, u32 newsize)
bh->b_state &= ~(1UL << BH_New);
mark_buffer_dirty_inode(bh, inode);
if (prev_bh) {
- u32 tmp = be32_to_cpu(AFFS_DATA_HEAD(prev_bh)->next);
- if (tmp)
- affs_warning(sb, "extent_file_ofs", "next block
already set for %d (%d)", bidx, tmp);
+ u32 _tmp = be32_to_cpu(AFFS_DATA_HEAD(prev_bh)->next);
+ if (_tmp)
+ affs_warning(sb, "extent_file_ofs", "next block
already set for %d (%d)", bidx, _tmp);
AFFS_DATA_HEAD(prev_bh)->next =
cpu_to_be32(bh->b_blocknr);
- affs_adjust_checksum(prev_bh, bh->b_blocknr - tmp);
+ affs_adjust_checksum(prev_bh, bh->b_blocknr - _tmp);
mark_buffer_dirty_inode(prev_bh, inode);
affs_brelse(prev_bh);
}
@@ -711,11 +711,11 @@ static int affs_write_end_ofs(struct file *file, struct
address_space *mapping,
AFFS_DATA_HEAD(bh)->next = 0;
bh->b_state &= ~(1UL << BH_New);
if (prev_bh) {
- u32 tmp =
be32_to_cpu(AFFS_DATA_HEAD(prev_bh)->next);
- if (tmp)
- affs_warning(sb, "commit_write_ofs",
"next block already set for %d (%d)", bidx, tmp);
+ u32 _tmp =
be32_to_cpu(AFFS_DATA_HEAD(prev_bh)->next);
+ if (_tmp)
+ affs_warning(sb, "commit_write_ofs",
"next block already set for %d (%d)", bidx, _tmp);
AFFS_DATA_HEAD(prev_bh)->next =
cpu_to_be32(bh->b_blocknr);
- affs_adjust_checksum(prev_bh, bh->b_blocknr -
tmp);
+ affs_adjust_checksum(prev_bh, bh->b_blocknr -
_tmp);
mark_buffer_dirty_inode(prev_bh, inode);
}
}
@@ -743,11 +743,11 @@ static int affs_write_end_ofs(struct file *file, struct
address_space *mapping,
AFFS_DATA_HEAD(bh)->next = 0;
bh->b_state &= ~(1UL << BH_New);
if (prev_bh) {
- u32 tmp =
be32_to_cpu(AFFS_DATA_HEAD(prev_bh)->next);
- if (tmp)
- affs_warning(sb, "commit_write_ofs",
"next block already set for %d (%d)", bidx, tmp);
+ u32 _tmp =
be32_to_cpu(AFFS_DATA_HEAD(prev_bh)->next);
+ if (_tmp)
+ affs_warning(sb, "commit_write_ofs",
"next block already set for %d (%d)", bidx, _tmp);
AFFS_DATA_HEAD(prev_bh)->next =
cpu_to_be32(bh->b_blocknr);
- affs_adjust_checksum(prev_bh, bh->b_blocknr -
tmp);
+ affs_adjust_checksum(prev_bh, bh->b_blocknr -
_tmp);
mark_buffer_dirty_inode(prev_bh, inode);
}
} else if (be32_to_cpu(AFFS_DATA_HEAD(bh)->size) < tmp)
@@ -828,8 +828,8 @@ affs_truncate(struct inode *inode)
struct address_space *mapping = inode->i_mapping;
struct page *page;
void *fsdata;
- u32 size = inode->i_size;
int res;
+ size = inode->i_size;
res = mapping->a_ops->write_begin(NULL, mapping, size, 0, 0,
&page, &fsdata);
if (!res)
--
1.5.4.1219.g65b9
--
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] correct inconsistent ntp interval/tick_length usage
On Fri, 2008-02-08 at 18:33 +0100, Roman Zippel wrote: > Hi, > > On Fri, 1 Feb 2008, John Stultz wrote: > > > > CLOCK_TICK_ADJUST is based on LATCH and HZ, if the update frequency isn't > > > based on HZ, there is no point in using it! > > > > Hey Roman, > > > > Again, I'm sorry I don't seem to be following your objections. If you > > want to suggest a different patch to fix the issue, it might help. > > I already gave you the necessary details for how to set > NTP_INTERVAL_LENGTH and in the previous mail I explained the basis for it. -ENOPATCH We're taking weeks to critique fairly small bug fix. I'm sure we both have better things to do then continue to misunderstand each other. I'll do the testing and will happily ack it if it resolves the issue. > I really don't understand what's your problem with it. Why do you try to > make it more complex than necessary? Again, I profusely apologize for not understanding your suggestions. I do appreciate your feedback and I really respect your insistence on getting this right, but I do not see exactly how your comments connect to resolving the bug I'm trying to fix. > > The big issue for me, is that we have to initialize the clocksource > > cycle interval so it matches the base tick_length that NTP uses. > > > > To be clear, the issue I'm trying to address is only this: > > Assuming there is no NTP adjustment yet to be made, if we initialize the > > clocksource interval to X, then compare it with Y when we accumulate, we > > introduce error if X and Y are not the same. > > > > It really doesn't matter how long the length is, if we're including > > CLOCK_TICK_ADJUST, or if it really matches the actual HZ tick length or > > not. The issue is that we have to be consistent. If we're not, then we > > introduce error that ntpd has to additionally correct for. > > You don't create consistency by adding corrections all over the place > until it adds up to the right sum. Uh, I'd argue that you create consistency by using the same method on both sides of the equation. That's what I'm trying to do. Now, If you're disputing that I'm correcting the wrong side of the equation, then we're getting somewhere. But its still not clear to me how you're suggesting the other side (which is calculated in ntp_update_frequency) be changed. > The current correction is already somewhat of a hack and I'd rather get > rid of it than to let it spread all over the place (it's really only > needed so that people with weird HZ settings don't hit the 500ppm limit > and we're basically cheating to the ntpd by not telling it the real > frequency). Please keep the knowledge about this crutch at a single place > and don't spread it. > Anyway, for NO_HZ this correction is completely irrelevant, so again > there's no point in adding random values all over the place until you get > the correct result. You keep on bringing up NO_HZ, and again, the bug I'm trying to fix occurs with or without NO_HZ. The fix I proposed resolves the issue with or without NO_HZ. > The only other alternative would be to calculate this correction > dynamically. For this you leave NTP_INTERVAL_LENGTH as is and when > changing clocks you check whether "abs(((cs->xtime_interval * > NTP_INTERVAL_FREQ) >> cs->shift) - NSEC_PER_SEC)" exceeds a certain limit > (e.g. 200usec) and in this case you print a warning message, that the > clock has large base drift value and is a bad ntp source and apply a > correction value. This way the correction only hits the very few system > which might need it and it would be the prefered solution, but it also > requires a few more changes. Uh, that seems to be just checking if the xtime_interval is off base, or if the ntp correction has gone too far. I just don't see how this connects to the issue at hand. Just so we're current, I've refined the patch further and included it below. It now addresses error caused by the intervals of adjusted clocksource being recalculated on clocksource changes (and thus including the adjustment in the base interval). thanks -john Fix time skew caused by inconsistent use of NTP_INTERVAL_LENGTH and current_tick_length(). Patch has three components: 1) Reverts the first version of this patch that made it upstream (while not perfect, its still avoids the issue for most users). 2) Changes NTP_INTERVAL_LENGTH to be consistent with the calculations made in ntp_update_frequency(). 3) Splits the clocksource mult value into two parts: the original mult component and the ntp adjusted mult_adj component. This allows us to correctly recalculate the base xtime_intervals if users switch back and forth between adjusted clocksources. Signed-off-by: John Stultz <[EMAIL PROTECTED]> diff --git a/arch/ia64/kernel/time.c b/arch/ia64/kernel/time.c index 3ab0427..07cacc9 100644 --- a/arch/ia64/kernel/time.c +++ b/arch/ia64/kernel/time.c @@ -357,7 +357,7 @@ void update_vsyscall(struct timespec *wall, struct clocksource *c) /* copy fsyscall
Re: [ofa-general] Re: [patch 0/6] MMU Notifiers V6
On Sat, 9 Feb 2008, Andrea Arcangeli wrote: > The VM shouldn't break if try_to_unmap doesn't actually make the page > freeable for whatever reason. Permanent pins shouldn't happen anyway, VM is livelocking if too many page are pinned that way right now. The higher the processors per node the higher the risk of livelock because more processors are in the process of cycling through pages that have an elevated refcount. > so defining an ad-hoc API for that doesn't sound too appealing. Not > sure if old hardware deserves those special lru-size-reduction > optimizations but it's not my call (certainly swapoff/mlock would get > higher priority in that lru-size-reduction area). Rik has a patchset under development that addresses issues like this. The elevated refcount pin problem is not really relevant to the patchset we are discussing here. -- 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: [ofa-general] Re: [patch 0/6] MMU Notifiers V6
On Fri, Feb 08, 2008 at 05:27:03PM -0800, Christoph Lameter wrote: > Pages will still be on the LRU and cycle through rmap again and again. > If page migration is used on those pages then the code may make repeated > attempt to migrate the page thinking that the page count must at some > point drop. > > I do not think that the page count was intended to be used to pin pages > permanently. If we had a marker on such pages then we could take them off > the LRU and not try to migrate them. The VM shouldn't break if try_to_unmap doesn't actually make the page freeable for whatever reason. Permanent pins shouldn't happen anyway, so defining an ad-hoc API for that doesn't sound too appealing. Not sure if old hardware deserves those special lru-size-reduction optimizations but it's not my call (certainly swapoff/mlock would get higher priority in that lru-size-reduction area). -- 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: Scheduler(?) regression from 2.6.22 to 2.6.24 for short-lived threads
Olof Johansson wrote: Hi, I ended up with a customer benchmark in my lap this week that doesn't do well on recent kernels. :( After cutting it down to a simple testcase/microbenchmark, it seems like recent kernels don't do as well with short-lived threads competing with the thread it's cloned off of. The CFS scheduler changes come to mind, but I suppose it could be caused by something else as well. The pared-down testcase is included below. Reported runtime for the testcase has increased almost 3x between 2.6.22 and 2.6.24: 2.6.22: 3332 ms 2.6.23: 4397 ms 2.6.24: 8953 ms 2.6.24-git19: 8986 ms While running, it'll fork off a bunch of threads, each doing just a little work, then busy-waiting on the original thread to finish as well. Yes, it's incredibly stupidly coded but that's not my point here. During run, (runtime 10s on my 1.5GHz Core2 Duo laptop), vmstat 2 shows: 0 0 0 115196 364748 224839600 0 0 163 89 0 0 100 0 2 0 0 115172 364748 224839600 0 0 270 178 24 0 76 0 2 0 0 115172 364748 224839600 0 0 402 283 52 0 48 0 2 0 0 115180 364748 224839600 0 0 402 281 50 0 50 0 2 0 0 115180 364764 224839600 022 403 295 51 0 48 1 2 0 0 115056 364764 224839600 0 0 399 280 52 0 48 0 0 0 0 115196 364764 224839600 0 0 241 141 17 0 83 0 0 0 0 115196 364768 224839600 0 2 155 67 0 0 100 0 0 0 0 115196 364768 224839600 0 0 148 62 0 0 100 0 I.e. runqueue is 2, but only one cpu is busy. However, this still seems true on the kernel that runs the testcase in more reasonable time. Also, 'time' reports real and user time roughly the same on all kernels, so it's not that the older kernels are better at spreading out the load between the two cores (either that or it doesn't account for stuff right). I've included the config files, runtime output and vmstat output at http://lixom.net/~olof/threadtest/. I see similar behaviour on PPC as well as x86, so it's not architecture-specific. Testcase below. Yes, I know, there's a bunch of stuff that could be done differently and better, but it still doesn't motivate why there's a 3x slowdown between kernel versions... I would say that something coded this bizarrely is really an application bug and not something that one could call a kernel regression. Any change in how the parent and child threads get scheduled will have a huge impact on this test. I bet if you replace that busy wait with a pthread_cond_wait or something similar, this problem goes away. Hopefully it doesn't have to be pointed out that spawning off threads to do so little work before terminating is inefficient, a thread pool or even just a single thread would likely do a much better job.. -- 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] keyboard notifier documentation
Document the keyboard notifier.
Signed-off-by: Samuel Thibault <[EMAIL PROTECTED]>
--- /dev/null 2008-02-09 01:22:34.790011677 +
+++ linux/Documentation/input/notifier.txt 2008-02-09 01:28:12.0
+
@@ -0,0 +1,52 @@
+Keyboard notifier
+
+One can use register_keyboard_notifier to get called back on keyboard
+events (see kbd_keycode() function for details). The passed structure is
+keyboard_notifier_param:
+
+- 'vc' always provide the VC for which the keyboard event applies ;
+- 'down' is 1 for a key press event, 0 for a key release ;
+- 'shift' is the current modifier state, mask bit indexes are KG_* ;
+- 'value' depends on the type of event.
+
+- KBD_KEYCODE events are always sent before other events, value is the keycode.
+- KBD_UNBOUND_KEYCODE events are sent if the keycode is not bound to a keysym.
+ value is the keycode.
+- KBD_UNICODE events are sent if the keycode -> keysym translation produced a
+ unicode character. value is the unicode value.
+- KBD_KEYSYM events are sent if the keycode -> keysym translation produced a
+ non-unicode character. value is the keysym.
+- KBD_POST_KEYSYM events are sent after the treatment of non-unicode keysyms.
+ That permits to inspect the resulting LEDs for instance.
+
+For each kind of event but the last, the callback may return NOTIFY_STOP in
+order to "eat" the event: the notify loop is stopped and the keyboard event is
+dropped.
+
+I a rough C snippet, we have:
+
+kbd_keycode(keycode) {
+ ...
+ params.value = keycode;
+ if (notifier_call_chain(KBD_KEYCODE,¶ms) == NOTIFY_STOP)
+ || !bound) {
+ notifier_call_chain(KBD_UNBOUND_KEYCODE,¶ms);
+ return;
+ }
+
+ if (unicode) {
+ param.value = unicode;
+ if (notifier_call_chain(KBD_UNICODE,¶ms) == NOTIFY_STOP)
+ return;
+ emit unicode;
+ return;
+ }
+
+ params.value = keysym;
+ if (notifier_call_chain(KBD_KEYSYM,¶ms) == NOTIFY_STOP)
+ return;
+ apply keysym;
+ notifier_call_chain(KBD_POST_KEYSYM,¶ms);
+}
+
+NOTE: This notifier is usually called from interrupt context.
--
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] scsi_error: Fix language abuse.
Alan Cox wrote:
The word "illegal" has a precise dictionary meaning of "prohibited by
law".
Also "contrary to or forbidden by official rules, regulations, etc".
So word meanings are like standards, there are so many to choose
from.
The error messages are therefore incorrect as so far nobody has
made SCSI violations a criminal offence.
Most USB mass storage implementations should result in jail
terms for the responsible parties.
This corrects scsi to match various other subsystems I've slowly been
ridding of this.
Pedantically-signed-off-by: Alan Cox <[EMAIL PROTECTED]>
Please don't do this.
- {0x2004, "Illegal command while in write capable state"},
+ {0x2004, "Invalid command while in write capable state"},
Several reasons:
1) Those strings appear in an international standard.
In this case SPC-3 ANSI INCITS 408-2005.
2) The way that INCITS standard (and others) is structured,
the relevant part of the text refers to a specific
additional sense code + qualifier instance by _name_
(e.g. "Illegal command while in write capable state")
not by number (e.g. 0x20,0x4). So given the Alan Cox
rendition of that string in a log, a diligent debugger
would need to get to constants.c to find the corresponding
asc/ascq numeric sequence, then search Annex D of SPC-3
to find the t10.org version of that string, then search
the body of SPC-3 and other t10 device class specific
standards for a match on the t10 string.
Vendor product manuals would tend to use the t10.org
strings as well.
3) I maintain constants.c and I do that with the help
of a program that compares t10's tables (specifically
http://www.t10.org/lists/asc-num.txt ) with the table
in constants.c . I'm glad to send you a copy so you
can take over maintaining the sanitized list and
cope with the abuse that may follow.
If you feel strongly about this then you could take it
up with ANSI or BS (a great acronym IMO).
Doug Gilbert
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.24-mm1/drivers/scsi/constants.c
linux-2.6.24-mm1/drivers/scsi/constants.c
--- linux.vanilla-2.6.24-mm1/drivers/scsi/constants.c 2008-02-06
14:14:40.0 +
+++ linux-2.6.24-mm1/drivers/scsi/constants.c 2008-02-06 14:35:16.0
+
@@ -606,10 +606,10 @@
{0x2001, "Access denied - initiator pending-enrolled"},
{0x2002, "Access denied - no access rights"},
{0x2003, "Access denied - invalid mgmt id key"},
- {0x2004, "Illegal command while in write capable state"},
+ {0x2004, "Invalid command while in write capable state"},
{0x2005, "Obsolete"},
- {0x2006, "Illegal command while in explicit address mode"},
- {0x2007, "Illegal command while in implicit address mode"},
+ {0x2006, "Invalid command while in explicit address mode"},
+ {0x2007, "Invalid command while in implicit address mode"},
{0x2008, "Access denied - enrollment conflict"},
{0x2009, "Access denied - invalid LU identifier"},
{0x200A, "Access denied - invalid proxy token"},
@@ -620,7 +620,7 @@
{0x2102, "Invalid address for write"},
{0x2103, "Invalid write crossing layer jump"},
- {0x2200, "Illegal function (use 20 00, 24 00, or 26 00)"},
+ {0x2200, "Invalid function (use 20 00, 24 00, or 26 00)"},
{0x2400, "Invalid field in cdb"},
{0x2401, "CDB decryption error"},
@@ -697,7 +697,7 @@
{0x2C02, "Invalid combination of windows specified"},
{0x2C03, "Current program area is not empty"},
{0x2C04, "Current program area is empty"},
- {0x2C05, "Illegal power condition request"},
+ {0x2C05, "Invalid power condition request"},
{0x2C06, "Persistent prevent conflict"},
{0x2C07, "Previous busy status"},
{0x2C08, "Previous task set full status"},
@@ -1014,7 +1014,7 @@
{0x6300, "End of user area encountered on this track"},
{0x6301, "Packet does not fit in available space"},
- {0x6400, "Illegal mode for this track"},
+ {0x6400, "Invalid mode for this track"},
{0x6401, "Invalid packet size"},
{0x6500, "Voltage fault"},
@@ -1124,7 +1124,7 @@
"Not Ready", /* 2: The addressed target is not ready */
"Medium Error", /* 3: Data error detected on the medium */
"Hardware Error", /* 4: Controller or device failure */
- "Illegal Request", /* 5: Error in request */
+ "Invalid Request", /* 5: Error in request */
"Unit Attention", /* 6: Removable medium was changed, or
the target has been reset, or ... */
"Data Protect", /* 7: Access to the data is blocked */
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe fro
Re: [ofa-general] Re: [patch 0/6] MMU Notifiers V6
On Sat, 9 Feb 2008, Andrea Arcangeli wrote: > > H.. that means we need something that actually pins pages for good so > > that the VM can avoid reclaiming it and so that page migration can avoid > > trying to migrate them. Something like yet another page flag. > > What's wrong with pinning with the page count like now? Dumb adapters > would simply not register themself in the mmu notifier list no? Pages will still be on the LRU and cycle through rmap again and again. If page migration is used on those pages then the code may make repeated attempt to migrate the page thinking that the page count must at some point drop. I do not think that the page count was intended to be used to pin pages permanently. If we had a marker on such pages then we could take them off the LRU and not try to migrate them. -- 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: [ofa-general] Re: [patch 0/6] MMU Notifiers V6
On Fri, Feb 08, 2008 at 04:36:16PM -0800, Christoph Lameter wrote: > On Fri, 8 Feb 2008, Roland Dreier wrote: > > > That would of course work -- dumb adapters would just always fail, > > which might be inefficient. > > H.. that means we need something that actually pins pages for good so > that the VM can avoid reclaiming it and so that page migration can avoid > trying to migrate them. Something like yet another page flag. What's wrong with pinning with the page count like now? Dumb adapters would simply not register themself in the mmu notifier list no? > > Ccing Rik. -- 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] prevent gpio chip drivers from unloading while used
> > > As long as one or more GPIOs on a gpio chip are used its driver should > > > not > > > be unloaded. > > > > The mechanism currently in place is to have gpiochip_remove() fail > > if the platform's teardown() logic doesn't reject it. (It may be > > practical to have the teardown code get rid of the users...) That > > would be reflected as an "rmmod" failure. > > > > Are you saying that doesn't work? > > Yes, that's what I'm saying. I had a GPIO in use and rmmod-ed pca953x. It > did produce an error message > > pca953x 0-0041: gpiochip_remove() failed, -16 > > , but rmmod completed. Doesn't that seem buglike to you? Oh, right -- the module exit code will ignore that status, it doesn't even have a way to report failures any more. Crap. So it looks like we have no choice but to do this. Can you make sure all the rmmod-capable gpio_chip drivers support this? Ignore the SOC support, that never supports rmmod -- just the stuff in drivers/gpio. > AFAIU, the only 2 ways currently to prevent rmmod > from completing, are: increment module use-count, then the respective > module_exit() function is not called at all and rmmod fails with -EBUSY. > Or block in rmmod until the resource becomes free. None of these has > happened. BTW, I think, there's the same problem with i2c adapter drivers. Right. In fact, every time you'd expect driver removal errors to cause module removal to fail. Maybe this is part of that whole "should we even *support* rmmod" discussion, which I tuned out. - 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: [stable] [patch 00/45] 2.6.24-stable review
On Thu, Feb 07, 2008 at 01:58:34PM -0800, Greg KH wrote: > On Thu, Feb 07, 2008 at 11:41:42PM +0200, S.??a??lar Onur wrote: > > Hi; > > > > 07 ??ub 2008 Per tarihinde, Greg KH ??unlar?? yazmt??: > > > This is the start of the stable review cycle for the 2.6.24.1 release. > > > There are 45 patches in this series, all will be posted as a response to > > > this one. If anyone has any issues with these being applied, please let > > > us know. If anyone is a maintainer of the proper subsystem, and wants > > > to add a Signed-off-by: line to the patch, please respond with it. > > > > If its possible could you please add [1] "mac80211: hardware scan rework" > > and [2] "mac80211: Restore rx.fc before every invocation of > > ieee80211_invoke_rx_handlers" into -stable too? > > > > [1] > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ece8edddf067d21c4e5abfe3f1205da1588edbb2 > > [2] > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=69f817b654d683265118188bbfb8bc0d8978cce6 > > I can queue them up for the next one after this release. In looking at these, I would rather that either the wireless maintainer, or the network maintainer send these too us, to verify that they are needed, and the backport works properly. So please go ask them to send these in. 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: [LINUX-KERNEL] C++ in linux kernel
2008/2/9, Jan Engelhardt <[EMAIL PROTECTED]>: > > On Feb 9 2008 00:14, Joonwoo Park wrote: > >2008/2/8, rohit h <[EMAIL PROTECTED]>: > >> Hi, > >> I am a kernel newbie. > >> I tried to insmod a C++ module containing classes, inheritance. > >> I am getting 'unresolved symbol' error when I use the 'new' keyword. > >> What could the problem be? > >> > >> What kind of runtime support is needed ( arm linux kernel)? Is a > >> patch available for it? > >> > >Please take a look at click modular router which is using c++ as a > >linux kernel module. > >http://www.read.cs.ucla.edu/click/ > >The lib/glue.cc provides custom operator new. > > Uh, let's not make the world worse :) > Just call malloc from C++, and carefully select what C++ features > you are going to use. The VMware source for example does it right. > Yep, also I think that if kmalloc is possible it would better than the operator new. Rohit, Compiling the kernel module with g++ is not a simple work, you may need big patch for kernel itself. The c++ has more internal keywords than c. e.g) new, delete, and :: The new and delete should be re-spelled with another names. The '::' is used in inline assembly however in c++ it means global namespace. In conclusion, I don't recommand c++ for linux kernel without very special goal like the click project :) Joonwoo -- 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] prevent gpio chip drivers from unloading while used
On Fri, 8 Feb 2008, David Brownell wrote:
> On Friday 08 February 2008, Guennadi Liakhovetski wrote:
> > As long as one or more GPIOs on a gpio chip are used its driver should not
> > be unloaded.
>
> The mechanism currently in place is to have gpiochip_remove() fail
> if the platform's teardown() logic doesn't reject it. (It may be
> practical to have the teardown code get rid of the users...) That
> would be reflected as an "rmmod" failure.
>
> Are you saying that doesn't work?
Yes, that's what I'm saying. I had a GPIO in use and rmmod-ed pca953x. It
did produce an error message
pca953x 0-0041: gpiochip_remove() failed, -16
, but rmmod completed. AFAIU, the only 2 ways currently to prevent rmmod
from completing, are: increment module use-count, then the respective
module_exit() function is not called at all and rmmod fails with -EBUSY.
Or block in rmmod until the resource becomes free. None of these has
happened. BTW, I think, there's the same problem with i2c adapter drivers.
> I'm not a huge fan of explicit manipulation of module refcounts,
Neither am I.
> though there can be a place for such things.
>
> Supporting removal of a gpio_chip is my least favorite feature of
> this framework. Especially for controller drivers which could
> realistically manage per-GPIO IRQs ... since genirq doesn't seem to
> like the notion of irq_chip removal. (The MCP23s08 and its I2C
> sibling the MCP23008 have real IRQ control logic, but the pca953x
> and pcf857x chips have a much less functional IRQ mechanism.)
Well, if all GPIOs of a gpio-chip are free, is there a reason why the
module cannot be removed? That's what you have the request-free mechanism
for, isn't it?
> > Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
> >
> > ---
> >
> > Note, that existing drivers do not have to be modified,
>
> If they call gpiochip_remove(), they should be modified to ensure
> they initialize this new "owner" field. That would be all of the
> drivers currently in drivers/gpio (not just pca953x).
>
>
> > for example those,
> > that are always statically linked in the kernel, as long as the respective
> > struct gpio_chip is nullified before calling gpiochip_add().
>
> By "nullified", I presume you mean to suggest that the "owner" field
> be initialized to NULL ... which will normally be the case, when the
> gpio_chip is a static data structure or comes from kzalloc().
Exactly this is what I meant. And this is why most existing drivers will
not be immediately broken if this patches are accepted. But we can and
should update them too.
Thanks
Guennadi
> > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> > index d8db2f8..dd535e1 100644
> > --- a/drivers/gpio/gpiolib.c
> > +++ b/drivers/gpio/gpiolib.c
> > @@ -177,6 +177,9 @@ int gpio_request(unsigned gpio, const char *label)
> > if (desc->chip == NULL)
> > goto done;
> >
> > + if (!try_module_get(desc->chip->owner))
> > + goto done;
> > +
> > /* NOTE: gpio_request() can be called in early boot,
> > * before IRQs are enabled.
> > */
> > @@ -184,8 +187,10 @@ int gpio_request(unsigned gpio, const char *label)
> > if (test_and_set_bit(FLAG_REQUESTED, &desc->flags) == 0) {
> > desc_set_label(desc, label ? : "?");
> > status = 0;
> > - } else
> > + } else {
> > status = -EBUSY;
> > + module_put(desc->chip->owner);
> > + }
> >
> > done:
> > if (status)
> > @@ -209,9 +214,10 @@ void gpio_free(unsigned gpio)
> > spin_lock_irqsave(&gpio_lock, flags);
> >
> > desc = &gpio_desc[gpio];
> > - if (desc->chip && test_and_clear_bit(FLAG_REQUESTED, &desc->flags))
> > + if (desc->chip && test_and_clear_bit(FLAG_REQUESTED, &desc->flags)) {
> > desc_set_label(desc, NULL);
> > - else
> > + module_put(desc->chip->owner);
> > + } else
> > WARN_ON(extra_checks);
> >
> > spin_unlock_irqrestore(&gpio_lock, flags);
> > diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
> > index 806b86c..f6d389a 100644
> > --- a/include/asm-generic/gpio.h
> > +++ b/include/asm-generic/gpio.h
> > @@ -3,6 +3,8 @@
> >
> > #ifdef CONFIG_HAVE_GPIO_LIB
> >
> > +#include
> > +
> > /* Platforms may implement their GPIO interface with library code,
> > * at a small performance cost for non-inlined operations and some
> > * extra memory (for code and for per-GPIO table entries).
> > @@ -52,6 +54,7 @@ struct seq_file;
> > */
> > struct gpio_chip {
> > char*label;
> > + struct module *owner;
> >
> > int (*direction_input)(struct gpio_chip *chip,
> > unsigned offset);
> >
>
>
---
Guennadi Liakhovetski
--
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.ht
Re: [ofa-general] Re: [patch 0/6] MMU Notifiers V6
On Fri, 8 Feb 2008, Roland Dreier wrote: > That would of course work -- dumb adapters would just always fail, > which might be inefficient. H.. that means we need something that actually pins pages for good so that the VM can avoid reclaiming it and so that page migration can avoid trying to migrate them. Something like yet another page flag. Ccing Rik. -- 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: [rft] s2ram wakeup moves to .c, could fix few machines
Rafael J. Wysocki wrote: Consolidated patch is appended. I'll test it tomorrow on x86-64. I'd like to add the cleaned up beeping code to it and perhaps try to push it for -mm testing without any further changes. We can still do more cleanups in followup patches. The other thing to figure out is to what extent we can clean up the conditionals in the video mode code by refactoring. All they really do here is save space by removing functionality not needed for wakeup, because I didn't know how much space was realistic. It's possible we can remove them altogether by having a dummy boot_params structure (4K). -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: Scheduler(?) regression from 2.6.22 to 2.6.24 for short-lived threads
On Sat, Feb 09, 2008 at 01:08:30AM +0100, Ingo Molnar wrote: > > * Olof Johansson <[EMAIL PROTECTED]> wrote: > > > 2.6.22: 3332 ms > > 2.6.23: 4397 ms > > 2.6.24: 8953 ms > > 2.6.24-git19: 8986 ms > > if you enable SCHED_DEBUG, and subtract 4 from the value of > /proc/sys/kernel/sched_features, does it get any better? > > if not, does writing 0 into /proc/sys/kernel/sched_features have any > impact? Doesn't seem to make a difference, either of them. I can unfortunately not retest on x86 at the moment, only powerpc. But it made no noticable difference in runtime w/ pasemi_defconfig and current mainline. -Olof -- 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: uml compile error
On Sat, Feb 09, 2008 at 01:05:15AM +0100, Jiri Kosina wrote: > On Sat, 9 Feb 2008, Adrian Bunk wrote: > > > Commit dd2cc4dff3b08ab54c4c177a080046bcc84ac41d broke uml: > > <-- snip --> > > ... > > CC fs/hostfs/hostfs_kern.o > > /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/hostfs/hostfs_kern.c: In > > function 'hostfs_show_options': > > /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/hostfs/hostfs_kern.c:328: > > error: dereferencing pointer to incomplete type > > make[3]: *** [fs/hostfs/hostfs_kern.o] Error 1 > > I guess we need this one? > > > > From: Jiri Kosina <[EMAIL PROTECTED]> > > UML: fix hostfs build >... Thanks that fixed it. 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: [PATCH] Documenting patch tags yet one more time
Jon wrote: > So here's a version which merges the information into > SubmittingPatches instead. Reviewed-by: Paul Jackson <[EMAIL PROTECTED]> --- That's my first time using that tag ... fun. Now I'm wondering if there might be some improvements that you, me, or someone could make to the SubmittingPatches file that would explain more clearly that PATCH's should start off, right from the top or after the initial From: line if present, with: - The body of the explanation, which will be copied to the permanent changelog to describe this patch. rather than opening with ephemeral reactions to the discussion of the moment which will make little "sense to a competent reader who has long since forgotten the immediate details of the discussion that might have led to this patch." As best my legalistic mind understands the patch format, such ephemeral reactions should go after the "---" marker line, in the same section as the diffstat would be placed. Or perhaps the patch format should be changed in this regard, since it is cumbersome and unnatural to embed the ephemeral opening comments half way down the patch, rather than opening with them. I don't know. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214 -- 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: [ofa-general] Re: [patch 0/6] MMU Notifiers V6
> I thought the adaptor can always remove the mapping by renegotiating > with the remote side? Even if its dumb then a callback could notify the > driver that it may be required to tear down the mapping. We then hold the > pages until we get okay by the driver that the mapping has been removed. Of course we can always destroy the memory region but that would break the semantics that applications expect. Basically an application can register some chunk of its memory and get a key that it can pass to a remote peer to let the remote peer operate on its memory via RDMA. And that memory region/key is expected to stay valid until there is an application-level operation to destroy it (or until the app crashes or gets killed, etc). > We could also let the unmapping fail if the driver indicates that the > mapping must stay. That would of course work -- dumb adapters would just always fail, which might be inefficient. -- 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: [rft] s2ram wakeup moves to .c, could fix few machines
On Friday, 8 of February 2008, Pavel Machek wrote:
> On Fri 2008-02-08 23:01:51, Rafael J. Wysocki wrote:
> > On Friday, 8 of February 2008, Pavel Machek wrote:
> > > Hi!
> > >
> > > Rafael, this is for you.
> >
> > Thanks.
> >
> > > My cleanups, relative to your cleanup patch. You may need manual patching
> > > around rep/stosd.
> >
> > OK, I'll try to merge it.
>
> For the record, now it is even tested on 32-bit and test-compiled on
> 64-bit.
Consolidated patch is appended. I'll test it tomorrow on x86-64.
I'd like to add the cleaned up beeping code to it and perhaps try to push it
for -mm testing without any further changes. We can still do more cleanups in
followup patches.
Thanks,
Rafael
---
arch/x86/boot/Makefile |2
arch/x86/boot/boot.h |5
arch/x86/boot/video-bios.c |6
arch/x86/boot/video-mode.c | 173
arch/x86/boot/video-vesa.c |8
arch/x86/boot/video-vga.c | 12 -
arch/x86/boot/video.c | 157 --
arch/x86/kernel/acpi/Makefile |9
arch/x86/kernel/acpi/realmode/Makefile | 58 +
arch/x86/kernel/acpi/realmode/copy.S |1
arch/x86/kernel/acpi/realmode/video-bios.c |1
arch/x86/kernel/acpi/realmode/video-mode.c |1
arch/x86/kernel/acpi/realmode/video-vesa.c |1
arch/x86/kernel/acpi/realmode/video-vga.c |1
arch/x86/kernel/acpi/realmode/wakemain.c | 26 ++
arch/x86/kernel/acpi/realmode/wakeup.S | 113 ++
arch/x86/kernel/acpi/realmode/wakeup.h | 35 +++
arch/x86/kernel/acpi/realmode/wakeup.lds.S | 61 +
arch/x86/kernel/acpi/sleep.c | 80 ++-
arch/x86/kernel/acpi/wakeup_32.S | 245 +-
arch/x86/kernel/acpi/wakeup_64.S | 313 -
arch/x86/kernel/acpi/wakeup_rm.S | 10
arch/x86/kernel/head_64.S |4
arch/x86/kernel/setup_32.c |4
arch/x86/kernel/smpboot_64.c | 10
25 files changed, 624 insertions(+), 712 deletions(-)
Index: linux-2.6/arch/x86/boot/Makefile
===
--- linux-2.6.orig/arch/x86/boot/Makefile
+++ linux-2.6/arch/x86/boot/Makefile
@@ -30,7 +30,7 @@ subdir- := compressed
setup-y+= a20.o cmdline.o copy.o cpu.o cpucheck.o edd.o
setup-y+= header.o main.o mca.o memory.o pm.o pmjump.o
-setup-y+= printf.o string.o tty.o video.o version.o
+setup-y+= printf.o string.o tty.o video.o video-mode.o
version.o
setup-$(CONFIG_X86_APM_BOOT) += apm.o
setup-$(CONFIG_X86_VOYAGER) += voyager.o
Index: linux-2.6/arch/x86/boot/boot.h
===
--- linux-2.6.orig/arch/x86/boot/boot.h
+++ linux-2.6/arch/x86/boot/boot.h
@@ -286,6 +286,11 @@ int getchar_timeout(void);
/* video.c */
void set_video(void);
+/* video-mode.c */
+int set_mode(u16 mode);
+int mode_defined(u16 mode);
+void probe_cards(int unsafe);
+
/* video-vesa.c */
void vesa_store_edid(void);
Index: linux-2.6/arch/x86/boot/video-bios.c
===
--- linux-2.6.orig/arch/x86/boot/video-bios.c
+++ linux-2.6/arch/x86/boot/video-bios.c
@@ -50,6 +50,7 @@ static int set_bios_mode(u8 mode)
if (new_mode == mode)
return 0; /* Mode change OK */
+#ifndef _WAKEUP
if (new_mode != boot_params.screen_info.orig_video_mode) {
/* Mode setting failed, but we didn't end up where we
started. That's bad. Try to revert to the original
@@ -59,13 +60,18 @@ static int set_bios_mode(u8 mode)
: "+a" (ax)
: : "ebx", "ecx", "edx", "esi", "edi");
}
+#endif
return -1;
}
static int bios_probe(void)
{
u8 mode;
+#ifdef _WAKEUP
+ u8 saved_mode = 0x03;
+#else
u8 saved_mode = boot_params.screen_info.orig_video_mode;
+#endif
u16 crtc;
struct mode_info *mi;
int nmodes = 0;
Index: linux-2.6/arch/x86/boot/video-mode.c
===
--- /dev/null
+++ linux-2.6/arch/x86/boot/video-mode.c
@@ -0,0 +1,173 @@
+/* -*- linux-c -*- --- *
+ *
+ * Copyright (C) 1991, 1992 Linus Torvalds
+ * Copyright 2007-2008 rPath, Inc. - All Rights Reserved
+ *
+ * This file is part of the Linux kernel, and is made available under
+ * the terms of the GNU General Public License version 2.
+ *
+ * --- */
+
+/*
+ * arch/i386/boot/video-mode.c
+ *
+ * Set the video mode. This is separated out into a different
+ * file in order to be shared with the ACPI w
Re: [patch 0/6] MMU Notifiers V6
On Fri, 8 Feb 2008, Andrew Morton wrote: > Quite possibly none of the infiniband developers even know about it.. Well Andrea's initial approach was even featured on LWN a couple of weeks back. -- 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/
ide/arm/bast-ide.c compile error
Commit 9e016a719209d95338e314b46c3012cc7feaaeec causes the following compile error: <-- snip --> ... CC drivers/ide/arm/bast-ide.o /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ide/arm/bast-ide.c: In function 'bastide_register': /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ide/arm/bast-ide.c:31: error: 'hwif' redeclared as different kind of symbol /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ide/arm/bast-ide.c:29: error: previous definition of 'hwif' was here make[4]: *** [drivers/ide/arm/bast-ide.o] Error 1 <-- snip --> 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: [ofa-general] Re: [patch 0/6] MMU Notifiers V6
On Fri, 8 Feb 2008, Roland Dreier wrote: > In general, this MMU notifier stuff will only be useful to a subset of > InfiniBand/RDMA hardware. Some adapters are smart enough to handle > changing the IO virtual -> bus/physical mapping on the fly, but some > aren't. For the dumb adapters, I think the current ib_umem_get() is > pretty close to as good as we can get: we have to keep the physical > pages pinned for as long as the adapter is allowed to DMA into the > memory region. I thought the adaptor can always remove the mapping by renegotiating with the remote side? Even if its dumb then a callback could notify the driver that it may be required to tear down the mapping. We then hold the pages until we get okay by the driver that the mapping has been removed. We could also let the unmapping fail if the driver indicates that the mapping must stay. -- 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: [ofa-general] Re: [patch 0/6] MMU Notifiers V6
> We have done several rounds of discussion on linux-kernel about this so > far and the IB folks have not shown up to join in. I have tried to make > this as general as possible. Sorry, this has been on my "things to look at" list for a while, but I haven't gotten a chance to really understand where things are yet. In general, this MMU notifier stuff will only be useful to a subset of InfiniBand/RDMA hardware. Some adapters are smart enough to handle changing the IO virtual -> bus/physical mapping on the fly, but some aren't. For the dumb adapters, I think the current ib_umem_get() is pretty close to as good as we can get: we have to keep the physical pages pinned for as long as the adapter is allowed to DMA into the memory region. For the smart adapters, we just need a chance to change the adapter's page table when the kernel/CPU's mapping changes, and naively, this stuff looks like it would work. Andrew, does that help? - R. -- 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/6] MMU Notifiers V6
On Fri, 8 Feb 2008 16:05:00 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]> wrote: > On Fri, 8 Feb 2008, Andrew Morton wrote: > > > You took it correctly, and I didn't understand the answer ;) > > We have done several rounds of discussion on linux-kernel about this so > far and the IB folks have not shown up to join in. I have tried to make > this as general as possible. infiniband would appear to be the major present in-kernel client of this new interface. So as a part of proving its usefulness, correctness, etc we should surely work on converting infiniband to use it, and prove its goodness. Quite possibly none of the infiniband developers even know about it.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Scheduler(?) regression from 2.6.22 to 2.6.24 for short-lived threads
* Olof Johansson <[EMAIL PROTECTED]> wrote: > 2.6.22: 3332 ms > 2.6.23: 4397 ms > 2.6.24: 8953 ms > 2.6.24-git19: 8986 ms if you enable SCHED_DEBUG, and subtract 4 from the value of /proc/sys/kernel/sched_features, does it get any better? if not, does writing 0 into /proc/sys/kernel/sched_features have any impact? Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/6] MMU Notifiers V6
On Fri, 8 Feb 2008, Andrew Morton wrote: > You took it correctly, and I didn't understand the answer ;) We have done several rounds of discussion on linux-kernel about this so far and the IB folks have not shown up to join in. I have tried to make this as general as possible. -- 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: uml compile error
On Sat, 9 Feb 2008, Adrian Bunk wrote: > Commit dd2cc4dff3b08ab54c4c177a080046bcc84ac41d broke uml: > <-- snip --> > ... > CC fs/hostfs/hostfs_kern.o > /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/hostfs/hostfs_kern.c: In > function 'hostfs_show_options': > /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/hostfs/hostfs_kern.c:328: error: > dereferencing pointer to incomplete type > make[3]: *** [fs/hostfs/hostfs_kern.o] Error 1 I guess we need this one? From: Jiri Kosina <[EMAIL PROTECTED]> UML: fix hostfs build We need to include mount.h to get vfsmount. Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]> diff --git a/fs/hostfs/hostfs_kern.c b/fs/hostfs/hostfs_kern.c index d0549cb..5222345 100644 --- a/fs/hostfs/hostfs_kern.c +++ b/fs/hostfs/hostfs_kern.c @@ -12,6 +12,7 @@ #include #include #include +#include #include "hostfs.h" #include "init.h" #include "kern.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/
scsi/arm/fas216.c compile error
Commit 30b0c37b27485a9cb897bfe3824f6f517b8c80d6 causes the following compile error: <-- snip --> ... CC drivers/scsi/arm/fas216.o /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/scsi/arm/fas216.c: In function 'fas216_std_done': /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/scsi/arm/fas216.c:2120: error: 'struct scsi_cmnd' has no member named 'request_bufflen' /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/scsi/arm/fas216.c:2122: error: 'struct scsi_cmnd' has no member named 'use_sg' make[4]: *** [drivers/scsi/arm/fas216.o] Error 1 <-- snip --> 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: [kvm-devel] KVM binary incompatiablity
On Fri, 08 Feb 2008 16:22:12 -0600 Anthony Liguori <[EMAIL PROTECTED]> wrote: > Stephen Hemminger wrote: > > I notice that recent KVM is incompatiable with older versions. > > > > Using a KVM image created on 2.6.24 will crash on 2.6.25 (or > > vice versa). It appears that Ubuntu Hardy has incorporated the 2.6.25 > > update even though it claims to be 2.6.24. > > > > This isn't intentional. What is the guest and how does it crash? > > I've been using the same image for most of KVM's development life cycle > without having issues. > > Regards, > > Anthony Liguori > I'll see if I can get a backtrace, it isn't reliably reproducible. -- Stephen Hemminger <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Scheduler(?) regression from 2.6.22 to 2.6.24 for short-lived threads
Hi,
I ended up with a customer benchmark in my lap this week that doesn't
do well on recent kernels. :(
After cutting it down to a simple testcase/microbenchmark, it seems like
recent kernels don't do as well with short-lived threads competing
with the thread it's cloned off of. The CFS scheduler changes come to
mind, but I suppose it could be caused by something else as well.
The pared-down testcase is included below. Reported runtime for the
testcase has increased almost 3x between 2.6.22 and 2.6.24:
2.6.22: 3332 ms
2.6.23: 4397 ms
2.6.24: 8953 ms
2.6.24-git19: 8986 ms
While running, it'll fork off a bunch of threads, each doing just a little
work, then busy-waiting on the original thread to finish as well. Yes,
it's incredibly stupidly coded but that's not my point here.
During run, (runtime 10s on my 1.5GHz Core2 Duo laptop), vmstat 2 shows:
0 0 0 115196 364748 224839600 0 0 163 89 0 0 100 0
2 0 0 115172 364748 224839600 0 0 270 178 24 0 76 0
2 0 0 115172 364748 224839600 0 0 402 283 52 0 48 0
2 0 0 115180 364748 224839600 0 0 402 281 50 0 50 0
2 0 0 115180 364764 224839600 022 403 295 51 0 48 1
2 0 0 115056 364764 224839600 0 0 399 280 52 0 48 0
0 0 0 115196 364764 224839600 0 0 241 141 17 0 83 0
0 0 0 115196 364768 224839600 0 2 155 67 0 0 100 0
0 0 0 115196 364768 224839600 0 0 148 62 0 0 100 0
I.e. runqueue is 2, but only one cpu is busy. However, this still seems
true on the kernel that runs the testcase in more reasonable time.
Also, 'time' reports real and user time roughly the same on all kernels,
so it's not that the older kernels are better at spreading out the load
between the two cores (either that or it doesn't account for stuff right).
I've included the config files, runtime output and vmstat output at
http://lixom.net/~olof/threadtest/. I see similar behaviour on PPC as
well as x86, so it's not architecture-specific.
Testcase below. Yes, I know, there's a bunch of stuff that could be done
differently and better, but it still doesn't motivate why there's a 3x
slowdown between kernel versions...
-Olof
#include
#include
#include
#ifdef __PPC__
static void atomic_inc(volatile long *a)
{
asm volatile ("1:\n\
lwarx %0,0,%1\n\
addic %0,%0,1\n\
stwcx. %0,0,%1\n\
bne- 1b" : "=&r" (result) : "r"(a));
}
#else
static void atomic_inc(volatile long *a)
{
asm volatile ("lock; incl %0" : "+m" (*a));
}
#endif
volatile long stopped;
int thread_func(int cpus)
{
int j;
for (j = 0; j < 1; j++)
;
atomic_inc(&stopped);
/* Busy-wait */
while (stopped < cpus)
j++;
}
long usecs(void)
{
struct timeval tv;
gettimeofday(&tv, NULL);
return tv.tv_sec * 100 + tv.tv_usec;
}
int main(int argc, char **argv)
{
pthread_t thread;
int i;
long t1, t2;
t1 = usecs();
for (i = 0; i < 500; i++) {
stopped = 0;
pthread_create(&thread, NULL, thread_func, 2);
thread_func(2);
pthread_join(thread, NULL);
}
t2 = usecs();
printf("time %ld ms\n", (t2-t1) / 1000);
return 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/
[PATCH] SUNPRC: Fix printk format warning
net/sunrpc/xprtrdma/svc_rdma_sendto.c:160: warning: format '%llx' expects type
'long long unsigned int', but argument 3 has type 'u64'
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
diff --git a/net/sunrpc/xprtrdma/svc_rdma_sendto.c
b/net/sunrpc/xprtrdma/svc_rdma_sendto.c
index 3e32194..4b913e7 100644
--- a/net/sunrpc/xprtrdma/svc_rdma_sendto.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_sendto.c
@@ -159,7 +159,7 @@ static int send_write(struct svcxprt_rdma *xprt, struct
svc_rqst *rqstp,
BUG_ON(sge_count >= 32);
dprintk("svcrdma: RDMA_WRITE rmr=%x, to=%llx, xdr_off=%d, "
"write_len=%d, xdr_sge=%p, sge_count=%d\n",
- rmr, to, xdr_off, write_len, xdr_sge, sge_count);
+ rmr, (unsigned long long) to, xdr_off, write_len, xdr_sge,
sge_count);
ctxt = svc_rdma_get_context(xprt);
ctxt->count = 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] [git pull] Input updates for 2.6.25-rc0
Andrew Morton wrote: On Fri, 8 Feb 2008 15:37:41 -0800 Randy Dunlap <[EMAIL PROTECTED]> wrote: I think someone already sent a patch to select the LEDS I did... and more. Who will merge it? (below) --- From: Randy Dunlap <[EMAIL PROTECTED]> Add I2C to config since the driver makes several i2c*() calls. Add to help text that the Intel I2C ICH (i801) driver is also needed for this kernel. Add LEDS_CLASS to config since the driver makes les_classdev_*() calls: ERROR: "led_classdev_register" [drivers/input/misc/apanel.ko] undefined! ERROR: "__led_classdev_unregister" [drivers/input/misc/apanel.ko] undefined! I have assumed that Dmitry will be handling this one. Yes, that would be it's normal route, but when builds are easily broken, it would be nice to have a fast-track mechanism... But then I (we?) still think that people should use Documentation/SubmitChecklist etc. also. :( -- ~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 1/2] prevent gpio chip drivers from unloading while used
On Friday 08 February 2008, Guennadi Liakhovetski wrote:
> As long as one or more GPIOs on a gpio chip are used its driver should not
> be unloaded.
The mechanism currently in place is to have gpiochip_remove() fail
if the platform's teardown() logic doesn't reject it. (It may be
practical to have the teardown code get rid of the users...) That
would be reflected as an "rmmod" failure.
Are you saying that doesn't work?
I'm not a huge fan of explicit manipulation of module refcounts,
though there can be a place for such things.
Supporting removal of a gpio_chip is my least favorite feature of
this framework. Especially for controller drivers which could
realistically manage per-GPIO IRQs ... since genirq doesn't seem to
like the notion of irq_chip removal. (The MCP23s08 and its I2C
sibling the MCP23008 have real IRQ control logic, but the pca953x
and pcf857x chips have a much less functional IRQ mechanism.)
> Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
>
> ---
>
> Note, that existing drivers do not have to be modified,
If they call gpiochip_remove(), they should be modified to ensure
they initialize this new "owner" field. That would be all of the
drivers currently in drivers/gpio (not just pca953x).
> for example those,
> that are always statically linked in the kernel, as long as the respective
> struct gpio_chip is nullified before calling gpiochip_add().
By "nullified", I presume you mean to suggest that the "owner" field
be initialized to NULL ... which will normally be the case, when the
gpio_chip is a static data structure or comes from kzalloc().
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index d8db2f8..dd535e1 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -177,6 +177,9 @@ int gpio_request(unsigned gpio, const char *label)
> if (desc->chip == NULL)
> goto done;
>
> + if (!try_module_get(desc->chip->owner))
> + goto done;
> +
> /* NOTE: gpio_request() can be called in early boot,
>* before IRQs are enabled.
>*/
> @@ -184,8 +187,10 @@ int gpio_request(unsigned gpio, const char *label)
> if (test_and_set_bit(FLAG_REQUESTED, &desc->flags) == 0) {
> desc_set_label(desc, label ? : "?");
> status = 0;
> - } else
> + } else {
> status = -EBUSY;
> + module_put(desc->chip->owner);
> + }
>
> done:
> if (status)
> @@ -209,9 +214,10 @@ void gpio_free(unsigned gpio)
> spin_lock_irqsave(&gpio_lock, flags);
>
> desc = &gpio_desc[gpio];
> - if (desc->chip && test_and_clear_bit(FLAG_REQUESTED, &desc->flags))
> + if (desc->chip && test_and_clear_bit(FLAG_REQUESTED, &desc->flags)) {
> desc_set_label(desc, NULL);
> - else
> + module_put(desc->chip->owner);
> + } else
> WARN_ON(extra_checks);
>
> spin_unlock_irqrestore(&gpio_lock, flags);
> diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
> index 806b86c..f6d389a 100644
> --- a/include/asm-generic/gpio.h
> +++ b/include/asm-generic/gpio.h
> @@ -3,6 +3,8 @@
>
> #ifdef CONFIG_HAVE_GPIO_LIB
>
> +#include
> +
> /* Platforms may implement their GPIO interface with library code,
> * at a small performance cost for non-inlined operations and some
> * extra memory (for code and for per-GPIO table entries).
> @@ -52,6 +54,7 @@ struct seq_file;
> */
> struct gpio_chip {
> char*label;
> + struct module *owner;
>
> int (*direction_input)(struct gpio_chip *chip,
> unsigned offset);
>
--
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: Integration of SCST in the mainstream Linux kernel
On Fri, 2008-02-08 at 17:42 +0300, Vladislav Bolkhovitin wrote: > Nicholas A. Bellinger wrote: > > On Thu, 2008-02-07 at 12:37 -0800, Luben Tuikov wrote: > > > >>Is there an open iSCSI Target implementation which does NOT > >>issue commands to sub-target devices via the SCSI mid-layer, but > >>bypasses it completely? > >> > >> Luben > >> > > > > > > Hi Luben, > > > > I am guessing you mean futher down the stack, which I don't know this to > > be the case. Going futher up the layers is the design of v2.9 LIO-SE. > > There is a diagram explaining the basic concepts from a 10,000 foot > > level. > > > > http://linux-iscsi.org/builds/user/nab/storage-engine-concept.pdf > > > > Note that only traditional iSCSI target is currently implemented in v2.9 > > LIO-SE codebase in the list of target mode fabrics on left side of the > > layout. The API between the protocol headers that does > > encoding/decoding target mode storage packets is probably the least > > mature area of the LIO stack (because it has always been iSCSI looking > > towards iSER :). I don't know who has the most mature API between the > > storage engine and target storage protocol for doing this between SCST > > and STGT, I am guessing SCST because of the difference in age of the > > projects. Could someone be so kind to fill me in on this..? > > SCST uses scsi_execute_async_fifo() function to submit commands to SCSI > devices in the pass-through mode. This function is slightly modified > version of scsi_execute_async(), which submits requests in FIFO order > instead of LIFO as scsi_execute_async() does (so with > scsi_execute_async() they are executed in the reverse order). > Scsi_execute_async_fifo() added as a separate patch to the kernel. The LIO-SE PSCSI Plugin also depends on scsi_execute_async() for builds on >= 2.6.18. Note in the core LIO storage engine code (would be iscsi_target_transport.c), there is no subsystem dependence logic. The LIO-SE API is what allows the SE plugins to remain simple and small: -rw-r--r-- 1 root root 35008 2008-02-02 03:25 iscsi_target_pscsi.c -rw-r--r-- 1 root root 7537 2008-02-02 17:27 iscsi_target_pscsi.h -rw-r--r-- 1 root root 18269 2008-02-04 02:23 iscsi_target_iblock.c -rw-r--r-- 1 root root 6834 2008-02-04 02:25 iscsi_target_iblock.h -rw-r--r-- 1 root root 30611 2008-02-02 03:25 iscsi_target_file.c -rw-r--r-- 1 root root 7833 2008-02-02 17:27 iscsi_target_file.h -rw-r--r-- 1 root root 35154 2008-02-02 04:01 iscsi_target_rd.c -rw-r--r-- 1 root root 9900 2008-02-02 17:27 iscsi_target_rd.h It also means that the core LIO-SE code does not have to change when the subsystem APIs change. This has been important in the past for the project, but for upstream code, probably would not make a huge difference. --nab -- 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 PATCH] sysdev_unregister() should call kobject_del()
On Fri, Feb 08, 2008 at 03:22:29PM -0800, Badari Pulavarty wrote: > > On Thu, 2008-02-07 at 20:55 -0800, Greg KH wrote: > > On Thu, Feb 07, 2008 at 05:25:46PM -0800, Badari Pulavarty wrote: > > > On Thu, 2008-02-07 at 16:38 -0800, Greg KH wrote: > > > > On Thu, Feb 07, 2008 at 03:56:58PM -0800, Badari Pulavarty wrote: > > > > > Hi Greg, > > > > > > > > > > While playing with hotplug memory remove on 2.6.24-mm1, I > > > > > noticed that /sysfs directory entries are not getting removed. > > > > > > > > > > sysdev_unregister() used to call kobject_unregister(). > > > > > But in 2.6.24-mm1, its only dropping the ref. It should > > > > > call kobject_del() to remove the object. Correct ? > > > > > > > > > > With this change, the directories are getting removed > > > > > correctly. Comments ? > > > > > > > > Ick, no, this shouldn't be needed, someone else must be holding a > > > > reference to the kobject device somewhere. See the kobject documenation > > > > for more info. > > > > > > > > I'll try to see where we grab 2 references... > > > > > > I will take a closer look then. I was taking easy way out :( > > > > Hm, I don't see anything obvious in the sys.c core. What code is > > controlling these objects that you are creating and removing from the > > system? > > > > I found the culprit. Its not in sys.c core :) Glad to hear it :) > remove_memory_block() takes a reference on kobject by calling > find_memory_block(). It then calls unregister_memory() to free up sysfs > entry. > It drops only one ref (which it got at register time). So it never gets > freed up. I am going to send out a separate patch for it. Ah, nice catch. 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] block layer: kmemcheck fixes
On Fri, Feb 08, 2008 at 02:56:09PM -0800, Arjan van de Ven wrote: > Nick Piggin wrote: > >>>Maybe cpus these days have so much store bandwith that doing > >>>things like the above is OK, but I doubt it :-) > >>on modern x86 cpus the memset may even be faster if the memory isn't in > >>cache; > >>the "explicit" method ends up doing Write Allocate on the cache lines > >>(so read them from memory) even though they then end up being written > >>entirely. > >>With memset the CPU is told that the entire range is set to a new value, > >>and > >>the WA can be avoided for the whole-cachelines in the range. > > > >Don't you have write combining store buffers? Or is it still speculatively > >issuing the reads even before the whole cacheline is combined? > > x86 memory order model doesn't allow that quite; and you need a "series" of > at least 64 bytes > without any other memory accesses in between even if it would > not happening in practice. OK, fair enough... then it will be a very nice test to see if it helps. I'm sure you could have an arch specific initialisation function if it makes a significant difference. -- 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/6] MMU Notifiers V6
On Fri, 8 Feb 2008 17:43:02 -0600 Robin Holt <[EMAIL PROTECTED]> wrote: > On Fri, Feb 08, 2008 at 03:41:24PM -0800, Christoph Lameter wrote: > > On Fri, 8 Feb 2008, Robin Holt wrote: > > > > > > > What about ib_umem_get()? > > > > Correct. > > > > You missed the turn of the conversation to how ib_umem_get() works. > > Currently it seems to pin the same way that the SLES10 XPmem works. > > Ah. I took Andrew's question as more of a probe about whether we had > worked with the IB folks to ensure this fits the ib_umem_get needs > as well. > You took it correctly, and I didn't understand the answer ;) -- 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] [git pull] Input updates for 2.6.25-rc0
On Fri, 8 Feb 2008 15:37:41 -0800 Randy Dunlap <[EMAIL PROTECTED]> wrote: > > I think someone already sent a patch to select the LEDS > > I did... and more. Who will merge it? (below) > > --- > From: Randy Dunlap <[EMAIL PROTECTED]> > > Add I2C to config since the driver makes several i2c*() calls. > > Add to help text that the Intel I2C ICH (i801) driver is also needed > for this kernel. > > Add LEDS_CLASS to config since the driver makes les_classdev_*() calls: > ERROR: "led_classdev_register" [drivers/input/misc/apanel.ko] undefined! > ERROR: "__led_classdev_unregister" [drivers/input/misc/apanel.ko] undefined! I have assumed that Dmitry will be handling this one. -- 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] pcmcia: fix i82092 printk format
On Fri, 8 Feb 2008 15:22:44 -0800 Randy Dunlap <[EMAIL PROTECTED]> wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Fix printk format warnings:
> linux-2.6.24-git19/drivers/pcmcia/i82092.c:650: warning: format '%lx' expects
> type 'long unsigned int', but argument 3 has type 'resource_size_t'
> linux-2.6.24-git19/drivers/pcmcia/i82092.c:650: warning: format '%lx' expects
> type 'long unsigned int', but argument 4 has type 'resource_size_t'
>
> Fix very long source line size.
> Fix spacing within the printk format string.
>
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
> ---
> drivers/pcmcia/i82092.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> --- linux-2.6.24-git19.orig/drivers/pcmcia/i82092.c
> +++ linux-2.6.24-git19/drivers/pcmcia/i82092.c
> @@ -647,7 +647,9 @@ static int i82092aa_set_mem_map(struct p
> if ( (mem->card_start > 0x3ff) || (region.start > region.end) ||
>(mem->speed > 1000) ) {
> leave("i82092aa_set_mem_map: invalid address / speed");
> - printk("invalid mem map for socket %i : %lx to %lx with a start
> of %x \n",sock,region.start, region.end, mem->card_start);
> + printk("invalid mem map for socket %i: %llx to %llx with a
> start of %x\n",
> + sock, (unsigned long long)region.start,
> + (unsigned long long)region.end, mem->card_start);
> return -EINVAL;
> }
>
I've apleady sent a similar patch to Greg
(drivers-pcmcia-i82092c-fix-up-after-pci_bus_region-changes.patch) but I
imagine he's swamped with -stable fun and games at present.
--
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: Integration of SCST in the mainstream Linux kernel
On Fri, 2008-02-08 at 17:36 +0300, Vladislav Bolkhovitin wrote: > Nicholas A. Bellinger wrote: > - It has been discussed which iSCSI target implementation should be in > the mainstream Linux kernel. There is no agreement on this subject > yet. The short-term options are as follows: > 1) Do not integrate any new iSCSI target implementation in the > mainstream Linux kernel. > 2) Add one of the existing in-kernel iSCSI target implementations to > the kernel, e.g. SCST or PyX/LIO. > 3) Create a new in-kernel iSCSI target implementation that combines > the advantages of the existing iSCSI kernel target implementations > (iETD, STGT, SCST and PyX/LIO). > > As an iSCSI user, I prefer option (3). The big question is whether the > various storage target authors agree with this ? > >>> > >>>I tend to agree with some important notes: > >>> > >>>1. IET should be excluded from this list, iSCSI-SCST is IET updated for > >>>SCST > >>>framework with a lot of bugfixes and improvements. > >>> > >>>2. I think, everybody will agree that Linux iSCSI target should work over > >>>some standard SCSI target framework. Hence the choice gets narrower: SCST > >>>vs > >>>STGT. I don't think there's a way for a dedicated iSCSI target (i.e. > >>>PyX/LIO) > >>>in the mainline, because of a lot of code duplication. Nicholas could > >>>decide > >>>to move to either existing framework (although, frankly, I don't think > >>>there's a possibility for in-kernel iSCSI target and user space SCSI > >>>target > >>>framework) and if he decide to go with SCST, I'll be glad to offer my help > >>>and support and wouldn't care if LIO-SCST eventually replaced iSCSI-SCST. > >>>The > >>>better one should win. > >> > >>why should linux as an iSCSI target be limited to passthrough to a SCSI > >>device. > > > > > > > > I don't think anyone is saying it should be. It makes sense that the > > more mature SCSI engines that have working code will be providing alot > > of the foundation as we talk about options.. > > > >>From comparing the designs of SCST and LIO-SE, we know that SCST has > > supports very SCSI specific target mode hardware, including software > > target mode forks of other kernel code. This code for the target mode > > pSCSI, FC and SAS control paths (more for the state machines, that CDB > > emulation) that will most likely never need to be emulated on non SCSI > > target engine. > > ...but required for SCSI. So, it must be, anyway. > > > SCST has support for the most SCSI fabric protocols of > > the group (although it is lacking iSER) while the LIO-SE only supports > > traditional iSCSI using Linux/IP (this means TCP, SCTP and IPv6). The > > design of LIO-SE was to make every iSCSI initiator that sends SCSI CDBs > > and data to talk to every potential device in the Linux storage stack on > > the largest amount of hardware architectures possible. > > > > Most of the iSCSI Initiators I know (including non Linux) do not rely on > > heavy SCSI task management, and I think this would be a lower priority > > item to get real SCSI specific recovery in the traditional iSCSI target > > for users. Espically things like SCSI target mode queue locking > > (affectionally called Auto Contingent Allegiance) make no sense for > > traditional iSCSI or iSER, because CmdSN rules are doing this for us. > > Sorry, it isn't correct. ACA provides possibility to lock commands queue > in case of CHECK CONDITION, so allows to keep commands execution order > in case of errors. CmdSN keeps commands execution order only in case of > success, in case of error the next queued command will be executed > immediately after the failed one, although application might require to > have all subsequent after the failed one commands aborted. Think about > journaled file systems, for instance. Also ACA allows to retry the > failed command and then resume the queue. > Fair enough. The point I was making is that I have never actually seen an iSCSI Initiator use ACA functionality (I don't believe that the Linux SCSI Ml implements this), or actually generate a CLEAR_ACA task management request. --nab > Vlad > -- 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] [git pull] Input updates for 2.6.25-rc0
On 09/02/2008, Randy Dunlap <[EMAIL PROTECTED]> wrote: ... > > On Sat, 9 Feb 2008 00:25:36 +0100 > > Ingo Molnar <[EMAIL PROTECTED]> wrote: > > ... > > I think someone already sent a patch to select the LEDS > > I did... and more. Who will merge it? (below) > > --- > From: Randy Dunlap <[EMAIL PROTECTED]> > > Add I2C to config since the driver makes several i2c*() calls. > > Add to help text that the Intel I2C ICH (i801) driver is also needed > for this kernel. > > Add LEDS_CLASS to config since the driver makes les_classdev_*() calls: > ERROR: "led_classdev_register" [drivers/input/misc/apanel.ko] undefined! > ERROR: "__led_classdev_unregister" [drivers/input/misc/apanel.ko] undefined! > > Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> I guess I could stick it in the Trivial tree and push it during the 2.6.26 merge window if it doesn't get merged elsewhere before that. It looks reasonably trivial. At least that way it doesn't get lost :) -- 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] Define a NO_GPIO macro to compare against and to use as an invalid GPIO
On Thursday 31 January 2008, Guennadi Liakhovetski wrote: > As discussed on i2c mailing list with David Brownell, and number > outside of the 0...MAX_INT range is invalid as a GPIO number. > Define a macro, similar to NO_IRQ, to be used as a deliberate > invalid GPIO, rather than defining a is_valid_gpio() macro. Actually I thought that what you needed was an is_valid_gpio(); your motivation was that you needed a predicate. The problem I have with a #define for a single such invalid GPIO number is that people will inevitably start to assume it's the only such number. In particular "if (gpio == NO_GPIO) ..." is by definition incorrect. So I'd really rather see a predicate like is_valid_gpio(). If you want to designate one value for use as an initializer, then I'd rather see a simple #define NO_GPIO (-EINVAL) without any option for arch-specific overrides ... along with a comment that this is only *one* of the numerous values which will fail is_valid_gpio(). - Dave > > Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]> > > --- > > As gpiolib doesn't seem to have an own mailing list, sending it directly > to LKML. > > include/asm-generic/gpio.h |4 > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h > index f29a502..806b86c 100644 > --- a/include/asm-generic/gpio.h > +++ b/include/asm-generic/gpio.h > @@ -16,6 +16,10 @@ > #define ARCH_NR_GPIOS256 > #endif > > +#ifndef NO_GPIO > +#define NO_GPIO ((unsigned int)-1) > +#endif > + > struct seq_file; > > /** > -- > 1.5.3.4 > -- 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/6] MMU Notifiers V6
On Fri, Feb 08, 2008 at 03:41:24PM -0800, Christoph Lameter wrote: > On Fri, 8 Feb 2008, Robin Holt wrote: > > > > > What about ib_umem_get()? > > Correct. > > You missed the turn of the conversation to how ib_umem_get() works. > Currently it seems to pin the same way that the SLES10 XPmem works. Ah. I took Andrew's question as more of a probe about whether we had worked with the IB folks to ensure this fits the ib_umem_get needs as well. Thanks, Robin -- 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 BUG at kernel/power/snapshot.c:464!
On Friday, 8 of February 2008, Jeff Mahoney wrote:
> Rafael J. Wysocki wrote:
> > On Friday, 8 of February 2008, Pavel Machek wrote:
> >> Hi!
> >>
> >>> Our old friend kernel BUG at kernel/power/snapshot.c:464! is back, this
> >>> time from mainline. I can't reproduce with 2.6.24-final, but I can with
> >>> a git snapshot from a few days ago. I'm doing a git bisect run now, but
> >>> it's rather time consuming, so I thought I'd pass this on in the interim.
> >>>
> >>> I can reproduce this just by doing "cat /dev/snapshot".
> >>>
> >>> Working output looks like:
> >>> swsusp: Marking nosave pages: 0009f000 - 0010
> >>> swsusp: Marking nosave pages: f7ff - 0001
> >>> swsusp: Basic memory bitmaps created
> >>> swsusp: Basic memory bitmaps freed
> >> [EMAIL PROTECTED]:~# cat /dev/snapshot
> >> cat: /dev/snapshot: No data available
> >> [EMAIL PROTECTED]:~#
> >>
> >> ...on less than two days old 2.6.25-rc0-git. Rafael, do you have any
> >> ideas what may break?
> >
> > No idea and I can't reproduce it.
> >
> > Plus the trace looks bogus, as there are no "swsusp: ..." messages in the
> > mainline any more.
>
> The git version from two days ago did. :)
>
> I just git pulled and built and got the same BUG.
>
> Here are the nosave registration messages:
> PM: Registered nosave memory: 0009f000 - 000a
> PM: Registered nosave memory: 000a - 000e
> PM: Registered nosave memory: 000e - 0010
> PM: Registered nosave memory: f7ff - f7fff000
> PM: Registered nosave memory: f7fff000 - f800
> PM: Registered nosave memory: f800 - ff78
> PM: Registered nosave memory: ff78 - 0001
>
> And the old swsusp messages match those ranges, just coalesced into two
> ranges.
>
> Reassembling the zones from /proc/zoneinfo yields:
> Node 0, zone DMA start_pfn: 0, spanned 4096
> (0x0-0x1000)
> Node 0, zone DMA32start_pfn: 4096, spanned 1011696
> (0x1000-0xf7ff0)
> Node 1, zone Normal start_pfn: 1048576, spanned 1048576
> (0x10-20)
Ah, NUMA.
> The pfn it's searching for is 0xf7ff0, which will end up hitting this in
> memory_bm_find_bit:
> while (pfn < zone_bm->start_pfn || pfn >= zone_bm->end_pfn) {
> zone_bm = zone_bm->next;
> BUG_ON(!zone_bm)
> }
>
> Should that be pfn > zone_bm->end_pfn, or is end_pfn non-inclusive?
It used to be non-inclusive and I think it is, as 0xf7ff0 seems to be the start
of a reserved region.
Well, the assumption is that if the PFN doesn't belong to any zone, then
pfn_valid() in mark_nosave_pages() should filter it out. Apparently, it has
stopped doing this at one point.
Andrew, have we had any changes to the way in which pfn_valid() works recently?
Rafael
> Here's the updated oops, which doesn't look any different:
>
> [ cut here ]
> kernel BUG at kernel/power/snapshot.c:464!
> invalid opcode: [1] SMP
> CPU 1
> Modules linked in: ocfs2_dlmfs ocfs2_dlm ocfs2_nodemanager configfs
> autofs4 sunrpc iptable_filter ip_tables ip6table_filter ip6_tables
> x_tables ipv6 af_packet loop dm_mod sbp2 ohci1394 ieee1394 k8temp
> amd_rng tg3 i2c_amd8111 hwmon i2c_amd756 floppy shpchp rtc_cmos rtc_core
> rtc_lib sr_mod i2c_core cdrom parport_pc parport pci_hotplug serio_raw
> button sg ohci_hcd sd_mod usbcore edd ext3 mbcache jbd fan sata_sil
> pata_amd libata scsi_mod thermal processor
> Pid: 3165, comm: cat Not tainted 2.6.24-vanilla #20
> RIP: 0010:[] []
> memory_bm_find_bit+0x20/0x78
> RSP: 0018:8100379bfd78 EFLAGS: 00010246
> RAX: RBX: 81003480 RCX: 8100379bfd8c
> RDX: 8100379bfd80 RSI: 000f7ff0 RDI: 81003793e5c0
> RBP: 000f7ff0 R08: 8100379bfd80 R09:
> R10: 0028 R11: 0001 R12: 81003793e5c0
> R13: 81003783f118 R14: 81003783f118 R15: 8100f603e380
> FS: 7f753cff06f0() GS:8100f767ec40() knlGS:
> CS: 0010 DS: ES: CR0: 8005003b
> CR2: 7f753cb47c30 CR3: f61fc000 CR4: 06e0
> DR0: DR1: DR2:
> DR3: DR6: 0ff0 DR7: 0400
> Process cat (pid: 3165, threadinfo 8100379be000, task 8100378f0640)
> Stack: 80254cb5 810037837018 003ff603e380 8025641f
> 8100f603e380 81003783f118 80257016
> 8100f777fe40 8040dbca 80451aa0
> Call Trace:
> [] ? memory_bm_set_bit+0x11/0x20
> [] ? create_basic_memory_bitmaps+0x134/0x139
> [] ? snapshot_open+0x58/0x13f
> [] ? mutex_lock+0xd/0x1e
> [] ? misc_open+0x13e/0x1b2
> [] ? chrdev_open+0x150/0x174
> [] ? open_namei+0x2d0/0x653
> [] ? chrdev_open+0x0/0x174
> [] ? __dentry_open+0xeb/0x1b
Re: [patch 0/6] MMU Notifiers V6
On Fri, 8 Feb 2008, Robin Holt wrote: > > > What about ib_umem_get()? > > > > Ok. It pins using an elevated refcount. Same as XPmem right now. With that > > we effectively pin a page (page migration will fail) but we will > > continually be reclaiming the page and may repeatedly try to move it. We > > have issues with XPmem causing too many pages to be pinned and thus the > > OOM getting into weird behavior modes (OOM or stop lru scanning due to > > all_reclaimable set). > > > > An elevated refcount will also not be noticed by any of the schemes under > > consideration to improve LRU scanning performance. > > Christoph, I am not sure what you are saying here. With v4 and later, > I thought we were able to use the rmap invalidation to remove the ref > count that XPMEM was holding and therefore be able to swapout. Did I miss > something? I agree the existing XPMEM does pin. I hope we are not saying > the XPMEM based upon these patches will not be able to swap/migrate. Correct. You missed the turn of the conversation to how ib_umem_get() works. Currently it seems to pin the same way that the SLES10 XPmem works. -- 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: mark USB drivers as being GPL only
Hi David, > > Anyway you are still under the impression that a Linux kernel module can > > be original work in the end. We keep telling you that could be a wrong > > assumption which is based on the view of many of the kernel developers > > and of most of the lawyers that looked at this specific topic. > > > Yes, I am of that view. I accept that I could be wrong, but that also > means that I could be right. We agree, so far. The important point is > that I could be right. What will be done when somebody brings forth such > an work? Will the restriction in EXPORT_SYMBOL_GPL be removed, or will > the driver be unfairly restricted from using those other modules? You > did agree I could be right, so positing such a driver, what happens? (I > predict nothing; the driver is unfairly restricted.) whatever you feel you get away with, but hey I am not a lawyer and my reading is that any kernel module is derivative work and thus has to be placed under GPL. Feel free to disagree with me. If you think you can convince me, than you are under the wrong impression. Since even if (and this is a big if) I am wrong, my action won't lead to a copyright violation. Yours however would if you are wrong. So pick your battle. > USB drivers must NOT be restricted to GPL-licence only; that would > damage Linux. Not writing and publishing GPL drivers damages Linux. Nothing else. > > And while you are talking to a lawyer. Ask him/her if it is okay to > > create a binary only application that uses a GPL library. Tell him/her > > that it is original work. > > Where does this come from? It's right out of left field. Since I've > never suggested such a thing, could you please do me the courtesy of > retracting the suggestion that I have? Lets phrase this in better words as Valdis pointed out: You can't distribute an application (binary or source form) under anything else than GPL if it uses a GPL library. It makes no difference if you distribute the GPL library with it or not. But hey (again), feel free to disagree with me here. Regards Marcel -- 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 3/4] oprofile: change cpu_buffer from array to per_cpu variable
Change cpu_buffer from array to per_cpu variable in
oprofile functions.
Based on linux-2.6.git + x86.git
Cc: Philippe Elie <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
drivers/oprofile/buffer_sync.c|2 +-
drivers/oprofile/cpu_buffer.c | 16
drivers/oprofile/cpu_buffer.h |3 ++-
drivers/oprofile/oprofile_stats.c |4 ++--
4 files changed, 13 insertions(+), 12 deletions(-)
--- a/drivers/oprofile/buffer_sync.c
+++ b/drivers/oprofile/buffer_sync.c
@@ -494,7 +494,7 @@ typedef enum {
*/
void sync_buffer(int cpu)
{
- struct oprofile_cpu_buffer * cpu_buf = &cpu_buffer[cpu];
+ struct oprofile_cpu_buffer * cpu_buf = &per_cpu(cpu_buffer, cpu);
struct mm_struct *mm = NULL;
struct task_struct * new;
unsigned long cookie = 0;
--- a/drivers/oprofile/cpu_buffer.c
+++ b/drivers/oprofile/cpu_buffer.c
@@ -27,7 +27,7 @@
#include "buffer_sync.h"
#include "oprof.h"
-struct oprofile_cpu_buffer cpu_buffer[NR_CPUS] __cacheline_aligned;
+DEFINE_PER_CPU_SHARED_ALIGNED(struct oprofile_cpu_buffer, cpu_buffer);
static void wq_sync_buffer(struct work_struct *work);
@@ -39,7 +39,7 @@ void free_cpu_buffers(void)
int i;
for_each_online_cpu(i)
- vfree(cpu_buffer[i].buffer);
+ vfree(per_cpu(cpu_buffer, i).buffer);
}
int alloc_cpu_buffers(void)
@@ -49,7 +49,7 @@ int alloc_cpu_buffers(void)
unsigned long buffer_size = fs_cpu_buffer_size;
for_each_online_cpu(i) {
- struct oprofile_cpu_buffer * b = &cpu_buffer[i];
+ struct oprofile_cpu_buffer * b = &per_cpu(cpu_buffer, i);
b->buffer = vmalloc_node(sizeof(struct op_sample) * buffer_size,
cpu_to_node(i));
@@ -83,7 +83,7 @@ void start_cpu_work(void)
work_enabled = 1;
for_each_online_cpu(i) {
- struct oprofile_cpu_buffer * b = &cpu_buffer[i];
+ struct oprofile_cpu_buffer * b = &per_cpu(cpu_buffer, i);
/*
* Spread the work by 1 jiffy per cpu so they dont all
@@ -100,7 +100,7 @@ void end_cpu_work(void)
work_enabled = 0;
for_each_online_cpu(i) {
- struct oprofile_cpu_buffer * b = &cpu_buffer[i];
+ struct oprofile_cpu_buffer * b = &per_cpu(cpu_buffer, i);
cancel_delayed_work(&b->work);
}
@@ -227,7 +227,7 @@ static void oprofile_end_trace(struct op
void oprofile_add_ext_sample(unsigned long pc, struct pt_regs * const regs,
unsigned long event, int is_kernel)
{
- struct oprofile_cpu_buffer * cpu_buf = &cpu_buffer[smp_processor_id()];
+ struct oprofile_cpu_buffer * cpu_buf = &__get_cpu_var(cpu_buffer);
if (!backtrace_depth) {
log_sample(cpu_buf, pc, is_kernel, event);
@@ -254,13 +254,13 @@ void oprofile_add_sample(struct pt_regs
void oprofile_add_pc(unsigned long pc, int is_kernel, unsigned long event)
{
- struct oprofile_cpu_buffer * cpu_buf = &cpu_buffer[smp_processor_id()];
+ struct oprofile_cpu_buffer * cpu_buf = &__get_cpu_var(cpu_buffer);
log_sample(cpu_buf, pc, is_kernel, event);
}
void oprofile_add_trace(unsigned long pc)
{
- struct oprofile_cpu_buffer * cpu_buf = &cpu_buffer[smp_processor_id()];
+ struct oprofile_cpu_buffer * cpu_buf = &__get_cpu_var(cpu_buffer);
if (!cpu_buf->tracing)
return;
--- a/drivers/oprofile/cpu_buffer.h
+++ b/drivers/oprofile/cpu_buffer.h
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
struct task_struct;
@@ -47,7 +48,7 @@ struct oprofile_cpu_buffer {
struct delayed_work work;
} cacheline_aligned;
-extern struct oprofile_cpu_buffer cpu_buffer[];
+DECLARE_PER_CPU(struct oprofile_cpu_buffer, cpu_buffer);
void cpu_buffer_reset(struct oprofile_cpu_buffer * cpu_buf);
--- a/drivers/oprofile/oprofile_stats.c
+++ b/drivers/oprofile/oprofile_stats.c
@@ -23,7 +23,7 @@ void oprofile_reset_stats(void)
int i;
for_each_possible_cpu(i) {
- cpu_buf = &cpu_buffer[i];
+ cpu_buf = &per_cpu(cpu_buffer, i);
cpu_buf->sample_received = 0;
cpu_buf->sample_lost_overflow = 0;
cpu_buf->backtrace_aborted = 0;
@@ -49,7 +49,7 @@ void oprofile_create_stats_files(struct
return;
for_each_possible_cpu(i) {
- cpu_buf = &cpu_buffer[i];
+ cpu_buf = &per_cpu(cpu_buffer, i);
snprintf(buf, 10, "cpu%d", i);
cpudir = oprofilefs_mkdir(sb, dir, buf);
--
--
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] [git pull] Input updates for 2.6.25-rc0
On Fri, 8 Feb 2008 15:28:12 -0800 Stephen Hemminger wrote: > On Sat, 9 Feb 2008 00:25:36 +0100 > Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > > * Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > > > > > Stephen Hemminger (2): > > > Input: add driver for Fujitsu application buttons > > > > this change broke the build on x86 in randconfig testing: > > > > drivers/built-in.o: In function `apanel_detach_client': > > apanel.c:(.text+0x15c120): undefined reference to > > `__led_classdev_unregister' > > drivers/built-in.o: In function `apanel_probe': > > apanel.c:(.text+0x15c30f): undefined reference to `led_classdev_register' > > > > .config attached. > > > > the Kconfig dependencies seem incomplete: > > > > > +config INPUT_APANEL > > > + tristate "Fujitsu Lifebook Application Panel buttons" > > > + depends on X86 > > > + select I2C_I801 > > > + select INPUT_POLLDEV > > > + select CHECK_SIGNATURE > > > + help > > > > it doesnt list LEDS. > > > > Ingo > > I think someone already sent a patch to select the LEDS I did... and more. Who will merge it? (below) --- From: Randy Dunlap <[EMAIL PROTECTED]> Add I2C to config since the driver makes several i2c*() calls. Add to help text that the Intel I2C ICH (i801) driver is also needed for this kernel. Add LEDS_CLASS to config since the driver makes les_classdev_*() calls: ERROR: "led_classdev_register" [drivers/input/misc/apanel.ko] undefined! ERROR: "__led_classdev_unregister" [drivers/input/misc/apanel.ko] undefined! Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- drivers/input/misc/Kconfig |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- linux-2.6.24-mm1.orig/drivers/input/misc/Kconfig +++ linux-2.6.24-mm1/drivers/input/misc/Kconfig @@ -42,14 +42,14 @@ config INPUT_M68K_BEEP config INPUT_APANEL tristate "Fujitsu Lifebook Application Panel buttons" - depends on X86 - select I2C_I801 + depends on X86 && I2C && LEDS_CLASS select INPUT_POLLDEV select CHECK_SIGNATURE help Say Y here for support of the Application Panel buttons, used on Fujitsu Lifebook. These are attached to the mainboard through -an SMBus interface managed by the I2C Intel ICH (i801) driver. +an SMBus interface managed by the I2C Intel ICH (i801) driver, +which you should also build for this kernel. To compile this driver as a module, choose M here: the module will be called apanel. -- 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 4/4] x86: minor cleanup of comments in processor.h
Removal of trivial comments in processor.h
Based on linux-2.6.git + x86.git
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
include/asm-x86/processor.h |4
1 file changed, 4 deletions(-)
--- a/include/asm-x86/processor.h
+++ b/include/asm-x86/processor.h
@@ -302,10 +302,6 @@ union i387_union {
};
#ifdef CONFIG_X86_32
-/*
- * the following now lives in the per cpu area:
- * extern int cpu_llc_id[NR_CPUS];
- */
DECLARE_PER_CPU(u8, cpu_llc_id);
#else
DECLARE_PER_CPU(struct orig_ist, orig_ist);
--
--
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/4] cpufreq: change cpu freq tables to per_cpu variables
Change cpu frequency tables from arrays to per_cpu variables.
Based on linux-2.6.git + x86.git
Cc: Dave Jones <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
drivers/cpufreq/cpufreq_userspace.c | 71 +++-
1 file changed, 39 insertions(+), 32 deletions(-)
--- a/drivers/cpufreq/cpufreq_userspace.c
+++ b/drivers/cpufreq/cpufreq_userspace.c
@@ -30,11 +30,11 @@
/**
* A few values needed by the userspace governor
*/
-static unsigned intcpu_max_freq[NR_CPUS];
-static unsigned intcpu_min_freq[NR_CPUS];
-static unsigned intcpu_cur_freq[NR_CPUS]; /* current CPU freq */
-static unsigned intcpu_set_freq[NR_CPUS]; /* CPU freq desired by userspace
*/
-static unsigned intcpu_is_managed[NR_CPUS];
+DEFINE_PER_CPU(int, cpu_max_freq);
+DEFINE_PER_CPU(int, cpu_min_freq);
+DEFINE_PER_CPU(int, cpu_cur_freq); /* current CPU freq */
+DEFINE_PER_CPU(int, cpu_set_freq); /* CPU freq desired by userspace */
+DEFINE_PER_CPU(int, cpu_is_managed);
static DEFINE_MUTEX(userspace_mutex);
static int cpus_using_userspace_governor;
@@ -48,12 +48,12 @@ userspace_cpufreq_notifier(struct notifi
{
struct cpufreq_freqs *freq = data;
- if (!cpu_is_managed[freq->cpu])
+ if (!per_cpu(cpu_is_managed, freq->cpu))
return 0;
dprintk("saving cpu_cur_freq of cpu %u to be %u kHz\n",
freq->cpu, freq->new);
- cpu_cur_freq[freq->cpu] = freq->new;
+ per_cpu(cpu_cur_freq, freq->cpu) = freq->new;
return 0;
}
@@ -77,15 +77,15 @@ static int cpufreq_set(unsigned int freq
dprintk("cpufreq_set for cpu %u, freq %u kHz\n", policy->cpu, freq);
mutex_lock(&userspace_mutex);
- if (!cpu_is_managed[policy->cpu])
+ if (!per_cpu(cpu_is_managed, policy->cpu))
goto err;
- cpu_set_freq[policy->cpu] = freq;
+ per_cpu(cpu_set_freq, policy->cpu) = freq;
- if (freq < cpu_min_freq[policy->cpu])
- freq = cpu_min_freq[policy->cpu];
- if (freq > cpu_max_freq[policy->cpu])
- freq = cpu_max_freq[policy->cpu];
+ if (freq < per_cpu(cpu_min_freq, policy->cpu))
+ freq = per_cpu(cpu_min_freq, policy->cpu);
+ if (freq > per_cpu(cpu_max_freq, policy->cpu))
+ freq = per_cpu(cpu_max_freq, policy->cpu);
/*
* We're safe from concurrent calls to ->target() here
@@ -105,7 +105,7 @@ static int cpufreq_set(unsigned int freq
/** sysfs interface /
static ssize_t show_speed (struct cpufreq_policy *policy, char *buf)
{
- return sprintf (buf, "%u\n", cpu_cur_freq[policy->cpu]);
+ return sprintf (buf, "%u\n", per_cpu(cpu_cur_freq, policy->cpu));
}
static ssize_t
@@ -154,12 +154,16 @@ static int cpufreq_governor_userspace(st
}
cpus_using_userspace_governor++;
- cpu_is_managed[cpu] = 1;
- cpu_min_freq[cpu] = policy->min;
- cpu_max_freq[cpu] = policy->max;
- cpu_cur_freq[cpu] = policy->cur;
- cpu_set_freq[cpu] = policy->cur;
- dprintk("managing cpu %u started (%u - %u kHz, currently %u
kHz)\n", cpu, cpu_min_freq[cpu], cpu_max_freq[cpu], cpu_cur_freq[cpu]);
+ per_cpu(cpu_is_managed, cpu) = 1;
+ per_cpu(cpu_min_freq, cpu) = policy->min;
+ per_cpu(cpu_max_freq, cpu) = policy->max;
+ per_cpu(cpu_cur_freq, cpu) = policy->cur;
+ per_cpu(cpu_set_freq, cpu) = policy->cur;
+ dprintk("managing cpu %u started "
+ "(%u - %u kHz, currently %u kHz)\n", cpu,
+ per_cpu(cpu_min_freq, cpu),
+ per_cpu(cpu_max_freq, cpu),
+ per_cpu(cpu_cur_freq, cpu));
start_out:
mutex_unlock(&userspace_mutex);
break;
@@ -172,11 +176,12 @@ start_out:
CPUFREQ_TRANSITION_NOTIFIER);
}
- cpu_is_managed[cpu] = 0;
- cpu_min_freq[cpu] = 0;
- cpu_max_freq[cpu] = 0;
- cpu_set_freq[cpu] = 0;
- sysfs_remove_file (&policy->kobj,
&freq_attr_scaling_setspeed.attr);
+ per_cpu(cpu_is_managed, cpu) = 0;
+ per_cpu(cpu_min_freq, cpu) = 0;
+ per_cpu(cpu_max_freq, cpu) = 0;
+ per_cpu(cpu_set_freq, cpu) = 0;
+ sysfs_remove_file (&policy->kobj,
+ &freq_attr_scaling_setspeed.attr);
dprintk("managing cpu %u stopped\n", cpu);
mutex_unlock(&userspace_mutex);
break;
@@ -185,22 +190,24 @@ start_out:
dprintk("limit event for cpu %u: %u - %u kHz,"
"currently %u kHz, last set to %u kHz\
[PATCH 0/4] NR_CPUS: non-x86 arch specific reduction of NR_CPUS usage
Here's another round of removing static allocations of arrays using NR_CPUS to size the length. The change is to use PER_CPU variables in place of the static tables. Based on linux-2.6.git + x86.git Cc: Dave Jones <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Cc: Len Brown <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Cc: Philippe Elie <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Signed-off-by: Mike Travis <[EMAIL PROTECTED]> --- (1 - if modules enabled, does not complete boot even without this patch) x86_64 configs built and booted: ingo-stress-test(1) defconfi nonuma nosmp bigsmp (NR_CPUS=1024, 1024 possible, 8 real) Other configs built: arm-default i386-default i386-single i386-smp ppc-pmac32 ppc-smp sparc64-default sparc64-smp x86_64-8psmp x86_64-debug x86_64-default x86_64-numa x86_64-single x86_64-allmodconfig x86_64-allyesconfig x86_64-maxsmp (NR_CPUS=4096 MAXNODES=512) Configs not built due to prior errors: ia64-sn2 ia64-default ia64-nosmp ia64-zx1 s390-default sparc-default Memory effects using x86_64-maxsmp Removes 1MB from permanant data adding 440 bytes to percpu area. 4k-cpus-before 4k-cpus-after 3463036 .bss -98304 -2% 6067456 .data.cacheline_alig -1048576 -17% 48712 .data.percpu +440 +0% 14275505 .text +336 +0% 14275505 Text +336 +0% 8521495 Data -336 +0% 3463036 Bss -98304 -2% 10974520 OtherData -1048576 -9% 48712 PerCpu +440 +0% 39275796 Total -1146104 -2% -- -- 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/4] acpi: change cpufreq tables to per_cpu variables
Change cpufreq tables from arrays to per_cpu variables in
drivers/acpi/processor_thermal.c
Based on linux-2.6.git + x86.git
Cc: Len Brown <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
drivers/acpi/processor_thermal.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
--- a/drivers/acpi/processor_thermal.c
+++ b/drivers/acpi/processor_thermal.c
@@ -93,7 +93,7 @@ static int acpi_processor_apply_limit(st
* _any_ cpufreq driver and not only the acpi-cpufreq driver.
*/
-static unsigned int cpufreq_thermal_reduction_pctg[NR_CPUS];
+static DEFINE_PER_CPU(unsigned int, cpufreq_thermal_reduction_pctg);
static unsigned int acpi_thermal_cpufreq_is_init = 0;
static int cpu_has_cpufreq(unsigned int cpu)
@@ -109,8 +109,8 @@ static int acpi_thermal_cpufreq_increase
if (!cpu_has_cpufreq(cpu))
return -ENODEV;
- if (cpufreq_thermal_reduction_pctg[cpu] < 60) {
- cpufreq_thermal_reduction_pctg[cpu] += 20;
+ if (per_cpu(cpufreq_thermal_reduction_pctg, cpu) < 60) {
+ per_cpu(cpufreq_thermal_reduction_pctg, cpu) += 20;
cpufreq_update_policy(cpu);
return 0;
}
@@ -123,13 +123,13 @@ static int acpi_thermal_cpufreq_decrease
if (!cpu_has_cpufreq(cpu))
return -ENODEV;
- if (cpufreq_thermal_reduction_pctg[cpu] > 20)
- cpufreq_thermal_reduction_pctg[cpu] -= 20;
+ if (per_cpu(cpufreq_thermal_reduction_pctg, cpu) > 20)
+ per_cpu(cpufreq_thermal_reduction_pctg, cpu) -= 20;
else
- cpufreq_thermal_reduction_pctg[cpu] = 0;
+ per_cpu(cpufreq_thermal_reduction_pctg, cpu) = 0;
cpufreq_update_policy(cpu);
/* We reached max freq again and can leave passive mode */
- return !cpufreq_thermal_reduction_pctg[cpu];
+ return !per_cpu(cpufreq_thermal_reduction_pctg, cpu);
}
static int acpi_thermal_cpufreq_notifier(struct notifier_block *nb,
@@ -143,7 +143,7 @@ static int acpi_thermal_cpufreq_notifier
max_freq =
(policy->cpuinfo.max_freq *
-(100 - cpufreq_thermal_reduction_pctg[policy->cpu])) / 100;
+(100 - per_cpu(cpufreq_thermal_reduction_pctg, policy->cpu))) /
100;
cpufreq_verify_within_limits(policy, 0, max_freq);
@@ -159,8 +159,9 @@ void acpi_thermal_cpufreq_init(void)
{
int i;
- for (i = 0; i < NR_CPUS; i++)
- cpufreq_thermal_reduction_pctg[i] = 0;
+ for (i = 0; i < nr_cpu_ids; i++)
+ if (cpu_present(i))
+ per_cpu(cpufreq_thermal_reduction_pctg, i) = 0;
i = cpufreq_register_notifier(&acpi_thermal_cpufreq_notifier_block,
CPUFREQ_POLICY_NOTIFIER);
--
--
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 tree urls
On Fri, 8 Feb 2008, Jan Engelhardt wrote: > > On Feb 8 2008 22:34, ael wrote: > > > >Sure, I looked there in some depth. But some/most are special purpose or > > 'locals'. One needs a map for the "main" repositories... > > Indeed, a page on kernelnewbies.org with the most important repositories > would be helpful. > > Well, to start: > > torvalds/linux-2.6.gitMainline > jgarzik/netdev-2.6.gitNetwork devices > davem/net-2.6.git Networking > x86/linux-2.6-x86.git x86 > mchehab/v4l-dvb.git V4L and DVB > bunk/trivial.git Spellos, typos and the obvious > > But it's not that easy. netdev-2.6.git for example regularly gets merged > into net-2.6.git, so you get a fairly recent netdev tree by choosing > either netdev or net. Also explaining the rotation of those two trees would be useful (I suppose some other subsystems too use somewhat similar rotation). I.e., net-2.6.26.git will eventually be opened and new development should be based on it (whenever such tree with a future version number is available), and that tree then becomes net-2.6.git once 2.6.25 is out. net-2.6.git is usually for fixes only unless merge window is currently open. These things come up quite often. -- i. -- 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/6] MMU Notifiers V6
On Fri, Feb 08, 2008 at 03:32:19PM -0800, Christoph Lameter wrote: > On Fri, 8 Feb 2008, Andrew Morton wrote: > > > What about ib_umem_get()? > > Ok. It pins using an elevated refcount. Same as XPmem right now. With that > we effectively pin a page (page migration will fail) but we will > continually be reclaiming the page and may repeatedly try to move it. We > have issues with XPmem causing too many pages to be pinned and thus the > OOM getting into weird behavior modes (OOM or stop lru scanning due to > all_reclaimable set). > > An elevated refcount will also not be noticed by any of the schemes under > consideration to improve LRU scanning performance. Christoph, I am not sure what you are saying here. With v4 and later, I thought we were able to use the rmap invalidation to remove the ref count that XPMEM was holding and therefore be able to swapout. Did I miss something? I agree the existing XPMEM does pin. I hope we are not saying the XPMEM based upon these patches will not be able to swap/migrate. Thanks, Robin -- 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] moduleparam: fix alpha, ia64 and ppc64 compile failures
On Fri, Feb 08, 2008 at 02:46:15PM -0800, Andrew Morton wrote: > I think it would have been better to define a new CONFIG_MODULEPARAM_CONST > for those three archictures, rather than muckying up the code like this. I'd prefer to keep this as is for now (sorta the uglier the better ;-) I really hope it's the short term solution as we need some feedback from gcc folks. We use named sections quite a lot, but gcc is sort of unfriendly with these, and this particular problem is not the main one. For instance, if someone dares to put a 'switch' statement into discarded section (__exit), the final link fails (on any arch!), because gcc generates a jump table in .rodata which references that discarded section... Ivan. -- 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/6] MMU Notifiers V6
On Fri, 8 Feb 2008, Andrew Morton wrote: > What about ib_umem_get()? Ok. It pins using an elevated refcount. Same as XPmem right now. With that we effectively pin a page (page migration will fail) but we will continually be reclaiming the page and may repeatedly try to move it. We have issues with XPmem causing too many pages to be pinned and thus the OOM getting into weird behavior modes (OOM or stop lru scanning due to all_reclaimable set). An elevated refcount will also not be noticed by any of the schemes under consideration to improve LRU scanning performance. -- 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/
Linux 2.6.24.1 - kernel does not boot; IRQ trouble?
Hi, I've just tried booting the 2.6.24.1 kernel, except without nmi_watchdog being enabled. It looks like there are IRQs still not being enabled. Cheers, Chris Linux version 2.6.24.1 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)) #1 SMP PREEMPT Fri Feb 8 22:41:10 GMT 2008 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1ffeb000 (usable) BIOS-e820: 1ffeb000 - 1ffef000 (ACPI data) BIOS-e820: 1ffef000 - 1000 (reserved) BIOS-e820: 1000 - 2000 (ACPI NVS) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: fff8 - 0001 (reserved) 511MB LOWMEM available. Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 131051 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -> 131051 DMI 2.3 present. ACPI: RSDP 000F7B40, 0014 (r0 ASUS ) ACPI: RSDT 1FFEB000, 0030 (r1 ASUS TUSL2-C 30303031 MSFT 31313031) ACPI: FACP 1FFEB100, 0074 (r1 ASUS TUSL2-C 30303031 MSFT 31313031) ACPI: DSDT 1FFEB180, 39FA (r1 ASUS TUSL2-C 1000 MSFT 10B) ACPI: FACS 1000, 0040 ACPI: BOOT 1FFEB040, 0028 (r1 ASUS TUSL2-C 30303031 MSFT 31313031) ACPI: APIC 1FFEB080, 005A (r1 ASUS TUSL2-C 30303031 MSFT 31313031) ACPI: PM-Timer IO Port: 0xe408 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 17 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level) Enabling APIC mode: Logical Cluster. Using 1 I/O APICs, target cpus f Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 3000 (gap: 2000:dec0) Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130028 Kernel command line: ro root=LABEL=/ video=matroxfb:vesa:0x11A console=ttyS0,115200n8 console=tty0 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c035f000 soft=c035b000 PID hash table entries: 2048 (order: 11, 8192 bytes) Detected 1005.085 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled console [ttyS0] enabled Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 513484k/524204k available (1577k kernel code, 10128k reserved, 607k data, 196k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfffb5000 - 0xf000 ( 296 kB) vmalloc : 0xe080 - 0xfffb3000 ( 503 MB) lowmem : 0xc000 - 0xdffeb000 ( 511 MB) .init : 0xc0327000 - 0xc0358000 ( 196 kB) .data : 0xc028a7ca - 0xc03227c4 ( 607 kB) .text : 0xc010 - 0xc028a7ca (1577 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 Calibrating delay using timer specific routine.. 2011.90 BogoMIPS (lpj=4023804) Mount-cache hash table entries: 512 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Compat vDSO mapped to e000. Checking 'hlt' instruction... OK. SMP alternatives: switching to UP code Freeing SMP alternatives: 9k freed ACPI: Core revision 20070126 CPU0: Intel Pentium III (Coppermine) stepping 06 Leaving ESR disabled. Total of 1 processors activated (2011.90 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 Brought up 1 CPUs net_namespace: 64 bytes NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xf0e30, last bus=3 PCI: Using configuration type 1 Setting up standard PCI resources ACPI: Interpreter enabled ACPI: (supports S0 S1 S5) ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI quirk: region e400-e47f claimed by ICH4 ACPI/GPIO/TCO PCI quirk: region ec00-ec3f claimed by ICH4 GPIO PCI: Transparent bridge - :00:1e.0 ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Interrupt Link
Re: [git pull] Input updates for 2.6.25-rc0
On Sat, 9 Feb 2008 00:25:36 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > > > Stephen Hemminger (2): > > Input: add driver for Fujitsu application buttons > > this change broke the build on x86 in randconfig testing: > > drivers/built-in.o: In function `apanel_detach_client': > apanel.c:(.text+0x15c120): undefined reference to > `__led_classdev_unregister' > drivers/built-in.o: In function `apanel_probe': > apanel.c:(.text+0x15c30f): undefined reference to `led_classdev_register' > > .config attached. > > the Kconfig dependencies seem incomplete: > > > +config INPUT_APANEL > > + tristate "Fujitsu Lifebook Application Panel buttons" > > + depends on X86 > > + select I2C_I801 > > + select INPUT_POLLDEV > > + select CHECK_SIGNATURE > > + help > > it doesnt list LEDS. > > Ingo I think someone already sent a patch to select the LEDS -- Stephen Hemminger <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Hi Valdis, > > And while you are talking to a lawyer. Ask him/her if it is okay to > > create a binary only application that uses a GPL library. Tell him/her > > It's perfectly legal to create such an application. > > It only gets interesting if you *distribute* it... > > (And yes, this is where you *have* to be pedantic about the wording used)... true, true and true. However I was under the impression we passed that discussion point, that you can do whatever inside your own walls :) Regards Marcel -- 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: mark USB drivers as being GPL only
On Friday 08 February 2008 16:36:37 Alan Cox wrote: > > In other words "EXPORT_SYMBOL_GPL" isn't his idea of "a good legal idea", > > but people ignoring this and doing things that circumvent this will, > > eventually, have problems with the people who hold the copyright on the > > code. (In addition, he stated that circumventing the "EXPORT_SYMBOL_GPL" > > bit might also be in violation of the DMCA, but he isn't sure if a court > > would see it in the same light as someone cracking the CSS key on a DVD > > expressly for the purpose of creating pirated copies) > > There was a good analysis of that argument on the list some time ago. I > think the conclusion was fairly definitively no as the GPL explicitly > gives the right to modify GPL code. You are therefore aready "authorised" > to make such a change. > > It might have a significance in terms of intent but thats for lawyers to > argue over. > > Alan I think that's why he said he "Wasn't Sure" - as was pointed out in another post, the Lexmark ruling appears to apply for more than the "interface" portion of the ruling. And Alan, while it might be legal to make the changes, making them for the sole purpose of using them in a proprietary module - when the people who actually hold the copyright have said "I think this is so core to the kernel that anything using it is a derivative work" - is what he thought *MIGHT* be legally actionable under the DMCA. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] Input updates for 2.6.25-rc0
* Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > Stephen Hemminger (2): > Input: add driver for Fujitsu application buttons this change broke the build on x86 in randconfig testing: drivers/built-in.o: In function `apanel_detach_client': apanel.c:(.text+0x15c120): undefined reference to `__led_classdev_unregister' drivers/built-in.o: In function `apanel_probe': apanel.c:(.text+0x15c30f): undefined reference to `led_classdev_register' .config attached. the Kconfig dependencies seem incomplete: > +config INPUT_APANEL > + tristate "Fujitsu Lifebook Application Panel buttons" > + depends on X86 > + select I2C_I801 > + select INPUT_POLLDEV > + select CHECK_SIGNATURE > + help it doesnt list LEDS. Ingo # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24 # Sat Feb 9 00:11:37 2008 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_HWEIGHT=y # CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set CONFIG_ARCH_HAS_CPU_RELAX=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_X86_32_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y # CONFIG_SYSVIPC is not set CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y # CONFIG_TASK_XACCT is not set CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=20 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y # CONFIG_NAMESPACES is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_EMBEDDED=y # CONFIG_UID16 is not set # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y # CONFIG_BUG is not set CONFIG_ELF_CORE=y # CONFIG_COMPAT_BRK is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y # CONFIG_EPOLL is not set # CONFIG_SIGNALFD is not set # CONFIG_TIMERFD is not set CONFIG_EVENTFD=y CONFIG_SHMEM=y # CONFIG_VM_EVENT_COUNTERS is not set # CONFIG_SLUB_DEBUG is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_MARKERS=y CONFIG_OPROFILE=y CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y CONFIG_HAVE_KPROBES=y # CONFIG_PROC_PAGE_MONITOR is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBD=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_LSF=y # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_CLASSIC_RCU=y # CONFIG_PREEMPT_RCU is not set # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y # CONFIG_X86_PC is not set # 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=y # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_X86_RDC321X is not set # CONFIG_X86_VSMP is not set # CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER is not set CONFIG_PARAVIRT_GUEST=y CONFIG_XEN=y CONFIG_VMI=y CONFIG_PARAVIRT=y # CONFIG_M386 is not set # CONFIG_M486
Re: 2.6.24-git15 Keyboard Issue?
On Fri, 8 Feb 2008, Jiri Kosina wrote: > > > I hope that, from at least my perspective, your question is > > > rhetorical. > > Yeah. The non rhetorical one was directed to Jiri. :) > Actually, I have no idea :) I am right now confused too, I am quite > surprised that 'nohpet' fixes the problem for you, Chris, even though your > system doesn't have HPET at all :) > Could you please double-check that 'nohpet' really reliably fixes the > issue? > I suggested using nohpet as I have already seen reports about such kinds > of problems on machines that had hpet, but this one seems to be more > confusing :) > Also, output of the kernel with the patch Thomas provided would be > interesting. And of course I forgot to mention -- if this started happening only recently, and wasn't hapenning with older kernels, doing git-bisect might help here (assuming that are able to see whether the problem is present or not) to find the exact commit that causes the behavior you are seeing. -- Jiri Kosina SUSE Labs -- 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] pcmcia: fix i82092 printk format
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix printk format warnings:
linux-2.6.24-git19/drivers/pcmcia/i82092.c:650: warning: format '%lx' expects
type 'long unsigned int', but argument 3 has type 'resource_size_t'
linux-2.6.24-git19/drivers/pcmcia/i82092.c:650: warning: format '%lx' expects
type 'long unsigned int', but argument 4 has type 'resource_size_t'
Fix very long source line size.
Fix spacing within the printk format string.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/pcmcia/i82092.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- linux-2.6.24-git19.orig/drivers/pcmcia/i82092.c
+++ linux-2.6.24-git19/drivers/pcmcia/i82092.c
@@ -647,7 +647,9 @@ static int i82092aa_set_mem_map(struct p
if ( (mem->card_start > 0x3ff) || (region.start > region.end) ||
(mem->speed > 1000) ) {
leave("i82092aa_set_mem_map: invalid address / speed");
- printk("invalid mem map for socket %i : %lx to %lx with a start
of %x \n",sock,region.start, region.end, mem->card_start);
+ printk("invalid mem map for socket %i: %llx to %llx with a
start of %x\n",
+ sock, (unsigned long long)region.start,
+ (unsigned long long)region.end, mem->card_start);
return -EINVAL;
}
--
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: [BUG] 2.6.24 refuses to boot - NMI watchdog problem?
And the same thing with 2.6.24.1. Cheers, Chris Linux version 2.6.24.1 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)) #1 SMP PREEMPT Fri Feb 8 22:41:10 GMT 2008 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1ffeb000 (usable) BIOS-e820: 1ffeb000 - 1ffef000 (ACPI data) BIOS-e820: 1ffef000 - 1000 (reserved) BIOS-e820: 1000 - 2000 (ACPI NVS) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: fff8 - 0001 (reserved) 511MB LOWMEM available. Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 131051 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -> 131051 DMI 2.3 present. ACPI: RSDP 000F7B40, 0014 (r0 ASUS ) ACPI: RSDT 1FFEB000, 0030 (r1 ASUS TUSL2-C 30303031 MSFT 31313031) ACPI: FACP 1FFEB100, 0074 (r1 ASUS TUSL2-C 30303031 MSFT 31313031) ACPI: DSDT 1FFEB180, 39FA (r1 ASUS TUSL2-C 1000 MSFT 10B) ACPI: FACS 1000, 0040 ACPI: BOOT 1FFEB040, 0028 (r1 ASUS TUSL2-C 30303031 MSFT 31313031) ACPI: APIC 1FFEB080, 005A (r1 ASUS TUSL2-C 30303031 MSFT 31313031) ACPI: PM-Timer IO Port: 0xe408 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 17 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level) Enabling APIC mode: Logical Cluster. Using 1 I/O APICs, target cpus f Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 3000 (gap: 2000:dec0) Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130028 Kernel command line: ro root=LABEL=/ video=matroxfb:vesa:0x11A console=ttyS0,115200n8 console=tty0 nmi_watchdog=1 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c035f000 soft=c035b000 PID hash table entries: 2048 (order: 11, 8192 bytes) Detected 1005.042 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled console [ttyS0] enabled Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 513484k/524204k available (1577k kernel code, 10128k reserved, 607k data, 196k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfffb5000 - 0xf000 ( 296 kB) vmalloc : 0xe080 - 0xfffb3000 ( 503 MB) lowmem : 0xc000 - 0xdffeb000 ( 511 MB) .init : 0xc0327000 - 0xc0358000 ( 196 kB) .data : 0xc028a7ca - 0xc03227c4 ( 607 kB) .text : 0xc010 - 0xc028a7ca (1577 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 Calibrating delay using timer specific routine.. 2011.89 BogoMIPS (lpj=4023790) Mount-cache hash table entries: 512 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Compat vDSO mapped to e000. Checking 'hlt' instruction... OK. SMP alternatives: switching to UP code Freeing SMP alternatives: 9k freed ACPI: Core revision 20070126 CPU0: Intel Pentium III (Coppermine) stepping 06 Leaving ESR disabled. Total of 1 processors activated (2011.89 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 WARNING: at arch/x86/kernel/smp_32.c:561 native_smp_call_function_mask() Pid: 1, comm: swapper Not tainted 2.6.24.1 #1 [] show_trace_log_lvl+0x1a/0x2f [] show_trace+0x12/0x14 [] dump_stack+0x6c/0x72 [] native_smp_call_function_mask+0x44/0x102 [] smp_call_function+0x1e/0x22 [] on_each_cpu+0x2a/0x57 [] setup_nmi+0x33/0x4a [] setup_IO_APIC+0x929/0xf11 [] native_smp_prepare_cpus+0x487/0x497 [] kernel_init+0x54/0x2c3 [] kernel_thread_helper+0x7/0x10 === APIC timer registered as dummy, due to nmi_watchdog=1! Brought up 1 CPUs net_namespace: 64 bytes NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xf0e30, last bus=3 PCI: Using configuration type 1 Setting up standard PCI resources ACPI: Interpreter enabled ACPI: (supports S0 S1 S5) ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI quirk: region e400-e47f claimed by ICH4 ACPI/GPIO/TCO PCI quirk: region ec00-ec3f claimed by ICH4 GPIO PCI: Transparent bridge - :00:1e.0 ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10
