2.6.24-8 Introduces Network Issue

[David R. Hedges]

I'll apologize right off the bat for lacking more concrete information about this bug, but perhaps you can guide me in isolating the issue better than I could on my own.

After upgrading my kernel (in hardy) to linux-image-2.6.24-8-generic from linux-image-2.6.24-7-generic, I noticed that when using synergyc, input 'hangs' on a regular basis. That is to say that when I move my mouse from the synergy server to the hardy client system, the mouse will only move intermittently, and keyboard input is similarly fragmented. None of the movements or keystrokes are ever actually lost (Synergy uses TCP, so that's expected), but movement is sporadic and jumpy, and keystrokes seem to occasionally get 'buffered' and then arrive all at the same time. I "confirmed" this was a kernel issue by rebooting and selecting the 2.6.24-7 kernel, and the issue disappeared again.

Also potentially of interest is that when I tried to diagnose the behavior by running a packet capture through Wireshark on the problematic client, the issue would never appear while capturing from the nic. Immediately after ending the capture, the issue would again manifest itself.

Even while the synergyc input was 'hung,' there was no apparent packet loss, as measured by a ping flood to the hardy machine.

Release: 8.04/hardy
Kernel: linux-image-2.6.24-8-generic 2.6.24-8.14
Architecture: amd64 / x86_64

Hardware (as queried from 2.6.24-7):
Lenovo Thinkpad T61
00:19.0 Ethernet controller: Intel Corporation 82566MM Gigabit Network Connection (rev 03)
 Subsystem: Lenovo ThinkPad T61
 Flags: bus master, fast devsel, latency 0, IRQ 503
 Memory at fe200000 (32-bit, non-prefetchable) [size=128K]
 Memory at fe225000 (32-bit, non-prefetchable) [size=4K]
 I/O ports at 1840 [size=32]
 Capabilities: [c8] Power Management version 2
 Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+

$ ethtool -i eth0
driver: e1000
version: 7.3.20-k2-NAPI
firmware-version: 0.3-0
bus-info: 0000:00:19.0

$ ethtool -d eth0
MAC Registers
-------------
0x00000: CTRL (Device control register) 0x00140240
      Endian mode (buffers): little
      Link reset: normal
      Set link up: 1
      Invert Loss-Of-Signal: no
      Receive flow control: disabled
      Transmit flow control: disabled
      VLAN mode: disabled
      Auto speed detect: disabled
      Speed select: 1000Mb/s
      Force speed: no
      Force duplex: no
0x00008: STATUS (Device status register) 0x00080462
      Duplex: half
      Link up: link config
      TBI mode: enabled
      Link speed: 100Mb/s
      Bus type: PCI Express
      Port number: 0
0x00100: RCTL (Receive control register) 0x00008002
      Receiver: enabled
      Store bad packets: disabled
      Unicast promiscuous: disabled
      Multicast promiscuous: disabled
      Long packet: disabled
      Descriptor minimum threshold size: 1/2
      Broadcast accept mode: accept
      VLAN filter: disabled
      Canonical form indicator: disabled
      Discard pause frames: filtered
      Pass MAC control frames: don't pass
      Receive buffer size: 2048
0x02808: RDLEN (Receive desc length) 0x00001000
0x02810: RDH (Receive desc head) 0x00000087
0x02818: RDT (Receive desc tail) 0x00000085
0x02820: RDTR (Receive delay timer) 0x00000000
0x00400: TCTL (Transmit ctrl register) 0x3103F0FA
      Transmitter: enabled
      Pad short packets: enabled
      Software XOFF Transmission: disabled
      Re-transmit on late collision: enabled
0x03808: TDLEN (Transmit desc length) 0x00001000
0x03810: TDH (Transmit desc head) 0x000000DF
0x03818: TDT (Transmit desc tail) 0x000000DF
0x03820: TIDV (Transmit delay timer) 0x00000008
PHY type: unknown

When queried from 2.6.24-8, only the following values change (which appear to change between calls to that command anyway):
0x02810: RDH (Receive desc head) 0x00000029
0x02818: RDT (Receive desc tail) 0x00000027

0x03810: TDH (Transmit desc head) 0x00000003
0x03818: TDT (Transmit desc tail) 0x00000003

[Guillermo Pérez (bisho)]

Perhaps it's related with 2.6.24-8 is the first tickless (CONFIG_NO_HZ) kernel.

I don't use synergyc, so I can't test it, but I didn't noticed any network problem with this kernel yet.

[Michael Frederick (x-launchpad-michaelfrederick-org)]

I've noticed identical behavior with this kernel and synergyc, so it's definitely not an isolated incident.

[John Ferlito (johnf-inodes)]

I can also confirm the same behaviour. Just rebooted into 2.6.24-7 and synergy is working fine again.

[Leann Ogasawara (leannogasawara)]

A few things you can try. . .

1) 2.6.24-10 was recently released so you may want test the latest update.
2) If you think it is related to the CONFIG_NO_HZ option being enbaled, you can play with building and booting your own kernel with this option disabled. Instructions on how to build your own kernel can be found here: https://wiki.ubuntu.com/KernelTeam/GitKernelBuild. But rather than using the upstream kernel source as outlined in that wiki, use Ubuntu's kernel source. Hope that helps.

