Samsung N130 ATA exception after 5min uptime -- Phoenix FailSafe issue?

Samsung N130 ATA exception after 5min uptime -- Phoenix FailSafe issue?

[Johannes Stezenbach]

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

Hi,

I'm refering to
http://bugzilla.kernel.org/show_bug.cgi?id=14314
and I still have this issue on a N130 with latest BIOS (05CM),
running kernel 2.6.32-rc8 + wireless-testing.

BIOS Information
        Vendor: Phoenix Technologies Ltd.
        Version: 05CM.M011.20091013.JIP
        Release Date: 10/13/2009
        Address: 0xE6300
        Runtime Size: 105728 bytes
        ROM Size: 2048 kB
        Characteristics:
                ISA is supported
                PCI is supported
                PNP is supported
                BIOS is upgradeable
                BIOS shadowing is allowed
                ESCD support is available
                ACPI is supported
                USB legacy is supported
                Smart battery is supported
                BIOS boot specification is supported
                Targeted content distribution is supported
        BIOS Revision: 5.0

Around 5min after boot or resume if generates the following error:

[  302.364174] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[  302.364201] ata1.00: failed command: WRITE DMA
[  302.364234] ata1.00: cmd ca/00:08:f7:01:1a/00:00:00:00:00/e0 tag 0 dma 4096 out
[  302.364241]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[  302.364257] ata1.00: status: { DRDY }
[  307.408107] ata1: link is slow to respond, please be patient (ready=0)
[  312.392109] ata1: device not ready (errno=-16), forcing hardreset
[  312.392138] ata1: soft resetting link
[  312.574482] ata1.00: configured for UDMA/133
[  312.574506] ata1.00: device reported invalid CHS sector 0
[  312.574542] ata1: EH complete

This also happens when booting with rdinit=/bin/sh, i.e. only running busybox sh
inside initrd.  The error then appears when accessing the disk after the 5min
period with dd if=/dev/sda of=/dev/null count=10000.


The link in comment #14 is dead but eventually I found
http://download.opensuse.org/repositories/Moblin:/Base/openSUSE_11.1/src/kernel-source-2.6.31.6-37.1.src.rpm
which contains the attached patch with a samsung_laptop driver.

I think it is weird that the Samsung BIOS has a special "SECLINUX" mode,
but anyway the samsung_laptop driver works (the backlight control via ACPI
also works with the 05CM BIOS, though).

However, it does not prevent the ATA exception.

(Side note about backlight level 0: I noticed that in Windows when you
set the backlight to the lowest level, after a minute of inactivity
the screen would dim one level more. Stupid -- why not allow the user
to choose that level manually?)

So I guess one really needs the special Linux BIOS that Greg was talking
about in comments #14 and #16?  It is not clear from comment #17
which BIOS worked for Mikhail.

Or did I just miss some patch or magic config setting?


According to $subject, I have a wild theory that the issue
might be caused by the Phoenix "FailSafe" BIOS feature.
first of all, there is no indication on Samsung's web pages
anywhere that the N130 has it, but I had looked at the pre-installed
Windows before I wiped it (and did the BIOS update while at it),
and it had a "Phoenix FailSafe" icon prominently placed on the desktop.
Some searching yields:
http://www.failsafe.com/samsung-partner-profile

And after some more searching:
http://www.blackhat.com/presentations/bh-usa-09/ORTEGA/BHUSA09-Ortega-DeactivateRootkit-PAPER.pdf
which is about Computrace which appears to be a similar technology.

What I think is what happens is that the BIOS waits to be contacted
by the Windows "FailSafe" agent, and if that doesn't happen then the BIOS
tries to reinstall the agent into the Windows installation. Thus it
accesses the disk behind the OS's back, and this causes the ATA exception.
When FailSafe isn't activated by the user then the BIOS shouldn't do that,
but the BIOS developers might have thought different...

Note however that the BIOS setup screen contains no indication about FailSafe
support, so this is all wild guessing. It would fit in with the "special
Linux BIOS" info, though.  But I had hoped that the "SECLINUX" mode
would also disable it.


Thanks
Johannes

