All of lore.kernel.org
 help / color / mirror / Atom feed
* Issues detecting i8042 AUX port
@ 2009-10-06 14:24 Peter Urbanec
  2009-10-08 21:17 ` Jiri Kosina
  0 siblings, 1 reply; 6+ messages in thread
From: Peter Urbanec @ 2009-10-06 14:24 UTC (permalink / raw)
  To: linux-input

I have come across an issue that appears to be either timing sensitive
or possibly a race condition when it comes to detecting i8042 AUX port.

The full story is at http://bugs.gentoo.org/show_bug.cgi?id=287019
including attachments that contain the results of dmesg output with
i8042.debug turned on.

In a nutshell, I can run the same kernel on the same hardware and on
some boots the AUX port will not be detected and on other boots it will
come up fine. So far the only suspicion I have is that the
initialisation of USB ports and/or SATA disks may cause some kind of
delay that interferes with the i8042 detection of the AUX port.

It was suggested that I try adding my machine's DMI information to the
noloop exception table. I do not believe that doing so makes much sense,
since this is an intermittent problem, not an outright inability to
raise the AUX IRQ.

Any ideas?


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Issues detecting i8042 AUX port
  2009-10-06 14:24 Issues detecting i8042 AUX port Peter Urbanec
@ 2009-10-08 21:17 ` Jiri Kosina
  2009-10-29 12:25   ` Peter Urbanec
  0 siblings, 1 reply; 6+ messages in thread
From: Jiri Kosina @ 2009-10-08 21:17 UTC (permalink / raw)
  To: Peter Urbanec; +Cc: linux-input

On Wed, 7 Oct 2009, Peter Urbanec wrote:

> I have come across an issue that appears to be either timing sensitive
> or possibly a race condition when it comes to detecting i8042 AUX port.
> 
> The full story is at http://bugs.gentoo.org/show_bug.cgi?id=287019
> including attachments that contain the results of dmesg output with
> i8042.debug turned on.
> 
> In a nutshell, I can run the same kernel on the same hardware and on
> some boots the AUX port will not be detected and on other boots it will
> come up fine. So far the only suspicion I have is that the
> initialisation of USB ports and/or SATA disks may cause some kind of
> delay that interferes with the i8042 detection of the AUX port.
> 
> It was suggested that I try adding my machine's DMI information to the
> noloop exception table. I do not believe that doing so makes much sense,
> since this is an intermittent problem, not an outright inability to
> raise the AUX IRQ.
> 
> Any ideas?

Does booting with 'i8042.noloop' improve the situation?

-- 
Jiri Kosina
SUSE Labs, Novell Inc.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Issues detecting i8042 AUX port
  2009-10-08 21:17 ` Jiri Kosina
@ 2009-10-29 12:25   ` Peter Urbanec
  2009-10-29 17:02     ` Dmitry Torokhov
  2009-11-02 14:33     ` Jiri Kosina
  0 siblings, 2 replies; 6+ messages in thread
From: Peter Urbanec @ 2009-10-29 12:25 UTC (permalink / raw)
  To: linux-input; +Cc: Jiri Kosina

Jiri Kosina wrote:
> On Wed, 7 Oct 2009, Peter Urbanec wrote:
>> In a nutshell, I can run the same kernel on the same hardware and on
>> some boots the AUX port will not be detected and on other boots it will
>> come up fine.
> 
> Does booting with 'i8042.noloop' improve the situation?

Jirko,

Thanks for the suggestion. I have been testing the i8042.noloop 
workaround for a few weeks now. So far I have not not experienced any 
problems when booting with that option. I would say that the workaround 
can be declared as being effective.

I also applied Dmitry's patch to log the timeout condition when 
detecting the AUX port. Without the i8042.noloop option, the AUX port 
detection fails intermittently, but when it does, it causes an aux irq 
test timeout, which coincides with uhci_hcd USB hub initialisation. 
Perhaps the USB code somehow causes the loss of this interrupt.

Adding the DMI info for the machine to the i8042_dmi_noloop_table is 
perhaps not the most correct fix for the underlying problem, but it does 
get results.

Here is the relevant dmidecode data for the laptop:

Handle 0x0001, DMI type 1, 27 bytes
	Header and Data:
		01 1B 01 00 01 02 03 04 43 4E 46 37 33 38 35 30
		51 44 00 1B 24 AC 45 81 06 05 06
	Strings:
		48 65 77 6C 65 74 74 2D 50 61 63 6B 61 72 64 00
		"Hewlett-Packard"
		48 50 20 50 61 76 69 6C 69 6F 6E 20 64 76 39 35
		30 30 20 4E 6F 74 65 62 6F 6F 6B 20 50 43 20 20
		20 20 00
		"HP Pavilion dv9500 Notebook PC    "
		52 65 76 20 31 00
		"Rev 1"
		43 4E 46 37 33 38 35 30 51 44 00
		"CNF73850QD"
		47 53 37 34 38 55 41 23 41 42 41 20 00
		"GS748UA#ABA "
		31 30 33 43 5F 35 33 33 35 4B 56 00
		"103C_5335KV"

Best regards,

	Peter Urbanec

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Issues detecting i8042 AUX port
  2009-10-29 12:25   ` Peter Urbanec