Thanks.

[PC-Ente (pcente)]

I can also confirm this problem, even with the new 2.6.24-10-generic Kernel. Maybe I'll build a kernel with CONFIG_NO_HZ to check if that is the problem

[Amber-Willow (amber-casema)]

My synergyc is acting up in the same way, also since the update to hardy. I'd like to add to the previous information that indeed, no packets are lost. All input during "hangtime" is still going through. For example, when typing, all text typed during hangtime will appear once the application resumes.

I've already tried messing with the priority of the process, which changed nothing.

I haven't tried building a new kernel yet with CONFIG_NO_HZ yet, which i might try later when i have more time on my hands

[PC-Ente (pcente)]

I build a kernel wiht git and CONFIG_NO_HZ diseablet but synergy "hung"s again. So it is not the CONFIG_NO_HZ option. Another point is, that tickless option is enabled since 2.6.22, (changelog) and it workt with Gutsy and 2.6.22-14 and even with 2.6.24-7...

here my own kernel-config

[PC-Ente (pcente)]

Sry, but forgot to say that it seemed that the synergy workt fine while compiling the new kernel, mean's while the CPU was working... there was no "hung" just a litte lag that could be from the CPU because its had 100% working in System-control.

[Amber-Willow (amber-casema)]

I've found a workaround (at least here)
when i sudo the process, it doesnt seem to happen anymore (not yet at least)
from what a friend of mine said, it might be buffer related

I know its no permanent solution, but maybe this info will help someone find one.

[rp (peinthor)]

i also have this problem with a vanilla 2.6.24.3 self build kernel.

The funny thing is, if you open the System Monitor-Resource view, the mouse is smooth, as soon you close the system monitor, synergy is more or less not usable anymore.

The workaround running synergyc as root is also working here, thanks for the tip!

I hope someone finds the real reason, or it is fixed in the kernel.

[jnewton (nevion)]

Also affected and completely up to date as of today (with both computers running 2.6.24-11). I'm using with a t61p as the server to a desktop as the client.

Listed workaround with starting synclient as root works but this feels dirty. Any idea to the cause of the problem? Seems rather strange to be NO_HZ related and both cpus are waking up quite a bit per second.

[Geoffrey Pursell (geoffp)]

I also suffer from this bug. I'm using Mac OS X as my synergy server, and Hardy as my client. The workaround of running "sudo synergyc" works for me, but can't be a long-term solution.

[IC Raibow (icrbow)]

Got this since first try with hardy alpha 5. Works well with "sudo".

[Sebastien Estienne (sebest)]

I can confirm the bug, and that "sudo" is a workaround.

I've strace synergyc with and without sudo. i attached to log file.

With sudo it works, it only hangs 2/3 times at the begining and then it works perfectly

When it's hanged i have a lot of:
6468 read(4, "\0\0\0\10DMMV\0\353\2\16", 4096) = 12
6468 read(4, 0xb73ea298, 4096) = -1 EAGAIN (Resource temporarily unavailable)
6468 select(8, [4 7], NULL, [4], NULL) = 1 (in [4])
6468 read(4, "\0\0\0\10DMMV\0\332\1\356", 4096) = 12
6468 read(4, 0xb73ea298, 4096) = -1 EAGAIN (Resource temporarily unavailable)
6468 select(8, [4 7], NULL, [4], NULL) = 1 (in [4])
6468 read(4, "\0\0\0\10DMMV\0\316\1\322", 4096) = 12
6468 read(4, 0xb73ea298, 4096) = -1 EAGAIN (Resource temporarily unavailable)
6468 select(8, [4 7], NULL, [4], NULL) = 1 (in [4])
6468 read(4, "\0\0\0\10DMMV\0\310\1\267", 4096) = 12
6468 read(4, 0xb73ea298, 4096) = -1 EAGAIN (Resource temporarily unavailable)
6468 select(8, [4 7], NULL, [4], NULL) = 1 (in [4])
6468 read(4, "\0\0\0\10DMMV\0\306\1\233", 4096) = 12

[Andy Lindeman (alindeman)]