[-- Attachment #2: samsung-laptop-driver.patch --]
[-- Type: text/plain, Size: 17206 bytes --]

>From foo@baz Fri Aug 21 15:51:53 PDT 2009
Date: Fri, 21 Aug 2009 15:51:53 -0700
To: Greg KH <greg@kroah.com>
From: Greg Kroah-Hartman <gregkh@suse.de>
Subject: Samsung laptop driver

This driver implements backlight controls for Samsung laptops that
currently do not have ACPI support for this control.

It has been tested on the N130 laptop and properly works there.

Info for the NC10 was provided by Soeren Sonnenburg <bugreports@nn7.de>
Info for the NP-Q45 from Jérémie Huchet <jeremie@lamah.info>

Many thanks to Dmitry Torokhov <dmitry.torokhov@gmail.com> for cleanups
and other suggestions on how to make the driver simpler.

Cc: Soeren Sonnenburg <bugreports@nn7.de>
Cc: Jérémie Huchet <jeremie@lamah.info>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/platform/x86/Kconfig          |   12 
 drivers/platform/x86/Makefile         |    1 
 drivers/platform/x86/samsung-laptop.c |  582 ++++++++++++++++++++++++++++++++++
 3 files changed, 595 insertions(+)


--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -425,4 +425,16 @@ config ACPI_TOSHIBA
 
 	  If you have a legacy free Toshiba laptop (such as the Libretto L1
 	  series), say Y.
+
+config SAMSUNG_LAPTOP
+	tristate "Samsung Laptop driver"
+	depends on BACKLIGHT_CLASS_DEVICE
+	depends on DMI
+	---help---
+	  This driver adds support to control the backlight on a number of
+	  Samsung laptops, like the N130, and control for some of the LEDs
+
+	  It will only be loaded on laptops that properly need it, so it is
+	  safe to say Y here.
+
 endif # X86_PLATFORM_DEVICES
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -20,3 +20,4 @@ obj-$(CONFIG_INTEL_MENLOW)	+= intel_menl
 obj-$(CONFIG_ACPI_WMI)		+= wmi.o
 obj-$(CONFIG_ACPI_ASUS)		+= asus_acpi.o
 obj-$(CONFIG_ACPI_TOSHIBA)	+= toshiba_acpi.o
+obj-$(CONFIG_SAMSUNG_LAPTOP)	+= samsung-laptop.o
--- /dev/null
+++ b/drivers/platform/x86/samsung-laptop.c
@@ -0,0 +1,582 @@
+/*
+ * Samsung N130 Laptop driver
+ *
+ * Copyright (C) 2009 Greg Kroah-Hartman (gregkh@suse.de)
+ * Copyright (C) 2009 Novell Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ */
+#include <linux/version.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/delay.h>
+#include <linux/pci.h>
+#include <linux/backlight.h>
+#include <linux/fb.h>
+#include <linux/dmi.h>
+#include <linux/platform_device.h>
+#include <linux/rfkill.h>
+
+/*
+ * This driver is needed because a number of Samsung laptops do not hook
+ * their control settings through ACPI.  So we have to poke around in the
+ * BIOS to do things like brightness values, and "special" key controls.
+ */
+
+/*
+ * We have 0 - 8 as valid brightness levels.  The specs say that level 0 should
+ * be reserved by the BIOS (which really doesn't make much sense), we tell
+ * userspace that the value is 0 - 7 and then just tell the hardware 1 - 8
+ */
+#define MAX_BRIGHT	0x07
+
+/* Brightness is 0 - 8, as described above.  Value 0 is for the BIOS to use */
+#define GET_BRIGHTNESS			0x00
+#define SET_BRIGHTNESS			0x01
+
+/* first byte:
+ * 0x00 - wireless is off
+ * 0x01 - wireless is on
+ * second byte:
+ * 0x02 - 3G is off
+ * 0x03 - 3G is on
+ * TODO, verify 3G is correct, that doesn't seem right...
+ */
+#define GET_WIRELESS_BUTTON		0x02
+#define SET_WIRELESS_BUTTON		0x03
+
+/* 0 is off, 1 is on */
+#define GET_BACKLIGHT			0x04
+#define SET_BACKLIGHT			0x05
+
+/*
+ * 0x80 or 0x00 - no action
+ * 0x81 - recovery key pressed
+ */
+#define GET_RECOVERY_METHOD		0x06
+#define SET_RECOVERY_METHOD		0x07
+
+/* 0 is low, 1 is high */
+#define GET_PERFORMANCE_LEVEL		0x08
+#define SET_PERFORMANCE_LEVEL		0x09
+
+/*
+ * Tell the BIOS that Linux is running on this machine.
+ * 81 is on, 80 is off
+ */
+#define SET_LINUX			0x0a
+
+
+#define MAIN_FUNCTION			0x4c49
+
+#define SABI_HEADER_PORT		0x00
+#define SABI_HEADER_RE_MEM		0x02
+#define SABI_HEADER_IFACEFUNC		0x03
+#define SABI_HEADER_EN_MEM		0x04
+#define SABI_HEADER_DATA_OFFSET		0x05
+#define SABI_HEADER_DATA_SEGMENT	0x07
+
+#define SABI_IFACE_MAIN			0x00
+#define SABI_IFACE_SUB			0x02
+#define SABI_IFACE_COMPLETE		0x04
+#define SABI_IFACE_DATA			0x05
+
+/* Structure to get data back to the calling function */
+struct sabi_retval {
+	u8 retval[20];
+};
+
+static void __iomem *sabi;
+static void __iomem *sabi_iface;
+static void __iomem *f0000_segment;
+static struct backlight_device *backlight_device;
+static struct mutex sabi_mutex;
+static struct platform_device *sdev;
+static struct rfkill *rfk;
+
+static int force;
+module_param(force, bool, 0);
+MODULE_PARM_DESC(force, "Disable the DMI check and forces the driver to be loaded");
+
+static int debug;
+module_param(debug, bool, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(debug, "Debug enabled or not");
+
+static int sabi_get_command(u8 command, struct sabi_retval *sretval)
+{
+	int retval = 0;
+	u16 port = readw(sabi + SABI_HEADER_PORT);
+
+	mutex_lock(&sabi_mutex);
+
+	/* enable memory to be able to write to it */
+	outb(readb(sabi + SABI_HEADER_EN_MEM), port);
+
+	/* write out the command */
+	writew(MAIN_FUNCTION, sabi_iface + SABI_IFACE_MAIN);
+	writew(command, sabi_iface + SABI_IFACE_SUB);
+	writeb(0, sabi_iface + SABI_IFACE_COMPLETE);
+	outb(readb(sabi + SABI_HEADER_IFACEFUNC), port);
+
+	/* write protect memory to make it safe */
+	outb(readb(sabi + SABI_HEADER_RE_MEM), port);
+
+	/* see if the command actually succeeded */
+	if (readb(sabi_iface + SABI_IFACE_COMPLETE) == 0xaa &&
+	    readb(sabi_iface + SABI_IFACE_DATA) != 0xff) {
+		/*
+		 * It did!
+		 * Save off the data into a structure so the caller use it.
+		 * Right now we only care about the first 4 bytes,
+		 * I suppose there are commands that need more, but I don't
+		 * know about them.
+		 */
+		sretval->retval[0] = readb(sabi_iface + SABI_IFACE_DATA);
+		sretval->retval[1] = readb(sabi_iface + SABI_IFACE_DATA + 1);
+		sretval->retval[2] = readb(sabi_iface + SABI_IFACE_DATA + 2);
+		sretval->retval[3] = readb(sabi_iface + SABI_IFACE_DATA + 3);
+		goto exit;
+	}
+
+	/* Something bad happened, so report it and error out */
+	printk(KERN_WARNING "SABI command 0x%02x failed with completion flag 0x%02x and output 0x%02x\n",
+		command, readb(sabi_iface + SABI_IFACE_COMPLETE),
+		readb(sabi_iface + SABI_IFACE_DATA));
+	retval = -EINVAL;
+exit:
+	mutex_unlock(&sabi_mutex);
+	return retval;
+
+}
+
+static int sabi_set_command(u8 command, u8 data)
+{
+	int retval = 0;
+	u16 port = readw(sabi + SABI_HEADER_PORT);
+
+	mutex_lock(&sabi_mutex);
+
+	/* enable memory to be able to write to it */
+	outb(readb(sabi + SABI_HEADER_EN_MEM), port);
+
+	/* write out the command */
+	writew(MAIN_FUNCTION, sabi_iface + SABI_IFACE_MAIN);
+	writew(command, sabi_iface + SABI_IFACE_SUB);
+	writeb(0, sabi_iface + SABI_IFACE_COMPLETE);
+	writeb(data, sabi_iface + SABI_IFACE_DATA);
+	outb(readb(sabi + SABI_HEADER_IFACEFUNC), port);
+
+	/* write protect memory to make it safe */
+	outb(readb(sabi + SABI_HEADER_RE_MEM), port);
+
+	/* see if the command actually succeeded */
+	if (readb(sabi_iface + SABI_IFACE_COMPLETE) == 0xaa &&
+	    readb(sabi_iface + SABI_IFACE_DATA) != 0xff) {
+		/* it did! */
+		goto exit;
+	}
+
+	/* Something bad happened, so report it and error out */
+	printk(KERN_WARNING "SABI command 0x%02x failed with completion flag 0x%02x and output 0x%02x\n",
+		command, readb(sabi_iface + SABI_IFACE_COMPLETE),
+		readb(sabi_iface + SABI_IFACE_DATA));
+	retval = -EINVAL;
+exit:
+	mutex_unlock(&sabi_mutex);
+	return retval;
+}
+
+static void test_backlight(void)
+{
+	struct sabi_retval sretval;
+
+	sabi_get_command(GET_BACKLIGHT, &sretval);
+	printk(KERN_DEBUG "backlight = 0x%02x\n", sretval.retval[0]);
+
+	sabi_set_command(SET_BACKLIGHT, 0);
+	printk(KERN_DEBUG "backlight should be off\n");
+
+	sabi_get_command(GET_BACKLIGHT, &sretval);
+	printk(KERN_DEBUG "backlight = 0x%02x\n", sretval.retval[0]);
+
+	msleep(1000);
+
+	sabi_set_command(SET_BACKLIGHT, 1);
+	printk(KERN_DEBUG "backlight should be on\n");
+
+	sabi_get_command(GET_BACKLIGHT, &sretval);
+	printk(KERN_DEBUG "backlight = 0x%02x\n", sretval.retval[0]);
+}
+
+static void test_wireless(void)
+{
+	struct sabi_retval sretval;
+
+	sabi_get_command(GET_WIRELESS_BUTTON, &sretval);
+	printk(KERN_DEBUG "wireless led = 0x%02x\n", sretval.retval[0]);
+
+	sabi_set_command(SET_WIRELESS_BUTTON, 0);
+	printk(KERN_DEBUG "wireless led should be off\n");
+
+	sabi_get_command(GET_WIRELESS_BUTTON, &sretval);
+	printk(KERN_DEBUG "wireless led = 0x%02x\n", sretval.retval[0]);
+
+	msleep(1000);
+
+	sabi_set_command(SET_WIRELESS_BUTTON, 1);
+	printk(KERN_DEBUG "wireless led should be on\n");
+
+	sabi_get_command(GET_WIRELESS_BUTTON, &sretval);
+	printk(KERN_DEBUG "wireless led = 0x%02x\n", sretval.retval[0]);
+}
+
+static u8 read_brightness(void)
+{
+	struct sabi_retval sretval;
+	int user_brightness = 0;
+	int retval;
+
+	retval = sabi_get_command(GET_BACKLIGHT, &sretval);
+	if (!retval)
+		user_brightness = sretval.retval[0];
+		if (user_brightness != 0)
+			--user_brightness;
+	return user_brightness;
+}
+
+static void set_brightness(u8 user_brightness)
+{
+	sabi_set_command(SET_BRIGHTNESS, user_brightness + 1);
+}
+
+static int get_brightness(struct backlight_device *bd)
+{
+	return bd->props.brightness;
+}
+
+static int update_status(struct backlight_device *bd)
+{
+	set_brightness(bd->props.brightness);
+
+	if (bd->props.power == FB_BLANK_UNBLANK)
+		sabi_set_command(SET_BACKLIGHT, 1);
+	else
+		sabi_set_command(SET_BACKLIGHT, 0);
+	return 0;
+}
+
+static struct backlight_ops backlight_ops = {
+	.get_brightness	= get_brightness,
+	.update_status	= update_status,
+};
+
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,31)
+static int rfkill_set(void *data, bool blocked)
+{
+	/* Do something with blocked...*/
+	/*
+	 * blocked == false is on
+	 * blocked == true is off
+	 */
+	if (blocked)
+		sabi_set_command(SET_WIRELESS_BUTTON, 0);
+	else
+		sabi_set_command(SET_WIRELESS_BUTTON, 1);
+
+	return 0;
+}
+
+static struct rfkill_ops rfkill_ops = {
+	.set_block = rfkill_set,
+};
+
+static int init_wireless(struct platform_device *sdev)
+{
+	int retval;
+
+	rfk = rfkill_alloc("samsung-wifi", &sdev->dev, RFKILL_TYPE_WLAN,
+			   &rfkill_ops, NULL);
+	if (!rfk)
+		return -ENOMEM;
+
+	retval = rfkill_register(rfk);
+	if (retval) {
+		rfkill_destroy(rfk);
+		return -ENODEV;
+	}
+
+	return 0;
+}
+
+static void destroy_wireless(void)
+{
+	rfkill_unregister(rfk);
+	rfkill_destroy(rfk);
+}
+
+#else
+
+static int rfkill_set(void *data, enum rfkill_state state)
+{
+	if (state ==  RFKILL_STATE_UNBLOCKED)
+		sabi_set_command(SET_WIRELESS_BUTTON, 1);
+	else
+		sabi_set_command(SET_WIRELESS_BUTTON, 0);
+
+	return 0;
+}
+
+static int init_wireless(struct platform_device *sdev)
+{
+	int retval;
+
+	rfk = rfkill_allocate(&sdev->dev, RFKILL_TYPE_WLAN);
+	if (!rfk)
+		return -ENOMEM;
+	rfk->toggle_radio = rfkill_set;
+	rfk->name = "samsung-wifi";
+
+	retval = rfkill_register(rfk);
+	if (retval) {
+		rfkill_free(rfk);
+		return -ENODEV;
+	}
+
+	return 0;
+}
+
+static void destroy_wireless(void)
+{
+	rfkill_unregister(rfk);
+}
+
+#endif
+
+static ssize_t get_silent_state(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	struct sabi_retval sretval;
+	int retval;
+
+	/* Read the state */
+	retval = sabi_get_command(GET_PERFORMANCE_LEVEL, &sretval);
+	if (retval)
+		return retval;
+
+	/* The logic is backwards, yeah, lots of fun... */
+	if (sretval.retval[0] == 0)
+		retval = 1;
+	else
+		retval = 0;
+	return sprintf(buf, "%d\n", retval);
+}
+
+static ssize_t set_silent_state(struct device *dev,
+				struct device_attribute *attr, const char *buf,
+				size_t count)
+{
+	char value;
+
+	if (count >= 1) {
+		value = buf[0];
+		if ((value == '0') || (value == 'n') || (value == 'N')) {
+			/* Turn speed up */
+			sabi_set_command(SET_PERFORMANCE_LEVEL, 0x01);
+		} else if ((value == '1') || (value == 'y') || (value == 'Y')) {
+			/* Turn speed down */
+			sabi_set_command(SET_PERFORMANCE_LEVEL, 0x00);
+		} else {
+			return -EINVAL;
+		}
+	}
+	return count;
+}
+static DEVICE_ATTR(silent, S_IWUGO | S_IRUGO,
+		   get_silent_state, set_silent_state);
+
+
+static int __init dmi_check_cb(const struct dmi_system_id *id)
+{
+	printk(KERN_INFO KBUILD_MODNAME ": found laptop model '%s'\n",
+		id->ident);
+	return 0;
+}
+
+static struct dmi_system_id __initdata samsung_dmi_table[] = {
+	{
+		.ident = "N128",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "N128"),
+			DMI_MATCH(DMI_BOARD_NAME, "N128"),
+		},
+		.callback = dmi_check_cb,
+	},
+	{
+		.ident = "N130",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "N130"),
+			DMI_MATCH(DMI_BOARD_NAME, "N130"),
+		},
+		.callback = dmi_check_cb,
+	},
+	{ },
+};
+MODULE_DEVICE_TABLE(dmi, samsung_dmi_table);
+
+static int __init samsung_init(void)
+{
+	struct sabi_retval sretval;
+	const char *testStr = "SECLINUX";
+	void __iomem *memcheck;
+	unsigned int ifaceP;
+	int pStr;
+	int loca;
+	int retval;
+
+	mutex_init(&sabi_mutex);
+
+	if (!force && !dmi_check_system(samsung_dmi_table))
+		return -ENODEV;
+
+	f0000_segment = ioremap(0xf0000, 0xffff);
+	if (!f0000_segment) {
+		printk(KERN_ERR "Can't map the segment at 0xf0000\n");
+		return -EINVAL;
+	}
+
+	/* Try to find the signature "SECLINUX" in memory to find the header */
+	pStr = 0;
+	memcheck = f0000_segment;
+	for (loca = 0; loca < 0xffff; loca++) {
+		char temp = readb(memcheck + loca);
+
+		if (temp == testStr[pStr]) {
+			if (pStr == strlen(testStr)-1)
+				break;
+			++pStr;
+		} else {
+			pStr = 0;
+		}
+	}
+	if (loca == 0xffff) {
+		printk(KERN_ERR "This computer does not support SABI\n");
+		goto error_no_signature;
+		}
+
+	/* point to the SMI port Number */
+	loca += 1;
+	sabi = (memcheck + loca);
+
+	if (debug) {
+		printk(KERN_DEBUG "This computer supports SABI==%x\n",
+			loca + 0xf0000 - 6);
+		printk(KERN_DEBUG "SABI header:\n");
+		printk(KERN_DEBUG " SMI Port Number = 0x%04x\n",
+			readw(sabi + SABI_HEADER_PORT));
+		printk(KERN_DEBUG " SMI Interface Function = 0x%02x\n",
+			readb(sabi + SABI_HEADER_IFACEFUNC));
+		printk(KERN_DEBUG " SMI enable memory buffer = 0x%02x\n",
+			readb(sabi + SABI_HEADER_EN_MEM));
+		printk(KERN_DEBUG " SMI restore memory buffer = 0x%02x\n",
+			readb(sabi + SABI_HEADER_RE_MEM));
+		printk(KERN_DEBUG " SABI data offset = 0x%04x\n",
+			readw(sabi + SABI_HEADER_DATA_OFFSET));
+		printk(KERN_DEBUG " SABI data segment = 0x%04x\n",
+			readw(sabi + SABI_HEADER_DATA_SEGMENT));
+	}
+
+	/* Get a pointer to the SABI Interface */
+	ifaceP = (readw(sabi + SABI_HEADER_DATA_SEGMENT) & 0x0ffff) << 4;
+	ifaceP += readw(sabi + SABI_HEADER_DATA_OFFSET) & 0x0ffff;
+	sabi_iface = ioremap(ifaceP, 16);
+	if (!sabi_iface) {
+		printk(KERN_ERR "Can't remap %x\n", ifaceP);
+		goto exit;
+	}
+	if (debug) {
+		printk(KERN_DEBUG "ifaceP = 0x%08x\n", ifaceP);
+		printk(KERN_DEBUG "sabi_iface = %p\n", sabi_iface);
+
+		test_backlight();
+		test_wireless();
+
+		retval = sabi_get_command(GET_BRIGHTNESS, &sretval);
+		printk(KERN_DEBUG "brightness = 0x%02x\n", sretval.retval[0]);
+	}
+
+	/* Turn on "Linux" mode in the BIOS */
+	retval = sabi_set_command(SET_LINUX, 0x81);
+	if (retval) {
+		printk(KERN_ERR KBUILD_MODNAME ": Linux mode was not set!\n");
+		goto error_no_platform;
+	}
+
+	/* knock up a platform device to hang stuff off of */
+	sdev = platform_device_register_simple("samsung", -1, NULL, 0);
+	if (IS_ERR(sdev))
+		goto error_no_platform;
+
+	/* create a backlight device to talk to this one */
+	backlight_device = backlight_device_register("samsung", &sdev->dev,
+						     NULL, &backlight_ops);
+	if (IS_ERR(backlight_device))
+		goto error_no_backlight;
+
+	backlight_device->props.max_brightness = MAX_BRIGHT;
+	backlight_device->props.brightness = read_brightness();
+	backlight_device->props.power = FB_BLANK_UNBLANK;
+	backlight_update_status(backlight_device);
+
+	retval = init_wireless(sdev);
+	if (retval)
+		goto error_no_rfk;
+
+	retval = device_create_file(&sdev->dev, &dev_attr_silent);
+	if (retval)
+		goto error_file_create;
+
+exit:
+	return 0;
+
+error_file_create:
+	destroy_wireless();
+
+error_no_rfk:
+	backlight_device_unregister(backlight_device);
+
+error_no_backlight:
+	platform_device_unregister(sdev);
+
+error_no_platform:
+	iounmap(sabi_iface);
+
+error_no_signature:
+	iounmap(f0000_segment);
+	return -EINVAL;
+}
+
+static void __exit samsung_exit(void)
+{
+	/* Turn off "Linux" mode in the BIOS */
+	sabi_set_command(SET_LINUX, 0x80);
+
+	device_remove_file(&sdev->dev, &dev_attr_silent);
+	backlight_device_unregister(backlight_device);
+	destroy_wireless();
+	iounmap(sabi_iface);
+	iounmap(f0000_segment);
+	platform_device_unregister(sdev);
+}
+
+module_init(samsung_init);
+module_exit(samsung_exit);
+
+MODULE_AUTHOR("Greg Kroah-Hartman <gregkh@suse.de>");
+MODULE_DESCRIPTION("Samsung Backlight driver");
+MODULE_LICENSE("GPL");

