quick ia64 patch for 2.5.44 (UP only)

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

Hi,

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&m3393743102152&w=2

Thanks,
Kimi

Kimio Suganuma <[email protected]>

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

Kimio Suganuma <[email protected]>

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

Kimio Suganuma <[email protected]>

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

Kimio Suganuma <[email protected]>

diff -Nur linux-2.5.44/arch/ia64/kernel/setup.c linux-2.5.44-new/arch/ia64/kernel/setup.c
@@ -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 */

Hi Kimi,

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

Regards,
Erich

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

Hi,

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&m3371059120183&w=2

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 <[email protected]>

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&m3371059120183&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

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...).

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