I still experience some intermittent hanging when the process is running as root, though it's much less pronounced. I can confirm the bug, and will provide any additional information that would be helpful to debugging upon request.

[stevenschlansker (stevenschlansker)]

This looks very similar to bug #91540, in case that helps anyone. I had that problem back in the day, and now it's happening again... :(

[SanderG (q-launchpad-sander-goudswaard-com-deactivatedaccount)]

Confirmed the same here, although synergyc was running on Hardy and synergys on Windows. When switching the two, the issue does not occur (now I have the problem that typing double quotes is not possible on Windows, although I can do that on Hardy at the same time).
At least keyboard movement is more fluent.

[MikeMayer (mikehmayer)]

I am also experiencing this problem.

[Eric Munson (emunson)]

Add another me too to this. I am running the synergy client on a T61p and my servers are one of Fedora Core 8, Win XP, or Debian stable. This behavior happens on all of the servers and the sudo workaround works for me. This is still an issue running a kernel from linus's tree yesterday.

Not sure if it is related, but I ran wireshark on my FC8 server while I was seeing the problem and it reported a large number of TCP check sum errors on packets coming from client to server for synergy.

[Sebastien Estienne (sebest)]

I'm using 2.6.24-7 and have no issue running synergyc as normal user, every version >= 2.6.24-8 have this lagging behaviour.

[travis.detert (travis-detert)]

Does anyone have any suspicions that the newly released 2.6.25 is
going to help us here? It sounds like there are a lot of tweakins'
coming through the interpipes with this release... Much along the
lines of the NAS additions, (framework)?