Re: Samsung N130 ATA exception after 5min uptime -- Phoenix FailSafe issue?

[Greg KH]

On Thu, Nov 26, 2009 at 05:42:12PM +0100, Johannes Stezenbach wrote:
> Hi,
> 
> I'm refering to
> http://bugzilla.kernel.org/show_bug.cgi?id=14314
> and I still have this issue on a N130 with latest BIOS (05CM),
> running kernel 2.6.32-rc8 + wireless-testing.
> 
> BIOS Information
>         Vendor: Phoenix Technologies Ltd.
>         Version: 05CM.M011.20091013.JIP
>         Release Date: 10/13/2009
>         Address: 0xE6300
>         Runtime Size: 105728 bytes
>         ROM Size: 2048 kB
>         Characteristics:
>                 ISA is supported
>                 PCI is supported
>                 PNP is supported
>                 BIOS is upgradeable
>                 BIOS shadowing is allowed
>                 ESCD support is available
>                 ACPI is supported
>                 USB legacy is supported
>                 Smart battery is supported
>                 BIOS boot specification is supported
>                 Targeted content distribution is supported
>         BIOS Revision: 5.0
> 
> Around 5min after boot or resume if generates the following error:
> 
> [  302.364174] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> [  302.364201] ata1.00: failed command: WRITE DMA
> [  302.364234] ata1.00: cmd ca/00:08:f7:01:1a/00:00:00:00:00/e0 tag 0 dma 4096 out
> [  302.364241]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> [  302.364257] ata1.00: status: { DRDY }
> [  307.408107] ata1: link is slow to respond, please be patient (ready=0)
> [  312.392109] ata1: device not ready (errno=-16), forcing hardreset
> [  312.392138] ata1: soft resetting link
> [  312.574482] ata1.00: configured for UDMA/133
> [  312.574506] ata1.00: device reported invalid CHS sector 0
> [  312.574542] ata1: EH complete

