03-03-2010 02:39 PM - edited 04-02-2010 05:16 PM
This will be the central thread for what we know on these issues. There have been too many freefloating threads where the answers are hidden in the middle, and it's causing confusion. All G19 threads that involve motherboards using these chipsets will be closed and directed to this thread
What we know about the G19: It is a USB-IF certified keyboard, which means not only is it fully certified as a USB compliant device, it can also have the Windows logo on its box which shows it complies to all standards that Microsoft sets out to operate with their OSes. Units that appear to have issues on specific afflicted systems (790i/x58 chipsets and Windows Vista/7 x64, usually while running processor intensive or SLi/Crossfire based tasks) function just fine on systems with other motherboards, on x86 versions of the OS, or with SLi/Crossfire disabled.
What we know about the situation: The G19, when plugged into a x58 or 790i motherboard running Windows Vista/7 x64, may experience symptoms like excessive USB cutouts, "stuck" keys, and degraded input performance of devices plugged into the G19's USB ports. Through extensive testing, we do not believe this is on the keyboard's side. This is because we are able to replicate the issue with ANY USB keyboard plugged into a USB 2.0 hub, regardless if they are made by Logitech or not, on these motherboard/OS combinations. The issues seem to be tied largely to the amount of data that is being communicated across the computer's bus, and so most people only witness this issue in-game while running GPUs in SLi or Crossfire mode. This reinforces that the problem lies external to the G19, as having these modes enabled or disabled makes no difference to the keyboard's hardware, firmware, or software.
Solutions we've found: We have found several solutions that, according to user reports, resolved the problem on these motherboards
- Disable EHCI Handoff: EHCI Handoff is [ENABLED] as a default in most motherboards, and should be [DISABLED] if you are using Windows XP SP2 or greater. Most people do not disable this setting, and in our testing and from customer reports, disabling this option seems to resolve the issue on many motherboards. If you have questions about disabling this feature on your motherboard, please contact your motherboard manufacturer for the BIOS options.
- Update your BIOS and look for driver/windows updates:We are aware that some motherboard manifactuers have released BIOS updates that resolve some motherboard issues with the G19. We've also become aware of Windows updates that will resolve the USB 2.0 communication issues that cause the G19 to have poor performance. Also check for any sort of motherboard or controller chip updates.
- Use a non-EHCI compliant PCI-e USB card, and plug the G19 into that: If a USB PCI-e card is "non-EHCI compliant", it means it uses its own drivers, and not the system drivers, to handle the USB communication. This has been reported to us and verified in house as a potential solution for motherboards that cannot disable EHCI handoff.
- Try spacing out or relocating USB plugs to different ports: Users have reported that plugging the G19 into a different set of USB ports, like front or top ports, OR relocating other devices to the front or top ports, has resolved USB reset issues.
- Relocate mobile phones and devices that emit radio signals away from the G19's screen: A distance of 15"/45cm from the screen has prevented issues with some motherboards.
- Reducing radical overclocks: Some users have reported success with their USB communications by lowering their overclock amount. Just like adjusting memory latency to adjust for optimum performance on memory chips, lowering overclocks for some users have resulted in systems with more stable USB communications.
- Disabling SLi or Crossfire: Not ideal for some people, but has fully resolved the problem for some users.
If other users report additional solutions to this problem, and I get the steps verified by the QA team, I will add them to this section.
What we are doing: We are continuing to review customer feedback and see what steps we can take. It does appear that most of the solutions that work have come from resolutions that are external to the keyboard, like changing BIOS settings. We will review all information to determine what can be best done from Logitech's side to resolve this issue, but we believe at this point that the problem lies external to the G19, because if it was internal to the G19, it would affect all computers regardless of motherboard or OS.
03-03-2010 02:40 PM - edited 04-02-2010 05:13 PM
03-04-2010 09:02 PM
This is a repost, but I thought I should get it under the new thread. I have not solved my G19/x58 issue, but I have a work-around that is working 100%. It's a bit is a pain. First, I have disabled legacy USB support in BIOS and this also disables the EHCI Handoff. Next I power up the PC from cold, then, after it's booted, I reboot.
That's it. It works everytime. If I don't reboot the G19 will start acting up within 10-15 mins.
03-05-2010 10:03 AM
I registered jus to give you my feedback about this issue.
I experienced the same troubles with my keeeeeeeeeeeeybooooooooooooard (looked like that)
I confirm the fact that mobil phone has huge influence on the device. I put it on the screen of the G19 (just testing right ?)
and it just CRASHED (no more screen and lights). Looks funny but for a 180 euros product, it's hard to see.
Whatever, I removed the phone and the keyboard turned on again.
Now I put it far away from the G19 (so far so good) and it seems to work for the moment (I do it since yesterday).
So one advice for those who experience this troubles : throw you mobil phone far away the keyboard (and maybe Logitech will refund it :-P )
Sorry for my English, some sentences may sound bizaaaaaaaaare.
03-06-2010 04:19 AM
I just sent an SMS from my Nokia 3720 and had the phone lying right on the screen. no problems.
motherboard is asus m2n68-am plus. different hardware spec, but i think interesting none the less.
g keys have been non-responsive for a while now...
03-06-2010 12:37 PM - edited 03-06-2010 12:43 PM
I have an Asus Essentio CG5290. It comes with an Asus Rampage II GENE motherboard (Intel x58). I have the latest BIOS ver 0701. I am not running SLI, I have an 896MB Nvidia GeForce GTX 260. Running Win 7 64 bit.
Also, if I do not do my reboot workaround and use the system until the G19 locks up, then the only recovery is shutdown the system, unplug the G19, plug back in, cold reboot, then warm reboot.
Finally, rereading my original post it reads like I change the BIOS everytime. I don't, that was a one time change. The cold boot/warm reboot is the workaround (pain, lol) I do everyday.
03-08-2010 12:26 AM
I posted a few replies back in the old "buffer overrun" thread. It's funny that you mention that it can be replicated with ANY USB keyboard. Then why is it that I never had these issues with my G15? Or even my crappy USB Microsoft keyboard?
I'm very frustrated with this keyboard, enough to turn me away from Logitech for good. Believe me, this is something that I don't want to do as most of my peripherals are Logitech.
I asked in the other thread, and I'll ask again:
Other than the G15, what are some keyboards that are similar to the G15/G19? I need access to a set of macros, not so much the LCD any more.
03-08-2010 08:34 AM
you never had these issues previously, because you have to put the system under a lot of load to see it. that kind of load doesn't typically occur, and with those other keyboards a regular consumer won't typically be able to manage it -- it takes an engineer to figure out exactly where to apply enough stress to get it to break. I'm not talking about CPU or GPU load here -- those things are easy to do, even for end-users. I'm talking about bus load, and it's very hard to test bus load properly without knowing how your system board is designed -- you have to know things like which USB ports share bus bandwidth with which PCI devices, which things are routed through which bridges, and how different arrangements of chipsets lead to bus bandwidth bottlenecks in different places.
if you removed all the extra features the G19 has that other keyboards don't have, everything would probably work just fine (without an engineer artificially applying load). but when you add those features back in, it creates just enough extra load that those specific hardware combinations can't cope. if you add those features to the G15, the G15 will start exhibiting this problem. if you add those features to a crappy USB Microsoft keyboard, it will start exhibiting the problem too. or if you have an engineer injecting extra load into a system, you can cause a G15 or a Microsoft USB keyboard to exhibit the same problem even without having those extra features at all.
I do not work for Logitech. I'm just a user.
03-08-2010 12:50 PM - edited 03-08-2010 12:52 PM
opruitt - I have to do something similar with my girlfriend's iMac. She has to warmboot or else the RAM causes problems. On cold boot it locks during boot, but resetting it (Or shutting the iMac down and starting it back up again in just a few minutes) allows it to boot fully. Works fine with the OEM RAM, but she needs 4GB to work with MAYA, so she's been coping.
On the bright side, that means that maybe there's a BIOS setting that can be tweaked, since it appears that cold boot situations are the tough point. I'll see if I can scrounge up the manual for that and take a look later
Goldfire - please reread my original statement:
"replicate the issue with ANY USB keyboard plugged into a USB 2.0 hub"
The G19 is, on a logical hardware level, a unique USB 1.1 keyboard (unique in that it uses a novel dual-matrix layout that eliminates ghosting and lockouts on 8 keypresses or less) hardwired into a USB 2.0 hub. With the system configurations that have problems with the G19, we see the same problems occuring with a USB keyboard plugged into a USB 2.0 hub.
Hadakajime - So, could you give me a precise rundown of what is, and what isn't working on your G19, and what version of Windows and LGPS you have installed?