Re: Failure to properly reinit i8042 post suspend-to-ram

2007-07-10 Thread Stefan Seyfried
Hi,

On Tue, Jul 10, 2007 at 10:59:57AM +1000, Nigel Cunningham wrote:
> On Saturday 07 July 2007 01:04:51 Stefan Seyfried wrote:
> > On Thu, Jul 05, 2007 at 09:04:27PM +1000, Nigel Cunningham wrote:
> > > 
> > > Adding i8042.reset=1 to the commandline fixed it.
> > 
> > Wasn't there a quirk list where workarounds for i8042 on known bad machines
> > are stored? Maybe it would be a good idea to get your machine into it ;-)
> 
> Unless I'm missing something, it looks like there's no such thing in the 
> i8042 
> driver. That's okay. I can cope with adding i8042.reset=1 to my 
> commandline :)

In drivers/input/serio/i8042-x86ia64io.h there are tables for various quirks,
but apparently nothing for "reset=1".
If we find another machine that needs reset=1, then it might be time for a
table for this quirk.

Best regards,

Stefan

-- 
Stefan Seyfried
QA / R Team Mobile Devices|  "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg  | "Well, surrounding them's out." 

This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
-
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: Failure to properly reinit i8042 post suspend-to-ram

2007-07-10 Thread Stefan Seyfried
Hi,

On Tue, Jul 10, 2007 at 10:59:57AM +1000, Nigel Cunningham wrote:
 On Saturday 07 July 2007 01:04:51 Stefan Seyfried wrote:
  On Thu, Jul 05, 2007 at 09:04:27PM +1000, Nigel Cunningham wrote:
   
   Adding i8042.reset=1 to the commandline fixed it.
  
  Wasn't there a quirk list where workarounds for i8042 on known bad machines
  are stored? Maybe it would be a good idea to get your machine into it ;-)
 
 Unless I'm missing something, it looks like there's no such thing in the 
 i8042 
 driver. That's okay. I can cope with adding i8042.reset=1 to my 
 commandline :)

In drivers/input/serio/i8042-x86ia64io.h there are tables for various quirks,
but apparently nothing for reset=1.
If we find another machine that needs reset=1, then it might be time for a
table for this quirk.

Best regards,

Stefan

-- 
Stefan Seyfried
QA / RD Team Mobile Devices|  Any ideas, John?
SUSE LINUX Products GmbH, Nürnberg  | Well, surrounding them's out. 

This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
-
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: Failure to properly reinit i8042 post suspend-to-ram

2007-07-09 Thread Nigel Cunningham
Hi.

On Saturday 07 July 2007 01:04:51 Stefan Seyfried wrote:
> On Thu, Jul 05, 2007 at 09:04:27PM +1000, Nigel Cunningham wrote:
> > > 
> > > If confusion persist after 4 seconds hard power down... then you h ve
> > > hw/BIOS problem. Complain to whoever is manufacturing that beast.
> > 
> > Adding i8042.reset=1 to the commandline fixed it.
> 
> Wasn't there a quirk list where workarounds for i8042 on known bad machines
> are stored? Maybe it would be a good idea to get your machine into it ;-)

Unless I'm missing something, it looks like there's no such thing in the i8042 
driver. That's okay. I can cope with adding i8042.reset=1 to my 
commandline :)

Nigel
-- 
Nigel Cunningham
Christian Reformed Church of Cobden
103 Curdie Street, Cobden 3266, Victoria, Australia
Ph. +61 3 5595 1185 / +61 417 100 574
Communal Worship: 11 am Sunday.


pgpiBYowsy33t.pgp
Description: PGP signature


Re: Failure to properly reinit i8042 post suspend-to-ram

2007-07-09 Thread Nigel Cunningham
Hi.

On Saturday 07 July 2007 01:04:51 Stefan Seyfried wrote:
 On Thu, Jul 05, 2007 at 09:04:27PM +1000, Nigel Cunningham wrote:
   
   If confusion persist after 4 seconds hard power down... then you h ve
   hw/BIOS problem. Complain to whoever is manufacturing that beast.
  
  Adding i8042.reset=1 to the commandline fixed it.
 
 Wasn't there a quirk list where workarounds for i8042 on known bad machines
 are stored? Maybe it would be a good idea to get your machine into it ;-)