This is because after 5 minutes, the BIOS implements C states in the
processor, which causes a "hic-up" in userspace.  Everything should be
fine after this, and most importantly, the power usage drops by a few
watts, which is most important.

> This also happens when booting with rdinit=/bin/sh, i.e. only running busybox sh
> inside initrd.  The error then appears when accessing the disk after the 5min
> period with dd if=/dev/sda of=/dev/null count=10000.

Yup, see above for why.

Samsung does this to make booting their BIOS faster.

> The link in comment #14 is dead but eventually I found
> http://download.opensuse.org/repositories/Moblin:/Base/openSUSE_11.1/src/kernel-source-2.6.31.6-37.1.src.rpm
> which contains the attached patch with a samsung_laptop driver.
> 
> I think it is weird that the Samsung BIOS has a special "SECLINUX" mode,
> but anyway the samsung_laptop driver works (the backlight control via ACPI
> also works with the 05CM BIOS, though).

Yes, but Samsung does not support ACPI at this time, even though it is
in their latest bios versions (experimental stuff, needed for Windows 7
mode or something...)

And yes, a "special" linux mode is weird, but at least they gave us
something that works :)

> However, it does not prevent the ATA exception.

Yup, it's not an issue though.

> (Side note about backlight level 0: I noticed that in Windows when you
> set the backlight to the lowest level, after a minute of inactivity
> the screen would dim one level more. Stupid -- why not allow the user
> to choose that level manually?)

