Re: [ANNOUNCE 2/6] Linux-iSCSI High-Performance Initiator

[Greg KH]

On Mon, Apr 11, 2005 at 08:24:08PM -0700, Alex Aizman wrote:
>   Common header files:
>   - iscsi_ifev.h (user/kernel events).

These structures cross the user/kernel boundry?  If so, they _must_ use
the __u32 and friends types, not the horrible uint32_t mess...

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] ppc32: refactor FPU exception handling

[Kumar Gala]

Ben,
Sorry about that, we have had some back and forth on this on the ppc 
embedded list.

Not sure I understand your concern about the duplication of the fast 
exception return path?  Jason's patch pretty much just moved code out 
of head.S into fpu.S so we dont duplicate it between head.S and 
head_44x.S & head_fsl_booke.S

- kumar
On Apr 11, 2005, at 9:28 PM, Benjamin Herrenschmidt wrote:
On Mon, 2005-04-11 at 17:02 -0500, Kumar Gala wrote:
 > Andrew,
 >
> Moved common FPU exception handling code out of head.S so it can be 
used
> by several of the sub-architectures that might of a full PowerPC 
FPU. 
>
> Also, uses new CONFIG_PPC_FPU define to fix alignment exception
> handling for floating point load/store instructions to only occur if 
we
> have a hardware FPU.
>
> Signed-off-by: Jason McMullan <[EMAIL PROTECTED]>
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>


Andrew, please hold on this patch, it hasn't been properly discussed
 with the relevant maintainer, that is Paul Mackerras.
I can see matter for debate in there, like the whole duplication of the
 fast exception return path...
It's also touching quite sensitive bits of kernel code (head.S) that
 needs careful auditing and testing before beeing pushed upstream.
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [ANNOUNCE 2/6] Linux-iSCSI High-Performance Initiator

[Greg KH]

> +struct iscsi_hdr {
> + uint8_t opcode;
> + uint8_t flags;  /* Final bit */
> + uint8_t rsvd2[2];
> + uint8_t hlength;/* AHSs total length */
> + uint8_t dlength[3]; /* Data length */
> + uint8_t lun[8];
> + uint32_titt;/* Initiator Task Tag */
> + uint32_tttt;/* Target Task Tag */
> + uint32_tstatsn;
> + uint32_texp_statsn;
> + uint8_t other[16];

Please use u8 and u32 instead of the types you used here.  See the lkml
archives for many threads about this topic.

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: [ANNOUNCE 2/6] Linux-iSCSI High-Performance Initiator

[Greg KH]

On Mon, Apr 11, 2005 at 08:24:08PM -0700, Alex Aizman wrote:
> +typedef uint64_t iscsi_snx_t;/* iSCSI Data-Path session 
> handle */
> +typedef uint64_t iscsi_cnx_t;/* iSCSI Data-Path connection 
> handle */

Do you really have to create a new typedef?  Please reconsider.  Just
use u64 everywhere, unless you need to do type checking...

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 4/6]cpu state clean after hot remove

[Li Shaohua]

Clean CPU states in order to reuse smp boot code for CPU hotplug.

Signed-off-by: Li Shaohua<[EMAIL PROTECTED]>
---

 linux-2.6.11-root/arch/i386/kernel/cpu/common.c |   12 
 linux-2.6.11-root/arch/i386/kernel/irq.c|5 +
 linux-2.6.11-root/arch/i386/kernel/process.c|   19 +++
 linux-2.6.11-root/arch/i386/kernel/smpboot.c|   62 ++--
 linux-2.6.11-root/include/asm-i386/irq.h|2 
 linux-2.6.11-root/include/asm-i386/smp.h|5 +
 6 files changed, 89 insertions(+), 16 deletions(-)

diff -puN arch/i386/kernel/cpu/common.c~cpu_state_clean 
arch/i386/kernel/cpu/common.c
--- linux-2.6.11/arch/i386/kernel/cpu/common.c~cpu_state_clean  2005-04-12 
10:37:50.642376224 +0800
+++ linux-2.6.11-root/arch/i386/kernel/cpu/common.c 2005-04-12 
10:37:50.654374400 +0800
@@ -644,3 +644,15 @@ void __devinit cpu_init (void)
clear_used_math();
mxcsr_feature_mask_init();
 }
+
+#ifdef CONFIG_HOTPLUG_CPU
+void __devinit cpu_uninit(void)
+{
+   int cpu = _smp_processor_id();
+   cpu_clear(cpu, cpu_initialized);
+
+   /* lazy TLB state */
+   per_cpu(cpu_tlbstate, cpu).state = 0;
+   per_cpu(cpu_tlbstate, cpu).active_mm = _mm;
+}
+#endif
diff -puN arch/i386/kernel/irq.c~cpu_state_clean arch/i386/kernel/irq.c
--- linux-2.6.11/arch/i386/kernel/irq.c~cpu_state_clean 2005-04-12 
10:37:50.643376072 +0800
+++ linux-2.6.11-root/arch/i386/kernel/irq.c2005-04-12 10:37:50.654374400 
+0800
@@ -158,6 +158,11 @@ void irq_ctx_init(int cpu)
cpu,hardirq_ctx[cpu],softirq_ctx[cpu]);
 }
 
+void irq_ctx_exit(int cpu)
+{
+   hardirq_ctx[cpu] = NULL;
+}
+
 extern asmlinkage void __do_softirq(void);
 
 asmlinkage void do_softirq(void)
diff -puN arch/i386/kernel/process.c~cpu_state_clean arch/i386/kernel/process.c
--- linux-2.6.11/arch/i386/kernel/process.c~cpu_state_clean 2005-04-12 
10:37:50.645375768 +0800
+++ linux-2.6.11-root/arch/i386/kernel/process.c2005-04-12 
10:37:50.655374248 +0800
@@ -148,21 +148,18 @@ static void poll_idle (void)
 /* We don't actually take CPU down, just spin without interrupts. */
 static inline void play_dead(void)
 {
+   /* This must be done before dead CPU ack */
+   cpu_exit_clear();
+   mb();
/* Ack it */
__get_cpu_var(cpu_state) = CPU_DEAD;
 
-   /* We shouldn't have to disable interrupts while dead, but
-* some interrupts just don't seem to go away, and this makes
-* it "work" for testing purposes. */
-   /* Death loop */
-   while (__get_cpu_var(cpu_state) != CPU_UP_PREPARE)
-   cpu_relax();
-
+   /*
+* With physical CPU hotplug, we should halt the cpu
+*/
local_irq_disable();
-   __flush_tlb_all();
-   cpu_set(smp_processor_id(), cpu_online_map);
-   enable_APIC_timer();
-   local_irq_enable();
+   while (1)
+   __asm__ __volatile__("hlt":::"memory");
 }
 #else
 static inline void play_dead(void)
diff -puN arch/i386/kernel/smpboot.c~cpu_state_clean arch/i386/kernel/smpboot.c
--- linux-2.6.11/arch/i386/kernel/smpboot.c~cpu_state_clean 2005-04-12 
10:37:50.646375616 +0800
+++ linux-2.6.11-root/arch/i386/kernel/smpboot.c2005-04-12 
10:37:50.656374096 +0800
@@ -798,8 +798,18 @@ wakeup_secondary_cpu(int phys_apicid, un
 #endif /* WAKE_SECONDARY_VIA_INIT */
 
 extern cpumask_t cpu_initialized;
+static inline int alloc_cpu_id(void)
+{
+   cpumask_t   tmp_map;
+   int cpu;
+   cpus_complement(tmp_map, cpu_present_map);
+   cpu = first_cpu(tmp_map);
+   if (cpu >= NR_CPUS)
+   return -ENODEV;
+   return cpu;
+}
 
-static int __devinit do_boot_cpu(int apicid)
+static int __devinit do_boot_cpu(int apicid, int cpu)
 /*
  * NOTE - on most systems this is a PHYSICAL apic ID, but on multiquad
  * (ie clustered apic addressing mode), this is a LOGICAL apic ID.
@@ -808,11 +818,12 @@ static int __devinit do_boot_cpu(int api
 {
struct task_struct *idle;
unsigned long boot_error;
-   int timeout, cpu;
+   int timeout;
unsigned long start_eip;
unsigned short nmi_high = 0, nmi_low = 0;
 
-   cpu = ++cpucount;
+   ++cpucount;
+
/*
 * We can't use kernel_thread since we must avoid to
 * reschedule the child.
@@ -884,13 +895,16 @@ static int __devinit do_boot_cpu(int api
inquire_remote_apic(apicid);
}
}
-   x86_cpu_to_apicid[cpu] = apicid;
+
if (boot_error) {
/* Try to put things back the way they were before ... */
unmap_cpu_to_logical_apicid(cpu);
cpu_clear(cpu, cpu_callout_map); /* was set here 
(do_boot_cpu()) */
cpu_clear(cpu, cpu_initialized); /* was set by cpu_init() */
cpucount--;
+   } else {
+   x86_cpu_to_apicid[cpu] = apicid;
+   cpu_set(cpu, cpu_present_map);
}
 

[PATCH] ppc64: very basic desktop g5 sound support (#2)

[Benjamin Herrenschmidt]

Hi !

(Andrew: This is an update of the previous patch, it fixes a problem
with headphone beeing incorrectly muted on some models).

This patch hacks the current PowerMac Alsa driver to add some basic
support of analog sound output to some desktop G5s. It has severe
limitations though:

 - Only 44100Khz 16 bits
 - Only work on G5 models using a TAS3004 analog code, that is early
   single CPU desktops and all dual CPU desktops at this date, but none
   of the more recent ones like iMac G5.
 - It does analog only, no digital/SPDIF support at all, no native
   AC3 support

Better support would require a complete rewrite of the driver (which I
am working on,  but don't hold your breath), to properly support the
diversity of apple sound HW setup, including dual codecs, several i2s
busses,  all the new codecs used in the new machines, proper clock
switching with digital, etc etc etc...

This patch applies on top of the other PowerMac sound patches I posted
in the past couple of days (new powerbook support and sleep fixes). 

Note: This is a FAQ entry for PowerMac sound support with TI codecs:
They have a feature called "DRC" which is automatically enabled for the
internal speaker (at least when auto mute control is enabled) which will
cause your sound to fade out to nothing after half a second of playback
if you don't set a proper "DRC Range" in the mixer. So if you have a
problem like that, check alsamixer and raise your DRC Range to something
reasonable.

Note2: This patch will also add auto-mute of the speaker when line-out
jack is used on some earlier desktop G4s (and on the G5) in addition to
the headphone jack. If that behaviour isn't what you want, just disable
auto-muting and use the manual mute controls in alsamixer.

Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>

Index: linux-work/sound/ppc/pmac.c
===
--- linux-work.orig/sound/ppc/pmac.c2005-04-11 22:09:18.0 +1000
+++ linux-work/sound/ppc/pmac.c 2005-04-11 22:27:37.0 +1000
@@ -27,14 +27,13 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include "pmac.h"
 #include 
-#ifdef CONFIG_PPC_HAS_FEATURE_CALLS
 #include 
-#else
-#include 
-#endif
+#include 
 
 
 #if defined(CONFIG_PM) && defined(CONFIG_PMAC_PBOOK)
@@ -57,22 +56,29 @@
 /*
  * allocate DBDMA command arrays
  */
-static int snd_pmac_dbdma_alloc(pmac_dbdma_t *rec, int size)
+static int snd_pmac_dbdma_alloc(pmac_t *chip, pmac_dbdma_t *rec, int size)
 {
-   rec->space = kmalloc(sizeof(struct dbdma_cmd) * (size + 1), GFP_KERNEL);
+   unsigned int rsize = sizeof(struct dbdma_cmd) * (size + 1);
+
+   rec->space = dma_alloc_coherent(>pdev->dev, rsize,
+   >dma_base, GFP_KERNEL);
if (rec->space == NULL)
return -ENOMEM;
rec->size = size;
-   memset(rec->space, 0, sizeof(struct dbdma_cmd) * (size + 1));
+   memset(rec->space, 0, rsize);
rec->cmds = (void __iomem *)DBDMA_ALIGN(rec->space);
-   rec->addr = virt_to_bus(rec->cmds);
+   rec->addr = rec->dma_base + (unsigned long)((char *)rec->cmds - (char 
*)rec->space);
+
return 0;
 }
 
-static void snd_pmac_dbdma_free(pmac_dbdma_t *rec)
+static void snd_pmac_dbdma_free(pmac_t *chip, pmac_dbdma_t *rec)
 {
-   if (rec)
-   kfree(rec->space);
+   if (rec) {
+   unsigned int rsize = sizeof(struct dbdma_cmd) * (rec->size + 1);
+
+   dma_free_coherent(>pdev->dev, rsize, rec->space, 
rec->dma_base);
+   }
 }
 
 
@@ -237,7 +243,7 @@
/* continuous DMA memory type doesn't provide the physical address,
 * so we need to resolve the address here...
 */
-   offset = virt_to_bus(runtime->dma_area);
+   offset = runtime->dma_addr;
for (i = 0, cp = rec->cmd.cmds; i < rec->nperiods; i++, cp++) {
st_le32(>phy_addr, offset);
st_le16(>req_count, rec->period_size);
@@ -664,8 +670,8 @@
chip->capture.cur_freqs = chip->freqs_ok;
 
/* preallocate 64k buffer */
-   snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_CONTINUOUS, 
- 
snd_dma_continuous_data(GFP_KERNEL),
+   snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV, 
+ >pdev->dev,
  64 * 1024, 64 * 1024);
 
return 0;
@@ -757,28 +763,10 @@
 /*
  * a wrapper to feature call for compatibility
  */
-#if defined(CONFIG_PM) && defined(CONFIG_PMAC_PBOOK)
 static void snd_pmac_sound_feature(pmac_t *chip, int enable)
 {
-#ifdef CONFIG_PPC_HAS_FEATURE_CALLS
ppc_md.feature_call(PMAC_FTR_SOUND_CHIP_ENABLE, chip->node, 0, enable);
-#else
-   if (chip->is_pbook_G3) {
-   pmu_suspend();
-   feature_clear(chip->node, FEATURE_Sound_power);
-   feature_clear(chip->node, 

[PATCH 6/6]suspend/resume SMP support

[Li Shaohua]

Using CPU hotplug to support suspend/resume SMP. Both S3 and S4 use
disable/enable_nonboot_cpus API. The S4 part is based on Pavel's
original S4 SMP patch.

Signed-off-by: Li Shaohua<[EMAIL PROTECTED]>
---

 linux-2.6.11-root/drivers/acpi/Kconfig|2 
 linux-2.6.11-root/include/linux/suspend.h |2 
 linux-2.6.11-root/kernel/power/Kconfig|2 
 linux-2.6.11-root/kernel/power/disk.c |   36 ++-
 linux-2.6.11-root/kernel/power/main.c |   16 +++--
 linux-2.6.11-root/kernel/power/smp.c  |   91 +++---
 linux-2.6.11-root/kernel/power/swsusp.c   |2 
 7 files changed, 69 insertions(+), 82 deletions(-)

diff -puN drivers/acpi/Kconfig~smp_sleep drivers/acpi/Kconfig
--- linux-2.6.11/drivers/acpi/Kconfig~smp_sleep 2005-04-12 11:11:14.884685080 
+0800
+++ linux-2.6.11-root/drivers/acpi/Kconfig  2005-04-12 11:11:14.898682952 
+0800
@@ -57,7 +57,7 @@ if ACPI_INTERPRETER
 
 config ACPI_SLEEP
bool "Sleep States (EXPERIMENTAL)"
-   depends on X86
+   depends on X86 && (!SMP || HOTPLUG_CPU)
depends on EXPERIMENTAL
default y
---help---
diff -puN include/linux/suspend.h~smp_sleep include/linux/suspend.h
--- linux-2.6.11/include/linux/suspend.h~smp_sleep  2005-04-12 
11:11:14.885684928 +0800
+++ linux-2.6.11-root/include/linux/suspend.h   2005-04-12 11:11:14.898682952 
+0800
@@ -58,7 +58,7 @@ static inline int software_suspend(void)
 }
 #endif
 
-#ifdef CONFIG_SMP
+#ifdef CONFIG_HOTPLUG_CPU
 extern void disable_nonboot_cpus(void);
 extern void enable_nonboot_cpus(void);
 #else
diff -puN kernel/power/disk.c~smp_sleep kernel/power/disk.c
--- linux-2.6.11/kernel/power/disk.c~smp_sleep  2005-04-12 11:11:14.887684624 
+0800
+++ linux-2.6.11-root/kernel/power/disk.c   2005-04-12 11:11:14.899682800 
+0800
@@ -117,8 +117,8 @@ static void finish(void)
 {
device_resume();
platform_finish();
-   enable_nonboot_cpus();
thaw_processes();
+   enable_nonboot_cpus();
pm_restore_console();
 }
 
@@ -131,28 +131,36 @@ static int prepare_processes(void)
 
sys_sync();
 
+   disable_nonboot_cpus();
+
if (freeze_processes()) {
error = -EBUSY;
-   return error;
+   goto enable_cpu;
}
 
if (pm_disk_mode == PM_DISK_PLATFORM) {
if (pm_ops && pm_ops->prepare) {
if ((error = pm_ops->prepare(PM_SUSPEND_DISK)))
-   return error;
+   goto thaw;
}
}
 
/* Free memory before shutting down devices. */
free_some_memory();
-
return 0;
+thaw:
+   thaw_processes();
+enable_cpu:
+   enable_nonboot_cpus();
+   pm_restore_console();
+   return error;
 }
 
 static void unprepare_processes(void)
 {
-   enable_nonboot_cpus();
+   platform_finish();
thaw_processes();
+   enable_nonboot_cpus();
pm_restore_console();
 }
 
@@ -160,15 +168,9 @@ static int prepare_devices(void)
 {
int error;
 
-   disable_nonboot_cpus();
-   if ((error = device_suspend(PMSG_FREEZE))) {
+   if ((error = device_suspend(PMSG_FREEZE)))
printk("Some devices failed to suspend\n");
-   platform_finish();
-   enable_nonboot_cpus();
-   return error;
-   }
-
-   return 0;
+   return error;
 }
 
 /**
@@ -185,9 +187,9 @@ int pm_suspend_disk(void)
int error;
 
error = prepare_processes();
-   if (!error) {
-   error = prepare_devices();
-   }
+   if (error)
+   return error;
+   error = prepare_devices();
 
if (error) {
unprepare_processes();
@@ -250,7 +252,7 @@ static int software_resume(void)
 
if ((error = prepare_processes())) {
swsusp_close();
-   goto Cleanup;
+   goto Done;
}
 
pr_debug("PM: Reading swsusp image.\n");
diff -puN kernel/power/Kconfig~smp_sleep kernel/power/Kconfig
--- linux-2.6.11/kernel/power/Kconfig~smp_sleep 2005-04-12 11:11:14.888684472 
+0800
+++ linux-2.6.11-root/kernel/power/Kconfig  2005-04-12 11:11:14.899682800 
+0800
@@ -28,7 +28,7 @@ config PM_DEBUG
 
 config SOFTWARE_SUSPEND
bool "Software Suspend (EXPERIMENTAL)"
-   depends on EXPERIMENTAL && PM && SWAP
+   depends on EXPERIMENTAL && PM && SWAP && (HOTPLUG_CPU || !SMP)
---help---
  Enable the possibility of suspending the machine.
  It doesn't need APM.
diff -puN kernel/power/main.c~smp_sleep kernel/power/main.c
--- linux-2.6.11/kernel/power/main.c~smp_sleep  2005-04-12 11:11:14.890684168 
+0800
+++ linux-2.6.11-root/kernel/power/main.c   2005-04-12 11:11:14.899682800 
+0800
@@ -59,6 +59,13 @@ static int suspend_prepare(suspend_state
 
pm_prepare_console();
 
+   disable_nonboot_cpus();
+
+   if (num_online_cpus() != 1) {
+

[PATCH 5/6]physical CPU hot add

[Li Shaohua]

Boot a CPU at runtime.

Signed-off-by: Li Shaohua<[EMAIL PROTECTED]>
---

 linux-2.6.11-root/arch/i386/kernel/smpboot.c |  112 ---
 linux-2.6.11-root/drivers/base/cpu.c |8 +
 linux-2.6.11-root/include/asm-i386/smp.h |2 
 3 files changed, 93 insertions(+), 29 deletions(-)

diff -puN arch/i386/kernel/smpboot.c~warm_boot_cpu arch/i386/kernel/smpboot.c
--- linux-2.6.11/arch/i386/kernel/smpboot.c~warm_boot_cpu   2005-04-12 
10:38:16.720411760 +0800
+++ linux-2.6.11-root/arch/i386/kernel/smpboot.c2005-04-12 
11:11:09.16040 +0800
@@ -80,6 +80,12 @@ cpumask_t cpu_callin_map;
 cpumask_t cpu_callout_map;
 static cpumask_t smp_commenced_mask;
 
+/* TSC's upper 32 bits can't be written in eariler CPU (before prescott), there
+ * is no way to resync one AP against BP. TBD: for prescott and above, we
+ * should use IA64's algorithm
+ */
+static int __devinitdata tsc_sync_disabled;
+
 /* Per CPU bogomips and other parameters */
 struct cpuinfo_x86 cpu_data[NR_CPUS] __cacheline_aligned;
 
@@ -416,7 +422,7 @@ static void __devinit smp_callin(void)
/*
 *  Synchronize the TSC with the BP
 */
-   if (cpu_has_tsc && cpu_khz)
+   if (cpu_has_tsc && cpu_khz && !tsc_sync_disabled)
synchronize_tsc_ap();
 }
 
@@ -809,6 +815,31 @@ static inline int alloc_cpu_id(void)
return cpu;
 }
 
+#ifdef CONFIG_HOTPLUG_CPU
+static struct task_struct * __devinitdata cpu_idle_tasks[NR_CPUS];
+static inline struct task_struct * alloc_idle_task(int cpu)
+{
+   struct task_struct *idle;
+
+   if ((idle = cpu_idle_tasks[cpu]) != NULL) {
+   /* initialize thread_struct.  we really want to avoid destroy
+* idle tread
+*/
+   idle->thread.esp = (unsigned long)(((struct pt_regs *)
+   (THREAD_SIZE + (unsigned long) idle->thread_info)) - 1);
+   init_idle(idle, cpu);
+   return idle;
+   }
+   idle = fork_idle(cpu);
+
+   if (!IS_ERR(idle))
+   cpu_idle_tasks[cpu] = idle;
+   return idle;
+}
+#else
+#define alloc_idle_task(cpu) fork_idle(cpu)
+#endif
+
 static int __devinit do_boot_cpu(int apicid, int cpu)
 /*
  * NOTE - on most systems this is a PHYSICAL apic ID, but on multiquad
@@ -828,7 +859,7 @@ static int __devinit do_boot_cpu(int api
 * We can't use kernel_thread since we must avoid to
 * reschedule the child.
 */
-   idle = fork_idle(cpu);
+   idle = alloc_idle_task(cpu);
if (IS_ERR(idle))
panic("failed fork for CPU %d", cpu);
idle->thread.eip = (unsigned long) start_secondary;
@@ -931,6 +962,55 @@ void cpu_exit_clear(void)
cpu_clear(cpu, smp_commenced_mask);
unmap_cpu_to_logical_apicid(cpu);
 }
+
+struct warm_boot_cpu_info {
+   struct completion *complete;
+   int apicid;
+   int cpu;
+};
+
+static void __devinit do_warm_boot_cpu(void *p)
+{
+   struct warm_boot_cpu_info *info = p;
+   do_boot_cpu(info->apicid, info->cpu);
+   complete(info->complete);
+}
+
+int __devinit smp_prepare_cpu(int cpu)
+{
+   DECLARE_COMPLETION(done);
+   struct warm_boot_cpu_info info;
+   struct work_struct task;
+   int apicid, ret;
+
+   lock_cpu_hotplug();
+   apicid = x86_cpu_to_apicid[cpu];
+   if (apicid == BAD_APICID) {
+   ret = -ENODEV;
+   goto exit;
+   }
+
+   info.complete = 
+   info.apicid = apicid;
+   info.cpu = cpu;
+   INIT_WORK(, do_warm_boot_cpu, );
+
+   tsc_sync_disabled = 1;
+
+   /* init low mem mapping */
+   memcpy(swapper_pg_dir, swapper_pg_dir + USER_PGD_PTRS,
+   sizeof(swapper_pg_dir[0]) * KERNEL_PGD_PTRS);
+   flush_tlb_all();
+   schedule_work();
+   wait_for_completion();
+
+   tsc_sync_disabled = 0;
+   zap_low_mappings();
+   ret = 0;
+exit:
+   unlock_cpu_hotplug();
+   return ret;
+}
 #endif
 
 static void smp_tune_scheduling (void)
@@ -1169,24 +1249,6 @@ void __devinit smp_prepare_boot_cpu(void
 }
 
 #ifdef CONFIG_HOTPLUG_CPU
-
-/* must be called with the cpucontrol mutex held */
-static int __devinit cpu_enable(unsigned int cpu)
-{
-   /* get the target out of its holding state */
-   per_cpu(cpu_state, cpu) = CPU_UP_PREPARE;
-   wmb();
-
-   /* wait for the processor to ack it. timeout? */
-   while (!cpu_online(cpu))
-   cpu_relax();
-
-   fixup_irqs(cpu_online_map);
-   /* counter the disable in fixup_irqs() */
-   local_irq_enable();
-   return 0;
-}
-
 static void
 remove_siblinginfo(int cpu)
 {
@@ -1270,14 +1332,6 @@ int __devinit __cpu_up(unsigned int cpu)
return -EIO;
}
 
