Re: [PATCH] [WATCHDOG] it8712f_wdt support for 16-bit timeout values, WDIOC_GETSTATUS

[Andrew Paprocki]

Sorry, try the attached file. I tried to send via IMAP draft, but I
suppose it is still not configured right.

Thanks,
-Andrew

On Thu, Feb 14, 2008 at 4:50 PM, Andrew Morton
<[EMAIL PROTECTED]> wrote:
> On Sun, 10 Feb 2008 22:11:15 -0500
>  "Andrew Paprocki" <[EMAIL PROTECTED]> wrote:
>
>  > This patch adds support for 16-bit watchdog timeout values which are
>  > available in chip revisions >= 0x08. Values <= 65535 are seconds precision,
>  > otherwise minutes precision is used up to a maximum value of 3932100. Added
>  > implementation for WDIOC_GETSTATUS which checks the WDT status bit in the
>  > WDT control register.
>  >
>  > Signed-off-by: Andrew Paprocki <[EMAIL PROTECTED]>
>  > ---
>  >   drivers/watchdog/it8712f_wdt.c |   82
>  > 
>  >   1 files changed, 66 insertions(+), 16 deletions(-)
>  >
>  > diff --git a/drivers/watchdog/it8712f_wdt.c 
> b/drivers/watchdog/it8712f_wdt.c
>  > index 1b6d7d1..803c699 100644
>  > --- a/drivers/watchdog/it8712f_wdt.c
>  > +++ b/drivers/watchdog/it8712f_wdt.c
>
>  The patch is wordwrapped, space-stuffed and has tabs replaced with spaces.
>  You hit the trifecta!
>
>  Please resend.  If you'd prefer to use an attachment rather than spending
>  half an hour wrestling your email client, feel free to do so ;)
>
>
From 23ce04e580f6fa2a24e247c3ad851de0f7e6a875 Mon Sep 17 00:00:00 2001
From: Andrew Paprocki <[EMAIL PROTECTED]>
Date: Thu, 14 Feb 2008 22:52:44 -0500
Subject: [PATCH] [WATCHDOG] it8712f_wdt support for 16-bit timeout values, 
WDIOC_GETSTATUS

This patch adds support for 16-bit watchdog timeout values which are
available in chip revisions >= 0x08. Values <= 65535 are seconds precision,
otherwise minutes precision is used up to a maximum value of 3932100. Added
implementation for WDIOC_GETSTATUS which checks the WDT status bit in the
WDT control register.

Signed-off-by: Andrew Paprocki <[EMAIL PROTECTED]>
---
 drivers/watchdog/it8712f_wdt.c |   78 ---
 1 files changed, 64 insertions(+), 14 deletions(-)

diff --git a/drivers/watchdog/it8712f_wdt.c b/drivers/watchdog/it8712f_wdt.c
index 1b6d7d1..1efcad3 100644
--- a/drivers/watchdog/it8712f_wdt.c
+++ b/drivers/watchdog/it8712f_wdt.c
@@ -7,7 +7,8 @@
  *
  * drivers/char/watchdog/scx200_wdt.c
  * drivers/hwmon/it87.c
- * IT8712F EC-LPC I/O Preliminary Specification 0.9.2.pdf
+ * IT8712F EC-LPC I/O Preliminary Specification 0.8.2
+ * IT8712F EC-LPC I/O Preliminary Specification 0.9.3
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License as
@@ -40,6 +41,7 @@ MODULE_DESCRIPTION("IT8712F Watchdog Driver");
 MODULE_LICENSE("GPL");
 MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR);

+static int max_units = 255;
 static int margin = 60;/* in seconds */
 module_param(margin, int, 0);
 MODULE_PARM_DESC(margin, "Watchdog margin in seconds");
@@ -51,6 +53,7 @@ MODULE_PARM_DESC(nowayout, "Disable watchdog shutdown on 
close");
 static struct semaphore it8712f_wdt_sem;
 static unsigned expect_close;
 static spinlock_t io_lock;
+static unsigned char revision;

 /* Dog Food address - We use the game port address */
 static unsigned short address;
@@ -108,6 +111,15 @@ superio_inw(int reg)
return val;
 }

+static void
+superio_outw(int val, int reg)
+{
+   outb(reg++, REG);
+   outb((val >> 8) & 0xff, VAL);
+   outb(reg, REG);
+   outb(val & 0xff, VAL);
+}
+
 static inline void
 superio_select(int ldn)
 {
@@ -143,15 +155,33 @@ static void
 it8712f_wdt_update_margin(void)
 {
int config = WDT_OUT_KRST | WDT_OUT_PWROK;
-
-   printk(KERN_INFO NAME ": timer margin %d seconds\n", margin);
-
-   /* The timeout register only has 8bits wide */
-   if (margin < 256)
-   config |= WDT_UNIT_SEC; /* else UNIT are MINUTES */
+   int units = margin;
+
+   /* Switch to minutes precision if the configured margin
+* value does not fit within the register width.
+*/
+   if (units <= max_units) {
+   config |= WDT_UNIT_SEC; /* else UNIT is MINUTES */
+   printk(KERN_INFO NAME ": timer margin %d seconds\n", units);
+   } else {
+   units /= 60;
+   printk(KERN_INFO NAME ": timer margin %d minutes\n", units);
+   }
superio_outb(config, WDT_CONFIG);

-   superio_outb((margin > 255) ? (margin / 60) : margin, WDT_TIMEOUT);
+   if (revision >= 0x08)
+   superio_outw(units, WDT_TIMEOUT);
+   else
+   superio_outb(units, WDT_TIMEOUT);
+}
+
+static int
+it8712f_wdt_get_status(void)
+{
+   if (superio_i

Re: [PATCH] [WATCHDOG] it8712f_wdt support for 16-bit timeout values, WDIOC_GETSTATUS

[Andrew Paprocki]

Sorry, try the attached file. I tried to send via IMAP draft, but I
suppose it is still not configured right.

Thanks,
-Andrew

On Thu, Feb 14, 2008 at 4:50 PM, Andrew Morton
[EMAIL PROTECTED] wrote:
 On Sun, 10 Feb 2008 22:11:15 -0500
  Andrew Paprocki [EMAIL PROTECTED] wrote:

   This patch adds support for 16-bit watchdog timeout values which are
   available in chip revisions = 0x08. Values = 65535 are seconds precision,
   otherwise minutes precision is used up to a maximum value of 3932100. Added
   implementation for WDIOC_GETSTATUS which checks the WDT status bit in the
   WDT control register.
  
   Signed-off-by: Andrew Paprocki [EMAIL PROTECTED]
   ---
 drivers/watchdog/it8712f_wdt.c |   82
   
 1 files changed, 66 insertions(+), 16 deletions(-)
  
   diff --git a/drivers/watchdog/it8712f_wdt.c 
 b/drivers/watchdog/it8712f_wdt.c
   index 1b6d7d1..803c699 100644
   --- a/drivers/watchdog/it8712f_wdt.c
   +++ b/drivers/watchdog/it8712f_wdt.c

  The patch is wordwrapped, space-stuffed and has tabs replaced with spaces.
  You hit the trifecta!

  Please resend.  If you'd prefer to use an attachment rather than spending
  half an hour wrestling your email client, feel free to do so ;)


From 23ce04e580f6fa2a24e247c3ad851de0f7e6a875 Mon Sep 17 00:00:00 2001
From: Andrew Paprocki [EMAIL PROTECTED]
Date: Thu, 14 Feb 2008 22:52:44 -0500
Subject: [PATCH] [WATCHDOG] it8712f_wdt support for 16-bit timeout values, 
WDIOC_GETSTATUS

This patch adds support for 16-bit watchdog timeout values which are
available in chip revisions = 0x08. Values = 65535 are seconds precision,
otherwise minutes precision is used up to a maximum value of 3932100. Added
implementation for WDIOC_GETSTATUS which checks the WDT status bit in the
WDT control register.

Signed-off-by: Andrew Paprocki [EMAIL PROTECTED]
---
 drivers/watchdog/it8712f_wdt.c |   78 ---
 1 files changed, 64 insertions(+), 14 deletions(-)

diff --git a/drivers/watchdog/it8712f_wdt.c b/drivers/watchdog/it8712f_wdt.c
index 1b6d7d1..1efcad3 100644
--- a/drivers/watchdog/it8712f_wdt.c
+++ b/drivers/watchdog/it8712f_wdt.c
@@ -7,7 +7,8 @@
  *
  * drivers/char/watchdog/scx200_wdt.c
  * drivers/hwmon/it87.c
- * IT8712F EC-LPC I/O Preliminary Specification 0.9.2.pdf
+ * IT8712F EC-LPC I/O Preliminary Specification 0.8.2
+ * IT8712F EC-LPC I/O Preliminary Specification 0.9.3
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License as
@@ -40,6 +41,7 @@ MODULE_DESCRIPTION(IT8712F Watchdog Driver);
 MODULE_LICENSE(GPL);
 MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR);

+static int max_units = 255;
 static int margin = 60;/* in seconds */
 module_param(margin, int, 0);
 MODULE_PARM_DESC(margin, Watchdog margin in seconds);
@@ -51,6 +53,7 @@ MODULE_PARM_DESC(nowayout, Disable watchdog shutdown on 
close);
 static struct semaphore it8712f_wdt_sem;
 static unsigned expect_close;
 static spinlock_t io_lock;
+static unsigned char revision;

 /* Dog Food address - We use the game port address */
 static unsigned short address;
@@ -108,6 +111,15 @@ superio_inw(int reg)
return val;
 }