On Thu, Mar 27, 2008 at 9:15 PM, Sebastien Estienne
<email address hidden> wrote:
> I'm using 2.6.24-7 and have no issue running synergyc as normal user,
> every version >= 2.6.24-8 have this lagging behaviour.
>
>
>
> --
> 2.6.24-8 Introduces Network Issue
> https://bugs.launchpad.net/bugs/194029
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in Source Package "linux" in Ubuntu: Incomplete
> Status in Source Package "synergy" in Ubuntu: Confirmed
>
> Bug description:
> I'll apologize right off the bat for lacking more concrete information about this bug, but perhaps you can guide me in isolating the issue better than I could on my own.
>
> After upgrading my kernel (in hardy) to linux-image-2.6.24-8-generic from linux-image-2.6.24-7-generic, I noticed that when using synergyc, input 'hangs' on a regular basis. That is to say that when I move my mouse from the synergy server to the hardy client system, the mouse will only move intermittently, and keyboard input is similarly fragmented. None of the movements or keystrokes are ever actually lost (Synergy uses TCP, so that's expected), but movement is sporadic and jumpy, and keystrokes seem to occasionally get 'buffered' and then arrive all at the same time. I "confirmed" this was a kernel issue by rebooting and selecting the 2.6.24-7 kernel, and the issue disappeared again.
>
> Also potentially of interest is that when I tried to diagnose the behavior by running a packet capture through Wireshark on the problematic client, the issue would never appear while capturing from the nic. Immediately after ending the capture, the issue would again manifest itself.
>
> Even while the synergyc input was 'hung,' there was no apparent packet loss, as measured by a ping flood to the hardy machine.
>
> Release: 8.04/hardy
> Kernel: linux-image-2.6.24-8-generic 2.6.24-8.14
> Architecture: amd64 / x86_64
>
> Hardware (as queried from 2.6.24-7):
> Lenovo Thinkpad T61
> 00:19.0 Ethernet controller: Intel Corporation 82566MM Gigabit Network Connection (rev 03)
> Subsystem: Lenovo ThinkPad T61
> Flags: bus master, fast devsel, latency 0, IRQ 503
> Memory at fe200000 (32-bit, non-prefetchable) [size=128K]
> Memory at fe225000 (32-bit, non-prefetchable) [size=4K]
> I/O ports at 1840 [size=32]
> Capabilities: [c8] Power Management version 2
> Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
>
> $ ethtool -i eth0
> driver: e1000
> version: 7.3.20-k2-NAPI
> firmware-version: 0.3-0
> bus-info: 0000:00:19.0
>
> $ ethtool -d eth0
> MAC Registers
> -------------
> 0x00000: CTRL (Device control register) 0x00140240
> Endian mode (buffers): little
> Link reset: normal
> Set link up: 1
> Invert Loss-Of-Signal: ...

[Nick Barcet (nijaba)]

it might be worth noting that while invoking synergyc with sudo does indeed seems to fix the issue, invoking it with gksudo does not seem to 8-|

[phooky (phooky)]

Hi; I encountered this issue and seem to have found a fix.

I suspect that the problem is the new scheduler in Heron. I managed to fix the problem completely by running the process with realtime priority:

chrt synergyc [... your ordinary parameters ...]

I haven't had a glitch since.

[SanderG (q-launchpad-sander-goudswaard-com-deactivatedaccount)]

I tried that, but chrt keeps the prio on 0 for me (SCHED_OTHER). When manually setting it to 99 it works but that needs sudo, and I do not want to run synergyc as root when I do not have to. I automated this by creating a file 'startsynergyc.sh' with file mode 6755 and the following contents:

/usr/bin/synergyc myserver; pgrep synergyc | sudo xargs chrt -p 99

It now works for me when running synergyc as user again.

[SanderG (q-launchpad-sander-goudswaard-com-deactivatedaccount)]

(sorry, that is still not 100% and also doen't prevent synergyc from crashing a few times a day)

[PSCArmstrSM (sarmstrong1)]

I added the following to my /etc/gdm/PreSession/Default to work-around this issue:

#Synergy Server (root)
/usr/bin/synergys --config /etc/synergy.conf &

This starts synergy automatically before login, as root. This also give me the ability to log out of my X session and still traverse to my mac.

:)

[Ned (ned-tropic)]

I'm running synergyc on hardy with kernel 2.6.24-15-generic on a Thinkpad R51. NIC is "Intel Corporation 82541GI Gigabit Ethernet Controller" according to lspci.

sudo does appear to work around the problem.

[kry10 (launchpad-marklinford)]

I compliled synergy from scratch and applied the information here:

http://sourceforge.net/tracker/index.php?func=detail&aid=1930587&group_id=59275&atid=490467

Now, synergy is very smooth, with no timeout issues.

[IC Raibow (icrbow)]

Great! Would this get into release?

[Amber-Willow (amber-casema)]

i doubt it.. I've copy pasted his "solution" below, as you can see at the end of his text, its obviously not proper coding. Its just another workaround to give it more priority. I haven't tested it myself yet, but checking for the event ever 0.01 second doesn't seem like a healthy way of making a final fix.

Amber
----from http://sourceforge.net/tracker/index.php?func=detail&aid=1930587&group_id=59275&atid=490467 ----
Date: 2008-04-01 15:50
Sender: neurohacker
Logged In: YES
user_id=19874
Originator: YES

In CEventQueue.cpp, calculating timeLeft generates values on the order of
3 to 6 seconds. When poll() is invoked, it blocks for the full time, then
operations seem to resume normally. This happens frequently enough that
synergy on my box is unusable.

To verify this was the source of the hangs, I hard-coded
CEventQueue::getEvent()'s call to m_buffer->waitForEvent(timeLeft) in
CEventQueue.cpp on line 149 to use a timeout of 0.1, and the client hangs
as often, but for a tenth of a second. To get it into a usable state
locally, I've jacked the value down to 0.01.

This is clearly not the right fix for the code written as it is. If I have
time to investigate it some more I'll send along more information or a
patch.

[SanderG (q-launchpad-sander-goudswaard-com-deactivatedaccount)]

True, but going to release with the current situation is even worse. This together with synergyc crashes multiple times a day is the most important issue I have with hardy.

[Baronek (baronek1)]

If this is regression in kernel then it was not resolved in vanila kernel 2.6.25 as I was able to reproduce it easily. Sudo workaround works.

[IC Raibow (icrbow)]

sudo workaround gives some boost, but performance is still crappy compared to 7.10.

[Mark Florian (markrian)]

And another Me Too.

I'm surprised how many people use synergy AND use hardy, pre-release!

[MikeMayer (mikehmayer)]

LOL ao drunk.

- Mike Mayer
www.mikehmayer.com

Sent from my iPhone

On Apr 18, 2008, at 8:06 PM, Mark Florian <email address hidden> wrote:

> And another Me Too.
>
> I'm surprised how many people use synergy AND use hardy, pre-release!
>
> --
> 2.6.24-8 Introduces Network Issue
> https://bugs.launchpad.net/bugs/194029
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.

[Steve Langasek (vorlon)]

Thank you for taking the time to report this problem and help to improve Ubuntu.

I believe this may be the same bug as bug #188226. Could someone who's experiencing this problem try to install the -server kernel flavor (linux-image-server or linux-server), to test whether the different scheduling options fixes this issue?

[Nick Barcet (nijaba)]

Steve Langasek wrote:
> I believe this may be the same bug as bug #188226. Could someone who's
> experiencing this problem try to install the -server kernel flavor
> (linux-image-server or linux-server), to test whether the different
> scheduling options fixes this issue?

One of my two machines is always running with a -server kernel and the
problem is the same as with the -generic machine. Sorry.

[Baronek (baronek1)]

I have disabled FAIR_GROUP_SCHED in my kernel config. Tested this on both vanila 2.6.25 and ubuntu srouces 2.6.24 (downloaded via apt today)
-- this is old config
$cat .config | grep FAIR
# CONFIG_FAIR_CGROUP_SCHED is not set
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_FAIR_USER_SCHED=y
--this is my modification
$cat .config | grep FAIR
# CONFIG_FAIR_GROUP_SCHED is not set

Issues with laggy synergy disappread. I got the idead from bug #188226 and this comment: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/188226/comments/22

[Amber-Willow (amber-casema)]

Thank you very much Baronek!
It works like a charm now, without having to sudo it :) (running on the .25 kernel)

