[Clfs-support] The case of the dead keyboard with the loaded driver...

[A.J. Venter]

SOLVED.
I'm sending this as my last message on the thread, just in case it
happens to somebody else - then the archives may help since it took me
about 8 hours to find a working solution.
When I did, a lot of other things like the framebuffer all started
working at once btw.

The key was this line in the debug log:
ehci-pci 0000:00:1a.0: cache line size of 64 is not supported

The solution is to add the following kernel commandline parameter:
usbcore.autosuspend=-1

I'm not sure what the surrounding triggers are, maybe it is because I
didn't put any suspend/resume or PM features in the kernel (makes no
sense on a desktop - this is not a notebook and it doesn't have a
battery to save) but that's just a guess.

Still maybe this will help somebody else.

Thanks
A.J.

On Wed, Sep 16, 2015 at 8:36 AM, A.J. Venter <ajventer at gmail.com> wrote:
> Some updates:
> neither single nor init=/bin/bash helped
> pci=noapic nolapic didn't help.
>
> I did pick up something though -  there's a difference between the
> host system logs and the CLFS logs:
> On CLFS they USB devices show like this:
> Sep 16 08:30:03 aj_clfs kernel: [    1.621631] usb 1-1.4: new
> low-speed USB device number 5 using ehci-pci
> Sep 16 08:30:03 aj_clfs kernel: [    1.732858] usb 1-1.4: New USB
> device found, idVendor=04d9, idProduct=1603
> Sep 16 08:30:03 aj_clfs kernel: [    1.732922] usb 1-1.4: New USB
> device strings: Mfr=1, Product=2, SerialNumber=0
> Sep 16 08:30:03 aj_clfs kernel: [    1.732987] usb 1-1.4: Product: USB Keyboard
> Sep 16 08:30:03 aj_clfs kernel: [    1.733034] usb 1-1.4: Manufacturer:
>
> But on the host system I see this:
> Sep 16 08:31:52 aj kernel: [    2.161997] usb 1-1.4: Product: USB Keyboard
> Sep 16 08:31:52 aj kernel: [    2.161999] usb 1-1.4: Manufacturer:
> Sep 16 08:31:52 aj kernel: [    2.172814] input:   USB Keyboard as
> /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/input/input6
> Sep 16 08:31:52 aj kernel: [    2.172987] hid-generic
> 0003:04D9:1603.0005: input,hidraw1: USB HID v1.10 Keyboard [  USB
> Keyboard] on usb-0000:00:1a.0-1.4/input0
> Sep 16 08:31:52 aj kernel: [    2.190100] input:   USB Keyboard as
> /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.1/input/input7
>
>
> None of the lines mentioning devices are visible in CLFS.
>
> I wonder if udev could be at fault ?
>
> On Wed, Sep 16, 2015 at 7:47 AM, A.J. Venter <ajventer at gmail.com> wrote:
>> ssh isn't an option as yet (also had that idea) since my network card
>> isn't working yet (onboot error says eth0 doesn't exist - I suspect a
>> naming error but haven't been able to get the information to debug
>> further).
>>
>> I'll try a few tricks like single user and init=/bin/bash, maybe even
>> try one with devpts removed from fstab in case this is a udev issue.
>> Interestingly if I unplug and replug it at the login prompt I can see
>> the message pop up that it was found, but still no response.
>>
>> I'm using the same keyboard in the host system (linux mint 17.2) to
>> write this mail btw.
>>
>> I also believe I've ruled out the kernel almost entirely - I actually
>> took the backup of my previous non-multilib LFS system, copied out the
>> kernel, modules and firmware and placed them onto the new clfs system,
>> updated the bootloader and booted that - no change. That suggest a
>> problem happening post-kernel.
>>
>> Here is my lsusb output from the host machine:
>> Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
>> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>> Bus 001 Device 005: ID 04d9:1603 Holtek Semiconductor, Inc. Keyboard
>> Bus 001 Device 004: ID 0458:014c KYE Systems Corp. (Mouse Systems)
>> Bus 001 Device 003: ID 0e8f:0012 GreenAsia Inc. USB Wireless 2.4GHz Gamepad
>> Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>
>>
>>
>> On Wed, Sep 16, 2015 at 3:29 AM, William Harrington
>> <kb0iic at berzerkula.org> wrote:
>>> On Wed, 16 Sep 2015 02:12:21 +0200
>>> "A.J. Venter" <ajventer at gmail.com> wrote:
>>>
>>>> I haven't the foggiest idea how to debug further. I can only do so
>>>> much from within a chroot, but to debug it with the live kernel is
>>>> rather tricky when that kernel won't let me type and log in.
>>>>
>>>> Any suggestions ? I am happy to send any logs or details that will
>>>> help if you give me an idea what to look for.
>>>
>>> Hello,
>>>
>>> I remember someone having issues with a USB device not working. The issue was the USB ports and kernel drivers. I think it was a USB device using an XHCI port or something like that. Maybe try an EHCI or OHCI USB port. Which ports do you have? Since the keyboard works fine in the boot menu, then somewhere along the line the kernel drivers and port initialization may be causing issues.
>>>
>>> Maybe you can ssh into the machine with the kernel which has no working keyboard input and try to debug that way. Load modules, unload modules, change usb ports for the connected keyboard, and maybe that will help you figure it out. You can also try to login single user mode and see if it works very early, or maybe maintenance mode.
>>>
>>> Sincerely,
>>>
>>> William Harrington
>>
>>
>>
>> --
>> "Semper in excretum set alta variant" - My father
>> A.J. Venter - http://www.silentcoder.co.za
>
>
>
> --
> "Semper in excretum set alta variant" - My father
> A.J. Venter - http://www.silentcoder.co.za



-- 
"Semper in excretum set alta variant" - My father
A.J. Venter - http://www.silentcoder.co.za