-#ifdef CONFIG_HOTPLUG_CPU
-   /* Already up, and in cpu_quiescent now? */
-   if (cpu_isset(cpu, smp_commenced_mask)) {
-   cpu_enable(cpu);
-   return 0;
- 

alloc_skb called nonatomically from interrupt

[Daniel Ann]

Hiya folks

I'm trying to get a feel of notifier_call_chain(), but with no luck.
This is basically what I've done.

On 2.4.21, I've added dev_sample() function which I've declared and
implemented in include/linux/netdevice.h and net/core/dev.c
respectively.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
int dev_sample(struct net_device *dev)
{
notifier_call_chain(_chain, NETDEV_SAMPLE, dev);
return 0;
}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Of course, I've defined NETDEV_SAMPLE in include/linux/notifier.h

Now up to this stage, its fine. Problem is when I try to call
dev_sample() from driver/net/natsemi.c (my network device driver).

natsemi.c has check_link function which runs periodically and checks
to see if cable is out. So I've placed my dev_sample() in this
function and have it called whenever status of cable changes. But as
soon as the status change, machine dies with "alloc_skb called
nonatomically from interrupt c00ba700", with some printk's I was able
to find out notifier_call_chain() was getting called. But it happens
when it traverses the _chain. (at the very first one in fact)

I've tried wrapping the dev_sample() with rtnl_lock and unlock but
with no luck. It looks to me its to do with accessing resource at a
wrong time, but I have no idea where to go from here.

Any suggestion would be appreciated.
Cheers,

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

Re: more git updates..

[David Lang]

I've been reading this and have another thought for you guys to keep in 
mind for this tool.

version control of system config files on linux systems.
it sounds like you could put the / fileystem under the control of git 
(after teaching it to not cross fileystem boundries so you can have 
another filesystem to work with) and version control your entire system. 
if this was done it would be nice to add a item type that would referance 
a file in a distro package to save space. it sounds like you could run a 
git checkin daily (as part of the updatedb run for example) at very little 
cost.

for that matter by comparing the git data between servers (or between a 
server and an archive) you could easily use it to detect tampering.

sounds very interesting, but I'm going to let things settle down a bit 
before I try to tackle this (but you guys who ar working on it shoudl feel 
free to add the couple options nessasary to implement this if you want ;-)

David Lang
On Sun, 10 Apr 2005, Christopher Li wrote:
Date: Sun, 10 Apr 2005 17:28:50 -0400
From: Christopher Li <[EMAIL PROTECTED]>
To: Linus Torvalds <[EMAIL PROTECTED]>
Cc: Paul Jackson <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], linux-kernel@vger.kernel.org
Subject: Re: more git updates..
I see. It just need some basic set operation (+, -, and)
and some way to select a set:
 sha5--->
/
   /
sha1-->sha2-->sha3--
  \/
   \  /
>sha4
list sha1   # all the file list in changeset sha1
# {sha1}
list sha1,sha1  # same as above
list sha1,sha2  # all the file list in between changeset sha1
# and changeset sha2
# {sha1, sha2} in example
list sha1,sha3  # {sha1, sha2, sha3, sha4}
list sha1,any   # all the change set reachable from sha1.
{sha1, ... sha5, ...}
new  sha1,sha2  # all the new file add between in sha1, sha2 (+)
changed  sha1,sha2  # add the changed file between sha1, sha2   (>) (<)
deleted  sha1,sha2  # add the deleted file between sha1, sha2(-)
before   time   # all the file before time
aftertime   # all the file after time
So in my example, the file I want to delete is :
{list hack1, base}+ {list hack2, base} ... {list hack6, base} \
- [list official_merge, base ]

On Sun, Apr 10, 2005 at 04:21:08PM -0700, Linus Torvalds wrote:

the official tree. It is more for my local version control.
I have a plan. Namely to have a "list-needed" command, which you give one
commit, and a flag implying how much "history" you want (*), and then it
spits out all the sha1 files it needs for that history.
Then you delete all the other ones from your SHA1 archive (easy enough to
do efficiently by just sorting the two lists: the list of "needed" files
and the list of "available" files).
Script that, and call the command "prune-tree" or something like that, and
you're all done.
(*) The amount of history you want might be "none", which is to say that
you don't want to go back in time, so you want _just_ the list of tree and
blob objects associated with that commit.
That will be {list head}
Or you might want a "linear"  history, which would be the longest path
through the parent changesets to the root.
That will be {list head,root}
Or you might want "all", which would follow all parents and all trees.
That will be {list any, root}
Or you might want to prune the history tree by date - "give me all
history, but cut it off when you hit a parent that was done more than 6
months ago".
That is {after -6month }
This "list-needed" thing is not just for pruning history either. If you
have a local tree "x", and you want to figure out how much of it you need
to send to somebody else who has an older tree "y", then what you'd do is
basically "list-needed x" and remove the set of "list-needed y". That
gives you the answer to the question "what's the minimum set of sha1 files
I need to send to the other guy so that he can re-create my top-of-tree".
That is {list x, any} - {list y, any}

My second plan is to make somebody else so fired up about the problem that
I can just sit back and take patches. That's really what I'm best at.
Sitting here, in the (rain) on the patio, drinking a foofy tropical drink,
and pressing the "apply" button. Then I take all the credit for my
incredible work.
Sounds like a good plan.
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
--
There are two ways of constructing a software design. One way is to make it so 
simple that there are obviously no deficiencies. And the other way is to make 
it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 

Re: read failed EINVAL with O_DIRECT flag

[Randy.Dunlap]

On Mon, 11 Apr 2005 21:14:17 +0200 Yves Crespin wrote:

| Hello,
| 
| Using O_DIRECT flag, read() failed and errno is EINVAL.
| kernel 2.4.22
| Filesystem Ext3 mount on /home
| What's wrong ?
| Thanks

In fs/buffer.c, it wants the buffer & the length (size) to be aligned:

function: brw_kiovec()

/* 
 * First, do some alignment and validity checks 
 */
for (i = 0; i < nr; i++) {
iobuf = iovec[i];
if ((iobuf->offset & (size-1)) ||
(iobuf->length & (size-1)))
return -EINVAL;
if (!iobuf->nr_pages)
panic("brw_kiovec: iobuf not initialised");
}

so in your program, malloc() the buf [pointer] (larger than needed)
and then align it to a page boundary and pass that aligned pointer
to read().