+static void
+superio_outw(int val, int reg)
+{
+   outb(reg++, REG);
+   outb((val  8)  0xff, VAL);
+   outb(reg, REG);
+   outb(val  0xff, VAL);
+}
+
 static inline void
 superio_select(int ldn)
 {
@@ -143,15 +155,33 @@ static void
 it8712f_wdt_update_margin(void)
 {
int config = WDT_OUT_KRST | WDT_OUT_PWROK;
-
-   printk(KERN_INFO NAME : timer margin %d seconds\n, margin);
-
-   /* The timeout register only has 8bits wide */
-   if (margin  256)
-   config |= WDT_UNIT_SEC; /* else UNIT are MINUTES */
+   int units = margin;
+
+   /* Switch to minutes precision if the configured margin
+* value does not fit within the register width.
+*/
+   if (units = max_units) {
+   config |= WDT_UNIT_SEC; /* else UNIT is MINUTES */
+   printk(KERN_INFO NAME : timer margin %d seconds\n, units);
+   } else {
+   units /= 60;
+   printk(KERN_INFO NAME : timer margin %d minutes\n, units);
+   }
superio_outb(config, WDT_CONFIG);

-   superio_outb((margin  255) ? (margin / 60) : margin, WDT_TIMEOUT);
+   if (revision = 0x08)
+   superio_outw(units, WDT_TIMEOUT);
+   else
+   superio_outb(units, WDT_TIMEOUT);
+}
+
+static int
+it8712f_wdt_get_status(void)
+{
+   if (superio_inb(WDT_CONTROL)  0x01)
+   return WDIOF_CARDRESET;
+   else
+   return 0;
 }

 static void
@@ -234,7 +264,7 @@ it8712f_wdt_ioctl(struct inode *inode, struct file *file,
.firmware_version = 1,
.options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
};
-   int new_margin;
+   int value;

switch

[PATCH] [WATCHDOG] it8712f_wdt support for 16-bit timeout values, WDIOC_GETSTATUS

[Andrew Paprocki]

This patch adds support for 16-bit watchdog timeout values which are
available in chip revisions >= 0x08. Values <= 65535 are seconds precision,
otherwise minutes precision is used up to a maximum value of 3932100. Added
implementation for WDIOC_GETSTATUS which checks the WDT status bit in the
WDT control register.

Signed-off-by: Andrew Paprocki <[EMAIL PROTECTED]>
---
  drivers/watchdog/it8712f_wdt.c |   82

  1 files changed, 66 insertions(+), 16 deletions(-)

diff --git a/drivers/watchdog/it8712f_wdt.c b/drivers/watchdog/it8712f_wdt.c
index 1b6d7d1..803c699 100644
--- a/drivers/watchdog/it8712f_wdt.c
+++ b/drivers/watchdog/it8712f_wdt.c
@@ -7,7 +7,8 @@
   *
   *drivers/char/watchdog/scx200_wdt.c
   *drivers/hwmon/it87.c
- * IT8712F EC-LPC I/O Preliminary Specification 0.9.2.pdf
+ * IT8712F EC-LPC I/O Preliminary Specification 0.8.2
+ * IT8712F EC-LPC I/O Preliminary Specification 0.9.3
   *
   *This program is free software; you can redistribute it and/or
   *modify it under the terms of the GNU General Public License as
@@ -40,6 +41,7 @@ MODULE_DESCRIPTION("IT8712F Watchdog Driver");
  MODULE_LICENSE("GPL");
  MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR);

+static int max_units = 255;
  static int margin = 60;   /* in seconds */
  module_param(margin, int, 0);
  MODULE_PARM_DESC(margin, "Watchdog margin in seconds");
@@ -51,6 +53,7 @@ MODULE_PARM_DESC(nowayout, "Disable watchdog shutdown
on close");
  static struct semaphore it8712f_wdt_sem;
  static unsigned expect_close;
  static spinlock_t io_lock;
+static unsigned char revision;

  /* Dog Food address - We use the game port address */
  static unsigned short address;
@@ -108,6 +111,15 @@ superio_inw(int reg)
return val;
  }

