Re: system freezes for 0.2 to 0.5 seconds when reading /proc/acpi/thermal_zone/THRM/temperature
Florian Engelhardt <[EMAIL PROTECTED]> wrote: > > Hello, > > On Wed, 27 Jul 2005 16:16:05 -0700 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > Florian Engelhardt <[EMAIL PROTECTED]> wrote: > > > > > > Hello, > > > > > > first of all, sorry for the long headline. > > > second: > > > Every time, i try to do the following: > > > cat /proc/acpi/thermal_zone/THRM/temperature > > > the whole system looks up for a short period of time (something > > > about 0.5s). realy everything, video and audio encoding, mouse and > > > keyboard input, firefox playing a flash animation, ... > > > I am also getting the following: > > > Losing some ticks... checking if CPU frequency changed. > > > > > > maybe these two things are belonging to each other. > > > > > > I am using a 2.6.12-rc3-mm1 kernel on a amd64 with a nvidia nforce4 > > > mainboard. > > > > It might help if you were to generate a kernel profile: > > > > readprofile -r > > returns: > /proc/profile: No such file or directory > > do i have to activate something special during kernel configuration? Set CONFIG_PROFILING=y > btw: i saw that mm2 is available. Are there any changes in it, which > could solve this problem? Well there's a huge ACPI patch in there, but I cannot say whether it addresses this problem. - 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] Disable the debug.exception-trace sysctl by default
debug.exception-trace causes a large amount of log spew when on, and it's on by default, which is an irritation. Here's a patch to turn it off. --- linux-2.6.12/arch/x86_64/mm/fault.c.~1~ 2005-06-28 21:33:27.0 -0700 +++ linux-2.6.12/arch/x86_64/mm/fault.c 2005-07-27 23:46:10.0 -0700 @@ -284,7 +284,7 @@ } int page_fault_trace = 0; -int exception_trace = 1; +int exception_trace = 0; /* * This routine handles page faults. It determines the address, -- Nicholas Miell <[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] arch/xx/pci: remap_pfn_range -> io_remap_pfn_range
Quoting r. Greg KH <[EMAIL PROTECTED]>: > Subject: Re: [PATCH] arch/xx/pci: remap_pfn_range -> io_remap_pfn_range > > On Tue, Jul 26, 2005 at 01:32:00AM +0300, Michael S. Tsirkin wrote: > > Greg, Martin, does the following make sense? > > If it does, should other architectures be updated as well? > > > Hm, you do realize that io_remap_pfn_range() is the same thing as > remap_pfn_range() on i386, right? > > So, why would this patch change anything? > > thanks, > > greg k-h > It doesnt change any behaviour. Its a style issue I'm trying to fix: even in arch specific code, isnt it better to use a generic io_remap_pfn_range to map PCI memory? -- MST - 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: system freezes for 0.2 to 0.5 seconds when reading /proc/acpi/thermal_zone/THRM/temperature
Hello, On Wed, 27 Jul 2005 16:16:05 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > Florian Engelhardt <[EMAIL PROTECTED]> wrote: > > > > Hello, > > > > first of all, sorry for the long headline. > > second: > > Every time, i try to do the following: > > cat /proc/acpi/thermal_zone/THRM/temperature > > the whole system looks up for a short period of time (something > > about 0.5s). realy everything, video and audio encoding, mouse and > > keyboard input, firefox playing a flash animation, ... > > I am also getting the following: > > Losing some ticks... checking if CPU frequency changed. > > > > maybe these two things are belonging to each other. > > > > I am using a 2.6.12-rc3-mm1 kernel on a amd64 with a nvidia nforce4 > > mainboard. > > It might help if you were to generate a kernel profile: > > readprofile -r returns: /proc/profile: No such file or directory do i have to activate something special during kernel configuration? btw: i saw that mm2 is available. Are there any changes in it, which could solve this problem? flo > for i in $(seq 10) > do > cat /proc/acpi/thermal_zone/THRM/temperature > done > readprofile -n -v -m /boot/System.map | sort -n +2 | tail -40 > > -- "I may have invented it, but Bill made it famous" David Bradley, who invented the (in)famous ctrl-alt-del key combination - 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] driver core: Add the ability to unbind drivers to devices from userspace
On Thu, Jul 28, 2005 at 12:49:21AM -0400, Jon Smirl wrote:
> @@ -207,6 +208,28 @@ flush_write_buffer(struct dentry * dentr
> struct attribute * attr = to_attr(dentry);
> struct kobject * kobj = to_kobj(dentry->d_parent);
> struct sysfs_ops * ops = buffer->ops;
> + char *x, *y, *z;
> +
> + /* locate leading white space */
> + x = buffer->page;
> + while (isspace(*x) && (x - buffer->page < count))
> + x++;
Ok, I can follow this. For example
buffer->page = " foo "
then x = "foo " at the end of that .
> + /* locate trailng white space */
> + z = y = x;
> + while (y - buffer->page < count) {
> + y++;
> + z = y;
> + while (isspace(*y) && (y - buffer->page < count)) {
> + y++;
> + }
> + }
> + count = z - x;
Hm, I _think_ this works, but I need someone else to verify this...
Anyone else?
> +
> + /* strip the white space */
> + if (buffer->page != x)
> + memmove(buffer->page, x, count);
> + buffer->page[count] = '\0';
Why move the buffer? Why not just pass in a pointer to the start of the
"non-whitespace filled" buffer to the store() function?
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: Fix up qla2xxx configuration bogosity
Linus, In looking through your latest git-pull and update of the Kconfig quirks in qla2xxx: Fix up qla2xxx configuration bogosity http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=e0aa8afd97536a9d94f82a07b4c4b3f05aef6f82;hp=e4ff4d7f9d85a2bc714307eb9113617182e62845 Would you also apply the attached patch which adds the appropriate FW_LOADER pre-requisite and a separate entry for ISP24xx support. Thanks to Adrian Bunk and Jesper Juhl for their efforts in fixing this quirk. Regards, Andrew Vasquez --- diff --git a/drivers/scsi/qla2xxx/Kconfig b/drivers/scsi/qla2xxx/Kconfig --- a/drivers/scsi/qla2xxx/Kconfig +++ b/drivers/scsi/qla2xxx/Kconfig @@ -7,6 +7,7 @@ config SCSI_QLA21XX tristate "QLogic ISP2100 host adapter family support" depends on SCSI_QLA2XXX select SCSI_FC_ATTRS + select FW_LOADER ---help--- This driver supports the QLogic 21xx (ISP2100) host adapter family. @@ -14,6 +15,7 @@ config SCSI_QLA22XX tristate "QLogic ISP2200 host adapter family support" depends on SCSI_QLA2XXX select SCSI_FC_ATTRS + select FW_LOADER ---help--- This driver supports the QLogic 22xx (ISP2200) host adapter family. @@ -21,6 +23,7 @@ config SCSI_QLA2300 tristate "QLogic ISP2300 host adapter family support" depends on SCSI_QLA2XXX select SCSI_FC_ATTRS + select FW_LOADER ---help--- This driver supports the QLogic 2300 (ISP2300 and ISP2312) host adapter family. @@ -29,6 +32,7 @@ config SCSI_QLA2322 tristate "QLogic ISP2322 host adapter family support" depends on SCSI_QLA2XXX select SCSI_FC_ATTRS + select FW_LOADER ---help--- This driver supports the QLogic 2322 (ISP2322) host adapter family. @@ -36,6 +40,16 @@ config SCSI_QLA6312 tristate "QLogic ISP63xx host adapter family support" depends on SCSI_QLA2XXX select SCSI_FC_ATTRS + select FW_LOADER ---help--- This driver supports the QLogic 63xx (ISP6312 and ISP6322) host adapter family. + +config SCSI_QLA24XX + tristate "QLogic ISP24xx host adapter family support" + depends on SCSI_QLA2XXX + select SCSI_FC_ATTRS + select FW_LOADER + ---help--- + This driver supports the QLogic 24xx (ISP2422 and ISP2432) host + adapter family. diff --git a/drivers/scsi/qla2xxx/Makefile b/drivers/scsi/qla2xxx/Makefile --- a/drivers/scsi/qla2xxx/Makefile +++ b/drivers/scsi/qla2xxx/Makefile @@ -1,5 +1,4 @@ EXTRA_CFLAGS += -DUNIQUE_FW_NAME -EXTRA_CFLAGS += -DCONFIG_SCSI_QLA24XX -DCONFIG_SCSI_QLA24XX_MODULE qla2xxx-y := qla_os.o qla_init.o qla_mbx.o qla_iocb.o qla_isr.o qla_gs.o \ qla_dbg.o qla_sup.o qla_rscn.o qla_attr.o - 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: [openib-general] Re: [PATCH] arch/xx/pci: remap_pfn_range -> io_remap_pfn_range
On Wed, Jul 27, 2005 at 09:30:17PM -0700, Roland Dreier wrote: > Greg> Hm, you do realize that io_remap_pfn_range() is the same > Greg> thing as remap_pfn_range() on i386, right? > > Greg> So, why would this patch change anything? > > It's not the same thing under Xen. I think this patch fixes userspace > access to PCI memory for XenLinux. But Xen is a separate arch, and hence, will get different pci arch specific functions, right? In short, what is this patch trying to fix? What is the problem anyone is seeing with the existing code? 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] driver core: Add the ability to unbind drivers to devices from userspace
Change log and signed off
--
Jon Smirl
[EMAIL PROTECTED]
Remove leading and trailing whitespace when text sysfs attributes are
assigned a value.
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
@@ -207,6 +208,28 @@ flush_write_buffer(struct dentry * dentr
struct attribute * attr = to_attr(dentry);
struct kobject * kobj = to_kobj(dentry->d_parent);
struct sysfs_ops * ops = buffer->ops;
+ char *x, *y, *z;
+
+ /* locate leading white space */
+ x = buffer->page;
+ while (isspace(*x) && (x - buffer->page < count))
+ x++;
+
+ /* locate trailng white space */
+ z = y = x;
+ while (y - buffer->page < count) {
+ y++;
+ z = y;
+ while (isspace(*y) && (y - buffer->page < count)) {
+ y++;
+ }
+ }
+ count = z - x;
+
+ /* strip the white space */
+ if (buffer->page != x)
+ memmove(buffer->page, x, count);
+ buffer->page[count] = '\0';
return ops->store(kobj,attr,buffer->page,count);
}
-
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: [openib-general] Re: [PATCH] arch/xx/pci: remap_pfn_range -> io_remap_pfn_range
Greg> Hm, you do realize that io_remap_pfn_range() is the same Greg> thing as remap_pfn_range() on i386, right? Greg> So, why would this patch change anything? It's not the same thing under Xen. I think this patch fixes userspace access to PCI memory for XenLinux. - 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] arch/xx/pci: remap_pfn_range -> io_remap_pfn_range
On Tue, Jul 26, 2005 at 01:32:00AM +0300, Michael S. Tsirkin wrote: > Greg, Martin, does the following make sense? > If it does, should other architectures be updated as well? > > --- > > Convert i386/pci to use io_remap_pfn_range instead of remap_pfn_range. > > Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]> > > Index: linux-2.6.12.2/arch/i386/pci/i386.c > === > --- linux-2.6.12.2.orig/arch/i386/pci/i386.c > +++ linux-2.6.12.2/arch/i386/pci/i386.c > @@ -295,9 +295,9 @@ int pci_mmap_page_range(struct pci_dev * > /* Write-combine setting is ignored, it is changed via the mtrr >* interfaces on this platform. >*/ > - if (remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff, > - vma->vm_end - vma->vm_start, > - vma->vm_page_prot)) > + if (io_remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff, > +vma->vm_end - vma->vm_start, > +vma->vm_page_prot)) Hm, you do realize that io_remap_pfn_range() is the same thing as remap_pfn_range() on i386, right? So, why would this patch change anything? 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] Final InfiniBand updates for 2.6.13
Linus, please pull from rsync://rsync.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git for-linus This will update the following files: core/ucm.c| 88 +- core/uverbs.h |1 core/uverbs_main.c| 14 ++- hw/mthca/mthca_cq.c |6 ++- hw/mthca/mthca_provider.c |6 +-- ulp/ipoib/ipoib_ib.c |6 +-- 6 files changed, 66 insertions(+), 55 deletions(-) through the following changes: commit 79d81907594e1ec4d5171653dde7cb9e9cb87de2 Author: Hal Rosenstock <[EMAIL PROTECTED]> Date: Wed Jul 27 20:38:56 2005 -0700 [IB/ucm]: Clean up userspace CM Only print debug messages when debug_level is set. Eliminate NULL checks prior to calling kfree. Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]> Signed-off-by: Libor Michalek <[EMAIL PROTECTED]> commit 6d376756f2cf3478d5a4fdb8d18e958948366b9d Author: Michael S. Tsirkin <[EMAIL PROTECTED]> Date: Wed Jul 27 14:42:45 2005 -0700 [IB/mthca]: Use io_remap_pfn_range for PCI space Use io_remap_pfn_range to remap IO pages (remap_pfn_range is for memory). Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]> Signed-off-by: Roland Dreier <[EMAIL PROTECTED]> commit 2181858bb814b51de8ec25b3ddd37cd06c53b0c9 Author: Roland Dreier <[EMAIL PROTECTED]> Date: Wed Jul 27 14:41:32 2005 -0700 [IB/ipoib]: Fix unsigned comparisons to handle wraparound Fix handling of tx_head/tx_tail comparisons to handle wraparound. Signed-off-by: Roland Dreier <[EMAIL PROTECTED]> commit abdf119b4dad015803819c3d046d20cfbd393e87 Author: Gleb Natapov <[EMAIL PROTECTED]> Date: Wed Jul 27 14:40:00 2005 -0700 [IB/uverbs]: Add O_ASYNC support Add support for O_ASYNC notifications on userspace verbs completion and asynchronous event file descriptors. Signed-off-by: Gleb Natapov <[EMAIL PROTECTED]> Signed-off-by: Roland Dreier <[EMAIL PROTECTED]> commit 42b1806d5cfc93bf8c3d7fa6e9e79e4ec860c678 Author: Roland Dreier <[EMAIL PROTECTED]> Date: Wed Jul 27 14:38:49 2005 -0700 [IB/mthca]: Fix error CQ entry handling on mem-free HCAs Fix handling of error CQ entries on mem-free HCAs: the doorbell count is never valid so we shouldn't look at it. This fixes problems exposed by new HCA firmware. Signed-off-by: Roland Dreier <[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] driver core: Add the ability to unbind drivers to devices from userspace
On Wed, Jul 27, 2005 at 11:59:11PM -0400, Jon Smirl wrote: > New patch with fixed whitespace. But no changelog info or signed-off-by line :( Care to try it again? 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/
[PATCH] x86_64: sync_tsc fix the race (so we can boot)
sync_tsc was using smp_call_function to ask the boot processor
to report it's tsc value. smp_call_function performs an IPI_send_allbutself
which is a broadcast ipi. There is a window during processor startup during
which the target cpu has started and before it has initialized it's interrupt
vectors so it can properly process an interrupt. Receveing an interrupt
during that window will triple fault the cpu and do other nasty things.
Why cli does not protect us from that is beyond me.
The simple fix is to match ia64 and provide a smp_call_function_single.
Which avoids the broadcast and is more efficient.
This certainly fixes the problem of getting stuck on boot which was
very easy to trigger on my SMP Hyperthreaded Xeon, and I think
it fixes it for the right reasons.
I believe this patch suffers from apicid versus logical cpu number confusion.
I copied the basic logic from smp_send_reschedule and I can't find where
that translates from the logical cpuid to apicid. So it isn't quite
correct yet. It should be close enough that it shouldn't be too hard
to finish it up.
More bug fixes after I have slept but I figured I needed to get this
one out for review.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/smp.c | 65 ++
arch/x86_64/kernel/smpboot.c | 21 --
include/asm-x86_64/smp.h |2 +
3 files changed, 79 insertions(+), 9 deletions(-)
571d8bdc5a935b85fb0ce5ff3fac9a59a86efe6e
diff --git a/arch/x86_64/kernel/smp.c b/arch/x86_64/kernel/smp.c
--- a/arch/x86_64/kernel/smp.c
+++ b/arch/x86_64/kernel/smp.c
@@ -294,6 +294,71 @@ void unlock_ipi_call_lock(void)
}
/*
+ * this function sends a 'generic call function' IPI to one other CPU
+ * in the system.
+ */
+static void __smp_call_function_single (int cpu, void (*func) (void *info),
void *info,
+ int nonatomic, int wait)
+{
+ struct call_data_struct data;
+ int cpus = 1;
+
+ data.func = func;
+ data.info = info;
+ atomic_set(&data.started, 0);
+ data.wait = wait;
+ if (wait)
+ atomic_set(&data.finished, 0);
+
+ call_data = &data;
+ wmb();
+ /* Send a message to all other CPUs and wait for them to respond */
+ send_IPI_mask(cpumask_of_cpu(cpu), CALL_FUNCTION_VECTOR);
+
+ /* Wait for response */
+ while (atomic_read(&data.started) != cpus)
+ cpu_relax();
+
+ if (!wait)
+ return;
+
+ while (atomic_read(&data.finished) != cpus)
+ cpu_relax();
+}
+
+/*
+ * Run a function on another CPU
+ * The function to run. This must be fast and non-blocking.
+ * An arbitrary pointer to pass to the function.
+ * Currently unused.
+ * If true, wait until function has completed on other CPUs.
+ * [RETURNS] 0 on success, else a negative status code.
+ *
+ * Does not return until the remote CPU is nearly ready to execute
+ * or is or has executed.
+ */
+
+int smp_call_function_single (int cpu, void (*func) (void *info), void *info,
+ int nonatomic, int wait)
+{
+
+ int me = get_cpu(); /* prevent preemption and reschedule on another
processor */
+
+ if (cpu == me) {
+ printk("%s: trying to call self\n", __func__);
+ put_cpu();
+ return -EBUSY;
+ }
+ spin_lock_bh(&call_lock);
+
+ __smp_call_function_single(cpu, func,info,nonatomic,wait);
+
+ spin_unlock_bh(&call_lock);
+ put_cpu();
+ return 0;
+}
+
+/*
* this function sends a 'generic call function' IPI to all other CPUs
* in the system.
*/
diff --git a/arch/x86_64/kernel/smpboot.c b/arch/x86_64/kernel/smpboot.c
--- a/arch/x86_64/kernel/smpboot.c
+++ b/arch/x86_64/kernel/smpboot.c
@@ -229,9 +229,6 @@ static __cpuinit void sync_master(void *
{
unsigned long flags, i;
- if (smp_processor_id() != boot_cpu_id)
- return;
-
go[MASTER] = 0;
local_irq_save(flags);
@@ -280,7 +277,7 @@ get_delta(long *rt, long *master)
return tcenter - best_tm;
}
-static __cpuinit void sync_tsc(void)
+static __cpuinit void sync_tsc(unsigned int master)
{
int i, done = 0;
long delta, adj, adjust_latency = 0;
@@ -294,9 +291,17 @@ static __cpuinit void sync_tsc(void)
} t[NUM_ROUNDS] __cpuinitdata;
#endif
+ printk(KERN_INFO "CPU %d: Syncing TSC to CPU %u.\n",
+ smp_processor_id(), master);
+
go[MASTER] = 1;
- smp_call_function(sync_master, NULL, 1, 0);
+ /* It is dangerous to broadcast IPI as cpus are coming up,
+* as they may not be ready to accept them. So since
+* we only need to send the ipi to the boot cpu direct
+* the message, and avoid the race.
+*/
+ smp_call_function_single(master, sync_master, NULL, 1, 0);
while (go[MASTER]) /* wait for master to be
Re: [PATCH] driver core: Add the ability to unbind drivers to devices from userspace
New patch with fixed whitespace.
--
Jon Smirl
[EMAIL PROTECTED]
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
@@ -207,6 +208,28 @@ flush_write_buffer(struct dentry * dentr
struct attribute * attr = to_attr(dentry);
struct kobject * kobj = to_kobj(dentry->d_parent);
struct sysfs_ops * ops = buffer->ops;
+ char *x, *y, *z;
+
+ /* locate leading white space */
+ x = buffer->page;
+ while (isspace(*x) && (x - buffer->page < count))
+ x++;
+
+ /* locate trailng white space */
+ z = y = x;
+ while (y - buffer->page < count) {
+ y++;
+ z = y;
+ while (isspace(*y) && (y - buffer->page < count)) {
+ y++;
+ }
+ }
+ count = z - x;
+
+ /* strip the white space */
+ if (buffer->page != x)
+ memmove(buffer->page, x, count);
+ buffer->page[count] = '\0';
return ops->store(kobj,attr,buffer->page,count);
}
-
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: "seeing minute plus hangs during boot" - 2.6.12 and 2.6.13
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Morton wrote: >>> >> >> >>Hi Andrew. >>I was not able to get anything when I press this key sequence. >> >>I checked my sysrq key with showkey -s as this doc >>(http://snafu.freedom.org/linux2.2/docs/sysrq.txt) says and I could >>confirm that alt+sysrq is sending 0x54. >> >>I also noted that many said that this option has to be compiled in >>kernel, but I couldn't find this option. >> >>Can you give me some tips? >> > > > (Please leave the cc list unchanged - always do reply-to-all) > > hm, maybe do alt-sysrq-7 to make sure that the loglevel is appropriately set. > > Or do alt-sysrq-B to test that the whole sysrq thing is working. If it is, > that will reboot the machine. > > Ok, nevermind. I just found that I didn't add the sysrq support when compiling my kernel :( I will recompile it and send you stack trace. Sorry for wasting your time, Andrew. - -- Regards, Francisco Figueiredo Jr. Npgsql Lead Developer http://gborg.postgresql.org/project/npgsql MonoBrasil Project Founder Member http://monobrasil.softwarelivre.org - - "Science without religion is lame; religion without science is blind." ~ Albert Einstein -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQuhebv7iFmsNzeXfAQKovAf+IytBAXybpV102ATXL6lDrNKCwy9QsmWH ntUv9+JLeIKbuzKJFn2gu3ftLW5dwiXq2fL0aRg5NGk9K32pCGcE43LEyZ+dglG9 FWBNV47iB4NxOLh7YfKrOf7wT3eRs4Qwfm9TZn5segJn0MExd9kHuYgJ1hO/ZUzF OksF5hAusjTM7dLA2LwX7mUOMs8VFPqRuEufCQ/TOCiPhxzoZJ6XFbkJ3ZHwqJ9m jZwfHihz2n0NiBWu0vNGBS2EjS3U2URphV0fhCAt/pILAk1kQvEAsXBo0vgFwsfg dYSjubVnPffACPFZZsNvjUBFf6tQ32+t1vVFDHD1ym2wq/4z87+5pw== =nG/V -END PGP SIGNATURE- ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable
Steven Rostedt wrote: OK, still looks like the generic ffb can be changed. Unless I'm missing something, this shows that I probably should be sending in a patch now to replace the find_first_bit. Ingo's sched_find_first_bit is still the winner, but that is customed to the scheduler, until we need a configurable priority. What do you think? Sure, if it is correct and faster. Just don't mark the (*b) test as unlikely. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "seeing minute plus hangs during boot" - 2.6.12 and 2.6.13
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Morton wrote: >>Hi Andrew. >>I was not able to get anything when I press this key sequence. >> >>I checked my sysrq key with showkey -s as this doc >>(http://snafu.freedom.org/linux2.2/docs/sysrq.txt) says and I could >>confirm that alt+sysrq is sending 0x54. >> >>I also noted that many said that this option has to be compiled in >>kernel, but I couldn't find this option. >> >>Can you give me some tips? >> > > > (Please leave the cc list unchanged - always do reply-to-all) > Oooops, sorry for that. I'm used to not send duplicate messages in reply all. > hm, maybe do alt-sysrq-7 to make sure that the loglevel is appropriately set. > > Or do alt-sysrq-B to test that the whole sysrq thing is working. If it is, > that will reboot the machine. > > Hi Andrew. No luck here :( Indeed my laptop has two keys: Sysrq and prtScrn. I tried both and no one worked. Am I missing something? I will do more research about it. Thanks in advance. - -- Regards, Francisco Figueiredo Jr. Npgsql Lead Developer http://gborg.postgresql.org/project/npgsql MonoBrasil Project Founder Member http://monobrasil.softwarelivre.org - - "Science without religion is lame; religion without science is blind." ~ Albert Einstein -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQuhdJ/7iFmsNzeXfAQK8jQgApO7admM+5rpw4jHQ59br6qbUi07hDP0W jl2IsAKXtyhTWeqQGLYbUbWu/4CirfwUcadrZBuUdBzn6dPTxbYSpseRKvyTTYR6 bZWH6HvlN9eEiu3VoGBN+CsQPCjZiFm/AmQJvjxaBlLi0eA6O2W1iPrkURLtE1U2 EUb4RRgtMfAv/CjMm8On8AGVUmJ6/7CabBTu2aNsQZpICga7QRUbZa1Iwkx/o5ls y2o8rCyx/VcHMOaFxlpRDmBTvM7UwveJYA4wsNt9WQJ4kMBNJ46pDHhFDJY0zEkp kdZJP0n3i08HCyWG6F9tqkoRhjv+9a+yrko/OByB6yIVOcWUAccO0g== =hR7g -END PGP SIGNATURE- ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: Add the ability to unbind drivers to devices from userspace
On Wed, Jul 27, 2005 at 10:05:34PM -0400, Jon Smirl wrote: > Any comments on this? I'll fix up the whitespace issues if everyone > agrees that the code works. I'll add the patch to my tree and -mm if you clean up the whitespace issues :) 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] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable
On Wed, 2005-07-27 at 23:32 -0400, Steven Rostedt wrote: > New benchmarks with my own formula. > Take two: I ran this on my laptop (IBM ThinkPad G41 with an 3.3GHz Pentium 4 HT processor, yeah yeah, no battery life :-). But this has an older compiler. $ gcc -v Reading specs from /usr/lib/gcc-lib/i486-linux-gnu/3.3.6/specs Configured with: ../src/configure -v --enable-languages=c,c ++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --enable-__cxa_atexit --with-system-zlib --enable-nls --without-included-gettext --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux-gnu Thread model: posix gcc version 3.3.6 (Debian 1:3.3.6-7) Here's the results on it: compiled again with "gcc -O2 -o ffb ffb.c" /* comments embedded */ sched=128 ffb=160 my=160 /* this is a 3.3GHz so clocks look good */ clock speed = :c5e54f4c 3320139596 ticks per second sched=159 ffb=159 my=159 last bit set generic ffb: :0a25b1d0 /* Hmm, all generic ffb is even slower? do I blame gcc or Intel? */ time: 0.051275712us sched ffb: :0023ae21 /* double Hmm, Ingo's is faster !? */ time: 0.000704289us my ffb: :019c458d /* look at this, mine is the same. Are the three bears coming around soon :-) */ time: 0.008137802us sched=0 ffb=0 my=0 first bit set generic ffb: :09766c3c time: 0.047816034us sched ffb: :0023c79f time: 0.000706254us my ffb: :005a8758 time: 0.001786939us OK, still looks like the generic ffb can be changed. Unless I'm missing something, this shows that I probably should be sending in a patch now to replace the find_first_bit. Ingo's sched_find_first_bit is still the winner, but that is customed to the scheduler, until we need a configurable priority. What do you think? -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel oops in 2.6.12.3 SMP
I've been having frequent lockup, especially while booting. Once it
hangs, even reset button doesn't reboot the machine. I have to turn
on/off the power. I suspect my memory is going bad.
In the last lockup, some kernel messages showed up in /var/log/syslog.
Can anyone decipher this into plain English?
<1>Unable to handle kernel paging request at virtual address 7fd48ac8
printing eip:
c015603f
*pde =
Oops: [#12]
SMP
Modules linked in: ppp_deflate zlib_deflate zlib_inflate bsd_comp ppp_async
crc_ccitt 8250 serial_core ppp_generic slhc psmouse pcspkr snd_pcm_oss
snd_mixer_oss nfsd exportfs lockd sunrpc ipt_MASQUERADE ipt_LOG ipt_state
iptable_filter ip_nat_ftp iptable_nat ip_tables ip_conntrack_ftp ip_conntrack
via_agp agpgart parport_pc parport snd_ens1371 snd_rawmidi snd_seq_device
snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc 3c59x mii ext3 jbd
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010286 (2.6.12.3-smp)
EIP is at do_sync_read+0x9f/0xe0
eax: 0080 ebx: d928ac40 ecx: e08623e0 edx:
esi: d14d9ee0 edi: d14d9fa4 ebp: bfea4524 esp: d14d9ed4
ds: 007b es: 007b ss: 0068
Process mpg123 (pid: 2523, threadinfo=d14d8000 task=d731a080)
Stack: 0080 00218b40 cfe9412c 0001
d928ac40 df564530 d6dd5000 c0164dcf d14d9f58 d731a080
00218b40 cfe9412c dffc3980 c0155591 d928ac8c
Call Trace:
[] open_namei+0x9f/0x610
[] dentry_open+0xf1/0x200
[] autoremove_wake_function+0x0/0x40
[] filp_open+0x50/0x60
[] vfs_read+0x97/0x100
[] sys_read+0x3d/0x70
[] syscall_call+0x7/0xb
Code: 89 44 24 60 89 44 24 64 8b bc 24 9c 00 00 00 8b 07 8b 57 04 89 54 24 40
89 44 24 3c 89 e6 8b 4b 10 52 50 8b 84 24 a0 00 00 00 50 <8b> 3c 68 40 c1 00 f9
30 c0 00 f9 30 c0 4c 68 40 c1 4c 68 40 c1
--
William Park <[EMAIL PROTECTED]>, Toronto, Canada
ThinFlash: Linux thin-client on USB key (flash) drive
http://home.eol.ca/~parkw/thinflash.html
BashDiff: Super Bash shell
http://freshmeat.net/projects/bashdiff/
-
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] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable
New benchmarks with my own formula.
I added my own find_first_bit algorithm, that still doesn't quite beat
Ingo's sched_find_first_bit, but it does a number on the generic
find_first_bit. I guess the compiler has finally beat what we do in
asm. Here's my generic algorithm.
static inline int my_find_first_bit(const unsigned long *b, unsigned size)
{
int x = 0;
size += 31;
do {
if (unlikely(*b))
return __ffs(*b) + x;
b++;
x += 32;
} while (x < size);
return x-32;
}
And here's the new results of my benchmark: Comments added.
/*
* I put in what is returned to see what really is returned is
* correct. Funny that sched_find_first_bit is wrong if there
* isn't a bit set. But this shouldn't be called if there isn't
* one set.
*/
sched=128 ffb=160 my=160
clock speed = :7f2f2cbb 2133798075 ticks per second
/* Here I set the last bit of 5 32bit words. */
sched=159 ffb=159 my=159
last bit set
generic ffb: :026a1cea
time: 0.018984294us
sched ffb: :001ee719
time: 0.000949125us
/*
* My time is 8ns, 8 times longer than Ingo's if the last
* bit is set (most likely case), but still more than twice
* as fast as ffb.
*/
my ffb: :0106a3dd
time: 0.008066546us
sched=0 ffb=0 my=0
first bit set
generic ffb: :01ee8e2b
time: 0.015189432us
sched ffb: :001eea92
time: 0.000949542us
/*
* With the first bit set, I'm still slower than Ingo's
* but only by 2, and I still beat the pants off of ffb.
*/
my ffb: :004d5de6
time: 0.002376190us
Conclusion: it looks like it might be time to change the i386 generic
ffb to something else.
Oh, and if you are wondering...
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c
++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --enable-nls
--without-included-gettext --enable-threads=posix --program-suffix=-4.0
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm
--enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.1 (Debian 4.0.1-2)
-- Steve
Attached is new version of ffb.c
#include
#include
#include
#include
#define unlikely(x) __builtin_expect(!!(x), 0)
static inline int find_first_bit(const unsigned long *addr, unsigned size)
{
int d0, d1;
int res;
/* This looks at memory. Mark it volatile to tell gcc not to move it around */
__asm__ __volatile__(
"xorl %%eax,%%eax\n\t"
"repe; scasl\n\t"
"jz 1f\n\t"
"leal -4(%%edi),%%edi\n\t"
"bsfl (%%edi),%%eax\n"
"1:\tsubl %%ebx,%%edi\n\t"
"shll $3,%%edi\n\t"
"addl %%edi,%%eax"
:"=a" (res), "=&c" (d0), "=&D" (d1)
:"1" ((size + 31) >> 5), "2" (addr), "b" (addr) : "memory");
return res;
}
static inline unsigned long __ffs(unsigned long word)
{
__asm__("bsfl %1,%0"
:"=r" (word)
:"rm" (word));
return word;
}
static inline int sched_find_first_bit(const unsigned long *b)
{
if (unlikely(b[0]))
return __ffs(b[0]);
if (unlikely(b[1]))
return __ffs(b[1]) + 32;
if (unlikely(b[2]))
return __ffs(b[2]) + 64;
if (b[3])
return __ffs(b[3]) + 96;
return __ffs(b[4]) + 128;
}
static inline int my_find_first_bit(const unsigned long *b, unsigned size)
{
int x = 0;
size += 31;
do {
if (unlikely(*b))
return __ffs(*b) + x;
b++;
x += 32;
} while (x < size);
return x-32;
}
#define rdtscll(val) \
__asm__ __volatile__("rdtsc" : "=A" (val))
#define rdtsc(low,high) \
__asm__ __volatile__("rdtsc" : "=a" (low), "=d" (high))
static unsigned long array[5];
#define ITER 100 /* 1,000,000 times */
void testit(unsigned long *array, unsigned long long clock)
{
unsigned long long s;
unsigned long long e;
unsigned long long t;
double f;
int i;
int x;
/*
* Since ITER is 1,000,000 the times will be in us.
*/
rdtscll(s);
for (i=0; i < ITER; i++)
x = find_first_bit(array,140);
rdtscll(e);
t = e - s;
f = (float)t / (float)clock;
printf("generic ffb: %08lx:%08lx\n",
(unsigned long)(t>>32),(unsigned long)t);
printf("time: %.09fus\n",f);
rdtscll(s);
for (i=0; i < ITER; i++)
x = sched_find_first_bit(array);
rdtscll(e);
t = e - s;
f = (float)t / (float)clock;
printf("sched ffb: %08lx:%08lx\n",
(unsigned long)(t>>32),(unsigned long)t);
printf("time: %.09fus\n",f);
rdtscll(s);
for (i=0; i < ITER; i++)
x = my_find_first_bit(array,140);
rdtscll(e);
t = e - s;
f = (float)t / (float)clock;
printf("my ffb: %08lx:%08lx\n",
(unsigned long)(t>>32),(unsigned long)t);
printf("time: %.09fus\n",f);
}
int main(int argc, char **argv)
{
unsigned long long s;
unsigned long long e;
unsigned long long t;
unsigned long long clock;
printf("sched=%d ffb=%d my=%d\n",
sched
Alternative to TIF_FREEZE -> a notifier in the task_struct?
Hmmm. I am thinking about an alternative to PF_FREEZE and TIF_FREEZE.
PF/TIF_FREEZE essentially makes a task call a certain function in the
context of the task. Maybe there is a way to generalize that?
One could introducing a notifier chain (todo) in the task_struct that
is then called in the current places where PF/TIF_FREEZE is checked?
This could be used to have a process execute any other piece that is
required to run in the context of the thread. Maybe such a feature could
help with PTRACE or/and get_user_pages that currently do ugly things to a
process. It may also allow changing values that so far cannot be
changed from the outside in the task struct by running a function
in the context of the process.
The feature to execute a function via a notifier chain allows to localize
the suspend functionality in kernel/power/process.c. We may be able to
take the definitions out of sched.h (while adding the functions to handle
the todo list).
Here is a patch against Linus current tree that does this. Note that this
patch is incomplete at this point and only a basis for further discussion.
Not all software suspend checkpoints are useful for a notifier chain. We
would need to inspect several cases where drivers/kernel threads have
special functionality for software suspend.
Index: linux-2.6/include/linux/sched.h
===
--- linux-2.6.orig/include/linux/sched.h2005-07-27 19:59:28.0
-0700
+++ linux-2.6/include/linux/sched.h 2005-07-27 20:04:57.0 -0700
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
struct exec_domain;
@@ -720,7 +721,10 @@
int (*notifier)(void *priv);
void *notifier_data;
sigset_t *notifier_mask;
-
+
+ /* todo list to be executed in the context of this thread */
+ struct notifier_block *todo;
+
void *security;
struct audit_context *audit_context;
seccomp_t seccomp;
@@ -811,7 +815,6 @@
#define PF_MEMALLOC0x0800 /* Allocating memory */
#define PF_FLUSHER 0x1000 /* responsible for disk writeback */
#define PF_USED_MATH 0x2000 /* if unset the fpu must be initialized
before use */
-#define PF_FREEZE 0x4000 /* this task is being frozen for
suspend now */
#define PF_NOFREEZE0x8000 /* this thread should not be frozen */
#define PF_FROZEN 0x0001 /* frozen for system suspend */
#define PF_FSTRANS 0x0002 /* inside a filesystem transaction */
@@ -1273,78 +1276,46 @@
#endif
-#ifdef CONFIG_PM
-/*
- * Check if a process has been frozen
- */
-static inline int frozen(struct task_struct *p)
-{
- return p->flags & PF_FROZEN;
-}
-
/*
- * Check if there is a request to freeze a process
+ * Check if there is a todo list request
*/
-static inline int freezing(struct task_struct *p)
+static inline int todo_list_active(void)
{
- return p->flags & PF_FREEZE;
+ return current->todo != NULL;
}
-/*
- * Request that a process be frozen
- * FIXME: SMP problem. We may not modify other process' flags!
- */
-static inline void freeze(struct task_struct *p)
+static inline void run_todo_list(void)
{
- p->flags |= PF_FREEZE;
+ notifier_call_chain(¤t->todo, 0, current);
}
-/*
- * Wake up a frozen process
- */
-static inline int thaw_process(struct task_struct *p)
+static inline int try_todo_list(void)
{
- if (frozen(p)) {
- p->flags &= ~PF_FROZEN;
- wake_up_process(p);
+ if (todo_list_active()) {
+ run_todo_list();
return 1;
- }
- return 0;
+ } else
+ return 0;
}
-/*
- * freezing is complete, mark process as frozen
- */
-static inline void frozen_process(struct task_struct *p)
-{
- p->flags = (p->flags & ~PF_FREEZE) | PF_FROZEN;
-}
+#ifdef CONFIG_PM
-extern void refrigerator(void);
extern int freeze_processes(void);
extern void thaw_processes(void);
-static inline int try_to_freeze(void)
+/*
+ * Check if a process has been frozen
+ */
+static inline int frozen(struct task_struct *p)
{
- if (freezing(current)) {
- refrigerator();
- return 1;
- } else
- return 0;
+ return p->flags & PF_FROZEN;
}
+
#else
static inline int frozen(struct task_struct *p) { return 0; }
-static inline int freezing(struct task_struct *p) { return 0; }
-static inline void freeze(struct task_struct *p) { BUG(); }
-static inline int thaw_process(struct task_struct *p) { return 1; }
-static inline void frozen_process(struct task_struct *p) { BUG(); }
-
-static inline void refrigerator(void) {}
static inline int freeze_processes(void) { BUG(); return 0; }
static inline void thaw_processes(void) {}
-static inline int try_to_freeze(void) { return 0; }
-
#endif /* CONFIG_PM */
#endif /* __KERNEL__ */
Index: linux-2.6/kernel/power/process.c
==
Re: [RFC][PATCH] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable
On Wed, 2005-07-27 at 21:25 -0400, Steven Rostedt wrote:
> On Wed, 2005-07-27 at 18:00 -0700, Daniel Walker wrote:
> > Don't you break sched_find_first_bit() , seems it's dependent on a
> > 140-bit bitmap .
>
> Oops! I forgot about that. With my custom kernels I had to change this
> to use the generic find_first_bit routine. It's been a while since I
> made these changes. So when we really need to have custom settings, we
> would have to change this. I should have remembered this, since it did
> cause me couple of days of debugging. Anyway, I never did the
> measurements, but does anyone know what the performance difference is
> between find_first_bit and sched_find_first_bit? I guess I'll do it and
> report back later. This should also be in a comment around changing
> these settings.
OK, here's the benchmark. Attached is the program that I used, and
compiled it this way:
gcc -O2 -o ffb ffb.c
and here's the results:
clock speed = :7f30c931 2133903665 ticks per second
last bit set
generic ffb: :02755284
time: 0.019327615us
sched ffb: :001e8f2b
time: 0.000938529us
first bit set
generic ffb: :01ea41f0
time: 0.015056688us
sched ffb: :001e8eff
time: 0.000938509us
/proc/cpuinfo shows that I have a SMP Authentic AMD running at
2133.635 MHz. The SMP doesn't matter for this test, but the Hz goes
right in line to the above BS tick measure. I ran both the generic ffb
and the sched_find_first_bit 1,000,000 times each and took the
measurements of both. The sched_find_first_bit ran 20 times faster!!!
So that is quite an improvement. Even when I set the first bit, it is
15 times faster. The time between the two for the sched_ffb is pretty
much constant, where as the ffb is quicker the closer the bit is (as
expected). But we are talking 19ns to do this, and a colleague of mine
said that this is just eliminating a fart in the wind storm. But I
still think that the ffb should be better for something like the
scheduler. Well, I guess I can spend some more time playing with
algorithms that can improve the ffb :-)
-- Steve
#include
#include
#include
#include
#define unlikely(x) __builtin_expect(!!(x), 0)
static inline int find_first_bit(const unsigned long *addr, unsigned size)
{
int d0, d1;
int res;
/* This looks at memory. Mark it volatile to tell gcc not to move it around */
__asm__ __volatile__(
"xorl %%eax,%%eax\n\t"
"repe; scasl\n\t"
"jz 1f\n\t"
"leal -4(%%edi),%%edi\n\t"
"bsfl (%%edi),%%eax\n"
"1:\tsubl %%ebx,%%edi\n\t"
"shll $3,%%edi\n\t"
"addl %%edi,%%eax"
:"=a" (res), "=&c" (d0), "=&D" (d1)
:"1" ((size + 31) >> 5), "2" (addr), "b" (addr) : "memory");
return res;
}
static inline unsigned long __ffs(unsigned long word)
{
__asm__("bsfl %1,%0"
:"=r" (word)
:"rm" (word));
return word;
}
static inline int sched_find_first_bit(const unsigned long *b)
{
if (unlikely(b[0]))
return __ffs(b[0]);
if (unlikely(b[1]))
return __ffs(b[1]) + 32;
if (unlikely(b[2]))
return __ffs(b[2]) + 64;
if (b[3])
return __ffs(b[3]) + 96;
return __ffs(b[4]) + 128;
}
#define rdtscll(val) \
__asm__ __volatile__("rdtsc" : "=A" (val))
#define rdtsc(low,high) \
__asm__ __volatile__("rdtsc" : "=a" (low), "=d" (high))
static unsigned long array[5];
#define ITER 100 /* 1,000,000 times */
void testit(unsigned long *array, unsigned long long clock)
{
unsigned long long s1;
unsigned long long e1;
unsigned long long s2;
unsigned long long e2;
unsigned long long t1;
unsigned long long t2;
double f1;
double f2;
int i;
int x;
rdtscll(s1);
for (i=0; i < ITER; i++)
x = find_first_bit(array,140);
rdtscll(e1);
rdtscll(s2);
for (i=0; i < ITER; i++)
x = sched_find_first_bit(array);
rdtscll(e2);
t1 = e1 - s1;
t2 = e2 - s2;
f1 = (float)t1 / (float)clock;
f2 = (float)t2 / (float)clock;
/*
* Since ITER is 1,000,000 the times will be in us.
*/
printf("generic ffb: %08lx:%08lx\n",
(unsigned long)(t1>>32),(unsigned long)t1);
printf("time: %.09fus\n",f1);
printf("sched ffb: %08lx:%08lx\n",
(unsigned long)(t2>>32),(unsigned long)t2);
printf("time: %.09fus\n",f2);
}
int main(int argc, char **argv)
{
unsigned long long s;
unsigned long long e;
unsigned long long t;
unsigned long long clock;
/*
* Calculate BS time, just to get an
* idea of the tsc speed.
*/
rdtscll(s);
sleep(8);
rdtscll(e);
t = e - s;
t >>= 3;
printf("clock speed = %08lx:%08lx %llu ticks per second\n",
(unsigned long)(t>>32),(unsigned long)t,
t);
clock = t;
array[4] = 0x8000;
printf("last bit set\n");
testit(array,clock);
array[0] = 0x0001;
printf("\nfirst bit set\n");
testit(array,clock);
exit(0);
}
Re: [parisc-linux] Re: [2.6 patch] schedule obsolete OSS drivers for removal
> Stuart, Randolph, comments? > > 1. > http://cvs.parisc-linux.org/linux-2.6/sound/pci/ad1889.c?rev=1.30&view=markup sure, kill the OSS ad1889 driver. randolph - 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-pm] Re: [PATCH 1/23] Add missing device_suspsend(PMSG_FREEZE) calls.
On Wed, 2005-07-27 at 19:12 -0600, Eric W. Biederman wrote: > Nigel Cunningham <[EMAIL PROTECTED]> writes: > > > Hi. > > > > Could you please send PMSG_* related patches to linux-pm at > > lists.osdl.org as well? > > I'll try. My goal was not to add or change not functionality but to > make what the kernel was already doing be consistent. > > It turns out the device_suspend(PMSG_FREEZE) is a major pain > sitting in the reboot path and I will be submitting a patch to > remove it from the reboot path in 2.6.13 completely. > > At the very least the ide driver breaks, and the e1000 driver > is affected. > > And there is of course the puzzle of why there exists simultaneously > driver shutdown() and suspend(PMSG_FREEZE) methods as I believed they > are defined to do exactly the same thing. I would expect more driver breakage and for the shutdown either. In current stage, suspend(PMSG_FREEZE) might put devices into D3 state. How can a shutdown() be done again? Thanks, Shaohua - 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-pm] Re: [PATCH 1/23] Add missing device_suspsend(PMSG_FREEZE) calls.
> And there is of course the puzzle of why there exists simultaneously > driver shutdown() and suspend(PMSG_FREEZE) methods as I believed they > are defined to do exactly the same thing. No puzzle; that's not how they're defined. Both of them cause the device to quiesce that device's activity. But: - shutdown() is a "dirty shutdown OK" heads-up for some level of restart/reboot; hardware will be completely re-initialized later, normally with hardware level resets and OS rebooting. - freeze() is a "clean shutdown only" that normally sees hardware state preserved, and is followed by suspend() or resume(). Or so I had understood. That does suggest why having FREEZE in the reboot path could be trouble: you could be rebooting because that hardware won't do a clean shutdown! - 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: [PATCH] driver core: Add the ability to unbind drivers to devices from userspace
Any comments on this? I'll fix up the whitespace issues if everyone
agrees that the code works.
This patch will break all of the fbdev attributes since I was making
wrong assumptions. I have another patch ready to fix them after this
one goes in.
On 7/25/05, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 7/25/05, Greg KH <[EMAIL PROTECTED]> wrote:
> > > I'll put one together to trim leading/trailing white space from the
> > > buffer before it is passed into the attribute functions. Now that I
> > > think about this I believe the attributes should have always had the
> > > leading/trailing white space removed. If we don't do it in the sysfs
> > > code then every driver has to do it.
> >
> > Ok, sounds good.
>
> How does this look? This is a count based interface but a lot of
> attributes don't work unless I add the terminating zero. This
> interface should be documented: count or zero terminated, white space
> stripped or not, etc. Are these strings ASCII, UTF8, Unicode?
>
> diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
> --- a/fs/sysfs/file.c
> +++ b/fs/sysfs/file.c
> @@ -6,6 +6,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -207,6 +208,28 @@ flush_write_buffer(struct dentry * dentr
> struct attribute * attr = to_attr(dentry);
> struct kobject * kobj = to_kobj(dentry->d_parent);
> struct sysfs_ops * ops = buffer->ops;
> + char *x, *y, *z;
> +
> + /* locate leading white space */
> + x = buffer->page;
> + while( isspace(*x) && (x - buffer->page < count))
> + x++;
> +
> + /* locate trailng white space */
> + z = y = x;
> + while (y - buffer->page < count) {
> + y++;
> + z = y;
> + while( isspace(*y) && (y - buffer->page < count)) {
> + y++;
> + }
> + }
> + count = z - x;
> +
> + /* strip the white space */
> + if (buffer->page != x)
> + memmove(buffer->page, x, count);
> + buffer->page[count] = '\0';
>
> return ops->store(kobj,attr,buffer->page,count);
> }
>
>
> --
> Jon Smirl
> [EMAIL PROTECTED]
>
--
Jon Smirl
[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: v850, which gcc and binutils version?
Jan Dittmer <[EMAIL PROTECTED]> writes: > Which is the recommended gcc/binutils combination for v850? The most crucial thing is that all supported processors are v850e derivatives (note the "e"), so please configure gcc/binutils for target "v850e-elf". [I usually use something bizarre and ancient, which appears to be a NEC local derivative of gcc 2.9, but I've occasionally compiled the kernel with gcc3 and it worked.] -Miles -- "1971 pickup truck; will trade for guns" - 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_64: fix cpu_to_node setup for sparse apic_ids
On Wed, Jul 27, 2005 at 06:24:45PM -0700, Andrew Morton wrote: > Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote: > > > > While booting with SMT disabled in bios, when using acpi srat to setup > > cpu_to_node[], sparse apic_ids create problems. Here's a fix for that. > > > > Again, I don't have enough info here to judge the urgency of this patch. > > What are the consequences and risks of not having this patch in 2.6.13, and > to how many machines? > Without this patch, intel x86_64 boxes with hyperthreading disabled in the bios (and which rely on srat for numa setup) endup having incorrect values in cpu_to_node[] arrays, causing sched domains to be built incorrectly etc. Thanks, Kiran - 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] properly stop devices before poweroff
Kenji Kaneshige <[EMAIL PROTECTED]> wrote: > > After all, I think ia64-halt-hangup-fix.patch should be removed > from -mm tree. yup, I already tested-and-dropped it, thanks. - 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] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable
On Wed, Jul 27, 2005 at 04:17:54PM +0200, Ingo Molnar wrote: > > * Steven Rostedt <[EMAIL PROTECTED]> wrote: > > > The following patch makes the MAX_RT_PRIO and MAX_USER_RT_PRIO > > configurable from the make *config. This is more of a proposal since > > I'm not really sure where in Kconfig this would best fit. I don't see > > why these options shouldn't be user configurable without going into > > the kernel headers to change them. > > i'd not do this patch, mainly because the '100 priority levels' thing is > pretty much an assumption in lots of userspace code. The patch to make > it easier to redefine it is of course fine and was accepted, but i dont > think we want to make it explicit via .config. > > It's a bit like with the 3:1 split: you can redefine it easily via > include files, but it's not configurable via .config, because many > people would just play with it and would see things break. > > so unless there's really a desire from distributions to actually change > the 100 RT-prio levels (and i dont sense such a desire), we shouldnt do > this. The queues take a fairly substantial amount of memory. I've had an option for configuring this under CONFIG_EMBEDDED in the -tiny tree for quite some time. -- Mathematics is the supreme nostalgia of our time. - 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] properly stop devices before poweroff
Hi, I think the patch Tony mentioned (ia64-halt-hangup-fix.patch) was already merged into -mm tree. But as Tony said, it doesn't work and removing reboot notifier of e1000 looks better than changing ia64 version of pcibios_disable_device(). After all, I think ia64-halt-hangup-fix.patch should be removed from -mm tree. Thanks, Kenji Kaneshige Luck, Tony wrote: I started on my OLS homework from Andrew ... and began looking into what is going on here. The story so far: Pavel added calls to device_suspend() to three of the cases in the sys_reboot() path. This stopped ia64 from being able to shutdown. There is a oops with a stacktrace pointing back at the sys_reboot call. Initial analysis from Kenji Kaneshige said that we might fix this by adding a patch to the ia64 version of pcibios_disable_device() to make it check whether the device was enabled before calling acpi_pci_irq_disable(). This might fix things if the issue was simply problems with this being called twice. Pavel sent a "Looks good", Adam said "Is it the right fix?" I just tried it ... it doesn't work, we still see an oops from the sys_reboot() ... so shutdown hangs, and we can sidestep the issue of whether this is ideologically correct. Then I wondered whether it was just an e1000 problem (since Pavel had also commented that we should perhaps removed the reboot notifier from the e1000 driver). So I rebuilt my kernel with e1000 as a module and ran "rmmod e1000" before running shutdown. Which promptly failed with a stack trace that ran through mptscsih driver instead of e1000. [N.B. Kaneshige-san has also noted that his i386 system which has the mptfusion also hangs executing a SYNCHRONIZE_CACHE command]. Code examination in the e1000 case shows that we are a bit confused and call first: notifier_call_chain(reboot_notifier, ...) e1000_notify_reboot(...) e1000_suspend(...) pci_disable_device(...) pci_set_power_state(...) and then: device_suspend(...) suspend_device() == dev->bus->suspend == pci_device_suspend e1000_suspend() pci_disable_device() pciset_power_state() So it looks like Pavel is right ... registering the reboot notifier is bogus in e1000. Commenting out the register/unregister also allows me to get past the e1000 so that I can fail in mptscsih_suspend() path. But the fusion driver doesn't register a reboot notifier, so I can't try the same trick there :-) Andrew: How did you get the squitty font on ia64? The stack trace from the oops flies off the top of the screen. I've tried a few "vga=0x0f07" type options, but I keep getting a big font. -Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12: no sound on SPDIF with emu10k1
On Thu, 2005-07-28 at 03:21 +0200, Thomas Zehetbauer wrote: > On Wed, 2005-07-27 at 16:44 -0400, Lee Revell wrote: > > On Wed, 2005-07-27 at 21:46 +0200, Thomas Zehetbauer wrote: > > > I cannot get my SB Live! 5.1's SPDIF (digital) output to work with > > > kernel > 2.6.12. I have not changed my mixer configuration and it is > > > still working when I boot 2.6.11.12 or earlier. I am using FC4 with > > > alsa-lib-1.0.9rf-2.FC4 installed. > > > > FC4 shipped a buggy ALSA version, I can't believe there are no updated > > RPMs yet. > > > > You need a newer ALSA. > > alsa-lib-1.0.9rf-2 is the latest update available: > http://download.fedora.redhat.com/pub/fedora/linux/core/updates/4/x86_64/alsa-lib-1.0.9rf-2.FC4.x86_64.rpm > > If FC4's ALSA was really broken, I wonder why it is working fine with > kernel 2.6.11.12 and earlier? If upgrading other ALSA packages does not work, see if it works with ALSA CVS (alsa-lib, alsa-utilsm, and alsa-kernel). Also, even though you said you did not change it, check your mixer configuration again - there was a change to that driver that could have caused some users to lose mixer settings (newer versions of alsactl work around it). Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] mm: Ensure proper alignment for node_remap_start_pfn
On Wed, Jul 27, 2005 at 06:17:24PM -0700, Andrew Morton wrote: > Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote: > > > > While reserving KVA for lmem_maps of node, we have to make sure that > > node_remap_start_pfn[] is aligned to a proper pmd boundary. > > (node_remap_start_pfn[] gets its value from node_end_pfn[]) > > > > What are the effects of not having this patch applied? Does someone's > computer crash, or what? Yes, it does cause a crash. Thanks, Kiran - 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.12: no sound on SPDIF with emu10k1
On Thu, 2005-07-28 at 03:21 +0200, Thomas Zehetbauer wrote: > On Wed, 2005-07-27 at 16:44 -0400, Lee Revell wrote: > > On Wed, 2005-07-27 at 21:46 +0200, Thomas Zehetbauer wrote: > > > I cannot get my SB Live! 5.1's SPDIF (digital) output to work with > > > kernel > 2.6.12. I have not changed my mixer configuration and it is > > > still working when I boot 2.6.11.12 or earlier. I am using FC4 with > > > alsa-lib-1.0.9rf-2.FC4 installed. > > > > FC4 shipped a buggy ALSA version, I can't believe there are no updated > > RPMs yet. > > > > You need a newer ALSA. > > alsa-lib-1.0.9rf-2 is the latest update available: You have to update all alsa packages, not just alsa-lib. Lee - 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] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable
On Wed, 2005-07-27 at 18:00 -0700, Daniel Walker wrote: > Don't you break sched_find_first_bit() , seems it's dependent on a > 140-bit bitmap . Oops! I forgot about that. With my custom kernels I had to change this to use the generic find_first_bit routine. It's been a while since I made these changes. So when we really need to have custom settings, we would have to change this. I should have remembered this, since it did cause me couple of days of debugging. Anyway, I never did the measurements, but does anyone know what the performance difference is between find_first_bit and sched_find_first_bit? I guess I'll do it and report back later. This should also be in a comment around changing these settings. Thanks, -- Steve - 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] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable
On Wed, 2005-07-27 at 21:20 -0400, Lee Revell wrote: > On Wed, 2005-07-27 at 18:00 -0700, Daniel Walker wrote: > > Don't you break sched_find_first_bit() , seems it's dependent on a > > 140-bit bitmap . > > And doesn't POSIX specify 100 RT priority levels? My customers don't care about POSIX :-) -- Steve - 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_64: fix cpu_to_node setup for sparse apic_ids
Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
>
> While booting with SMT disabled in bios, when using acpi srat to setup
> cpu_to_node[], sparse apic_ids create problems. Here's a fix for that.
>
Again, I don't have enough info here to judge the urgency of this patch.
What are the consequences and risks of not having this patch in 2.6.13, and
to how many machines?
>
> Index: linux-2.6.13-rc3/arch/x86_64/mm/srat.c
> ===
> --- linux-2.6.13-rc3.orig/arch/x86_64/mm/srat.c 2005-06-17
> 12:48:29.0 -0700
> +++ linux-2.6.13-rc3/arch/x86_64/mm/srat.c2005-07-27 15:36:23.0
> -0700
> @@ -20,6 +20,9 @@
>
> static struct acpi_table_slit *acpi_slit;
>
> +/* Internal processor count */
> +static unsigned int __initdata num_processors = 0;
> +
> static nodemask_t nodes_parsed __initdata;
> static nodemask_t nodes_found __initdata;
> static struct node nodes[MAX_NUMNODES] __initdata;
> @@ -101,16 +104,18 @@
> bad_srat();
> return;
> }
> - if (pa->apic_id >= NR_CPUS) {
> - printk(KERN_ERR "SRAT: lapic %u too large.\n",
> -pa->apic_id);
> + if (num_processors >= NR_CPUS) {
> + printk(KERN_ERR "SRAT: Processor #%d (lapic %u) INVALID. (Max
> ID: %d).\n",
> + num_processors, pa->apic_id, NR_CPUS);
> bad_srat();
> return;
> }
> - cpu_to_node[pa->apic_id] = node;
> + cpu_to_node[num_processors] = node;
> acpi_numa = 1;
> - printk(KERN_INFO "SRAT: PXM %u -> APIC %u -> Node %u\n",
> -pxm, pa->apic_id, node);
> + printk(KERN_INFO "SRAT: PXM %u -> APIC %u -> CPU %u -> Node %u\n",
> +pxm, pa->apic_id, num_processors, node);
> +
> + num_processors++;
> }
>
> /* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
-
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.12: no sound on SPDIF with emu10k1
On Wed, 2005-07-27 at 16:44 -0400, Lee Revell wrote: > On Wed, 2005-07-27 at 21:46 +0200, Thomas Zehetbauer wrote: > > I cannot get my SB Live! 5.1's SPDIF (digital) output to work with > > kernel > 2.6.12. I have not changed my mixer configuration and it is > > still working when I boot 2.6.11.12 or earlier. I am using FC4 with > > alsa-lib-1.0.9rf-2.FC4 installed. > > FC4 shipped a buggy ALSA version, I can't believe there are no updated > RPMs yet. > > You need a newer ALSA. alsa-lib-1.0.9rf-2 is the latest update available: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/4/x86_64/alsa-lib-1.0.9rf-2.FC4.x86_64.rpm If FC4's ALSA was really broken, I wonder why it is working fine with kernel 2.6.11.12 and earlier? Tom -- T h o m a s Z e h e t b a u e r ( TZ251 ) PGP encrypted mail preferred - KeyID 96FFCB89 finger [EMAIL PROTECTED] for key Chaos is the only form of life, order was caused by the Nazis and millions died! signature.asc Description: This is a digitally signed message part
Re: [RFC][PATCH] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable
On Wed, 2005-07-27 at 18:00 -0700, Daniel Walker wrote: > Don't you break sched_find_first_bit() , seems it's dependent on a > 140-bit bitmap . And doesn't POSIX specify 100 RT priority levels? Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] mm: Ensure proper alignment for node_remap_start_pfn
Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
>
> While reserving KVA for lmem_maps of node, we have to make sure that
> node_remap_start_pfn[] is aligned to a proper pmd boundary.
> (node_remap_start_pfn[] gets its value from node_end_pfn[])
>
What are the effects of not having this patch applied? Does someone's
computer crash, or what?
IOW: what problem is this fixing, precisely?
>
> Index: linux-2.6.13-rc3/arch/i386/mm/discontig.c
> ===
> --- linux-2.6.13-rc3.orig/arch/i386/mm/discontig.c2005-07-26
> 15:10:25.0 -0700
> +++ linux-2.6.13-rc3/arch/i386/mm/discontig.c 2005-07-26 16:27:43.0
> -0700
> @@ -243,6 +243,14 @@
> /* now the roundup is correct, convert to PAGE_SIZE pages */
> size = size * PTRS_PER_PTE;
>
> + if (node_end_pfn[nid] & (PTRS_PER_PTE-1)) {
> + /*
> + * Adjust size if node_end_pfn is not on a proper
> + * pmd boundary. remap_numa_kva will barf otherwise.
> + */
> + size += node_end_pfn[nid] & (PTRS_PER_PTE-1);
> + }
> +
> /*
>* Validate the region we are allocating only contains valid
>* pages.
-
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] x86_64: fix cpu_to_node setup for sparse apic_ids
While booting with SMT disabled in bios, when using acpi srat to setup
cpu_to_node[], sparse apic_ids create problems. Here's a fix for that.
Signed-off-by: Ravikiran Thirumalai <[EMAIL PROTECTED]>
Signed-off-by: Shai Fultheim <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc3/arch/x86_64/mm/srat.c
===
--- linux-2.6.13-rc3.orig/arch/x86_64/mm/srat.c 2005-06-17 12:48:29.0
-0700
+++ linux-2.6.13-rc3/arch/x86_64/mm/srat.c 2005-07-27 15:36:23.0
-0700
@@ -20,6 +20,9 @@
static struct acpi_table_slit *acpi_slit;
+/* Internal processor count */
+static unsigned int __initdata num_processors = 0;
+
static nodemask_t nodes_parsed __initdata;
static nodemask_t nodes_found __initdata;
static struct node nodes[MAX_NUMNODES] __initdata;
@@ -101,16 +104,18 @@
bad_srat();
return;
}
- if (pa->apic_id >= NR_CPUS) {
- printk(KERN_ERR "SRAT: lapic %u too large.\n",
- pa->apic_id);
+ if (num_processors >= NR_CPUS) {
+ printk(KERN_ERR "SRAT: Processor #%d (lapic %u) INVALID. (Max
ID: %d).\n",
+ num_processors, pa->apic_id, NR_CPUS);
bad_srat();
return;
}
- cpu_to_node[pa->apic_id] = node;
+ cpu_to_node[num_processors] = node;
acpi_numa = 1;
- printk(KERN_INFO "SRAT: PXM %u -> APIC %u -> Node %u\n",
- pxm, pa->apic_id, node);
+ printk(KERN_INFO "SRAT: PXM %u -> APIC %u -> CPU %u -> Node %u\n",
+ pxm, pa->apic_id, num_processors, node);
+
+ num_processors++;
}
/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
-
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/23] Add missing device_suspsend(PMSG_FREEZE) calls.
Nigel Cunningham <[EMAIL PROTECTED]> writes: > Hi. > > Could you please send PMSG_* related patches to linux-pm at > lists.osdl.org as well? I'll try. My goal was not to add or change not functionality but to make what the kernel was already doing be consistent. It turns out the device_suspend(PMSG_FREEZE) is a major pain sitting in the reboot path and I will be submitting a patch to remove it from the reboot path in 2.6.13 completely. At the very least the ide driver breaks, and the e1000 driver is affected. And there is of course the puzzle of why there exists simultaneously driver shutdown() and suspend(PMSG_FREEZE) methods as I believed they are defined to do exactly the same thing. Eric - 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] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable
Don't you break sched_find_first_bit() , seems it's dependent on a 140-bit bitmap . Daniel On Wed, 2005-07-27 at 10:13 -0400, Steven Rostedt wrote: > The following patch makes the MAX_RT_PRIO and MAX_USER_RT_PRIO > configurable from the make *config. This is more of a proposal since > I'm not really sure where in Kconfig this would best fit. I don't see > why these options shouldn't be user configurable without going into the > kernel headers to change them. > > Also, is there a way in the Kconfig to force the checking of > MAX_USER_RT_PRIO <= MAX_RT_PRIO? > > -- Steve > > (Patched against 2.6.12.2) > > Index: vanilla_kernel/include/linux/sched.h > === > --- vanilla_kernel/include/linux/sched.h (revision 263) > +++ vanilla_kernel/include/linux/sched.h (working copy) > @@ -389,9 +389,13 @@ > * MAX_RT_PRIO must not be smaller than MAX_USER_RT_PRIO. > */ > > -#define MAX_USER_RT_PRIO 100 > -#define MAX_RT_PRIO MAX_USER_RT_PRIO > +#define MAX_USER_RT_PRIO CONFIG_MAX_USER_RT_PRIO > +#define MAX_RT_PRIO CONFIG_MAX_RT_PRIO > > +#if MAX_USER_RT_PRIO > MAX_RT_PRIO > +#error MAX_USER_RT_PRIO must not be greater than MAX_RT_PRIO > +#endif > + > #define MAX_PRIO (MAX_RT_PRIO + 40) > > #define rt_task(p) (unlikely((p)->prio < MAX_RT_PRIO)) > Index: vanilla_kernel/init/Kconfig > === > --- vanilla_kernel/init/Kconfig (revision 263) > +++ vanilla_kernel/init/Kconfig (working copy) > @@ -162,6 +162,32 @@ > building a kernel for install/rescue disks or your system is very > limited in memory. > > +config MAX_RT_PRIO > + int "Maximum RT priority" > + default 100 > + help > + The real-time priority of threads that have the policy of SCHED_FIFO > + or SCHED_RR have a priority higher than normal threads. This range > + can be set here, where the range starts from 0 to MAX_RT_PRIO-1. > + If this range is higher than MAX_USER_RT_PRIO than kernel threads > + may have a higher priority than any user thread. > + > + This may be the same as MAX_USER_RT_PRIO, but do not set this > + to be less than MAX_USER_RT_PRIO. > + > +config MAX_USER_RT_PRIO > + int "Maximum User RT priority" > + default 100 > + help > + The real-time priority of threads that have the policy of SCHED_FIFO > + or SCHED_RR have a priority higher than normal threads. This range > + can be set here, where the range starts from 0 to MAX_USER_RT_PRIO-1. > + If this range is lower than MAX_RT_PRIO, than kernel threads may have > + a higher priority than any user thread. > + > + This may be the same as MAX_RT_PRIO, but do not set this to be > + greater than MAX_RT_PRIO. > + > config AUDIT > bool "Auditing support" > default y if SECURITY_SELINUX > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/6] mm: micro-optimise rmap
Alexander Nyberg wrote: void page_add_anon_rmap(struct page *page, linear_page_index() here too? Hi Alexander, Yes, that's what patch 3/6 did :) -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] mm: Ensure proper alignment for node_remap_start_pfn
While reserving KVA for lmem_maps of node, we have to make sure that
node_remap_start_pfn[] is aligned to a proper pmd boundary.
(node_remap_start_pfn[] gets its value from node_end_pfn[])
Signed-off-by: Ravikiran Thirumalai <[EMAIL PROTECTED]>
Signed-off-by: Shai Fultheim <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc3/arch/i386/mm/discontig.c
===
--- linux-2.6.13-rc3.orig/arch/i386/mm/discontig.c 2005-07-26
15:10:25.0 -0700
+++ linux-2.6.13-rc3/arch/i386/mm/discontig.c 2005-07-26 16:27:43.0
-0700
@@ -243,6 +243,14 @@
/* now the roundup is correct, convert to PAGE_SIZE pages */
size = size * PTRS_PER_PTE;
+ if (node_end_pfn[nid] & (PTRS_PER_PTE-1)) {
+ /*
+* Adjust size if node_end_pfn is not on a proper
+* pmd boundary. remap_numa_kva will barf otherwise.
+*/
+ size += node_end_pfn[nid] & (PTRS_PER_PTE-1);
+ }
+
/*
* Validate the region we are allocating only contains valid
* pages.
-
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: xor as a lazy comparison
On Wed, 27 Jul 2005 15:58:48 -0400, "linux-os \(Dick Johnson\)" <[EMAIL PROTECTED]> wrote: > >I think the XOR thread was started by somebody as a ruse or >a joke. XOR will always destroy the value of an operand. You missed the part where somebody checked assembler output and found compiler optimised xor to cmp as nothing referenced the result. Grant. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] schedule obsolete OSS drivers for removal
On Jul 27 2005, Lee Revell wrote: > On Wed, 2005-07-27 at 01:38 +0200, Zoran Dzelajlija wrote: > > The OSS maestro driver works better on my old Armada E500 laptop. > > I tried ALSA after switching to 2.6, but the computer hung with > > 2.6.8.1 or 2.6.10 if I touched the volume buttons. > > Please test a newer ALSA version, like the one in 2.6.12. I have an Armada V300 laptop that uses the maestro2 chipset (and I wouldn't be surprised if your E500 used that very same chip) and it works fine with the ALSA provided in kernels since the 2.6.10-mm era (actually, I think it worked fine with even earlier kernels, but I am not sure). Just another datapoint, Rogério. -- Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ - 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] pci_find_device --> pci_get_device [only marks deprecation]
On 7/28/05, Jiri Slaby <[EMAIL PROTECTED]> wrote: > On 7/19/05, Rolf Eike Beer <[EMAIL PROTECTED]> wrote: > > Jiri Slaby wrote: > > >* Marks the function as deprecated in pci.h > [it is meant pci_find_device] > > > > This is a very good idea in my eyes. > > 2.6.13-rc3-mm2 > > Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> > > diff --git a/include/linux/pci.h b/include/linux/pci.h > --- a/include/linux/pci.h > +++ b/include/linux/pci.h > @@ -754,7 +754,7 @@ void pci_setup_cardbus(struct pci_bus *b > > /* Generic PCI functions exported to card drivers */ > > -struct pci_dev *pci_find_device (unsigned int vendor, unsigned int device, > const struct pci_dev *from); > +struct pci_dev *pci_find_device (unsigned int vendor, unsigned int device, > const struct pci_dev *from) __deprecated; > struct pci_dev *pci_find_device_reverse (unsigned int vendor, unsigned int > device, const struct pci_dev *from); > struct pci_dev *pci_find_slot (unsigned int bus, unsigned int devfn); > int pci_find_capability (struct pci_dev *dev, int cap); Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> There are some additional spaces in the text patch, so repost with an attachement. lnx-pci_find-depr-6.13r3m2.patch Description: Binary data
Re: [2.6 patch] NETCONSOLE must depend on INET
From: Matt Mackall <[EMAIL PROTECTED]> Date: Tue, 26 Jul 2005 19:36:37 -0700 > # HG changeset patch > # User [EMAIL PROTECTED] > # Node ID 6cdd6f36d53678a016cfbf5ce667cbd91504d538 > # Parent 75716ae25f9d87ee2a5ef7c4df2d8f86e0f3f762 > Move in_aton from net/ipv4/utils.c to net/core/utils.c This patch doesn't apply, in the current 2.6.x GIT tree NETCONSOLE does not depend on NETDEVICES. Please fix up this patch so that I can apply it. Thanks. - 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] qla2xxx: mark dependency on FW_LOADER
Jindrich spotted this 10 days ago, but it seems to have fallen through the cracks. qla_init.c uses request_firmware/release_firmware ... so make sure that our kernel is configured to provide them if qla2xxx is included. Signed-off-by: Tony Luck <[EMAIL PROTECTED]> --- diff --git a/drivers/scsi/qla2xxx/Kconfig b/drivers/scsi/qla2xxx/Kconfig --- a/drivers/scsi/qla2xxx/Kconfig +++ b/drivers/scsi/qla2xxx/Kconfig @@ -3,6 +3,7 @@ config SCSI_QLA2XXX default (SCSI && PCI) depends on SCSI && PCI select SCSI_FC_ATTRS + select FW_LOADER config SCSI_QLA21XX tristate "QLogic ISP2100 host adapter family support" - 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] jfs update
On Wed, 27 Jul 2005, Dave Kleikamp wrote: > > Linus, please pull from > > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/shaggy/jfs-2.6.git/HEAD-for-linus Please use the format "repo branch" in your pull requests, ie since the real branch is called "for-linus", just say rsync://rsync.kernel.org/pub/scm/linux/kernel/git/shaggy/jfs-2.6.git for-linus which ends up being the syntax I have to use anyway ;) Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pci_find_device --> pci_get_device [only marks deprecation]
On 7/19/05, Rolf Eike Beer <[EMAIL PROTECTED]> wrote: Jiri Slaby wrote: >* Marks the function as deprecated in pci.h [it is meant pci_find_device] This is a very good idea in my eyes. 2.6.13-rc3-mm2 Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> diff --git a/include/linux/pci.h b/include/linux/pci.h --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -754,7 +754,7 @@ void pci_setup_cardbus(struct pci_bus *b /* Generic PCI functions exported to card drivers */ -struct pci_dev *pci_find_device (unsigned int vendor, unsigned int device, const struct pci_dev *from); +struct pci_dev *pci_find_device (unsigned int vendor, unsigned int device, const struct pci_dev *from) __deprecated; struct pci_dev *pci_find_device_reverse (unsigned int vendor, unsigned int device, const struct pci_dev *from); struct pci_dev *pci_find_slot (unsigned int bus, unsigned int devfn); int pci_find_capability (struct pci_dev *dev, int cap); - 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: ACPI buttons in 2.6.12-rc4-mm2
>> I'm open to suggestions on how to approach this transition. >> I can make ACPI_PROC a static build option -- what else >> can I do to ease the transition in this, our stable release? > >Well I don't know how awkward this would be from an >implementation POV, but can we just leave the legacy >/proc stuff there until the /sys interface is >all in place and userspace is upgraded? >Then kill all the /proc stuff later? > >We could also print a rude message the first time someone >tries to use a deprecated /proc file, just to help push the >userspace tool developers along. >Although I note that sys_bdflush() is still with us ;) /proc/acpi/event /proc/acpi/sleep are used the most. /proc/acpi///* are really screwed up in that is an arbitrary internal BIOS string that should have never been exposed to userspace. Instead we should have done what sysfs does -- look at the _type_ of device and then simply add a number to it -- cpu0, cpu1 so that a program could actually find stuff. I'm constantly nagged that this layer in the /proc/tree had arbitrary strings in pathnames. Also, the /proc file handling code is buggy -- so it wastes my time maintaining it, when it should not exist at all... Restoring the /proc code to the button driver will increase button.c in size by over 60%... So I'm in favor of whatever solution makes it all go away as soon as possible. -Len - 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] signed char fixes for scripts
On 07.27, Sam Ravnborg wrote:
> On Fri, Jul 15, 2005 at 10:14:43PM +, J.A. Magallon wrote:
> >
> > On 07.16, J.A. Magallon wrote:
> > >
> > > On 07.15, Andrew Morton wrote:
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
> > > >
> >
> > This time I did not break anything... and they shut up gcc4 ;)
>
> I have applied it to my tree. There still is a lot left when I compile
> with -Wsign-compare.
>
All the problems are born here:
struct sym_entry {
unsigned long long addr;
unsigned int len;
unsigned char *sym;
};
I suppose you want sym to be an unsigned char to store the type and to do
the checksum math in there.
And why use a 64bit address in 32bit archs ?. There is no math involved
with 'addr', so you can make it a pointer and let the compiler decide its
size.
Why don't you do something like:
struct sym_entry {
void*addr;
unsigned char type;
unsigned short len;
union {
unsigned char data[KSYM_NAME_LEN+1];
charname[KSYM_NAME_LEN+1];
};
};
Option b) is identify the five lines that do the checksum math and plague
them with (unsigned char) casts...
Will try to do it...
--
J.A. Magallon \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.12-jam10 (gcc 4.0.1 (4.0.1-0.2mdk for Mandriva Linux release 2006.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 00/14] ppc32: Remove board ports that are no longer maintained
On Jul 27, 2005, at 12:15 PM, Matt Porter wrote: On Wed, Jul 27, 2005 at 09:27:41AM -0700, Eugene Surovegin wrote: On Wed, Jul 27, 2005 at 12:13:23PM -0400, Michael Richardson wrote: Kumar, I thought that we had some volunteers to take care of some of those. I know that I still care about ep405, and I'm willing to maintain the code. Well, it has been almost two months since Kumar asked about maintenance for this board. Nothing happened since then. Why is it not fixed yet? Please, send a patch which fixes it. This is the _best_ way to keep this board in the tree, not some empty maintenance _promises_. When we recover our history from the linuxppc-2.4/2.5 trees we can show exactly how long it's been since anybody touched ep405. Quick googling shows that it's been almost 2 years since the last mention of ep405 (exluding removal discussions) on linuxppc-embedded. Last ep405-related commits are more than 2 years ago. So we are ok with it being removed. This seems to be the only board port that I removed that has caused any noise. - kumar - 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 00/14] ppc32: Remove board ports that are no longer maintained
On Jul 27, 2005, at 2:57 PM, Andrew Morton wrote: Kumar Gala <[EMAIL PROTECTED]> wrote: The following board ports are no longer maintained or have become obsolete: adir ash beech cedar ep405 k2 mcpn765 menf1 oak pcore rainier redwood sm850 spd823ts We are there for removing support for them. I'll merge all these into -mm for now, but will hold off sending any of them upstream pending confirmation of which patches we really want to proceed with. Sounds good. We will get to some resolution on the ep405 which seems the be the only system that people are making noise on today. - kumar - 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/3] ppc32: add 440ep support
Paul Mackerras <[EMAIL PROTECTED]> wrote: > > Andrew Morton writes: > > > Matt Porter <[EMAIL PROTECTED]> wrote: > > > > > > +static u64 dma_mask = 0xULL; > > > > I'm sure you're totally uninterested in this, but the above will probably > > generate warnings on (say) ppc64, where u64 is implemented as unsigned > > long. > > > > I usually chuck a simple `-1' in there and the compiler always gets it > > right, regardless of signedness and size and architecture. > > Umm, I think we actually want 2^32-1 not -1, don't we? Doh. Cant coun't. - 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: ACPI buttons in 2.6.12-rc4-mm2
>Len Brown <[EMAIL PROTECTED]> wrote: >> I deleted /proc/acpi/button on purpose, >> did you have a use for those files? > >Can we put it back, please? of course. >We cannot go ripping out stuff which applications and users >are currently using without quite a lot of preparation. Agreed. Although the implementation of the /proc lid status file is fundamentally flawed in that even its name in /proc is able to change and thus it is a totally bogus user-space API, it was not thoughtful to delete it. I'm open to suggestions on how to approach this transition. I can make ACPI_PROC a static build option -- what else can I do to ease the transition in this, our stable release? thanks, -Len - 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 patch] schedule obsolete OSS drivers for removal
On Wed, 2005-07-27 at 01:38 +0200, Zoran Dzelajlija wrote: > The OSS maestro driver works better on my old Armada E500 laptop. I tried > ALSA after switching to 2.6, but the computer hung with 2.6.8.1 or 2.6.10 if > I touched the volume buttons. Please test a newer ALSA version, like the one in 2.6.12. Lee - 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: ACPI buttons in 2.6.12-rc4-mm2
"Brown, Len" <[EMAIL PROTECTED]> wrote: > > > >Len Brown <[EMAIL PROTECTED]> wrote: > >> I deleted /proc/acpi/button on purpose, > >> did you have a use for those files? > > > >Can we put it back, please? > > of course. Thanks. > >We cannot go ripping out stuff which applications and users > >are currently using without quite a lot of preparation. > > Agreed. Although the implementation of the /proc lid status > file is fundamentally flawed in that even its name in /proc > is able to change and thus it is a totally bogus user-space API, > it was not thoughtful to delete it. > > I'm open to suggestions on how to approach this transition. > I can make ACPI_PROC a static build option -- what else > can I do to ease the transition in this, our stable release? Well I don't know how awkward this would be from an implementation POV, but can we just leave the legacy /proc stuff there until the /sys interface is all in place and userspace is upgraded? Then kill all the /proc stuff later? We could also print a rude message the first time someone tries to use a deprecated /proc file, just to help push the userspace tool developers along. Although I note that sys_bdflush() is still with us ;) - 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: Add prefetch switch stack hook in scheduler function
Also, should this be called prefetch_stack() or perhaps even just
prefetch_task()? Not every architecture defines a switch_stack
structure.
--david
--
Mosberger Consulting LLC, voice/fax: 510-744-9372,
http://www.mosberger-consulting.com/
35706 Runckel Lane, Fremont, CA 94536
On 7/27/05, Andrew Morton <[EMAIL PROTECTED]> wrote:
> "Chen, Kenneth W" <[EMAIL PROTECTED]> wrote:
> >
> > +#ifdef ARCH_HAS_PREFETCH_SWITCH_STACK
> > +extern void prefetch_switch_stack(struct task_struct*);
> > +#else
> > +#define prefetch_switch_stack(task) do { } while (0)
> > +#endif
>
> It is better to use
>
> static inline void prefetch_switch_stack(struct task_struct *t) { }
>
> in the second case, rather than a macro. It provides typechecking.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.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 0/23] reboot-fixes
Pavel Machek <[EMAIL PROTECTED]> writes: > Hi! > >> > Yes, I think we should do device_suspend(PMSG_FREEZE) in reboot path. >> >> Considering how many device drivers that are likely broken, I disagree. >> Especially since Andrew seems to have trivially found a machine where it >> doesn't work. > > I'm not sure if we want to do that for 2.6.13, but long term, we > should just tell drivers to FREEZE instead of inventing reboot > notifier lists and similar uglynesses... Then as part of the patch device_shutdown should disappear. It is silly to have two functions that want to achieve the same thing. Right now the device driver model is ugly and over complicated in that case and it needs to be simplified so driver writers have a chance of getting it correct. device_suspend(PMSG_FREEZE) feels more reusable than device_shutdown so long term it feels right. But a simple question is why can't you simply use the shutdown method instead of extending the suspend method in the drivers. Eric - 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: driver for Marvell 88E8053 PCI Express Gigabit LAN
Alexander Fieroch wrote: http://dlsvr01.asus.com/pub/ASUS/lan/marvell/8053/8053_others2.zip Oh, that driver is very old. Here is the latest one which is working with the current kernel: http://www.syskonnect.de/syskonnect/support/driver/htm/sk9elin.htm Could you please integrate it to the kernel? Regards, Alexander - 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: system freezes for 0.2 to 0.5 seconds when reading /proc/acpi/thermal_zone/THRM/temperature
Florian Engelhardt <[EMAIL PROTECTED]> wrote: > > Hello, > > first of all, sorry for the long headline. > second: > Every time, i try to do the following: > cat /proc/acpi/thermal_zone/THRM/temperature > the whole system looks up for a short period of time (something about > 0.5s). realy everything, video and audio encoding, mouse and keyboard > input, firefox playing a flash animation, ... > I am also getting the following: > Losing some ticks... checking if CPU frequency changed. > > maybe these two things are belonging to each other. > > I am using a 2.6.12-rc3-mm1 kernel on a amd64 with a nvidia nforce4 > mainboard. It might help if you were to generate a kernel profile: readprofile -r for i in $(seq 10) do cat /proc/acpi/thermal_zone/THRM/temperature done readprofile -n -v -m /boot/System.map | sort -n +2 | tail -40 - 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: Add prefetch switch stack hook in scheduler function
"Chen, Kenneth W" <[EMAIL PROTECTED]> wrote:
>
> +#ifdef ARCH_HAS_PREFETCH_SWITCH_STACK
> +extern void prefetch_switch_stack(struct task_struct*);
> +#else
> +#define prefetch_switch_stack(task) do { } while (0)
> +#endif
It is better to use
static inline void prefetch_switch_stack(struct task_struct *t) { }
in the second case, rather than a macro. It provides typechecking.
-
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: [ck] 2.6.12-ck4
On 7/27/05, Con Kolivas <[EMAIL PROTECTED]> wrote: > Changes since 2.6.12-ck3: > > Added: > +s11.3_s11.4.diff > Staircase cpu scheduler update. Change rr intervals to 5ms minimum. With > interbench I can confidently say there is objective evidence of interactive > improvement in the human perceptible range with this change :) > Excellent :) > HZ-864.diff > +My take on the never ending config HZ debate. Apart from the number not being > pleasing on the eyes, a HZ value that isn't a multiple of 10 is perfectly > valid. Setting HZ to 864 gives us very similar low latency performance to a > 1000HZ kernel, decreases overhead ever so slightly, and minimises clock drift > substantially. The -server patch uses HZ=82 for similar reasons, with the > emphasis on throughput rather than low latency. Madness? Probably, but then I > can't see any valid argument against using these values. > I recently built the new release. Sadly, this particular change results in my machine performing a hard reset during boot :( Thus far, I've confirmed that changing the HZ value back to 1000 resolves the issue and I'm now up and running. So it's not the end of the world but I would like to know which area of the kernel is falling foul of this change. I'm concerned that others might be affected. I'll see if I can establish a clearer picture of what seems to be going wrong here. Maybe it would be a good idea to allow the user to change this if needs be? The patch below allows for this (assuming gmail does not mangle it), provided that experimental config options are enabled and only on the x86, ppc64 and x86_64 architectures. --- linux-2.6.12-ck4.orig/init/Kconfig 2005-06-17 20:48:29.0 +0100 +++ linux-2.6.12-ck4/init/Kconfig 2005-07-28 00:52:12.0 +0100 @@ -77,6 +77,26 @@ object and source tree, in that order. Your total string can be a maximum of 64 characters. +config HERTZ + int "HZ timer (interrupts per second)" + depends on EXPERIMENTAL && (X86 || PPC64 || X86_64) + range 10 2000 + default 864 + ---help--- + This option configures the timer interrupt rate. The value in the + mainline kernel is 1000. In -ck kernels the default is 864 which + maintains favourable latencies whilst decreasing overhead slightly + and helping to minimise clock drift substantially. + + In general, reducing this value results in lower scheduling + granularity with higher throughput whereas increasing it results in + higher scheduling granularity with lower throughput. Servers may be + happier with a lower value such as 100. Setting a lower value can + also help to alleviate issues with some laptops and to increase + battery life. + + If unsure then do not alter this value. + config SWAP bool "Support for paging of anonymous memory (swap)" depends on MMU --- linux-2.6.12-ck4.orig/include/asm-i386/param.h 2005-07-27 23:38:04.0 +0100 +++ linux-2.6.12-ck4/include/asm-i386/param.h 2005-07-28 00:53:31.0 +0100 @@ -2,7 +2,7 @@ #define _ASMi386_PARAM_H #ifdef __KERNEL__ -# define HZ1000/* Internal kernel timer frequency */ +# define HZCONFIG_HERTZ/* Internal kernel timer frequency */ # define USER_HZ 100 /* .. some user interfaces are in "ticks" */ # define CLOCKS_PER_SEC(USER_HZ) /* like times() */ #endif --- linux-2.6.12-ck4.orig/include/asm-ppc64/param.h 2005-07-27 21:23:27.0 +0100 +++ linux-2.6.12-ck4/include/asm-ppc64/param.h 2005-07-28 00:57:40.0 +0100 @@ -9,7 +9,7 @@ */ #ifdef __KERNEL__ -# define HZ864 /* Internal kernel timer frequency */ +# define HZCONFIG_HERTZ/* Internal kernel timer frequency */ # define USER_HZ 100 /* .. some user interfaces are in "ticks" */ # define CLOCKS_PER_SEC(USER_HZ) /* like times() */ #endif --- linux-2.6.12-ck4.orig/include/asm-x86_64/param.h2005-07-27 21:23:27.0 +0100 +++ linux-2.6.12-ck4/include/asm-x86_64/param.h 2005-07-28 00:57:58.0 +0100 @@ -2,7 +2,7 @@ #define _ASMx86_64_PARAM_H #ifdef __KERNEL__ -# define HZ864 /* Internal kernel timer frequency */ +# define HZCONFIG_HERTZ /* Internal kernel timer frequency */ # define USER_HZ 100 /* .. some user interfaces are in "ticks */ #define CLOCKS_PER_SEC(USER_HZ) /* like times() */ #endif Cheers, --Kerin - 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: ACPI buttons in 2.6.12-rc4-mm2
Len Brown <[EMAIL PROTECTED]> wrote: > > On Sun, 2005-05-22 at 07:25 -0400, Cameron Harris wrote: > > I just upgraded from 2.6.11.3 and now my /proc/acpi/button directory > > doesn't exist... > > I deleted /proc/acpi/button on purpose, > did you have a use for those files? Can we put it back, please? > Note that over time everything in /proc/acpi is > going away. In this case, there didn't seem to be > a case for making appear in /sys. That'll be hard. I guess we could add the new /sys entries, make sure that userspace tool developers have migrated and then remove the /proc entries in a year or so. We cannot go ripping out stuff which applications and users are currently using without quite a lot of preparation. - 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/23] reboot-fixes
Pavel Machek <[EMAIL PROTECTED]> writes: > Hi! > > Yes, I think we should do device_suspend(PMSG_FREEZE) in reboot path. > >> My gut feel is the device_suspend calls are the right direction >> as it allows us to remove code from the drivers and possible >> kill device_shutdown completely. >> >> But this close to 2.6.13 I'm not certain what the correct solution >> is. With this we have had issues with both ide and the e1000. >> But those are among the few drivers that do anything in either >> device_shutdown() or the reboot_notifier. > .. >> Looking at it more closely the code is confusing because >> FREEZE and SUSPEND are actually the same message, and in >> addition to what shutdown does they place the device in > > Not in -mm; I was finally able to fix that one. Cool. >> My gut feel is that device_suspend(PMSG_FREEZE) should be >> removed from kernel_restart until is a different message >> from PMSG_SUSPEND at which point it should be equivalent >> to device_shutdown and we can remove that case. > > PMSG_FREEZE != PMSG_SUSPEND in current -mm, but I'm not sure if we can > push that to 2.6.13... Currently device_suspend(PMSG_FREEZE) in the reboot path breaks the e1000 and the ide driver. Which is common enough hardware it effectively breaks reboots in 2.6.13 despite the fact that nearly everything thing else works. To make device_suspend(PMSG_FREEZE) solid in the reboot path I think it would take pushing and stabilizing all of PMSG_FREEZE != PMSG_SUSPEND. It will certainly take a bunch of digging to make certain reboots keep working. Since the number of drivers that implement either a reboot notifier or a shutdown method is small the it is conceivable we could track down all of the serious issues before 2.6.13. However I'm not ready to take point on the bug hunt. So unless you are really ambitious I'd like to take device_suspend(PMSG_FREEZE) out of the reboot path for 2.6.13, put in -mm where people can bang on it for a bit and see that it is coming and delay the merge with the stable branch until the bugs with common hardware have been sorted out. Eric - 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/23] reboot-fixes
Pavel Machek <[EMAIL PROTECTED]> wrote: > > > Good question. I'm not certain if Pavel intended to add > > device_suspend(PMSG_FREEZE) to the reboot path. It was > > there in only one instance. Pavel comments talk only about > > the suspend path. > > Yes, I think we should do device_suspend(PMSG_FREEZE) in reboot path. Why? - 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: sis190 driver
[bouncing @sis.com address removed from the Cc:] Lars Vahlenberg <[EMAIL PROTECTED]> : [...] > I can get mii-tool to work with this patch, but if I have > a ping command running and changing to another speed I > stop receiving or get 1 - 3 sek pings. ei x000ms. The current SiS driver is way more readable than the previous version but I still have not finished to revamp its mii/phy init sequence: - it's a bit ad hoc; - it duplicates code here and there (see link timer and mii/phy init); - imnsho, it tries to achieve too much work in the pci probe phase; - it mostly ignores what is available in include/linux/mii.h and drivers/net/mii.c. Expect something to test before the end of the week. -- Ueimor - 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/3] ppc32: add 440ep support
Andrew Morton writes: > Matt Porter <[EMAIL PROTECTED]> wrote: > > > > +static u64 dma_mask = 0xULL; > > I'm sure you're totally uninterested in this, but the above will probably > generate warnings on (say) ppc64, where u64 is implemented as unsigned > long. > > I usually chuck a simple `-1' in there and the compiler always gets it > right, regardless of signedness and size and architecture. Umm, I think we actually want 2^32-1 not -1, don't we? In which case I think Matt's code is what we have to have. I tried a little test compile with gcc 4.0 with -m64 -Wall and it didn't generate a warning with the 0xULL constant. Paul. - 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] PNP: consolidate kmalloc wrappers
ISAPNP, PNPBIOS, and PNPACPI all had their own kmalloc wrappers that
reimplemented kcalloc(). Remove the wrappers and just use kcalloc()
directly.
Note that this also removes the PNPBIOS error message when the kmalloc
fails.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work/drivers/pnp/isapnp/core.c
===
--- work.orig/drivers/pnp/isapnp/core.c 2005-07-25 15:04:26.0 -0600
+++ work/drivers/pnp/isapnp/core.c 2005-07-27 13:28:09.0 -0600
@@ -142,17 +142,6 @@
isapnp_write_byte(idx+1, val);
}
-static void *isapnp_alloc(long size)
-{
- void *result;
-
- result = kmalloc(size, GFP_KERNEL);
- if (!result)
- return NULL;
- memset(result, 0, size);
- return result;
-}
-
static void isapnp_key(void)
{
unsigned char code = 0x6a, msb;
@@ -406,7 +395,7 @@
struct pnp_id * id;
if (!dev)
return;
- id = isapnp_alloc(sizeof(struct pnp_id));
+ id = kcalloc(1, sizeof(struct pnp_id), GFP_KERNEL);
if (!id)
return;
sprintf(id->id, "%c%c%c%x%x%x%x",
@@ -430,7 +419,7 @@
struct pnp_dev *dev;
isapnp_peek(tmp, size);
- dev = isapnp_alloc(sizeof(struct pnp_dev));
+ dev = kcalloc(1, sizeof(struct pnp_dev), GFP_KERNEL);
if (!dev)
return NULL;
dev->number = number;
@@ -461,7 +450,7 @@
unsigned long bits;
isapnp_peek(tmp, size);
- irq = isapnp_alloc(sizeof(struct pnp_irq));
+ irq = kcalloc(1, sizeof(struct pnp_irq), GFP_KERNEL);
if (!irq)
return;
bits = (tmp[1] << 8) | tmp[0];
@@ -485,7 +474,7 @@
struct pnp_dma *dma;
isapnp_peek(tmp, size);
- dma = isapnp_alloc(sizeof(struct pnp_dma));
+ dma = kcalloc(1, sizeof(struct pnp_dma), GFP_KERNEL);
if (!dma)
return;
dma->map = tmp[0];
@@ -505,7 +494,7 @@
struct pnp_port *port;
isapnp_peek(tmp, size);
- port = isapnp_alloc(sizeof(struct pnp_port));
+ port = kcalloc(1, sizeof(struct pnp_port), GFP_KERNEL);
if (!port)
return;
port->min = (tmp[2] << 8) | tmp[1];
@@ -528,7 +517,7 @@
struct pnp_port *port;
isapnp_peek(tmp, size);
- port = isapnp_alloc(sizeof(struct pnp_port));
+ port = kcalloc(1, sizeof(struct pnp_port), GFP_KERNEL);
if (!port)
return;
port->min = port->max = (tmp[1] << 8) | tmp[0];
@@ -550,7 +539,7 @@
struct pnp_mem *mem;
isapnp_peek(tmp, size);
- mem = isapnp_alloc(sizeof(struct pnp_mem));
+ mem = kcalloc(1, sizeof(struct pnp_mem), GFP_KERNEL);
if (!mem)
return;
mem->min = ((tmp[2] << 8) | tmp[1]) << 8;
@@ -573,7 +562,7 @@
struct pnp_mem *mem;
isapnp_peek(tmp, size);
- mem = isapnp_alloc(sizeof(struct pnp_mem));
+ mem = kcalloc(1, sizeof(struct pnp_mem), GFP_KERNEL);
if (!mem)
return;
mem->min = (tmp[4] << 24) | (tmp[3] << 16) | (tmp[2] << 8) | tmp[1];
@@ -595,7 +584,7 @@
struct pnp_mem *mem;
isapnp_peek(tmp, size);
- mem = isapnp_alloc(sizeof(struct pnp_mem));
+ mem = kcalloc(1, sizeof(struct pnp_mem), GFP_KERNEL);
if (!mem)
return;
mem->min = mem->max = (tmp[4] << 24) | (tmp[3] << 16) | (tmp[2] << 8) |
tmp[1];
@@ -838,7 +827,7 @@
static void isapnp_parse_card_id(struct pnp_card * card, unsigned short
vendor, unsigned short device)
{
- struct pnp_id * id = isapnp_alloc(sizeof(struct pnp_id));
+ struct pnp_id * id = kcalloc(1, sizeof(struct pnp_id), GFP_KERNEL);
if (!id)
return;
sprintf(id->id, "%c%c%c%x%x%x%x",
@@ -874,7 +863,7 @@
header[4], header[5], header[6], header[7], header[8]);
printk(KERN_DEBUG "checksum = 0x%x\n", checksum);
#endif
- if ((card = isapnp_alloc(sizeof(struct pnp_card))) == NULL)
+ if ((card = kcalloc(1, sizeof(struct pnp_card), GFP_KERNEL)) ==
NULL)
continue;
card->number = csn;
Index: work/drivers/pnp/pnpacpi/core.c
===
--- work.orig/drivers/pnp/pnpacpi/core.c2005-07-27 10:43:37.0
-0600
+++ work/drivers/pnp/pnpacpi/core.c 2005-07-27 13:28:33.0 -0600
@@ -41,15 +41,6 @@
return (!acpi_match_ids(dev, excluded_id_list));
}
-void *pnpacpi_kmalloc(size_t size, int f)
-{
- void *p = kmalloc(size, f);
-
- if (p)
- memset(p, 0, size);
- return p;
-}
-
/*
* Compatible Device IDs
*/
@@ -146,7 +137,7 @@
return 0;
pnp_dbg("ACPI device : hid %s", acpi_device_hid(device));
- dev = pnpacpi_kmalloc(sizeof(struct pnp_dev), GFP_K
Re: [PATCH 0/23] reboot-fixes
Hi! > > > Good question. I'm not certain if Pavel intended to add > > > device_suspend(PMSG_FREEZE) to the reboot path. It was > > > there in only one instance. Pavel comments talk only about > > > the suspend path. > > > > Yes, I think we should do device_suspend(PMSG_FREEZE) in reboot path. > > Why? Many bioses are broken; if you leave hardware active during reboot, they'll hang during reboot. It is so common problem that I think that only sane solution is make hardware quiet before reboot. Pavel -- teflon -- maybe it is a trademark, but it should not be. - 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/23] reboot-fixes
Hi! > > Yes, I think we should do device_suspend(PMSG_FREEZE) in reboot path. > > Considering how many device drivers that are likely broken, I disagree. > Especially since Andrew seems to have trivially found a machine where it > doesn't work. I'm not sure if we want to do that for 2.6.13, but long term, we should just tell drivers to FREEZE instead of inventing reboot notifier lists and similar uglynesses... Pavel -- teflon -- maybe it is a trademark, but it should not be. - 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/23] reboot-fixes
On Thu, 28 Jul 2005, Pavel Machek wrote: > > Yes, I think we should do device_suspend(PMSG_FREEZE) in reboot path. Considering how many device drivers that are likely broken, I disagree. Especially since Andrew seems to have trivially found a machine where it doesn't work. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/23] reboot-fixes
Hi!
> >> > My fairly ordinary x86 test box gets stuck during reboot on the
> >> > wait_for_completion() in ide_do_drive_cmd():
> >>
> >> Hmm. The only thing I can think of is someone started adding calls
> >> to device_suspend() before device_shutdown(). Not understanding
> >> where it was a good idea I made certain the calls were in there
> >> consistently.
> >>
> >> Andrew can you remove the call to device_suspend from kernel_restart
> >> and see if this still happens?
> >
> > yup, that fixes it.
> >
> > --- devel/kernel/sys.c~a2005-07-27 10:36:06.0 -0700
> > +++ devel-akpm/kernel/sys.c 2005-07-27 10:36:26.0 -0700
> > @@ -371,7 +371,6 @@ void kernel_restart(char *cmd)
> > {
> > notifier_call_chain(&reboot_notifier_list, SYS_RESTART, cmd);
> > system_state = SYSTEM_RESTART;
> > - device_suspend(PMSG_FREEZE);
> > device_shutdown();
> > if (!cmd) {
> > printk(KERN_EMERG "Restarting system.\n");
> > _
> >
> >
> > Presumably it unfixes Pavel's patch?
>
> Good question. I'm not certain if Pavel intended to add
> device_suspend(PMSG_FREEZE) to the reboot path. It was
> there in only one instance. Pavel comments talk only about
> the suspend path.
Yes, I think we should do device_suspend(PMSG_FREEZE) in reboot path.
> My gut feel is the device_suspend calls are the right direction
> as it allows us to remove code from the drivers and possible
> kill device_shutdown completely.
>
> But this close to 2.6.13 I'm not certain what the correct solution
> is. With this we have had issues with both ide and the e1000.
> But those are among the few drivers that do anything in either
> device_shutdown() or the reboot_notifier.
..
> Looking at it more closely the code is confusing because
> FREEZE and SUSPEND are actually the same message, and in
> addition to what shutdown does they place the device in
Not in -mm; I was finally able to fix that one.
> My gut feel is that device_suspend(PMSG_FREEZE) should be
> removed from kernel_restart until is a different message
> from PMSG_SUSPEND at which point it should be equivalent
> to device_shutdown and we can remove that case.
PMSG_FREEZE != PMSG_SUSPEND in current -mm, but I'm not sure if we can
push that to 2.6.13...
Pavel
--
teflon -- maybe it is a trademark, but it should not be.
-
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] SERIAL: add MMIO support to 8250_pnp
Add support for UARTs in MMIO space and clean up a little whitespace.
HP legacy-free ia64 machines need this.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work/drivers/serial/8250_pnp.c
===
--- work.orig/drivers/serial/8250_pnp.c 2005-07-27 09:57:10.0 -0600
+++ work/drivers/serial/8250_pnp.c 2005-07-27 10:07:09.0 -0600
@@ -394,7 +394,7 @@
}
static int __devinit
-serial_pnp_probe(struct pnp_dev * dev, const struct pnp_device_id *dev_id)
+serial_pnp_probe(struct pnp_dev *dev, const struct pnp_device_id *dev_id)
{
struct uart_port port;
int ret, line, flags = dev_id->driver_data;
@@ -406,15 +406,23 @@
}
memset(&port, 0, sizeof(struct uart_port));
- port.irq = pnp_irq(dev,0);
- port.iobase = pnp_port_start(dev, 0);
+ port.irq = pnp_irq(dev, 0);
+ if (pnp_port_valid(dev, 0)) {
+ port.iobase = pnp_port_start(dev, 0);
+ port.iotype = UPIO_PORT;
+ } else if (pnp_mem_valid(dev, 0)) {
+ port.mapbase = pnp_mem_start(dev, 0);
+ port.iotype = UPIO_MEM;
+ port.flags = UPF_IOREMAP;
+ } else
+ return -ENODEV;
#ifdef SERIAL_DEBUG_PNP
- printk("Setup PNP port: port %x, irq %d, type %d\n",
- port.iobase, port.irq, port.iotype);
+ printk("Setup PNP port: port %x, mem 0x%lx, irq %d, type %d\n",
+ port.iobase, port.mapbase, port.irq, port.iotype);
#endif
- port.flags = UPF_SKIP_TEST | UPF_BOOT_AUTOCONF;
+ port.flags |= UPF_SKIP_TEST | UPF_BOOT_AUTOCONF;
port.uartclk = 1843200;
port.dev = &dev->dev;
@@ -426,7 +434,7 @@
}
-static void __devexit serial_pnp_remove(struct pnp_dev * dev)
+static void __devexit serial_pnp_remove(struct pnp_dev *dev)
{
long line = (long)pnp_get_drvdata(dev);
if (line)
-
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] signed char fixes for scripts
On Fri, Jul 15, 2005 at 10:14:43PM +, J.A. Magallon wrote: > > On 07.16, J.A. Magallon wrote: > > > > On 07.15, Andrew Morton wrote: > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/ > > > > > This time I did not break anything... and they shut up gcc4 ;) I have applied it to my tree. There still is a lot left when I compile with -Wsign-compare. Sam - 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: Build error in Kernel 2.6.13-rc3 git current
On Wed, 27 Jul 2005 at 08:49:03 +0200, Michael Berger wrote:
> I would like to report following build error in Kernel 2.6.13-rc3 git
> current:
>
>gcc -m32 -Wp,-MD,init/.do_mounts_initrd.o.d -nostdinc -isystem
> /usr/lib/gcc-lib/i486-linux/3.3.5/include -D__KERNEL__ -Iinclude -Wall
> -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
> -ffreestanding -O2 -fomit-frame-pointer -pipe -msoft-float
> -mpreferred-stack-boundary=2 -march=i686 -mregparm=3
> -Iinclude/asm-i386/mach-default -DKBUILD_BASENAME=do_mounts_initrd
> -DKBUILD_MODNAME=mounts -c -o init/do_mounts_initrd.o
> init/do_mounts_initrd.c
> In file included from include/asm/unistd.h:426,
> from include/linux/unistd.h:9,
> from init/do_mounts_initrd.c:2:
> include/asm/ptrace.h: In function `user_mode_vm':
> include/asm/ptrace.h:67: error: `VM_MASK' undeclared (first use in this
> function)
> include/asm/ptrace.h:67: error: (Each undeclared identifier is reported
> only once
> include/asm/ptrace.h:67: error: for each function it appears in.)
> make[1]: *** [init/do_mounts_initrd.o] Error 1
> make: *** [init] Error 2
Andrew has already fixed this and sent it to Linus. And now I know to be
more careful when turning macros into inlines: a macro just sits there until
someone uses it while an inline function is always evaluated.
Fix:
diff -puN include/asm-i386/ptrace.h~user_mode_vm-build-fix
include/asm-i386/ptrace.h
--- devel/include/asm-i386/ptrace.h~user_mode_vm-build-fix 2005-07-27
11:14:01.0 -0700
+++ devel-akpm/include/asm-i386/ptrace.h2005-07-27 11:14:27.0
-0700
@@ -55,6 +55,9 @@ struct pt_regs {
#define PTRACE_SET_THREAD_AREA26
#ifdef __KERNEL__
+
+#include
+
struct task_struct;
extern void send_sigtrap(struct task_struct *tsk, struct pt_regs *regs, int
error_code);
__
Chuck
-
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/
net/ipv4/netfilter/ip_conntrack_core.c fix -Wundef error
This fixes a single -Wundef error in the file net/ipv4/netfilter/ip_conntrack_core.c , Please Apply Nick Sillik [EMAIL PROTECTED] diff -urN a/net/ipv4/netfilter/ip_conntrack_core.c b/net/ipv4/netfilter/ip_conntrack_core.c --- a/net/ipv4/netfilter/ip_conntrack_core.c2005-07-27 16:40:16.0 -0400 +++ b/net/ipv4/netfilter/ip_conntrack_core.c2005-07-27 16:41:00.0 -0400 @@ -723,7 +723,7 @@ /* Welcome, Mr. Bond. We've been expecting you... */ __set_bit(IPS_EXPECTED_BIT, &conntrack->status); conntrack->master = exp->master; -#if CONFIG_IP_NF_CONNTRACK_MARK +#ifdef CONFIG_IP_NF_CONNTRACK_MARK conntrack->mark = exp->master->mark; #endif nf_conntrack_get(&conntrack->master->ct_general);
Linux-2.4.31-hf3 (SECURITY)
Hello, due to a recent vulnerability discovered in zlib (CAN-2005-1849), here's a new set of hotfixes for stable kernels 2.4 : - 2.4.31-hf3 - 2.4.30-hf6 - 2.4.29-hf13 The zlib vulnerability has been shown to be able to segfault gunzip with a specially crafted input stream ; it is expected that the kernel may crash if zlib users such as PPP or zisofs were targetted. Aside that, the correct version of Davem's netlink hashing fix has been merged, as well as 2 other minor patches. Changelog appended, and updates available at the usual URL below. Naturally, upgrade is recommended. http://linux.exosec.net/kernel/2.4-hf/ Only build of 2.4.31-hf3 with full modules has been tested. Grant will probably update his more complete build/test reports there soon : http://scatter.mine.nu/linux-2.4-hotfix/ Regards Willy -- Changelog From 2.4.31-hf2 to 2.4.31-hf3 (semi-automated) --- '+' = added ; '-' = removed + 2.4.31-zlib-security-bugs-1(Tim Yamin) Fix outstanding security bugs in the Linux zlib implementations. See: a) http://sources.redhat.com/ml/bug-gnu-utils/1999-06/msg00183.html b) http://bugs.gentoo.org/show_bug.cgi?id=94584 + 2.4.31-ip_vs_conn_tab-race-1 (Neil Horman) [IPVS]: Close race conditions on ip_vs_conn_tab list modification. In an smp system, it is possible for an connection timer to expire, calling ip_vs_conn_expire while the connection table is being flushed, before ct_write_lock_bh is acquired. (...) The result is that the next pointer gets set to NULL, and subsequently dereferenced, resulting in an oops. + 2.4.31-inode-cache-smp-races-1 (Larry Woodman) [PATCH] workaround inode cache (prune_icache/__refile_inode) SMP races Over the past couple of weeks we have seen two races in the inode cache code. The first is between [dispose_list()] and __refile_inode() and the second is between prune_icache() and truncate_inodes(). Fixes bug 155289. + 2.4.31-netlink-socket-hashing-bugs-2 (David S. Miller) [NETLINK]: Fix two socket hashing bugs. netlink_release() should only decrement the hash entry count if the socket was actually hashed. netlink_autobind() needs to propagate the error return from netlink_insert(). Otherwise, callers will not see the error as they should and thus try to operate on a socket with a zero pid, which is very bad. Thanks to Jakub Jelinek for providing backtraces, and Herbert Xu for debugging patches to help track this down. + 2.4.31-sparc64-sys32_utimes-random-timestamps-1 (Jakub Bogusz) [SPARC64]: fix sys32_utimes(somefile, NULL) This patch fixes utimes(somefile, NULL) syscalls on sparc64 kernel with 32-bit userland - use of uninitialized value resulted in making random timestamps, which confused e.g. sudo. It has been already fixed (by davem) in linux-2.6 tree 30 months ago. -- END -- - 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.12: no sound on SPDIF with emu10k1
On Wed, 2005-07-27 at 21:46 +0200, Thomas Zehetbauer wrote: > Hi! > > I cannot get my SB Live! 5.1's SPDIF (digital) output to work with > kernel > 2.6.12. I have not changed my mixer configuration and it is > still working when I boot 2.6.11.12 or earlier. I am using FC4 with > alsa-lib-1.0.9rf-2.FC4 installed. FC4 shipped a buggy ALSA version, I can't believe there are no updated RPMs yet. You need a newer ALSA. Lee - 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/
driver for Marvell 88E8053 PCI Express Gigabit LAN
Hello, there are GPL driver for the Marvell 88E8053 GLAN: http://dlsvr01.asus.com/pub/ASUS/lan/marvell/8053/8053_others2.zip The problem is that they are not compiling with the current kernel. Could you please adapt and integrate the drivers to the current kernel? Thanks & regards, Alexander - 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: [ACPI] Re: ACPI buttons in 2.6.12-rc4-mm2
Hi! > Len Brown <[EMAIL PROTECTED]> wrote: > > > I deleted /proc/acpi/button on purpose, > > did you have a use for those files? > > There are various cases where it's useful to know whether a laptop is > shut or not, and /proc/acpi/button seems to be the only place where that > information is made available at the moment. > Unless it was in obsolete-feature-removal file for a year changing userspace interface is bad idea in the middle of stable series. Pavel -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces
On 23.07.2005 [22:12:30 +0200], Roman Zippel wrote:
> Hi,
>
> On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
>
> > > Jiffies are the basic time unit for kernel timers, hiding that fact gives
> > > users only wrong expectations about them.
> >
> > We already have msleep() and msleep_interruptible(), which hide jiffies
> > in milliseconds. These interfaces are their parallel in the wait-queue
> > case. If you don't want to use them, or their use is not appropriate,
> > then the callers won't be changed.
>
> I'm not exactly impressed with their implementation, it's completely silly
> that there is no such convience function based on jiffies, e.g. if you
> look at the msleep_interruptible(), you'll find quite a few
> "msleep_interruptible(jiffies_to_msecs())".
Patches are welcome, I guess :)
> msleep_interruptible() is especially bad as there are a few users who
> check the return value and since it adds one to the timeout, you can
> create loops which may never timeout (as e.g. in drivers/w1/w1_therm.c:
> w1_therm_read_bin()), this is nice example of a bad interface.
>
> These two function should actually look like this:
>
> static inline void msleep(unsigned int msecs)
> {
> sleep(msecs_to_jiffies(msecs));
> }
>
> static inline int msleep_interruptible(unsigned int msecs)
> {
> sleep_interruptible(msecs_to_jiffies(msecs)) != 0;
> }
Where are sleep() and sleep_interruptible() defined? And this basically
pushes down the identical implementation a layer, correct? Finally, you
cannot simply do msecs_to_jiffies() in the caller of
sleep{,_interruptible()}, unless sleep{,_interruptible()} add 1 to every
request themselves. The basic issue is that with jiffies and ticks being
identical, there is no concept of the inter-tick position (i.e., a
sub-jiffy value), and the callers of these conversion functions *must*
assume they are going to be added to the timer subsystem immediately
before a timer interrupt occurs. An entire tick has not elapsed, but if
the caller had not added 1, then we could potentially go off almost an
entire tick early. The +1 is basically specifying we are asking to add
our delay to the *next* tick.
> > My goal is to distinguish between these cases in sleeping-logic:
> >
> > 1) tick-oriented
> > use schedule_timeout(), add_timer(), etc.
> >
> > 2) time-oriented
> > use schedule_timeout_msecs()
>
> There is _no_ difference, the scheduler is based on ticks. Even if we soon
> have different time sources, the scheduler will continue to measure the
> time in ticks and for a simple reason - portability. Jiffies _are_ simple,
> don't throw that away.
I agree that from an internal perspective there is no difference, but
from an *interface* perspective they are hugely different, simply on the
basis that one uses human-time units and one does not.
I guess we must continue to agree to disagree.
I am still waiting for some feedback from Andrew if he would prefer a
jiffy-only version or both the jiffy and msec version.
Thanks,
Nish
-
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: [ACPI] Re: [Alsa-devel] [PATCH] 2.6.13-rc3-git5: fix Bug #4416 (1/2)
Hi! > > The following patch adds free_irq() and request_irq() to the suspend and > > resume, respectively, routines in the snd_intel8x0 driver. > > The patch looks OK to me although I have some concerns. > > - The error in resume can't be handled properly. > > What should we do for the error of request_irq()? > > - Adding this to all drivers seem too much. There's probably no other way. Talk to Len Brown. > We just need to stop the irq processing until resume, so something > like suspend_irq(irq, dev_id) and resume_irq(irq, dev_id) would be > more uesful? Its more complex than that. Irq numbers may change during resume. -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - 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/
system freezes for 0.2 to 0.5 seconds when reading /proc/acpi/thermal_zone/THRM/temperature
Hello, first of all, sorry for the long headline. second: Every time, i try to do the following: cat /proc/acpi/thermal_zone/THRM/temperature the whole system looks up for a short period of time (something about 0.5s). realy everything, video and audio encoding, mouse and keyboard input, firefox playing a flash animation, ... I am also getting the following: Losing some ticks... checking if CPU frequency changed. maybe these two things are belonging to each other. I am using a 2.6.12-rc3-mm1 kernel on a amd64 with a nvidia nforce4 mainboard. kind regards flo -- "I may have invented it, but Bill made it famous" David Bradley, who invented the (in)famous ctrl-alt-del key combination - 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/
powersave not working with amd64 on nforce 4 board
Hello, powersaving is not working with a 2.6.12-rc3-mm1 kernel and a amd64 3500+ on a nvidia nforce 4 mainboard. syslog tells me the following about it: ... ACPI: Processor [CPU0] (supports 8 throttling states) ... powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.40.2) acpi_processor-0252 [04] acpi_processor_get_per: Error evaluating _PSS powernow-k8: BIOS error - no PSB or ACPI _PSS objects acpi_processor-0252 [04] acpi_processor_get_per: Error evaluating _PSS kind regards flo -- "I may have invented it, but Bill made it famous" David Bradley, who invented the (in)famous ctrl-alt-del key combination - 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.13-rc3-mm2 doesn't boot
On Wed, Jul 27, 2005 at 02:16:46PM -0700, Andrew Morton wrote: > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > 2.6.13-rc3-mm2 doesn't boot on my computer: > >Badness in nr_blockdev_pages at fs/block_dev.c:399 > >... > >kmem_cache_create: Early error in slab inet_peer_cache > > > > A screenshot is available at [1]. > > > > My .config is attached. > > > > 2.6.13-rc3-mm1 boots and works without problems. > > > > cu > > Adrian > > > > [1] http://www.fs.tum.de/~bunk/kernel/boot_failure.jpg > > I'd be suspecting there's been a huge preempt_count() windup and the kernel > thinks that it's running in_interrupt(), so various checks are triggering. > > Please try this one: >... Thanks, this fixed it. > And if that doesn't fix, enable CONFIG_DEBUG_PREEMPT and see if the > sub_preempt_count() check triggers. This wouldn't have been possible since I'm using CONFIG_PREEMPT_NONE=y. 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/
[PATCH 2.6.13-rc3-mm2] fs/reiser4/plugin/node/node40.h fix warning with -Wundef
Fixes another -Wundef warning in ReiserFS code. Nick Sillik [EMAIL PROTECTED] Signed-off-by: Nick Sillik <[EMAIL PROTECTED]> diff -urN a/fs/reiser4/plugin/node/node40.h b/fs/reiser4/plugin/node/node40.h --- a/fs/reiser4/plugin/node/node40.h 2005-07-27 18:14:04.0 -0400 +++ b/fs/reiser4/plugin/node/node40.h 2005-07-27 18:14:53.0 -0400 @@ -80,7 +80,7 @@ int check_node40(const znode * node, __u32 flags, const char **error); int parse_node40(znode * node); int init_node40(znode * node); -#if GUESS_EXISTS +#ifdef GUESS_EXISTS int guess_node40(const znode * node); #endif void change_item_size_node40(coord_t * coord, int by);
Re: 2.6.13-rc3-mm2/mm1 breaks DRI
>> >> >> >> I also use 2.6.13-rc3-mm1. Will try with a previous version an report to >> >> lkml if >> >> it works. >> >> >> > >> > I just tried 13-rc2-mm1 and dri is working again. Its reported to also work >> > with 13-rc3. >> > >Hmm no idea what could have broken it, I'm at OLS and don't have any >DRI capable machine here yet.. so it'll be a while before I get to >take a look at it .. I wouldn't be terribly surprised if some of the >new mapping code might have some issues.. Still happens with mm2. Thanks Ed - 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/
Add ia64 specific prefetch switch stack implementation
This patch adds ia64 specific implementation to prefetch switch stack structure. It applies on top of "add prefetch switch stack hook ..." posted earlier. Using my favorite industry standard OLTP workload, we measured 6.2X reduction on cache misses occurred in the context switch code and yielded about 0.2% performance gain on large scale db setup. Signed-off-by: Ken Chen <[EMAIL PROTECTED]> --- linux-2.6.12/arch/ia64/kernel/entry.S.orig 2005-07-27 14:43:25.853236577 -0700 +++ linux-2.6.12/arch/ia64/kernel/entry.S 2005-07-27 14:47:24.634483652 -0700 @@ -470,6 +470,29 @@ ENTRY(load_switch_stack) br.cond.sptk.many b7 END(load_switch_stack) +GLOBAL_ENTRY(prefetch_switch_stack) + add r14 = -IA64_SWITCH_STACK_SIZE, sp + add r15 = IA64_TASK_THREAD_KSP_OFFSET, in0 + ;; + ld8 r16 = [r15] // load next's stack pointer + lfetch.fault.excl [r14], 128 + ;; + lfetch.fault.excl [r14], 128 + lfetch.fault [r16], 128 + ;; + lfetch.fault.excl [r14], 128 + lfetch.fault [r16], 128 + ;; + lfetch.fault.excl [r14], 128 + lfetch.fault [r16], 128 + ;; + lfetch.fault.excl [r14], 128 + lfetch.fault [r16], 128 + ;; + lfetch.fault [r16], 128 + br.ret.sptk.many rp +END(prefetch_switch_stack) + GLOBAL_ENTRY(execve) mov r15=__NR_execve // put syscall number in place break __BREAK_SYSCALL --- linux-2.6.12/include/asm-ia64/system.h.orig 2005-07-27 14:43:49.209681604 -0700 +++ linux-2.6.12/include/asm-ia64/system.h 2005-07-27 14:44:03.389368930 -0700 @@ -274,6 +274,7 @@ extern void ia64_load_extra (struct task */ #define __ARCH_WANT_UNLOCKED_CTXSW +#define ARCH_HAS_PREFETCH_SWITCH_STACK #define ia64_platform_is(x) (strcmp(x, platform_name) == 0) void cpu_idle_wait(void); - 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.12-git8] ACPI shutdown fails to power off machine
On Tuesday, 19 July 2005, at 04:41:26 -0600, Eric W. Biederman wrote: > Roughly for your part of the problem the acpi shutdown code needs to > get called sooner when interrupts are still enabled. > After the recent patches that went in to the kernel, I downloaded version 2.6.13-rc8-git8, compiled, and now the box powers off correctly. Seems my setup is working fine again now. However, I didn't check if this is working ok all the times, because it seems in another thread that someone is having problems to get his system powering off reliably. But the precise problem I reported is gone. Thank you Eric. Greetings, -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.13-rc3-git8) signature.asc Description: Digital signature
Add prefetch switch stack hook in scheduler function
I would like to propose adding a prefetch switch stack hook in
the scheduler function. For architecture like ia64, the switch
stack structure is fairly large (currently 528 bytes). For context
switch intensive application, we found that significant amount of
cache misses occurs in switch_to() function. The following patch
adds a hook in the schedule() function to prefetch switch stack
structure as soon as 'next' task is determined. This allows maximum
overlap in prefetch cache lines for that structure.
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
--- linux-2.6.12/include/linux/sched.h.orig 2005-07-27 14:43:49.321986290
-0700
+++ linux-2.6.12/include/linux/sched.h 2005-07-27 14:44:03.390345492 -0700
@@ -622,6 +622,11 @@ extern int groups_search(struct group_in
#define GROUP_AT(gi, i) \
((gi)->blocks[(i)/NGROUPS_PER_BLOCK][(i)%NGROUPS_PER_BLOCK])
+#ifdef ARCH_HAS_PREFETCH_SWITCH_STACK
+extern void prefetch_switch_stack(struct task_struct*);
+#else
+#define prefetch_switch_stack(task)do { } while (0)
+#endif
struct audit_context; /* See audit.c */
struct mempolicy;
--- linux-2.6.12/kernel/sched.c.orig2005-07-27 14:43:49.39136 -0700
+++ linux-2.6.12/kernel/sched.c 2005-07-27 14:44:03.394251742 -0700
@@ -3044,6 +3044,7 @@ switch_tasks:
if (next == rq->idle)
schedstat_inc(rq, sched_goidle);
prefetch(next);
+ prefetch_switch_stack(next);
clear_tsk_need_resched(prev);
rcu_qsctr_inc(task_cpu(prev));
-
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: Variable ticks
On Wed, 27 Jul 2005, Lee Revell wrote: > On Wed, 2005-07-27 at 02:13 -0600, Zwane Mwaikambo wrote: > > > What about audio? If there is a sound server running then you're going > > > to have a constant stream of interrupts and DMA activity from the sound > > > card even if the machine is idle and there aren't any sounds playing. > > > > Doesn't artsd at least close the audio device after some configurable idle > > time? In which case that sounds like a userspace issue. > > Well, as of ALSA 1.0.9 which does software mixing and volume control by > default, all the sound servers are obsolete. So this should be a > non-issue with a modern distro. > > As far as legacy support, AFAIK esd and artsd both grab the sound device > on startup and never release it. I just setup KDE/artsd to release the sound device after 30seconds and it seems to work. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PCDP: if PCDP contains parity information, use it
If the PCDP supplies parity, use it (only none/even/odd supported),
and don't append parity/stop bit arguments unless baud is present.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work/drivers/firmware/pcdp.c
===
--- work.orig/drivers/firmware/pcdp.c 2005-07-25 15:04:23.0 -0600
+++ work/drivers/firmware/pcdp.c2005-07-25 15:08:05.0 -0600
@@ -25,14 +25,22 @@
#ifdef CONFIG_SERIAL_8250_CONSOLE
int mmio;
static char options[64], *p = options;
+ char parity;
mmio = (uart->addr.address_space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY);
p += sprintf(p, "console=uart,%s,0x%lx",
mmio ? "mmio" : "io", uart->addr.address);
- if (uart->baud)
+ if (uart->baud) {
p += sprintf(p, ",%lu", uart->baud);
- if (uart->bits)
- p += sprintf(p, "n%d", uart->bits);
+ if (uart->bits) {
+ switch (uart->parity) {
+ case 0x2: parity = 'e'; break;
+ case 0x3: parity = 'o'; break;
+ default: parity = 'n';
+ }
+ p += sprintf(p, "%c%d", parity, uart->bits);
+ }
+ }
return early_serial_console_init(options);
#else
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.13rc3] IPv6: Check interface bindings on IPv6 raw socket reception
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Sun, 24 Jul 2005 07:39:12 +0200 > [IPV4/6]: Check if packet was actually delivered to a raw socket to decide > whether to send an ICMP unreachable > > Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> Applied, thanks Patrick. - 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/
Helpme WitCh Cpu Scaling. Hi People
It is the first mail that I write. I call gabri and I am 18 years old. I am Spanish. I want to comment that me program does not work ningun to regulate the Mhz of the processor. " Cpufreq, cpuydn, powernow ". I do not manage to load ningun module from the kernel inside cpuscalig in that it(he,she) fences with an amd mobile sempron. The modules of athlon do not go. Do they work to give support to the mobile sempron in the future versions of the kernel? what can I do ? __ Renovamos el Correo Yahoo! Nuevos servicios, más seguridad http://correo.yahoo.es - 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/
possible brief list outage this evening
vger.kernel.org will be pushed over to a completely new machine, and this will likely occur this evening No problems are expected, but you all know how these things sometimes go :-) - 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/
