Bug 850785 - Keyboard input almost never working using remote console DELL iDRAC on new server PowerEdge R720
Keyboard input almost never working using remote console DELL iDRAC on new se...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
19
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-22 08:24 EDT by Philippe
Modified: 2015-01-28 23:49 EST (History)
22 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-01-28 23:49:03 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 22234 None None None Never

  None (edit)
Description Philippe 2012-08-22 08:24:01 EDT
Description of problem:

I'm trying to access the server Using Dell remote console through iDRAC on a Dell R720 new generation server.
(That was working on all previous Dell Servers i used in the past, R710, PE2950, PE2850 ...)
The screen is displayed correctly, but the keyboard input will almost never work (sometimes when you just open, it will allow you to type 3 or 4 chars)


Version-Release number of selected component (if applicable):
Fedora 17 - from the first kernel release of the install CD
and also now with latest  3.5.1-1.fc17.x86_64 kernel


How reproducible:
Always


Steps to Reproduce:
1. Login to console and type


Actual results:
Typings usually does not work 
or
Typings would work for 4 or 5 chars


Expected results:
Typings OK


Additional info:
I was not able to install the server using Fedora 17 CD for the same reasons.
I had to use Fedora 16 and then perform dist. upgrade to Fedora 17 :(
Comment 1 Philippe 2012-08-22 10:53:44 EDT
Adding kernel parameter usbcore.autosuspend=-1 seems to fix the problem.

I have no precise idea of the real impact of this parameter for me on the server performances. But its a real pain not to be able to install Fedora 17 from CD without knowing this.
Comment 2 Josh Boyer 2012-08-22 15:58:32 EDT
What version of udev do you have installed?
Comment 3 Philippe 2012-08-22 21:22:14 EDT
udev-182-3.fc17.x86_64
Comment 4 Fabian Deutsch 2013-01-22 09:15:59 EST
Hey,

is there any update on this bug?

We see some oVirt Node users running into this problem?
Comment 5 Timon 2013-03-18 04:39:13 EDT
The same problem with Fedora 18
and usbcore.autosuspend=-1 fixes this issue
Comment 6 Simon Natella 2013-05-23 06:08:20 EDT
Seeing this problem on R620s with iDRAC7 too.

Fedora18 (graphical, text) and ovirt-node affected, the usbcore fix works.

I can provide more information if required.
Comment 7 Fabian Deutsch 2013-05-28 04:51:54 EDT
Simon,

could you try it with ovirt-node-3.0.0rc1 [0] which contains a newer udev.


[0] http://resources.ovirt.org/releases/node-base/beta/iso/ovirt-node-iso-3.0.0-1.0.20130517.fc18.iso
Comment 8 Simon Natella 2013-05-28 12:06:09 EDT
(In reply to Fabian Deutsch from comment #7)
> Simon,
> 
> could you try it with ovirt-node-3.0.0rc1 [0] which contains a newer udev.
> 
> 
> [0]
> http://resources.ovirt.org/releases/node-base/beta/iso/ovirt-node-iso-3.0.0-
> 1.0.20130517.fc18.iso

Hello Fabian,

Interesting set of results, while trying to run the install iso with:

- UEFI boot (GRUB2?) I get to a screen (after the throbber finishes loading) which says:

"An error appeared in the UI: IOError(2, 'No such file or directory')
Press ENTER to logout...
or enter 's' to drop to shell"

Both ENTER and 's' do nothing.


- BIOS boot (syslinux?) we can install properly.

Came to first login prompt and managed to type in username and keyboard input died again. Tried a reboot but no luck.


Many thanks
Comment 9 Fedora End Of Life 2013-07-03 19:30:51 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 10 Fabian Deutsch 2013-07-12 05:08:42 EDT
(In reply to Simon Natella from comment #8)
> (In reply to Fabian Deutsch from comment #7)
> > Simon,
> > 
> > could you try it with ovirt-node-3.0.0rc1 [0] which contains a newer udev.
> > 
> > 
> > [0]
> > http://resources.ovirt.org/releases/node-base/beta/iso/ovirt-node-iso-3.0.0-
> > 1.0.20130517.fc18.iso
> 
> Hello Fabian,
> 
> Interesting set of results, while trying to run the install iso with:
> 
> - UEFI boot (GRUB2?) I get to a screen (after the throbber finishes loading)
> which says:
> 
> "An error appeared in the UI: IOError(2, 'No such file or directory')
> Press ENTER to logout...
> or enter 's' to drop to shell"
> 
> Both ENTER and 's' do nothing.
>

Hey, that was an EFI bug, which should be solved.

> 
> - BIOS boot (syslinux?) we can install properly.
> 
> Came to first login prompt and managed to type in username and keyboard
> input died again. Tried a reboot but no luck.
> 
> 
> Many thanks

Could you try one of our most recent F19 builds to see if this is fixed:
http://resources.ovirt.org/releases/node-base/3.0.0/iso/ovirt-node-iso-3.0.0-3.0.1.fc19.iso
Comment 11 Timon 2013-08-21 04:18:57 EDT
confirm this bug with latest fedora19 iso
http://mirror.yandex.ru/fedora/linux//releases/19/Fedora/x86_64/iso/Fedora-19-x86_64-DVD.iso
Comment 12 Timon 2013-08-21 05:06:38 EDT
but ovirt-node-iso-3.0.0-5.0.1.fc19.iso works fine
Comment 13 Simon Natella 2013-08-21 05:09:27 EDT
We've not tried the ovirt-node-iso-3.0.0-3.0.1.fc19.iso image, but we've tried ovirt again with Fedora19 and that still required the usbcore.autosuspend=-1 fix.

I am hoping to get some time on our test machine soon to give the ovirt-node image.

Kind regards,

Simon
Comment 14 Fabian Deutsch 2013-08-21 05:20:16 EDT
Hi Timon and Simon,

thanks for giving this feedback.

Mike,

looking at [1] I think that we should use the sysctl way of setting the param to disable USB autosuspend on Node. Normally I'm always in favor of saving power. But as Node is predestined to be used with some remote console thingy (tm) I think that going with this slightly-less power-saving configuration is needed to fix this problem.
I'd go (needs to be investigated if it works) with the sysctl way of setting the param to not clutter the kernel cmdline even more.

[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/usb/power-management.txt?id=HEAD#n176
Comment 15 David Burrows 2013-12-04 04:30:08 EST
Forgive me if I'm wrong, but this issue almost certainly shouldn't be CLOSED.  I spent several hours not being able to type into a Dell server via the remote access console, wasting my time updating to the latest firmware etc, only to by chance discover this bug report.  The expected behaviour is that one can login to their system remotely by typing into the console.  Please re-open this issue, and find a more acceptable solution than having to consult the ERRATA.
Comment 16 Fabian Deutsch 2013-12-04 06:14:37 EST
Josh,

can you say why this one got closed?

In what - probably - udev version is this fixed?
Comment 17 Josh Boyer 2013-12-04 19:03:30 EST
Not sure why I closed this.  Possibly just a mistake on my part.  It should probably be reassigned to udev to get a rule added to disable autosuspend on this device.
Comment 18 Fabian Deutsch 2013-12-05 07:06:59 EST
Thanks Josh.
Comment 19 R P Herrold 2013-12-09 12:58:04 EST
documented at https://fedorahosted.org/ovirt/ticket/80#comment:7 as in play
Comment 20 Fabian Deutsch 2013-12-10 06:43:44 EST
Adding a simple fix for this right now.

Will add a link to an ISO to test.
Comment 22 Daniel Johnson 2014-03-13 17:56:41 EDT
This appears to impact the RedHat Enterprise Linux v7 beta (RHEL7, RHEL v7) also.  Confirmed on Dell R720xd and T320 servers, keyboard works fine in text mode but keyboard and mouse are non-responsive in GUI (both setup menu and normal boot after installation).  I suspect it impacts all of Dell's 12G servers, since they all use the iDRAC7 for remote access.

Use of the "usbcore.autosuspend=-1" kernel parameter makes the system behave normally.

Similar test on an R710 (Dell 11th generation, iDRAC6) shows no problem.

Tested using the file downloaded 2014-02-25 with this SHA256sum:
4c4f20cf1e189f97ded6912d8b962f3791f60bdf8284a005708cb30acb8ef611 *rhel-7-public-beta-x86_64-dvd.iso

Kernel 3.10.0-54.0.1.el7.x86_64, iDRAC7 firmware v1.51.51 on both 12G test servers.
Comment 23 Daniel Johnson 2014-04-28 19:32:54 EDT
Re-tested today with RHEL7 rc1 (bea5e951342a7ab0233219c3deb3b3acff023ea5dc67a9a4564a97a89364f192 *rhel-server-7.0-x86_64-dvd.iso), no change on iDRAC7 v1.51.51.  *HOWEVER*, with iDRAC7 v1.56.55 both the Beta and RC ISOs worked properly in GUI mode.

Whether there is still an underlying issue in the usbcore code I cannot say, but at least if you update your Dell iDRAC7 firmware the issue *appears* to be resolved or bypassed.
Comment 24 Zbigniew Jędrzejewski-Szmek 2014-07-22 22:30:39 EDT
So, is there anything to fix here?
Comment 25 Fedora End Of Life 2015-01-09 17:26:10 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Note You need to log in before you can comment on or make changes to this bug.