| /* --- start code --- */
| #include 
| #include 
| #include 
| #include 
| #include 
| #include 
| #include 
| 
| #define O_BINARY0
| 
| int main(int argc,char *argv[])
| {
| struct statsbuf;
| charbuf[8192];
| intopenFlags;
| intfd;
| intnb;
| intsize;
| 
| if (argc!=2){
| printf("Missing file name\n");
| exit(2);
| }
| openFlags = O_RDWR|O_BINARY|O_NOCTTY;
| openFlags |= O_DIRECT;/* Not POSIX */
| fd = open(argv[1],openFlags,0666);
| if (fd==-1){
| printf("open failed [%s] %#o %#o errno 
| %d\n",argv[1],openFlags,0666,errno);
| exit(1);
| }
| if (fstat(fd,)<0){
| printf("fstat failed\n");
| exit(1);
| }
| size = sbuf.st_blksize;
| if (size > sizeof(buf)){
| printf("Page size too big\n");
| exit(3);
| }
| if (size > sbuf.st_size){
| printf("File too small\n");
| exit(3);
| }
| nb = read(fd,buf,size);
| if (nb != size){
| printf("read failed fd %d size %d nb %d errno 
| %d\n",fd,size,nb,errno);
| exit(1);
| }
| if (close(fd)){
| printf("close failed\n");
| exit(1);
| }
| return 0;
| }

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

[ANNOUNCE 6/6] Linux-iSCSI High-Performance Initiator

[Alex Aizman]

Documentation/scsi/iscsi.txt
Signed-off-by: Alex Aizman <[EMAIL PROTECTED]>
Signed-off-by: Dmitry Yusupov <[EMAIL PROTECTED]>





diff -Nru linux-2.6.12-rc2.orig/Documentation/scsi/iscsi.txt 
linux-2.6.12-rc2.dima/Documentation/scsi/iscsi.txt
--- linux-2.6.12-rc2.orig/Documentation/scsi/iscsi.txt  1969-12-31 
16:00:00.0 -0800
+++ linux-2.6.12-rc2.dima/Documentation/scsi/iscsi.txt  2005-04-11 
18:13:12.0 -0700
@@ -0,0 +1,292 @@
+=
+
+Linux* Open-iSCSI
+
+=
+
+April 11, 2005
+
+Contents
+
+
+- 1. In This Release
+- 2. Introduction
+- 3. Installation
+- 4. Open-iSCSI daemon
+- 5. Open-iSCSI Configuration Utility
+- 6. Configuration
+- 7. Getting Started
+- 8. TBD
+- Appendix A. SendTargets snapshot.
+
+
+
+1. In This Release
+==
+
+This file describes the Linux* Open-iSCSI Initiator. The software was
+tested on AMD Opteron (TM) and Intel Xeon (TM). 
+
+The latest development release is available at:
+http://linux-iscsi.sf.net
+
+For questions, comments, contributions send e-mail to:
[EMAIL PROTECTED] and [EMAIL PROTECTED] 
+
+1.1. Features
+
+- highly optimized and very small-footprint data path;
+- multiple outstanding R2Ts;
+- persistent configuration database;
+- SendTargets discovery;
+- CHAP;
+- PDU header Digest;
+- multiple sessions;
+- multi-connection sessions.
+
+For the most recent list of features please refer to:
+http://www.open-iscsi.org/cgi-bin/wiki.pl/Roadmap
+
+
+
+2. Introduction
+===
+
+Open-iSCSI project is a high-performance, transport independent,
+multi-platform implementation of RFC3720 iSCSI.
+
+Open-iSCSI is partitioned into user and kernel parts.
+
+The kernel portion of Open-iSCSI is a from-scratch code
+licensed under GPL. The kernel part implements iSCSI data path
+(that is, iSCSI Read and iSCSI Write), and consists of two
+loadable modules: iscsi_if.ko and iscsi_tcp.ko.
+
+User space contains the entire control plane: configuration
+manager, iSCSI Discovery, Login and Logout processing,
+connection-level error processing, Nop-In and Nop-Out handling,
+and (in the future:) Text processing, iSNS, SLP, Radius, etc.
+
+The user space Open-iSCSI consists of a daemon process called
+iscsid, and a management utility iscsiadm.
+
+
+3. Installation
+===
+
+As of today, the Open-iSCSI Initiator requires a host running the
+Linux operating system with kernel version 2.6.11, or later. You need to
+enable "Cryptographic API" under "Cryptographic options" in the
+kernel config. You also need to enable "CRC32c CRC algorithm" if
+you use header or data digests. They are the kernel options,
+CONFIG_CRYPTO and CONFIG_CRYPTO_CRC32C, respectively.
+
+Compilation of the kernel Opne-iSCSI modules requires a path
+to kernel sources:
+
+   make KSRC=
+
+or cross-compilation:
+
+   make KSRC= KARCH="ARCH=um"
+
+
+4. Open-iSCSI daemon
+
+
+The daemon implements control path of iSCSI protocol, plus some management
+facilities. For example, the daemon could be configured to automatically 
+re-start discovery at startup, based on the contents of persistent 
+iSCSI database (see next section).
+
+For help, run:
+
+   ./iscsid --help
+
+Usage: iscsid [OPTION]
+
+  -c, --config=[path] Execute in the config file (/etc/iscsid.conf).
+  -f, --foregroundrun iscsid in the foreground
+  -d, --debug debuglevel  print debugging information
+  -u, --uid=uid   run as uid, default is current user
+  -g, --gid=gid   run as gid, default is current user group
+  -h, --help  display this help and exit
+  -v, --version   display version and exit
+
+
+
+5. Open-iSCSI Configuration Utility
+===
+
+Open-iSCSI persistent configuration is implemented as a DBM database
+available on all Linux installations.
+
+The database contains two tables:
+
+- Discovery table (discovery.db);
+- Node table (node.db).
+
+The regular place for iSCSI database files: /var/db/iscsi/*.db
+
+The iscsiadm utility is a command-line tool to manage (update, delete,
+insert, query) the persistent database.
+
+The utility presents set of operations that a user can perform 
+on iSCSI nodes, sessions, connections, and discovery records.
+
+Note that some of the iSCSI Node and iSCSI Discovery operations 
+do not require iSCSI daemon (iscsid) loaded.
+
+For help, run:
+
+   ./iscsiadm --help
+
+Usage: iscsiadm [OPTION]
+
+  -m, --mode  specify operational mode op = 
+  -m discovery --type=[type] --portal=[ip:port] --login
+  perform [type] discovery for target portal with
+  ip-address [ip] and port [port]. Initiate Login for
+  

Re: 2.6.12-rc2-mm3

[Juergen Kreileder]

Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:

> On Tue, 2005-04-12 at 03:18 +0200, Juergen Kreileder wrote:
>> Andrew Morton <[EMAIL PROTECTED]> writes:
>>
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>>
>> I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
>>
>> 2.6.11-mm4 works fine but all 2.6.12 versions I've tried (all since
>> -rc1-mm3) lock up randomly.  The easiest way to reproduce the
>> problem seems to be running Azareus.  So it might be network
>> related, but I'm not 100% sure about that, there was a least one
>> deadlock with virtually no network usage.
>
> Hrm... I just noticed you have CONFIG_PREEMPT enabled... Can you
> test without it and let me know if it makes a difference ?

IIRC I had disabled that for rc2-mm2 and it didn't make a difference.
I'll disable it again when I try older versions.

I just got another crash with rc2-mm3.  The crash was a bit different
this time, I still could move the mouse pointer and the logs contained
some info:

Badness in slb_flush_and_rebolt at arch/ppc64/mm/slb.c:52
[c0017690b860] [00069a73] 0x69a73 (unreliable)
[c0017690b900] [c003b300] .__schedule_tail+0x9c/0x1b4
[c0017690b9a0] [c03162b0] .schedule+0x324/0x610
[c0017690ba80] [c03177e8] .schedule_timeout+0xfc/0x104
[c0017690bb60] [c00b6118] .do_select+0x278/0x4c4
[c0017690bcb0] [c00d6f4c] .compat_sys_select+0x390/0x690
[c0017690bdc0] [c0019eb8] .ppc32_select+0x14/0x28
[c0017690be30] [c000da00] syscall_exit+0x0/0x18
Badness in slb_flush_and_rebolt at arch/ppc64/mm/slb.c:52
Call Trace:
[c0016fe23860] [0413] 0x413 (unreliable)
[c0016fe23900] [c003b300] .__schedule_tail+0x9c/0x1b4
[c0016fe239a0] [c03162b0] .schedule+0x324/0x610
[c0016fe23a80] [c0317774] .schedule_timeout+0x88/0x104
[c0016fe23b60] [c00b6118] .do_select+0x278/0x4c4
[c0016fe23cb0] [c00d6f4c] .compat_sys_select+0x390/0x690
[c0016fe23dc0] [c0019eb8] .ppc32_select+0x14/0x28
[c0016fe23e30] [c000da00] syscall_exit+0x0/0x18
Badness in slb_flush_and_rebolt at arch/ppc64/mm/slb.c:52
Call Trace:
[c00175d2b860] [0163] 0x163 (unreliable)
[c00175d2b900] [c003b300] .__schedule_tail+0x9c/0x1b4
[c00175d2b9a0] [c03162b0] .schedule+0x324/0x610
[c00175d2ba80] [c0317774] .schedule_timeout+0x88/0x104
[c00175d2bb60] [c00b6118] .do_select+0x278/0x4c4
[c00175d2bcb0] [c00d6f4c] .compat_sys_select+0x390/0x690
[c00175d2bdc0] [c0019eb8] .ppc32_select+0x14/0x28
[c00175d2be30] [c000da00] syscall_exit+0x0/0x18
Badness in slb_flush_and_rebolt at arch/ppc64/mm/slb.c:52
Call Trace:
[c00178a17860] [0eb1] 0xeb1 (unreliable)
[c00178a17900] [c003b300] .__schedule_tail+0x9c/0x1b4
[c00178a179a0] [c03162b0] .schedule+0x324/0x610
[c00178a17a80] [c0317774] .schedule_timeout+0x88/0x104
[c00178a17b60] [c00b6118] .do_select+0x278/0x4c4
[c00178a17cb0] [c00d6f4c] .compat_sys_select+0x390/0x690
[c00178a17dc0] [c0019eb8] .ppc32_select+0x14/0x28
[c00178a17e30] [c000da00] syscall_exit+0x0/0x18
Badness in slb_flush_and_rebolt at arch/ppc64/mm/slb.c:52
Call Trace:
[c001767fba10] [1bca] 0x1bca (unreliable)

and so on until the machine switched into jet-fighter mode after:

[c0016f887a10] [0001fc8c] 0x1fc8c (unreliable)
[c0016f887ab0] [c003b300] .__schedule_tail+0x9c/0x1b4
[c0016f887b50] [c03162b0] .schedule+0x324/0x610
[c0016f887c30] [c0317774] .schedule_timeout+0x88/0x104
[c0016f887d10] [c00b6bb4] .sys_poll+0x3b8/0x4dc
[c0016f887e30] [c000da00] syscall_exit+0x0/0x18
Oops: Machine check, sig: 0 [#1]


Machine info:
* PowerMac7,2 with 2x 2GHz
* 4GB RAM
* 2 disks with ext3 partitions on top of LVM2
* Radeon 9800Pro with radeonfb and X (from Debian sid) at 1600x1200
* USB Mouse via evdev
* Bluetooth enabled but unused
* Firewire disabled
* No PCI cards
* Kernel compiled with gcc-3.4.2


Juergen

-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-rc2-mm3

[Andrew Morton]

Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> - The anticipatory I/O scheduler has always been fairly useless with SCSI
>disks which perform tagged command queueing.  There's a patch here from 
> Jens
>which is designed to fix that up by constraining the number of requests
>which we'll leave pending in the device.
> 
>The depth currently defaults to 1.  Tunable in
>/sys/block/hdX/queue/iosched/queue_depth
> 
>This patch hasn't been performance tested at all yet.  If you think it is
>misbehaving (the usual symptom is processes stuck in D state) then please
>report it, then boot with `elevator=cfq' or `elevator=deadline' to work
>around it.

So it turns out that patch was broken.  I've fixed it locally and the
results are good, but odd.

The machine is a 4GB x86_64 with aic79xx controllers and MAXTOR
ATLAS10K4_73WLS disks.  ext2 filesystem.

The workload is continuous pagecache writeback versus
read-lots-of-little-files:

while true
do
dd if=/dev/zero of=/mnt/sdb2/x bs=40M count=100 conv=notrunc
done

versus

find /mnt/sdb2/linux-2.4.25 -type f | xargs cat > /dev/null

we measure how long the find+cat takes.

2.6.12-rc2, as, tcq depth=2:7.241 seconds
2.6.12-rc2, as, tcq depth=64:   12.172 seconds
2.6.12-rc2+patch,as,tcq depth=64:   7.199 seconds
2.6.12-rc2, cfq2,   tcq depth=64:   much more than 5 minutes
2.6.12-rc2, cfq3,   tcq depth=64:   much more than 5 minutes

So

- The effects of tcq on AS are much less disastrous than I thought they
  were.  Do I have the wrong workload?  Memory fails me.  Or did we fix the
  anticipatory scheduler?

- as-limit-queue-depth.patch fixes things right up anyway.  Seems to be
  doing the right thing.  

- CFQ is seriously, seriously read-starved on this workload.

CFQ2:

procs ---memory-- ---swap-- -io --system-- cpu
 r  b   swpd   free   buff  cache   si   sobibo   incs us sy id wa
 2  3   1116  25504   4868 385400840 8 61976 1112   291  0  4 39 58
 0  4   1112  24992   4868 38551200  568 4 53804 1124   452  0  4 54 43
 0  4   1112  24032   4868 385600400 8 44652 1110   303  0  3 45 53
 0  2   1112  25912   4872 385416400 4 51108 1122   321  0  3 52 45
 2  3   1112  24312   4872 38557280032 52240 1113   300  0  4 44 52
 1  3   1112  25728   4876 38544320020 48128 1118   296  0  3 58 39
 0  2   1112  23872   4876 385633600 4 48136 1116   288  0  4 47 49
 0  4   1112  25856   4876 38543000416 50260 1117   294  0  3 55 42

CFQ3:

procs ---memory-- ---swap-- -io --system-- cpu
 r  b   swpd   free   buff  cache   si   sobibo   incs us sy id wa
 1  5   1008  25888   4204 38458200012 50544 1119   116  0  3 49 48
 0  5   1008  24096   4204 384752000 8 51200 1112   110  0  3 49 48
 0  5   1008  25824   4204 384582000 8 54816 1117   120  0  4 49 48
 0  5   1008  25440   4204 384616000 8 52880 1113   115  0  3 49 48
 0  5   1008  25888   4208 38457480016 51024 1121   116  0  3 49 48


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

[ANNOUNCE 4/6] Linux-iSCSI High-Performance Initiator

[Alex Aizman]

 drivers/scsi/Makefile changes (added iscsi_if and iscsi_tcp).
 Signed-off-by: Alex Aizman <[EMAIL PROTECTED]>
 Signed-off-by: Dmitry Yusupov <[EMAIL PROTECTED]>






--- linux-2.6.12-rc2.orig/drivers/scsi/Makefile 2005-03-01 23:38:19.0 
-0800
+++ linux-2.6.12-rc2.dima/drivers/scsi/Makefile 2005-04-11 18:13:12.0 
-0700
@@ -30,6 +30,8 @@
 obj-$(CONFIG_SCSI_FC_ATTRS)+= scsi_transport_fc.o
 obj-$(CONFIG_SCSI_ISCSI_ATTRS) += scsi_transport_iscsi.o
 
+obj-$(CONFIG_ISCSI_IF) += iscsi_if.o
+obj-$(CONFIG_ISCSI_TCP)+= iscsi_tcp.o
 obj-$(CONFIG_SCSI_AMIGA7XX)+= amiga7xx.o   53c7xx.o
 obj-$(CONFIG_A3000_SCSI)   += a3000.o  wd33c93.o
 obj-$(CONFIG_A2091_SCSI)   += a2091.o  wd33c93.o

Re: 2.6.12-rc2-mm3

[Benjamin Herrenschmidt]

On Tue, 2005-04-12 at 03:18 +0200, Juergen Kreileder wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
> 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
> 
> I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
> 
> 2.6.11-mm4 works fine but all 2.6.12 versions I've tried (all since
> -rc1-mm3) lock up randomly.  The easiest way to reproduce the problem
> seems to be running Azareus.  So it might be network related, but I'm
> not 100% sure about that, there was a least one deadlock with
> virtually no network usage.
> 
> BTW, what's the SysRq key on recent Apple USB keyboards?  Alt/Cmd-F13
> doesn't work for me.
> 

Hrm... I just noticed you have CONFIG_PREEMPT enabled... Can you test
without it and let me know if it makes a difference ?

Ben.


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

[ANNOUNCE 3/6] Linux-iSCSI High-Performance Initiator

[Alex Aizman]

 drivers/scsi/Kconfig changes.
 Signed-off-by: Alex Aizman <[EMAIL PROTECTED]>
 Signed-off-by: Dmitry Yusupov <[EMAIL PROTECTED]>






diff -Nru --exclude 'iscsi*' --exclude Makefile 
linux-2.6.12-rc2.orig/drivers/scsi/Kconfig 
linux-2.6.12-rc2.dima/drivers/scsi/Kconfig
--- linux-2.6.12-rc2.orig/drivers/scsi/Kconfig  2005-04-11 17:13:39.0 
-0700
+++ linux-2.6.12-rc2.dima/drivers/scsi/Kconfig  2005-04-11 18:13:12.0 
-0700
@@ -185,6 +185,45 @@
  there should be no noticeable performance impact as long as you have
  logging turned off.
 
+config ISCSI_IF
+   tristate "iSCSI Open Transport Interface"
+   depends on SCSI && INET
+   ---help---
+   This driver manages multiple iSCSI transports. This module is required
+   for normal iscsid operation.
+
+   To compile this driver as a module, choose M here: the
+   module will be called iscsi_if.
+
+   See more detailed information here:
+
+   http://linux-iscsi.sf.net
+
+config ISCSI_TCP
+   tristate "iSCSI Initiator over TCP/IP"
+   depends on ISCSI_IF
+   default y
+   select CRYPTO
+   select CRYPTO_MD5
+   select CRYPTO_CRC32C
+   select SCSI_ISCSI_ATTRS
+   ---help---
+   The iSCSI Driver provides a host with the ability to access storage
+   through an IP network. The driver uses the iSCSI protocol to transport
+   SCSI requests and responses over a TCP/IP network between the host
+   (the "initiator") and "targets".  Architecturally, the iSCSI driver
+   combines with the host's TCP/IP stack, network drivers, and Network
+   Interface Card (NIC) to provide the same functions as a SCSI or a
+   Fibre Channel (FC) adapter driver with a Host Bus Adapter (HBA).
+
+   To compile this driver as a module, choose M here: the
+   module will be called iscsi_tcp.
+ 
+   The userspace component needed to initialize the driver, documentation,
+   and sample configuration files can be found here:
+ 
+   http://linux-iscsi.sf.net
+
 menu "SCSI Transport Attributes"
depends on SCSI
 

[ANNOUNCE 2/6] Linux-iSCSI High-Performance Initiator

[Alex Aizman]

  Common header files:
  - iscsi_ifev.h (user/kernel events).
  - iscsi_if.h (user/kernel #defines);
  - iscsi_iftrans.h (iscsi transport interface);
  - iscsi_proto.h (RFC3720 #defines and types).
  Signed-off-by: Alex Aizman <[EMAIL PROTECTED]>
  Signed-off-by: Dmitry Yusupov <[EMAIL PROTECTED]>






diff -Nru linux-2.6.12-rc2.orig/include/scsi/iscsi_ifev.h 
linux-2.6.12-rc2.dima/include/scsi/iscsi_ifev.h
--- linux-2.6.12-rc2.orig/include/scsi/iscsi_ifev.h 1969-12-31 
16:00:00.0 -0800
+++ linux-2.6.12-rc2.dima/include/scsi/iscsi_ifev.h 2005-04-11 
18:13:12.0 -0700
@@ -0,0 +1,118 @@
+/*
+ * iSCSI Kernel/User Interface Events
+ *
+ * Copyright (C) 2005 Dmitry Yusupov, Alex Aizman
+ * maintained by [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published
+ * by the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * See the file COPYING included with this distribution for more details.
+ */
+
+#ifndef ISCSI_IFEV_H
+#define ISCSI_IFEV_H
+
+enum iscsi_uevent_e {
+   ISCSI_UEVENT_UNKNOWN= 0,
+
+   /* down events */
+   ISCSI_UEVENT_CREATE_SESSION = UEVENT_BASE + 1,
+   ISCSI_UEVENT_DESTROY_SESSION= UEVENT_BASE + 2,
+   ISCSI_UEVENT_CREATE_CNX = UEVENT_BASE + 3,
+   ISCSI_UEVENT_DESTROY_CNX= UEVENT_BASE + 4,
+   ISCSI_UEVENT_BIND_CNX   = UEVENT_BASE + 5,
+   ISCSI_UEVENT_SET_PARAM  = UEVENT_BASE + 6,
+   ISCSI_UEVENT_START_CNX  = UEVENT_BASE + 7,
+   ISCSI_UEVENT_STOP_CNX   = UEVENT_BASE + 8,
+   ISCSI_UEVENT_SEND_PDU   = UEVENT_BASE + 9,
+   ISCSI_UEVENT_TRANS_LIST = UEVENT_BASE + 10,
+
+   /* up events */
+   ISCSI_KEVENT_RECV_PDU   = KEVENT_BASE + 1,
+   ISCSI_KEVENT_CNX_ERROR  = KEVENT_BASE + 2,
+   ISCSI_KEVENT_IF_ERROR   = KEVENT_BASE + 3,
+};
+
+struct iscsi_uevent {
+   uint32_t type; /* k/u events type */
+   uint32_t iferror; /* carries interface or resource errors */
+   uint64_t transport_handle;
+
+   union {
+   /* messages u -> k */
+   struct msg_create_session {
+   uint64_tsession_handle;
+   uint32_tinitial_cmdsn;
+   } c_session;
+   struct msg_destroy_session {
+   uint64_tsession_handle;
+   uint32_tsid;
+   } d_session;
+   struct msg_create_cnx {
+   uint64_tsession_handle;
+   uint64_tcnx_handle;
+   uint32_tcid;
+   uint32_tsid;
+   } c_cnx;
+   struct msg_bind_cnx {
+   uint64_tsession_handle;
+   uint64_tcnx_handle;
+   uint32_ttransport_fd;
+   uint32_tis_leading;
+   } b_cnx;
+   struct msg_destroy_cnx {
+   uint64_tcnx_handle;
+   uint32_tcid;
+   } d_cnx;
+   struct msg_send_pdu {
+   uint32_thdr_size;
+   uint32_tdata_size;
+   uint64_tcnx_handle;
+   } send_pdu;
+   struct msg_set_param {
+   uint64_tcnx_handle;
+   uint32_tparam; /* enum iscsi_param */
+   uint32_tvalue;
+   } set_param;
+   struct msg_start_cnx {
+   uint64_tcnx_handle;
+   } start_cnx;
+   struct msg_stop_cnx {
+   uint64_tcnx_handle;
+   uint32_tflag;
+   } stop_cnx;
+   } u;
+   union {
+   /* messages k -> u */
+   uint64_thandle;
+   int retcode;
+   struct msg_create_session_ret {
+   uint64_thandle;
+   uint32_tsid;
+   } c_session_ret;
+   struct msg_recv_req {
+   uint64_trecv_handle;
+   uint64_tcnx_handle;
+   } recv_req;
+   struct msg_cnx_error {
+   uint64_t

[ANNOUNCE 0/6] Linux-iSCSI High-Performance Initiator

[Alex Aizman]

This is to announce Linux-iSCSI project: High-Performance iSCSI 
Initiator v5.0.0.2.

The corresponding user space tools:
http://sourceforge.net/project/showfiles.php?group_id=26396
1. Performance Results
=
1.1 SETUP

See http://www.open-iscsi.org/cgi-bin/wiki.pl/Performance-setup
1.2 SUMMARY

256K block Write: 810 MBytes/sec
256K blocks Read: 550 MBytes/sec
1K block Read: 75,000 IOPS
1.3 Disktest results
==
256K block size WRITE operation:

Session #0: /dev/sda
| 2005/04/11-09:39:42 | STAT  | 9796 | v1.1.12 | /dev/sda | Write 
throughput: 430646600.1B/s (410.70MB/s), IOPS 1642.9/s.
| 2005/04/11-09:39:43 | STAT  | 9796 | v1.1.12 | /dev/sda | Write 
throughput: 430876514.5B/s (410.92MB/s), IOPS 1643.8/s.

Session #1: /dev/sdb
| 2005/04/11-09:40:11 | STAT  | 9811 | v1.1.12 | /dev/sdb | Write 
throughput: 419816033.3B/s (400.37MB/s), IOPS 1601.6/s.
| 2005/04/11-09:40:12 | STAT  | 9811 | v1.1.12 | /dev/sdb | Write 
throughput: 419868739.1B/s (400.42MB/s), IOPS 1601.8/s.

Total: ~810 MBytes/sec from a single iSCSI Initiator.
256K block size READ operation:

Session #0: /dev/sda
| 2005/04/11-09:47:00 | STAT  | 9988 | v1.1.12 | /dev/sda | Read 
throughput: 278883766.9B/s (265.96MB/s), IOPS 1065.3/s.
| 2005/04/11-09:47:01 | STAT  | 9988 | v1.1.12 | /dev/sda | Read 
throughput: 281018368.0B/s (268.00MB/s), IOPS 1073.2/s.

Session #1: /dev/sdb
| 2005/04/11-09:47:04 | STAT  | 9976 | v1.1.12 | /dev/sdb | Read 
throughput: 294106843.4B/s (280.48MB/s), IOPS 1122.6/s.
| 2005/04/11-09:47:05 | STAT  | 9976 | v1.1.12 | /dev/sdb | Read 
throughput: 294842094.9B/s (281.18MB/s), IOPS 1125.4/s.

Total: ~550 MBytes/sec from single iSCSI Initiator machine
1K block size READ operation:
-
Session #0: /dev/sda
| 2005/04/11-09:57:28 | STAT  | 10067 | v1.1.12 | /dev/sda | Read 
throughput: 38327973.2B/s (36.55MB/s), IOPS 37430.2/s.
| 2005/04/11-09:57:29 | STAT  | 10067 | v1.1.12 | /dev/sda | Read 
throughput: 38321291.3B/s (36.55MB/s), IOPS 37423.7/s.

Session #1: /dev/sdb
| 2005/04/11-09:57:30 | STAT  | 1 | v1.1.12 | /dev/sdb | Read 
throughput: 39967796.7B/s (38.12MB/s), IOPS 39031.5/s.
| 2005/04/11-09:57:31 | STAT  | 1 | v1.1.12 | /dev/sdb | Read 
throughput: 40131755.9B/s (38.27MB/s), IOPS 39191.6/s.

Total: ~76,000 IOPS from single iSCSI Initiator machine
2. Patches

The following 6 patches alltogether represent the Open-iSCSI Initiator:
Patch 1:
SCSI LLDD consists of 3 files:
- iscsi_if.c (iSCSI open interface over netlink);
- iscsi_tcp.[ch] (iSCSI transport over TCP/IP).
Patch 2:
Common header files:
- iscsi_if.h (user/kernel #defines);
- iscsi_proto.h (RFC3720 #defines and types);
- iscsi_iftrans.h (iscsi transport interface).
 - iscsi_ifev.h (user/kernel events).
Patch 3:
drivers/scsi/Kconfig changes.
Patch 4:
drivers/scsi/Makefile changes.
Patch 5:
include/linux/netlink.h changes (added new protocol NETLINK_ISCSI)
Patch 6:
Documentation/scsi/iscsi.txt
3. Changelog since v5.0.0.1 (Open-iSCSI v 0.1)
===
* ERL=0 in kernel support
* fixed scsi discovery
* highmem fix
* more acurate asserts
* host-put fix
* r2t vs. sendhdr race fix
* minor fixes
* discovery fix, small write cleanup
* serialization between conn_destroy(), xmitworker() and data_recv()
* xmit code cleanup
* read regression fix
* more accurate command line handling
* adding tname to the node rec key
* mempool preallocation
* recv pdu OOM-safe
* fix r2t->sg
* buf_left() fix
* trim skb on alloc
* immqueue leak fix
* more accurate error reporting
* do not check for LUN on R2T receive in ERL=0.
* flush xmit queues on conn_stop()
* Ming's patch to have default port for discovery
* do not close session on bad cmd_rsp() from target
* write optimization: send iSCSI PDU header as a part of the same TCP 
payload
* ctask->sg vs. sg_count cleanup
* refcounting on session create/destroy fix
* unblock eh_abort() in case of TMF timedout
* 256 LUNS support fix
* race fixed: rmmod concurrent with session_destroy()
* cleanup comments (Matt Mackall) - implemented
* recovery optimization: avoid big allocations on re-open
* initial scsi_transport_iscsi implementation
* introduced host, session and connection contexts on the iscsi_if level
* iscsi_if parameters validation
* no mallocs on datapath during netlink operations in user-space for 
down calls
* initial resource error detection
* task abort sent after session gets reopened - fixed
* greater than 2TB support
* iscsid fork now works.
* to sync caches, delete session's LUNs before actual logout task
* added get_param(); used in iscsi transport class
* regression.sh: device parameter added
* transport register/unregister path cleanup
* transport api vs. user/kernel definitions split
* idbm node and discovery records version check
* IPC via netlink + mempool_zones initial implementation
* immediate task's data pool preallocation
* added 

Re: New SCM and commit list

[Adam J. Richter]

On 2005-04-11, Daniel Barkalow wrote:
>If merge took trees instead of single files, and had some way of detecting
>renames (or it got additional information about the differences between
>files), would that give BK-quality performance? Or does BK also support
>cases like:
>
>orig ---> first ---> first-merge -
> |/   \
> |--> second - -> final
> |\   /
> |--> third ---> third-merge -
>
>where the final merge requires, for complete cleanliness, a comparison of
>more than 3 states (since some changes will have orig as the common
>ancestor and some will have second).

With 3-way merge and the ability to regenerate the relevant
files from each step, this should be easy to handle as long
as you have a list of which patches are considered to have been
duplicated.  Let's detail your example:

orig ---> first 1a 1b 1c ---> first-merge - 1d 1e
 |  /\
 |--> second 2a 2b 2c -   -> final
 |  \/
 |--> third 3a 3b 3c ---> third-merge - 3d 3e

Here, 1a, 1b, etc. refer to specific states of the source tree.
I will refer to differences by a notation like "1a->1b", which
is the difference to go from snapshot 1a to 1b.  All that the
merge algorithm for the final merge needs to know is that the
ends of the branches (that is, 1e and 3e) both contain the
following diffs:

orig->2a
2a->2b
2b->2c

The function merge(orig, ver1, ver2) can try to reverse
the duplicate merges in one of the branches:

1e' = merge( 1e, 2c->2b);
1e'' = merge(1e', 2b->2a);
1e''' = merge(1e'', 2a->orig);
return merge(1e''', 2c->3e)

Of course, conflicts can happen, but that can happen
in any merge.  There are also other ways to calculate the
merge and because there are different ways one can write a
merge function, it is possible that merging in a different
order might produce slightly different results.  For example,
it would be possible to reverse the dpulicates in your "third merge"
branch instead of your "first merge" branch, or one could
reconstruct a branch without the duplicated merges by executing
the other changes forward from a common ancestor, like so:

1e''' = merge(orig, 3d->3e);

...regardless, the point is that all the information
that is absolutely needed is a list of instance of diffs
to be skipped.  It is not even necessary that the changes
have such a clearly explainable ancestory as that you have
described.  All the merge program needs to know are the changes
to be skipped, although information like changes the skipped
patches are duplicating may be useful for things like trying
to reverse a patch in your "third-merge" branch in your
example if reverseing the patch in "first-merge" fails.

I believe that at least bitkeeper, darcs, a free python-based
system that I can't remember at the moment, and possibly arch do this
sort of machination already.


>Does this happen in real life? [...]

Yes.  Both individual users and Linux distributions incorporate
patches that they think are useful to them and then futher patches
that they develop.  The time costs of rejecting such patches would
likely be paid for by other integration or development work not being
done.

>It seems like sane development processes
   
>wouldn't have multiple mainline-candidate patch sets including the same
>patches, if for no other reason than that, should the merge fail, nobody
>with any clue about the original patches would be anywhere nearby.

If you could avoid prejudicial subjective adjectives, it
it would make it easier for the saneness or insaneness of an
approach to be apparent just by discussing your more objective criteria,
like the remainder of your sentence, which is where the focus should
be.

(1) Does allowing duplicate patches really mean that
   "nobody with any clue about the original patches would be
   anywhere near by?"  What attracts these clueful people
   just by third parties having to rebase their patches?

(2) Does this supposed benefit outweigh the cost of rejecting
many patches unnecessarily?  I know from my own experience
that I have either given up on or had to put into a very low
priority mode at least 66% of the patches that I haven't
gotten integrated, but which I am confident the kernel
would be better having (e.g.: devfs shrink, lookup()
trapping, ipv4 as a loadable (not not yet removable) module,
sysfs memory shrink, factoring much of the DMA mapping to
the common bus code from individual drivers, fewer kmap's
in crypto, I could go on).

>It
>seems better to throw something back to someone to 

USB on zx5405us

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

USB isn't working on my zv5405us on a 2.6.10 ubuntu kernel.  Or on
gentoo.  Or anything.  It works in WindowsXP though.

I can extract the error from dmesg.

Here's ACPI first (ACPI works btw)

Nvidia board detected. Ignoring ACPI timer override.
ACPI: RSDP (v000 PTLTD ) @
0x000f7260
ACPI: RSDT (v001 PTLTDRSDT   0x0604  LTP 0x) @
0x1ff7a87e
ACPI: FADT (v001 NVIDIA CK8  0x0604 PTL_ 0x000f4240) @
0x1ff7ee13
ACPI: MADT (v001 NVIDIA NV_APIC_ 0x0604  LTP 0x) @
0x1ff7ee87
ACPI: BOOT (v001 PTLTD  $SBFTBL$ 0x0604  LTP 0x0001) @
0x1ff7eee1
ACPI: SSDT (v001 PTLTD  POWERNOW 0x0604  LTP 0x0001) @
0x1ff7ef09
ACPI: DSDT (v001 NVIDIA  CK8 0x0604 MSFT 0x010e) @
0x
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: BIOS IRQ0 pin2 override ignored.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information

ACPI wakeup devices:
USB0 USB1 USB2 PS2K PS2M MAC0
ACPI: (supports S0 S3 S4 S5)

NFORCE3-150: IDE controller at PCI slot :00:08.0
NFORCE3-150: chipset revision 165
NFORCE3-150: not 100% native mode: will probe irqs later
NFORCE3-150: BIOS didn't set cable bits correctly. Enabling workaround.
NFORCE3-150: :00:08.0 (rev a5) UDMA133 controller
ide0: BM-DMA at 0x2080-0x2087, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x2088-0x208f, BIOS settings: hdc:DMA, hdd:pio



Finally, the USB messages themselves:

ohci_hcd :00:02.0: nVidia Corporation nForce3 USB 1.1
ohci_hcd :00:02.0: USB HC TakeOver failed!
ohci_hcd :00:02.0: can't reset
ohci_hcd :00:02.0: init :00:02.0 fail, -16
ohci_hcd: probe of :00:02.0 failed with error -16


lspci gives:

:00:02.0 USB Controller: nVidia Corporation nForce3 USB 1.1 (rev a5)
:00:02.1 USB Controller: nVidia Corporation nForce3 USB 1.1 (rev a5)
:00:02.2 USB Controller: nVidia Corporation nForce3 USB 2.0 (rev a2)


lsusb gives:

Bus 001 Device 001: ID :

Happens to be the USB2 stuff.


/proc/bus/usb/devices:

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480 MxCh= 6
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS= 8 #Cfgs=  1
P:  Vendor= ProdID= Rev= 2.06
S:  Manufacturer=Linux 2.6.10-5-amd64-generic ehci_hcd
S:  Product=nVidia Corporation nForce3 USB 2.0
S:  SerialNumber=:00:02.2
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=256ms


A mass storage device that works on my desktop doesn't work here.  It
works in Windows though.


- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
 -- Eric Steven Raymond
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCWz3chDd4aOud5P8RArB9AJ9AECG8+VrPUt8Zu7djzvl+Oi3lwgCfdD17
QbgPw+B1tbY66BjcFSpz9L4=
=0WK/
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Bug?] Keyboard Problem

[Dmitry Torokhov]

Hi,

On Monday 11 April 2005 18:45, Manu wrote:
> I'm currently using a 2.6.10 kernel (on a Debian Sarge, i386).
> 
> I've compiled a 2.6.11.5 and a 2.6.11.7 kernels and my keyboard (a
> sweex SILVER MULTIMEDIA KEYBOARD, SW-23 -- PS/2 105 keys -- a
> classical keyboard) doesn't work with these kernels.
...
> CONFIG_EMBEDDED=y
...
> #
> # Input I/O drivers
> #
> # CONFIG_GAMEPORT is not set
> CONFIG_SOUND_GAMEPORT=y
> CONFIG_SERIO=y
> # CONFIG_SERIO_I8042 is not set

You need to enable i8042 support - that's your keyboard controller.

Also, is there a specific reason why you enabled "embedded" mode? In
normal mode i8042 would be selected automatically...

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [INFO] Kernel strict versioning

[Franco \"Sensei\"]

Adrian Bunk wrote:
You say API but talk about ABI.
As long as we want to guarantee abi, we must use the same names. Api 
names, not implementation should be the same. You can't substitute 
get_namei with get_my_own_namei_version_I_know...

You said you've read stable_api_nonsense.txt .
stable_api_nonsense.txt talks about exactly these issues.
Yes.
The right solution for this issue is simple:
Get the module into the kernel.
Not that e.g. your pwc module will be in kernel 2.6.12.
Of course not... I don't expect nobody doing that! :)
Please check the facts:
QT 1 is _not_ binary compatible with QT 3.
There's a reason why the library changed the so-name...
Yes! That's my point. I didn't mean to say that the library has the same 
classes as the first version. Qt 3 is *not* compatible with Qt 1. Qt 
3.3.0 is binary compatible with qt 3.3.1, 3.3.2, and so on... unless 
someone makes an error.

My point is that versioning should be, in come cases, less restrictive, 
letting the 2.4 kernel being not compatible with 2.6, but all 2.6.x 
series being binary compatible with each other. If versioning means 
something, the last number should be a revision, additions, but since 
they belong to 2.6 version, they would be compatible.

Major kernel changes should probably result in major version change... 
I'm supposing it. Of course, note that ABI can be achieved stating that 
all the binaries must be compiled with the same gcc. So, the kernel 
module library could possibly be simply /lib/modules/2.6/.

I'm probably (surely) not getting the point about this issue. It's not 
that bad... I don't see awkward issues in guaranteeing 2.6, 2.8 and so 
on compatibility with the ``major second number''.

--
Sensei  
   
   
   


signature.asc
Description: OpenPGP digital signature

[ANNOUNCE] open-iscsi and linux-iscsi project teams have merged!

[linux-iscsi development team]

The linux-iscsi and open-iscsi developers would like to announce
that they have combined forces on a single iSCSI initiator effort!
This mail gives an overview of this combined effort and will be followed
by a set of iSCSI patches the combined team submits for review as a
candidate for inclusion into the mainline kernel.
Background
After some dialog with the developers on each team, it was decided
that although each team started out with independent code and some
differences in architecture, it was worth considering the possibility
of combining the two efforts into one.  Alternatives were considered
for the combined architecture of the two projects, including adding
an option for a kernel control plane.  After discussions, it was
decided by consensus that the open-iscsi architecture and code would
be the best starting point for the "next gen" linux-iscsi project.
The advantages of this starting point include open-iscsi's optimized
I/O paths that were built from scratch, as well as incorporation of
well tested iscsi-sfnet components for the control plane and userspace
components.  The combined open-iscsi and linux-iscsi teams believe
this will result in the highest performing and most stable iSCSI stack
for Linux.
Overview of Combined Project
This new combined effort will consist of the open-iscsi code and
developers moving over to the linux-iscsi project on sourceforge
(http://sourceforge.net/projects/linux-iscsi/).  The open-iscsi
(http://www.open-iscsi.org) architecture will be the basis for
the "next gen" of linux-iscsi, which will be numbered the
linux-iscsi-5.x release series.
Release Numbering
If you were following the open-iscsi series, here is the mapping
between the open-iscsi numbering and the linux-iscsi-5.x numbering:
- open-iscsi-0.2 == linux-iscsi-5.0.0.2
Kernel Submission
The kernel component of the first release in this linux-iscsi 5.x
series will follow shortly, and the combined teams wish to submit
this as a candidate for inclusion into the mainline kernel.
If you've reviewed the previous open-iscsi patch set, you'll find
that this patchset is very similar, with previous reviewer comments
incorporated.
Thanks.
- The combined open-iscsi and linux-iscsi teams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] ppc32: refactor FPU exception handling

[Benjamin Herrenschmidt]

On Mon, 2005-04-11 at 17:02 -0500, Kumar Gala wrote:
> Andrew,
> 
> Moved common FPU exception handling code out of head.S so it can be used 
> by several of the sub-architectures that might of a full PowerPC FPU.  
> 
> Also, uses new CONFIG_PPC_FPU define to fix alignment exception 
> handling for floating point load/store instructions to only occur if we 
> have a hardware FPU.
> 
> Signed-off-by: Jason McMullan <[EMAIL PROTECTED]>
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>


Andrew, please hold on this patch, it hasn't been properly discussed
with the relevant maintainer, that is Paul Mackerras.

I can see matter for debate in there, like the whole duplication of the
fast exception return path...

It's also touching quite sensitive bits of kernel code (head.S) that
needs careful auditing and testing before beeing pushed upstream.

Ben.


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

bkbits.net is down

[Larry McVoy]

Seems to have crashed, we don't know the cause yet.  Is there anyone who is
dependent on this tonight?  If so I'll drive down and fix it (yeah, very lame
of us, we moved it to a different rack which was too far away from our remote
power so I can't power cycle it remotely.  Our bad.)

Let me know, if I don't hear from anyone we'll get it in about 14 hours.  If
that's too long I'll understand, it's 20 minutes away and I can go deal.

--lm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] sched: unlocked context-switches

[Nick Piggin]

On Mon, 2005-04-11 at 18:06 -0700, David Mosberger wrote:

> I had to refresh my memory with a quick Google search that netted [1]
> (look for "Disable interrupts during context switch").  Actually, it
> wasn't really a deadlock, but rather a livelock, since a CPU got stuck
> on an infinite page-not-present loop.
> 
> Fundamentally, the issue was that doing the switch_mm() and
> switch_to() with interrupts enabled opened a window during which you
> could get a call to flush_tlb_mm() (as a result of an IPI).  This, in
> turn, could end up activating the wrong MMU-context, since the action
> of flush_tlb_mm() depends on the value of current->active_mm.  The
> problematic sequence was:
> 
> 1) schedule() calls switch_mm() which calls activate_context() to
>switch to the new address-space
> 2) IPI comes in and flush_tlb_mm(mm) gets called
> 3) "current" still points to old task and if "current->active_mm == mm",
>activate_mm() is called for the old address-space, resetting the
>address-space back to that of the old task
> 
> Now, Ingo says that the order is reversed with his patch, i.e.,
> switch_mm() happens after switch_to().  That means flush_tlb_mm() may
> now see a current->active_mm which hasn't really been activated yet.

If that did bother you, could you keep track of the actually
activated mm in your arch code? Or would that involve more arch
hooks and general ugliness in the scheduler?

Could you alternatively just disable interrupts across the switch?
I guess that would require a bit of #ifdefery in sched.c, which we
are trying to move away from, but it would be pretty minimal. Much
better than what is there now.

> That should be OK since it would just mean that we'd do an early (and
> duplicate) activate_context().  While it does not give me a warm and
> fuzzy feeling to have this inconsistent state be observable by
> interrupt-handlers (and, in particular, IPI-handlers), I don't see any
> problem with it off hand.
> 

IMO it *is* the direction we should move towards. That is,
liberating context switching from scheduler locking, and providing
a single set of semantics for the context switch hooks for all
architectures.

No rush, of course. But it would be good to get it in sooner
or later.

Nick



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-rc2-mm3

[Benjamin Herrenschmidt]

On Tue, 2005-04-12 at 03:18 +0200, Juergen Kreileder wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
> 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
> 
> I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
> 
> 2.6.11-mm4 works fine but all 2.6.12 versions I've tried (all since
> -rc1-mm3) lock up randomly.  The easiest way to reproduce the problem
> seems to be running Azareus.  So it might be network related, but I'm
> not 100% sure about that, there was a least one deadlock with
> virtually no network usage.
> 
> BTW, what's the SysRq key on recent Apple USB keyboards?  Alt/Cmd-F13
> doesn't work for me.

No idea about sysrq, i don't use it. However, I haven't experienced any
such problem with the various G5s we have here (and no other G5 user
reported such a problem).

So it would be useful if you could provide a bit more informations here
though. For example, what exact G5 model is this, do you have any 3rd
party PCI card, what video card are you using, can you reproduce the
crash in console mode, that sort of thing ...

Also, did you run a memtest equivalent on the machine ?

Finally, it would be useful if you could point out which specific patch
or bk snapshot, or at least -mm rev. introduced the bug. As I said
previously, you are the only one to report that and none of the G5s here
is showing such a problem.

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] drivers/block/ll_rw_blk.c: possible cleanups

[Adrian Bunk]

On Mon, Apr 11, 2005 at 08:12:34AM +0200, Jens Axboe wrote:
> On Sun, Apr 10 2005, Adrian Bunk wrote:
> > This patch contains the following possible cleanups:
> > - make needlessly global code static
> > - remove the following unused global functions:
> >   - blkdev_scsi_issue_flush_fn
> 
> Kill the function completely, it is not used anymore.
> 
> >   - __blk_attempt_remerge
> 
> Normally I would say leave that since it's part of the API, but lets
> just kill it. I don't envision any further users of the remerging
> attempts.
> 
> > - remove the following unused EXPORT_SYMBOL's:
> >   - blk_phys_contig_segment
> >   - blk_hw_contig_segment
> >   - blkdev_scsi_issue_flush_fn
> >   - __blk_attempt_remerge
> > 
> > Please review which of these changes make sense.
> 
> Looks fine to me, thanks. Can you send a new patch that kills
> blkdev_scsi_issue_flush_fn()?

I have a problem parsing your email.

Which parts of my patch are OK and which shouldn't be applied?
Or why do you want a separate blkdev_scsi_issue_flush_fn patch?

> Jens Axboe

cu
Adrian

-- 

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

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

Re: [patch] MAINTAINERS: remove obsolete ACP/MWAVE MODEM entry

[Adrian Bunk]

On Mon, Apr 11, 2005 at 05:39:32AM -0300, Marcelo Tosatti wrote:

> Adrian,

Hi Marcelo,

> ./drivers/char/mwave/Makefile also references Paul's email 
> address, at least in v2.4.

I've given up on removing and correcting obsolete email addresses.

This created more discussions than it was worth...

> Applied, thanks.

Thanks.

cu
Adrian

-- 

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

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

Re: [INFO] Kernel strict versioning

[Adrian Bunk]

On Mon, Apr 11, 2005 at 08:02:55PM -0500, Franco Sensei wrote:
> Adrian Bunk wrote:
> >This has nothing to do with versioning.
> >
> >You are asking for ABI compatibility between different kernel versions.
> 
> The problem is probably misunderstanding about what I intend by version.
> 
> >There is no stable ABI between different kernel versions and there will 
> >never be one. Please read Documentation/stable_api_nonsense.txt for 
> >details.
> 
> I've read it.
> 
> Assuming the fact that a kernel can be considered stable, my point of
> view implies an assumption: kernel and modules are distributed by a
> distro, and compiled with the same gcc. Of course, I'm not talking about
> different architectures and so on, since I'm talking about something
> different, I'm talking about the api involved in the developement. 
> Distributions have to use a great care about compiler changes, and it's 
> not kernel developers' problem.
> 
> A kernel stable 2.X  version should not differ much in the
> subversioning (2.X.a ~= 2.X.b). Changing APIs in the kernel can be 

You say API but talk about ABI.

> possibly avoided by using a release versioning different from the one 
> used now. Structues and exported functions should be almost the same, 
> the implementation should be, and of course, must be different: bugs, 
> improvements and so on.

You said you've read stable_api_nonsense.txt .

stable_api_nonsense.txt talks about exactly these issues.

> I see the point about continuous developement, that's why I'm using 
> linux since 97, but I find interesting also the design of a stable 
> infrastructure, that can be achieved. A data structure no longer in use 
> by anyone, functions being unused for a long time, can be made harmless. 
> Providing a binary compatibility makes recompiling all external modules 
> (external to the official kernel I mean) not necessary, making life 
> easier for any other person using linux (e.g. pwc module for my logitech 
> pro 4000 webcam, every new kernel, new module compilation. Stability 
> makes in this sense a real big improvement. An example of this care can 

The right solution for this issue is simple:

Get the module into the kernel.

Not that e.g. your pwc module will be in kernel 2.6.12.

> be found in trolltech qt library. I use them since 1.x and it's a really 
> good thing assuring the binary compatibility... of course they just 
> screw it some day to day :) Everybody can be wrong.
>...

Please check the facts:

QT 1 is _not_ binary compatible with QT 3.

There's a reason why the library changed the so-name...


cu
Adrian

-- 

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

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

Re: Re: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)

[Petr Baudis]

Dear diary, on Tue, Apr 12, 2005 at 03:20:18AM CEST, I got a letter
where "Adam J. Richter" <[EMAIL PROTECTED]> told me that...
> >Dear diary, on Mon, Apr 11, 2005 at 05:46:38PM CEST, I got a letter
> >where "Adam J. Richter" <[EMAIL PROTECTED]> told me that...
> >..snip..
> >> Graydon Hoare.  (By the way, I would prefer that git just punt to
> >> user level programs for diff and merge when all of the versions
> >> involved are different or at least have a very thin interface
> >> for extending the facility, because I would like to do some character
> >> based merge stuff.)
> >..snip..
> 
> >But this is what git already does. I agree it could do it even better,
> >by checking environment variables for the appropriate tools (then you
> >could use that to pass diff e.g. -p etc.).
> 
> This message from Linus seemed to imply that git was going to get
> its own 3-way merge code:
> 
> | Then the bad news: the merge algorithm is going to suck. It's going to be
> | just plain 3-way merge, the same RCS/CVS thing you've seen before. With no
> | understanding of renames etc. I'll try to find the best parent to base the
> | merge off of, although early testers may have to tell the piece of crud
> | what the most recent common parent was.

Well, from what I can read it says "just plain 3-way merge, the same
RCS/CVS thing you've seen before". :-)

Basically, when you look at merge(1) :

SYNOPSIS
   merge [ options ] file1 file2 file3
DESCRIPTION
   merge  incorporates  all  changes that lead from file2 to file3
into file1.

The only big problem is how to guess the best file2 when you give it
file3 and file1.

-- 
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)

[Adam J. Richter]

On Mon, 11 Apr 2005 20:45:38 +0200, Peter Baudis wrote:
>  Hello,

>  please do not trim the cc list so agressively.

Sorry.  I read the list from a web site that does not show the
cc lists.  I'll try to cc more people from the relevant discussions
though.  On the other hand, I've dropped Linus from this message,
as it just points to something he previously said.

>Dear diary, on Mon, Apr 11, 2005 at 05:46:38PM CEST, I got a letter
>where "Adam J. Richter" <[EMAIL PROTECTED]> told me that...
>..snip..
>> Graydon Hoare.  (By the way, I would prefer that git just punt to
>> user level programs for diff and merge when all of the versions
>> involved are different or at least have a very thin interface
>> for extending the facility, because I would like to do some character
>> based merge stuff.)
>..snip..

>But this is what git already does. I agree it could do it even better,
>by checking environment variables for the appropriate tools (then you
>could use that to pass diff e.g. -p etc.).

This message from Linus seemed to imply that git was going to get
its own 3-way merge code:

| Then the bad news: the merge algorithm is going to suck. It's going to be
| just plain 3-way merge, the same RCS/CVS thing you've seen before. With no
| understanding of renames etc. I'll try to find the best parent to base the
| merge off of, although early testers may have to tell the piece of crud
| what the most recent common parent was.

( from http://marc.theaimsgroup.com/?l=linux-kernel=111320013100822=2 )


__ __
Adam J. Richter\ /
[EMAIL PROTECTED]  | g g d r a s i l
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Policy question (was Re: [2.6.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop)

[Shawn Starr]

Well, of course. When I get around to figuring out the best way to do this.  
Since I don't want to bloat up sysfs ACPI stuff just to check if the echoed 
value is a number or string. We can just gradually phase it out by just 
marking it DEPRECATED and keep it ON in the Kbuild file so nobody looses the 
functionality until then.

I'm thinking 2 years but some say thats too long :)

Now that I look at it, I don't need to put it into a CONFIG option as its 
already a module :-) even better.

Shawn.

On April 11, 2005 20:09, Rob Landley wrote:
> On Wednesday 06 April 2005 05:22 pm, Shawn Starr wrote:
> > --- Pavel Machek <[EMAIL PROTECTED]> wrote:
> > > Hi!
> > >
> > > > So nobody minds if I make this into a CONFIG
> > >
> > > option marked as Deprecated? :)
> > >
> > > Actually it should probably go through
> > >
> > > Documentation/feature-removal-schedule.txt
> > >
> > > ...and give it *long* timeout, since it is API
> > > change.
> > >  Pavel
>
> Shouldn't all deprecated features be in feature-removal-schedule.txt?
>
> There are four entries in feature-removal-schedule in 2.6.12-rc2, but
> `find . -name "Kconfig" | xargs grep -i deprecated` finds eight entries. 
> (And there's more if the grep -i is for "obsolete" instead...)
>
> Just wondering...
>
> Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-rc2-mm3

[Juergen Kreileder]

Andrew Morton <[EMAIL PROTECTED]> writes:

> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/

I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.

2.6.11-mm4 works fine but all 2.6.12 versions I've tried (all since
-rc1-mm3) lock up randomly.  The easiest way to reproduce the problem
seems to be running Azareus.  So it might be network related, but I'm
not 100% sure about that, there was a least one deadlock with
virtually no network usage.

BTW, what's the SysRq key on recent Apple USB keyboards?  Alt/Cmd-F13
doesn't work for me.


Juergen

CONFIG_64BIT=y
CONFIG_MMU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_EARLY_PRINTK=y
CONFIG_COMPAT=y
CONFIG_FORCE_MAX_ZONEORDER=13
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_KALLSYMS=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_PPC_MULTIPLATFORM=y
CONFIG_PPC_PMAC=y
CONFIG_PPC=y
CONFIG_PPC64=y
CONFIG_PPC_OF=y
CONFIG_ALTIVEC=y
CONFIG_U3_DART=y
CONFIG_PPC_PMAC64=y
CONFIG_BOOTX_TEXT=y
CONFIG_POWER4_ONLY=y
CONFIG_IOMMU_VMERGE=y
CONFIG_SMP=y
CONFIG_NR_CPUS=2
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_FLATMEM=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_SECCOMP=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_PCI_NAMES=y
CONFIG_PROC_DEVICETREE=y
CONFIG_NET=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_SYN_COOKIES=y
CONFIG_IP_TCPDIAG=y
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_HCIUSB=m
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CDROM_PKTCDVD=y
CONFIG_CDROM_PKTCDVD_BUFFERS=8
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_IDE_TASK_IOCTL=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDE_PMAC=y
CONFIG_BLK_DEV_IDE_PMAC_ATA100FIRST=y
CONFIG_BLK_DEV_IDEDMA_PMAC=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_SCSI=y
CONFIG_SCSI_PROC_FS=y
CONFIG_BLK_DEV_SD=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SATA=y
CONFIG_SCSI_SATA_SVW=y
CONFIG_SCSI_QLA2XXX=y
CONFIG_MD=y
CONFIG_BLK_DEV_DM=y
CONFIG_DM_CRYPT=y
CONFIG_DM_SNAPSHOT=y
CONFIG_DM_MIRROR=y
CONFIG_DM_ZERO=y
CONFIG_ADB_PMU=y
CONFIG_THERM_PM72=y
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_SUNGEM=y
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1600
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1200
CONFIG_INPUT_EVDEV=m
CONFIG_INPUT_KEYBOARD=y
CONFIG_INPUT_MOUSE=y
CONFIG_INPUT_MISC=y
CONFIG_INPUT_UINPUT=m
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_RTC=y
CONFIG_AGP=y
CONFIG_AGP_UNINORTH=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_KEYWEST=y
CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_SOFT_CURSOR=y
CONFIG_FB_MACMODES=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_OF=y
CONFIG_FB_RADEON=y
CONFIG_FB_RADEON_I2C=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_SOUND=m
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
CONFIG_SND_POWERMAC=m
CONFIG_SND_USB_AUDIO=m
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_BANDWIDTH=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_STORAGE=m
CONFIG_USB_HID=y
CONFIG_USB_HIDINPUT=y
CONFIG_USB_HIDDEV=y
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_JBD=y
CONFIG_FS_MBCACHE=y
CONFIG_FS_POSIX_ACL=y
CONFIG_INOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_FUSE_FS=m
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=850

Re: Processes stuck on D state on Dual Opteron

[Nick Piggin]

On Tue, 2005-04-12 at 01:22 +0100, Claudio Martins wrote:
> On Monday 11 April 2005 23:59, Nick Piggin wrote:
> >
> > >   OK, I'll try them in a few minutes and report back.
> >
> > I'm not overly hopeful. If they fix the problem, then it's likely
> > that the real bug is hidden.
> >
> 
>   Well, the thing is, they do fix the problem. Or at least they hide it very 
> well ;-)
> 
>   It has been running for more than 5 hours now with stress with no problems 
> and no stuck processes.
> 

Well, that is good... I guess ;)

Actually the patches I have sent you do fix real bugs, but they also
make the block layer less likely to recurse into page reclaim, so it
may be eg. hiding the problem that Neil's patch fixes.

It may be that your fundamental problem is solved by my patches, but
we need to be sure.

>   I think I'm going to give a try to Neil's patch, but I'll have to apply 
> some 
> patches from -mm.
> 

Yep that would be good. Please test -rc2 with Andrew's patch, and
obviously my patches backed out. Thanks for sticking with it.

Nick




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.11.7 1/1] x86 reboot: Add reboot fixup for gx1/cs5530a

[jayalk]

Hi Peter, 

As per your suggestion, I switched do {} while(0) to ((void)(0))
for the dummy define, since it's an argumentless function.

Please let me know if it's okay now.

Thanks,
Jaya Kumar

--- 

I ran into a problem getting reboot working with 2.6.11 on an embedded
board. The board has a Geode GX1 with a CS5530A companion. What I observe on
reboot is the "Restarting system" printk, and then a cpu stall/hang. I think
the problem arises because the keyboard controller is disabled by the BIOS,
so the traditional mach_reboot()'s output to port 0x64 is ignored. Then the
386 triple fault issued after mach_reboot() results in a shutdown (because
the hardware doesn't have to detect the triple fault and issue a reset).
That then gives the end result of a stalled cpu/hang. 

I found that the CS5530A in question has a "issue system wide reset" bit.
The reboot works cleanly if I write that bit rather than do mach_reboot().
So the following patch is my attempt to incorporate that change into 2.6.11
by adding a X86_REBOOTFIXUPS option. In order to keep reboot.c free of hw
specific fixups, I put it in another file, reboot_fixups.c. I tried to make
it a bit generic so that if there are other reboot related fixups for other
chipsets/boards, there'd be a clean place to put it. Please let me know what
you think.

Thanks,
Jaya Kumar

---

Signed-off-by:  Jaya Kumar  <[EMAIL PROTECTED]>

diff -uprN -X dontdiff linux-2.6.11.7-vanilla/arch/i386/Kconfig 
linux-2.6.11.7/arch/i386/Kconfig
--- linux-2.6.11.7-vanilla/arch/i386/Kconfig2005-04-08 02:57:18.0 
+0800
+++ linux-2.6.11.7/arch/i386/Kconfig2005-04-11 14:21:05.0 +0800
@@ -645,6 +645,24 @@ config I8K
  Say Y if you intend to run this kernel on a Dell Inspiron 8000.
  Say N otherwise.
 
+config X86_REBOOTFIXUPS
+   bool "Enable X86 board specific fixups for reboot"
+   depends on X86 
+   default n
+   ---help---
+ This enables chipset and/or board specific fixups to be done
+ in order to get reboot to work correctly. This is only needed on
+ some combinations of hardware and BIOS. The symptom, for which 
+ this config is intended, is when reboot ends with a stalled/hung 
+ system. 
+
+ Currently, the only fixup is for the Geode GX1/CS5530A/TROM2.1. 
+ combination.
+
+ Say Y if you want to enable the fixup. Currently, it's safe to
+ enable this option even if you don't need it.
+ Say N otherwise.
+
 config MICROCODE
tristate "/dev/cpu/microcode - Intel IA32 CPU microcode support"
---help---
diff -uprN -X dontdiff linux-2.6.11.7-vanilla/arch/i386/kernel/Makefile 
linux-2.6.11.7/arch/i386/kernel/Makefile
--- linux-2.6.11.7-vanilla/arch/i386/kernel/Makefile2005-04-08 
02:57:22.0 +0800
+++ linux-2.6.11.7/arch/i386/kernel/Makefile2005-04-11 13:10:31.0 
+0800
@@ -23,6 +23,7 @@ obj-$(CONFIG_X86_TRAMPOLINE)  += trampoli
 obj-$(CONFIG_X86_MPPARSE)  += mpparse.o
 obj-$(CONFIG_X86_LOCAL_APIC)   += apic.o nmi.o
 obj-$(CONFIG_X86_IO_APIC)  += io_apic.o
+obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups.o
 obj-$(CONFIG_X86_NUMAQ)+= numaq.o
 obj-$(CONFIG_X86_SUMMIT_NUMA)  += summit.o
 obj-$(CONFIG_KPROBES)  += kprobes.o
diff -uprN -X dontdiff linux-2.6.11.7-vanilla/arch/i386/kernel/reboot.c 
linux-2.6.11.7/arch/i386/kernel/reboot.c
--- linux-2.6.11.7-vanilla/arch/i386/kernel/reboot.c2005-04-08 
02:57:27.0 +0800
+++ linux-2.6.11.7/arch/i386/kernel/reboot.c2005-04-11 13:10:31.0 
+0800
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include "mach_reboot.h"
+#include 
 
 /*
  * Power off function, if any
@@ -348,6 +349,7 @@ void machine_restart(char * __unused)
/* rebooting needs to touch the page at absolute addr 0 */
*((unsigned short *)__va(0x472)) = reboot_mode;
for (;;) {
+   mach_reboot_fixups(); /* for board specific fixups */
mach_reboot();
/* That didn't work - force a triple fault.. */
__asm__ __volatile__("lidt %0": :"m" (no_idt));
diff -uprN -X dontdiff linux-2.6.11.7-vanilla/arch/i386/kernel/reboot_fixups.c 
linux-2.6.11.7/arch/i386/kernel/reboot_fixups.c
--- linux-2.6.11.7-vanilla/arch/i386/kernel/reboot_fixups.c 1970-01-01 
07:30:00.0 +0730
+++ linux-2.6.11.7/arch/i386/kernel/reboot_fixups.c 2005-04-11 
14:09:02.0 +0800
@@ -0,0 +1,56 @@
+/*
+ * linux/arch/i386/kernel/reboot_fixups.c
+ * 
+ * This is a good place to put board specific reboot fixups.
+ *
+ * List of supported fixups:
+ * geode-gx1/cs5530a - Jaya Kumar <[EMAIL PROTECTED]>
+ *
+ */
+
+#include 
+#include 
+
+static void cs5530a_warm_reset(struct pci_dev *dev)
+{
+   /* writing 1 to the reset control register, 0x44 causes the 
+   cs5530a to perform a system warm reset */
+   pci_write_config_byte(dev, 0x44, 0x1);
+   

Policy question (was Re: [2.6.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop)

[Rob Landley]

On Wednesday 06 April 2005 05:22 pm, Shawn Starr wrote:
> --- Pavel Machek <[EMAIL PROTECTED]> wrote:
> > Hi!
> >
> > > So nobody minds if I make this into a CONFIG
> >
> > option marked as Deprecated? :)
> >
> > Actually it should probably go through
> >
> > Documentation/feature-removal-schedule.txt
> >
> > ...and give it *long* timeout, since it is API
> > change.
> > Pavel

Shouldn't all deprecated features be in feature-removal-schedule.txt?

There are four entries in feature-removal-schedule in 2.6.12-rc2, but
`find . -name "Kconfig" | xargs grep -i deprecated` finds eight entries.  (And 
there's more if the grep -i is for "obsolete" instead...)

Just wondering...

Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] sched: unlocked context-switches

[David Mosberger]

> On Sun, 10 Apr 2005 08:43:24 +0200, Ingo Molnar <[EMAIL PROTECTED]> said:

  Ingo> * David S. Miller <[EMAIL PROTECTED]> wrote:

  >> > Yes, of course.  The deadlock was due to context-switching, not
  >> > switch_mm() per se.  Hopefully someone else beats me to
  >> remembering > the details before Monday.

  >> Sparc64 has a deadlock because we hold mm->page_table_lock during
  >> switch_mm().  I bet IA64 did something similar, as I remember it
  >> had a very similar locking issue in this area.

  >> So the deadlock was, we held the runqueue locks over switch_mm(),
  >> switch_mm() spins on mm->page_table_lock, the cpu which does have
  >> mm-> page_table_lock tries to do a wakeup on the first cpu's
  >> mm-> runqueue.
  >> Classic AB-BA deadlock.

  Ingo> yeah, i can see that happening - holding the runqueue lock and
  Ingo> enabling interrupts. (it's basically never safe to enable irqs
  Ingo> with the runqueue lock held.)

  Ingo> the patch drops both the runqueue lock and enables interrupts,
  Ingo> so this particular issue should not trigger.

I had to refresh my memory with a quick Google search that netted [1]
(look for "Disable interrupts during context switch").  Actually, it
wasn't really a deadlock, but rather a livelock, since a CPU got stuck
on an infinite page-not-present loop.

Fundamentally, the issue was that doing the switch_mm() and
switch_to() with interrupts enabled opened a window during which you
could get a call to flush_tlb_mm() (as a result of an IPI).  This, in
turn, could end up activating the wrong MMU-context, since the action
of flush_tlb_mm() depends on the value of current->active_mm.  The
problematic sequence was:

1) schedule() calls switch_mm() which calls activate_context() to
   switch to the new address-space
2) IPI comes in and flush_tlb_mm(mm) gets called
3) "current" still points to old task and if "current->active_mm == mm",
   activate_mm() is called for the old address-space, resetting the
   address-space back to that of the old task

Now, Ingo says that the order is reversed with his patch, i.e.,
switch_mm() happens after switch_to().  That means flush_tlb_mm() may
now see a current->active_mm which hasn't really been activated yet.
That should be OK since it would just mean that we'd do an early (and
duplicate) activate_context().  While it does not give me a warm and
fuzzy feeling to have this inconsistent state be observable by
interrupt-handlers (and, in particular, IPI-handlers), I don't see any
problem with it off hand.

--david

[1] http://www.gelato.unsw.edu.au/linux-ia64/0307/6109.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: bdflush/rpciod high CPU utilization, profile does not make sense

[Greg Banks]

On Tue, 2005-04-12 at 01:42, Jakob Oestergaard wrote:
> Yes, as far as I know - the Broadcom Tigeon3 driver does not have the
> option of enabling/disabling RX polling (if we agree that is what we're
> talking about), but looking in tg3.c it seems that it *always*
> unconditionally uses NAPI...

I've whined and moaned about this in the past, but for all its
faults NAPI on tg3 doesn't lose packets.  It does cause a huge
increase in irq cpu time on multiple fast CPUs.  What irq rate
are you seeing?

I did once post a patch to make NAPI for tg3 selectable at
configure time.
http://marc.theaimsgroup.com/?l=linux-netdev=107183822710263=2

> No dropped packets... I wonder if the tg3 driver is being completely
> honest about this...

At one point it wasn't, since this patch it is:
http://marc.theaimsgroup.com/?l=linux-netdev=108433829603319=2

Greg.
-- 
Greg Banks, R Software Engineer, SGI Australian Software Group.
I don't speak for SGI.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [INFO] Kernel strict versioning

[Franco \"Sensei\"]

Adrian Bunk wrote:
This has nothing to do with versioning.
You are asking for ABI compatibility between different kernel versions.
The problem is probably misunderstanding about what I intend by version.
There is no stable ABI between different kernel versions and there will 
never be one. Please read Documentation/stable_api_nonsense.txt for 
details.
I've read it.
Assuming the fact that a kernel can be considered stable, my point of
view implies an assumption: kernel and modules are distributed by a
distro, and compiled with the same gcc. Of course, I'm not talking about
different architectures and so on, since I'm talking about something
different, I'm talking about the api involved in the developement. 
Distributions have to use a great care about compiler changes, and it's 
not kernel developers' problem.

A kernel stable 2.X  version should not differ much in the
subversioning (2.X.a ~= 2.X.b). Changing APIs in the kernel can be 
possibly avoided by using a release versioning different from the one 
used now. Structues and exported functions should be almost the same, 
the implementation should be, and of course, must be different: bugs, 
improvements and so on.

I see the point about continuous developement, that's why I'm using 
linux since 97, but I find interesting also the design of a stable 
infrastructure, that can be achieved. A data structure no longer in use 
by anyone, functions being unused for a long time, can be made harmless. 
Providing a binary compatibility makes recompiling all external modules 
(external to the official kernel I mean) not necessary, making life 
easier for any other person using linux (e.g. pwc module for my logitech 
pro 4000 webcam, every new kernel, new module compilation. Stability 
makes in this sense a real big improvement. An example of this care can 
be found in trolltech qt library. I use them since 1.x and it's a really 
good thing assuring the binary compatibility... of course they just 
screw it some day to day :) Everybody can be wrong.

I find it an interesting point anyway. I know there would never be, as 
you said, but I don't find the document you've pointed me to, really 
convincing. Still have doubts...

--
Sensei  
   
   
   


signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/3] cifs: md5 cleanup - functions

[Steve French]

Alexander Nyberg <[EMAIL PROTECTED]> wrote on 04/11/2005 03:26:14 PM:

> > Function names and return types on same line - conform to
established 
> > fs/cifs/ style.
> > 
> > -void
> > -MD5Init(struct MD5Context *ctx)
> > +void MD5Init(struct MD5Context *ctx)
> >  {
> > ctx->buf[0] = 0x67452301;
> > ctx->buf[1] = 0xefcdab89;
> > @@ -60,8 +58,7 @@ MD5Init(struct MD5Context *ctx)
> >   * Update context to reflect the concatenation of another buffer
full
> >   * of bytes.
> >   */
> > -void
> > -MD5Update(struct MD5Context *ctx, unsigned char const *buf,
unsigned len)
> > +void MD5Update(struct MD5Context *ctx, unsigned char const *buf, 
> unsigned len)
> >  {
> 
> Can anyone enlighten me why CIFS is not using crypto/md5?
> Same question about md4
> 


There was a patch suggested a year or so ago to remove the older cifs
md5 implementation and have cifsencrypt.c use the newer Linux crypto
API, but since it made the code considerably more complex it did not
make any sense. The current crypto API seems to be designed for much
more complex usage patterns than cifs needs it for. The key use for this
for CIFS is the following small function (to calculate the packet
signitures on cifs packets in fs/cifs/cifsencrypt.c)

38 static int cifs_calculate_signature(const struct smb_hdr * cifs_pdu,
const char * key, char * signature)
39 {
40 struct  MD5Context context;
41 
42 if((cifs_pdu == NULL) || (signature == NULL))
43 return -EINVAL;
44 
45 MD5Init();
46 MD5Update(,key,CIFS_SESSION_KEY_SIZE+16);
47   
MD5Update(,cifs_pdu->Protocol,cifs_pdu->smb_buf_length);
48 MD5Final(signature,);
49 return 0;
50 }


The problem with moving this function to use crypto/md5.c is that the
three needed md5 functions (MD5Init, MD5Update, MD5Final) are not
exported (although they appear to be already implemented in close to the
right form already - but they are defined as static in crypto/md5.c) and
the only way to do the equivalent is much more complicated. I don't mind
using those equivalent three functions in crypto/md5.c directly if
someone could verify that they match the three functions of the same
name and could export them so cifs could call them - I would like to get
rid of cifs/md5.c

There was a similar issue IIRC with md4.c - the code gets more complex
rather than less complex moving to the crypto API.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Processes stuck on D state on Dual Opteron

[Andrew Morton]

Claudio Martins <[EMAIL PROTECTED]> wrote:
>
>   I think I'm going to give a try to Neil's patch, but I'll have to apply 
> some 
>  patches from -mm.

Just this one if you're using 2.6.12-rc2:

--- 25/drivers/md/md.c~avoid-deadlock-in-sync_page_io-by-using-gfp_noio Mon Apr 
11 16:55:07 2005
+++ 25-akpm/drivers/md/md.c Mon Apr 11 16:55:07 2005
@@ -332,7 +332,7 @@ static int bi_complete(struct bio *bio, 
 static int sync_page_io(struct block_device *bdev, sector_t sector, int size,
   struct page *page, int rw)
 {
-   struct bio *bio = bio_alloc(GFP_KERNEL, 1);
+   struct bio *bio = bio_alloc(GFP_NOIO, 1);
struct completion event;
int ret;
 
_

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Marco Colombo]

On Mon, 11 Apr 2005, Sven Luther wrote:
On Mon, Apr 11, 2005 at 10:54:50PM +0200, Marco Colombo wrote:
In this case, A is clearly the author (onwer of rights) of the firmware.
D is fine on respect of the other A's, since their source is actually
(and clearly) there. It's the missing source case we're considering
and the number of A's is quite small, the copyright owners of firmware
images. Those A's are easily identified, and perfectly able to act.
Well, i am not sure with your interpretation, but even if you where right, 
we
have no guarantee that A will continue being lenient, and no guarantee that A
will not start suing D or whoever for illegally distributing his stuff without
sources.
Let's keep things separated. I'm saying that the only one that may
sue D is A, not C. If we agree on this, we may abandon the case of a third
party sueing D.
As for threats coming from A, IMHO D is safe as long as he distributes
what A claims the source is, even if it's a hex string. In no world
A can publicly state "this is the source" and then sue D because
"no, that's not the source" (assuming D is copying it verbatim).
So, even if C comes to think D is breaking GPL, all C can do is notify
A. The GPL D is supposedly breaking is an agreement between A and D
only. On which basis may C sue D? For breaking what agreement? It's up
to A to sue D for breaking GPL.
This is indeed an interpretation. I am not sure myself if a user receiving
GPLed software in binary only fashion as is the case here can sue either D or
A to get access to that source code.
The point is, if A states (even implicitly) D is distributing the right
source, there's nothing C can do to D. D is not breaking GPL, as long A
So, i get some random bit of GPLed software, i add a module or some code to
it, i distribute that code in binary format only, and claim that i have used
an hex editor to write it, or simply that it is the 'right' source.
I have some serious doubts that i will not get sued by all the authors of the
original GPLed work if i were to do that, and rightly so.
No. Please don't throw irrelevant matters in. D is not modifing the
software at all. D is a mere distributor. We're not addressing issues
related to modification, since no one is going to modify the firmware
anyway. This is not a general discussion on GPL. Issues related to
modification do not belong to this thread, which already very close
to off topic on l-k.
Which reminds me. The only reason why this thread belongs here, IMHO,
it's because when it comes to GPL, it really doesn't matter what
FSF's interpretation is, or anyone else's. The authors are choosing
GPL as a license, so _thier_ interpretation is what really matters.
says so and it's A granting D the right to distribute. There's no way C
can prevent D from distributing A's software, if A is fine with it.
It's up to A to decide if GPL conditions are met by D.
Even in that case, you still need explicit permission of A, and all the 
other
copyright holders of the rest of the GPLed work, to give you an explicit
exception to link with this non-free bit of code.
Yes, but it does not apply to our case here. There's no "all other
copyright holders". _You_ stated that the firmware is included by mere
aggregation, so there's no other holders involved. We're talking
about the firmware case. A is one or two well identified subjects.
And A wrote it is GPL'ed. Whether you agree or not, that's the licence
A chose. A placed the copyright notice.
The licence is a matter between A and D. A may sue D and D may (less
likely) sue A, if conditions are not met. I'm not sure at all GPL
is enforceable by D upon A. Let's assume it is, for sake of discussion,
anyway.
Now you could argue that any number of authors of GPLed bits of the linux
kernel could sue D for distributing their software as a derived work of the
binary-only bit, and the fact that D doesn't distribute the source code to the
binary bit voids any other right allowed him by the GPL, and thus he has no
right to do the distribution at all. The GPL is very clear on this topic.
We're not talking of that case. D _is_ actually distributing the right
source, according to A. It's C that is unsatisfied with it.
No. The source code is clearly the prefered form of modification, not some
random intermediate state A may be claiming is source.
In this context, it is. Only A may sue D for not distributing the source.
Whatever D distributes, D has to make A happy. If A is happy with D
distributing `dd if=/dev/random count=1` as source, no one can stop D
from doing that. Keep in mind A is the copyright holder. He grants
rights to third parties. No one but A can remove them.
[...]
I'm not following. Are you saying what if A is bought? That is
different. Well GPL is quite clear:
1. You may copy and distribute verbatim copies of the Program's source
code as you receive it, ...
If D is distributing the source as received from A, D is in full
compliance. How could A sue D? If A distributed incomplete source
in 

RE: [PATCH] Priority Lists for the RT mutex

[Perez-Gonzalez, Inaky]

>From: Bill Huey (hui) [mailto:[EMAIL PROTECTED]
>
>> Quick fix: the usual. Enable deadlock detection and if it
>> returns deadlock, assume it is locked already and proceed (or
>> do a recursive mutex, or a trylock).
>
>You have to be joking me ? geez.
>...

This is way *more* common than you think--I've seen it around
some big multithreaded OSS packages [can't remember which now]. 

>> Sure--and because most was for legacy reasons that adhered to
>> POSIX strictly, it was very simple: we need POSIX this, that and
>> that (PI, proper adherence to scheduler policy wake up/rt-behaviour,
>> deadlock detection, etc).
>
>Some of this stuff sounds like recursive locking. Would this be a
>better expression to solve the "top level API locking" problem
>you're referring to ?

Bingo. That's another way to "fix" it. Luckily, recursive locking
can be safely and quickly done in user space (I own this lock,
ergo I just inc the lock count).

The problem with deadlocks is when the scenario gets more complex
and you are trying to lock a mutex and the owner is waiting for
a mutex whose owner is waiting for a mutex that you own...this
more commonly happens when you don't know what the heck is going
on in the code, which unfortunately is very common on people that
inherits big pieces of stacks to maintain.

>> Fortunately in those areas POSIX is not too gray; code to the book.
>> Deal.
>
>I would think that there will have to be a graph discontinuity
>between user/kernel spaces at kernel entry and exit for the deadlock
>detector. Can't say about issues at fork time, but I would expect
>that those objects would have to be destroyed when the process exits.

fork time is not an issue, as POSIX makes forks and thread incompatible
(in a nutshell, only the thread calling fork() survives, all the mutexes
are [IIRC] reinitialized or something like that...).

>The current RT (Ingo's) lock isn't recursive nor is the deadlock
>detector the last time I looked. Do think that this is a problem
>for legacy apps if it gets overload for being the userspace futex
>as well ? (assuming I'm understanding all of this correctly)

Should be not on the recursive side; as I said, that is easy to do
[currently NPTL does it with the futexes]. The deadlock stuff gets
hairier, but it's not such a big of a deal when you have your data
structures setup. It takes time, though.

>> Of course, selling it to the lkml is another story.
>
>I would think that pushing as much of this into userspace would
>make the kernel hooks for it more acceptable. Don't know.

Agreed. Deadlock checking though, has to be done in the kernel. For
the generic case it is the only way to do it sanely.

-- Inaky 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]

[Nathan Scott]

On Tue, Apr 12, 2005 at 01:51:10AM +0200, Pavel Machek wrote:
> I should take some sleep now, so I can't test the patch, but I don't
> think it will help. If someone has PF_FREEZE set, he should be in
> refrigerator.

OK, so if that doesn't help, here's an alternate approach - this
lets xfsbufd track when its entering the refrigerator(), so that
other callers know that attempts to wake it are futile.

cheers.

-- 
Nathan


--- fs/xfs/linux-2.6/xfs_buf.c.orig 2005-04-12 09:00:26.375351560 +1000
+++ fs/xfs/linux-2.6/xfs_buf.c  2005-04-12 10:14:27.468202824 +1000
@@ -1746,13 +1746,15 @@ STATIC DECLARE_COMPLETION(pagebuf_daemon
 STATIC struct task_struct *pagebuf_daemon_task;
 STATIC int pagebuf_daemon_active;
 STATIC int force_flush;
-
+STATIC int force_sleep;
 
 STATIC int
 pagebuf_daemon_wakeup(
int priority,
unsigned intmask)
 {
+   if (force_sleep)
+   return 0;
force_flush = 1;
barrier();
wake_up_process(pagebuf_daemon_task);
@@ -1778,7 +1780,12 @@ pagebuf_daemon(
 
INIT_LIST_HEAD();
do {
-   try_to_freeze(PF_FREEZE);
+   if (unlikely(current->flags & PF_FREEZE)) {
+   force_sleep = 1;
+   refrigerator(PF_FREEZE);
+   } else {
+   force_sleep = 0;
+   }
 
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout((xfs_buf_timer_centisecs * HZ) / 100);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Processes stuck on D state on Dual Opteron

[Claudio Martins]

On Tuesday 12 April 2005 00:46, Neil Brown wrote:
> On Monday April 11, [EMAIL PROTECTED] wrote:
> > Neil, have you had a look at the traces? Do they mean much to you?
>
> Just looked.
> bio_alloc_bioset seems implicated, as does sync_page_io.
>
> sync_page_io used to use a 'struct bio' on the stack, but Jens Axboe
> change it to use bio_alloc (don't know why..) and I should have
> checked the change better.
>
> sync_page_io can be called on the write out path, so it should use
> GFP_NOIO rather than GFP_KERNEL.
>
> See if this helps Actually this patch is against 2.6.12-rc2-mm1
> which uses md_super_write instead of sync_page_io (which is now only
> used for read).  So if you are using a non-mm kernel (which seems to
> be the case) you'll need to apply the patch by hand.
>

   Hi Neil,

  I'll test this patch, but I'm wondering if I have to apply all the 
md-related patches from broken out directory of 2.6.12-rc2-mm1 or only some 
specific ones?
   Anyway I'm happy to test all those md updates, if you think they might 
help.

 Thanks 

Claudio

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Processes stuck on D state on Dual Opteron

[Claudio Martins]

On Monday 11 April 2005 23:59, Nick Piggin wrote:
>
> >   OK, I'll try them in a few minutes and report back.
>
> I'm not overly hopeful. If they fix the problem, then it's likely
> that the real bug is hidden.
>

  Well, the thing is, they do fix the problem. Or at least they hide it very 
well ;-)

  It has been running for more than 5 hours now with stress with no problems 
and no stuck processes.

  I think I'm going to give a try to Neil's patch, but I'll have to apply some 
patches from -mm.

 Thanks

Claudio

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Priority Lists for the RT mutex

[hui]

On Mon, Apr 11, 2005 at 04:28:25PM -0700, Perez-Gonzalez, Inaky wrote:
> >From: Bill Huey (hui) [mailto:[EMAIL PROTECTED]
...
> API than once upon a time was made multithreaded by just adding
> a bunch of pthread_mutex_[un]lock() at the API entry point...
> without realizing that some of the top level API calls also 
> called other top level API calls, so they'd deadlock.

Oh crap.

> Quick fix: the usual. Enable deadlock detection and if it
> returns deadlock, assume it is locked already and proceed (or
> do a recursive mutex, or a trylock).

You have to be joking me ? geez.
... 
> It is certainly something to explore, but I'd better drive your
> way than do it. It's cleaner. Hides implementation details.
>
> I agree, but it doesn't work that well when talking about legacy 
> systems...that's the problem.

Yeah, ok, I understand what's going on now. There isn't a notion
of projecting priority across into the Unix/Linux kernel traditionally
which is why it seemed so bizarre.

> Sure--and because most was for legacy reasons that adhered to 
> POSIX strictly, it was very simple: we need POSIX this, that and
> that (PI, proper adherence to scheduler policy wake up/rt-behaviour,
> deadlock detection, etc). 

Some of this stuff sounds like recursive locking. Would this be a
better expression to solve the "top level API locking" problem
you're referring to ?

> Fortunately in those areas POSIX is not too gray; code to the book.
> Deal. 

I would think that there will have to be a graph discontinuity
between user/kernel spaces at kernel entry and exit for the deadlock
detector. Can't say about issues at fork time, but I would expect
that those objects would have to be destroyed when the process exits.

The current RT (Ingo's) lock isn't recursive nor is the deadlock
detector the last time I looked. Do think that this is a problem
for legacy apps if it gets overload for being the userspace futex
as well ? (assuming I'm understanding all of this correctly)

> Of course, selling it to the lkml is another story.

I would think that pushing as much of this into userspace would
make the kernel hooks for it more acceptable. Don't know.

/me thinks more

bill

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

Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation

[Roland Dreier]

Roland> Yes, because the kernel may go through and unmap pages
Roland> from userspace while trying to swap.  Since we have the
Roland> page locked in the kernel, the physical page won't go
Roland> anywhere, but userspace might end up with a different page
Roland> mapped at the same virtual address.

Andrew> That shouldn't happen.  If get_user_pages() has elevated
Andrew> the refcount on a page then the following can happen:

...

Andrew> IOW: while the page has an elevated refcount from
Andrew> get_user_pages(), that physical page is 100% pinned.
Andrew> Once you've done the set_page_dirty+put_page(), the page
Andrew> is again under control of the VM.

Hmm... I've never tested it first hand but Libor assures me there is a
something like what I said.  Libor, did I get the explanation right?

 - 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: 2.6.12-rc2-mm3

[Andrew Morton]

Jindrich Makovicka <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
> 
> MPlayer randomly crashes in various pthread_* calls when using binary
> codecs. 2.6.12-rc2-mm2 was ok. I tried to reverse
> fix-crash-in-entrys-restore_all.patch, but it didn't help.
> 

hm, could be anything.

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

Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation

[Andrew Morton]

Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> Troy> Do we even need the mlock in userspace then?
> 
> Yes, because the kernel may go through and unmap pages from userspace
> while trying to swap.  Since we have the page locked in the kernel,
> the physical page won't go anywhere, but userspace might end up with a
> different page mapped at the same virtual address.

That shouldn't happen.  If get_user_pages() has elevated the refcount on a
page then the following can happen:

- The VM may decide to add the page to swapcache (if it's not mmapped
  from a file).

- Once the page is backed by either swapcache of a (mmapped) file, the VM
  may decide the unmap the application's pte's.  A later minor fault by the
  app will cause the same physical page to be remapped.

- The VM may decide to try to write the page to its backing file or swap.
   If it does, the page is still in core, but is now clean.

- Once all pte's are unmapped and the page is clean, the VM may decide to
  try to reclaim the page.  The VM will then see the elevated refcount and
  will bale out, leaving the page in core.

- If your code was doing a read-from-disk (modifying memory), then your
  code should run set_page_dirty() or set_page_dirty_lock() against the
  page before dropping the refcount which get_user_pages() added.  Once the
  page is dirty, the VM can't reclaim it until it has been been written to
  swap or mmapped backing file.

IOW: while the page has an elevated refcount from get_user_pages(), that
physical page is 100% pinned.  Once you've done the
set_page_dirty+put_page(), the page is again under control of the VM.

There should be no need to run mlock() from userspace.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] scripts/patch-kernel: EXTRAVERSION patches are not incremental

[Randy.Dunlap]

On Tue, 15 Mar 2005 16:15:54 + David Greaves wrote:

| Old thread (!) but this is the last time I could find patch-kernel updated.

I found a little time to update patch-kernel if anyone wants
to use it.  OTOH, using Matt Mackall's "ketchup" is OK too.

I also use 'kcurrent' to keep up with the latest kernel vesions
available -- as noted on www.kernel.org.  It's also attached
and both scripts are available at
  http://developer.osdl.org/rddunlap/scripts/

---

patch-kernel: support non-incremental 2.6.x.y 'stable' patches

# Add better support for (non-incremental) 2.6.x.y patches;
# If an ending version number if not specified, the script automatically
# increments the SUBLEVEL (x in 2.6.x.y) until no more patch files are found;
# however, EXTRAVERSION (y in 2.6.x.y) is never automatically incremented
# but must be specified fully.
#
# patch-kernel does not normally support reverse patching, but does so when
# applying EXTRAVERSION (x.y) patches, so that moving from 2.6.11.y to 2.6.11.z
# is easy and handled by the script (reverse 2.6.11.y and apply 2.6.11.z).

 patch-kernel |  131 +--
 1 files changed, 101 insertions(+), 30 deletions(-)

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

--- patch-kernel-0042004-08-18 12:12:19.0 -0700
+++ patch-kernel2005-04-11 17:02:38.0 -0700
@@ -46,6 +46,19 @@
 # fix some whitespace damage;
 # be smarter about stopping when current version is larger than requested;
 #  Randy Dunlap <[EMAIL PROTECTED]>, 2004-AUG-18.
+#
+# Add better support for (non-incremental) 2.6.x.y patches;
+# If an ending version number if not specified, the script automatically
+# increments the SUBLEVEL (x in 2.6.x.y) until no more patch files are found;
+# however, EXTRAVERSION (y in 2.6.x.y) is never automatically incremented
+# but must be specified fully.
+#
+# patch-kernel does not normally support reverse patching, but does so when
+# applying EXTRAVERSION (x.y) patches, so that moving from 2.6.11.y to 2.6.11.z
+# is easy and handled by the script (reverse 2.6.11.y and apply 2.6.11.z).
+#  Randy Dunlap <[EMAIL PROTECTED]>, 2005-APR-08.
+
+PNAME=patch-kernel
 
 # Set directories from arguments, or use defaults.
 sourcedir=${1-/usr/src/linux}
@@ -54,7 +67,7 @@ stopvers=${3-default}
 
 if [ "$1" == -h -o "$1" == --help -o ! -r "$sourcedir/Makefile" ]; then
 cat << USAGE
-usage: patch-kernel [-h] [ sourcedir [ patchdir [ stopversion ] [ -acxx ] ] ]
+usage: $PNAME [-h] [ sourcedir [ patchdir [ stopversion ] [ -acxx ] ] ]
   source directory defaults to /usr/src/linux,
   patch directory defaults to the current directory,
   stopversion defaults to .
@@ -73,6 +86,19 @@ do
 done
 
 # ---
+# arg1 is filename
+noFile () {
+   echo "cannot find patch file: ${patch}"
+   exit 1
+}
+
+# ---
+backwards () {
+   echo "$PNAME does not support reverse patching"
+   exit 1
+}
+
+# ---
 # Find a file, first parameter is basename of file
 # it tries many compression mechanisms and sets variables to say how to get it
 findFile () {
@@ -133,6 +159,28 @@ applyPatch () {
   return 0;
 }
 
+# ---
+# arg1 is patch filename
+reversePatch () {
+   echo -n "Reversing $1 (${name}) ... "
+   if $uncomp ${patchdir}/"$1"${ext} | patch -p1 -Rs -N -E -d $sourcedir
+   then
+   echo "done."
+   else
+   echo "failed.  Clean it up."
+   exit 1
+   fi
+   if [ "`find $sourcedir/ '(' -name '*.rej' -o -name '.*.rej' ')' 
-print`" ]
+   then
+   echo "Aborting.  Reject files found."
+   return 1
+   fi
+   # Remove backup files
+   find $sourcedir/ '(' -name '*.orig' -o -name '.*.orig' ')' -exec rm -f 
{} \;
+
+   return 0
+}
+
 # set current VERSION, PATCHLEVEL, SUBLEVEL, EXTRAVERSION
 TMPFILE=`mktemp .tmpver.XX` || { echo "cannot make temp file" ; exit 1; }
 grep -E "^(VERSION|PATCHLEVEL|SUBLEVEL|EXTRAVERSION)" $sourcedir/Makefile > 
$TMPFILE
@@ -160,53 +208,57 @@ then
EXTRAVER=$EXTRAVERSION
fi
EXTRAVER=${EXTRAVER%%[[:punct:]]*}
-   #echo "patch-kernel: changing EXTRAVERSION from $EXTRAVERSION to 
$EXTRAVER"
+   #echo "$PNAME: changing EXTRAVERSION from $EXTRAVERSION to $EXTRAVER"
 fi
 
 #echo "stopvers=$stopvers"
 if [ $stopvers != "default" ]; then
STOPSUBLEVEL=`echo $stopvers | cut -d. -f3`
STOPEXTRA=`echo $stopvers | cut -d. -f4`
-   #echo "STOPSUBLEVEL=$STOPSUBLEVEL, STOPEXTRA=$STOPEXTRA"
+   #echo "#___STOPSUBLEVEL=/$STOPSUBLEVEL/, STOPEXTRA=/$STOPEXTRA/"
 else
STOPSUBLEVEL=
STOPEXTRA=
 fi
 
-while :# 

Re: [patch 4/5] sched: RCU sched domains

[Nick Piggin]

Paul E. McKenney wrote:
On Thu, Apr 07, 2005 at 05:58:40PM +1000, Nick Piggin wrote:

OK thanks for the good explanation. So I'll keep it as is for now,
and whatever needs cleaning up later can be worked out as it comes
up.

Looking forward to the split of synchronize_kernel() into synchronize_rcu()
and synchronize_sched(), the two choices are:
o   Use synchronize_rcu(), but insert rcu_read_lock()/rcu_read_unlock()
pairs on the read side.
o   Use synchronize_sched(), and make sure all read-side code is
under preempt_disable().
Yep, I think we'll go for the second option initially (because that
pretty closely matches the homebrew locking scheme that it used to
use).
Either way, there may also need to be some rcu_dereference()s when picking
up pointer and rcu_assign_pointer()s when updating the pointers.
For example, if traversing the domain parent list is to be RCU protected,
the for_each_domain() macro should change to something like:
Yes, I think you're right, because there's no barriers or synchronisation
when attaching a new domain. Just a small point though:
#define for_each_domain(cpu, domain) \
for (domain = cpu_rq(cpu)->sd; domain; domain = 
rcu_dereference(domain->parent))
This should probably be done like so?
#define for_each_domain(cpu, domain) \
for (domain = rcu_dereference(cpu_rq(cpu)->sd); domain; domain = 
domain->parent)
And I think it would be wise to use rcu_assign_pointer in the update too.
Thanks Paul.
--
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [discuss] [21/31] x86_64: Always use CPUID 80000008 to figure out MTRR address space size

[Siddha, Suresh B]

On Mon, Apr 11, 2005 at 08:00:01PM +0200, Andi Kleen wrote:
> On Sun, Apr 10, 2005 at 11:25:23PM -0700, Siddha, Suresh B wrote:
> > We need to use the size_and_mask in set_mtrr_var_ranges(which is called 
> > while programming MTRR's for AP's
> 
> Patch is ok for me. But how did you find this out? Did you force
> a mapping high in the address space?

No. It was through code inspection.

thanks,
suresh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]

[Pavel Machek]

Hi!

> > > > > No, XFS is my root filesystem. :( (Now that I think about it, would
> > > > > modularizing XFS and using an initrd be OK?)
> > > > 
> > > > Yes, loading xfs from initrd should help. [At least it did during
> > > > suse9.3 testing.]
> > > 
> > > Once I modularized xfs and switched to using an initrd, the problem
> > > disappeared.
> > 
> > I reproduced it locally. Problem is that xfsbufd goes refrigerated,
> > but someone still tries to wake it up *very* often. Probably something
> > else in xfs needs refrigerating, too, but I'm not a XFS wizard...
> 
> Thanks Pavel - I've been reading the thread from the other side
> of the fence, not understanding the swsusp side of things. :)
> 
> There are two ways the xfsbufd thread will wake up - either by its
> timer going off (for it to flush delayed write metadata buffers)
> or by being explicitly woken up when we're low on memory (in which
> case it also flushes out dirty metadata, such that pages can be
> cleaned and made available to the system).
> 
> Since the refrigerator() call is in place in the main xfsbufd loop,
> I suspect we're hitting that second case here, where a low memory
> situation is resulting in someone attempting to wakeup xfsbufd --
> I'm not sure if this is the right way to check if we're in that
> state, but does this patch help?  (it would certainly prevent the
> spurious wakeups, but only if the caller has PF_FREEZE set - will
> that be the case here?)

I should take some sleep now, so I can't test the patch, but I don't
think it will help. If someone has PF_FREEZE set, he should be in
refrigerator.

Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Processes stuck on D state on Dual Opteron

[Neil Brown]

On Monday April 11, [EMAIL PROTECTED] wrote:
> 
> Neil, have you had a look at the traces? Do they mean much to you?
> 

Just looked. 
bio_alloc_bioset seems implicated, as does sync_page_io.

sync_page_io used to use a 'struct bio' on the stack, but Jens Axboe
change it to use bio_alloc (don't know why..) and I should have 
checked the change better.

sync_page_io can be called on the write out path, so it should use
GFP_NOIO rather than GFP_KERNEL.

See if this helps Actually this patch is against 2.6.12-rc2-mm1
which uses md_super_write instead of sync_page_io (which is now only
used for read).  So if you are using a non-mm kernel (which seems to
be the case) you'll need to apply the patch by hand.


Thanks,
NeilBrown

---
Avoid deadlock in sync_page_io by using GFP_NOIO

..as sync_page_io can be called on the write-out path.
Ditto for md_super_write

Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./drivers/md/md.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff ./drivers/md/md.c~current~ ./drivers/md/md.c
--- ./drivers/md/md.c~current~  2005-04-08 11:25:26.0 +1000
+++ ./drivers/md/md.c   2005-04-12 09:42:29.0 +1000
@@ -351,7 +351,7 @@ void md_super_write(mddev_t *mddev, mdk_
 * if zero is reached.
 * If an error occurred, call md_error
 */
-   struct bio *bio = bio_alloc(GFP_KERNEL, 1);
+   struct bio *bio = bio_alloc(GFP_NOIO, 1);
 
bio->bi_bdev = rdev->bdev;
bio->bi_sector = sector;
@@ -374,7 +374,7 @@ static int bi_complete(struct bio *bio, 
 int sync_page_io(struct block_device *bdev, sector_t sector, int size,
   struct page *page, int rw)
 {
-   struct bio *bio = bio_alloc(GFP_KERNEL, 1);
+   struct bio *bio = bio_alloc(GFP_NOIO, 1);
struct completion event;
int ret;
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Bug?] Keyboard Problem

[Manu]

I'm currently using a 2.6.10 kernel (on a Debian Sarge, i386).

I've compiled a 2.6.11.5 and a 2.6.11.7 kernels and my keyboard (a
sweex SILVER MULTIMEDIA KEYBOARD, SW-23 -- PS/2 105 keys -- a
classical keyboard) doesn't work with these kernels.
I asked for help and one said me it is probably a bug in the kernel
since a normal keyboard must always work with the kernel.

I can give more informations if you need, say me.

Please send a copy of your replies, I'm not a subscriber for this list.

P.S.: English is not my native language, I'm doing the best I can. :)

Bye.
-- 
Manuel Dahmen
181 Avenue des Coteaux
4030 Grivegnée
04/367 46 48
MSN: [EMAIL PROTECTED]
http://stagiaires.ressource-toi.org/~rst237/


config-2.6.11.7
Description: Binary data

[PATCH] LifeView FlyTV Platinum FM: Remote Control support

[Peter Missel]

Greetings!

Subject says it ... this card's IR microcontroller design and attachment
are compatible to the company's previous designs, so the patch was as simple as 
it gets.

Note that this patch goes on top of the other one I posted yesterday, thank you 
very much.

regards,
Peter

--- linux-2.6.12-rc2/drivers/media/video/saa7134/saa7134-cards.c
2005-04-09 12:01:47.0 +0200
+++ video4linux/saa7134-cards.c 2005-04-12 00:58:57.0 +0200
@@ -1948,6 +1948,7 @@
dev->has_remote = 1;
board_flyvideo(dev);
break;
+   case SAA7134_BOARD_FLYTVPLATINUM_FM:
case SAA7134_BOARD_CINERGY400:
case SAA7134_BOARD_CINERGY600:
case SAA7134_BOARD_CINERGY600_MK3:

--- linux-2.6.12-rc2/drivers/media/video/saa7134/saa7134-input.c 2005-04-09 
12:01:47.0 +0200
+++ video4linux/saa7134-input.c 2005-04-12 01:15:11.0 +0200
@@ -379,6 +379,7 @@
switch (dev->board) {
case SAA7134_BOARD_FLYVIDEO2000:
case SAA7134_BOARD_FLYVIDEO3000:
+   case SAA7134_BOARD_FLYTVPLATINUM_FM:
ir_codes = flyvideo_codes;
mask_keycode = 0xEC0;
mask_keydown = 0x004;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Priority Lists for the RT mutex

[Perez-Gonzalez, Inaky]

>From: Bill Huey (hui) [mailto:[EMAIL PROTECTED]
>On Mon, Apr 11, 2005 at 03:31:41PM -0700, Perez-Gonzalez, Inaky wrote:
>> If you are exposing the kernel locks to userspace to implement
>> mutexes (eg POSIX mutexes), deadlock checking is a feature you want
>> to have to complain with POSIX. According to some off the record
>> requirements I've been given, some applications badly need it (I have
>> a hard time believing that they are so broken, but heck...).
>
>I'd like to read about those requirements, but, IMO a lot of the value

More than a formal requirement is a "practical" one. Some
company (leader in their field, of course) has this huge
blobl of code they want to use in Linux and it has the typical
API than once upon a time was made multithreaded by just adding
a bunch of pthread_mutex_[un]lock() at the API entry point...
without realizing that some of the top level API calls also 
called other top level API calls, so they'd deadlock.

Quick fix: the usual. Enable deadlock detection and if it
returns deadlock, assume it is locked already and proceed (or
do a recursive mutex, or a trylock).

And so on, and so forth...

>of various priority protocols varies greatly on the context and size (N
>threads) of the application using it. If user/kernel space have to be
>coupled via some thread of execution, (IMO) then it's better to
seperate
>them with some event notification queues like signals (wake a thread
>via an queue event) than to mix locks across the user/kernel space
> ...

I wonder if we are confusing apples and oranges here--I don't think
we were considering cases about mixing kernel locks that are accessible
both from kernel and user space. 

The focus is to have a kernel lock entity and that user space can
use it for implementing the user space mutexes, but *not* mix
them (like in user and kernel space sharing this lock for doing 
whatever).

It is certainly something to explore, but I'd better drive your
way than do it. It's cleaner. Hides implementation details.

>It's important to outline the requirements of the applications and then
>see what you can do using minimal synchronization objects before
>exploding that divide.

I agree, but it doesn't work that well when talking about legacy 
systems...that's the problem.

>Also, Posix isn't always politically neutral nor complete regarding
>various things. You have to consider the context of these things.
>I'll have to think about this a bit more and review your patch more
>carefully.

Sure--and because most was for legacy reasons that adhered to 
POSIX strictly, it was very simple: we need POSIX this, that and
that (PI, proper adherence to scheduler policy wake up/rt-behaviour,
deadlock detection, etc). 

Fortunately in those areas POSIX is not too gray; code to the book.
Deal. 

Of course, selling it to the lkml is another story.

-- Inaky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Call to atention about using hash functions as content indexers (SCM saga)

[Magnus Damm]

On 4/12/05, Petr Baudis <[EMAIL PROTECTED]> wrote:

> (iv) You fail to propose a better solution.

I would feel safer with back end storage filenames based on email and
mtime together with an optional hash lookup that turns collisions into
worse performance. But that's just me.

/ magnus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]

[Nathan Scott]

On Mon, Apr 11, 2005 at 12:57:59PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > No, XFS is my root filesystem. :( (Now that I think about it, would
> > > > modularizing XFS and using an initrd be OK?)
> > > 
> > > Yes, loading xfs from initrd should help. [At least it did during
> > > suse9.3 testing.]
> > 
> > Once I modularized xfs and switched to using an initrd, the problem
> > disappeared.
> 
> I reproduced it locally. Problem is that xfsbufd goes refrigerated,
> but someone still tries to wake it up *very* often. Probably something
> else in xfs needs refrigerating, too, but I'm not a XFS wizard...

Thanks Pavel - I've been reading the thread from the other side
of the fence, not understanding the swsusp side of things. :)

There are two ways the xfsbufd thread will wake up - either by its
timer going off (for it to flush delayed write metadata buffers)
or by being explicitly woken up when we're low on memory (in which
case it also flushes out dirty metadata, such that pages can be
cleaned and made available to the system).

Since the refrigerator() call is in place in the main xfsbufd loop,
I suspect we're hitting that second case here, where a low memory
situation is resulting in someone attempting to wakeup xfsbufd --
I'm not sure if this is the right way to check if we're in that
state, but does this patch help?  (it would certainly prevent the
spurious wakeups, but only if the caller has PF_FREEZE set - will
that be the case here?)

cheers.

-- 
Nathan


--- fs/xfs/linux-2.6/xfs_buf.c.orig 2005-04-12 09:00:26.375351560 +1000
+++ fs/xfs/linux-2.6/xfs_buf.c  2005-04-12 08:59:38.973557728 +1000
@@ -1753,6 +1753,8 @@ pagebuf_daemon_wakeup(
int priority,
unsigned intmask)
 {
+   if (current->flags & PF_FREEZE)
+   return 0;
force_flush = 1;
barrier();
wake_up_process(pagebuf_daemon_task);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Priority Lists for the RT mutex

[hui]

On Mon, Apr 11, 2005 at 03:31:41PM -0700, Perez-Gonzalez, Inaky wrote:
> If you are exposing the kernel locks to userspace to implement
> mutexes (eg POSIX mutexes), deadlock checking is a feature you want
> to have to complain with POSIX. According to some off the record
> requirements I've been given, some applications badly need it (I have 
> a hard time believing that they are so broken, but heck...).

I'd like to read about those requirements, but, IMO a lot of the value
of various priority protocols varies greatly on the context and size (N
threads) of the application using it. If user/kernel space have to be
coupled via some thread of execution, (IMO) then it's better to seperate
them with some event notification queues like signals (wake a thread
via an queue event) than to mix locks across the user/kernel space
boundary. There's tons of abuse that can be opened up with various
priority protocols with regard to RT apps and giving it a first class
entry way without consideration is kind of scary.

It's important to outline the requirements of the applications and then
see what you can do using minimal synchronization objects before
exploding that divide.

Also, Posix isn't always politically neutral nor complete regarding
various things. You have to consider the context of these things.
I'll have to think about this a bit more and review your patch more
carefully.

I'm all ears if you think I'm wrong.

bill

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

[PATCH 3/3] mm/Kconfig: give DISCONTIG more help text

[Dave Hansen]

This gives DISCONTIGMEM a bit more help text to explain
what it does, not just when to choose it.

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

 memhotplug-dave/mm/Kconfig |   10 ++
 1 files changed, 10 insertions(+)

diff -puN mm/Kconfig~A2-mm-Kconfig-DISCONTIG-help-text mm/Kconfig
--- memhotplug/mm/Kconfig~A2-mm-Kconfig-DISCONTIG-help-text 2005-04-11 
15:49:10.0 -0700
+++ memhotplug-dave/mm/Kconfig  2005-04-11 15:49:10.0 -0700
@@ -23,6 +23,16 @@ config DISCONTIGMEM_MANUAL
bool "Discontigious Memory"
depends on ARCH_DISCONTIGMEM_ENABLE
help
+ This option provides enhanced support for discontiguous
+ memory systems, over FLATMEM.  These systems have holes
+ in their physical address spaces, and this option provides
+ more efficient handling of these holes.  However, the vast
+ majority of hardware has quite flat address spaces, and
+ can have degraded performance from extra overhead that
+ this option imposes.
+
+ Many NUMA configurations will have this as the only option.
+
  If unsure, choose "Flat Memory" over this option.
 
 endchoice
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] mm/Kconfig: kill unused ARCH_FLATMEM_DISABLE

[Dave Hansen]

This used to be used to disable FLATMEM selection, but I decided
to change it to be done generically when DISCONTIG is enabled.
The option is unused, so this kills it.

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

 memhotplug-dave/./arch/mips/Kconfig   |4 
 memhotplug-dave/./arch/parisc/Kconfig |4 
 memhotplug-dave/./arch/sh/Kconfig |4 
 3 files changed, 12 deletions(-)

diff -puN ./arch/parisc/Kconfig~A0-mm-Kconfig-kill-ARCH_FLATMEM_DISABLE 
./arch/parisc/Kconfig
--- memhotplug/./arch/parisc/Kconfig~A0-mm-Kconfig-kill-ARCH_FLATMEM_DISABLE
2005-04-11 15:49:09.0 -0700
+++ memhotplug-dave/./arch/parisc/Kconfig   2005-04-11 15:49:09.0 
-0700
@@ -153,10 +153,6 @@ config ARCH_DISCONTIGMEM_ENABLE
  or have huge holes in the physical address space for other reasons.
  See  for more.
 
-config ARCH_FLATMEM_DISABLE
-   def_bool y
-   depends on ARCH_DISCONTIGMEM_ENABLE
-
 source "mm/Kconfig"
 
 config PREEMPT
diff -puN ./arch/sh/Kconfig~A0-mm-Kconfig-kill-ARCH_FLATMEM_DISABLE 
./arch/sh/Kconfig
--- memhotplug/./arch/sh/Kconfig~A0-mm-Kconfig-kill-ARCH_FLATMEM_DISABLE
2005-04-11 15:49:09.0 -0700
+++ memhotplug-dave/./arch/sh/Kconfig   2005-04-11 15:49:09.0 -0700
@@ -496,10 +496,6 @@ config ARCH_DISCONTIGMEM_ENABLE
  or have huge holes in the physical address space for other reasons.
  See  for more.
 
-config ARCH_FLATMEM_DISABLE
-   def_bool y
-   depends on ARCH_DISCONTIGMEM_ENABLE
-
 source "mm/Kconfig"
 
 config ZERO_PAGE_OFFSET
diff -puN ./arch/mips/Kconfig~A0-mm-Kconfig-kill-ARCH_FLATMEM_DISABLE 
./arch/mips/Kconfig
--- memhotplug/./arch/mips/Kconfig~A0-mm-Kconfig-kill-ARCH_FLATMEM_DISABLE  
2005-04-11 15:49:09.0 -0700
+++ memhotplug-dave/./arch/mips/Kconfig 2005-04-11 15:49:09.0 -0700
@@ -501,10 +501,6 @@ config ARCH_DISCONTIGMEM_ENABLE
  or have huge holes in the physical address space for other reasons.
  See  for more.
 
-config ARCH_FLATMEM_DISABLE
-   def_bool y
-   depends on ARCH_DISCONTIGMEM_ENABLE
-
 config NUMA
bool "NUMA Support"
depends on SGI_IP27
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/3] mm/Kconfig: hide "Memory Model" selection menu

[Dave Hansen]

I got some feedback from users who think that the new "Memory
Model" menu is a little invasive.  This patch will hide that menu,
except when CONFIG_EXPERIMENTAL is enabled *or* when an individual
architecture wants it.

An individual arch may want to enable it because they've removed
their arch-specific DISCONTIG prompt in favor of the mm/Kconfig one.

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

 arch/i386/Kconfig  |0 
 memhotplug-dave/mm/Kconfig |   21 +
 2 files changed, 17 insertions(+), 4 deletions(-)

diff -puN mm/Kconfig~A1-mm-Kconfig-hide-selection-menu mm/Kconfig
--- memhotplug/mm/Kconfig~A1-mm-Kconfig-hide-selection-menu 2005-04-11 
15:49:10.0 -0700
+++ memhotplug-dave/mm/Kconfig  2005-04-11 15:49:10.0 -0700
@@ -1,9 +1,14 @@
+config SELECT_MEMORY_MODEL
+   def_bool y
+   depends on EXPERIMENTAL || ARCH_SELECT_MEMORY_MODEL
+
 choice
prompt "Memory model"
-   default DISCONTIGMEM if ARCH_DISCONTIGMEM_DEFAULT
-   default FLATMEM
+   depends on SELECT_MEMORY_MODEL
+   default DISCONTIGMEM_MANUAL if ARCH_DISCONTIGMEM_DEFAULT
+   default FLATMEM_MANUAL
 
-config FLATMEM
+config FLATMEM_MANUAL
bool "Flat Memory"
depends on !ARCH_DISCONTIGMEM_ENABLE || ARCH_FLATMEM_ENABLE
help
@@ -14,7 +19,7 @@ config FLATMEM
 
  If unsure, choose this option over any other.
 
-config DISCONTIGMEM
+config DISCONTIGMEM_MANUAL
bool "Discontigious Memory"
depends on ARCH_DISCONTIGMEM_ENABLE
help
@@ -22,6 +27,14 @@ config DISCONTIGMEM
 
 endchoice
 
+config DISCONTIGMEM
+   def_bool y
+   depends on (!SELECT_MEMORY_MODEL && ARCH_DISCONTIGMEM_ENABLE) || 
DISCONTIGMEM_MANUAL
+
+config FLATMEM
+   def_bool y
+   depends on !DISCONTIGMEM || FLATMEM_MANUAL
+
 #
 # Both the NUMA code and DISCONTIGMEM use arrays of pg_data_t's
 # to represent different areas of memory.  This variable allows
diff -puN arch/i386/Kconfig~A1-mm-Kconfig-hide-selection-menu arch/i386/Kconfig
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Processes stuck on D state on Dual Opteron

[Nick Piggin]

Claudio Martins wrote:
   Right. I'm using two Seagate ATA133 disks (ide controler is AMD-8111) each 
with 4 partitions, so I get 4 md Raid1 devices. The first one, md0, is for 
swap. The rest are

~$ df -h
FilesystemSize  Used Avail Use% Mounted on
/dev/md1  4.6G  1.9G  2.6G  42% /
tmpfs1005M 0 1005M   0% /dev/shm
/dev/md3   32G  107M   30G   1% /home
/dev/md2   31G  149M   29G   1% /var
  In these tests, /home on md3 is the working area for stress.
  The io scheduler used is the anticipatory. 

OK.
  OK, I'll try them in a few minutes and report back.
 
I'm not overly hopeful. If they fix the problem, then it's likely
that the real bug is hidden.
  I'm curious as whether increasing the vm.min_free_kbytes sysctl value would 
help or not in this case. But I guess it wouldn't since there is already some 
free memory and also the alloc failures are order 0, right?

Yes. And the failures you were seeing with my first patch were coming
from the mempool code anyway. We want those to fail early so they don't
eat into the min_free_kbytes memory.
You could try raising min_free_kbytes though. If that fixes it, then it
indicates there might be some problem in a memory allocation failure
path in software raid somewhere.
Thanks
--
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Call to atention about using hash functions as content indexers (SCM saga)

[Petr Baudis]

Dear diary, on Tue, Apr 12, 2005 at 12:40:21AM CEST, I got a letter
where Pedro Larroy <[EMAIL PROTECTED]> told me that...
> Hi

Hello,

> I had a quick look at the source of GIT tonight, I'd like to warn you
> about the use of hash functions as content indexers.
> 
> As probably you are aware, hash functions such as SHA-1 are surjective not
> bijective (1-to-1 map), so they have collisions. Here one can argue
> about the low probability of such a collision, I won't get into
> subjetive valorations of what probability of collision is tolerable for
> me and what is not. 
> 
> I my humble opinion, choosing deliberately, as a design decision, a
> method such as this one, that in some cases could corrupt data in a
> silent and very hard to detect way, is not very good. One can also argue
> that the probability of data getting corrupted in the disk, or whatever
> could be higher than that of the collision, again this is not valid
> comparison, since the fact that indexing by hash functions without
> additional checking could make data corruption legal between the
> reasonable working parameters of the program is very dangerous.

(i) 1461501637330902918203684832716283019655932542976 possible SHA1 hashes.

(ii) In git-pasky, there's (turnable off) detection of collisions.

(iii) Your argument against comparing with the probability of a hardware
error does not make sense to me.

(iv) You fail to propose a better solution.

-- 
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: New SCM and commit list

[Daniel Barkalow]

On Sun, 10 Apr 2005, Linus Torvalds wrote:

> On Mon, 11 Apr 2005, Jeff Garzik wrote:
> > 
> > > But I hope that I can get non-conflicting merges done fairly soon, and 
> > > maybe I can con James or Jeff or somebody to try out GIT then...
> > 
> > I don't mind being a guinea pig as long as someone else does the hard 
> > work of finding a new way to merge :)
> 
> So I can tell you what merges are going to be like, just to prepare you.
> 
> First, the good news: I think we can make the workflow look like bk, ie
> pretty much like "git pull" and "git push".  And for well-behaved stuff
> (ie minimal changes to the same files on both sides) it will even be fast.  
> I think.
> 
> Then the bad news: the merge algorithm is going to suck. It's going to be
> just plain 3-way merge, the same RCS/CVS thing you've seen before. With no
> understanding of renames etc. I'll try to find the best parent to base the
> merge off of, although early testers may have to tell the piece of crud
> what the most recent common parent was.
>
> So anything that got modified in just one tree obviously merges to that 
> version. Any file that got modified in two trees will end up just being 
> passed to the "merge" program. See "man merge" and "man diff3". The merger 
> gets to fix up any conflicts by hand.

If merge took trees instead of single files, and had some way of detecting
renames (or it got additional information about the differences between
files), would that give BK-quality performance? Or does BK also support
cases like:

orig ---> first ---> first-merge -
 |/   \
 |--> second - -> final
 |\   /
 |--> third ---> third-merge -

where the final merge requires, for complete cleanliness, a comparison of
more than 3 states (since some changes will have orig as the common
ancestor and some will have second).

Does this happen in real life? It seems like sane development processes
wouldn't have multiple mainline-candidate patch sets including the same
patches, if for no other reason than that, should the merge fail, nobody
with any clue about the original patches would be anywhere nearby. It
seems better to throw something back to someone to rebase their diffs.

Otherwise, the problem seems to boil down to finding the common ancestor
well, getting trees instead of files to merge, and improving merge until
it handles all of the tractible cases.

-Daniel
*This .sig left intentionally blank*

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

Re: [PATCH 2/3] Keys: Use RCU to manage session keyring pointer

[Paul E. McKenney]

On Wed, Mar 23, 2005 at 08:55:46PM +, David Howells wrote:
> 
> The attached patch uses RCU to manage the session keyring pointer in struct
> signal_struct. This means that searching need not disable interrupts and get a
> the sighand spinlock to access this pointer. Furthermore, by judicious use of
> rcu_read_(un)lock(), this patch also avoids the need to take and put refcounts
> on the session keyring itself, thus saving on even more atomic ops.
> 
> Signed-Off-By: David Howells <[EMAIL PROTECTED]>

This looks quite good!  A few questions interspersed below.

Thanx, Paul

PS.  Sorry to be so slow in getting to this one!

> ---
> warthog>diffstat -p1 keys-rcu-session-2612rc1mm1.diff 
>  security/keys/process_keys.c |   42 
> +-
>  security/keys/request_key.c  |7 +++
>  2 files changed, 24 insertions(+), 25 deletions(-)
> 
> diff -uNrp linux-2.6.12-rc1-mm1-keys-umhelper/security/keys/process_keys.c 
> linux-2.6.12-rc1-mm1-keys-rcu-session/security/keys/process_keys.c
> --- linux-2.6.12-rc1-mm1-keys-umhelper/security/keys/process_keys.c   
> 2005-03-23 17:22:46.0 +
> +++ linux-2.6.12-rc1-mm1-keys-rcu-session/security/keys/process_keys.c
> 2005-03-23 18:27:12.055768099 +
> @@ -1,6 +1,6 @@
>  /* process_keys.c: management of a process's keyrings
>   *
> - * Copyright (C) 2004 Red Hat, Inc. All Rights Reserved.
> + * Copyright (C) 2004-5 Red Hat, Inc. All Rights Reserved.
>   * Written by David Howells ([EMAIL PROTECTED])
>   *
>   * This program is free software; you can redistribute it and/or
> @@ -181,7 +181,7 @@ static int install_process_keyring(struc
>   goto error;
>   }
>  
> - /* attach or swap keyrings */
> + /* attach keyring */
>   spin_lock_irqsave(>sighand->siglock, flags);
>   if (!tsk->signal->process_keyring) {
>   tsk->signal->process_keyring = keyring;
> @@ -227,12 +227,14 @@ static int install_session_keyring(struc
>  
>   /* install the keyring */
>   spin_lock_irqsave(>sighand->siglock, flags);
> - old = tsk->signal->session_keyring;
> - tsk->signal->session_keyring = keyring;
> + old = rcu_dereference(tsk->signal->session_keyring);

I don't understand why rcu_dereference() is needed in this case.
Since we are holding the lock, it should not be possible for
this to change, right?  Or am I missing something?  (Quite possible,
am not all that familiar with this code.)

> + rcu_assign_pointer(tsk->signal->session_keyring, keyring);
>   spin_unlock_irqrestore(>sighand->siglock, flags);
>  
>   ret = 0;
>  
> + /* we're using RCU on the pointer */
> + synchronize_kernel();

This would want to become synchronize_rcu().

>   key_put(old);
>   error:
>   return ret;
> @@ -245,8 +247,6 @@ static int install_session_keyring(struc
>   */
>  int copy_thread_group_keys(struct task_struct *tsk)
>  {
> - unsigned long flags;
> -
>   key_check(current->thread_group->session_keyring);
>   key_check(current->thread_group->process_keyring);
>  
> @@ -254,10 +254,10 @@ int copy_thread_group_keys(struct task_s
>   tsk->signal->process_keyring = NULL;
>  
>   /* same session keyring */
> - spin_lock_irqsave(>sighand->siglock, flags);
> + rcu_read_lock();
>   tsk->signal->session_keyring =
> - key_get(current->signal->session_keyring);
> - spin_unlock_irqrestore(>sighand->siglock, flags);
> + key_get(rcu_dereference(current->signal->session_keyring));
> + rcu_read_unlock();
>  
>   return 0;
>  
> @@ -381,8 +381,7 @@ struct key *search_process_keyrings_aux(
>   key_match_func_t match)
>  {
>   struct task_struct *tsk = current;
> - unsigned long flags;
> - struct key *key, *ret, *err, *tmp;
> + struct key *key, *ret, *err;
>  
>   /* we want to return -EAGAIN or -ENOKEY if any of the keyrings were
>* searchable, but we failed to find a key or we found a negative key;
> @@ -436,17 +435,18 @@ struct key *search_process_keyrings_aux(
>   }
>  
>   /* search the session keyring last */
> - spin_lock_irqsave(>sighand->siglock, flags);
> -
> - tmp = tsk->signal->session_keyring;
> - if (!tmp)
> - tmp = tsk->user->session_keyring;
> - atomic_inc(>usage);
> -
> - spin_unlock_irqrestore(>sighand->siglock, flags);
> + if (tsk->signal->session_keyring) {
> + rcu_read_lock();
> + key = keyring_search_aux(
> + rcu_dereference(tsk->signal->session_keyring),
> + type, description, match);
> + rcu_read_unlock();
> + }
> + else {
> + key = keyring_search_aux(tsk->user->session_keyring,
> +  type, description, match);

This one is constant, right?  If not, I 

[patch, I hope you like it better this way :-)] fix few remaining u32 vs. pm_message_t problems in -mm3

[Pavel Machek]

This fixes remaining u32 vs. pm_message_t confusions in
-rc2-mm3. [There are usb changes, too; they went to Greg on his
request.]

Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>

--- clean-mm/drivers/macintosh/via-pmu.c2005-04-11 22:53:30.0 
+0200
+++ linux-mm/drivers/macintosh/via-pmu.c2005-04-11 23:09:13.0 
+0200
@@ -2371,7 +2371,7 @@
 * use this but still... This will take care of sysdev's as well, so
 * we exit from here with local irqs disabled and PIC off.
 */
-   ret = device_power_down(PM_SUSPEND_MEM);
+   ret = device_power_down(PMSG_SUSPEND);
if (ret) {
wakeup_decrementer();
local_irq_enable();

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

Call to atention about using hash functions as content indexers (SCM saga)

[Pedro Larroy]

Hi

I had a quick look at the source of GIT tonight, I'd like to warn you
about the use of hash functions as content indexers.

As probably you are aware, hash functions such as SHA-1 are surjective not
bijective (1-to-1 map), so they have collisions. Here one can argue
about the low probability of such a collision, I won't get into
subjetive valorations of what probability of collision is tolerable for
me and what is not. 

I my humble opinion, choosing deliberately, as a design decision, a
method such as this one, that in some cases could corrupt data in a
silent and very hard to detect way, is not very good. One can also argue
that the probability of data getting corrupted in the disk, or whatever
could be higher than that of the collision, again this is not valid
comparison, since the fact that indexing by hash functions without
additional checking could make data corruption legal between the
reasonable working parameters of the program is very dangerous.

And by the way, I've read
http://www.usenix.org/events/hotos03/tech/full_papers/henson/henson_html/node15.html

and I don't agree with it. Asides from the "avalanche effect" the
properties of a good hash function is that distributes well the entropy
between the output bits, so probably, although the inputs are not
random, the pdf change in the outputs would be small, otherwise it would
be easier to find collision by differential or statistical methods.

Last, hash functions should be only used to check data integrity, and
that's the reason of the "avalanche effect", so even single bit errors
are propagated and it's effect is very noticeable at the output.

Regards.

-- 
Pedro Larroy Tovar | Linux & Network consultant |  pedro%larroy.com 
Make debian mirrors with debian-multimirror: http://pedro.larroy.com/deb_mm/
* Las patentes de programación son nocivas para la innovación * 
http://proinnova.hispalinux.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/

[PATCH] Fix help text for ixdp465

[Russell King]

For some reason, this help text was missed when the file was
last audited by the documentation referencing folk.  Fix this
incorrect documentation reference.

Signed-off-by: Russell King <[EMAIL PROTECTED]>

diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x '*.orig' -x '*.rej' -r 
orig/arch/arm/mach-ixp4xx/Kconfig linux/arch/arm/mach-ixp4xx/Kconfig
--- orig/arch/arm/mach-ixp4xx/Kconfig   Sun Feb  6 11:37:44 2005
+++ linux/arch/arm/mach-ixp4xx/Kconfig  Tue Feb  1 00:05:28 2005
@@ -41,7 +41,7 @@ config MACH_IXDP465
help
  Say 'Y' here if you want your kernel to support Intel's
  IXDP465 Development Platform (Also known as BMP).
- For more information on this platform, see Documentation/arm/IXP4xx.
+ For more information on this platform, see 
.
 
 
 #

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Priority Lists for the RT mutex

[Perez-Gonzalez, Inaky]

>From: Bill Huey (hui) [mailto:[EMAIL PROTECTED]
>
>On Mon, Apr 11, 2005 at 10:57:37AM +0200, Ingo Molnar wrote:
>>
>> * Perez-Gonzalez, Inaky <[EMAIL PROTECTED]> wrote:
>>
>> > Let me re-phrase then: it is a must have only on PI, to make sure
you
>> > don't have a loop when doing it. Maybe is a consequence of the
>> > algorithm I chose. -However- it should be possible to disable it in
>> > cases where you are reasonably sure it won't happen (such as kernel
>> > code). In any case, AFAIR, I still did not implement it.
>>
>> are there cases where userspace wants to disable deadlock-detection
for
>> its own locks?
>
>I'd disable it for userspace locks. There might be folks that want to
>implement userspace drivers, but I can't imagine it being 'ok' to have
>the kernel call out to userspace and have it block correctly. I would
>expect them to do something else that's less drastic.

If you are exposing the kernel locks to userspace to implement
mutexes (eg POSIX mutexes), deadlock checking is a feature you want
to have to complain with POSIX. According to some off the record
requirements I've been given, some applications badly need it (I have 
a hard time believing that they are so broken, but heck...).

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

[PATCH] Add comment about dma_supported()

[Russell King]

The ARM dma_supported() is rather basic, and I don't think
it takes into account everything that it should do (eg,
whether the mask agrees with what we'd return for GFP_DMA
allocations).  Note this.

Signed-off-by: Russell King <[EMAIL PROTECTED]>

diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x '*.orig' -x '*.rej' -r 
orig/include/asm-arm/dma-mapping.h linux/include/asm-arm/dma-mapping.h
--- orig/include/asm-arm/dma-mapping.h  Wed Jan 12 10:13:19 2005
+++ linux/include/asm-arm/dma-mapping.h Fri Jun 18 17:56:02 2004
@@ -21,6 +21,9 @@ extern void consistent_sync(void *kaddr,
  * properly.  For example, if your device can only drive the low 24-bits
  * during bus mastering, then you would pass 0x00ff as the mask
  * to this function.
+ *
+ * FIXME: This should really be a platform specific issue - we should
+ * return false if GFP_DMA allocations may not satisfy the supplied 'mask'.
  */
 static inline int dma_supported(struct device *dev, u64 mask)
 {

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-rc2-mm3

[Benoit Boissinot]

On Apr 11, 2005 10:46 PM, Martin J. Bligh <[EMAIL PROTECTED]> wrote:
> 
> 
> --On Monday, April 11, 2005 01:25:32 -0700 Andrew Morton <[EMAIL PROTECTED]> 
> wrote:
> 
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
> >
> >
> > - The anticipatory I/O scheduler has always been fairly useless with SCSI
> >   disks which perform tagged command queueing.  There's a patch here from 
> > Jens
> >   which is designed to fix that up by constraining the number of requests
> >   which we'll leave pending in the device.
> >
> >   The depth currently defaults to 1.  Tunable in
> >   /sys/block/hdX/queue/iosched/queue_depth
> >
> >   This patch hasn't been performance tested at all yet.  If you think it is
> >   misbehaving (the usual symptom is processes stuck in D state) then please
> >   report it, then boot with `elevator=cfq' or `elevator=deadline' to work
> >   around it.
> >
> > - More CPU scheduler work.  I hope someone is testing this stuff.
> 
> Trying ... having some build problems that seem to be part test-harness,
> part bugs.
> 
> Meanwhile on PPC64:
> 
> fs/cifs/misc.c: In function `cifs_convertUCSpath':
> fs/cifs/misc.c:546: error: case label does not reduce to an integer constant
> fs/cifs/misc.c:549: error: case label does not reduce to an integer constant
> fs/cifs/misc.c:552: error: case label does not reduce to an integer constant
> fs/cifs/misc.c:561: error: case label does not reduce to an integer constant
> fs/cifs/misc.c:564: error: case label does not reduce to an integer constant
> fs/cifs/misc.c:567: error: case label does not reduce to an integer constant
> make[2]: *** [fs/cifs/misc.o] Error 1
> make[1]: *** [fs/cifs] Error 2
> make[1]: *** Waiting for unfinished jobs
> 
>
See this patch from Steve French:
http://cifs.bkbits.net:8080/linux-2.5cifs/[EMAIL PROTECTED]
 
> M.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message 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: Linux 2.4.30-rc3 md/ext3 problems (ext3 gurus : please check)

[Stephen C. Tweedie]

Hi,

On Mon, 2005-04-11 at 21:46, Andrew Morton wrote:
> "Stephen C. Tweedie" <[EMAIL PROTECTED]> wrote:
> >
> > Andrew, what was the exact illegal state of the pages you were seeing
> >  when fixing that recent leak?  It looks like it's nothing more complex
> >  than dirty buffers on an anon page.
> 
> Correct.

Good --- I think I've got the debugging solid against 2.4 for that case,
patching against 2.6 now.

> >  I think that simply calling
> >  try_to_release_page() for all the remaining buffers at umount time will
> 
> Presumably these pages have no ->mapping, so try_to_release_page() will
> call try_to_free_buffers().

Exactly.

> >  The only thing that would be required on
> >  top of that would be a check that the page is also on the VM LRU lists.
> 
> Why do we have dirty buffers left over at umount time?

In the leak case we're worried about, the buffers are dirty but the page
is anon so there's nothing to clean them up.  The buffers _will_ be
destroyed by unmount, sure; invalidate_bdev() should see to that.  But
I'm doing the bh leak check before we get to the final
invalidate_bdev(), so they should still be available for testing at that
point.

--Stephen

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

Re: 2.6.12-rc2-mm3

[Andrew Morton]

Borislav Petkov <[EMAIL PROTECTED]> wrote:
>
> On Monday 11 April 2005 11:43, Andrew Morton wrote:
> > (Please do reply-to-all)
> >
> > "J.A. Magallon" <[EMAIL PROTECTED]> wrote:
> > > On 04.11, Andrew Morton wrote:
> > >  > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-r
> > >  >c2/2.6.12-rc2-mm3/
> > >
> > >  Is this not needed anymore ?
> > >
> > >  --- 25/arch/i386/kernel/entry.S~nmi_stack_correct-fix2005-04-05
> > > 00:02:48.0 -0700 +++ 25-akpm/arch/i386/kernel/entry.S 
> > > 2005-04-05
> > > 00:02:48.0 -0700
> >
> > Hopefully not. fix-crash-in-entrys-restore_all.patch works around the
> > problem. -
> 
> Hello Andrew,
> I don't know whether you remember the mysterious crashes I was telling you 
> about last week and me rookiesh-ly trying to debug them with kgdb over the 
> serial console. Well, today I tried for the n-th time again and after rc2-mm3 
> blocked again while loading, here's what I did:
> 
> 
> [   12.335438] NET: Registered protocol family 17
> [   12.362483] Testing NMI watchdog ... OK.
> [   12.416195] Starting balanced_irq
> [   12.443099] VFS: Mounted root (ext2 filesystem) readonly.
> [   12.472490] Freeing unused kernel memory: 196k freed
> [   12.521004] logips2pp: Detected unknown logitech mouse model 1
> [   12.572581] Warning: unable to open an initial console.
> [   12.972518] input: PS/2 Logitech Mouse on isa0060/serio1
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0xc0102ee7 in resume_kernelX () at atomic.h:175 <--- this one is wrong for a 
> mysterious reason
> 175 {
> (gdb) p $eip
> $1 = (void *) 0xc0102ee7
> 
> (gdb) disas 0xc0102ee7
> Dump of assembler code for function resume_kernelX:
> 0xc0102ee7 :  mov0x30(%esp),%eax
> 0xc0102eeb :  mov0x38(%esp),%ah
> 0xc0102eef :  mov0x2c(%esp),%al
> 0xc0102ef3 : and$0x20403,%eax
> 0xc0102ef8 : cmp$0x403,%eax
> 0xc0102efd : je 0xc0102f0c 
> End of assembler dump.
> (gdb)  
> 
> And as we see, we're at the "mov0x30(%esp),%eax" which accesses above the 
> bottom of the stack. After applying nmi_stack_correct-fix.patch, rc2-mm3 
> booted just fine, so I IMHO think that we might still be needing this, after 
> all.

Interesting.  It could be an interaction between the kgdb patch and the new
vm86 checking code.  (looks.  I don't think that's the case).

Stas, could you please take a look at 2.6.12-rc2-mm3's entry.S sometime,
see if you think my theory is correct?

It seems that you have CONFIG_TRAP_BAD_SYSCALL_EXITS enabled - I can't say
that I've ever used that, and I really should remove it.  But I doubt if
that is the cause of this bug.


The above code is accessing esp+56, but Stas's patch only offsets the stack
pointer by 32 bytes, so I assume this, in copy_thread():

-   p->thread.esp0 = (unsigned long) (childregs+1) - 8;
+   p->thread.esp0 = (unsigned long) (childregs+1) - 15;

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

[PATCH] Fix comments in 8250.c

[Russell King]

Fix the formatting of some comments in 8250.c, and add a note
that the register_serial / unregister_serial shouldn't be used
in new code.

We do this here in preference to adding to linux/serial.h, since
that is used by a number of non-8250 drivers which pretend to be
8250.  It is not known whether it would be appropriate to do so.

Signed-off-by: Russell King <[EMAIL PROTECTED]>

diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x '*.orig' -x '*.rej' -r 
orig/drivers/serial/8250.c linux/drivers/serial/8250.c
--- orig/drivers/serial/8250.c  Mon Apr  4 22:54:05 2005
+++ linux/drivers/serial/8250.c Mon Apr 11 20:41:22 2005
@@ -1065,8 +1065,10 @@ receive_chars(struct uart_8250_port *up,
tty_flip_buffer_push(tty);
spin_lock(>port.lock);
}
-   /* If this failed then we will throw away the
-  bytes but must do so to clear interrupts */
+   /*
+* If this failed then we will throw away the
+* bytes but must do so to clear interrupts
+*/
}
ch = serial_inp(up, UART_RX);
flag = TTY_NORMAL;
@@ -1106,7 +1108,7 @@ receive_chars(struct uart_8250_port *up,
up->port.icount.overrun++;
 
/*
-* Mask off conditions which should be ingored.
+* Mask off conditions which should be ignored.
 */
lsr &= up->port.read_status_mask;
 
@@ -2570,6 +2572,9 @@ MODULE_ALIAS_CHARDEV_MAJOR(TTY_MAJOR);
  * If this fails an error is returned.
  *
  * On success the port is ready to use and the line number is returned.
+ *
+ * Note: this function is deprecated - use serial8250_register_port
+ * instead.
  */
 int register_serial(struct serial_struct *req)
 {
@@ -2624,6 +2629,9 @@ EXPORT_SYMBOL(register_serial);
  *
  * Remove one serial port.  This may not be called from interrupt
  * context.  We hand the port back to our local PM control.
+ *
+ * Note: this function is deprecated - use serial8250_unregister_port
+ * instead.
  */
 void unregister_serial(int 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] Priority Lists for the RT mutex

[hui]

On Mon, Apr 11, 2005 at 10:57:37AM +0200, Ingo Molnar wrote:
> 
> * Perez-Gonzalez, Inaky <[EMAIL PROTECTED]> wrote:
> 
> > Let me re-phrase then: it is a must have only on PI, to make sure you 
> > don't have a loop when doing it. Maybe is a consequence of the 
> > algorithm I chose. -However- it should be possible to disable it in 
> > cases where you are reasonably sure it won't happen (such as kernel 
> > code). In any case, AFAIR, I still did not implement it.
> 
> are there cases where userspace wants to disable deadlock-detection for 
> its own locks?

I'd disable it for userspace locks. There might be folks that want to
implement userspace drivers, but I can't imagine it being 'ok' to have
the kernel call out to userspace and have it block correctly. I would
expect them to do something else that's less drastic.
 
> the deadlock detector in PREEMPT_RT is pretty much specialized for 
> debugging (it does all sorts of weird locking tricks to get the first 
> deadlock out, and to really report it on the console), but it ought to 
> be possible to make it usable for userspace-controlled locks as well.

If I understand things correctly, I'd let that be an RT app issue and
the app folks should decided what is appropriate for their setup. If
they need a deadlock detector they should decide on their own protocol.
The kernel debugging issues are completely different.

That's my two cents.

bill

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

[PATCH] Fix floppy disk dependencies

[Russell King]

Both the RiscPC and (optionally) EBSA285 have floppy disk
support.  Allow this option to be selected on these ARM
platforms again.

Signed-off-by: Russell King <[EMAIL PROTECTED]>

diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x '*.orig' -x '*.rej' -r 
orig/drivers/block/Kconfig linux/drivers/block/Kconfig
--- orig/drivers/block/Kconfig  Mon Apr  4 22:53:23 2005
+++ linux/drivers/block/Kconfig Mon Apr  4 23:42:07 2005
@@ -6,7 +6,7 @@ menu "Block devices"
 
 config BLK_DEV_FD
tristate "Normal floppy disk support"
-   depends on (!ARCH_S390 && !M68K && !IA64 && !UML) || Q40 || (SUN3X && 
BROKEN)
+   depends on (!ARCH_S390 && !M68K && !IA64 && !UML) || Q40 || (SUN3X && 
BROKEN) || ARCH_RPC || ARCH_EBSA285
---help---
  If you want to use the floppy disk drive(s) of your PC under Linux,
  say Y. Information about this driver, especially important for IBM

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

[PATCH] Add comment about max_low_pfn/max_pfn

[Russell King]

Oddly, max_low_pfn/max_pfn end up being the number of pages
in the system, rather than the maximum PFN on ARM.  This
doesn't seem to cause any problems, so just add a note about
it.

Signed-off-by: Russell King <[EMAIL PROTECTED]>

diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x '*.orig' -x '*.rej' -r 
orig/arch/arm/mm/init.c linux/arch/arm/mm/init.c
--- orig/arch/arm/mm/init.c Sat Mar 19 11:20:00 2005
+++ linux/arch/arm/mm/init.cMon Apr 11 14:06:10 2005
@@ -223,6 +223,9 @@ find_memend_and_nodes(struct meminfo *mi
 * This doesn't seem to be used by the Linux memory
 * manager any more.  If we can get rid of it, we
 * also get rid of some of the stuff above as well.
+*
+* Note: max_low_pfn and max_pfn reflect the number
+* of _pages_ in the system, not the maximum PFN.
 */
max_low_pfn = memend_pfn - O_PFN_DOWN(PHYS_OFFSET);
max_pfn = memend_pfn - O_PFN_DOWN(PHYS_OFFSET);

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

[PATCH] Fix SIGBUS handling

[Russell King]

ARM wasn't raising a SIGBUS with a siginfo structure.  Fix
__do_user_fault() to allow us to use it for SIGBUS conditions,
and arrange for the sigbus path to use this.

We need to prevent the siginfo code being called if we do
not have a user space context to call it, so consolidate the
"user_mode()" tests.

Thanks to Ian Campbell who spotted this oversight.

Signed-off-by: Russell King <[EMAIL PROTECTED]>

diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x *.orig -x *.rej 
orig/arch/arm/mm/fault.c linux/arch/arm/mm/fault.c
--- orig/arch/arm/mm/fault.cFri Nov  5 19:28:15 2004
+++ linux/arch/arm/mm/fault.c   Fri Apr  8 14:24:50 2005
@@ -108,14 +108,15 @@ __do_kernel_fault(struct mm_struct *mm, 
  */
 static void
 __do_user_fault(struct task_struct *tsk, unsigned long addr,
-   unsigned int fsr, int code, struct pt_regs *regs)
+   unsigned int fsr, unsigned int sig, int code,
+   struct pt_regs *regs)
 {
struct siginfo si;
 
 #ifdef CONFIG_DEBUG_USER
if (user_debug & UDBG_SEGV) {
-   printk(KERN_DEBUG "%s: unhandled page fault at 0x%08lx, code 
0x%03x\n",
-  tsk->comm, addr, fsr);
+   printk(KERN_DEBUG "%s: unhandled page fault (%d) at 0x%08lx, 
code 0x%03x\n",
+  tsk->comm, sig, addr, fsr);
show_pte(tsk->mm, addr);
show_regs(regs);
}
@@ -124,11 +125,11 @@ __do_user_fault(struct task_struct *tsk,
tsk->thread.address = addr;
tsk->thread.error_code = fsr;
tsk->thread.trap_no = 14;
-   si.si_signo = SIGSEGV;
+   si.si_signo = sig;
si.si_errno = 0;
si.si_code = code;
si.si_addr = (void __user *)addr;
-   force_sig_info(SIGSEGV, , tsk);
+   force_sig_info(sig, , tsk);
 }
 
 void
@@ -140,7 +141,7 @@ do_bad_area(struct task_struct *tsk, str
 * have no context to handle this fault with.
 */
if (user_mode(regs))
-   __do_user_fault(tsk, addr, fsr, SEGV_MAPERR, regs);
+   __do_user_fault(tsk, addr, fsr, SIGSEGV, SEGV_MAPERR, regs);
else
__do_kernel_fault(mm, addr, fsr, regs);
 }
@@ -201,10 +202,11 @@ survive:
goto out;
 
/*
-* If we are out of memory for pid1,
-* sleep for a while and retry
+* If we are out of memory for pid1, sleep for a while and retry
 */
+   up_read(>mmap_sem);
yield();
+   down_read(>mmap_sem);
goto survive;
 
 check_stack:
@@ -219,7 +221,7 @@ do_page_fault(unsigned long addr, unsign
 {
struct task_struct *tsk;
struct mm_struct *mm;
-   int fault;
+   int fault, sig, code;
 
tsk = current;
mm  = tsk->mm;
@@ -242,55 +244,45 @@ do_page_fault(unsigned long addr, unsign
return 0;
 
/*
-* We had some memory, but were unable to
-* successfully fix up this page fault.
-*/
-   if (fault == 0)
-   goto do_sigbus;
-
-   /*
 * If we are in kernel mode at this point, we
 * have no context to handle this fault with.
 */
if (!user_mode(regs))
goto no_context;
 
-   if (fault == VM_FAULT_OOM) {
+   switch (fault) {
+   case VM_FAULT_OOM:
/*
-* We ran out of memory, or some other thing happened to
-* us that made us unable to handle the page fault gracefully.
+* We ran out of memory, or some other thing
+* happened to us that made us unable to handle
+* the page fault gracefully.
 */
printk("VM: killing process %s\n", tsk->comm);
do_exit(SIGKILL);
-   } else
-   __do_user_fault(tsk, addr, fsr, fault == VM_FAULT_BADACCESS ?
-   SEGV_ACCERR : SEGV_MAPERR, regs);
-   return 0;
+   return 0;
 
+   case 0:
+   /*
+* We had some memory, but were unable to
+* successfully fix up this page fault.
+*/
+   sig = SIGBUS;
+   code = BUS_ADRERR;
+   break;
 
-/*
- * We ran out of memory, or some other thing happened to us that made
- * us unable to handle the page fault gracefully.
- */
-do_sigbus:
-   /*
-* Send a sigbus, regardless of whether we were in kernel
-* or user mode.
-*/
-   tsk->thread.address = addr;
-   tsk->thread.error_code = fsr;
-   tsk->thread.trap_no = 14;
-   force_sig(SIGBUS, tsk);
-#ifdef CONFIG_DEBUG_USER
-   if (user_debug & UDBG_BUS) {
-   printk(KERN_DEBUG "%s: sigbus at 0x%08lx, pc=0x%08lx\n",
-   current->comm, addr, instruction_pointer(regs));
+   default:
+   /*
+* Something tried to access memory that
+* isn't in our memory map..
+  

Re: [patch 4/5] sched: RCU sched domains

[Paul E. McKenney]

On Thu, Apr 07, 2005 at 05:58:40PM +1000, Nick Piggin wrote:
> Ingo Molnar wrote:
> >* Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> >
> >>>At a minimum i think we need the fix+comment below.
> >>
> >>Well if we say "this is actually RCU", then yes. And we should 
> >>probably change the preempt_{dis|en}ables in other places to 
> >>rcu_read_lock.
> >>
> >>OTOH, if we say we just want all running threads to process through a 
> >>preemption stage, then this would just be a preempt_disable/enable 
> >>pair.
> >>
> >>In practice that makes no difference yet, but it looks like you and 
> >>Paul are working to distinguish these two cases in the RCU code, to 
> >>accomodate your low latency RCU stuff?
> >
> >
> >it doesnt impact PREEMPT_RCU/PREEMPT_RT directly, because the scheduler 
> >itself always needs to be non-preemptible.
> >
> >those few places where we currently do preempt_disable(), which should 
> >thus be rcu_read_lock(), are never in codepaths that can take alot of 
> >time.
> >
> >but yes, in principle you are right, but in this particular (and 
> >special) case it's not a big issue. We should document the RCU read-lock 
> >dependencies cleanly and make all rcu-read-lock cases truly 
> >rcu_read_lock(), but it's not a pressing issue even considering possible 
> >future features like PREEMPT_RT.
> >
> >the only danger in this area is to PREEMPT_RT: it is a bug on PREEMPT_RT 
> >if kernel code has an implicit 'spinlock means preempt-off and thus 
> >RCU-read-lock' assumption. Most of the time these get discovered via 
> >PREEMPT_DEBUG. (preempt_disable() disables preemption on PREEMPT_RT too, 
> >so that is not a problem either.)
> >
> 
> OK thanks for the good explanation. So I'll keep it as is for now,
> and whatever needs cleaning up later can be worked out as it comes
> up.

Looking forward to the split of synchronize_kernel() into synchronize_rcu()
and synchronize_sched(), the two choices are:

o   Use synchronize_rcu(), but insert rcu_read_lock()/rcu_read_unlock()
pairs on the read side.

o   Use synchronize_sched(), and make sure all read-side code is
under preempt_disable().

Either way, there may also need to be some rcu_dereference()s when picking
up pointer and rcu_assign_pointer()s when updating the pointers.
For example, if traversing the domain parent list is to be RCU protected,
the for_each_domain() macro should change to something like:

#define for_each_domain(cpu, domain) \
for (domain = cpu_rq(cpu)->sd; domain; domain = 
rcu_dereference(domain->parent))

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

Re: [RFC] FUSE permission modell (Was: fuse review bits)

[Daniel Jacobowitz]

On Mon, Apr 11, 2005 at 09:56:29PM +0200, Miklos Szeredi wrote:
> Well the sanity check on the "server" side is always enforced.  You
> can't "trick" sftp or ftp to not check permissions.  So checking on
> the "client" side too (where the fuse daemon is running) makes no
> sense, does it?

That argument doesn't make much sense to me.  But we're at the end of
my useful contributions to this discussion; I'm going to be quiet now
and hope some folks who know more about filesystems have more useful
responses.

-- 
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] ppc32: refactor FPU exception handling

[Kumar Gala]

Andrew,

Moved common FPU exception handling code out of head.S so it can be used 
by several of the sub-architectures that might of a full PowerPC FPU.  

Also, uses new CONFIG_PPC_FPU define to fix alignment exception 
handling for floating point load/store instructions to only occur if we 
have a hardware FPU.

Signed-off-by: Jason McMullan <[EMAIL PROTECTED]>
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>

---

diff -Nru a/arch/ppc/Kconfig b/arch/ppc/Kconfig
--- a/arch/ppc/Kconfig  2005-04-11 17:00:36 -05:00
+++ b/arch/ppc/Kconfig  2005-04-11 17:00:36 -05:00
@@ -53,6 +53,7 @@
 
 config 6xx
bool "6xx/7xx/74xx/52xx/82xx/83xx"
+   select PPC_FPU
help
  There are four types of PowerPC chips supported.  The more common
  types (601, 603, 604, 740, 750, 7400), the Motorola embedded
@@ -85,6 +86,9 @@
bool "e500"
 
 endchoice
+
+config PPC_FPU
+   bool
 
 config BOOKE
bool
diff -Nru a/arch/ppc/Makefile b/arch/ppc/Makefile
--- a/arch/ppc/Makefile 2005-04-11 17:00:36 -05:00
+++ b/arch/ppc/Makefile 2005-04-11 17:00:36 -05:00
@@ -53,6 +53,7 @@
 
 head-$(CONFIG_6xx) += arch/ppc/kernel/idle_6xx.o
 head-$(CONFIG_POWER4)  += arch/ppc/kernel/idle_power4.o
+head-$(CONFIG_PPC_FPU) += arch/ppc/kernel/fpu.o
 
 core-y += arch/ppc/kernel/ arch/ppc/platforms/ \
   arch/ppc/mm/ arch/ppc/lib/ arch/ppc/syslib/
diff -Nru a/arch/ppc/kernel/Makefile b/arch/ppc/kernel/Makefile
--- a/arch/ppc/kernel/Makefile  2005-04-11 17:00:36 -05:00
+++ b/arch/ppc/kernel/Makefile  2005-04-11 17:00:36 -05:00
@@ -9,6 +9,7 @@
 extra-$(CONFIG_8xx):= head_8xx.o
 extra-$(CONFIG_6xx)+= idle_6xx.o
 extra-$(CONFIG_POWER4) += idle_power4.o
+extra-$(CONFIG_PPC_FPU)+= fpu.o
 extra-y+= vmlinux.lds
 
 obj-y  := entry.o traps.o irq.o idle.o time.o misc.o \
diff -Nru a/arch/ppc/kernel/align.c b/arch/ppc/kernel/align.c
--- a/arch/ppc/kernel/align.c   2005-04-11 17:00:36 -05:00
+++ b/arch/ppc/kernel/align.c   2005-04-11 17:00:36 -05:00
@@ -368,16 +368,24 @@
 
/* Single-precision FP load and store require conversions... */
case LD+F+S:
+#ifdef CONFIG_PPC_FPU
preempt_disable();
enable_kernel_fp();
cvt_fd(, , >thread.fpscr);
preempt_enable();
+#else
+   return 0;
+#endif
break;
case ST+F+S:
+#ifdef CONFIG_PPC_FPU
preempt_disable();
enable_kernel_fp();
cvt_df(, , >thread.fpscr);
preempt_enable();
+#else
+   return 0;
+#endif
break;
}
 
diff -Nru a/arch/ppc/kernel/fpu.S b/arch/ppc/kernel/fpu.S
--- /dev/null   Wed Dec 31 16:00:00 196900
+++ b/arch/ppc/kernel/fpu.S 2005-04-11 17:00:36 -05:00
@@ -0,0 +1,190 @@
+/*
+ *  FPU support code, moved here from head.S so that it can be used
+ *  by chips which use other head-whatever.S files.
+ *
+ *  This program is free software; you can redistribute it and/or
+ *  modify it under the terms of the GNU General Public License
+ *  as published by the Free Software Foundation; either version
+ *  2 of the License, or (at your option) any later version.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * This task wants to use the FPU now.
+ * On UP, disable FP for the task which had the FPU previously,
+ * and save its floating-point registers in its thread_struct.
+ * Load up this task's FP registers from its thread_struct,
+ * enable the FPU for the current task and return to the task.
+ */
+   .globl  load_up_fpu
+load_up_fpu:
+   mfmsr   r5
+   ori r5,r5,MSR_FP
+#ifdef CONFIG_PPC64BRIDGE
+   clrldi  r5,r5,1 /* turn off 64-bit mode */
+#endif /* CONFIG_PPC64BRIDGE */
+   SYNC
+   MTMSRD(r5)  /* enable use of fpu now */
+   isync
+/*
+ * For SMP, we don't do lazy FPU switching because it just gets too
+ * horrendously complex, especially when a task switches from one CPU
+ * to another.  Instead we call giveup_fpu in switch_to.
+ */
+#ifndef CONFIG_SMP
+   tophys(r6,0)/* get __pa constant */
+   addis   r3,r6,[EMAIL PROTECTED]
+   lwz r4,[EMAIL PROTECTED](r3)
+   cmpwi   0,r4,0
+   beq 1f
+   add r4,r4,r6
+   addir4,r4,THREAD/* want last_task_used_math->thread */
+   SAVE_32FPRS(0, r4)
+   mffsfr0
+   stfdfr0,THREAD_FPSCR-4(r4)
+   lwz r5,PT_REGS(r4)
+   add r5,r5,r6
+   lwz r4,_MSR-STACK_FRAME_OVERHEAD(r5)
+   li  r10,MSR_FP|MSR_FE0|MSR_FE1
+   andcr4,r4,r10   /* disable FP for previous task */
+   stw r4,_MSR-STACK_FRAME_OVERHEAD(r5)
+1:
+#endif /* CONFIG_SMP */
+   /* 

Re: 2.6.12-rc2-mm3

[Borislav Petkov]

On Monday 11 April 2005 11:43, Andrew Morton wrote:
> (Please do reply-to-all)
>
> "J.A. Magallon" <[EMAIL PROTECTED]> wrote:
> > On 04.11, Andrew Morton wrote:
> >  > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-r
> >  >c2/2.6.12-rc2-mm3/
> >
> >  Is this not needed anymore ?
> >
> >  --- 25/arch/i386/kernel/entry.S~nmi_stack_correct-fix  2005-04-05
> > 00:02:48.0 -0700 +++ 25-akpm/arch/i386/kernel/entry.S   
> > 2005-04-05
> > 00:02:48.0 -0700
>
> Hopefully not. fix-crash-in-entrys-restore_all.patch works around the
> problem. -

Hello Andrew,
I don't know whether you remember the mysterious crashes I was telling you 
about last week and me rookiesh-ly trying to debug them with kgdb over the 
serial console. Well, today I tried for the n-th time again and after rc2-mm3 
blocked again while loading, here's what I did:


[   12.335438] NET: Registered protocol family 17
[   12.362483] Testing NMI watchdog ... OK.
[   12.416195] Starting balanced_irq
[   12.443099] VFS: Mounted root (ext2 filesystem) readonly.
[   12.472490] Freeing unused kernel memory: 196k freed
[   12.521004] logips2pp: Detected unknown logitech mouse model 1
[   12.572581] Warning: unable to open an initial console.
[   12.972518] input: PS/2 Logitech Mouse on isa0060/serio1

Program received signal SIGTRAP, Trace/breakpoint trap.
0xc0102ee7 in resume_kernelX () at atomic.h:175 <--- this one is wrong for a 
mysterious reason
175 {
(gdb) p $eip
$1 = (void *) 0xc0102ee7

(gdb) disas 0xc0102ee7
Dump of assembler code for function resume_kernelX:
0xc0102ee7 :  mov0x30(%esp),%eax
0xc0102eeb :  mov0x38(%esp),%ah
0xc0102eef :  mov0x2c(%esp),%al
0xc0102ef3 : and$0x20403,%eax
0xc0102ef8 : cmp$0x403,%eax
0xc0102efd : je 0xc0102f0c 
End of assembler dump.
(gdb)  

And as we see, we're at the "mov0x30(%esp),%eax" which accesses above the 
bottom of the stack. After applying nmi_stack_correct-fix.patch, rc2-mm3 
booted just fine, so I IMHO think that we might still be needing this, after 
all.

Regards,
Boris.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] usb: kfree() cleanups in drivers/usb/core/devio.c

[Jesper Juhl]

Checking for NULL before calling kfree() is redundant. This patch removes 
these redundant checks and also makes a few tiny whitespace changes.

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

 devio.c |   32 
 1 files changed, 12 insertions(+), 20 deletions(-)

--- linux-2.6.12-rc2-mm3-orig/drivers/usb/core/devio.c  2005-04-11 
21:20:49.0 +0200
+++ linux-2.6.12-rc2-mm3/drivers/usb/core/devio.c   2005-04-11 
23:49:41.0 +0200
@@ -213,12 +213,10 @@ static struct async *alloc_async(unsigne
 
 static void free_async(struct async *as)
 {
-if (as->urb->transfer_buffer)
-kfree(as->urb->transfer_buffer);
-if (as->urb->setup_packet)
-kfree(as->urb->setup_packet);
+   kfree(as->urb->transfer_buffer);
+   kfree(as->urb->setup_packet);
usb_free_urb(as->urb);
-kfree(as);
+   kfree(as);
 }
 
 static inline void async_newpending(struct async *as)
@@ -938,17 +936,13 @@ static int proc_do_submiturb(struct dev_
return -EINVAL;
}
if (!(as = alloc_async(uurb->number_of_packets))) {
-   if (isopkt)
-   kfree(isopkt);
-   if (dr)
-   kfree(dr);
+   kfree(isopkt);
+   kfree(dr);
return -ENOMEM;
}
if (!(as->urb->transfer_buffer = kmalloc(uurb->buffer_length, 
GFP_KERNEL))) {
-   if (isopkt)
-   kfree(isopkt);
-   if (dr)
-   kfree(dr);
+   kfree(isopkt);
+   kfree(dr);
free_async(as);
return -ENOMEM;
}
@@ -967,8 +961,7 @@ static int proc_do_submiturb(struct dev_
as->urb->iso_frame_desc[u].length = isopkt[u].length;
totlen += isopkt[u].length;
}
-   if (isopkt)
-   kfree(isopkt);
+   kfree(isopkt);
as->ps = ps;
 as->userurb = arg;
if (uurb->endpoint & USB_DIR_IN)
@@ -1237,7 +1230,7 @@ static int proc_ioctl (struct dev_state 
return -ENOMEM;
if ((_IOC_DIR(ctrl.ioctl_code) & _IOC_WRITE)) {
if (copy_from_user (buf, ctrl.data, size)) {
-   kfree (buf);
+   kfree(buf);
return -EFAULT;
}
} else {
@@ -1246,8 +1239,7 @@ static int proc_ioctl (struct dev_state 
}
 
if (!connected(ps->dev)) {
-   if (buf)
-   kfree(buf);
+   kfree(buf);
return -ENODEV;
}
 
@@ -1309,8 +1301,8 @@ static int proc_ioctl (struct dev_state 
&& size > 0
&& copy_to_user (ctrl.data, buf, size) != 0)
retval = -EFAULT;
-   if (buf != NULL)
-   kfree (buf);
+
+   kfree(buf);
return retval;
 }
 



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] FUSE permission modell (Was: fuse review bits)

[Jamie Lokier]

Miklos Szeredi wrote:
> That is exactly the intended effect.  If I'm at my work machine (where
> I'm not an admin unfortunately) and I mount my home machine with sshfs
> (because FUSE is installed fortunately :), then I bloody well don't
> want the sysadmin or some automated script of his to go mucking under
> the mountpoint.

I think that would be _much_ nicer implemented as a mount which is
invisible to other users, rather than one which causes the admin's
scripts to spew error messages.  Is the namespace mechanism at all
suitable for that?

It would also be nice to generalise and have virtual filesystems which
are able to present different views to different users.  Can FUSE do
that already - is the userspace part told which user is doing each
operation?  With that, the desire for virtual filesystems which cannot
be read by your sysadmin (by accident) is easy to satisfy - and that
kind of mechanism would probably be acceptable to all.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 encrypted swsusp 1/3] core functionality

[Rafael J. Wysocki]

Hi,

On Monday, 11 of April 2005 23:08, Pavel Machek wrote:
> Hi!
> 
]--snip--[
> > > @@ -130,6 +150,52 @@
> > >  static unsigned short swapfile_used[MAX_SWAPFILES];
> > >  static unsigned short root_swap;
> > >  
> > > +#ifdef CONFIG_SWSUSP_ENCRYPT
> > > +static struct crypto_tfm *crypto_init(int mode)
> > 
> > I think it's better if this function returns an int error code and the
> > messages are printed where it's called from.  This way, the essential
> > part of the code would be easier to grasp (Pavel?).
> 
> Agreed. Actually I do not care where messages are printed, but
> returning different code for different errors seems right.

Hm.  You probably don't want suspend-related messages to be printed during
resume (this function is called in two different places)? :-)

Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: New SCM and commit list

[James Bottomley]

On Mon, 2005-04-11 at 14:26 -0700, Linus Torvalds wrote:
> I don't think kernel.org mirrors the private home directories, so it you
> do _temporary_ trees, just make them readable in your private home
> directory rather than in /pub/linux/kernel/people. For people with 
> kernel.org accounts, we can use that as the "bkbits.net" thing.

It's also going to be a slight problem for those of us who don't have a
kernel.org account...although I think the hosting I use on the parisc
website might actually be outside the HP firewall, so I can probably beg
for it to run any protocol you need (like rsync).

James


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

Re: [PATCH] zero disk pages used by swsusp on resume

[Rafael J. Wysocki]

Hi,

On Monday, 11 of April 2005 19:02, Andreas Steinmetz wrote:
> Rafael J. Wysocki wrote:
> > Hi,
> > 
> > On Monday, 11 of April 2005 12:37, Oliver Neukum wrote:
> > 
> >>Am Sonntag, 10. April 2005 22:14 schrieb Pavel Machek:
> >>
> >>>Hi!
> >>>
> >>>
> >Oliver Neukum wrote:
> >
> >>What is the point in doing so after they've rested on the disk for ages?
> >
> >The point is not physical access to the disk but data gathering after
> >resume or reboot.
> 
> After resume or reboot normal access control mechanisms will work
> again. Those who can read a swap partition under normal circumstances
> can also read /dev/kmem. It seems to me like you are putting an extra
> lock on a window on the third floor while leaving the front door open.
> >>>
> >>>Andreas is right, his patches are needed.
> >>>
> >>>Currently, if your laptop is stolen after resume, they can still data
> >>>in swsusp image.
> >>>
> >>>Zeroing the swsusp pages helps a lot here, because at least they are
> >>>not getting swsusp image data without heavy tools. [Or think root
> >>>compromise month after you used swsusp.]
> >>>
> >>>Encrypting swsusp image is of course even better, because you don't
> >>>have to write large ammounts of zeros to your disks during resume ;-).
> >>
> >>Not only is it better, it completely supercedes wiping the image.
> >>Your laptop being stolen after resume is very much a corner case.
> >>You suspend your laptop while you are not around, don't you?
> > 
> > 
> > Not necessarily.  Some people use suspend instead of shutdown. :-)
> 
> Now here's what I'm currently doing:
> 
> I do usually suspend instead of shutdown. The suspend partition is the
> only unencrypted swap partition and it is disabled during regular
> operation so it is not used for regular swapping. Except for a small
> boot partition without any valuable data all other partitions are encrypted.
> 
> The key for dm-crypt setup is stored on an ide flash disk which isn't
> inserted during travelling and which is transported separately.
> 
> Now let's imagine the laptop gets stolen by an average thief which is
> the most common case.Thief needs to know if the laptop is working
> because thief wants to sell it so thief powers on the laptop.
> 
> swsusp resumes and with the encryption patch renders the suspend image
> worthless. The suspend/resume script immediately checks for the presence
> of the ide flash disk with the correct key (match is done against the
> in-kernel dm-crypt key). If the ide flash disk is not present or if
> there is a key mismatch the script shuts the system immediately down, so
> the in-kernel key is lost.
> 
> The only way for the thief now to access any data on the disk is to come
> back and steal the flash disk, too.

Yes.  And if you accidentally lose the flash disk, you are locked out of your
own data. ;-)  The same happens if the data on the flash disk is lost (which
occurs, from time to time).  You should be _really_ careful doing such things
and IMO it's not to be tried by Joe User.

OTOH, the encryption of the system image during suspend is generally
a very good idea.  IMO we should also check the integrity of the image
at that time, which would require computing some checksums on suspend.

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: New SCM and commit list

[Linus Torvalds]

On Mon, 11 Apr 2005, Greg KH wrote:
> 
> I have a feeling that the kernel.org mirror system is just going to
> _love_ us using it to store temporary git trees :)

I don't think kernel.org mirrors the private home directories, so it you
do _temporary_ trees, just make them readable in your private home
directory rather than in /pub/linux/kernel/people. For people with 
kernel.org accounts, we can use that as the "bkbits.net" thing.

For really public hosting, we need to find some other approach. 

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: [RFC][PATCH] Simple privacy enhancement for /proc/

[Rene Scharfe]

Bodo Eggert schrieb:
> On Sun, 10 Apr 2005, Rene Scharfe wrote:
> 
> 
>>First, configuring via kernel parameters is sufficient.
> 
> 
> I don't remember: Would a mount option be equally easy to implement?
> (Kernel parameters are OK for me, too.)

A mount option for procfs would be changable at remount, making
implementation a bit more involved.

>>I have another idea: let's keep the details of _every_ process owned by
>>user root readable by anyone.
> 
> 
> What about SUID processes acting on behalf of users?

SUID root processes will we visible for all, too.  That's fair enough, I
think.  If it's a concern to you use proc.privacy=2.

>>- processor.max_cstate=   [HW, ACPI]
>>- Limit processor to maximum C-state
>>- max_cstate=9 overrides any DMI blacklist limit.
>>-
> 
> 
> This seems to belong into another patch

Strictly speaking, yes, but it's just a trivial cleanup near my own
change.  And I guarantee it has zero impact on any built kernel image. :]

> (in pid_revalidate:)
> What about moving the things around? (just editing in the MUA)
> 
> 
>>+ if (IS_PID_DIR(proc_type(inode)) || task_dumpable(task)) {
>>  inode->i_uid = task->euid;
>>+ inode->i_gid = proc_gid;
>>+ if (!proc_privacy || IS_PID_DIR(proc_type(inode)))
>>  inode->i_gid = task->egid;
>>  } else {
>>  inode->i_uid = 0;
>>  inode->i_gid = 0;
>>  }
>>  security_task_to_inode(task, inode);
>>  return 1;
>>  }

I suppose you could do that, but I don't see any gain.  I also find my
version easier to read because it keeps the two conditionals (having
different intents and purposes) apart.

> BTW: You might be able to cache IS_PID_DIR(). It looks like being a gain.

I'd rather let the compiler do that job.  It's only a small macro, I
really doubt you would measure any speedup from putting it into a local
variable.

>>@@ -1454,6 +1468,11 @@ static struct dentry *proc_pident_lookup
> 
> 
>>+ if (proc_privacy == 2 || task->euid != 0)
> 
>^
> redundand.

You're right and it's a matter of taste, I guess.  By the way, this is
also what the FreeBSD crowd calls a "bikeshed". :-)

Thanks for reviewing my patch!
Rene
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Mon, Apr 11, 2005 at 10:54:50PM +0200, Marco Colombo wrote:
> In this case, A is clearly the author (onwer of rights) of the firmware.
> D is fine on respect of the other A's, since their source is actually 
> (and clearly) there. It's the missing source case we're considering
> and the number of A's is quite small, the copyright owners of firmware
> images. Those A's are easily identified, and perfectly able to act.

Well, i am not sure with your interpretation, but even if you where right, we
have no guarantee that A will continue being lenient, and no guarantee that A
will not start suing D or whoever for illegally distributing his stuff without
sources.

> > > So, even if C comes to think D is breaking GPL, all C can do is notify
> > > A. The GPL D is supposedly breaking is an agreement between A and D
> > > only. On which basis may C sue D? For breaking what agreement? It's up
> > > to A to sue D for breaking GPL.
> > 
> > This is indeed an interpretation. I am not sure myself if a user receiving
> > GPLed software in binary only fashion as is the case here can sue either D 
> > or
> > A to get access to that source code.
> 
> The point is, if A states (even implicitly) D is distributing the right
> source, there's nothing C can do to D. D is not breaking GPL, as long A

So, i get some random bit of GPLed software, i add a module or some code to
it, i distribute that code in binary format only, and claim that i have used
an hex editor to write it, or simply that it is the 'right' source.

I have some serious doubts that i will not get sued by all the authors of the
original GPLed work if i were to do that, and rightly so.

> says so and it's A granting D the right to distribute. There's no way C
> can prevent D from distributing A's software, if A is fine with it.
> It's up to A to decide if GPL conditions are met by D.

Even in that case, you still need explicit permission of A, and all the other
copyright holders of the rest of the GPLed work, to give you an explicit
exception to link with this non-free bit of code.

> Maybe mine it's only one interpretation. But I can't see any other.
> 
> > Now you could argue that any number of authors of GPLed bits of the linux
> > kernel could sue D for distributing their software as a derived work of the
> > binary-only bit, and the fact that D doesn't distribute the source code to 
> > the
> > binary bit voids any other right allowed him by the GPL, and thus he has no
> > right to do the distribution at all. The GPL is very clear on this topic.
> 
> We're not talking of that case. D _is_ actually distributing the right
> source, according to A. It's C that is unsatisfied with it.

No. The source code is clearly the prefered form of modification, not some
random intermediate state A may be claiming is source.

> > > What is the risk for D, if D is distributing the source of the software
> > > _exactly_ in the form A publicly provides it? It's not up to D to
> > > produce the source, all D has to do is to provide verbatim copies of
> > > it to anyone D distributes the software to, on request.
> > 
> > Imagine one of those companies got bought up by some predatory company who
> > wishes us (linux, debian, redhat/suse, whoever) harm. They would then be 
> > able
> > to sue for damage or prejudice or whatever. And given what i have heard 
> > about
> > the uncertainities of the Alteon ownership, this seems indeed like a 
> > plausible
> > scenario, which could result in a SCO bis case.
> 
> I'm not following. Are you saying what if A is bought? That is
> different. Well GPL is quite clear:
> 
> 1. You may copy and distribute verbatim copies of the Program's source
> code as you receive it, ...
> 
> If D is distributing the source as received from A, D is in full
> compliance. How could A sue D? If A distributed incomplete source
> in the first place, it's not D's fault for sure. Do you really think
> the following scenario is likely:
> 
> A to D: you must distribute the complete source, or the license will be
> terminated!
> D to A: gimme the complete source, and I'll distribute it.
> A to D: no, I'm not willing to give you the full source of my firmware,
> but you must distribute it anyway!

The result is that the code in question has to be stopped from being
distributed by D. But the case here is different, since A is not the sole
copyright owner, so he doesn't get to set random interpretations of what is
source code. 

> That, in court? Is this really what you're afraid of?
> The outcome is, very likely A will be forced to release the full source.
> (and D forced to distribute it, but all D's we're talking of here are
> very happy with the full disclosure scenario, aren't they?)

Imagine A refusing to give away the source code, and D is ordered to remove
the incriminated code it is illegally distributing from all its servers, and
recall all those thousands of CD and DVD isos containing the code it
distributed, and being fined for each day it 

[PATCH] net: remove redundant NULL pointer checks prior to kfree in drivers/net/slip.c

[Jesper Juhl]

kfree() checks for NULL. Checking prior to calling it is redundant.
This patch removes these redundant checks from drivers/net/slip.c

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

 slip.c |   30 --
 1 files changed, 12 insertions(+), 18 deletions(-)

--- linux-2.6.12-rc2-mm3-orig/drivers/net/slip.c2005-03-02 
08:38:33.0 +0100
+++ linux-2.6.12-rc2-mm3/drivers/net/slip.c 2005-04-11 23:10:06.0 
+0200
@@ -185,15 +185,12 @@ sl_alloc_bufs(struct slip *sl, int mtu)
/* Cleanup */
 err_exit:
 #ifdef SL_INCLUDE_CSLIP
-   if (cbuff)
-   kfree(cbuff);
+   kfree(cbuff);
if (slcomp)
slhc_free(slcomp);
 #endif
-   if (xbuff)
-   kfree(xbuff);
-   if (rbuff)
-   kfree(rbuff);
+   kfree(xbuff);
+   kfree(rbuff);
return err;
 }
 
@@ -204,13 +201,13 @@ sl_free_bufs(struct slip *sl)
void * tmp;
 
/* Free all SLIP frame buffers. */
-   if ((tmp = xchg(>rbuff, NULL)) != NULL)
-   kfree(tmp);
-   if ((tmp = xchg(>xbuff, NULL)) != NULL)
-   kfree(tmp);
+   tmp = xchg(>rbuff, NULL);
+   kfree(tmp);
+   tmp = xchg(>xbuff, NULL);
+   kfree(tmp);
 #ifdef SL_INCLUDE_CSLIP
-   if ((tmp = xchg(>cbuff, NULL)) != NULL)
-   kfree(tmp);
+   tmp = xchg(>cbuff, NULL);
+   kfree(tmp);
if ((tmp = xchg(>slcomp, NULL)) != NULL)
slhc_free(tmp);
 #endif
@@ -297,13 +294,10 @@ done_on_bh:
spin_unlock_bh(>lock);
 
 done:
-   if (xbuff)
-   kfree(xbuff);
-   if (rbuff)
-   kfree(rbuff);
+   kfree(xbuff);
+   kfree(rbuff);
 #ifdef SL_INCLUDE_CSLIP
-   if (cbuff)
-   kfree(cbuff);
+   kfree(cbuff);
 #endif
return err;
 }


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] I2C rtc8564.c remove duplicate include (whitespace fixed)

[Jean Delvare]

Hi Clemens,

> [PATCH] I2C rtc8564.c remove duplicate include
> 
> Trivial fix: removes duplicate include line.
> Patch applies to: 2.6.11.x
> 
> (This is my very first patch to the linux-kernel, so let me
> start with small things first...)
> 
> Signed-off-by: Clemens Koller <[EMAIL PROTECTED]>

Thanks for the patch, I added it to my stack. Greg, please pick it for
your i2c tree.

-- 
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 encrypted swsusp 1/3] core functionality

[Pavel Machek]

Hi!

> I had no time to review your patch earlier, sorry.  I'm inlining it so that I 
> can
> comment it:

> > @@ -72,6 +75,16 @@
> >  
> >  #include "power.h"
> >  
> > +#ifdef CONFIG_SWSUSP_ENCRYPT
> > +#include 
> > +#include 
> > +#include 
> > +#endif
> > +
> > +#define CIPHER "aes"
> > +#define MAXKEY 32
> > +#define MAXIV  32
> 
> Why not to put these definitions under #ifdef?
> 
> > +
> >  /* References to section boundaries */
> >  extern const void __nosave_begin, __nosave_end;
> >  
> > @@ -104,7 +117,9 @@
> >  #define SWSUSP_SIG "S1SUSPEND"
> >  
> >  static struct swsusp_header {
> > -   char reserved[PAGE_SIZE - 20 - sizeof(swp_entry_t)];
> 
> I would add #ifdef here as well.

I think avoiding both ifdefs is actually right thing to do. Keep the
ifdef noise down.

> > +   char reserved[PAGE_SIZE - 20 - MAXKEY - MAXIV - sizeof(swp_entry_t)];
> > +   u8 key[MAXKEY];
> > +   u8 iv[MAXIV];
> > swp_entry_t swsusp_info;
> > charorig_sig[10];
> > charsig[10];
> > @@ -112,6 +127,11 @@
> >  
> >  static struct swsusp_info swsusp_info;
> >  
> > +#ifdef CONFIG_SWSUSP_ENCRYPT
> > +static u8 key[MAXKEY];
> > +static u8 iv[MAXIV];
> > +#endif
> > +
> >  /*
> >   * XXX: We try to keep some more pages free so that I/O operations succeed
> >   * without paging. Might this be more?
> > @@ -130,6 +150,52 @@
> >  static unsigned short swapfile_used[MAX_SWAPFILES];
> >  static unsigned short root_swap;
> >  
> > +#ifdef CONFIG_SWSUSP_ENCRYPT
> > +static struct crypto_tfm *crypto_init(int mode)
> 
> I think it's better if this function returns an int error code and the
> messages are printed where it's called from.  This way, the essential
> part of the code would be easier to grasp (Pavel?).

Agreed. Actually I do not care where messages are printed, but
returning different code for different errors seems right.

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

2.6.12-rc2-mm3: CONFIG_MODULES=n MTD compile error

[Adrian Bunk]

On Mon, Apr 11, 2005 at 01:25:32AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.12-rc2-mm2:
>...
> +remove-inter-module-mtd.patch
> 
>  Remove intermodule_foo() usage from mtd.
>...

This breaks the compilation with CONFIG_MODULES=n:

<--  snip  -->

...
  CC  drivers/mtd/devices/docprobe.o
drivers/mtd/devices/docprobe.c: In function `DoC_Probe':
drivers/mtd/devices/docprobe.c:311: warning: implicit declaration of 
function `__symbol_get'
drivers/mtd/devices/docprobe.c:311: warning: assignment makes pointer 
from integer without a cast
drivers/mtd/devices/docprobe.c:315: warning: implicit declaration of function 
`__symbol_put'
...
  LD  .tmp_vmlinux1
drivers/built-in.o(.init.text+0x60f20): In function `DoC_Probe':
: undefined reference to `__symbol_get'
drivers/built-in.o(.init.text+0x60f3b): In function `DoC_Probe':
: undefined reference to `__symbol_put'
drivers/built-in.o(.init.text+0x610a4): In function `DoC_Probe':
: undefined reference to `__symbol_get'
make: *** [.tmp_vmlinux1] Error 1

<--  snip  -->


cu
Adrian

-- 

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

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

Re: New SCM and commit list

[Greg KH]

On Sun, Apr 10, 2005 at 10:25:22PM -0500, James Bottomley wrote:
> On Sun, 2005-04-10 at 16:26 -0700, Linus Torvalds wrote:
> > On Mon, 11 Apr 2005, Benjamin Herrenschmidt wrote:
> > > If yes, then I would appreciate if you could either keep the same list,
> > > or if you want to change the list name, keep the subscriber list so
> > > those of us who actually archive it don't miss anything ;)
> > 
> > I didn't even set up the list. I think it's Bottomley. I'm cc'ing him just 
> > so that he sees the message, but I don't actually expect him to do 
> > anything about it. I'm not even ready to start _testing_ real merges yet. 
> > But I hope that I can get non-conflicting merges done fairly soon, and 
> > maybe I can con James or Jeff or somebody to try out GIT then...
> 
> Not guilty.  If I remember correctly, the list was set up by the vger
> list maintainers (davem and company).  It was tied to a trigger in one
> of your trees (which I think Larry did).  It shouldn't be too difficult
> to add to git ... it just means traversing all the added patches on a
> merge and sending out mail.
> 
> I can try out your source control tools ... I have some rc fixes
> ready ... when you're ready to try out merges...

I have some rc fixes too, let us know when you are ready to accept them,
and what format you want them in.

I have a feeling that the kernel.org mirror system is just going to
_love_ us using it to store temporary git trees :)

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/