Re: [PATCH] Input: synaptics - add retry mechanism for reconnect
I'll have someone test it out. Thanks for the patch. On 04/10/2013 01:40 AM, Chung-Yih Wang (王崇懿) wrote: > Hi Eric Miao, James Leddy and Daniel Manrique, > > If possible, could you give it a try for the patch I have on your device(s)? > https://patchwork.kernel.org/patch/2156601/ > > I think we may address similar issue here. The synaptics device may not > respond to the commands in synaptics_reconnect() for stress test of > suspend/resume, so my patch is trying to do > the 'retry' for all requests in the reconnect path if one fails. > > > > On Wed, Feb 20, 2013 at 2:50 AM, Dmitry Torokhov > mailto:dmitry.torok...@gmail.com>> wrote: > > Hi Chung-yih, > > On Mon, Feb 18, 2013 at 04:40:21PM +0800, Chung-yih Wang wrote: > > On the Samsung Series 5 Chromebook, the Synaptics ClickPad will > sometimes not > > send an "0xFA" PS/2 ACK in response to a command byte during the > reconnect > > sequence following a resume from suspend. From our experiments, > the failure can > > happen during any byte of any of the commands in the reconnect batch. > > > > This failure results in a timeout in the psmouse driver. In > addition, the > > ClickPad will often also respond to the next PS/2 command byte > with an "0xFE" > > PS/2 RESEND response. > > Since you control the firmware of the device can you figure out under > what condition the touchpad does not acknowledge the commands sent to it > and fix it there? > > Thanks. > > -- > Dmitry > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1][RESUBMIT] input: fix weird issue of synaptics psmouse sync lost after resume
From: Eric Miao
In summary, the symptom is intermittent key events lost after resume
on some machines with synaptics touchpad (seems this is synaptics _only_),
and key events loss is due to serio port reconnect after psmouse sync lost.
Removing psmouse and inserting it back during the suspend/resume process
is able to work around the issue, so the difference between
psmouse_connect()
and psmouse_reconnect() is the key to the root cause of this problem.
After comparing the two different paths, synaptics driver has its own
implementation of synaptics_reconnect(), and the missing psmouse_probe()
seems significant, the patch below added psmouse_probe() to the reconnect
process, and has been verified many times that the issue could not be
reliably
reproduced.
There are two PS/2 commands in psmouse_probe():
1. PSMOUSE_CMD_GETID
2. PSMOUSE_CMD_RESET_DIS
Only the PSMOUSE_CMD_GETID seems to be significant. The
PSMOUSE_CMD_RESET_DIS is irrelevant to this issue after trying
several times. So we have only implemented this patch to issue
the PSMOUSE_CMD_GETID so far.
Tested-by: Daniel Manrique
Signed-off-by: James M Leddy
---
drivers/input/mouse/synaptics.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/mouse/synaptics.c
b/drivers/input/mouse/synaptics.c
index 12d12ca..3438a9d 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -1355,6 +1355,7 @@ static int synaptics_reconnect(struct psmouse
*psmouse)
{
struct synaptics_data *priv = psmouse->private;
struct synaptics_data old_priv = *priv;
+ unsigned char param[2];
int retry = 0;
int error;
@@ -1370,6 +1371,7 @@ static int synaptics_reconnect(struct psmouse
*psmouse)
*/
ssleep(1);
}
+ ps2_command(&psmouse->ps2dev, param, PSMOUSE_CMD_GETID);
error = synaptics_detect(psmouse, 0);
} while (error && ++retry < 3);
-- 1.7.9.5
Re: [PATCH 0/1][RESUBMIT] input: fix weird issue of synaptics psmouse sync lost
I meant to send this to linux-input On 04/09/2013 08:30 PM, James M Leddy wrote: > We have been using this patch in Ubuntu kernels for 5 months now > without issue. Since patch author Eric Miao no longer works for us, > I'm sending to the list so that other distros can take advantage of > this. > > Last we left off, the suggestion was to make this generic across the > entire range of protocols, not just synaptics. I'm against this for > two reasons. The first is that I don't want to have to ask for > additional testing (I don't have access to the machine). The second > and far more important reason is that I am afraid that this will break > other non-synaptics touchpads, and even though we have a wide range of > hardware, it is impossible to guarantee that it'll work on everything > out there. I will do it however if it's the way we need to go with > this. > > Please let me know what you think, or if you need any additional > information or testing. > > James M Leddy (1): > input: fix weird issue of synaptics psmouse sync lost > after resume > > drivers/input/mouse/synaptics.c |2 ++ > 1 file changed, 2 insertions(+) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1][RESUBMIT] input: fix weird issue of synaptics psmouse sync lost after resume
From: Eric Miao
In summary, the symptom is intermittent key events lost after resume
on some machines with synaptics touchpad (seems this is synaptics _only_),
and key events loss is due to serio port reconnect after psmouse sync lost.
Removing psmouse and inserting it back during the suspend/resume process
is able to work around the issue, so the difference between psmouse_connect()
and psmouse_reconnect() is the key to the root cause of this problem.
After comparing the two different paths, synaptics driver has its own
implementation of synaptics_reconnect(), and the missing psmouse_probe()
seems significant, the patch below added psmouse_probe() to the reconnect
process, and has been verified many times that the issue could not be reliably
reproduced.
There are two PS/2 commands in psmouse_probe():
1. PSMOUSE_CMD_GETID
2. PSMOUSE_CMD_RESET_DIS
Only the PSMOUSE_CMD_GETID seems to be significant. The
PSMOUSE_CMD_RESET_DIS is irrelevant to this issue after trying
several times. So we have only implemented this patch to issue
the PSMOUSE_CMD_GETID so far.
Tested-by: Daniel Manrique
Signed-off-by: James M Leddy
---
drivers/input/mouse/synaptics.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index 12d12ca..3438a9d 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -1355,6 +1355,7 @@ static int synaptics_reconnect(struct psmouse *psmouse)
{
struct synaptics_data *priv = psmouse->private;
struct synaptics_data old_priv = *priv;
+ unsigned char param[2];
int retry = 0;
int error;
@@ -1370,6 +1371,7 @@ static int synaptics_reconnect(struct psmouse *psmouse)
*/
ssleep(1);
}
+ ps2_command(&psmouse->ps2dev, param, PSMOUSE_CMD_GETID);
error = synaptics_detect(psmouse, 0);
} while (error && ++retry < 3);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1][RESUBMIT] input: fix weird issue of synaptics psmouse sync lost
We have been using this patch in Ubuntu kernels for 5 months now without issue. Since patch author Eric Miao no longer works for us, I'm sending to the list so that other distros can take advantage of this. Last we left off, the suggestion was to make this generic across the entire range of protocols, not just synaptics. I'm against this for two reasons. The first is that I don't want to have to ask for additional testing (I don't have access to the machine). The second and far more important reason is that I am afraid that this will break other non-synaptics touchpads, and even though we have a wide range of hardware, it is impossible to guarantee that it'll work on everything out there. I will do it however if it's the way we need to go with this. Please let me know what you think, or if you need any additional information or testing. James M Leddy (1): input: fix weird issue of synaptics psmouse sync lost after resume drivers/input/mouse/synaptics.c |2 ++ 1 file changed, 2 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Not just RealTek 8139/dhcpcd..epic100 broken also
Kernel 2.4.2(working) 2.4.4(broken), Xeon 2-way SMP 400 mhz, 128 mem, gcc 2.95.3, DHCP Client Daemon v.1.3, Mandrake 7.2 2.4.4 is broken with my epic100/dhcpcd2.4.2 works fine. I copied /lib/module/2.4.2../epic100.o to /lib/modules/2.4.4/../epic100.o with no success. Messages error: Apr 29 15:44:24 windeath kernel: eth0: Transmit timeout using MII device, Tx status 0003. Followed by more of the same except with status 000b. Unlike the realtek errors a network stop/start/restart doesn't help. Looking at the patch for 2.4.4 shows one tiny change to epic100. -- James M. aka "Dart" - 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: BUG Report 2.4.0-test11-pre3: NMI Watchdoch detected LOCKUP atCPU[01]
Gert Wollny wrote:
>
> Hello,
>
> i think it got it nailed, please try the attached patch (it is against
> 11-pre4, but it should work against all test11).
>
> Explanation:
> with test7-pre6 in the imm-module the new scsi - code was enabled (see
> imm.h).
> This causes the locking of the io_request_lock in scsi_register_host
> (scsi.c) during detection of the ZIP drive. Seems, that the request_module
> call for the parport_pc doesn't like this.
> The patch does, what the comment in scsi.c suggests: Enable the new code
> only, after the drive is detected.
>
> Have a nice day
Thank you Gert. I turned off Winbond support as before and it truly is
"safe to say no" now. Your patch seems to work. Good Job.
Still outstanding:
If (mode=SPP && Zip100) Log_msg("Spp is godawful slow, set for EPP in
bios");
// I don't know off top of my head if Zip250 can use ECP or not
// Zip100 is EPP at best
Imm driver reports Zip100 at 101 MB
ECP/EPP setting in Bios yields SPP for Zip100. 1284 spec says you should
be able to set mode 100 to get EPP and even tho it's a M$ extension most
chipsets should support it.
Speed Sucks: Hdparm reports 496k/sec for EPP on a 64 MB buffered disk
read. 1284 spec says 500k/2 MB for EPP and Iomega says it can do 1.4 MB
sustained for Zip100. Not that it matters but SPP runs 96k/sec.
I'm coding up a parport-poker to get familiar then I'll take a stab at
these if someone doesn't beat me to it.
>
> Gert
>
>
>
>
> Name: imm-lockup.patch
>imm-lockup.patch Type: Plain Text (TEXT/PLAIN)
> Encoding: BASE64
>Description: the patch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Parport/IMM/Zip Oops Revisited -- Winbond
Gert Wollny wrote: > > On Tue, 14 Nov 2000, James M wrote: > >Was just trying to find out why I can mount in 11pre1 and 11pre2 when > > Gert can't mount at all, so I removed my VFAT factory formatted zipdisk > > and put in an Ext2 formatted one.**BOOM** > The configure help for the Winbond SuperIO states: "Saying Y here enables some probes for Super-IO chipsets in order to find out things like base addresses, IRQ lines and DMA channels. It is safe to say N." Enabling this allows me to mount both VFAT and EXT2 in 11pre3, it appears it should no longer be marked "Experimental" or "Safe to say No" in the case of Zipdrives at least. Dunno what time it is over there but could you give this a try when you get a chance? My port is still misdetected but at least I didn't have to fsck this time...;=) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Parport/IMM/Zip Oops Revisited -- Filesys problem? Viro pleaselook
Gert Wollny wrote: > > Actually i never tried to mount in my testings, just did "modprobe imm". I > did not even load sd.o, which reads the size of the medium. Output after > successfull modprobe: > kernel: imm: Version 2.04 (for Linux 2.4.0) > kernel: imm_connect 1 > kernel: imm: Found device at ID 6, Attempting to use EPP 32 bit > kernel: imm: Found device at ID 6, Attempting to use PS/2 > kernel: imm: Communication established at 0x378 with ID 6 using PS/2 > kernel: device_check 0 > kernel: scsi1 : Iomega VPI2 (imm) interface > kernel: scsi : 2 hosts. > kernel: Vendor: IOMEGAModel: ZIP 250 Rev: J.45 > kernel: Type: Direct-Access ANSI SCSI revision: 02 > > Even without a disk this works (if parport_pc is preloaded). > > Anyway the disk in the drive was a 250MB vfat formatted one. But OTOH, the > oops trace points to ext2. > > For completeness: With the disk "modprobe sd" gives As you say, for completeness: SCSI subsystem driver Revision: 1.00 parport0: PC-style at 0x378 [PCSPP] parport0: irq 7 detected imm: Version 2.04 (for Linux 2.4.0) imm: Found device at ID 6, Attempting to use EPP 32 bit imm: Found device at ID 6, Attempting to use SPP imm: Communication established at 0x378 with ID 6 using SPP scsi0 : Iomega VPI2 (imm) interface Vendor: IOMEGAModel: ZIP 100 Rev: P.05 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi removable disk sda at scsi0, channel 0, id 6, lun 0 SCSI device sda: 196608 512-byte hdwr sectors (101 MB) sda: Write Protect is off sda: sda4 As I noted in a previous posting to the list my Communication type is misdetected as SPP when it really is EPP. The 101 MB size looks fishy also as it usually reads 96 MB IIRC. > > kernel: Detected scsi removable disk sda at scsi1, channel 0, id 6, lun 0 > kernel: SCSI device sda: hdwr sector= 512 bytes. Sectors= 489532 [239 MB] [0.2 GB] > kernel: sda: Write Protect is off > kernel: sda: sda4 > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Parport/IMM/Zip Oops Revisited -- Filesys problem? Viro please look
James M wrote: Was just trying to find out why I can mount in 11pre1 and 11pre2 when Gert can't mount at all, so I removed my VFAT factory formatted zipdisk and put in an Ext2 formatted one.**BOOM** Al, my original oops report is here: http://boudicca.tux.org/hypermail/linux-kernel/2000week42/1240.html Summary: Test10 is broken for both filesystems (sick of fsck'n-not confirmed) 11pre1-pre2 work for VFAT broken for EXT2 11pre3 is broken for both filesystems Anything you want me to try just let me know, I've already been through about 100 fscks, a few more won't hurt. BTW I have a list of 23 common non-obvious files that changed in test10/11pre1 and 11pre2/pre3, say the word and I'll mail the list. James M. --30 Gig of fsck sucks-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re:test11-pre1 Parport/IMM/Zip Oops fixed -- Are we in Florida?
James M wrote: > >My previously reported Parport/Zip Oops seems to have gone away. I > suspect the SMP race fixs were the culprit...thank you. >However my parport is still misdetected as SPP by the IMM driver when > it is actually set to EPP. This is an Epox/SMP Xeon (400 mhz), EP-GXB-M > with an Award Bios and Winbond Super I/O Multi controller. Move that one back into the broken column please. It happened between 11pre2 and 11pre3. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re:test11-pre1 - Parport/IMM/Zip Oops fixed
My previously reported Parport/Zip Oops seems to have gone away. I suspect the SMP race fixs were the culprit...thank you. However my parport is still misdetected as SPP by the IMM driver when it is actually set to EPP. This is an Epox/SMP Xeon (400 mhz), EP-GXB-M with an Award Bios and Winbond Super I/O Multi controller. Now if we could just do something about those 10 fps in quake that I lost since 2.3.4x;=) James M. aka "Dart" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: lockup with parport_pc on 2.4.0-test10-pre1]
Kernel test10-pre2, Dual Xeon PII(400 mhz), Mandrake 7.1, microde
updates enabled
Mounting my zipdrive(IMM) will result in something like this:
Sysrq does not work, machine is completely dead after 20-40 seconds.The
usual progession is CPU's lockup, modprobe dies, kflushed and syslogd
follow shortly afterwards.
NMI Watchdog detected LOCKUP on CPU0, registers:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00200086
eax: 2101 ebx: 00200202 ecx: 0001 edx: 001f8f79
esi: 2101 edi: 0084 ebp: 00089e60 esp: c60e7e98
ds: 0018 es: 0018 ss: 0018
Process modprobe (pid: 1207, stackpage=c60e7000)
Stack: c7eb4cc0 0001 c0163bfa 2101 c7eb4cc0
c60e7f0c
c0163db1 c7eb4cc0 c7eb4cc0 0001 000c 1000
c01342a2
0001 c60e7f0c c7fa5a64 c1197a7c c7c7da1c
1000
Call Trace: [] [] [] []
[] [>EIP; c01d7243<=
Trace; c0163bfa
Trace; c0163db1
Trace; c01342a2
Trace; c0153773
Trace; c01530a8
Code; c01d7243
<_EIP>:
Code; c01d7243<=
0: 80 3d c4 67 21 c0 00 cmpb $0x0,0xc02167c4 <=
Code; c01d724a
7: f3 90 repz nop
Code; c01d724c
9: 7e f5 jle0 <_EIP>
Code; c01d724e
b: e9 76 bd f8 ffjmpfff8bd86 <_EIP+0xfff8bd86>
c0162fc9
Code; c01d7253
10: 80 3d 34 2a 00 00 00 cmpb $0x0,0x2a34
NMI Watchdog detected LOCKUP on CPU0, registers:
CPU:0
EIP:0010:[]
EFLAGS: 00200086
eax: 2105 ebx: 00200206 ecx: 0005 edx: 00bc1f49
esi: 2105 edi: 0084 ebp: 0010 esp: c1263f7c
ds: 0018 es: 0018 ss: 0018
Process kflushd (pid: 4, stackpage=c1263000)
Stack: c4f042c0 0001 c0163bfa 2105 c4f042c0 0001
c1263fd8
c0163db1 0001 c4f042c0 0029 c7a9b380 0001 c1262000
c013560a
Warning (Oops_read): Code line not seen, dumping what data is available
>>EIP; c01d7243<=
If anyone has a patch to test let me knowI'll try anything once,
twice if I like it...:=)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