Talk to samsung about this.  There is one more lower level the BIOS can
go to, which is what Windows does here.  Samsung doesn't want Linux to
use that mode at this time.  It only saves a bit less than .1W, so it's
not that big of a deal.

Glad it's all working for you now.

greg k-h

Re: Samsung N130 ATA exception after 5min uptime -- Phoenix FailSafe issue?

[Robert Hancock]

On 11/28/2009 01:19 PM, Greg KH wrote:
> On Thu, Nov 26, 2009 at 05:42:12PM +0100, Johannes Stezenbach wrote:
>> Hi,
>>
>> I'm refering to
>> http://bugzilla.kernel.org/show_bug.cgi?id=14314
>> and I still have this issue on a N130 with latest BIOS (05CM),
>> running kernel 2.6.32-rc8 + wireless-testing.
>>
>> BIOS Information
>>          Vendor: Phoenix Technologies Ltd.
>>          Version: 05CM.M011.20091013.JIP
>>          Release Date: 10/13/2009
>>          Address: 0xE6300
>>          Runtime Size: 105728 bytes
>>          ROM Size: 2048 kB
>>          Characteristics:
>>                  ISA is supported
>>                  PCI is supported
>>                  PNP is supported
>>                  BIOS is upgradeable
>>                  BIOS shadowing is allowed
>>                  ESCD support is available
>>                  ACPI is supported
>>                  USB legacy is supported
>>                  Smart battery is supported
>>                  BIOS boot specification is supported
>>                  Targeted content distribution is supported
>>          BIOS Revision: 5.0
>>
>> Around 5min after boot or resume if generates the following error:
>>
>> [  302.364174] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
>> [  302.364201] ata1.00: failed command: WRITE DMA
>> [  302.364234] ata1.00: cmd ca/00:08:f7:01:1a/00:00:00:00:00/e0 tag 0 dma 4096 out
>> [  302.364241]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
>> [  302.364257] ata1.00: status: { DRDY }
>> [  307.408107] ata1: link is slow to respond, please be patient (ready=0)
>> [  312.392109] ata1: device not ready (errno=-16), forcing hardreset
>> [  312.392138] ata1: soft resetting link
>> [  312.574482] ata1.00: configured for UDMA/133
>> [  312.574506] ata1.00: device reported invalid CHS sector 0
>> [  312.574542] ata1: EH complete
>
> This is because after 5 minutes, the BIOS implements C states in the
> processor, which causes a "hic-up" in userspace.  Everything should be
> fine after this, and most importantly, the power usage drops by a few
> watts, which is most important.

Why does this "hiccup" seem to cause interrupts to get lost? This would 
cause an up to 30-second stall in disk I/O.

>
>> This also happens when booting with rdinit=/bin/sh, i.e. only running busybox sh
>> inside initrd.  The error then appears when accessing the disk after the 5min
>> period with dd if=/dev/sda of=/dev/null count=10000.
>
> Yup, see above for why.
>
> Samsung does this to make booting their BIOS faster.

Ugh.. Seriously?

>
>> The link in comment #14 is dead but eventually I found
>> http://download.opensuse.org/repositories/Moblin:/Base/openSUSE_11.1/src/kernel-source-2.6.31.6-37.1.src.rpm
>> which contains the attached patch with a samsung_laptop driver.
>>
>> I think it is weird that the Samsung BIOS has a special "SECLINUX" mode,
>> but anyway the samsung_laptop driver works (the backlight control via ACPI
>> also works with the 05CM BIOS, though).
>
> Yes, but Samsung does not support ACPI at this time, even though it is
> in their latest bios versions (experimental stuff, needed for Windows 7
> mode or something...)

ACPI support would seem much preferable to implementing power management 
with such strange proprietary hacks..

>
> And yes, a "special" linux mode is weird, but at least they gave us
> something that works :)
>
>> However, it does not prevent the ATA exception.
>
> Yup, it's not an issue though.
>
>> (Side note about backlight level 0: I noticed that in Windows when you
>> set the backlight to the lowest level, after a minute of inactivity
>> the screen would dim one level more. Stupid -- why not allow the user
>> to choose that level manually?)
>
> Talk to samsung about this.  There is one more lower level the BIOS can
> go to, which is what Windows does here.  Samsung doesn't want Linux to
> use that mode at this time.  It only saves a bit less than .1W, so it's
> not that big of a deal.
>
> Glad it's all working for you now.
>
> greg k-h

Re: Samsung N130 ATA exception after 5min uptime -- Phoenix FailSafe issue?

[Greg KH]

On Sat, Nov 28, 2009 at 02:30:38PM -0600, Robert Hancock wrote:
> On 11/28/2009 01:19 PM, Greg KH wrote:
>> On Thu, Nov 26, 2009 at 05:42:12PM +0100, Johannes Stezenbach wrote:
>>> Hi,
>>>
>>> I'm refering to
>>> http://bugzilla.kernel.org/show_bug.cgi?id=14314
>>> and I still have this issue on a N130 with latest BIOS (05CM),
>>> running kernel 2.6.32-rc8 + wireless-testing.
>>>
>>> BIOS Information
>>>          Vendor: Phoenix Technologies Ltd.
>>>          Version: 05CM.M011.20091013.JIP
>>>          Release Date: 10/13/2009
>>>          Address: 0xE6300
>>>          Runtime Size: 105728 bytes
>>>          ROM Size: 2048 kB
>>>          Characteristics:
>>>                  ISA is supported
>>>                  PCI is supported
>>>                  PNP is supported
>>>                  BIOS is upgradeable
>>>                  BIOS shadowing is allowed
>>>                  ESCD support is available
>>>                  ACPI is supported
>>>                  USB legacy is supported
>>>                  Smart battery is supported
>>>                  BIOS boot specification is supported
>>>                  Targeted content distribution is supported
>>>          BIOS Revision: 5.0
>>>
>>> Around 5min after boot or resume if generates the following error:
>>>
>>> [  302.364174] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
>>> [  302.364201] ata1.00: failed command: WRITE DMA
>>> [  302.364234] ata1.00: cmd ca/00:08:f7:01:1a/00:00:00:00:00/e0 tag 0 dma 4096 out
>>> [  302.364241]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
>>> [  302.364257] ata1.00: status: { DRDY }
>>> [  307.408107] ata1: link is slow to respond, please be patient (ready=0)
>>> [  312.392109] ata1: device not ready (errno=-16), forcing hardreset
>>> [  312.392138] ata1: soft resetting link
>>> [  312.574482] ata1.00: configured for UDMA/133
>>> [  312.574506] ata1.00: device reported invalid CHS sector 0
>>> [  312.574542] ata1: EH complete
>>
>> This is because after 5 minutes, the BIOS implements C states in the
>> processor, which causes a "hic-up" in userspace.  Everything should be
>> fine after this, and most importantly, the power usage drops by a few
>> watts, which is most important.
>
> Why does this "hiccup" seem to cause interrupts to get lost? This would 
> cause an up to 30-second stall in disk I/O.