I hope the default will be set to off soon, so that i dont have to do this for each new kernel version.

No more mouse/keyboard lag!!! :cheers:

[Sebastien Estienne (sebest)]

Maybe we should add a comment to bug #188226 about this synergy issue?

[Baronek (baronek1)]

I did not comment on that bug because what I've read they already make up their mind, so I guess they have some valid reasons.
Making people desktop unresponive could be one of them, I am not an kernel expert.

If you think that you can persuade them to do the right thing feel free to do so (and be encoureged to :)

[Beex (bweeks)]

I've also encountered this problem. The sudo workaround fixed it, but the greater kernel bug makes me anxious. Where will we see it affect hardy next?

[Sebastien Estienne (sebest)]

This bug is regression caused by a kernel change #188226

What can be done to make synergy functionnal for hardy?

[Stephen Birch (sgbirch)]

Well ... I have the released version of hardy installed and have the same problem. Using sudo workaround for now.

[Scott Wegner (swegner)]

I'm also experiencing this bug. The sudo workaround seems to fix it, but is there a way to automatically start synergy with sudo on startup?

[kayakmike (mike-thevests)]

I just upgraded two machines to 8.04 (from 7.10) and noticed that synergy is lagging on the client machine. sudo seems to fix the problem for me, but wanted to say "me too" .

[stevenschlansker (stevenschlansker)]

Is it possible that this bug is affecting other applications too? I occasionally (but not nearly as often) see similar behavior in Firefox - it hangs for a few seconds and then eventually 'catches up' and goes through all the keyboard/mouse movements in high speed (this is without synergy installed, but the behavior seems similar)

I just introduced a friend of mine to Ubuntu and he's having the problem too with other random applications.

[SireeBob (sireebob)]

Yet another "me too" from me, considering this is triaged. I was having a slightly different problem than commonly described here, because my Ubuntu Hardy laptop is the server and my desktop is the client. When my mouse was on my desktop, and I clicked something, there would be a varying delayed reaction up to about 5 seconds. But if, when it's having a delayed reaction, I move the mouse, then it continues. So if I click a button, I have the move the mouse after that for the click to register - or wait a few seconds.

So I decided to try making my desktop the server. That's when I started experiencing huge delays and temporary mouse lockups, as described here. Running as root does prevent the problem, even for the server (thanks, PSCArmstrSM!), but a fix would be really nice.

[Joseph Fannin (jfannin)]

This bug has been triaged; the cause of the bug seems to be known.

Yes, the root cause of this bug can introduce lags and general desktop unresponsiveness in other applications. It's a kernel scheduler option that's known to the (upstream) developers to cause scheduling problems and which has unfortunately been enabled in the Hardy 8.04 release.

The fix seems to be in the pipeline:
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=273f7b551a420580307fa414fe616f0e276a4035

Hopefully this will be released as an update soon.

(not affiliated with Ubuntu or Canonical in any way, myself)

[Mike Stroyan (stroyan)]

This problem with synergyc is actually synergy's own defect related to using X11 from multiple threads.
The connection to the kernel schedule is seen because a race condition in the application is turning
out badly more often than it used to. But the right fix for this problem is in synergy.

I just added this fix as a comment to the upstream report at
http://sourceforge.net/tracker/index.php?func=detail&aid=1930587&group_id=59275&atid=490467

This problem is caused by a bad assumption in the use of poll or select
on the X11 socket connection when waiting for an event in
CXWindowsEventQueueBuffer::waitForEvent*().
The assumption is that any new event will wake the thread when
the socket becomes ready to read. The flaw in that reasoning is that
Xlib will read the data for several events at once if it is available.
The calls to XSendEvent and XFlush in CXWindowsEventQueueBuffer::flush
can read data from the X11 socket and put it in an Xlib buffer. That will
change the XPending and isEmpty status without ever finishing the poll
or select call. The flush function can be called either from another
thread via addEvent or in the direct call to flush in waitForEvent
itself. The severity of these problems will vary greatly with changes
to the scheduling of threads and the X server. It is not surprising
that they show up more often with some kernels than with others.