Unless I'm missing something, it looks like there's no such thing in the i8042 
driver. That's okay. I can cope with adding i8042.reset=1 to my 
commandline :)

Nigel
-- 
Nigel Cunningham
Christian Reformed Church of Cobden
103 Curdie Street, Cobden 3266, Victoria, Australia
Ph. +61 3 5595 1185 / +61 417 100 574
Communal Worship: 11 am Sunday.


pgpiBYowsy33t.pgp
Description: PGP signature


Re: Failure to properly reinit i8042 post suspend-to-ram

2007-07-06 Thread Nigel Cunningham
Hi.

On Saturday 07 July 2007 01:04:51 Stefan Seyfried wrote:
> On Thu, Jul 05, 2007 at 09:04:27PM +1000, Nigel Cunningham wrote:
> > > 
> > > If confusion persist after 4 seconds hard power down... then you h ve
> > > hw/BIOS problem. Complain to whoever is manufacturing that beast.
> > 
> > Adding i8042.reset=1 to the commandline fixed it.
> 
> Wasn't there a quirk list where workarounds for i8042 on known bad machines
> are stored? Maybe it would be a good idea to get your machine into it ;-)

Never heard of it. I'll see what I can find.

Regards,

Nigel
-- 
Nigel Cunningham
Christian Reformed Church of Cobden
103 Curdie Street, Cobden 3266, Victoria, Australia
Ph. +61 3 5595 1185 / +61 417 100 574
Communal Worship: 11 am Sunday.


pgpBC02U9aY7W.pgp
Description: PGP signature


Re: Failure to properly reinit i8042 post suspend-to-ram

2007-07-06 Thread Stefan Seyfried
On Thu, Jul 05, 2007 at 09:04:27PM +1000, Nigel Cunningham wrote:
> > 
> > If confusion persist after 4 seconds hard power down... then you h ve
> > hw/BIOS problem. Complain to whoever is manufacturing that beast.
> 
> Adding i8042.reset=1 to the commandline fixed it.

Wasn't there a quirk list where workarounds for i8042 on known bad machines
are stored? Maybe it would be a good idea to get your machine into it ;-)
-- 
Stefan Seyfried
QA / R Team Mobile Devices|  "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg  | "Well, surrounding them's out." 

This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
-
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: Failure to properly reinit i8042 post suspend-to-ram

2007-07-06 Thread Stefan Seyfried
On Thu, Jul 05, 2007 at 09:04:27PM +1000, Nigel Cunningham wrote:
  
  If confusion persist after 4 seconds hard power down... then you h ve
  hw/BIOS problem. Complain to whoever is manufacturing that beast.
 
 Adding i8042.reset=1 to the commandline fixed it.

Wasn't there a quirk list where workarounds for i8042 on known bad machines
are stored? Maybe it would be a good idea to get your machine into it ;-)
-- 
Stefan Seyfried
QA / RD Team Mobile Devices|  Any ideas, John?
SUSE LINUX Products GmbH, Nürnberg  | Well, surrounding them's out. 

This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
-
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: Failure to properly reinit i8042 post suspend-to-ram

2007-07-06 Thread Nigel Cunningham
Hi.

On Saturday 07 July 2007 01:04:51 Stefan Seyfried wrote:
 On Thu, Jul 05, 2007 at 09:04:27PM +1000, Nigel Cunningham wrote:
   
   If confusion persist after 4 seconds hard power down... then you h ve
   hw/BIOS problem. Complain to whoever is manufacturing that beast.
  
  Adding i8042.reset=1 to the commandline fixed it.
 
 Wasn't there a quirk list where workarounds for i8042 on known bad machines
 are stored? Maybe it would be a good idea to get your machine into it ;-)

Never heard of it. I'll see what I can find.

Regards,