@ 2009-10-29 17:02     ` Dmitry Torokhov
  2009-11-02 14:33     ` Jiri Kosina
  1 sibling, 0 replies; 6+ messages in thread
From: Dmitry Torokhov @ 2009-10-29 17:02 UTC (permalink / raw)
  To: Peter Urbanec; +Cc: linux-input, Jiri Kosina

On Thursday 29 October 2009 05:25:52 am Peter Urbanec wrote:
> Jiri Kosina wrote:
> > On Wed, 7 Oct 2009, Peter Urbanec wrote:
> >> In a nutshell, I can run the same kernel on the same hardware and on
> >> some boots the AUX port will not be detected and on other boots it will
> >> come up fine.
> >
> > Does booting with 'i8042.noloop' improve the situation?
> 
> Jirko,
> 
> Thanks for the suggestion. I have been testing the i8042.noloop
> workaround for a few weeks now. So far I have not not experienced any
> problems when booting with that option. I would say that the workaround
> can be declared as being effective.
> 
> I also applied Dmitry's patch to log the timeout condition when
> detecting the AUX port. Without the i8042.noloop option, the AUX port
> detection fails intermittently, but when it does, it causes an aux irq
> test timeout, which coincides with uhci_hcd USB hub initialisation.
> Perhaps the USB code somehow causes the loss of this interrupt.
> 
> Adding the DMI info for the machine to the i8042_dmi_noloop_table is
> perhaps not the most correct fix for the underlying problem, but it does
> get results.
> 

I ended up just disabling aux irq delivery test in 2.6.32 on all laptops and 
portables (as long as they have sane PNP data)... There are just too many 
failures and the vast majority of them use PS/2 touchpads/trackpoints.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Issues detecting i8042 AUX port
  2009-10-29 12:25   ` Peter Urbanec
  2009-10-29 17:02     ` Dmitry Torokhov
@ 2009-11-02 14:33     ` Jiri Kosina
  2009-11-08  4:22       ` Peter Urbanec
  1 sibling, 1 reply; 6+ messages in thread
From: Jiri Kosina @ 2009-11-02 14:33 UTC (permalink / raw)
  To: Peter Urbanec; +Cc: linux-input

On Thu, 29 Oct 2009, Peter Urbanec wrote:

> > On Wed, 7 Oct 2009, Peter Urbanec wrote:
> > > In a nutshell, I can run the same kernel on the same hardware and on
> > > some boots the AUX port will not be detected and on other boots it will
> > > come up fine.
> > 
> > Does booting with 'i8042.noloop' improve the situation?
> 
> Jirko,
> 
> Thanks for the suggestion. I have been testing the i8042.noloop workaround for
> a few weeks now. So far I have not not experienced any problems when booting
> with that option. I would say that the workaround can be declared as being
> effective.
> 
> I also applied Dmitry's patch to log the timeout condition when detecting the
> AUX port. Without the i8042.noloop option, the AUX port detection fails
> intermittently, but when it does, it causes an aux irq test timeout, which
> coincides with uhci_hcd USB hub initialisation. Perhaps the USB code somehow
> causes the loss of this interrupt.
> 
> Adding the DMI info for the machine to the i8042_dmi_noloop_table is perhaps
> not the most correct fix for the underlying problem, but it does get results.
> 
> Here is the relevant dmidecode data for the laptop:

Thanks for providing the data.

Does 2.6.32 work out of the box without any modifications? Dmitry added 
generic blacklist entry for all notebook chasis types, so 2.6.32 should 
have solved it for you.

Thanks,

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Issues detecting i8042 AUX port
  2009-11-02 14:33     ` Jiri Kosina
@ 2009-11-08  4:22       ` Peter Urbanec
  0 siblings, 0 replies; 6+ messages in thread
From: Peter Urbanec @ 2009-11-08  4:22 UTC (permalink / raw)
  To: linux-input

Jiri Kosina wrote:
> Does 2.6.32 work out of the box without any modifications? Dmitry added 
> generic blacklist entry for all notebook chasis types, so 2.6.32 should 
> have solved it for you.

I currently don't have the resources to do much testing, but once 2.6.32 
is released and available as a Gentoo package, I'll re-test without the 
i8042.noloop option.

I expect that Dmitry's fix will be effective, but if there are any 
issues, I'll be back with more info.


Thanks.

	Peter Urbanec

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2009-11-08  4:22 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-10-06 14:24 Issues detecting i8042 AUX port Peter Urbanec
2009-10-08 21:17 ` Jiri Kosina
2009-10-29 12:25   ` Peter Urbanec
2009-10-29 17:02     ` Dmitry Torokhov
2009-11-02 14:33     ` Jiri Kosina
2009-11-08  4:22       ` Peter Urbanec

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.