The attached diffs fix the two cases. The call to flush in waitForEvent
is followed by a new call to isEmpty to check if the flush caused any
events to be read. The call to flush in addEvent is followed by writing
a character to the write side of a pipe. The poll or select call in
waitForEvent then waits for a readable state on either the X11 socket
or the pipe.

[Nick Barcet (nijaba)]

Mike Stroyan wrote:
> I just added this fix as a comment to the upstream report at
> http://sourceforge.net/tracker/index.php?func=detail&aid=1930587&group_id=59275&atid=490467
> ** Attachment added: "fix for lag of synergyc on input"
> http://launchpadlibrarian.net/13995863/synergy_diffs

I just downloaded, applied, compiled and installed synergy using your
patch but my synergyc client still displays the same behavior afterward
when not invoke with sudo.
Did I miss something? In fact, synergyc seems to even die all by
itself after a very short while...

[Sebastien Estienne (sebest)]

I also applied the patch, things worked ok for some seconds and then synergyc crashed (or exited).

[Sebastien Estienne (sebest)]

i got this error message:
INFO: CScreen.cpp,116: leaving screen
INFO: CScreen.cpp,98: entering screen
synergyc: ../../src/xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy->request)) >= 0)' failed.
Abandon

[Mike Stroyan (stroyan)]

I found a couple of problems in the previous patch.
The test for isEmpty had the sense backwards.
I also reduced the number of writes to the wake-up pipe
and increased the amount read from the pipe per call.
The select-based code (which ubuntu doesn't use) also had
a couple of defects that I found and fixed after forcing the
non-poll based code to be used.

I don't see how those problems could lead to the assertion in
XGetXCBBuffer. There may be a latent problem with reentrant
calls to Xlib that still hides on my single cpu system.
A dual core system may help to bring out that bad behavior.
But I haven't put hardy on such a system yet.

[Sebastien Estienne (sebest)]

Hi Mike,

Just tested your new patch, i still get the xXGetXCBBuffer assertion.
I'm not really using a dual core cpu, only a p4 with hyperthreading

Another issue with this new patch is that synergyc was using 100% of my cpu.

[palladium (btnelson)]

Had the same issue with WinXP as server and Hardy as client. Using QuickSynergy (command line gives me scary flashbacks of COBOL green screens...) and modifying the launcher (right click Applications, Edit Menus, Accessories, Right click QuickSynergy, Properties) changed the command to 'gksudo quicksynergy'. You must use gksudo and not sudo since it's being executed from the GUI. Works perfectly now (except that it's running as root).

[Fortius (p-launchpad-fishey-neverbox-com)]

I've got a little different situation. I've got a WinXP server, Win2003 client, Ubuntu 8.04 client, and Xubuntu 8.04 client, each of the linux computers are running the 2.6.24-16-generic kernel and the Ubuntu computer initially had the spotty problem but now works fine, the Xubuntu computer though still has the problem. Is there anything about the Ubuntu box that would have fixed itself? All 4 are identical hardware, all GX280.

[navaburo (navaburo)]

I have the same issue as the original poster.

I also ran a Wireshark sniff, but from the server-side. The lag did occur during the capture, and seems to correlate with the sections of the capture where the client responds with TCP/Synergy/NOP packets instead of blank TCP/ACK packets. Capture attached.

I was about to reconfigure my kernel without the CONFIG_FAIR_GROUP_SCHED option, but then I discovered that the following made synergy run well:

sudo nice -n -20 synergyc <server IP>

[navaburo (navaburo)]

sorry about the large attachment above. Use this one instead.

[Andy Martin (7-administrat0r-hotmail-co-uk)]

I have had this bug with 2.4.24-16-generic (single-core i686 Intel Pentium M box).

My solution was to recompile libX11 with XCB disabled (not sure if this is a good idea or not, just throwing another workaround out there in case anyone wants it).
It worked for me, no lag or issues since then.

[David Vincent (dvincent)]

Just wanted to add I still have this problem on a Hardy client with a Hardy server after the latest linux-image-2.6.24-17-generic kernel was installed.

Also, even though I am using a Hardy server my Synergy client works fine and without lag on a Gutsy client.

[Nick Barcet (nijaba)]

I personally do not have this issue anymore since I installed linux-image-2.6.24-17-generic from proposed on my 64 bit laptop.

[David Vincent (dvincent)]

I may have spoken too soon, I cannot reproduce the issue right now with the new linux-image-2.6.24-17-generic kernel.

[ledzepjes (ledzepjes)]