Nigel
-- 
Nigel Cunningham
Christian Reformed Church of Cobden
103 Curdie Street, Cobden 3266, Victoria, Australia
Ph. +61 3 5595 1185 / +61 417 100 574
Communal Worship: 11 am Sunday.


pgpBC02U9aY7W.pgp
Description: PGP signature


Re: Failure to properly reinit i8042 post suspend-to-ram

2007-07-05 Thread Nigel Cunningham
Hi.

On Thursday 05 July 2007 20:15:14 Pavel Machek wrote:
> Hi!
> 
> > I have recently begun to try and use suspend to ram more, and have an 
> > intermittent problem. Actually, it's a couple of (possibly related) 
problems, 
> > but I'll start with the one that's easiest.
> > 
> > Sometimes, when I resume, the keyboard stops responding. I then need to 
hold 
> > down the power button for 4 seconds. At the next boot, things are still 
not 
> > right. The i8042 controller seems to be confused about it's mode, because 
I 
> > get the following differences in dmesg to a 'normal' boot:
> 
> If confusion persist after 4 seconds hard power down... then you h ve
> hw/BIOS problem. Complain to whoever is manufacturing that beast.

Adding i8042.reset=1 to the commandline fixed it.

Regards,

Nigel
-- 
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.


pgpBwPuKkb0hx.pgp
Description: PGP signature


Re: Failure to properly reinit i8042 post suspend-to-ram

2007-07-05 Thread Pavel Machek
Hi!

> I have recently begun to try and use suspend to ram more, and have an 
> intermittent problem. Actually, it's a couple of (possibly related) problems, 
> but I'll start with the one that's easiest.
> 
> Sometimes, when I resume, the keyboard stops responding. I then need to hold 
> down the power button for 4 seconds. At the next boot, things are still not 
> right. The i8042 controller seems to be confused about it's mode, because I 
> get the following differences in dmesg to a 'normal' boot:

If confusion persist after 4 seconds hard power down... then you h ve
hw/BIOS problem. Complain to whoever is manufacturing that beast.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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: Failure to properly reinit i8042 post suspend-to-ram

2007-07-05 Thread Nigel Cunningham
Hi.

On Thursday 05 July 2007 20:15:14 Pavel Machek wrote:
 Hi!
 
  I have recently begun to try and use suspend to ram more, and have an 
  intermittent problem. Actually, it's a couple of (possibly related) 
problems, 
  but I'll start with the one that's easiest.
  
  Sometimes, when I resume, the keyboard stops responding. I then need to 
hold 
  down the power button for 4 seconds. At the next boot, things are still 
not 
  right. The i8042 controller seems to be confused about it's mode, because 
I 
  get the following differences in dmesg to a 'normal' boot:
 
 If confusion persist after 4 seconds hard power down... then you h ve
 hw/BIOS problem. Complain to whoever is manufacturing that beast.

Adding i8042.reset=1 to the commandline fixed it.

Regards,

Nigel
-- 
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.


pgpBwPuKkb0hx.pgp
Description: PGP signature


Re: Failure to properly reinit i8042 post suspend-to-ram

2007-07-05 Thread Pavel Machek
Hi!

 I have recently begun to try and use suspend to ram more, and have an 
 intermittent problem. Actually, it's a couple of (possibly related) problems, 
 but I'll start with the one that's easiest.
 
 Sometimes, when I resume, the keyboard stops responding. I then need to hold 
 down the power button for 4 seconds. At the next boot, things are still not 
 right. The i8042 controller seems to be confused about it's mode, because I 
 get the following differences in dmesg to a 'normal' boot:

If confusion persist after 4 seconds hard power down... then you h ve
hw/BIOS problem. Complain to whoever is manufacturing that beast.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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: Failure to properly reinit i8042 post suspend-to-ram

2007-06-24 Thread Nigel Cunningham
Hi.

