Skip to contentSkip to conversation

remove mount_root_failed_msg()

PATCH In review Jeff Garzik 3 participants 3 messages Aug 20, 2003 – Aug 21, 2003 VFS

lore
Share & tools
lore

Jeff Garzik

author
#0 lore raw

PATCH 1/1 remove mount_root_failed_msg()

This one snuck in...

* debugging message for ACPI

* Intel guys removed it from their 2.4 tree (at my request)

* it's point-in-time specific (message becomes nearly useless after ACPI bug fixes)

* b/c of the point-in-time issue, it's IMO much more appropriate for a vendor kernel (where the message, I agree, may be helpful)

* can potentially mislead users to the correct cause of root mount failure

* overall, I disagree with adding messages like this. The number one bug report, by far, for networking drivers is ACPI-related (no interrupts delivered). You don't see me adding "boot with acpi=off" messages to the net subsystem.

===== arch/i386/kernel/dmi_scan.c 1.41 vs edited =====

arch/i386/kernel/dmi_scan.c +0 -24
@@ -1116,27 +1116,3 @@
 }
 
 EXPORT_SYMBOL(is_unsafe_smbus);
-
-#ifdef CONFIG_MOUNT_ROOT_FAILED_MSG
-/*
- * mount_root_failed_msg()
- *
- * Called from mount_block_root() upon failure to mount root.
- * architecture dependent to give different platforms
- * the opportunity to print different handy messages
- * On x86 this lives here b/c it dumps out some DMI info.
- */
-
-void
-mount_root_failed_msg(void)
-{
-#ifdef	CONFIG_ACPI_BOOT
-	printk ("Try booting with pci=noacpi, acpi=ht, "
-		"or acpi=off on the command line.\n");
-	printk ("If one helps, please report the following lines:\n");
-
-	dmi_dump_system();
-#endif
-}
-#endif	/* CONFIG_MOUNT_ROOT_FAILED_MSG */
-

===== arch/i386/defconfig 1.100 vs edited =====

arch/i386/defconfig +0 -1
@@ -228,7 +228,6 @@
 # CONFIG_BLK_DEV_RAM is not set
 # CONFIG_BLK_DEV_INITRD is not set
 CONFIG_LBD=y
-CONFIG_MOUNT_ROOT_FAILED_MSG=y
 
 #
 # ATA/ATAPI/MFM/RLL support

===== init/do_mounts.h 1.6 vs edited =====

init/do_mounts.h +0 -10
@@ -80,13 +80,3 @@
 
 #endif
 
-#ifdef CONFIG_MOUNT_ROOT_FAILED_MSG
-
-void mount_root_failed_msg(void);
-
-#else
-
-static inline void mount_root_failed_msg(void) {}
-
-#endif
-

===== init/do_mounts.c 1.54 vs edited =====

init/do_mounts.c +0 -2
@@ -286,8 +286,6 @@
 				root_device_name, b);
 		printk("Please append a correct \"root=\" boot option\n");
 
-		mount_root_failed_msg();	/* architecture dependent */
-
 		panic("VFS: Unable to mount root fs on %s", b);
 	}
 	panic("VFS: Unable to mount root fs on %s", __bdevname(ROOT_DEV, b));

===== arch/i386/Kconfig 1.71 vs edited =====

arch/i386/Kconfig +0 -4
@@ -1204,10 +1204,6 @@
 
 source "drivers/block/Kconfig"
 
-config MOUNT_ROOT_FAILED_MSG
-	bool
-	default y
-
 source "drivers/ide/Kconfig"
 
 source "drivers/scsi/Kconfig"
#1 lore raw
Quoted 5 lines · Jeff Garzik

* overall, I disagree with adding messages like this. The number one bug report, by far, for networking drivers is ACPI-related (no interrupts delivered). You don't see me adding "boot with acpi=off" messages to the net subsystem.

It's the number one bug report for USB drivers too :(

It has gotten smaller, and I would hope that is due to advances in the ACPI code, but they still do crop up quite frequently.

thanks,

greg k-h

#2 lore raw

PATCH 1/1 [2.5] fix 'pci=noacpi' was: Re: [patch] remove mount_root_failed_msg()

Quoted 10 lines · Greg KH
Quoted 4 lines · Jeff Garzik

* overall, I disagree with adding messages like this. The number one bug report, by far, for networking drivers is ACPI-related (no interrupts delivered). You don't see me adding "boot with acpi=off" messages to the net subsystem.

It's the number one bug report for USB drivers too :(

It has gotten smaller, and I would hope that is due to advances in the ACPI code, but they still do crop up quite frequently.

Well, I've got a board with these problems, too... (Epox 8K9A) It seems the ACPI IRQ override tables are buggy, so it cannot work... :-( But with 'pci=noacpi' it should work as the Documentation states:

noacpi [IA-32] Do not use ACPI for IRQ routing.

Unfortunately the ACPI IO-APIC setup is not overridden and without the attached patch, which corrects this issue, I had to use 'acpi=off'...

I think this will help people easily working around their APCI interrupt routing problems, as I think most of these are due to buggy ACPI IRQ override tables. Windows seems not to use them and so they are often badly tested... :-(

Best regards
Thomas Schlichter

BTW: Hunk 3 of this patch is only a simplification, because(acpi_lapic && acpi_ioapic) is always true here when that code is reached...

arch/i386/kernel/acpi/boot.c renamed from arch/i386/kernel/acpi/boot.c.orig +7 -8
@@ -39,6 +39,7 @@
 #define PREFIX			"ACPI: "
 
 extern int acpi_disabled;
+extern int acpi_irq;
 extern int acpi_ht;
 
 /* --------------------------------------------------------------------------

@@ -416,7 +417,7 @@
 	 * If MPS is present, it will handle them,
 	 * otherwise the system will stay in PIC mode
 	 */
-	if (acpi_disabled) {
+	if (acpi_disabled || !acpi_irq) {
 		return 1;
         }
 

@@ -451,15 +452,13 @@
 
 	acpi_ioapic = 1;
 
+#ifdef CONFIG_X86_LOCAL_APIC
+	smp_found_config = 1;
+	clustered_apic_check();
+#endif
+
 #endif /*CONFIG_ACPI*/
 #endif /*CONFIG_X86_IO_APIC*/
-
-#ifdef CONFIG_X86_LOCAL_APIC
-	if (acpi_lapic && acpi_ioapic) {
-		smp_found_config = 1;
-		clustered_apic_check();
-	}
-#endif
 
 	return 0;
 }
arch/i386/kernel/setup.c renamed from arch/i386/kernel/setup.c.orig +6 -0
@@ -70,6 +70,7 @@
 EXPORT_SYMBOL(acpi_disabled);
 
 #ifdef	CONFIG_ACPI_BOOT
+	int acpi_irq __initdata = 1;	/* enable IRQ */
 	int acpi_ht __initdata = 1;	/* enable HT */
 #endif
 

@@ -541,6 +542,11 @@
 		else if (!memcmp(from, "acpi=ht", 7)) {
 			acpi_ht = 1;
 			if (!acpi_force) acpi_disabled = 1;
+		}
+
+		/* "pci=noacpi" disables ACPI interrupt routing */
+		else if (!memcmp(from, "pci=noacpi", 10)) {
+			acpi_irq = 0;
 		}
 #endif