Logitech k400 keyboard and v3.2

[Sleep Mode zZ]

2 success stories is better than 0. Sleep Mode zZ hasn't had any luck, so let me ask you to unplug any
other USB devices and see if it works then.

I unplugged my Wingman Rumblepad and tried this again. From reboot 4 times lucky, the fifth time needed repluggin of the K400. So the rc.local-fix do not work here.

[MaxK1]

I'll assume(!) everything is up-to-date. One last shot - try putting
sleep 10
before the rmmod and modprobe. The fact that you had better luck with the Rumblepad
unplugged (not perfect) tells me.... something. Not sure what. I'm thinking that during start up, the system is just very busy (at least busy enough) that the Unifying receiver is not getting initialized properly or something is getting missed. By removing and and re-installing the driver we just move
initialization to a more quiet time. Down side is 10 more seconds before you can login.

[MaxK1]

Try it with and without the Rumblepad. Should not make a difference (guess) with the "sleep" in there.

[thegr8brian]

2 success stories is better than 0. Sleep Mode zZ hasn't had any luck, so let me ask you to unplug any
other USB devices and see if it works then.

This is my only USB device.

[Sleep Mode zZ]

I'll assume(!) everything is up-to-date. One last shot - try putting
sleep 10
before the rmmod and modprobe. The fact that you had better luck with the Rumblepad
unplugged (not perfect) tells me.... something. Not sure what. I'm thinking that during start up, the system is just very busy (at least busy enough) that the Unifying receiver is not getting initialized properly or something is getting missed. By removing and and re-installing the driver we just move initialization to a more quiet time. Down side is 10 more seconds before you can login.

Everything is up-to-date in the "apt-get update && apt-get upgrade" sense. I don't use rpi-update.

Tried now the "sleep 10" addition. So far 7 reboots without need for replugging. I will continue tomorrow...

[MaxK1]

Can you live with the workaround? You can try shortening the sleep time if it still works.
Otherwise leave it as is until the USB driver has a more complete fix...

[PaulCheffus]

I won't be able to help without first know the exact update that broke it. Look here:
https://github.com/raspberrypi/firmware ... kernel.img

That's a list of all commits to kernel.img (which is probably the relevant file).

Click on the "browse code" button next to a given date's kernel. You can now click "view raw" and download that version of the kernel.

Hopefully just the kernel is sufficient to see if the problem still occurs.
You will need associated modules if you want to startx or use external peripherals, but normally the keyboard is handled in the main kernel.

Hi Dom

Finally got around to doing this.

System start point was 3.1.9+ #202 25 July 22:11:06 with Vcgencmd 328039

I tried the following kernel.img files which all worked
3.1.9+ #242 1 August 19:47:22
3.1.9+ #272 8 August 22:51:44
3.1.9+ #278 15 August 20:59:07

However this one
3.2.27 #6 18 August 15:05:48
the keyboard fails to work on every reboot and even unplugging and plugging back in doesn't work.

Cheers

Paul

[dom]

I tried the following kernel.img files which all worked
3.1.9+ #242 1 August 19:47:22
3.1.9+ #272 8 August 22:51:44
3.1.9+ #278 15 August 20:59:07

However this one
3.2.27 #6 18 August 15:05:48
the keyboard fails to work on every reboot and even unplugging and plugging back in doesn't work.

Thanks for investigating. Unfortunately that is the shift from 3.1.9 to 3.2.27 kernel. There is nothing changed by us in that commit, just getting a newer version of the linux tree.
Now it may be changes in the mainline linux kernel have caused problems for this keyboard, in which case there should be bug reports on other plaforms (and possibly a subsequent fix).

[PaulCheffus]

I tried the following kernel.img files which all worked
3.1.9+ #242 1 August 19:47:22
3.1.9+ #272 8 August 22:51:44
3.1.9+ #278 15 August 20:59:07

However this one
3.2.27 #6 18 August 15:05:48
the keyboard fails to work on every reboot and even unplugging and plugging back in doesn't work.