On Monday 25 June 2007 07:03:20 Rafael J. Wysocki wrote:
> Hi,
> 
> On Friday, 22 June 2007 08:07, Nigel Cunningham wrote:
> > Hi.
> > 
> > I have recently begun to try and use suspend to ram more, and have an 
> > intermittent problem. Actually, it's a couple of (possibly related) 
> > problems, 
> > but I'll start with the one that's easiest.
> > 
> > Sometimes, when I resume, the keyboard stops responding. I then need to 
> > hold 
> > down the power button for 4 seconds. At the next boot, things are still not 
> > right. The i8042 controller seems to be confused about it's mode, because I 
> > get the following differences in dmesg to a 'normal' boot:
> 
> Well, I'm afraid no one has any idea.
> 
> I think you can file a bug report with the kernel bugzilla.

Yeah. I think I'll do some more debugging first, though - seek to find out 
exactly what is failing.

Regards,

Nigel

-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia


pgpSvHwnB8QtQ.pgp
Description: PGP signature


Re: Failure to properly reinit i8042 post suspend-to-ram

2007-06-24 Thread Rafael J. Wysocki
Hi,

On Friday, 22 June 2007 08:07, Nigel Cunningham wrote:
> Hi.
> 
> I have recently begun to try and use suspend to ram more, and have an 
> intermittent problem. Actually, it's a couple of (possibly related) problems, 
> but I'll start with the one that's easiest.
> 
> Sometimes, when I resume, the keyboard stops responding. I then need to hold 
> down the power button for 4 seconds. At the next boot, things are still not 
> right. The i8042 controller seems to be confused about it's mode, because I 
> get the following differences in dmesg to a 'normal' boot:

Well, I'm afraid no one has any idea.

I think you can file a bug report with the kernel bugzilla.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth
-
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: Failure to properly reinit i8042 post suspend-to-ram

2007-06-24 Thread Rafael J. Wysocki
Hi,

On Friday, 22 June 2007 08:07, Nigel Cunningham wrote:
 Hi.
 
 I have recently begun to try and use suspend to ram more, and have an 
 intermittent problem. Actually, it's a couple of (possibly related) problems, 
 but I'll start with the one that's easiest.
 
 Sometimes, when I resume, the keyboard stops responding. I then need to hold 
 down the power button for 4 seconds. At the next boot, things are still not 
 right. The i8042 controller seems to be confused about it's mode, because I 
 get the following differences in dmesg to a 'normal' boot:

Well, I'm afraid no one has any idea.

I think you can file a bug report with the kernel bugzilla.

Greetings,
Rafael


-- 
Premature optimization is the root of all evil. - Donald Knuth
-
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: Failure to properly reinit i8042 post suspend-to-ram

2007-06-24 Thread Nigel Cunningham
Hi.

On Monday 25 June 2007 07:03:20 Rafael J. Wysocki wrote:
 Hi,
 
 On Friday, 22 June 2007 08:07, Nigel Cunningham wrote:
  Hi.
  
  I have recently begun to try and use suspend to ram more, and have an 
  intermittent problem. Actually, it's a couple of (possibly related) 
  problems, 
  but I'll start with the one that's easiest.
  
  Sometimes, when I resume, the keyboard stops responding. I then need to 
  hold 
  down the power button for 4 seconds. At the next boot, things are still not 
  right. The i8042 controller seems to be confused about it's mode, because I 
  get the following differences in dmesg to a 'normal' boot:
 
 Well, I'm afraid no one has any idea.
 
 I think you can file a bug report with the kernel bugzilla.

Yeah. I think I'll do some more debugging first, though - seek to find out 
exactly what is failing.

Regards,

Nigel

-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia


pgpSvHwnB8QtQ.pgp
Description: PGP signature


Failure to properly reinit i8042 post suspend-to-ram

2007-06-22 Thread Nigel Cunningham
Hi.

I have recently begun to try and use suspend to ram more, and have an 
intermittent problem. Actually, it's a couple of (possibly related) problems, 
but I'll start with the one that's easiest.

Sometimes, when I resume, the keyboard stops responding. I then need to hold 
down the power button for 4 seconds. At the next boot, things are still not 
right. The i8042 controller seems to be confused about it's mode, because I 
get the following differences in dmesg to a 'normal' boot:

