Bug 186318

This is an unfortunate failure, because it requires work to get the
required data (e.g. at least dmesg). The only way I see is to install
FC-5 elsewhere, move the disk over, boot from it, see if the problem
can be reproduced.

I would also try to get serial console to work (adding console=ttyS0
at the syslinux prompt).

Created attachment 126516 [details]
Serial console output

I don't know if I should be able to drive the installer from the serial
console, but it doesn't appear to work here.

Booting with 'linux acpi=off' keeps keyboard working.

This was a good try with the serial console. Seems that ohci-hcd is not being
loaded at all. I wonder why. I suppose only Peter and Jeremy can answer.

Created attachment 126551 [details]
First boot serial console log

After installing (acpi=off required for USB keyboard to work), the
keyboard/mouse fails to work on first boot.  Tried both using acpi=off and
without any acpi= setting.  Console log is with acpi=off.

Created attachment 127028 [details]
USB system info

A bit more information, lsmod output and contents of proc/bus/usb/devices, from
the system in two states.  The first is during install (acpi=off) where the
keyboard/mouse works.  The second is on first boot - over the serial console
since the keyboard/mouse doesn't work (with or without acpi=off).

Created attachment 127029 [details]
USB system info

A bit more information, lsmod output and contents of proc/bus/usb/devices, from
the system in two states.  The first is during install (acpi=off) where the
keyboard/mouse works.  The second is on first boot - over the serial console
since the keyboard/mouse doesn't work (with or without acpi=off).

I can confirm the problems on Sun W1100z with both FC5 kernels:
kernel-2.6.15-1.2054_FC5
kernel-2.6.16-1.2080_FC5

NOTE #1: This happens only on _SOME_ W1100z (BIOS versions used here are B4S3 
and B4S4). I have W1100z boxes that install and boot fine with USB 
keyboards/mice (some use KVM switches, some directly connected to 
keyboars/mouse).

NOTE #2: FC3 is fine (tested install CD and boota full system after FC5 
problems showed up), so I do not suspect hardware/BIOS problems.

The problematic boxes hang at media check screen. My workaround is to install 
with: 'linux askmethod selinux=0'

Post-install, these boxes do not see anything on the USB port.

# cat /proc/bus/usb/devices

T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 3
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.16-1.2080_FC5 ohci_hcd
S:  Product=OHCI Host Controller
S:  SerialNumber=0000:01:00.1
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 3
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.16-1.2080_FC5 ohci_hcd
S:  Product=OHCI Host Controller
S:  SerialNumber=0000:01:00.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

Syslog excerpt:
<snip>
Mar 31 16:48:52 lw109 kernel: ACPI: PCI Interrupt 0000:01:00.0[D] -> GSI 19 
(level, low) -> IRQ 20
Mar 31 16:48:52 lw109 kernel: ohci_hcd 0000:01:00.0: OHCI Host Controller
Mar 31 16:48:52 lw109 kernel: ohci_hcd 0000:01:00.0: new USB bus registered, 
assigned bus number 1
Mar 31 16:48:52 lw109 kernel: ohci_hcd 0000:01:00.0: irq 20, io mem 0xe0100000
Mar 31 16:48:52 lw109 kernel: usb usb1: configuration #1 chosen from 1 choice
Mar 31 16:48:52 lw109 kernel: hub 1-0:1.0: USB hub found
Mar 31 16:48:52 lw109 kernel: hub 1-0:1.0: 3 ports detected
Mar 31 16:48:52 lw109 kernel: ACPI: PCI Interrupt 0000:01:00.1[D] -> GSI 19 
(level, low) -> IRQ 20
Mar 31 16:48:52 lw109 kernel: ohci_hcd 0000:01:00.1: OHCI Host Controller
Mar 31 16:48:52 lw109 kernel: ohci_hcd 0000:01:00.1: new USB bus registered, 
assigned bus number 2
Mar 31 16:48:52 lw109 kernel: ohci_hcd 0000:01:00.1: irq 20, io mem 0xe0110000
Mar 31 16:48:52 lw109 kernel: usb usb2: configuration #1 chosen from 1 choice
Mar 31 16:48:52 lw109 kernel: hub 2-0:1.0: USB hub found
Mar 31 16:48:52 lw109 kernel: hub 2-0:1.0: 3 ports detected
<snip>

When I plug a USB key, I either get nothing at all or this message:

