Bug 850785

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.

What version of udev do you have installed?

udev-182-3.fc17.x86_64

Hey,

is there any update on this bug?

We see some oVirt Node users running into this problem?

The same problem with Fedora 18
and usbcore.autosuspend=-1 fixes this issue

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.

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

(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

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.

(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

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

but ovirt-node-iso-3.0.0-5.0.1.fc19.iso works fine

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

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

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.

Josh,

can you say why this one got closed?

In what - probably - udev version is this fixed?

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.

Thanks Josh.

documented at https://fedorahosted.org/ovirt/ticket/80#comment:7 as in play

Adding a simple fix for this right now.

Will add a link to an ISO to test.

Could someone please try this  build:

http://jenkins.ovirt.org/job/node-devel/1369/distro=fedora19/artifact/ovirt-node-iso-3.1.0-0.999.0.20131218094553git32b6966.1369.fc19.iso

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.

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.

So, is there anything to fix here?

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.