+static void
+superio_outw(int val, int reg)
+{
+outb(reg++, REG);
+outb((val >> 8) & 0xff, VAL);
+outb(reg, REG);
+outb(val & 0xff, VAL);
+}
+
  static inline void
  superio_select(int ldn)
  {
@@ -143,15 +155,33 @@ static void
  it8712f_wdt_update_margin(void)
  {
int config = WDT_OUT_KRST | WDT_OUT_PWROK;
+int units = margin;
+
+/* Switch to minutes precision if the configured margin
+ * value does not fit within the register width.
+ */
+if (units <= max_units) {
+config |= WDT_UNIT_SEC; /* else UNIT is MINUTES */
+printk(KERN_INFO NAME ": timer margin %d seconds\n",
units);
+} else {
+units /= 60;
+printk(KERN_INFO NAME ": timer margin %d minutes\n",
units);
+}
+superio_outb(config, WDT_CONFIG);
+
+if (revision >= 0x08)
+superio_outw(units, WDT_TIMEOUT);
+else
+superio_outb(units, WDT_TIMEOUT);
+}

-   printk(KERN_INFO NAME ": timer margin %d seconds\n", margin);
-
-   /* The timeout register only has 8bits wide */
-   if (margin < 256)
-   config |= WDT_UNIT_SEC; /* else UNIT are MINUTES */
-   superio_outb(config, WDT_CONFIG);
-
-   superio_outb((margin > 255) ? (margin / 60) : margin, WDT_TIMEOUT);
+static int
+it8712f_wdt_get_status(void)
+{
+if (superio_inb(WDT_CONTROL) & 0x01)
+return WDIOF_CARDRESET;
+else
+return 0;
  }

  static void
@@ -234,7 +264,7 @@ it8712f_wdt_ioctl(struct inode *inode, struct file
*file,
.firmware_version = 1,
.options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
};
-   int new_margin;
+   int value;

switch (cmd) {
default:
@@ -244,17 +274,27 @@ it8712f_wdt_ioctl(struct inode *inode, struct file
*file,
return -EFAULT;
return 0;
case WDIOC_GETSTATUS:
+superio_enter();
+superio_select(LDN_GPIO);
+
+value = it8712f_wdt_get_status();
+
+superio_exit();
+
+   return put_user(value, p);
case WDIOC_GETBOOTSTATUS:
-   return put_user(0, p);
+return put_user(0, p);
case WDIOC_KEEPALIVE:
it8712f_wdt_ping();
return 0;
case WDIOC_SETTIMEOUT:
-   if (get_user(new_margin, p))
+   if (get_user(value, p))
return -EFAULT;
-   if (new_margin < 1)
+   if (value < 1)
return -EINVAL;
-   margin = new_margin;
+if (value > (max_units * 60))
+return -EINVAL;
+   margin = value;
superio_enter();
superio_select(LDN_GPIO);

@@ -262,6 +302,7 @@ it8712f_wdt_ioctl(struct inode *inode, struct file
*file,

superio_exit();
it87

Re: I/O collisions w/ hwmon/it87.c and watchdog/it8712f_wdt.c? (Super I/O chips in general..)

[Andrew Paprocki]

Does it make sense to use the drivers/mfd directory for Super I/O
chips then? Is there any problem with having other hwmon, watchdog,
etc depend on drivers/mfd? Should this kind of setup for platform
devices be documented in the driver-model?

-Andrew

On Feb 10, 2008 6:05 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> > Since these chips touch many different parts of traditionally separate
> > driver areas, how should the drivers be structured so that they can
> > all talk to the chip? Should the low level communications routines for
> > the chip live in a library which all the drivers could use?
>
> Probably yes. And that if possible should manage all the locking. Thats
> roughly how the majority of drivers do it. Some export the lock from base
> code and inline the accessors depending how complex it is.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

I/O collisions w/ hwmon/it87.c and watchdog/it8712f_wdt.c? (Super I/O chips in general..)

[Andrew Paprocki]

I'm interested in expanding the current support for the it87 Super I/O
chip to provide access to more of its capabilities. I started by
looking at two existing drivers which talk to different parts of the
chip. Maybe I'm missing something, but what guarantees that both of
these drivers won't attempt to talk to the chip at the same time?

The watchdog/it8712f_wdt.c driver has an internal spinlock, the
hwmon/it87.c driver doesn't, and I don't see how a lock could be
shared across both unless it is taken care of at a lower level that
I'm not aware of. You can see that code is essentially copied between
the two files to talk to the chip.

This brings me to a more general question regarding SuperI/O chips.
Since these chips touch many different parts of traditionally separate
driver areas, how should the drivers be structured so that they can
all talk to the chip? Should the low level communications routines for
the chip live in a library which all the drivers could use? Should all
of the created devices live inside one file? (e.g. platform/it87.c
instead of hwmon, watchdog, etc)

Thanks,
-Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

I/O collisions w/ hwmon/it87.c and watchdog/it8712f_wdt.c? (Super I/O chips in general..)

[Andrew Paprocki]

I'm interested in expanding the current support for the it87 Super I/O
chip to provide access to more of its capabilities. I started by
looking at two existing drivers which talk to different parts of the
chip. Maybe I'm missing something, but what guarantees that both of
these drivers won't attempt to talk to the chip at the same time?

The watchdog/it8712f_wdt.c driver has an internal spinlock, the
hwmon/it87.c driver doesn't, and I don't see how a lock could be
shared across both unless it is taken care of at a lower level that
I'm not aware of. You can see that code is essentially copied between
the two files to talk to the chip.

This brings me to a more general question regarding SuperI/O chips.
Since these chips touch many different parts of traditionally separate
driver areas, how should the drivers be structured so that they can
all talk to the chip? Should the low level communications routines for
the chip live in a library which all the drivers could use? Should all
of the created devices live inside one file? (e.g. platform/it87.c
instead of hwmon, watchdog, etc)

Thanks,
-Andrew
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: I/O collisions w/ hwmon/it87.c and watchdog/it8712f_wdt.c? (Super I/O chips in general..)

[Andrew Paprocki]

Does it make sense to use the drivers/mfd directory for Super I/O
chips then? Is there any problem with having other hwmon, watchdog,
etc depend on drivers/mfd? Should this kind of setup for platform
devices be documented in the driver-model?

-Andrew

On Feb 10, 2008 6:05 PM, Alan Cox [EMAIL PROTECTED] wrote:
  Since these chips touch many different parts of traditionally separate
  driver areas, how should the drivers be structured so that they can
  all talk to the chip? Should the low level communications routines for
  the chip live in a library which all the drivers could use?

 Probably yes. And that if possible should manage all the locking. Thats
 roughly how the majority of drivers do it. Some export the lock from base
 code and inline the accessors depending how complex it is.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] [WATCHDOG] it8712f_wdt support for 16-bit timeout values, WDIOC_GETSTATUS

[Andrew Paprocki]

This patch adds support for 16-bit watchdog timeout values which are
available in chip revisions = 0x08. Values = 65535 are seconds precision,
otherwise minutes precision is used up to a maximum value of 3932100. Added
implementation for WDIOC_GETSTATUS which checks the WDT status bit in the
WDT control register.

Signed-off-by: Andrew Paprocki [EMAIL PROTECTED]
---
  drivers/watchdog/it8712f_wdt.c |   82

  1 files changed, 66 insertions(+), 16 deletions(-)

diff --git a/drivers/watchdog/it8712f_wdt.c b/drivers/watchdog/it8712f_wdt.c
index 1b6d7d1..803c699 100644
--- a/drivers/watchdog/it8712f_wdt.c
+++ b/drivers/watchdog/it8712f_wdt.c
@@ -7,7 +7,8 @@
   *
   *drivers/char/watchdog/scx200_wdt.c
   *drivers/hwmon/it87.c
- * IT8712F EC-LPC I/O Preliminary Specification 0.9.2.pdf
+ * IT8712F EC-LPC I/O Preliminary Specification 0.8.2
+ * IT8712F EC-LPC I/O Preliminary Specification 0.9.3
   *
   *This program is free software; you can redistribute it and/or
   *modify it under the terms of the GNU General Public License as
@@ -40,6 +41,7 @@ MODULE_DESCRIPTION(IT8712F Watchdog Driver);
  MODULE_LICENSE(GPL);
  MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR);

+static int max_units = 255;
  static int margin = 60;   /* in seconds */
  module_param(margin, int, 0);
  MODULE_PARM_DESC(margin, Watchdog margin in seconds);
@@ -51,6 +53,7 @@ MODULE_PARM_DESC(nowayout, Disable watchdog shutdown
on close);
  static struct semaphore it8712f_wdt_sem;
  static unsigned expect_close;
  static spinlock_t io_lock;
+static unsigned char revision;

  /* Dog Food address - We use the game port address */
  static unsigned short address;
@@ -108,6 +111,15 @@ superio_inw(int reg)
return val;
  }

+static void
+superio_outw(int val, int reg)
+{
+outb(reg++, REG);
+outb((val  8)  0xff, VAL);
+outb(reg, REG);
+outb(val  0xff, VAL);
+}
+
  static inline void
  superio_select(int ldn)
  {
@@ -143,15 +155,33 @@ static void
  it8712f_wdt_update_margin(void)
  {
int config = WDT_OUT_KRST | WDT_OUT_PWROK;
+int units = margin;
+
+/* Switch to minutes precision if the configured margin
+ * value does not fit within the register width.
+ */
+if (units = max_units) {
+config |= WDT_UNIT_SEC; /* else UNIT is MINUTES */
+printk(KERN_INFO NAME : timer margin %d seconds\n,
units);
+} else {
+units /= 60;
+printk(KERN_INFO NAME : timer margin %d minutes\n,
units);
+}
+superio_outb(config, WDT_CONFIG);
+
+if (revision = 0x08)
+superio_outw(units, WDT_TIMEOUT);
+else
+superio_outb(units, WDT_TIMEOUT);
+}

-   printk(KERN_INFO NAME : timer margin %d seconds\n, margin);
-
-   /* The timeout register only has 8bits wide */
-   if (margin  256)
-   config |= WDT_UNIT_SEC; /* else UNIT are MINUTES */
-   superio_outb(config, WDT_CONFIG);
-
-   superio_outb((margin  255) ? (margin / 60) : margin, WDT_TIMEOUT);
+static int
+it8712f_wdt_get_status(void)
+{
+if (superio_inb(WDT_CONTROL)  0x01)
+return WDIOF_CARDRESET;
+else
+return 0;
  }

  static void
@@ -234,7 +264,7 @@ it8712f_wdt_ioctl(struct inode *inode, struct file
*file,
.firmware_version = 1,
.options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
};
-   int new_margin;
+   int value;

switch (cmd) {
default:
@@ -244,17 +274,27 @@ it8712f_wdt_ioctl(struct inode *inode, struct file
*file,
return -EFAULT;
return 0;
case WDIOC_GETSTATUS:
+superio_enter();
+superio_select(LDN_GPIO);
+
+value = it8712f_wdt_get_status();
+
+superio_exit();
+
+   return put_user(value, p);
case WDIOC_GETBOOTSTATUS:
-   return put_user(0, p);
+return put_user(0, p);
case WDIOC_KEEPALIVE:
it8712f_wdt_ping();
return 0;
case WDIOC_SETTIMEOUT:
-   if (get_user(new_margin, p))
+   if (get_user(value, p))
return -EFAULT;
-   if (new_margin  1)
+   if (value  1)
return -EINVAL;
-   margin = new_margin;
+if (value  (max_units * 60))
+return -EINVAL;
+   margin = value;
superio_enter();
superio_select(LDN_GPIO);

@@ -262,6 +302,7 @@ it8712f_wdt_ioctl(struct inode *inode, struct file
*file,

superio_exit();
it8712f_wdt_ping();
+/* Fall through */
case WDIOC_GETTIMEOUT:
if (put_user(margin, p))
return -EFAULT;
@@ -336,9

Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs

[Andrew Paprocki]

Thomas,

I haven't found a good way to capture the SysRq output for this. I
found that when it locks up at boot time, even SysRq is unresponsive.
I don't have another way of getting console on the machine right now
to get the output off of it. I have since upgraded to 2.6.24 and the
problem still persists.

Another interesting twist though.. I just rebuilt my kernel with
ARCH=x86_64 and HPET works perfectly. So this only appears to break
when in 32-bit mode. For some reason it picks tsc at boot time, but if
I install hpet afterwards under x86_64 it no longer hangs when I run
'sleep 1'. Does that shed any more light on the problem?

Thanks,
-Andrew

# uname -a
Linux am2 2.6.24 #7 Sat Feb 9 18:06:50 EST 2008 x86_64 GNU/Linux
# dmesg | egrep -i clock\|hpet
ACPI: HPET 3DFE7780, 0038 (r1 RS690  AWRDACPI 42302E31 AWRD   98)
ACPI: HPET id: 0x10b9a201 base: 0xfed0
hpet clockevent registered
TSC calibrated against HPET
hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0
hpet0: 4 32-bit timers, 14318180 Hz
Time: tsc clocksource has been installed.
Real Time Clock Driver v1.12ac
hpet_resources: 0xfed0 is busy
# echo -n hpet >
/sys/devices/system/clocksource/clocksource0/current_clocksource
# dmesg | tail -1
Time: hpet clocksource has been installed.
# time sleep 1

real0m1.001s
user0m0.000s
sys 0m0.000s

On Jan 18, 2008 5:26 AM, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Wed, 16 Jan 2008, Andrew Paprocki wrote:
>
> > I applied the patch and I am still locking up after
> > Time: hpet clocksource has been installed.
>
> That was expected :)
>
> > I rebooted with "clocksource=tsc" to get the logs of the trace which
> > was added. I'm assuming the grep below gets all the interesting parts.
> > I enabled the HPET character device as mentioned before, which is why
> > the hpet0 lines appear now.
> >
> > # dmesg | egrep -i "(hpet|time|clock)"
> > ACPI: HPET 37FE7400, 0038 (r1 RS690  AWRDACPI 42302E31 AWRD   98)
> > ATI board detected. Disabling timer routing over 8254.
> > ACPI: PM-Timer IO Port: 0x4008
> > ACPI: HPET id: 0x10b9a201 base: 0xfed0
> > Kernel command line: vga=0x31a root=/dev/sda1 ro clocksource=tsc
> > HPET check: t1=5 t2=1139 s=56226339975 n=56226539985
>
> Ok, the counter works when we initialize the HPET.
>
> t2-t1 = 1134 ticks ~= 79us
> s-n = 200010 ~= 2525MHz --> That should be the frequency of your CPU.
>
> > Jan 16 14:44:43 am2 kernel: Call Trace:
> > Jan 16 14:44:48 am2 kernel:  [] enqueue_hrtimer+0xd7/0xe2
> > Jan 16 14:44:48 am2 kernel:  [] hrtimer_start+0xe8/0xf4
> > Jan 16 14:44:48 am2 kernel:  [] do_nanosleep+0x48/0x73
> > Jan 16 14:44:48 am2 kernel:  [] 
> > hrtimer_nanosleep_restart+0x34/0xa1
> > Jan 16 14:44:48 am2 kernel:  [] hrtimer_wakeup+0x0/0x18
> > Jan 16 14:44:48 am2 kernel:  [] sys_restart_syscall+0xe/0xf
> > Jan 16 14:44:48 am2 kernel:  [] sysenter_past_esp+0x5f/0x85
>
> When the system is hung, can you please hit SysRq-Q wait a bit and hit
> SysRq-Q again. Please provide the output.
>
> Thanks,
> tglx
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs

[Andrew Paprocki]

Thomas,

I haven't found a good way to capture the SysRq output for this. I
found that when it locks up at boot time, even SysRq is unresponsive.
I don't have another way of getting console on the machine right now
to get the output off of it. I have since upgraded to 2.6.24 and the
problem still persists.

Another interesting twist though.. I just rebuilt my kernel with
ARCH=x86_64 and HPET works perfectly. So this only appears to break
when in 32-bit mode. For some reason it picks tsc at boot time, but if
I install hpet afterwards under x86_64 it no longer hangs when I run
'sleep 1'. Does that shed any more light on the problem?

Thanks,
-Andrew

# uname -a
Linux am2 2.6.24 #7 Sat Feb 9 18:06:50 EST 2008 x86_64 GNU/Linux
# dmesg | egrep -i clock\|hpet
ACPI: HPET 3DFE7780, 0038 (r1 RS690  AWRDACPI 42302E31 AWRD   98)
ACPI: HPET id: 0x10b9a201 base: 0xfed0
hpet clockevent registered
TSC calibrated against HPET
hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0
hpet0: 4 32-bit timers, 14318180 Hz
Time: tsc clocksource has been installed.
Real Time Clock Driver v1.12ac
hpet_resources: 0xfed0 is busy
# echo -n hpet 
/sys/devices/system/clocksource/clocksource0/current_clocksource
# dmesg | tail -1
Time: hpet clocksource has been installed.
# time sleep 1

real0m1.001s
user0m0.000s
sys 0m0.000s

On Jan 18, 2008 5:26 AM, Thomas Gleixner [EMAIL PROTECTED] wrote:
 On Wed, 16 Jan 2008, Andrew Paprocki wrote:

  I applied the patch and I am still locking up after
  Time: hpet clocksource has been installed.

 That was expected :)

  I rebooted with clocksource=tsc to get the logs of the trace which
  was added. I'm assuming the grep below gets all the interesting parts.
  I enabled the HPET character device as mentioned before, which is why
  the hpet0 lines appear now.
 
  # dmesg | egrep -i (hpet|time|clock)
  ACPI: HPET 37FE7400, 0038 (r1 RS690  AWRDACPI 42302E31 AWRD   98)
  ATI board detected. Disabling timer routing over 8254.
  ACPI: PM-Timer IO Port: 0x4008
  ACPI: HPET id: 0x10b9a201 base: 0xfed0
  Kernel command line: vga=0x31a root=/dev/sda1 ro clocksource=tsc
  HPET check: t1=5 t2=1139 s=56226339975 n=56226539985

 Ok, the counter works when we initialize the HPET.

 t2-t1 = 1134 ticks ~= 79us
 s-n = 200010 ~= 2525MHz -- That should be the frequency of your CPU.

  Jan 16 14:44:43 am2 kernel: Call Trace:
  Jan 16 14:44:48 am2 kernel:  [c01371be] enqueue_hrtimer+0xd7/0xe2
  Jan 16 14:44:48 am2 kernel:  [c0137803] hrtimer_start+0xe8/0xf4
  Jan 16 14:44:48 am2 kernel:  [c03ac8d3] do_nanosleep+0x48/0x73
  Jan 16 14:44:48 am2 kernel:  [c03ac932] 
  hrtimer_nanosleep_restart+0x34/0xa1
  Jan 16 14:44:48 am2 kernel:  [c013735d] hrtimer_wakeup+0x0/0x18
  Jan 16 14:44:48 am2 kernel:  [c012e837] sys_restart_syscall+0xe/0xf
  Jan 16 14:44:48 am2 kernel:  [c0103d0a] sysenter_past_esp+0x5f/0x85

 When the system is hung, can you please hit SysRq-Q wait a bit and hit
 SysRq-Q again. Please provide the output.

 Thanks,
 tglx


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: lxfb is not changing modes, no errors/information printing out

[Andrew Paprocki]

On Jan 27, 2008 2:28 PM, Jordan Crouse <[EMAIL PROTECTED]> wrote:
> On 27/01/08 13:45 -0500, Andrew Paprocki wrote:
> > Using 2.6.24, I can't get my Geode LX (LX800 CPU) to boot in anything
> > other than the default 80x25 console even though lxfb appears to be
> > loading normally. This device doesn't work with the VESA fb either
> > when I request "vga=0x31a". All the other boards I have display a
> > 1280x1024 console on my monitor. Are my kernel parameters wrong in
> > some way? I tried "video=lxfb:" with and without "vga=0x31a".
> > The driver is compiled into the kernel -- I am not using modules.
>
> Can you change the mode after you have booted with 'fbset'?

Two answers to this I just found out..

This is a system I installed BusyBox 1.8.0 on, and running 'fbset
1280x1024-75' does nothing. I copied over the real fbset binary from
my Debian install and when I ran it the same way, it worked perfectly.
So, yes, it appears that it is possible to change it after the fact,
but for some reason BusyBox can't do it. The only problem then appears
to be setting the fb mode from the boot line.

BusyBox 1.8.0 binary:

# fbset 1280x1024-75

mode "1280x1024-75"
# D: 134.880 MHz, H: 79.905 kHz, V: 74.958 Hz
geometry 1280 1024 1280 3264 8
timings 7414 232 64 38 1 112 3
accel true
rgba 8/0,8/0,8/0,0/0
endmode
(nothing happens)

Debian binary:

# /tmp/fbset -v 1280x1024-60
Linux Frame Buffer Device Configuration Version 2.1 (23/06/1999)
(C) Copyright 1995-1999 by Geert Uytterhoeven

Opening frame buffer device `/dev/fb0'
Reading mode database from file `/etc/fb.modes'
Using video mode `1280x1024-60'
Setting video mode to `/dev/fb0'
(works)

Thanks,
-Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

lxfb is not changing modes, no errors/information printing out

[Andrew Paprocki]

Using 2.6.24, I can't get my Geode LX (LX800 CPU) to boot in anything
other than the default 80x25 console even though lxfb appears to be
loading normally. This device doesn't work with the VESA fb either
when I request "vga=0x31a". All the other boards I have display a
1280x1024 console on my monitor. Are my kernel parameters wrong in
some way? I tried "video=lxfb:" with and without "vga=0x31a".
The driver is compiled into the kernel -- I am not using modules.

Also, a side note.. blanking on this display doesn't seem to work
properly. When the screen would normally blank after a timeout, a thin
~20px width vertical black strip appears on the left-hand side of the
screen, but the rest of the display area remains showing whatever
contents were on the screen when the blank was triggered. Hitting a
key goes back to displaying the current fb contents like you would
expect.

Thanks,
-Andrew

Relevant dmesg info:

Kernel command line: video=lxfb:1280x1024-60 vga=0x31a root=/dev/hda1
Console: colour dummy device 80x25
console [tty0] enabled
lxfb :00:01.1: 8192 KB of video memory at 0xee00
Console: switching to colour frame buffer device 80x30
fb0: Geode LX frame buffer device

# lspci -vvnn -s 00:01.1
00:01.1 VGA compatible controller [0300]: Advanced Micro Devices [AMD]
Geode LX Video [1022:2081] (prog-if 00 [VGA])
Subsystem: Advanced Micro Devices [AMD] Geode LX Video [1022:2081]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- SERR- http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

lxfb is not changing modes, no errors/information printing out

[Andrew Paprocki]

Using 2.6.24, I can't get my Geode LX (LX800 CPU) to boot in anything
other than the default 80x25 console even though lxfb appears to be
loading normally. This device doesn't work with the VESA fb either
when I request vga=0x31a. All the other boards I have display a
1280x1024 console on my monitor. Are my kernel parameters wrong in
some way? I tried video=lxfb:mode with and without vga=0x31a.
The driver is compiled into the kernel -- I am not using modules.

Also, a side note.. blanking on this display doesn't seem to work
properly. When the screen would normally blank after a timeout, a thin
~20px width vertical black strip appears on the left-hand side of the
screen, but the rest of the display area remains showing whatever
contents were on the screen when the blank was triggered. Hitting a
key goes back to displaying the current fb contents like you would
expect.

Thanks,
-Andrew

Relevant dmesg info:

Kernel command line: video=lxfb:1280x1024-60 vga=0x31a root=/dev/hda1
Console: colour dummy device 80x25
console [tty0] enabled
lxfb :00:01.1: 8192 KB of video memory at 0xee00
Console: switching to colour frame buffer device 80x30
fb0: Geode LX frame buffer device

# lspci -vvnn -s 00:01.1
00:01.1 VGA compatible controller [0300]: Advanced Micro Devices [AMD]
Geode LX Video [1022:2081] (prog-if 00 [VGA])
Subsystem: Advanced Micro Devices [AMD] Geode LX Video [1022:2081]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- TAbort- MAbort- SERR- PERR-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 11
Region 0: Memory at ee00 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at efff4000 (32-bit, non-prefetchable) [size=16K]
Region 2: Memory at efff (32-bit, non-prefetchable) [size=16K]
Region 3: Memory at effec000 (32-bit, non-prefetchable) [size=16K]
Region 4: Memory at effe8000 (32-bit, non-prefetchable) [size=16K]
00: 22 10 81 20 07 00 20 02 00 00 00 03 08 00 00 00
10: 00 00 00 ee 00 40 ff ef 00 00 ff ef 00 c0 fe ef
20: 00 80 fe ef 00 00 00 00 00 00 00 00 22 10 81 20
30: 00 00 00 00 00 00 00 00 00 00 00 00 07 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: d0 03 00 00 c0 03 00 00 00 00 0a 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

# grep CONFIG_FB.*=y .config
CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_DEFERRED_IO=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
CONFIG_FB_GEODE=y
CONFIG_FB_GEODE_LX=y

# cat /sys/class/graphics/fb0/name
Geode LX
# cat /sys/class/graphics/fb0/modes
U:640x480p-63
# cat /sys/class/graphics/fb0/state
0
# cat /sys/class/graphics/fb0/virtual_size
640,480
# cat /sys/class/graphics/fb0/stride
1280
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: lxfb is not changing modes, no errors/information printing out

[Andrew Paprocki]

On Jan 27, 2008 2:28 PM, Jordan Crouse [EMAIL PROTECTED] wrote:
 On 27/01/08 13:45 -0500, Andrew Paprocki wrote:
  Using 2.6.24, I can't get my Geode LX (LX800 CPU) to boot in anything
  other than the default 80x25 console even though lxfb appears to be
  loading normally. This device doesn't work with the VESA fb either
  when I request vga=0x31a. All the other boards I have display a
  1280x1024 console on my monitor. Are my kernel parameters wrong in
  some way? I tried video=lxfb:mode with and without vga=0x31a.
  The driver is compiled into the kernel -- I am not using modules.

 Can you change the mode after you have booted with 'fbset'?

Two answers to this I just found out..

This is a system I installed BusyBox 1.8.0 on, and running 'fbset
1280x1024-75' does nothing. I copied over the real fbset binary from
my Debian install and when I ran it the same way, it worked perfectly.
So, yes, it appears that it is possible to change it after the fact,
but for some reason BusyBox can't do it. The only problem then appears
to be setting the fb mode from the boot line.

BusyBox 1.8.0 binary:

# fbset 1280x1024-75

mode 1280x1024-75
# D: 134.880 MHz, H: 79.905 kHz, V: 74.958 Hz
geometry 1280 1024 1280 3264 8
timings 7414 232 64 38 1 112 3
accel true
rgba 8/0,8/0,8/0,0/0
endmode
(nothing happens)

Debian binary:

# /tmp/fbset -v 1280x1024-60
Linux Frame Buffer Device Configuration Version 2.1 (23/06/1999)
(C) Copyright 1995-1999 by Geert Uytterhoeven

Opening frame buffer device `/dev/fb0'
Reading mode database from file `/etc/fb.modes'
Using video mode `1280x1024-60'
Setting video mode to `/dev/fb0'
(works)

Thanks,
-Andrew
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs

[Andrew Paprocki]

I applied the patch and I am still locking up after
Time: hpet clocksource has been installed.

I rebooted with "clocksource=tsc" to get the logs of the trace which
was added. I'm assuming the grep below gets all the interesting parts.
I enabled the HPET character device as mentioned before, which is why
the hpet0 lines appear now.

# dmesg | egrep -i "(hpet|time|clock)"
ACPI: HPET 37FE7400, 0038 (r1 RS690  AWRDACPI 42302E31 AWRD   98)
ATI board detected. Disabling timer routing over 8254.
ACPI: PM-Timer IO Port: 0x4008
ACPI: HPET id: 0x10b9a201 base: 0xfed0
Kernel command line: vga=0x31a root=/dev/sda1 ro clocksource=tsc
HPET check: t1=5 t2=1139 s=56226339975 n=56226539985
hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0
hpet0: 4 32-bit timers, 14318180 Hz
Calibrating delay using timer specific routine.. 4927.58 BogoMIPS (lpj=9855168)
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
Time: tsc clocksource has been installed.
PCI: Setting latency timer of device :00:06.0 to 64
Real Time Clock Driver v1.12ac
hpet_resources: 0xfed0 is busy
Clocksource tsc unstable (delta = 459979812 ns)
Software Watchdog Timer: 0.07 initialized. soft_noboot=0
soft_margin=60 sec (nowayout= 0)
PCI: Setting latency timer of device :02:00.0 to 64

I ran a 'sleep 1', which hung as expected when I installed hpet as the
clocksource via /sys. I dumped the sysrq trace showing where it was
hung:

Jan 16 14:44:48 am2 kernel: sleep S f582df68 0  2205   2155
Jan 16 14:44:48 am2 kernel:f582df50 0086 c1706e80 f582df68
c1706f04 c1706e78  c01371be
Jan 16 14:44:48 am2 kernel:c17f8ab0 c17f8bf4 c1709a40 
f7077200 0286 c0137803 0001
Jan 16 14:44:43 am2 kernel:c1706e78  0286 f582df68
 f582c020 f582c000 c03ac8d3
Jan 16 14:44:43 am2 kernel: Call Trace:
Jan 16 14:44:48 am2 kernel:  [] enqueue_hrtimer+0xd7/0xe2
Jan 16 14:44:48 am2 kernel:  [] hrtimer_start+0xe8/0xf4
Jan 16 14:44:48 am2 kernel:  [] do_nanosleep+0x48/0x73
Jan 16 14:44:48 am2 kernel:  [] hrtimer_nanosleep_restart+0x34/0xa1
Jan 16 14:44:48 am2 kernel:  [] hrtimer_wakeup+0x0/0x18
Jan 16 14:44:48 am2 kernel:  [] sys_restart_syscall+0xe/0xf
Jan 16 14:44:48 am2 kernel:  [] sysenter_past_esp+0x5f/0x85

My 'cron' and 'atd' processes were also hung with this exact stack in
'enqueue_hrtimer'.

Thanks,
-Andrew

On Jan 16, 2008 10:21 AM, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> > > The hint is in the original report:
> > >
> > > Clocksource tsc unstable (delta = 500013666 ns)
> > >
> > > That means, that the TSC was counting, but HPET not. So it looks like
> > > the HPET readout is stale. Which explains, why after switching to HPET
> > > clocksource the time system gets hosed.
> > >
> > > I wonder why the HPET counter works check did not catch this.
> > >
> > > Can you please apply the path below and provide the output ?
>
> This time against 2.6.23
>
> Thanks,
> tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs

[Andrew Paprocki]

I applied the patch and I am still locking up after
Time: hpet clocksource has been installed.

I rebooted with clocksource=tsc to get the logs of the trace which
was added. I'm assuming the grep below gets all the interesting parts.
I enabled the HPET character device as mentioned before, which is why
the hpet0 lines appear now.

# dmesg | egrep -i (hpet|time|clock)
ACPI: HPET 37FE7400, 0038 (r1 RS690  AWRDACPI 42302E31 AWRD   98)
ATI board detected. Disabling timer routing over 8254.
ACPI: PM-Timer IO Port: 0x4008
ACPI: HPET id: 0x10b9a201 base: 0xfed0
Kernel command line: vga=0x31a root=/dev/sda1 ro clocksource=tsc
HPET check: t1=5 t2=1139 s=56226339975 n=56226539985
hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0
hpet0: 4 32-bit timers, 14318180 Hz
Calibrating delay using timer specific routine.. 4927.58 BogoMIPS (lpj=9855168)
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
Time: tsc clocksource has been installed.
PCI: Setting latency timer of device :00:06.0 to 64
Real Time Clock Driver v1.12ac
hpet_resources: 0xfed0 is busy
Clocksource tsc unstable (delta = 459979812 ns)
Software Watchdog Timer: 0.07 initialized. soft_noboot=0
soft_margin=60 sec (nowayout= 0)
PCI: Setting latency timer of device :02:00.0 to 64

I ran a 'sleep 1', which hung as expected when I installed hpet as the
clocksource via /sys. I dumped the sysrq trace showing where it was
hung:

Jan 16 14:44:48 am2 kernel: sleep S f582df68 0  2205   2155
Jan 16 14:44:48 am2 kernel:f582df50 0086 c1706e80 f582df68
c1706f04 c1706e78  c01371be
Jan 16 14:44:48 am2 kernel:c17f8ab0 c17f8bf4 c1709a40 
f7077200 0286 c0137803 0001
Jan 16 14:44:43 am2 kernel:c1706e78  0286 f582df68
 f582c020 f582c000 c03ac8d3
Jan 16 14:44:43 am2 kernel: Call Trace:
Jan 16 14:44:48 am2 kernel:  [c01371be] enqueue_hrtimer+0xd7/0xe2
Jan 16 14:44:48 am2 kernel:  [c0137803] hrtimer_start+0xe8/0xf4
Jan 16 14:44:48 am2 kernel:  [c03ac8d3] do_nanosleep+0x48/0x73
Jan 16 14:44:48 am2 kernel:  [c03ac932] hrtimer_nanosleep_restart+0x34/0xa1
Jan 16 14:44:48 am2 kernel:  [c013735d] hrtimer_wakeup+0x0/0x18
Jan 16 14:44:48 am2 kernel:  [c012e837] sys_restart_syscall+0xe/0xf
Jan 16 14:44:48 am2 kernel:  [c0103d0a] sysenter_past_esp+0x5f/0x85

My 'cron' and 'atd' processes were also hung with this exact stack in
'enqueue_hrtimer'.

Thanks,
-Andrew

On Jan 16, 2008 10:21 AM, Thomas Gleixner [EMAIL PROTECTED] wrote:
   The hint is in the original report:
  
   Clocksource tsc unstable (delta = 500013666 ns)
  
   That means, that the TSC was counting, but HPET not. So it looks like
   the HPET readout is stale. Which explains, why after switching to HPET
   clocksource the time system gets hosed.
  
   I wonder why the HPET counter works check did not catch this.
  
   Can you please apply the path below and provide the output ?

 This time against 2.6.23

 Thanks,
 tglx
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs

[Andrew Paprocki]

I applied the patch to my 2.6.23.13 tree and upon reboot it stopped right after:

Clocksource tsc unstable (delta = ... ns)
Time: hpet clocksource has been installed.

It locked up hard.. cursor stopped blinking and SysRq isn't working either.

-Andrew

On Jan 13, 2008 7:03 AM, Dhaval Giani <[EMAIL PROTECTED]> wrote:
>
> On Sun, Jan 13, 2008 at 06:10:52AM -0500, Andrew Paprocki wrote:
> > I started debugging a problem I was having with my sky2 network driver
> > under 2.6.23.13. The investigation led me to find that the HPET timer
> > wasn't working at all, causing the sky2 driver to not work properly.
> > Simple example:
> >
> > am2:/sys/devices/system/clocksource/clocksource0# cat current_clocksource
> > jiffies
> > am2:/sys/devices/system/clocksource/clocksource0# time sleep 1
> > real0m1.000s
> > user0m0.000s
> > sys 0m0.000s
> > am2:/sys/devices/system/clocksource/clocksource0# echo tsc > 
> > current_clocksource
> > am2:/sys/devices/system/clocksource/clocksource0# time sleep 1
> > real0m1.005s
> > user0m0.004s
> > sys 0m0.000s
> > am2:/sys/devices/system/clocksource/clocksource0# echo hpet >
> > current_clocksource
> > am2:/sys/devices/system/clocksource/clocksource0# time sleep 1
> > 
> >
> > Running strace shows it blocked on nanosleep(). I'm building the
> > kernel with the processor type set to Athalon64. I've built it with
> > and without SMP and high-res timers enabled and I get the same result.
> > My previous 2.6.18-4 kernel works because it does not install HPET as
> > the default timer. The same behavior occurs in 2.6.24-rc7 git head.
> > I've attached the config/dmesg below.
> >
>
> It seems the HPET timer was not being assigned any IRQs at all. Can you
> try the patch at http://lkml.org/lkml/2008/1/12/128 ?
>
> Thanks,
> --
> regards,
> Dhaval
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

HPET timer broken using 2.6.23.13 / nanosleep() hangs

[Andrew Paprocki]

I started debugging a problem I was having with my sky2 network driver
under 2.6.23.13. The investigation led me to find that the HPET timer
wasn't working at all, causing the sky2 driver to not work properly.
Simple example:

am2:/sys/devices/system/clocksource/clocksource0# cat current_clocksource
jiffies
am2:/sys/devices/system/clocksource/clocksource0# time sleep 1
real0m1.000s
user0m0.000s
sys 0m0.000s
am2:/sys/devices/system/clocksource/clocksource0# echo tsc > current_clocksource
am2:/sys/devices/system/clocksource/clocksource0# time sleep 1
real0m1.005s
user0m0.004s
sys 0m0.000s
am2:/sys/devices/system/clocksource/clocksource0# echo hpet >
current_clocksource
am2:/sys/devices/system/clocksource/clocksource0# time sleep 1


Running strace shows it blocked on nanosleep(). I'm building the
kernel with the processor type set to Athalon64. I've built it with
and without SMP and high-res timers enabled and I get the same result.
My previous 2.6.18-4 kernel works because it does not install HPET as
the default timer. The same behavior occurs in 2.6.24-rc7 git head.
I've attached the config/dmesg below.

-Andrew

Under 2.6.18-4 (Debian stock kernel):

ACPI: HPET id: 0x10b9a201 base: 0xfed0
hpet0: at MMIO 0xfed0 (virtual 0xf880), IRQs 2, 8, 0, 0
hpet0: 4 32-bit timers, 14318180 Hz
Using HPET for base-timer
hpet_resources: 0xfed0 is busy
Time: tsc clocksource has been installed.

Under 2.6.23.13 w/ SMP:

ACPI: HPET 37FE7400, 0038 (r1 RS690  AWRDACPI 42302E31 AWRD   98)
ACPI: HPET id: 0x10b9a201 base: 0xfed0
Time: tsc clocksource has been installed.
Clocksource tsc unstable (delta = 500013666 ns)
Time: hpet clocksource has been installed.

Relevant top of .config from 2.6.23.13:

CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_CPUSETS is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBD=y
# CONFIG_BLK_DEV_IO_TRACE is not set
CONFIG_LSF=y
# CONFIG_BLK_DEV_BSG is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"

#
# Processor type and features
#
# CONFIG_TICK_ONESHOT is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_SMP=y
CONFIG_X86_PC=y
CONFIG_MK8=y
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_X86_XADD=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_NR_CPUS=2
# CONFIG_SCHED_SMT is not set
CONFIG_SCHED_MC=y
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_BKL=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_MCE is not set
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y

dmesg full output until HPET is installed:

Linux version 2.6.23.13 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115
(prerelease) 

HPET timer broken using 2.6.23.13 / nanosleep() hangs

[Andrew Paprocki]

I started debugging a problem I was having with my sky2 network driver
under 2.6.23.13. The investigation led me to find that the HPET timer
wasn't working at all, causing the sky2 driver to not work properly.
Simple example:

am2:/sys/devices/system/clocksource/clocksource0# cat current_clocksource
jiffies
am2:/sys/devices/system/clocksource/clocksource0# time sleep 1
real0m1.000s
user0m0.000s
sys 0m0.000s
am2:/sys/devices/system/clocksource/clocksource0# echo tsc  current_clocksource
am2:/sys/devices/system/clocksource/clocksource0# time sleep 1
real0m1.005s
user0m0.004s
sys 0m0.000s
am2:/sys/devices/system/clocksource/clocksource0# echo hpet 
current_clocksource
am2:/sys/devices/system/clocksource/clocksource0# time sleep 1
hangs indefinetly...

Running strace shows it blocked on nanosleep(). I'm building the
kernel with the processor type set to Athalon64. I've built it with
and without SMP and high-res timers enabled and I get the same result.
My previous 2.6.18-4 kernel works because it does not install HPET as
the default timer. The same behavior occurs in 2.6.24-rc7 git head.
I've attached the config/dmesg below.

-Andrew

Under 2.6.18-4 (Debian stock kernel):

ACPI: HPET id: 0x10b9a201 base: 0xfed0
hpet0: at MMIO 0xfed0 (virtual 0xf880), IRQs 2, 8, 0, 0
hpet0: 4 32-bit timers, 14318180 Hz
Using HPET for base-timer
hpet_resources: 0xfed0 is busy
Time: tsc clocksource has been installed.

Under 2.6.23.13 w/ SMP:

ACPI: HPET 37FE7400, 0038 (r1 RS690  AWRDACPI 42302E31 AWRD   98)
ACPI: HPET id: 0x10b9a201 base: 0xfed0
Time: tsc clocksource has been installed.
Clocksource tsc unstable (delta = 500013666 ns)
Time: hpet clocksource has been installed.

Relevant top of .config from 2.6.23.13:

CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_CPUSETS is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBD=y
# CONFIG_BLK_DEV_IO_TRACE is not set
CONFIG_LSF=y
# CONFIG_BLK_DEV_BSG is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED=cfq

#
# Processor type and features
#
# CONFIG_TICK_ONESHOT is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_SMP=y
CONFIG_X86_PC=y
CONFIG_MK8=y
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_X86_XADD=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_NR_CPUS=2
# CONFIG_SCHED_SMT is not set
CONFIG_SCHED_MC=y
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_BKL=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_MCE is not set
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y

dmesg full output until HPET is installed:

Linux version 2.6.23.13 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115

Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs

[Andrew Paprocki]

I applied the patch to my 2.6.23.13 tree and upon reboot it stopped right after:

Clocksource tsc unstable (delta = ... ns)
Time: hpet clocksource has been installed.

It locked up hard.. cursor stopped blinking and SysRq isn't working either.

-Andrew

On Jan 13, 2008 7:03 AM, Dhaval Giani [EMAIL PROTECTED] wrote:

 On Sun, Jan 13, 2008 at 06:10:52AM -0500, Andrew Paprocki wrote:
  I started debugging a problem I was having with my sky2 network driver
  under 2.6.23.13. The investigation led me to find that the HPET timer
  wasn't working at all, causing the sky2 driver to not work properly.
  Simple example:
 
  am2:/sys/devices/system/clocksource/clocksource0# cat current_clocksource
  jiffies
  am2:/sys/devices/system/clocksource/clocksource0# time sleep 1
  real0m1.000s
  user0m0.000s
  sys 0m0.000s
  am2:/sys/devices/system/clocksource/clocksource0# echo tsc  
  current_clocksource
  am2:/sys/devices/system/clocksource/clocksource0# time sleep 1
  real0m1.005s
  user0m0.004s
  sys 0m0.000s
  am2:/sys/devices/system/clocksource/clocksource0# echo hpet 
  current_clocksource
  am2:/sys/devices/system/clocksource/clocksource0# time sleep 1
  hangs indefinetly...
 
  Running strace shows it blocked on nanosleep(). I'm building the
  kernel with the processor type set to Athalon64. I've built it with
  and without SMP and high-res timers enabled and I get the same result.
  My previous 2.6.18-4 kernel works because it does not install HPET as
  the default timer. The same behavior occurs in 2.6.24-rc7 git head.
  I've attached the config/dmesg below.
 

 It seems the HPET timer was not being assigned any IRQs at all. Can you
 try the patch at http://lkml.org/lkml/2008/1/12/128 ?

 Thanks,
 --
 regards,
 Dhaval


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Geode GX framebuffer driver: Arcom vs. AMD

[Andrew Paprocki]

Tony,

Do you have the patch working already? I'd love to try this out in the
meantime on the LX system I am developing with at the moment. I'm
assuming you worked this into the existing Arcom framework (gxfb) and
pulled the necessary pieces from the AMD code?

I looked at doing this, but it just seemed easier to use the AMD
provided driver, as it would be easier to merge any changes in the
future and might provide more full support for the hardware and all
its modes.

Also, question for AMD/Jordan.. Is AMD going to provide any
support/patches for the existing gxfb and this new lxfb? (Maybe
perhaps an AMD supported DirectFB driver? :))

If anyone else is interested, I'll get around to making a patch of the
work I just did to bring the original AMD 2.6.11 framebuffer &
Cimarron fully up to date with the 2.6.22 tree. If AMD is going to
continue to maintain their own driver, this will allow the use of an
up-to-date kernel.

Thanks, -Andrew

On 7/14/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:

There's a patch for the AMD Geode LX which I'm going to send for the -mm
tree soon. Its module name is lxfb.

Tony

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Geode GX framebuffer driver: Arcom vs. AMD

[Andrew Paprocki]

On 7/14/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:

After a very brief look on the relevant part of the patch:
-> Needs to be adapted to CodingStyle all over.


I agree, this can be done if it was ever going to be included.


-> The use of AMD specific BUILDNUM etc are not used in-kernel


This can be cleaned up as well, or put behind some #ifdef to allow AMD
to keep using their own system, I suppose.


-> The HAL in lib/cimarron needs to be justified - who are the oter users?


The HAL is used by the driver, obviously, but is included in
lib/cimarron for any other module writers which want to access the
graphics hardware from inside the kernel. When you're developing a
user app and want to access the hardware, you link Cimarron into your
code directly. I'm not sure what other kernel modules AMD expected to
be written, but I'm guessing they just wanted to keep their HAL and
write the framebuffer driver in terms of that instead of maintaining a
user-space HAL and a duplicate kernel driver.


-> There seems to be a _lot_ of specific defines in lib/cimarron - I wonder
   if this is the way used in the rest of the kernel?


Which defines are you referring to? I know there are a few 'settings'
which are modified by changing #defines in one of the .h files. I'm
assuming that those would be moved to Kconfig values if this was ever
in the kernel.


But anyway - the patch it not trivially ready for inclusion.


I agree. I just did the work to port it from 2.6.11 to 2.6.22 just to
get it working in my tree. It all builds cleanly now, so any work
would most likely be cosmetic to clean up the code base.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Geode GX framebuffer driver: Arcom vs. AMD

[Andrew Paprocki]

Is there any reason why the GPL framebuffer driver for the GX/GX1/LX
directly from AMD is not integrated into the kernel and only a custom
driver for only the GX/GX1 written by Arcom exists?
(drivers/video/geode/*)

If you have an LX, the Arcom driver won't work and it is difficult to
use AMD's patch for 2.6.11 with a more recent kernel because the
drivers/video/geode directory has filename conflicts with files in the
patch.

If there are no issues preventing its inclusion, would updated patches
be accepted to switch to AMD's framebuffer driver? The AMD patches
would need to be combined to support all three platforms in the driver
dir, all sitting on top of the Cimarron HAL installed in lib/cimarron.

The entire AMD LX patch for 2.6.11 is here:
http://www.amd.com/files/connectivitysolutions/geode/geode_lx/Patches_Linux2.6.11_Common_02.03.0100.patch

The relevant parts are:
drivers/video/geode/*
lib/cimarron/*

Thanks, -Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Geode GX framebuffer driver: Arcom vs. AMD

[Andrew Paprocki]

Is there any reason why the GPL framebuffer driver for the GX/GX1/LX
directly from AMD is not integrated into the kernel and only a custom
driver for only the GX/GX1 written by Arcom exists?
(drivers/video/geode/*)

If you have an LX, the Arcom driver won't work and it is difficult to
use AMD's patch for 2.6.11 with a more recent kernel because the
drivers/video/geode directory has filename conflicts with files in the
patch.

If there are no issues preventing its inclusion, would updated patches
be accepted to switch to AMD's framebuffer driver? The AMD patches
would need to be combined to support all three platforms in the driver
dir, all sitting on top of the Cimarron HAL installed in lib/cimarron.

The entire AMD LX patch for 2.6.11 is here:
http://www.amd.com/files/connectivitysolutions/geode/geode_lx/Patches_Linux2.6.11_Common_02.03.0100.patch

The relevant parts are:
drivers/video/geode/*
lib/cimarron/*

Thanks, -Andrew
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Geode GX framebuffer driver: Arcom vs. AMD

[Andrew Paprocki]

On 7/14/07, Sam Ravnborg [EMAIL PROTECTED] wrote:

After a very brief look on the relevant part of the patch:
- Needs to be adapted to CodingStyle all over.


I agree, this can be done if it was ever going to be included.


- The use of AMD specific BUILDNUM etc are not used in-kernel


This can be cleaned up as well, or put behind some #ifdef to allow AMD
to keep using their own system, I suppose.


- The HAL in lib/cimarron needs to be justified - who are the oter users?


The HAL is used by the driver, obviously, but is included in
lib/cimarron for any other module writers which want to access the
graphics hardware from inside the kernel. When you're developing a
user app and want to access the hardware, you link Cimarron into your
code directly. I'm not sure what other kernel modules AMD expected to
be written, but I'm guessing they just wanted to keep their HAL and
write the framebuffer driver in terms of that instead of maintaining a
user-space HAL and a duplicate kernel driver.


- There seems to be a _lot_ of specific defines in lib/cimarron - I wonder
   if this is the way used in the rest of the kernel?


Which defines are you referring to? I know there are a few 'settings'
which are modified by changing #defines in one of the .h files. I'm
assuming that those would be moved to Kconfig values if this was ever
in the kernel.


But anyway - the patch it not trivially ready for inclusion.


I agree. I just did the work to port it from 2.6.11 to 2.6.22 just to
get it working in my tree. It all builds cleanly now, so any work
would most likely be cosmetic to clean up the code base.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Geode GX framebuffer driver: Arcom vs. AMD

[Andrew Paprocki]

Tony,

Do you have the patch working already? I'd love to try this out in the
meantime on the LX system I am developing with at the moment. I'm
assuming you worked this into the existing Arcom framework (gxfb) and
pulled the necessary pieces from the AMD code?

I looked at doing this, but it just seemed easier to use the AMD
provided driver, as it would be easier to merge any changes in the
future and might provide more full support for the hardware and all
its modes.

Also, question for AMD/Jordan.. Is AMD going to provide any
support/patches for the existing gxfb and this new lxfb? (Maybe
perhaps an AMD supported DirectFB driver? :))

If anyone else is interested, I'll get around to making a patch of the
work I just did to bring the original AMD 2.6.11 framebuffer 
Cimarron fully up to date with the 2.6.22 tree. If AMD is going to
continue to maintain their own driver, this will allow the use of an
up-to-date kernel.

Thanks, -Andrew

On 7/14/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:

There's a patch for the AMD Geode LX which I'm going to send for the -mm
tree soon. Its module name is lxfb.

Tony

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.22-rc2 amd64 slab allocator bug reported at boot time

[Andrew Paprocki]

Snippet from dmesg output (the full dmesg output was attached to my
previous e-mail right before this one regarding 2.6.22-rc2 amd64+4gb
ram agpgart bug):

PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
NET: Registered protocol family 8
NET: Registered protocol family 20
BUG: at /usr/src/linux-2.6.22-rc2/mm/slab.c:777 __find_general_cachep()

Call Trace:
[] __kmalloc+0x3e/0xbe
[] cache_k8_northbridges+0x7f/0xf0
[] gart_iommu_init+0x13/0x4f8
[] kobject_shadow_add+0xef/0x1a2
[] kobject_get+0x12/0x17
[] class_register+0x10a/0x13d
[] pci_iommu_init+0x9/0x12
[] kernel_init+0x167/0x2d7
[] child_rip+0xa/0x12
[] acpi_ds_init_one_object+0x0/0x7c
[] kernel_init+0x0/0x2d7
[] child_rip+0x0/0x12

PCI-GART: No AMD northbridge found.
hpet0: at MMIO 0xfed0, IRQs 2, 8, 0
hpet0: 3 64-bit timers, 14318180 Hz

-Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.22-rc2 amd64 + 4gb ram hanging during boot after agpgart detection

[Andrew Paprocki]

This issue appears to be identical to the one reported here:
http://lists.opensuse.org/opensuse-amd64/2007-04/msg1.html

By manually adding mem=4096M to my boot line, the system is able to
come up fine. Otherwise, it will randomly hang during boot after the
line:
agpgart: detected an Intel 965G chipset.

This is a Gigabyte GA-965P-DQ6 motherboard at the latest F10 BIOS
level. The full dmesg output from a working boot with mem=4096M is
attached.

Thanks -Andrew
Linux version 2.6.22-rc2-plateado ([EMAIL PROTECTED]) (gcc version 4.1.2 
20061115 (prerelease) (Debian 4.1.1-21)) #3 SMP Mon May 21 19:38:38 EDT 2007
Command line: root=/dev/sdg3 ro mem=4096M
BIOS-provided physical RAM map:
 BIOS-e820:  - 00097c00 (usable)
 BIOS-e820: 0009f800 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - dfee (usable)
 BIOS-e820: dfee - dfee3000 (ACPI NVS)
 BIOS-e820: dfee3000 - dfef (ACPI data)
 BIOS-e820: dfef - dff0 (reserved)
 BIOS-e820: f000 - f400 (reserved)
 BIOS-e820: fec0 - 0001 (reserved)
 BIOS-e820: 0001 - 00012000 (usable)
Entering add_active_range(0, 0, 151) 0 entries of 256 used
Entering add_active_range(0, 256, 917216) 1 entries of 256 used
end_pfn_map = 1048576
DMI 2.4 present.
ACPI: RSDP 000F6E70, 0014 (r0 GBT   )
ACPI: RSDT DFEE3040, 0034 (r1 GBTGBTUACPI 42302E31 GBTU  1010101)
ACPI: FACP DFEE30C0, 0074 (r1 GBTGBTUACPI 42302E31 GBTU  1010101)
ACPI: DSDT DFEE3180, 49F4 (r1 GBTGBTUACPI 1000 MSFT  10C)
ACPI: FACS DFEE, 0040
ACPI: HPET DFEE7CC0, 0038 (r1 GBTGBTUACPI 42302E31 GBTU   98)
ACPI: MCFG DFEE7D40, 003C (r1 GBTGBTUACPI 42302E31 GBTU  1010101)
ACPI: APIC DFEE7BC0, 0084 (r1 GBTGBTUACPI 42302E31 GBTU  1010101)
Entering add_active_range(0, 0, 151) 0 entries of 256 used
Entering add_active_range(0, 256, 917216) 1 entries of 256 used
Zone PFN ranges:
  DMA 0 -> 4096
  DMA324096 ->  1048576
  Normal1048576 ->  1048576
early_node_map[2] active PFN ranges
0:0 ->  151
0:  256 ->   917216
On node 0 totalpages: 917111
  DMA zone: 56 pages used for memmap
  DMA zone: 960 pages reserved
  DMA zone: 2975 pages, LIFO batch:0
  DMA32 zone: 12484 pages used for memmap
  DMA32 zone: 900636 pages, LIFO batch:31
  Normal zone: 0 pages used for memmap
ACPI: PM-Timer IO Port: 0x408
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled)
ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
ACPI: HPET id: 0x8086a201 base: 0xfed0
Using ACPI (MADT) for SMP configuration information
swsusp: Registered nosave memory region: 00097000 - 000a
swsusp: Registered nosave memory region: 000a - 000f
swsusp: Registered nosave memory region: 000f - 0010
Allocating PCI resources starting at e000 (gap: dff0:1010)
SMP: Allowing 4 CPUs, 2 hotplug CPUs
PERCPU: Allocating 37128 bytes of per cpu data
Built 1 zonelists.  Total pages: 903611
Kernel command line: root=/dev/sdg3 ro mem=4096M
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
time.c: Detected 2400.000 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Checking aperture...
Memory: 3604856k/3668864k available (1953k kernel code, 63184k reserved, 974k 
data, 204k init)
Calibrating delay using timer specific routine.. 4803.25 BogoMIPS (lpj=9606519)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 256
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 4096K
using mwait in idle threads.
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
CPU0: Thermal monitoring enabled (TM2)
SMP alternatives: switching to UP code
ACPI: Core revision 20070126
Using local APIC timer interrupts.
result 1647
Detected 16.666 MHz APIC timer.
SMP alternatives: switching to SMP code
Booting processor 1/2 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 4800.02 BogoMIPS 

2.6.22-rc2 amd64 + 4gb ram hanging during boot after agpgart detection

[Andrew Paprocki]

This issue appears to be identical to the one reported here:
http://lists.opensuse.org/opensuse-amd64/2007-04/msg1.html

By manually adding mem=4096M to my boot line, the system is able to
come up fine. Otherwise, it will randomly hang during boot after the
line:
agpgart: detected an Intel 965G chipset.

This is a Gigabyte GA-965P-DQ6 motherboard at the latest F10 BIOS
level. The full dmesg output from a working boot with mem=4096M is
attached.

Thanks -Andrew
Linux version 2.6.22-rc2-plateado ([EMAIL PROTECTED]) (gcc version 4.1.2 
20061115 (prerelease) (Debian 4.1.1-21)) #3 SMP Mon May 21 19:38:38 EDT 2007
Command line: root=/dev/sdg3 ro mem=4096M
BIOS-provided physical RAM map:
 BIOS-e820:  - 00097c00 (usable)
 BIOS-e820: 0009f800 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - dfee (usable)
 BIOS-e820: dfee - dfee3000 (ACPI NVS)
 BIOS-e820: dfee3000 - dfef (ACPI data)
 BIOS-e820: dfef - dff0 (reserved)
 BIOS-e820: f000 - f400 (reserved)
 BIOS-e820: fec0 - 0001 (reserved)
 BIOS-e820: 0001 - 00012000 (usable)
Entering add_active_range(0, 0, 151) 0 entries of 256 used
Entering add_active_range(0, 256, 917216) 1 entries of 256 used
end_pfn_map = 1048576
DMI 2.4 present.
ACPI: RSDP 000F6E70, 0014 (r0 GBT   )
ACPI: RSDT DFEE3040, 0034 (r1 GBTGBTUACPI 42302E31 GBTU  1010101)
ACPI: FACP DFEE30C0, 0074 (r1 GBTGBTUACPI 42302E31 GBTU  1010101)
ACPI: DSDT DFEE3180, 49F4 (r1 GBTGBTUACPI 1000 MSFT  10C)
ACPI: FACS DFEE, 0040
ACPI: HPET DFEE7CC0, 0038 (r1 GBTGBTUACPI 42302E31 GBTU   98)
ACPI: MCFG DFEE7D40, 003C (r1 GBTGBTUACPI 42302E31 GBTU  1010101)
ACPI: APIC DFEE7BC0, 0084 (r1 GBTGBTUACPI 42302E31 GBTU  1010101)
Entering add_active_range(0, 0, 151) 0 entries of 256 used
Entering add_active_range(0, 256, 917216) 1 entries of 256 used
Zone PFN ranges:
  DMA 0 - 4096
  DMA324096 -  1048576
  Normal1048576 -  1048576
early_node_map[2] active PFN ranges
0:0 -  151
0:  256 -   917216
On node 0 totalpages: 917111
  DMA zone: 56 pages used for memmap
  DMA zone: 960 pages reserved
  DMA zone: 2975 pages, LIFO batch:0
  DMA32 zone: 12484 pages used for memmap
  DMA32 zone: 900636 pages, LIFO batch:31
  Normal zone: 0 pages used for memmap
ACPI: PM-Timer IO Port: 0x408
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled)
ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
ACPI: HPET id: 0x8086a201 base: 0xfed0
Using ACPI (MADT) for SMP configuration information
swsusp: Registered nosave memory region: 00097000 - 000a
swsusp: Registered nosave memory region: 000a - 000f
swsusp: Registered nosave memory region: 000f - 0010
Allocating PCI resources starting at e000 (gap: dff0:1010)
SMP: Allowing 4 CPUs, 2 hotplug CPUs
PERCPU: Allocating 37128 bytes of per cpu data
Built 1 zonelists.  Total pages: 903611
Kernel command line: root=/dev/sdg3 ro mem=4096M
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
time.c: Detected 2400.000 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Checking aperture...
Memory: 3604856k/3668864k available (1953k kernel code, 63184k reserved, 974k 
data, 204k init)
Calibrating delay using timer specific routine.. 4803.25 BogoMIPS (lpj=9606519)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 256
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 4096K
using mwait in idle threads.
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
CPU0: Thermal monitoring enabled (TM2)
SMP alternatives: switching to UP code
ACPI: Core revision 20070126
Using local APIC timer interrupts.
result 1647
Detected 16.666 MHz APIC timer.
SMP alternatives: switching to SMP code
Booting processor 1/2 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 4800.02 BogoMIPS 

2.6.22-rc2 amd64 slab allocator bug reported at boot time

[Andrew Paprocki]

Snippet from dmesg output (the full dmesg output was attached to my
previous e-mail right before this one regarding 2.6.22-rc2 amd64+4gb
ram agpgart bug):

PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try pci=routeirq.  If it helps, post a report
NET: Registered protocol family 8
NET: Registered protocol family 20
BUG: at /usr/src/linux-2.6.22-rc2/mm/slab.c:777 __find_general_cachep()

Call Trace:
[802743dc] __kmalloc+0x3e/0xbe
[8021d65f] cache_k8_northbridges+0x7f/0xf0
[8052bb53] gart_iommu_init+0x13/0x4f8
[802d15e1] kobject_shadow_add+0xef/0x1a2
[802d13fb] kobject_get+0x12/0x17
[8033b2a4] class_register+0x10a/0x13d
[80527964] pci_iommu_init+0x9/0x12
[8052060e] kernel_init+0x167/0x2d7
[8020aba8] child_rip+0xa/0x12
[802fb7e4] acpi_ds_init_one_object+0x0/0x7c
[805204a7] kernel_init+0x0/0x2d7
[8020ab9e] child_rip+0x0/0x12

PCI-GART: No AMD northbridge found.
hpet0: at MMIO 0xfed0, IRQs 2, 8, 0
hpet0: 3 64-bit timers, 14318180 Hz

-Andrew
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/