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

 
 

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

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

Submitter:  Horst Prote <prote>
Submitted:  Wed 27 Jun 2012 04:36:47 PM UTC
Votes: 30
 
Category:  None Severity:  Major
Priority:  5 - Normal Item Group:  Software Error
Status:  Fixed Privacy:  Public
Assigned to:  None Originator Name: 
Open/Closed:  Closed Release:  Bazaar - trunk
Release:  Reproducibility:  Every Time
Planned Release:  None

Jump to the original submission

Fri 12 Apr 2013 06:54:00 PM UTC, 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>
Group administrator
Mon 11 Feb 2013 07:14:15 PM UTC, 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).

Conclusion:
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...)

BR,
Ales

Ales Nesrsta <starous>
Group Member
Mon 04 Feb 2013 09:20:30 PM UTC, 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.
BR,
Ales

Ales Nesrsta <starous>
Group Member
Tue 29 Jan 2013 10:55:16 PM UTC, 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:

Good:
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... :-)

Bad:
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.)

BR,
Ales

(file #27349)

Ales Nesrsta <starous>
Group Member
Sun 16 Dec 2012 06:18:33 PM UTC, comment #16: 

Hi,
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... :-(
)

BR,
Ales

Ales Nesrsta <starous>
Group Member
Fri 07 Dec 2012 08:35:15 PM UTC, comment #15: 

Hi,

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
command.
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.

BR,
Ales

Ales Nesrsta <starous>
Group Member
Fri 07 Dec 2012 07:30:39 PM UTC, 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.

BR,
Ales

Ales Nesrsta <starous>
Group Member
Sat 17 Nov 2012 09:25:04 PM UTC, comment #13: 

Hmmmm, it is bad.

Ok, so, in this case:

1.
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...

2.
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?

BR,
Ales

Ales Nesrsta <starous>
Group Member
Tue 13 Nov 2012 02:45:18 PM UTC, 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/.

BR,
Horst

Horst Prote <prote>
Sun 11 Nov 2012 07:42:32 PM UTC, 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 ?

BR,
Ales

Ales Nesrsta <starous>
Group Member
Wed 07 Nov 2012 08:51:09 PM UTC, 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:

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

Ales Nesrsta <starous>
Group Member
Tue 06 Nov 2012 05:00:00 PM UTC, 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 04 Nov 2012 10:02:47 PM UTC, 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>
Group administrator
Sun 04 Nov 2012 09:25:49 PM UTC, 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.
Correction:
...
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>
Group Member
Sun 04 Nov 2012 11:49:59 AM UTC, 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:

1.
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.

2.
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>
Group Member
Sat 03 Nov 2012 07:44:25 PM UTC, 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 02 Nov 2012 10:45:49 PM UTC, comment #4: 

Hi,

Horst, please, send here output of
lspci -vvv
and
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).

BR,
Ales

Ales Nesrsta <starous>
Group Member
Tue 03 Jul 2012 03:01:26 PM UTC, comment #3: 

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

Horst Prote <prote>
Thu 28 Jun 2012 09:12:20 AM UTC, 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 27 Jun 2012 04:58:58 PM UTC, 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>
Group administrator
Wed 27 Jun 2012 04:36:47 PM UTC, 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
or
 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>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #27349:  usb_ehci_split_130129_0 added by starous (7KiB - application/octet-stream)
file #27057:  usb_split_121207_0.patch added by starous (7KiB - text/x-patch - Promised patch)
file #26873:  lspci.out added by prote (60KiB - application/octet-stream - Output of "lspci -vvv" resp. "lsusb -vvv".)
file #26874:  lsusb.out added by prote (28KiB - application/octet-stream - Output of "lspci -vvv" resp. "lsusb -vvv".)
file #26115:  transcript.txt added by prote (10KiB - 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
  • -email is unavailable- added by sascha_silbe
  • -email is unavailable- added by starous (Posted a comment)
  • -email is unavailable- added by prote (Voted in favor of this item)
  • -email is unavailable- added by phcoder (Posted a comment)
  • -email is unavailable- added by prote (Submitted the item)
  •  

    There are 30 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-07-14 sascha_silbe Carbon-Copy- Added sascha_silbe
    2013-04-12 phcoder StatusNone Fixed
        Open/ClosedOpen Closed
    2013-01-29 starous Attached File- Added usb_ehci_split_130129_0, #27349
    2012-12-07 starous Attached File- Added usb_split_121207_0.patch, #27057
    2012-11-03 prote Attached File- Added lspci.out, #26873
        Attached File- Added lsusb.out, #26874
    2012-06-28 prote Carbon-Copy- Added prote
    2012-06-27 prote Attached File- Added transcript.txt, #26115

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code