[Linux-ia64] quick ia64 patch for 2.5.44 (UP only)

[Linux-ia64] quick ia64 patch for 2.5.44 (UP only)

[David Mosberger]

A quick patch that gets 2.5.44 (mostly) working on ia64 is now at
ftp.kernel.org/pub/linux/kernel/ports/ia64/v2.5/ in file:

	linux-2.5.44-ia64-021024.diff.gz

With this patch, the kernel should work on Itanium 1, Itanium 2, and
the Ski simulator, PROVIDED you use the "nosmp" option with SMP
kernels.  Without "nosmp", the kernel crashes when starting up the
application processors.  It appears that the crash is caused by
something calling a NULL function pointer.

Kernel profiling is currently disabled (I haven't sorted out yet what
should be done with respect to the new profiling infrastructure).

Another caveat is that Itanium 1 machines need to have reasonably
recent firmware with correct ACPI information.  For Big Sur (e.g.,
i2000 machines), firmware 117C seems to be good enough (this firmware
is available from hp's workstation support web site, for example).
I'm not exactly sure what the earliest firmware version is that will
work properly.  But if you're encoutering interrupt routine problems,
the culprit is probably bad firmware.

I apologize for releasing such an incomplete patch, but I'm in the
middle of a family emergency which is keeping me from working
full-time.  I expect things to be back to normal sometime later next
week.  In the meantime, I appreciate (as always) all help to improve
the ia64 kernel.

Thanks,

	--david

Re: [Linux-ia64] quick ia64 patch for 2.5.44 (UP only)

[Kimio Suganuma]

Hi,

On Thu, 24 Oct 2002 22:35:37 -0700
David Mosberger <davidm@napali.hpl.hp.com> wrote:

> A quick patch that gets 2.5.44 (mostly) working on ia64 is now at
> ftp.kernel.org/pub/linux/kernel/ports/ia64/v2.5/ in file:
> 
> 	linux-2.5.44-ia64-021024.diff.gz
> 
> With this patch, the kernel should work on Itanium 1, Itanium 2, and
> the Ski simulator, PROVIDED you use the "nosmp" option with SMP
> kernels.  Without "nosmp", the kernel crashes when starting up the
> application processors.  It appears that the crash is caused by
> something calling a NULL function pointer.

I found that tasklet_hi_action() seemed to call NULL pointer.
So I tried to put following code (I guess this is wrong fix)
into the function;

	if (t->func = NULL) {
		tasklet_unlock(t);
		continue;
	}

And the system initialization moved on, but it hung at INIT execution.
Anyway, I feel this problem might be related to the timer change.

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

Thanks,
Kimi

-- 
Kimio Suganuma <k-suganuma@mvj.biglobe.ne.jp>

Re: [Linux-ia64] quick ia64 patch for 2.5.44 (UP only)

[Kimio Suganuma]

Hi,

I found that functions in timer.c and rcupdate.c are calling
tasklet_init() for all CPUs before APs start running.
I think per_cpu() cannot be used for not running CPU for ia64,
and this assumption was broken by them.

I attached args for tasklet_init() at booting and you can see
tasklet structures for CPU#0 are only valid.
Caller might be init_timers() and rcu_init().

I cannot come up with good solution for it but I think
we have to change current per_cpu implementation.
Any idea?

Thanks,
Kimi

enter tasklet_init tà00000100000180, funcà00000004a2e340
enter tasklet_init t 00000000008180, funcà00000004a2e340
enter tasklet_init t 00000000008180, funcà00000004a2e340
enter tasklet_init t 00000000008180, funcà00000004a2e340
enter tasklet_init t 00000000008180, funcà00000004a2e340
enter tasklet_init t 00000000008180, funcà00000004a2e340
enter tasklet_init t 00000000008180, funcà00000004a2e340
enter tasklet_init t 00000000008180, funcà00000004a2e340
enter tasklet_init t 00000000008180, funcà00000004a2e340
enter tasklet_init t 00000000008180, funcà00000004a2e340
enter tasklet_init t 00000000008180, funcà00000004a2e340
enter tasklet_init t 00000000008180, funcà00000004a2e340
enter tasklet_init t 00000000008180, funcà00000004a2e340
enter tasklet_init t 00000000008180, funcà00000004a2e340
enter tasklet_init t 00000000008180, funcà00000004a2e340
enter tasklet_init t 00000000008180, funcà00000004a2e340
enter tasklet_init tà00000100000158, funcà00000004a2c100
enter tasklet_init t 00000000008158, funcà00000004a2c100
enter tasklet_init t 00000000008158, funcà00000004a2c100
enter tasklet_init t 00000000008158, funcà00000004a2c100
enter tasklet_init t 00000000008158, funcà00000004a2c100
enter tasklet_init t 00000000008158, funcà00000004a2c100
enter tasklet_init t 00000000008158, funcà00000004a2c100
enter tasklet_init t 00000000008158, funcà00000004a2c100
enter tasklet_init t 00000000008158, funcà00000004a2c100
enter tasklet_init t 00000000008158, funcà00000004a2c100
enter tasklet_init t 00000000008158, funcà00000004a2c100
enter tasklet_init t 00000000008158, funcà00000004a2c100
enter tasklet_init t 00000000008158, funcà00000004a2c100
enter tasklet_init t 00000000008158, funcà00000004a2c100
enter tasklet_init t 00000000008158, funcà00000004a2c100
enter tasklet_init t 00000000008158, funcà00000004a2c100


On Fri, 25 Oct 2002 14:50:33 -0700
Kimio Suganuma <k-suganuma@mvj.biglobe.ne.jp> wrote:

> I found that tasklet_hi_action() seemed to call NULL pointer.
> So I tried to put following code (I guess this is wrong fix)
> into the function;
> 
> 	if (t->func = NULL) {
> 		tasklet_unlock(t);
> 		continue;
> 	}
> 
> And the system initialization moved on, but it hung at INIT execution.
> Anyway, I feel this problem might be related to the timer change.
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m\x103393743102152&w=2

-- 
Kimio Suganuma <k-suganuma@mvj.biglobe.ne.jp>

Re: [Linux-ia64] quick ia64 patch for 2.5.44 (UP only)

[Kimio Suganuma]

Hi,

I succeeded to boot the kernel on 8way ia64 box by
porting the generic percpu (i.e. i386's percpu) to ia64.
I think this should not right way to fix the problem.
I can show the patch if there is a requirement.

Thanks,
Kimi

On Fri, 25 Oct 2002 16:23:43 -0700
Kimio Suganuma <k-suganuma@mvj.biglobe.ne.jp> wrote:

> I found that functions in timer.c and rcupdate.c are calling
> tasklet_init() for all CPUs before APs start running.
> I think per_cpu() cannot be used for not running CPU for ia64,
> and this assumption was broken by them.
> 
> I attached args for tasklet_init() at booting and you can see
> tasklet structures for CPU#0 are only valid.
> Caller might be init_timers() and rcu_init().
> 
> I cannot come up with good solution for it but I think
> we have to change current per_cpu implementation.
> Any idea?

-- 
Kimio Suganuma <k-suganuma@mvj.biglobe.ne.jp>

Re: [Linux-ia64] quick ia64 patch for 2.5.44 (UP only)

[Kimio Suganuma]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

Hi Erich,

Here is the patch.
I changed cpu_init() in setup.c so that BSP prepares
per_cpu data for all CPUS.

Regards,
Kimi

On Sun, 27 Oct 2002 18:13:31 +0100
Erich Focht <efocht@ess.nec.de> wrote:

> Hi Kimi,
> 
> On Saturday 26 October 2002 03:09, Kimio Suganuma wrote:
> > I succeeded to boot the kernel on 8way ia64 box by
> > porting the generic percpu (i.e. i386's percpu) to ia64.
> > I think this should not right way to fix the problem.
> > I can show the patch if there is a requirement.
> 
> yes, please send the patch. I'd like to test something on 2.5.44
> on Azusa on Monday.

-- 
Kimio Suganuma <k-suganuma@mvj.biglobe.ne.jp>

[-- Attachment #2: smp_fix-2.5.44.patch --]
[-- Type: application/octet-stream, Size: 3822 bytes --]

diff -Nur linux-2.5.44/arch/ia64/kernel/setup.c linux-2.5.44-new/arch/ia64/kernel/setup.c
--- linux-2.5.44/arch/ia64/kernel/setup.c	Fri Oct 25 18:22:51 2002
+++ linux-2.5.44-new/arch/ia64/kernel/setup.c	Fri Oct 25 19:17:49 2002
@@ -618,53 +618,40 @@
 	unsigned long num_phys_stacked;
 	pal_vm_info_2_u_t vmi;
 	unsigned int max_ctx;
-	struct cpuinfo_ia64 *my_cpu_info;
-	void *my_cpu_data;
+	struct cpuinfo_ia64 *cpu_info;
+	void *cpu_data;
 
 #ifdef CONFIG_SMP
 	extern char __per_cpu_end[];
-	int cpu = smp_processor_id();
+	int cpu;
 
 	if (__per_cpu_end - __per_cpu_start > PAGE_SIZE)
 		panic("Per-cpu data area too big! (%Zu > %Zu)",
 		      __per_cpu_end - __per_cpu_start, PAGE_SIZE);
 
-# ifdef CONFIG_NUMA
-	{
-		static unsigned long boot_cpu_data;
-
-		/*
-		 * get_free_pages() cannot be used before cpu_init() done.  BSP allocates
-		 * "NR_CPUS" pages for all CPUs to avoid that AP calls get_zeroed_page().
-		 */
-		if (cpu == 0)
-			boot_cpu_data = (unsigned long)alloc_bootmem_pages(PAGE_SIZE * NR_CPUS);
-		my_cpu_data = (void *)(boot_cpu_data + (cpu * PAGE_SIZE));
-
-		memcpy(my_cpu_data, __phys_per_cpu_start, __per_cpu_end - __per_cpu_start);
-		__per_cpu_offset[cpu] = (char *) my_cpu_data - __per_cpu_start;
-		my_cpu_info = my_cpu_data + ((char *) &__get_cpu_var(cpu_info) - __per_cpu_start);
 
-		my_cpu_info->node_data = get_node_data_ptr();
-		my_cpu_info->nodeid = boot_get_local_nodeid();
-	}
-# else /* !CONFIG_NUMA */
 	/*
-	 * On the BSP, the page allocator isn't initialized by the time we get here.  On
-	 * the APs, the bootmem allocator is no longer available...
+	 * get_free_pages() cannot be used before cpu_init() done.  BSP allocates
+	 * "NR_CPUS" pages for all CPUs to avoid that AP calls get_zeroed_page().
 	 */
-	if (cpu == 0)
-		my_cpu_data = alloc_bootmem_pages(__per_cpu_end - __per_cpu_start);
-	else
-		my_cpu_data = (void *) get_zeroed_page(GFP_KERNEL);
-	memcpy(my_cpu_data, __phys_per_cpu_start, __per_cpu_end - __per_cpu_start);
-	__per_cpu_offset[cpu] = (char *) my_cpu_data - __per_cpu_start;
-	my_cpu_info = my_cpu_data + ((char *) &__get_cpu_var(cpu_info) - __per_cpu_start);
-# endif /* !CONFIG_NUMA */
+	if (smp_processor_id() == 0) {
+		cpu_data = (unsigned long)alloc_bootmem_pages(PAGE_SIZE * NR_CPUS);
+		for (cpu = 0; cpu < NR_CPUS; cpu++) {
+			memcpy(cpu_data, __phys_per_cpu_start, __per_cpu_end - __per_cpu_start);
+			__per_cpu_offset[cpu] = (char *) cpu_data - __per_cpu_start;
+			cpu_data += PAGE_SIZE;
+		}
+	}
+	cpu_data = __per_cpu_start + __per_cpu_offset[smp_processor_id()];
 #else /* !CONFIG_SMP */
-	my_cpu_data = __phys_per_cpu_start;
+	cpu_data = __phys_per_cpu_start;
 #endif /* !CONFIG_SMP */
-	my_cpu_info = my_cpu_data + ((char *) &__get_cpu_var(cpu_info) - __per_cpu_start);
+
+	cpu_info = cpu_data + ((char *) &__get_cpu_var(cpu_info) - __per_cpu_start);
+#ifdef CONFIG_NUMA
+	cpu_info->node_data = get_node_data_ptr();
+	cpu_info->nodeid = boot_get_local_nodeid();
+#endif
 
 	/*
 	 * We can't pass "local_cpu_data" to identify_cpu() because we haven't called
@@ -672,14 +659,14 @@
 	 * depends on the data returned by identify_cpu().  We break the dependency by
 	 * accessing cpu_data() the old way, through identity mapped space.
 	 */
-	identify_cpu(my_cpu_info);
+	identify_cpu(cpu_info);
 
 #ifdef CONFIG_MCKINLEY
 	{
 #		define FEATURE_SET 16
 		struct ia64_pal_retval iprv;
 
-		if (my_cpu_info->family == 0x1f) {
+		if (cpu_info->family == 0x1f) {
 			PAL_CALL_PHYS(iprv, PAL_PROC_GET_FEATURES, 0, FEATURE_SET, 0);
 			if ((iprv.status == 0) && (iprv.v0 & 0x80) && (iprv.v2 & 0x80))
 				PAL_CALL_PHYS(iprv, PAL_PROC_SET_FEATURES,
@@ -710,7 +697,7 @@
 	if (current->mm)
 		BUG();
 
-	ia64_mmu_init(my_cpu_data);
+	ia64_mmu_init(cpu_data);
 
 #ifdef CONFIG_IA32_SUPPORT
 	/* initialize global ia32 state - CR0 and CR4 */

Re: [Linux-ia64] quick ia64 patch for 2.5.44 (UP only)

[Erich Focht]

Hi Kimi,

On Saturday 26 October 2002 03:09, Kimio Suganuma wrote:
> I succeeded to boot the kernel on 8way ia64 box by
> porting the generic percpu (i.e. i386's percpu) to ia64.
> I think this should not right way to fix the problem.
> I can show the patch if there is a requirement.

yes, please send the patch. I'd like to test something on 2.5.44
on Azusa on Monday.

Regards,
Erich

Re: [Linux-ia64] quick ia64 patch for 2.5.44 (UP only)

[Peter Chubb]

>>>>> "Kimio" = Kimio Suganuma <k-suganuma@mvj.biglobe.ne.jp> writes:

Kimio> Hi Erich,
Kimio> Here is the patch.
Kimio> I changed cpu_init() in setup.c so that BSP prepares
Kimio> per_cpu data for all CPUS.

After applying this patch, I can boot on SMP.  However, the machine
hangs on shutdown

...
Deconfiguring network interfaces... done.
Deactivating swap... done.
Unmounting local filesystems... done.
Rebooting... Shutting down devices

so there's still something wrong, not sure what (as interrupts are
disabled, I can't use the magic sysrq key to find out what's
happening)

Peter C

Re: [Linux-ia64] quick ia64 patch for 2.5.44 (UP only)

[Kimio Suganuma]

Hi,

On Mon, 28 Oct 2002 10:57:17 +1100
Peter Chubb <peter@chubb.wattle.id.au> wrote:

> >>>>> "Kimio" = Kimio Suganuma <k-suganuma@mvj.biglobe.ne.jp> writes:
> 
> Kimio> Hi Erich,
> Kimio> Here is the patch.
> Kimio> I changed cpu_init() in setup.c so that BSP prepares
> Kimio> per_cpu data for all CPUS.
> 
> After applying this patch, I can boot on SMP.  However, the machine
> hangs on shutdown
> 
> ...
> Deconfiguring network interfaces... done.
> Deactivating swap... done.
> Unmounting local filesystems... done.
> Rebooting... Shutting down devices

I have a same problem on Bigsur since 2.5.39.
So the problem caused by another bug.

I've heard a rumor that this patch might fix it, but I haven't
test it, yet.

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

> so there's still something wrong, not sure what (as interrupts are
> disabled, I can't use the magic sysrq key to find out what's
> happening)

Keyboard cannot be used on my Bigsur since 2.5.3? also.
I've heard that there was a same problem at early 2.4.

Thanks,
Kimi

-- 
Kimio Suganuma <k-suganuma@mvj.biglobe.ne.jp>

Re: [Linux-ia64] quick ia64 patch for 2.5.44 (UP only)

[Peter Chubb]

>>>>> "Kimio" = Kimio Suganuma <k-suganuma@mvj.biglobe.ne.jp> writes:


Kimio> I have a same problem on Bigsur since 2.5.39.
Kimio> So the problem caused by another bug.

 Yes, I agree there's another problem here.

Kimio> I've heard a rumor that this patch might fix it, but I haven't
Kimio> test it, yet.

Kimio> http://marc.theaimsgroup.com/?l=linux-kernel&m\x103371059120183&w=2

This patch is for the sound driver, that I haven't compiled in.  So
it's unlikely to fix my problem.  Although maybe there's a similar
problem somewhere else?

I did *not* have the problem on 2.5.39 or on 2.5.44 UP (it appears to
be an SMP problem that was introduced between 2.5.39 and 2.5.44).
I'm using serial console only.

Peter C

Re: [Linux-ia64] quick ia64 patch for 2.5.44 (UP only)

[David Mosberger]

I updated the 2.5.44 ia64 patch with the SMP (per-CPU) fix by Kimi.
Various other minor fixes are there as well.  The patch file is called

	linux-2.5.44-ia64-021027.gz

in the usual place...

Thanks,

	--david

PS: I only tested Big Sur SMP and 1 out of 3 times it hung on me when
    switching to runlevel 3.

PPS: It looks like I'll be able to work Mon & Tue.  Wednesday I'll be
     out and it's unclear how quickly I'll be back afterwards (but I
     will be reading email so keep the patches coming...).

RE: [Linux-ia64] quick ia64 patch for 2.5.44 (UP only)

[Luck, Tony]

> Keyboard cannot be used on my Bigsur since 2.5.3? also.
> I've heard that there was a same problem at early 2.4.

I don't know if it was the the same problem, but the symptoms
and the workaround are the same.  Through most of the mid-teens
2.4 kernel would come up on BigSur with the keyboard non-functional.
Unplugging the keyboard, and replugging it would fix it. I
forget the release when this stopped happening, but 2.4.18 and
2.4.19 definitely don't have this problem.

2.5.39 is doing the same thing (but now I have a Belkin KVM switch
in between the keyboard and the machine, just selecting a different
machine, and then selecting back to the BigSur corrects the problem).

-Tony