Yup, it does.

>>> This also happens when booting with rdinit=/bin/sh, i.e. only running busybox sh
>>> inside initrd.  The error then appears when accessing the disk after the 5min
>>> period with dd if=/dev/sda of=/dev/null count=10000.
>>
>> Yup, see above for why.
>>
>> Samsung does this to make booting their BIOS faster.
>
> Ugh.. Seriously?

Seriously.  It's a BIOS issue, and is the way that Samsung has
implemented this.  There is nothing that the OS can do about it.
Windows has the same "issue" here.

>>> The link in comment #14 is dead but eventually I found
>>> http://download.opensuse.org/repositories/Moblin:/Base/openSUSE_11.1/src/kernel-source-2.6.31.6-37.1.src.rpm
>>> which contains the attached patch with a samsung_laptop driver.
>>>
>>> I think it is weird that the Samsung BIOS has a special "SECLINUX" mode,
>>> but anyway the samsung_laptop driver works (the backlight control via ACPI
>>> also works with the 05CM BIOS, though).
>>
>> Yes, but Samsung does not support ACPI at this time, even though it is
>> in their latest bios versions (experimental stuff, needed for Windows 7
>> mode or something...)
>
> ACPI support would seem much preferable to implementing power management 
> with such strange proprietary hacks..

I do not disagree with you at all about this.  This has been
communicated to Samsung, but at this point in time, they are not going
to support ACPI and only want Linux to use this interface.

thanks,

greg k-h

Re: Samsung N130 ATA exception after 5min uptime -- Phoenix FailSafe issue?

[Johannes Stezenbach]

On Sat, Nov 28, 2009 at 01:34:46PM -0800, Greg KH wrote:
> On Sat, Nov 28, 2009 at 02:30:38PM -0600, Robert Hancock wrote:
> > On 11/28/2009 01:19 PM, Greg KH wrote:
> >> On Thu, Nov 26, 2009 at 05:42:12PM +0100, Johannes Stezenbach wrote:
> >>>
> >>> Around 5min after boot or resume if generates the following error:
> >>>
> >>> [  302.364174] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> >>> [  302.364201] ata1.00: failed command: WRITE DMA
> >>> [  302.364234] ata1.00: cmd ca/00:08:f7:01:1a/00:00:00:00:00/e0 tag 0 dma 4096 out
> >>> [  302.364241]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> >>> [  302.364257] ata1.00: status: { DRDY }
> >>> [  307.408107] ata1: link is slow to respond, please be patient (ready=0)
> >>> [  312.392109] ata1: device not ready (errno=-16), forcing hardreset
> >>> [  312.392138] ata1: soft resetting link
> >>> [  312.574482] ata1.00: configured for UDMA/133
> >>> [  312.574506] ata1.00: device reported invalid CHS sector 0
> >>> [  312.574542] ata1: EH complete
> >>
> >> This is because after 5 minutes, the BIOS implements C states in the
> >> processor, which causes a "hic-up" in userspace.  Everything should be
> >> fine after this, and most importantly, the power usage drops by a few
> >> watts, which is most important.
> >
> > Why does this "hiccup" seem to cause interrupts to get lost? This would 
> > cause an up to 30-second stall in disk I/O.
> 
> Yup, it does.
> 
> >>> This also happens when booting with rdinit=/bin/sh, i.e. only running busybox sh
> >>> inside initrd.  The error then appears when accessing the disk after the 5min
> >>> period with dd if=/dev/sda of=/dev/null count=10000.
> >>
> >> Yup, see above for why.
> >>
> >> Samsung does this to make booting their BIOS faster.
> >
> > Ugh.. Seriously?
> 
> Seriously.  It's a BIOS issue, and is the way that Samsung has
> implemented this.  There is nothing that the OS can do about it.
> Windows has the same "issue" here.

Um, "how does Windows handle this" would've been my next question.
I didn't do much with Windows before I wiped it, I mainly used it
to confirm the thing works and to do the BIOS update. I did go through
a few reboot cycles though and I think I would've noticed a 30 second
hang. Maybe they just lowered the ATA timeout to hide it or something.
Otherwise I guess google would turn up complaints from Windows users, too,
not just from Linux users.

BTW, at 5min after boot it is 99% guaranteed that this ATA
exception will happen during the occasional fsck. That
doesn't feel right.

> I do not disagree with you at all about this.  This has been
> communicated to Samsung, but at this point in time, they are not going
> to support ACPI and only want Linux to use this interface.

Well, at least they made the information for the SECLINUX interface
available (to you), but it would be better they'd support ACPI.
I mean if they have to support it for Windows 7 anyway, then
what's the point of not supporting it for other OSs?


While were at it I have another question:  When running on battery the
ethernet throughput drops to ~25Mbit/s.  After a bit of experimenting
I found that this is connected to a BIOS entry about "CPU Power
Saving Mode".  lspci shows that this changes "LnkCtl: ASPM L1
Enabled" to "LnkCtl: ASPM L0s L1 Enabled".  Having this config
option in the BIOS is inflexible.  IIRC there was an app in
Windows which allows to configure it at runtime.  Do you
know how to do it in Linux?


Thanks
Johannes

Re: Samsung N130 ATA exception after 5min uptime -- Phoenix FailSafe issue?

[Greg KH]

On Sat, Nov 28, 2009 at 11:22:03PM +0100, Johannes Stezenbach wrote:
> > Seriously.  It's a BIOS issue, and is the way that Samsung has
> > implemented this.  There is nothing that the OS can do about it.
> > Windows has the same "issue" here.
> 
> Um, "how does Windows handle this" would've been my next question.
> I didn't do much with Windows before I wiped it, I mainly used it
> to confirm the thing works and to do the BIOS update. I did go through
> a few reboot cycles though and I think I would've noticed a 30 second
> hang. Maybe they just lowered the ATA timeout to hide it or something.
> Otherwise I guess google would turn up complaints from Windows users, too,
> not just from Linux users.
> 
> BTW, at 5min after boot it is 99% guaranteed that this ATA
> exception will happen during the occasional fsck. That
> doesn't feel right.