Thanks for investigating. Unfortunately that is the shift from 3.1.9 to 3.2.27 kernel. There is nothing changed by us in that commit, just getting a newer version of the linux tree.
Now it may be changes in the mainline linux kernel have caused problems for this keyboard, in which case there should be bug reports on other plaforms (and possibly a subsequent fix).

Hi Dom

Thanks for the reply and information.

Any idea where I can go to find out about progress and if this has actually been reported?

Cheers

Paul

[Sleep Mode zZ]

Can you live with the workaround? You can try shortening the sleep time if it still works.
Otherwise leave it as is until the USB driver has a more complete fix...

Today, on the thirteenth reboot/power on after adding the sleep instruction, the K400 needed replugging. I will continue like this if the frequency of repluggings stays so low.

I don't know if there is anything special about my pi that I don't get as good results as the other two. Maybe my SD card or that my pi is overclocked (Dom's settings) could be the reason.

Yes, I can live with this. Thank you MaxK1.

[MaxK1]

I've been out of town for the last few days, but it looks like most of you have had pretty good luck.
BTW that "workaround" can "possibly" be used with other devices that don't initialize properly.
The downside is that if word gets out, it might interfere with Dom, Gordon et al (whoever he is)
actually being able to track issues. So don't tell anyone

[MaxK1]

Can you live with the workaround? You can try shortening the sleep time if it still works.
Otherwise leave it as is until the USB driver has a more complete fix...

Today, on the thirteenth reboot/power on after adding the sleep instruction, the K400 needed replugging. I will continue like this if the frequency of repluggings stays so low.

I don't know if there is anything special about my pi that I don't get as good results as the other two. Maybe my SD card or that my pi is overclocked (Dom's settings) could be the reason.

Yes, I can live with this. Thank you MaxK1.

Do you have any other USB devices or a wired network? Are you starting any services that might be hitting the network (wired or wifi)? That _may_ affect the timing a little. You could try extending the sleep time by a bit - it doesn't hurt anything except it takes a little longer to boot. Don't go any higher than you are comfortable with.

Remember that Dom and gsh are working on the underlying problem in the USB stack so you might want to stay fairly current with upgrades and rpi-updates + any new options that affect the USB subsystem (usually in /boot/cmdline.txt) I expect they will have it fixed fairly soon and you can throw the workaround away!

[Sleep Mode zZ]

Do you have any other USB devices or a wired network? Are you starting any services that might be hitting the network (wired or wifi)? That _may_ affect the timing a little. You could try extending the sleep time by a bit - it doesn't hurt anything except it takes a little longer to boot. Don't go any higher than you are comfortable with.

I have wired network but I have not added any services to my Raspbian installation.

Remember that Dom and gsh are working on the underlying problem in the USB stack so you might want to stay fairly current with upgrades and rpi-updates + any new options that affect the USB subsystem (usually in /boot/cmdline.txt) I expect they will have it fixed fairly soon and you can throw the workaround away!

I don't use rpi-update, I will stick to apt-get upgrade, I'm not in a hurry and will get all the fixes eventually, after the more adventurous have tested them. I will check the need for the workaround after kernel upgrades.

[PaulCheffus]

Can you live with the workaround? You can try shortening the sleep time if it still works.
Otherwise leave it as is until the USB driver has a more complete fix...

Today, on the thirteenth reboot/power on after adding the sleep instruction, the K400 needed replugging. I will continue like this if the frequency of repluggings stays so low.

I don't know if there is anything special about my pi that I don't get as good results as the other two. Maybe my SD card or that my pi is overclocked (Dom's settings) could be the reason.

Yes, I can live with this. Thank you MaxK1.

Do you have any other USB devices or a wired network? Are you starting any services that might be hitting the network (wired or wifi)? That _may_ affect the timing a little. You could try extending the sleep time by a bit - it doesn't hurt anything except it takes a little longer to boot. Don't go any higher than you are comfortable with.

Remember that Dom and gsh are working on the underlying problem in the USB stack so you might want to stay fairly current with upgrades and rpi-updates + any new options that affect the USB subsystem (usually in /boot/cmdline.txt) I expect they will have it fixed fairly soon and you can throw the workaround away!

Hi

From what Dom has said this is unlikely to be fixed by the Raspberry Pi community as it has been cause by the change to 3.2.27 as mentioned in his reply on 13 September to my testing.

Cheers

Paul

[MaxK1]

Of course it won't work _properly_ until the USB stack is fixed. That leaves 3 choices:
1 - live with it until fixed
2 - go back to 3.1.9
3 - try the workaround and see if it at least improves the situation

[PaulCheffus]

Of course it won't work _properly_ until the USB stack is fixed.

Hi

Maybe I'm being stupid here but if it has been broken in the main Debian release how is fixing the USB stack on the Raspberry Pi going to cure the problem?

Cheers

Paul

[MaxK1]

The USB driver is part of the Linux kernel. You'll have to upgrade when they release the patch through
the usual apt-get/rpi-update. Until then, you have the 3 options I listed.

[MaxK1]

OK - I think I know where your confusion stems from. The Logitech driver is NOT broken, it is a problem
with the underlying USB driver that is broken. If it was the Logitech driver that had a problem, the workaround I suggested would not have worked at all for anybody. It seems to be working ~100% for 3 people. Give it a try. When they announce they have a fix (or fixes - may take more than 1) for the USB
driver, back the workaround out and see if the problem with the Logitech keyboard goes away. If it doesn't, then Gordon has more work to do. And you can put the workaround back and keep on computing

[prich]

Hi,

I have had several problems with USB devices on the Pi over the last few weeks - in order:

Up to last Saturday (22/09/2012) I was unable to get my TL-WN822N wifi adaptor to work (tried every solution I could find - spent about 30 hours all up).
Last Saturday on a 'new' SD card the adaptor worked without any intervention. Problem was the Logitech K400 required unplug/replug of receiver.
Did an update/upgrade and rpi-update last night now NONE of the USB devices work without unplug/replug - I have the keyboard and wifi plugged into a Logitech 4 port powered hub (appears to be a H-UE5).
Unplug/replug of the hub (as opposed to each device individually) fixes the problem.

The current kernel is:
Linux raspberrypi 3.2.27+ #174 PREEMPT Wed Sep 26 14:09:47 BST 2012 armv6l GNU/LINUX

regards
Peter

[MaxK1]

Does unplugging devices individually not work? If it does, you can try the workaround of unloading
modules and reloading them.

[thegr8brian]

The successful results in my previous post was using xbian 0.7b1

I wanted to report that I tried to use raspbmc RC5 today and this fix no longer works for me. I tried with and without sleep and saw no difference.

Maybe this will be a useful datapoint to someone but I haven't had any ideas on why there would be such discrepancy.

[MaxK1]

I need to grab Raspbmc RC5 and take a look at what is going on. Do you by any chance have any other USB devices connected? (WiFi, USB flash drive or HDD) If so, can you unplug them and try
again? I'm thinking that the Logitech driver needs the USB bus to be "quiet" while it's initializing. From another post, it sounds like Gordon will have another patch in a few days. Whether that will solve the problem (or allow the "workaround" to fudge it) remains to be seen...

[thegr8brian]

I need to grab Raspbmc RC5 and take a look at what is going on. Do you by any chance have any other USB devices connected? (WiFi, USB flash drive or HDD) If so, can you unplug them and try
again? I'm thinking that the Logitech driver needs the USB bus to be "quiet" while it's initializing. From another post, it sounds like Gordon will have another patch in a few days. Whether that will solve the problem (or allow the "workaround" to fudge it) remains to be seen...

No other USB devices connected other than the Ethernet I suppose. Maybe it's some race condition between these two devices.

Could you point me to the post regarding the patch you mentioned for reference?

[MaxK1]

http://www.raspberrypi.org/phpBB3/viewt ... &start=525

It's the"USB - the elephant in our room" thread. Well worth watching for possible solutions/things to try.
(but fairly lengthy)

[Sleep Mode zZ]

Maybe this Ubuntu bug report is relevant to this topic and worth keeping an eye on: https://bugs.launchpad.net/ubuntu/+bug/958174. This seems to indicate to me that the problem lies in the logitech driver and is not restricted to the Pi...