I have installed the final release of hardy, and tried the beta, and have the same hanging issues that everyone else has, and doing the sudo trick doesn't seem to give any noticeable improvement. I don't recall having any issues with Gutsy Gibbon as the client or the server. Come on Ubuntu, it still works fine in XP, please don't make me say that two letter word again.

[Luke Faraone (lfaraone)]

I'm on 2.6.24-17-generic in the latest hardy and am still having this issue.

[helpdeskdan (helpdeskdan-gmail)]

Gah! What an annoying problem! What solution is the best current workaround? Thanks to everybody for commenting on this bug!

[Tiago Faria (gouki)]

Still happening on 2.6.24-16-generic;

helpdeskdan: I would recommend running it with sudo. Your call, though.

[Luke Faraone (lfaraone)]

Bug still occurs

[Troy C (troxor)]

Using Mike's patch from 2008-04-29 (comment #56), normal usage doesn't yield any lag. However, mashing keys in a terminal and moving the mouse wildly triggers a noticeable delay.

[Steven Harms (sharms)]

For me, enabling hardy-proposed w 2.6.24-16 solved this issue along with a lot of others. Now running synergy without root.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/188226

[brian360 (brian-11h)]

In my case, I'm running 2.6.24-17-generic from hardy-proposed and while the long lagging/"buffering" problem is gone, it is still very slow (mouse is jumpy and I can type faster than keys show up in a terminal window, for example) and thus barely usable. It feels like I'm on a bad remote desktop/VNC connection. Running synergyc as root or increasing process priority makes no difference. This is on a single-core pentium 4 2.6GHz with hyper-threading.

[IC Raibow (icrbow)]

I'm updated my client machine to proposed kernel. It fees much better, but still not as good as in 7.10 - mouse sometimes lags a bit, keyboard messes up typed symbols in alternate (russian) layout when i type quick.

[helpdeskdan (helpdeskdan-gmail)]

Seems also to lag once in a while when running via sudo, but is mostly usable.

[changlinn (morganstorey)]

I'd just like to add a me too.
I am using Synergy server from Ubuntu Feisty to Ubuntu Hardy, and it is slow
At the same time the same synergy server is going to a windows Xp and an ubuntu Gutsy, with no problems.

[Steven Harms (sharms)]

For those still having network problems, if you follow the advice of Marlon Rodriguez at https://sourceforge.net/tracker/?func=detail&atid=490467&aid=1956832&group_id=59275 does the issue go away?

[David Vincent (dvincent)]

I am experiencing sporadic crashes of both the server and client on my Hardy machines. Hardy server, two Hardy clients, all running the 2.6.24-17-generic kernel on vastly differing hardware.

I don't seem to be able to reproduce it at will. When I enable debugging synergy slows down and the problem seems to disappear. I plan on playing with the debugging output levels some more to see if I can narrow this at all but so far no luck.

[brian360 (brian-11h)]

Steven,

I have both upgraded to the latest kernel in hardy-proposed and made the hosts file changes and the problem still occurs.

[brian360 (brian-11h)]

Steven,
Retract my last comment :) After rebooting my WinXP machine, which is the synergy server, the problem is fixed and mouse/keyboard is perfectly smooth now. Sorry for the bother!

[Jeff Licquia (jeff-licquia)]

Debian maintainer here.

In Debian, synergy has been working fine up until we get Xlib-XCB into unstable/testing; it still worked fine even with kernel 2.6.24. So, it seems the combination of the newer kernel and Xlib was the catalyst.

Still, I can confirm that Mike Stroyan's patch seems to clear everything up. I got confused between his original and updated patches, and re-did some of the fixes in his update, and also fixed a small build issue. But, after all that, I'm seeing synergyc work without hangups, and with no unusual load.

I've attached my version of his patch. You can also get the Debian package source at my Bazaar tree on bzr.licquia.org, and build what will likely be synergy 1.3.1-4 for Debian.

[Matt Hall (ioeth-trocolar)]

Jeff,

I pulled the package source from your Bazaar tree at http://bzr.licquia.org/synergy/debian/, and after messing around with it to get everything in order, I was able to get it installed. Problem is, I'm still getting the lag problem on my client. I think I'm running opposite of what most everyone else here is; Hardy is my synergy server and WinXP is my synergy client. Have I done something wrong?

[Jeff Licquia (jeff-licquia)]

Matt:

If it still works at all, I doubt you did too much wrong. :-)

The fix was very specific to the X11 code, and may have only fixed the client side. So there may be some more work to do. OTOH, I've also noticed a few bugs related to the Windows client, so it could be something else.

If you can, it might be interesting switching the client and server roles for your computers, and see if you still have the problem.

[Joel Fuster (j-fuster)]

Hi Jeff,

