bugGNU GRUB - Bugs: bug #36740, FTDI USB Serial Device not...


You are not allowed to post comments on this tracker with your current authentification level.

bug #36740: FTDI USB Serial Device not recognized and "insmod ehci" freezes grub

Submitted by:  Horst Prote <prote>
Submitted on:  Wed Jun 27 16:36:47 2012  
Votes:  10  
Category: NoneSeverity: Major
Priority: 5 - NormalItem Group: Software Error
Status: FixedPrivacy: Public
Assigned to: NoneOriginator Name: 
Open/Closed: ClosedRelease: 
Release: Bazaar - trunkReproducibility: Every Time
Planned Release: None

(Jump to the original submission Jump to the original submission)

Fri Apr 12 18:54:00 2013, comment #20:

Patch committed, thanks. As for the second problem it's probably about fini_hw, I modified it to continue even if errors occur, this should fix the problem.

Vladimir Serbinenko <phcoder>
Project Administrator
Mon Feb 11 19:14:15 2013, comment #19:

Hi once again,

I made some investigation about boot freezing today and I found this:
GRUB DOES NOT FREEZE ON BOOT when module for companion USB host controller (UHCI in my case) is loaded together with EHCI module.

So, I think that the freezing is not real bug (e.g. some memory corruption etc.) but "feature" which can happen in some case of BIOS properties/settings, USB HW configuration and "partial" USB handling by GRUB.
Maybe is good to mention this case somewhere in GRUB documentation, e.g. by something like following text:
If PC has EHCI controller with companion controller(s) UHCI/OHCI, than should be loaded both modules ehci + uhci/ohci (or none of them). In another case some USB related things can behave unexpectedly (because, in such case, some parts of the common USB HW are handled by GRUB and some by BIOS).

I think the subject of this bug is solved by patch https://savannah.gnu.org/support/download.php?file_id=27349

The second "bug" I found is probably not a bug - and it can be avoided by this:
1. Don't load any GRUB USB driver :-)
2. Load drivers for all types of USB controllers on PC, not EHCI only.
(There could be one potential problem - GRUB doesn't have driver for xHCI...)


Ales Nesrsta <starous>
Project Member
Mon Feb 4 21:20:30 2013, comment #18:

Hi again,
only some addendum - I forgot to mention probably important thing related to freezing on boot caused by USB keyboard:
Freezing is not related to patch included here. It happens also without this patch, e.g. if USB keyboard is connected via USB 2.0 hub.

Ales Nesrsta <starous>
Project Member
Tue Jan 29 22:55:16 2013, comment #17:

Hi Vladimir,

thanks to my colleague I finally have some old device with 4-port USB 1.1 hub. Today I tested my patch published here previously - with some changes according to actual state of related USB files in trunk. I sent actual patch here as usb_ehci_split_130129_0.

After testing I have two news - one good and one bad:

Patch is OK - it repairs some mistake related to values needed for split transfers, hub address and number of port where is full/low speed device connected on the USB 2.0 hub.
So, any full/low speed device (including USB keyboard, of course) is now working correctly if it is connected via USB 1.1 hub to USB 2.0 hub and EHCI - at least on my PC with my hubs... :-)

