2.6 kernel won't reboot on AMD system (no, not the BIOS...)

[ Please CC replies to me. ]

[ Sorry for the rerun, but I guess everyone was away at the OLS, so I'll try again, operating on the squeaky wheel principle. ]

Before you hit reply or erase, no, I'm not talking about the machine not getting past the BIOS check complaining that there is no keyboard present.

Kernel 2.6.7

model name : AMD Athlon(tm) XP 2400+

motherboard: http://www.ecsusa.com/products/km400-m2.html

... not sure what else might be useful... apci=off added to boot options. Preemptive kernel.

In any case, the machine in question does not reboot. I traced the problem down to the mach_reboot but it doesn't get past those assembly instructions. Things do seem to work alright if a keyboard is installed. Otherwise, the machine just sits there, no longer responsive to pings or anything else.

This appears to be a somewhat common problem, as I found several other posters discussing it:

http://lkml.org/lkml/2004/3/12/248

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

any ideas on what parts of the kernel to look at in order to determine what is causing this? I need to fix it, and I don't know where to start looking.

Thankyou,

David N. Welton
[email protected]

[ Please CC replies to me. ]

....

By putting a series of 'crashme/reboot' calls into the kernel, I narrowed a possibl cause of it down to this bit of code in drivers/input/serio.c:753

/*
* Write CTR back.
*/

	if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
		printk(KERN_ERR "i8042.c: Can't write CTR while initializing i8042.\n");
		return -1;
	}

If I do the reboot instructions before this, it reboots fine. Afterwards, and it just sits there, no reboot.

Any ideas what to think/look for/do?

Sascha, to see if your problem is the same as mine, you might try putting this bit of code before the above call:

	{
	    static struct
	    {
		unsigned short       size __attribute__ ((packed));
		unsigned long long * base __attribute__ ((packed));
	    } no_idt = { 0, 0 };

	    /* That didn't work - force a triple fault.. */
	    __asm__ __volatile__("lidt %0": :"m" (no_idt));
	    __asm__ __volatile__("int3");
	}

It will cause your machine to reboot before it's even finished booting, so don't do it with your only available kernel!

Thanks,

David N. Welton
[email protected]

drivers/input/serio/i8042.c
right?

This is quite interesting, as there is only one function/macro, which seems to be messing up things -- I don't know much (hardly anything) aboout that hardwarestuff, but I'll have a look at i8042_command as soon as I find the time. At least it's a start...

[reboot code]

It works, so this seems to be the exactly same issue. I only tested with the code before the point above, I'll do further testings at the weekend, but I'm quite optimistic, that you found the point of failure. Thanks!

don't worry, lots o'kernel here... ;-)

cheers
sascha

Sascha Wilde : "There are 10 types of people in the world. 
             : Those who understand binary and those who don't."

Hi,

Could you please try the patch below? I am interested in tests both with and without keyboard/mouse. The main idea is to leave ports that have been disabled by BIOS alone... The patch compiles but otherwise untested. Against 2.6.7.

BTW, do you both have the same motherboard/chipset? Maybe a dmi entry is in order...

Thanks!

Dmitry

--- 2.6.7/drivers/input/serio/i8042.c.2.6.7	2004-08-10 22:47:49.000000000 -0500
+++ 2.6.7/drivers/input/serio/i8042.c	2004-08-10 23:07:29.000000000 -0500
@@ -567,6 +567,13 @@
 	static int i8042_check_aux_cookie;
 
 /*
+ * Ignore possible presence of AUX port if interface is disabled by
+ * the BIOS.
+ */
+	if (~i8042_initial_ctr & I8042_CTR_AUXDIS)
+		return -1;
+
+/*
  * Check if AUX irq is available. If it isn't, then there is no point
  * in trying to detect AUX presence.
  */
@@ -610,6 +617,7 @@
 
 	if (i8042_command(&param, I8042_CMD_AUX_DISABLE))
 		return -1;
+
 	if (i8042_command(&param, I8042_CMD_CTL_RCTR) || (~param & I8042_CTR_AUXDIS)) {
 		printk(KERN_WARNING "Failed to disable AUX port, but continuing anyway... Is this a SiS?\n");
 		printk(KERN_WARNING "If AUX port is really absent please use the 'i8042.noaux' option.\n");
@@ -712,31 +720,34 @@
 
 	i8042_initial_ctr = i8042_ctr;
 
+	if (~i8042_initial_ctr & I8042_CTR_KBDDIS) {
 /*
- * Disable the keyboard interface and interrupt.
+ * Disable the keyboard interface and interrupt. Note that we only try
+ * initializing keyboard port if it was enabled by the BIOS, otherwise
+ * some chipsets get upset and interfere with reboot process.
  */
 
-	i8042_ctr |= I8042_CTR_KBDDIS;
-	i8042_ctr &= ~I8042_CTR_KBDINT;
+		i8042_ctr |= I8042_CTR_KBDDIS;
+		i8042_ctr &= ~I8042_CTR_KBDINT;
 
 /*
  * Handle keylock.
  */
 
-	if (~i8042_read_status() & I8042_STR_KEYLOCK) {
-		if (i8042_unlock)
-			i8042_ctr |= I8042_CTR_IGNKEYLOCK;
-		 else
-			printk(KERN_WARNING "i8042.c: Warning: Keylock active.\n");
-	}
+		if (~i8042_read_status() & I8042_STR_KEYLOCK) {
+			if (i8042_unlock)
+				i8042_ctr |= I8042_CTR_IGNKEYLOCK;
+			 else
+				printk(KERN_WARNING "i8042.c: Warning: Keylock active.\n");
+		}
 
 /*
  * If the chip is configured into nontranslated mode by the BIOS, don't
  * bother enabling translating and be happy.
  */
 
-	if (~i8042_ctr & I8042_CTR_XLATE)
-		i8042_direct = 1;
+		if (~i8042_ctr & I8042_CTR_XLATE)
+			i8042_direct = 1;
 
 /*
  * Set nontranslated mode for the kbd interface if requested by an option.
@@ -745,18 +756,19 @@
  * BIOSes.
  */
 
-	if (i8042_direct) {
-		i8042_ctr &= ~I8042_CTR_XLATE;
-		i8042_kbd_port.type = SERIO_8042;
-	}
+		if (i8042_direct) {
+			i8042_ctr &= ~I8042_CTR_XLATE;
+			i8042_kbd_port.type = SERIO_8042;
+		}
 
 /*
  * Write CTR back.
  */
 
-	if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
-		printk(KERN_ERR "i8042.c: Can't write CTR while initializing i8042.\n");
-		return -1;
+		if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
+			printk(KERN_ERR "i8042.c: Can't write CTR while initializing i8042.\n");
+			return -1;
+		}
 	}
 
 	return 0;