Well, I've never been doing a fsck at 5 minutes into boot, and neither do
most Windows users :)

> > I do not disagree with you at all about this.  This has been
> > communicated to Samsung, but at this point in time, they are not going
> > to support ACPI and only want Linux to use this interface.
> 
> Well, at least they made the information for the SECLINUX interface
> available (to you),

You have as much information for the SECLINUX interface that I do at
this point in time.  It is all documented in the driver.  Actually, it's
documented better in the driver than the "hints" they originally
provided me...

> but it would be better they'd support ACPI.
> I mean if they have to support it for Windows 7 anyway, then
> what's the point of not supporting it for other OSs?

Hey, no argument from me here, but I think the main issue is that they
do not officially support Windows 7 on this platform yet either.  Hence,
no ACPI support.  The ACPI support in the latest BIOS seems very rough,
I think this is the first time they have ever implemented ACPI, so I
would not count on it working properly just yet.

> While were at it I have another question:  When running on battery the
> ethernet throughput drops to ~25Mbit/s.  After a bit of experimenting
> I found that this is connected to a BIOS entry about "CPU Power
> Saving Mode".  lspci shows that this changes "LnkCtl: ASPM L1
> Enabled" to "LnkCtl: ASPM L0s L1 Enabled".  Having this config
> option in the BIOS is inflexible.  IIRC there was an app in
> Windows which allows to configure it at runtime.  Do you
> know how to do it in Linux?

I do not konw anything about this.  Are you saying that Windows would
allow you to turn the throughput back up at the expense of battery life
through an application?  Do you know what that application is called and
where I could find it?

thanks,

greg k-h

Re: Samsung N130 ATA exception after 5min uptime -- Phoenix FailSafe issue?

[Johannes Stezenbach]

On Sat, Nov 28, 2009 at 04:17:45PM -0800, Greg KH wrote:
> On Sat, Nov 28, 2009 at 11:22:03PM +0100, Johannes Stezenbach wrote:
> > 
> > BTW, at 5min after boot it is 99% guaranteed that this ATA
> > exception will happen during the occasional fsck. That
> > doesn't feel right.
> 
> Well, I've never been doing a fsck at 5 minutes into boot, and neither do
> most Windows users :)

I've been through a lot of reboots with all the testing, and
the fsck took longer than 5min, and the ATA exception  struck.
fsck continued after the 30 second stall and succeeded.

> > but it would be better they'd support ACPI.
> > I mean if they have to support it for Windows 7 anyway, then
> > what's the point of not supporting it for other OSs?
> 
> Hey, no argument from me here, but I think the main issue is that they
> do not officially support Windows 7 on this platform yet either.  Hence,
> no ACPI support.  The ACPI support in the latest BIOS seems very rough,
> I think this is the first time they have ever implemented ACPI, so I
> would not count on it working properly just yet.

You can buy it officially with Windows 7 now, it seems to be fully supported.
http://www.samsung.com/us/consumer/office/mobile-computing/netbooks/NP-N130-KA04US/index.idx?pagetype=prd_detail&tab=support

> > While were at it I have another question:  When running on battery the
> > ethernet throughput drops to ~25Mbit/s.  After a bit of experimenting
> > I found that this is connected to a BIOS entry about "CPU Power
> > Saving Mode".  lspci shows that this changes "LnkCtl: ASPM L1
> > Enabled" to "LnkCtl: ASPM L0s L1 Enabled".  Having this config
> > option in the BIOS is inflexible.  IIRC there was an app in
> > Windows which allows to configure it at runtime.  Do you
> > know how to do it in Linux?
> 
> I do not konw anything about this.  Are you saying that Windows would
> allow you to turn the throughput back up at the expense of battery life
> through an application?  Do you know what that application is called and
> where I could find it?

I haven't actually tested throughput in Windows, but ISTR that there was
a Samsung app where you could configure various power saving features.
Might have been the "SAMSUNG Battery Manager".


Thanks,
Johannes

Re: Samsung N130 ATA exception after 5min uptime -- Phoenix FailSafe issue?

[Tejun Heo]

On 11/29/2009 09:51 AM, Johannes Stezenbach wrote:
> On Sat, Nov 28, 2009 at 04:17:45PM -0800, Greg KH wrote:
>> On Sat, Nov 28, 2009 at 11:22:03PM +0100, Johannes Stezenbach wrote:
>>>
>>> BTW, at 5min after boot it is 99% guaranteed that this ATA
>>> exception will happen during the occasional fsck. That
>>> doesn't feel right.
>>
>> Well, I've never been doing a fsck at 5 minutes into boot, and neither do
>> most Windows users :)
> 
> I've been through a lot of reboots with all the testing, and
> the fsck took longer than 5min, and the ATA exception  struck.
> fsck continued after the 30 second stall and succeeded.

The timeout will happen if the C state switching happens while ATA
command is in flight so unless there's heavy IO load, it's not very
likely to hit.  Another factor is that windows uses shorter IO timeout
(I think it's 7 secs or 15, I'm not sure) so it's gonna be less
noticeable when it happens.  Hmmm.... there were talks about
shortening the timeout.  Maybe it's about time we actually do that.

Thanks.

-- 
tejun

Re: Samsung N130 ATA exception after 5min uptime -- Phoenix FailSafe issue?

[Johannes Stezenbach]

On Mon, Nov 30, 2009 at 05:52:59PM +0900, Tejun Heo wrote:
> On 11/29/2009 09:51 AM, Johannes Stezenbach wrote:
> > On Sat, Nov 28, 2009 at 04:17:45PM -0800, Greg KH wrote:
> >> On Sat, Nov 28, 2009 at 11:22:03PM +0100, Johannes Stezenbach wrote:
> >>>
> >>> BTW, at 5min after boot it is 99% guaranteed that this ATA
> >>> exception will happen during the occasional fsck. That
> >>> doesn't feel right.
> >>
> >> Well, I've never been doing a fsck at 5 minutes into boot, and neither do
> >> most Windows users :)
> > 
> > I've been through a lot of reboots with all the testing, and
> > the fsck took longer than 5min, and the ATA exception  struck.
> > fsck continued after the 30 second stall and succeeded.
> 
> The timeout will happen if the C state switching happens while ATA
> command is in flight so unless there's heavy IO load, it's not very
> likely to hit.

I've booted with rdinit=/bin/sh (busybox sh in initramfs), so
nothing accesses the disk.  After 5min the C state switch
happens, but no ATA exception. I waited a few more miniutes
and then used dd if=/dev/sda of=/dev/null  -> ATA exception.
There is no way to escape it.


Johannes

Re: Samsung N130 ATA exception after 5min uptime -- Phoenix FailSafe issue?

[Tejun Heo]

Hello,

On 11/30/2009 07:21 PM, Johannes Stezenbach wrote:
> I've booted with rdinit=/bin/sh (busybox sh in initramfs), so
> nothing accesses the disk.  After 5min the C state switch
> happens, but no ATA exception. I waited a few more miniutes
> and then used dd if=/dev/sda of=/dev/null  -> ATA exception.
> There is no way to escape it.

Ah, okay, so whatever follows the switch times out.