I found another very bad bug - GRUB freezes when booting Linux if USB keyboard is used with EHCI (maybe also with UHCI/OHCI, I didn't test it yet).
The last text displayed on console is "Booting the kernel.".
If some serial console is connected to GRUB via USB/RS232 converter, the last text on such serial console is "Loading initial ramdisk...".
I did not test what will be displayed if standard serial port will be used for serial console.

What is very interesting for me, the freezing DOES NOT occur when USB keyboard is connected AFTER loading EHCI driver.
And, in opposite, GRUB freezes in booting process every time if USB keyboard is connected BEFORE loading EHCI driver (i.e., USB keyboard is handled by BIOS until EHCI module is loaded).

And there is second potential bug (which maybe has something to do with the first one): If USB keyboard is connected BEFORE EHCI driver is loaded, USB keyboard is sometimes not working in GRUB until it is unplugged and plugged again.

Maybe my testing situation is little bit special - I have connected PS2 keyboard to PC together with tested USB keyboard and I have enabled "USB legacy support" in BIOS which means handling of USB hubs, keyboards and mass storage devices by BIOS. (I expect problem does not happen if USB legacy support will be disabled in BIOS - but I didn't test it yet.)

Could You try GRUB with my patch if the same situations happen also on Your PC?

In both cases (bugs) I suspect as the reason some bad interaction between GRUB and BIOS - maybe GRUB is using (somewhere in terminal code or elsewhere?) some BIOS keyboard routine which becomes dead when EHCI driver is loaded - is it possible?
(From my point of view this freezing looks little bit similarly like situation with booting from USB disk which I was talking about in ML in thread "Boot GRUB from USB - potential problem" in December. With big difference - the "USB keyboard crash" happens not immediately but at the time when GRUB finishes its work...)

Do You have some another idea(s)?
(The next suspect thing could be potentialy "grub_ehci_cancel_transfer" routine for LOW speed device, i.e. "abnormal" removing QH from Periodic List - I little bit don't like part of its current code, it seems to be in conflict with EHCI specification part related to handling interrupt split transfers in periodic list. But, if the problem will be in this function, the freezing should occur EVERY TIME, independently if USB keyboard is connected before or after loading of EHCI driver - so I think it is not the reason.)


(file #27349)

Ales Nesrsta <starous>
Project Member
Sun Dec 16 18:18:33 2012, comment #16:

I borrowed FTDI USB/serial converter to test the HW compatibility with GRUB.
Borrowed device has the same USB ID 0403:6001 - but it is FULL speed device, not HIGH speed as Horst have. I hope it doesn't matter.
For the first look it seems to be working well - GRUB recognizes this device and works with it (e.g. serial_usb0).

I tried connect another computer with PuTTY application to GRUB via serial line and FTDI - to use PuTTY as second GRUB console.
I used on GRUB side these commands:
terminal_input console serial_usb0
terminal_output console serial_usb0

It worked well - I didn't find any problem.

So, I hope, if my previously mentioned/sent patch is correct, it looks You can be satisfied :-)

I tested the patch on my PC if it doesn't make some regression etc. - it looks to be OK.
But I still did not test Your (Horst) configuration, i.e. correct function of chain EHCI -> USB 2 hub -> USB 1 hub -> low/full speed device - because I still didn't receive USB 1 hub.
It is not so easy to get USB 1 hub nowadays, there are USB 2 only... :-(


Ales Nesrsta <starous>
Project Member
Fri Dec 7 20:35:15 2012, comment #15:


I sent promised patch - https://savannah.gnu.org/bugs/download.php?file_id=27057 - You can try it if You want (and if You have enough courage to try it on machine with important data... :-) )

You should load EHCI driver, i.e. You should issue
insmod ehci
After that Your USB keyboard should be still alive and if You connect FTDI serial converter, it (maybe) will work - if GRUB FTDI driver is suitable also for real HW.


Ales Nesrsta <starous>
Project Member
Fri Dec 7 19:30:39 2012, comment #14:

Hi Horst,

I probably found the cause of this bug.

I will prepare some experimental patch (soon - I hope) which You can try - if You want.
I will make my own tests later when the ordered USB hub 1.1 will come to me (it takes probably (very) long time...).

To Vladimir:

The problem is related to split transfer. EHCI needs address and port related to FULL/LOW speed device connected to USB 2.0 hub which can do transaction translation of split packets.

In Horst case it should be the address and port of USB 2.0 hub integrated in PC where the ATEN KVM switch is connected (because ATEN is FULL speed device - USB 1.1 hub with some special HID compound device connected to it, i.e. the transaction transaction should be done in USB 2.0 hub in PC).

But GRUB uses (for split transfer) address and port of hub to which is target device DIRECTLY connected - in Horst case it is address and port of ATEN USB 1.1 hub (which, of course, cannot do transaction translation...).
In another word, GRUB will fail in communication with any device which is connected via USB 1.1 hub to USB 2.0 hub when USB 2.) hub is attached to EHCI controller. This problem cannot happen on OHCI/UHCI controller.
I should rewrite whole logic which is related to "hubaddr" and "port" members of grub_usb_device which I added together with EHCI.


Ales Nesrsta <starous>
Project Member
Sat Nov 17 21:25:04 2012, comment #13:

Hmmmm, it is bad.

Ok, so, in this case:

It will be interesting if You find some time to shut down this machine and try the experiment described before.
I.e. disconnect this PC from ATEN KVM switch, connect USB keyboard & some monitor instead and try if GRUB will be "alive".
If Yes, try connect FTDI serial converter togehter with keyboard and test again if GRUB will be functional (and possibly also FTDI).
If Yes, we will know that the problem is "only" with ATEN KVM switch, e.g. with chain EHCI->USB2.0 hub->USB 1.1 hub->Low speed HID device(s) - maybe there is some mistake in GRUB USB hub functions or elsewhere...

It will be VERY important to get full debug output of Your situation (not only "ehci" but "all" - to see debug messages from all GRUB USB modules).
But, don't try it yet - because FTDI is not functional and there is no another "normal" serial port, it is difficult or nearly impossible to save debug output - there will be LOT OF scrolling text which You cannot "capture" by camera...

Vladimir, do You have some idea how to save debug output in some another way?


Ales Nesrsta <starous>
Project Member
Tue Nov 13 14:45:18 2012, comment #12:

Hi Ales,

when I made my test and got the freezes in June I had installed grub from trunk source on Tue Jun 26 17:03:19 2012 CEST and according to my logs revision 4532 was fetched from http://bzr.savannah.gnu.org/r/grub/trunk/grub/.


Horst Prote <prote>
Sun Nov 11 19:42:32 2012, comment #11:

Hi Horst,

there is one important thing - according to lsusb.out You have connected kayboard (ATEN switch) in this way:

EHCI -> PC internal USB2.0 Hub -> ATEN internal USB1.1 Hub -> ATEN keyboard

I.e. You probably hit this EHCI problem: USB keyboard (or any USB low speed device) cannot be connected to EHCI via USB2.0 hub.

This problem was fixed in trunk version approx. half year ago (AFAIK after official release of GRUB 2.0 version).

So, there is important question:
Do You using official GRUB release 2.0 or did You make it from trunk source ?


Ales Nesrsta <starous>
Project Member
Wed Nov 7 20:51:09 2012, comment #10:

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:

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?


Ales Nesrsta <starous>
Project Member
Tue Nov 6 17:00:00 2012, comment #9:

How/where would I add the device id to the list?

And does this make the reboot test obsolete? As the machine is an important server of our institute I can't reboot it as I like.

Horst Prote <prote>
Sun Nov 4 22:02:47 2012, comment #8:

GRUB2 FTDI driver uses only deviceid for qemu. It won't detect any other FTDI. You need to add your device id manually to the list

Vladimir Serbinenko <phcoder>
Project Administrator
Sun Nov 4 21:25:49 2012, comment #7:

ad 1.
Sorry, I forgot the GRUB has separate driver for FTDI.
But I don't know its status (if it is tested and working with real HW - not only in QEMU).

ad 2.
I.e., try to start PC in this way: Connect to PC only "normal" USB keyboard and some monitor, nothing else.
+ Try boot GRUB and load EHCI driver.
Does it help?
+ If it does not freeze, try to connect serial converter and check if it works.

Ales Nesrsta <starous>
Project Member
Sun Nov 4 11:49:59 2012, comment #6:

Hm, it was bad idea - You have really USB 2.0 version of serial converter.

So, from my point of view there are these possible reasons:

Your serial converter is not fully compatible with GRUB USB serial driver which is related to Prolific PL2303.
It might be pssible because Your converter has little bit another configuration of endpoints (e.g. there is missing interrupt endpoint according to my device).
But I don't expect it too much.

You are using ATEN KVM switch instead of "normal" keyboard, mouse and monitor. KVM switch is some compound USB device possibly not compatible with GRUB yet - it could be the reason why GRUB freezes when EHCI driver is loaded.

Could You try boot GRUB without ATEN KVM switch?
I.e., try to start PC in this way: Connect to PC only "normal" USB keyboard and some monitor, nothing else.
Does it help?

Ales Nesrsta <starous>
Project Member
Sat Nov 3 19:44:25 2012, comment #5:

I attached the output of "lspci -vvv" in lspci.out and "lsusb -vvv" in lsusb.out.

(file #26873, file #26874)

Horst Prote <prote>
Fri Nov 2 22:45:49 2012, comment #4:


Horst, please, send here output of
lspci -vvv
lsusb -vvv

There is something strange - RS232 converter is (most probably) of USB 1.1 type, i.e. it cannot be connected into EHCI - EHCI itself cannot manage USB 1.1 devices.

So, there is maybe some integrated USB hub between EHCI and device - or USB 1.1 devices are manged via xHCI (I don't know if it is possible, I didn't study it yet).


Ales Nesrsta <starous>
Project Member
Tue Jul 3 15:01:26 2012, comment #3:

> Even partital debug log can be very useful.
Does my attached transcript help or shall I add more?

Horst Prote <prote>
Thu Jun 28 09:12:20 2012, comment #2:

Yes you are right: According to dmesg the mobo has:
ehci_hcd 0000:00:1a.0: EHCI Host Controller
ehci_hcd 0000:00:1d.0: EHCI Host Controller
xhci_hcd 0000:03:00.0: xHCI Host Controller
xhci_hcd 0000:03:00.0: xHCI Host Controller
xhci_hcd 0000:04:00.0: xHCI Host Controller
xhci_hcd 0000:04:00.0: xHCI Host Controller
and my dongle is connected to one of the EHCI Controller:
usb 1-1: new high-speed USB device number 2 using ehci_hcd
usb 1-1.1: new full-speed USB device number 3 using ehci_hcd
usb 1-1.1: Detected FT232RL
usb 1-1.1: Number of endpoints 2
usb 1-1.1: Endpoint 1 MaxPacketSize 64
usb 1-1.1: Endpoint 2 MaxPacketSize 64
usb 1-1.1: Setting MaxPacketSize 64
usb 1-1.1: FTDI USB Serial Device converter now attached to ttyUSB0

By the way the 'insmod ehci' freezes grub even when I dosconnect the dongle.

Horst Prote <prote>
Wed Jun 27 16:58:58 2012, comment #1:

It didn't work with uhci/ohci since probably your mobo doesn't have these controllers. Even partital debug log can be very useful. EHCI module hasn't been tested long enough yet to round up all the edges, especiallly given the amount of troublesome hardware around.

Vladimir Serbinenko <phcoder>
Project Administrator
Wed Jun 27 16:36:47 2012, original submission:

My aim is to have grub terminal over serial line but as the mainboard has no serial connector I bought an USB-Serial dongle but it is not recognized by "usb" on grub command line. Even after
 insmod uhci
 insmod ohci
the "usb" command still lists no device.

When I enter
insmod ehci
grub freezes. So I repeated this with a prior "set debug=ehci" and got fast scrolling debug messages which seem to repeat themselves in an endless loop. Once I let this running for 3:30 minutes before pressing the reset button. Unfortunately without a serial console I can't copy the messages to a file. I tried to shoot some pictures/movies but the photo camera didn't catch everything and the video camera has only 25 fps. Shall I attach them nonetheless?
I'll attach my transcript of some lines.

When the system is booted the agetty on ttyUSB0 works fine though.

System is gentoo, amd64 with grub-9999 (which is revision 4532 from bzr) and USE flags for grub_platforms_efi-64 and device-mapper.

# lsusb | grep USB-Serial
Bus 002 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

# cat /proc/tty/driver/usbserial
usbserinfo:1.0 driver:2.0
0: name:"FTDI USB Serial Device" vendor:0403 product:6001 num_ports:1 port:1 path:usb-0000:00:1d.0-1.5

The mainboard is an Asus P8P67 DELUXE.

Horst Prote <prote>


Attached Files
file #27349:  usb_ehci_split_130129_0 added by starous (7kB - application/octet-stream)
file #27057:  usb_split_121207_0.patch added by starous (7kB - text/x-patch - Promised patch)
file #26873:  lspci.out added by prote (60kB - application/octet-stream - Output of "lspci -vvv" resp. "lsusb -vvv".)
file #26874:  lsusb.out added by prote (28kB - application/octet-stream - Output of "lspci -vvv" resp. "lsusb -vvv".)
file #26115:  transcript.txt added by prote (10kB - text/plain - Video/Photo transcript of ehci debug messages)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by starous (Posted a comment)
  • -unavailable- added by prote (Voted in favor of this item)
  • -unavailable- added by phcoder (Posted a comment)
  • -unavailable- added by prote (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 10 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri Apr 12 18:54:00 2013phcoderStatusNone=>Fixed
    Tue Jan 29 22:55:16 2013starousAttached File-=>Added usb_ehci_split_130129_0, #27349
    Fri Dec 7 20:18:44 2012starousAttached File-=>Added usb_split_121207_0.patch, #27057
    Sat Nov 3 19:44:25 2012proteAttached File-=>Added lspci.out, #26873
      Attached File-=>Added lsusb.out, #26874
    Thu Jun 28 09:12:20 2012proteCarbon-Copy-=>Added prote
    Wed Jun 27 16:36:47 2012proteAttached File-=>Added transcript.txt, #26115

    Back to the top

    Powered by Savane 3.1-cleanup