bug-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #36740] FTDI USB Serial Device not recognized and "insmod ehci" fre


From: Ales Nesrsta
Subject: [bug #36740] FTDI USB Serial Device not recognized and "insmod ehci" freezes grub
Date: Wed, 07 Nov 2012 20:51:09 +0000
User-agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20100101 Firefox/16.0 Iceweasel/16.0.2

Follow-up Comment #10, bug #36740 (project grub):

Hi Vladimir,
I am afraid it will not help because according to sent lsusb.out it looks like
the serial converter has the same USB ID as it is already included in source
code of ftdi.c:

lsusb.out:
...
Bus 001 Device 003: ID 0403:6001 Future Technology Devices
...

Part of ftdi.c:
...
static const struct
{
  grub_uint16_t vendor, product;
} products[] =
  {
    {0x0403, 0x6001} /* QEMU virtual USBserial.  */
  };
...

So, from my point of view, usb serial driver is most probably loaded and used.
There is question if it is working well with real HW, specially with USB 2.0
FTDI variant. Unfortunately, I don't have such HW to try to test it, all my
three serial converters are PL2303 USB 1.1... :-(

Another thing is - why the GRUB freezes when there is no serial converter
connected and ehci driver is loaded?

According to (unfortunately too short) debug text it looks like EHCI driver
successfully takes ownership of EHCI and EHCI begins communication with some
device - as I can see, without errors.

As Horst told somewhere at the beginning, debug output never stops - so I
think GRUB is probably not really crashing but it is probably "looping"
somewhere in code related to keyboard input - maybe there are some
communication errors or some unexpected situations/data.

Currently I have two ideas:

- Maybe there is some unknown interaction with ATEN KVM switch which is not
"pure" keyboard (according to lsusb.out) - that is why I want to test what
happens when ATEN KVM switch will be not connected.

- Maybe there is some unknown interaction with xHCI or its BIOS SW - there I
have no further idea yet.


What is very bad is impossibility of reasonable debug output capturing. Even I
can reduce some repeating things from debug output, there will be still too
long outputs to capture it only via console and camera as Horst did.
Do You have any idea how to capture debug output in another way?

BR,
Ales

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36740>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]