--- good-boot-dmesg-no-timestamp.txt2007-06-22 15:54:03.0 +1000
+++ problem-boot-dmesg-no-timestamp.txt 2007-06-22 15:54:18.0 +1000
@@ -203,14 +203,11 @@
 pnp: the driver 'i8042 aux' has been registered
 pnp: match found with the PnP device '00:01' and the driver 'i8042 aux'
 at 0x60,0x64 irq 1,12
-i8042.c: Detected active multiplexing controller, rev 1.1.
 serio: i8042 KBD port at 0x60,0x64 irq 1
-serio: i8042 AUX0 port at 0x60,0x64 irq 12
-serio: i8042 AUX1 port at 0x60,0x64 irq 12
-serio: i8042 AUX2 port at 0x60,0x64 irq 12
-serio: i8042 AUX3 port at 0x60,0x64 irq 12
+serio: i8042 AUX port at 0x60,0x64 irq 12
 mice: PS/2 mouse device common for all mice
 input: PC Speaker as /class/input/input0
+input: AT Translated Set 2 keyboard as /class/input/input1
 pnp: the driver 'rtc_cmos' has been registered
 pnp: match found with the PnP device '00:03' and the driver 'rtc_cmos'
 rtc_cmos: dev (254:0)

I've been able to log in remotely after suspending to ram, and see the "failed 
to resume active multiplexor" message in dmesg at that stage. Dmitry (or 
others), is this a known issue? I'm more than happy to probe further if not.

In case it's relevant, the other issue is that sometimes the hard drive stays 
on constantly and the system becomes unresponsive. The controller is an 
ALI15X3. I'm using the old drivers.

Nigel


pgpbwTLGhtZhI.pgp
Description: PGP signature


Failure to properly reinit i8042 post suspend-to-ram

2007-06-22 Thread Nigel Cunningham
Hi.

I have recently begun to try and use suspend to ram more, and have an 
intermittent problem. Actually, it's a couple of (possibly related) problems, 
but I'll start with the one that's easiest.

Sometimes, when I resume, the keyboard stops responding. I then need to hold 
down the power button for 4 seconds. At the next boot, things are still not 
right. The i8042 controller seems to be confused about it's mode, because I 
get the following differences in dmesg to a 'normal' boot:

--- good-boot-dmesg-no-timestamp.txt2007-06-22 15:54:03.0 +1000
+++ problem-boot-dmesg-no-timestamp.txt 2007-06-22 15:54:18.0 +1000
@@ -203,14 +203,11 @@
 pnp: the driver 'i8042 aux' has been registered
 pnp: match found with the PnP device '00:01' and the driver 'i8042 aux'
 at 0x60,0x64 irq 1,12
-i8042.c: Detected active multiplexing controller, rev 1.1.
 serio: i8042 KBD port at 0x60,0x64 irq 1
-serio: i8042 AUX0 port at 0x60,0x64 irq 12
-serio: i8042 AUX1 port at 0x60,0x64 irq 12
-serio: i8042 AUX2 port at 0x60,0x64 irq 12
-serio: i8042 AUX3 port at 0x60,0x64 irq 12
+serio: i8042 AUX port at 0x60,0x64 irq 12
 mice: PS/2 mouse device common for all mice
 input: PC Speaker as /class/input/input0
+input: AT Translated Set 2 keyboard as /class/input/input1
 pnp: the driver 'rtc_cmos' has been registered
 pnp: match found with the PnP device '00:03' and the driver 'rtc_cmos'
 rtc_cmos: dev (254:0)

I've been able to log in remotely after suspending to ram, and see the failed 
to resume active multiplexor message in dmesg at that stage. Dmitry (or 
others), is this a known issue? I'm more than happy to probe further if not.

In case it's relevant, the other issue is that sometimes the hard drive stays 
on constantly and the system becomes unresponsive. The controller is an 
ALI15X3. I'm using the old drivers.

Nigel


pgpbwTLGhtZhI.pgp
Description: PGP signature