Mar 31 16:33:45 lw109 kernel: Initializing USB Mass Storage driver...
Mar 31 16:33:45 lw109 kernel: usbcore: registered new driver usb-storage
Mar 31 16:33:45 lw109 kernel: USB Mass Storage support registered.

and the device is not accessible (it should place it on /dev/sda)

This smells strongly as a handoff issue (which FC-3 didn't implement).
Unfortunately, in our infinite collective wisdom, we (I, Stern, et.al.)
did not provide any means to override the early handoff in
drivers/pci/pci-quirks.c, because nothing could go wrong there,
this is what XP does, right? I guess not on Sun hardware...
If I had access to one of those, I'd run some experiments.

Anyway, can BIOS be updated on the box in question?
Phillipe, what is a verion that works (other than B4S3, B4S4)?

The W1100z box I am testing on has BIOS B4S4.  I tried using askmethod
selinux=0, but that doesn't work for me.  My box requires acpi=off for the
keyboard/mouse to work during install.

More info (and weirdness): 

I plugged a wireless keyboard/mouse combo which has LEDs on the mouse base, so 
I can tell me when power gets through the USB port.

Before booting Linux (at the grub stage), unplug and plug the combo back in 
gives:
 - on problematic boxes (no keyboard)  -> LED on
 - on functional boxes (keyboard works)-> LED on

When the machine has completed the boot stage, unplug and plug the combo back 
in gives:
 - on problematic boxes (no keyboard)  -> LED off
 - on functional boxes (keyboard works)-> LED on


It also seems that on functional boxes, the LEDs go to off state and light 
back up at the 'starting udev' stage.

Lastly (and surprisingly), after plugging the USB keyboard in other places at 
various stages during boot (not after), I could get a problematic box to 
become functional (and I can no longer make it problematic). I reproduced that 
on a second box.
 
> Phillipe, what is a verion that works (other than B4S3, B4S4)?
s/Phillipe/Philippe/

The non-problematic box runs B4S4. The first problematic box was B4S4, the 
second was B4S3, I just upgraded it to B4S4, fiddled with plugging/unplugging 
and it now works. I will have more data on that when I install FC5 on more 
boxes next week.

More information:

- I have reproduced this problem on several other machines now.
- Functional machines (USB works after boot) can become non-functional and 
vice versa (all my boxes have with B4S4 BIOS).
- The problem is not only during install, but at _each_ reboot the machine can 
become non-functional.
- The title of the bug should therefore be changed to something like:
  USB keyboard cannot be used on Sun W1100z
- The problem is grave because the Sun W1100z _only_ has USB ports for the 
keyboard and mouse (no PS/2 ports).
- The LED indicators (comment#11) is not a reliable indicator. In some cases, 
the LED on the mouse base is kept on during the boot and the mouse/keyboards  
are non-functional.
- booting with 'acpi=off' and/or 'single' options does not change anything.
 

Some other information :

I have the exact same problem (same steps to reproduce, FC5 x86_64) except that
my keyboard is a PS/2 keyboard.
The keyboard doesn't work on my PC with a Gigabyte GA-K8NF-9 motherboard (full
configuration : http://www.patheticcockroach.com/mpam4/index.php?p=63#conf4),
but it does work on my PC with a Gigabyte GA-K8NF-9 Ultra (full configuration :
http://www.patheticcockroach.com/mpam4/index.php?p=63#conf5).
I hope this helps...

Gigabyte is a data point, but if we find a fix for Sun, it's going to
be Sun-specific (at least it seems this way for me at present).

Kernel 2.6.16-1.2080_FC5 recompiled with CONFIG_USB_DEBUG=y.  
  
-------------------------------  
Machine with working keyboard  
-------------------------------  
hub 3-0:1.0: power on to power good time: 30ms  
hub 3-0:1.0: local power source is good  
hub 3-0:1.0: no over-current condition exists  
ohci_hcd 0000:01:00.0: suspend root hub  
hub 3-0:1.0: state 7 ports 3 chg 0000 evt 0000  
drivers/usb/core/inode.c: creating file '001'  
ohci_hcd 0000:01:03.0: GetStatus roothub.portstatus [0] = 0x00010301 CSC   
LSDA PPS CCS  
hub 3-0:1.0: port 1, status 0301, change 0001, 1.5 Mb/s  
ohci_hcd 0000:01:03.1: OHCI Host Controller  
drivers/usb/core/inode.c: creating file '004'  
ohci_hcd 0000:01:03.1: new USB bus registered, assigned bus number 4  
ohci_hcd 0000:01:03.1: irq 19, io mem 0xe0130000  
ohci_hcd 0000:01:03.1: resetting from state 'reset', control = 0x0  
ohci_hcd 0000:01:00.1: suspend root hub  
ohci_hcd 0000:01:03.1: OHCI controller state  
....  
  
----------------------------------  
Machine with non-Working keyboard  
----------------------------------  
hub 2-0:1.0: power on to power good time: 2ms  
hub 2-0:1.0: local power source is good  
hub 2-0:1.0: no over-current condition exists  
ieee1394: Initialized config rom entry `ip1394'  
hub 2-0:1.0: state 7 ports 3 chg 0000 evt 0000  
drivers/usb/core/inode.c: creating file '001'  
ohci_hcd 0000:01:00.0: suspend root hub  
ohci_hcd 0000:01:00.1: suspend root hub  
****  No more usb events *****  
  
  
Complete dmesg follows  

Created attachment 128014 [details]
dmesg for working machine

Created attachment 128015 [details]
dmesg for non-working machine

Increasing the delay during hub_power_on() fixes the problem here --well, at 
least for that box ;-). 
 
--- linux-2.6.16.x86_64/drivers/usb/core/hub.c.orig     2006-04-19 
21:32:49.000000000 -0400 
+++ linux-2.6.16.x86_64/drivers/usb/core/hub.c  2006-04-19 21:33:39.000000000 
-0400 
@@ -441,8 +441,8 @@ 
                                        USB_PORT_FEAT_POWER); 
        } 
 
-       /* Wait at least 100 msec for power to become stable */ 
-       msleep(max(pgood_delay, (unsigned) 100)); 
+       /* Wait at least 200 msec for power to become stable */ 
+       msleep(max(pgood_delay, (unsigned) 200)); 
 } 
 

Updated to kernel-2.6.16-1.2096_FC5. Same symptoms as with previous kernels.

> Increasing the delay during hub_power_on() fixes the problem here
> --well, at least for that box
and for two others. However, another box still had problems even with the 
patch applied (since then it became functional again). Will try with a bigger 
delay (e.g 800ms).

The hack at comment#18 does not fix the problem, 
The only consistent workaround for now to purchase a PCI card :-( which the 
kernel detects and configures correctly.

A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.

I'm having the same problem with FC6 x86_64 as in my comment #13 (except that I
didn't test it on my PC with a Gigabyte GA-K8NF-9 Ultra yet) : I can't install
because my keyboard isn't detected.

I can confirm the following on the Sun W1100z:
 - For FC5, kernel 2.6.18-1.2200.fc5 does not fix the problem. I have some 
boxes that still show the problem after the kernel upgrade.

 - FC6 install (kernel-2.6.18-1.2798.fc6.x86_64.rpm) hangs: it starts OK (at 
the 'boot:' menu, one can press 'Enter' to start booting), but after the 
initial boot, the install stops at the first menu where keyboard input is 
expected (it is the test menu, with the choice between 'OK' or 'Skip').

Fedora Core 6 is no longer maintained. Is this bug still present in Fedora 7 or
Fedora 8?

I'm not even trying anymore: removing device support so fast is so stupid that
even Windows don't do it. As far as I remember, Fedora Core 4 and Ubuntu 6.06
(maybe also 6.10) worked with my keyboard and motherboard (see my comment #13),
FC5 and FC6 don't, Ubuntu 7.x doesn't either. I had the same problem with other
Linux distros at that time (since I couldn't install FC, I tried several other
distros before finding Ubuntu, which was the only one working with my keyboard,
until version 7.x...). So my guess is that at some point something common to all
distros (kernel or something?) was "upgraded". I'll post again if I happen to
try Fedora 8, I think my bro already downloaded the DVD.

As far as I know this configuration (ie USB only) is far more common and no
longer presents a problem.  I no longer have access to the system on which this
fault exhibited itself.  Thanks for checking back.

Regards, Bevis.

I just tested with Fedora 8 64 bits, the problem still occurs: the keyboard
works on the very first screen (where we chose between install, install text
only, rescue...) and then it doesn't work when the installer asks whether or not
to skip the disc check.

Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

As I posted in my comment #27, I reproduced this bug with Fedora 8 64 bits. But
I'm not allowed to change the version myself in the bug report.

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  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 '8'.

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 8'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 8 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.