I have no idea what to do about it at this point.  :-(

-- 
tejun

Re: Samsung N130 ATA exception after 5min uptime -- Phoenix FailSafe issue?

[Hans Werner]

> Betreff: Re: Samsung N130 ATA exception after 5min uptime -- Phoenix FailSafe issue?

> Hello,
> 
> On 11/30/2009 07:21 PM, Johannes Stezenbach wrote:
> > I've booted with rdinit=/bin/sh (busybox sh in initramfs), so
> > nothing accesses the disk.  After 5min the C state switch
> > happens, but no ATA exception. I waited a few more miniutes
> > and then used dd if=/dev/sda of=/dev/null  -> ATA exception.
> > There is no way to escape it.
> 
> Ah, okay, so whatever follows the switch times out.
> 
> I have no idea what to do about it at this point.  :-(
> 
> -- 
> tejun

Tejun,

testing in the Arch Linux Forums has shown that if one applies
a patch which you posted to the linux-ide ML on 2008-11-21
then the problem is no longer seen. Instead the kernel log shows
that a spurious IRQ was cleared.

[PATCH #upstraem-fixes] ata_piix: detect and clear spurious IRQs
http://marc.info/?l=linux-ide&m=122724081603679&w=2
http://bbs.archlinux.org/viewtopic.php?id=86454

What's the current status of this patch? Is it safe to use?
What does it tell us about the Samsung N130/140?

Regards,
Hans

-- 
Release early, release often.

GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Re: Samsung N130 ATA exception after 5min uptime -- Phoenix FailSafe issue?

[Johannes Stezenbach]

On Wed, Dec 30, 2009 at 01:04:28PM +0100, Hans Werner wrote:
> 
> testing in the Arch Linux Forums has shown that if one applies
> a patch which you posted to the linux-ide ML on 2008-11-21
> then the problem is no longer seen. Instead the kernel log shows
> that a spurious IRQ was cleared.
> 
> [PATCH #upstraem-fixes] ata_piix: detect and clear spurious IRQs
> http://marc.info/?l=linux-ide&m=122724081603679&w=2
> http://bbs.archlinux.org/viewtopic.php?id=86454
> 
> What's the current status of this patch? Is it safe to use?
> What does it tell us about the Samsung N130/140?

FWIW, I just tested a current git kernel (v2.6.33-rc2-268-g45d28b0)
with Tejun's patch applied on my N130.  The ATA exception and hang is
indeed gone, just "ata1: clearing spurious IRQ" is logged.

I've see Tejun's comment in
http://bugzilla.kernel.org/show_bug.cgi?id=14314
and I would like to add that the ATA irq is not shared.

 14:      43885          0   IO-APIC-edge      ata_piix
 15:          0          0   IO-APIC-edge      ata_piix


Thanks,
Johannes

Re: Samsung N130 ATA exception after 5min uptime -- Phoenix FailSafe issue?

[Tejun Heo]

Hello,

On 01/04/2010 07:11 AM, Johannes Stezenbach wrote:
> On Wed, Dec 30, 2009 at 01:04:28PM +0100, Hans Werner wrote:
>>
>> testing in the Arch Linux Forums has shown that if one applies
>> a patch which you posted to the linux-ide ML on 2008-11-21
>> then the problem is no longer seen. Instead the kernel log shows
>> that a spurious IRQ was cleared.
>>
>> [PATCH #upstraem-fixes] ata_piix: detect and clear spurious IRQs
>> http://marc.info/?l=linux-ide&m=122724081603679&w=2
>> http://bbs.archlinux.org/viewtopic.php?id=86454
>>
>> What's the current status of this patch? Is it safe to use?
>> What does it tell us about the Samsung N130/140?
> 
> FWIW, I just tested a current git kernel (v2.6.33-rc2-268-g45d28b0)
> with Tejun's patch applied on my N130.  The ATA exception and hang is
> indeed gone, just "ata1: clearing spurious IRQ" is logged.
> 
> I've see Tejun's comment in
> http://bugzilla.kernel.org/show_bug.cgi?id=14314
> and I would like to add that the ATA irq is not shared.
> 
>  14:      43885          0   IO-APIC-edge      ata_piix
>  15:          0          0   IO-APIC-edge      ata_piix

Can you please post that on bug#14314?  If the IRQ line indeed wasn't
shared, it might mean that the controller raised the IRQ line before
getting its internal state in order and the IRQ checking sequence
cleared the external IRQ status while leaving the internal pending bit
intact, which I've never heard of on piix and don't think is possible.
Hmmmm... given that the problem was dependent on BIOS on the other
model (is it the N130?), maybe the BIOS is doing something funny.  :-(
Anyways, please post full output of "cat /proc/interrupts" at the bz.

Thanks.

-- 
tejun

Re: Samsung N130 ATA exception after 5min uptime -- Phoenix FailSafe issue?

[Johannes Stezenbach]

On Mon, Jan 04, 2010 at 07:59:59AM +0900, Tejun Heo wrote:
> On 01/04/2010 07:11 AM, Johannes Stezenbach wrote:
> > 
> > FWIW, I just tested a current git kernel (v2.6.33-rc2-268-g45d28b0)
> > with Tejun's patch applied on my N130.  The ATA exception and hang is
> > indeed gone, just "ata1: clearing spurious IRQ" is logged.
> > 
> > I've see Tejun's comment in
> > http://bugzilla.kernel.org/show_bug.cgi?id=14314
> > and I would like to add that the ATA irq is not shared.
> > 
> >  14:      43885          0   IO-APIC-edge      ata_piix
> >  15:          0          0   IO-APIC-edge      ata_piix
> 
> Can you please post that on bug#14314?  If the IRQ line indeed wasn't
> shared, it might mean that the controller raised the IRQ line before
> getting its internal state in order and the IRQ checking sequence
> cleared the external IRQ status while leaving the internal pending bit
> intact, which I've never heard of on piix and don't think is possible.
> Hmmmm... given that the problem was dependent on BIOS on the other
> model (is it the N130?), maybe the BIOS is doing something funny.  :-(
> Anyways, please post full output of "cat /proc/interrupts" at the bz.

I've updated bug#14314.  It is certainly a BIOS issue, but the
"spurious IRQ" check deals way better with it than the previous
30sec hang waiting for timeout.  IMHO the patch should be merged
into mainline asap.  Or do you think it has any downside?


Thanks
Johannes

Re: Samsung N130 ATA exception after 5min uptime -- Phoenix FailSafe issue?

[Tejun Heo]

Hello,

On 01/04/2010 09:41 AM, Johannes Stezenbach wrote:
> I've updated bug#14314.  It is certainly a BIOS issue, but the
> "spurious IRQ" check deals way better with it than the previous
> 30sec hang waiting for timeout.  IMHO the patch should be merged
> into mainline asap.  Or do you think it has any downside?

The danger is that when the hardware is actually malfunctioning and
causing IRQ storm, the driver will tell the IRQ subsystem that the
IRQs aren't spurious.  This will bypass the IRQ storm detection logic
and lead to complete system lockup under such conditions.  Small
modification to the patch should remove that problem.  I'll post an
updated patch soon.

Thanks.

-- 
tejun