I applied your patch and rebuilt Synergy, but I still have the lag issue. I am using it as a client to a WinXP machine. Potentially relevant information:
  * Running an up-to-date 8.04
  * I have an SMP machine
  * It is most pronounced for me with Mozilla Thunderbird or a busy page in Firefox--whenever the window loses or gains focus, there is a large amount of lag
  * Unlike many of the other reports, running synergyc as root does not fix the problem for me.
  * I did not have this problem with 7.10

Thanks.

[Joel Fuster (j-fuster)]

Just thought I'd report that I used "chrt -r -p 1 <Xorg pid>" and the difference is night and day...no lag or stuttering cursor. I had first tried this on the synergyc process, but that didn't seem to have an effect. Not sure why this is necessary now, but at least I have a workaround for the moment...

[WSmart (wsmart)]

I just installed Xubuntu Hardy and I was running Synergy for a period without a problem, Ubuntu Gutsy as server. Suddenly it's unusable. Might be a coincidence, but this happened right after I first tried to copy text from a browser. That was the first time I tried to use the clipboard. I had to fight to get it to copy and then fight to get it to paste using ctrl v-no paste in the context, and it finally pasted, a bunch of Chinese picture script. I was able to copy the text correctly, after using the sudo command, but it's touch and go with anything I copy from the web, ie ¹
º
¼
1ö0
®
¯
°
,

Also noticed that the more I move the mouse around, the worse the problem got, as if the network were getting jammed.

[Jeff Licquia (jeff-licquia)]

Joel Fuster wrote:
> I applied your patch and rebuilt Synergy, but I still have the lag issue. I am using it as a client to a WinXP machine. Potentially relevant information:
> * Running an up-to-date 8.04
> * I have an SMP machine
> * It is most pronounced for me with Mozilla Thunderbird or a busy page in Firefox--whenever the window loses or gains focus, there is a large amount of lag
> * Unlike many of the other reports, running synergyc as root does not fix the problem for me.
> * I did not have this problem with 7.10

I'll need to check, but I think the patch only affected the server.
Does it work better if you switch roles--make Ubuntu the server and XP
the client?

[Jeff Licquia (jeff-licquia)]

WSmart wrote:
> I just installed Xubuntu Hardy and I was running Synergy for a period
> without a problem, Ubuntu Gutsy as server. Suddenly it's unusable.
> Might be a coincidence, but this happened right after I first tried to
> copy text from a browser. That was the first time I tried to use the
> clipboard. I had to fight to get it to copy and then fight to get it to
> paste using ctrl v-no paste in the context, and it finally pasted, a
> bunch of Chinese picture script. I was able to copy the text correctly,
> after using the sudo command, but it's touch and go with anything I copy
> from the web, ie ¹
º
¼
1ö0
®
¯
°
,

I think we've seen this before, and it's a separate bug.

> Also noticed that the more I move the mouse around, the worse the
> problem got, as if the network were getting jammed.

This looks more like the problem we're seeing. Have you had a chance to
try the fixed package?

[Sean Dague (sdague)]

For what it's worth, this returned again in Intrepid if you use the hardy synergy package (the intrepid package is broken, and yes there is already a bug for that). Using the debian bzr tree does make this go away.

[kry10 (launchpad-marklinford)]

Hi, everyone:

FWIW, I just installed the synergy package on a fresh install of Intrepid Beta. Vanilla synergyc (my server is an XP workstation) is working great for me - if anything, it feels as fast and responsive as 7.10 did.

[grsch (grsch-ubuntulaunchpad)]

actually an anecdote: The performance degradation was so important in my case, that synergyc started reordering the X events, jumbling what I was writing:

"Dies sollte ein verdrehungsfreier Satz sein.... mal sehen, ob man den nach einer Weile noch lesen kann"
came out as
"Die ss oslltee iennvrerdhugfreieier Ssataz senn... ml eh,ob man den nach einer Weile noch lesen kann"

...which by the way seems weird to me, as synergyc ought to receive a (TCP!) ordered bytestream of events... so there seems to be an additional race condition? Is synergyc splitting up the received data onto multiple threads? o.O

It happened using semantik and vym over synergy on hardy + backports on a connection with about ~60ms delay (don't ask ;) )
synergy version was: 1.3.1-2ubuntu2
kernel was vanilla (yes, flame me! ;P ) 2.6.26.5

starting synergyc with sudo resulted in very smooth mouse movements and no jumbled input... so it must have been this issue...

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

[Ilan (ilan)]

The page mentioned in the last update is no longer valid. The new link is:

https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies

[Joseph Fannin (jfannin)]

This issue is gone in Karmic. I skipped Jaunty, so I cannot speak for that release, though I suspect it is fixed there too. This report is potentially closeable.