@@ -772,17 +784,21 @@
 		unsigned char param;
 
 		if (i8042_command(&param, I8042_CMD_CTL_TEST))
-			printk(KERN_ERR "i8042.c: i8042 controller reset timeout.\n");
+			printk(KERN_WARNING "i8042.c: i8042 controller reset timeout.\n");
 	}
 
 /*
  * Restore the original control register setting.
  */
 
-	i8042_ctr = i8042_initial_ctr;
-
-	if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR))
-		printk(KERN_WARNING "i8042.c: Can't restore CTR.\n");
+	if (i8042_command(&i8042_ctr, I8042_CMD_CTL_RCTR))
+		printk(KERN_WARNING "i8042.c: Can't read CTR while resetting i8042.\n");
+	else
+		if (i8042_ctr != i8042_initial_ctr) {
+			i8042_ctr = i8042_initial_ctr;
+			if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR))
+				printk(KERN_WARNING "i8042.c: Can't restore CTR.\n");
+		}
 }
 
 
@@ -974,7 +990,8 @@
 			i8042_port_register(&i8042_aux_values, &i8042_aux_port);
 	}
 
-	i8042_port_register(&i8042_kbd_values, &i8042_kbd_port);
+	if (~i8042_initial_ctr & I8042_CTR_KBDDIS)
+		i8042_port_register(&i8042_kbd_values, &i8042_kbd_port);
 
 	mod_timer(&i8042_timer, jiffies + I8042_POLL_PERIOD);

The patch seems to work well! It doesn't apply completely cleanly to my sources... maybe I left some of my own stuff in. On reboot, with keyboard attached, I get this:

uart_close: bad serial port count; tty->count is 1, state->count2
while rebooting the system.

drivers/input/serio/i8042.c: ff -> i8042 (kbd-data) [121813]

drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [121886]

drivers/input/serio/i8042.c: aa <- i8042 (interrupt, kbd, 1) [122268]

drivers/input/serio/i8042.c: 20 -> i8042 (command) [122404]

drivers/input/serio/i8042.c: 45 <- i8042 (return) [122404]

drivers/input/serio/i8042.c: 60 -> i8042 (command) [122542]

drivers/input/serio/i8042.c: 65 -> i8042 (parameter) [122542]

Restarting system.

Mine is a VIA chipset with an AMD processor:

http://www.ecsusa.com/products/km400-m2.html

How do I fetch the exact information that would be needed for a DMI entry?

Thanks much,

David N. Welton
[email protected]

Well, this has a problem - plugging a mouse later will never work, as the interface will be disabled by the BIOS if a mouse is not present at boot.

Vojtech Pavlik
SuSE Labs, SuSE CR

Nor does plugging a keyboard in work either. On the other hand, for the application this computer is destined for, not being able to reboot is far, far worse than adding a mouse/keyboard at run time, so I'm happy. I'm still willing to work on and test patches, though, as I think it would be good to get some form of fix into the kernel. And the fact that 2.4 works shows that it is possible...

David N. Welton
[email protected]

[...]

Is PS/2 supposed to support hotpluging at all? I guess it's not, but I may be wrong...

cheers

Sascha Wilde   -.-. ..- .-. .. --- ... .. - -.-- 
               -.- .. .-.. .-.. . -.. 
               - .... .
               -.-. .- -

Hmm, this may be the design of the system, but from experience I can say that I've only had one computer that wouldn't later use a mouse or keyboard if it wasn't plugged in at boot. All my systems for the last three years will happily boot with nothing plugged in and use a mouse and keyboard whenever you want to plug them in. That one system that needed the mouse/keyboard plugged in at boot was Winblows. It would work fine in Linux.

David

begin:vcard
fn:David Ford
n:Ford;David
email;internet:[email protected]
title:Industrial Geek
tel;home:Ask please
tel;cell:(203) 650-3611
x-mozilla-html:TRUE
version:2.1
end:vcard

Electrically it's fine - the data and clock lines are pulled-up open-collector.

Protocol-wise it's also OK, each device announces itself after it's plugged in.

Vojtech Pavlik
SuSE Labs, SuSE CR

[...]

Sorry, but the patch does not work for me. The resulting kernel reboots, but it _disables_ (or fails to enable?) the PS/2 keyboard.

I don't know if it is of any interest, but I'm using grub to load linux (and in the grub boot shell the keyboard works).

No. I'm using a MSI Mainboard with AMD (Viper) chipset.

cheers
sascha

Sascha Wilde : "GUIs normally make it simple to accomplish simple 
             : actions and impossible to accomplish complex actions."
             : (Doug Gwyn - 22/Jun/91 in comp.unix.wizards)