I finally found 1st commit (not connected with USB problem) which prevents 
booting, but it is corrected much later in 4.10-rc8.I don't know how to locate 
correction commit for the one below
$ git bisect bad
174cc7187e6f088942c8e74daa7baff7b44b33c9 is the first bad commit
commit 174cc7187e6f088942c8e74daa7baff7b44b33c9
Author: Lv Zheng <lv.zh...@intel.com>
Date:   Wed Dec 14 15:04:25 2016 +0800

    ACPICA: Tables: Back port acpi_get_table_with_size() and 
early_acpi_os_unmap_memory() from Linux kernel
    
    ACPICA commit cac6790954d4d752a083e6122220b8a22febcd07
    
    This patch back ports Linux acpi_get_table_with_size() and
    early_acpi_os_unmap_memory() into ACPICA upstream to reduce divergences.
    
    The 2 APIs are used by Linux as table management APIs for long time, it
    contains a hidden logic that during the early stage, the mapped tables
    should be unmapped before the early stage ends.
    
    During the early stage, tables are handled by the following sequence:
     acpi_get_table_with_size();
     parse the table
     early_acpi_os_unmap_memory();
    During the late stage, tables are handled by the following sequence:
     acpi_get_table();
     parse the table
    Linux uses acpi_gbl_permanent_mmap to distinguish the early stage and the
    late stage.
    
    The reasoning of introducing acpi_get_table_with_size() is: ACPICA will
    remember the early mapped pointer in acpi_get_table() and Linux isn't able 
to
    prevent ACPICA from using the wrong early mapped pointer during the late
    stage as there is no API provided from ACPICA to be an inverse of
    acpi_get_table() to forget the early mapped pointer.
    
    But how ACPICA can work with the early/late stage requirement? Inside of
    ACPICA, tables are ensured to be remained in "INSTALLED" state during the
    early stage, and they are carefully not transitioned to "VALIDATED" state
    until the late stage. So the same logic is in fact implemented inside of
    ACPICA in a different way. The gap is only that the feature is not provided
    to the OSPMs in an accessible external API style.
    
    It then is possible to fix the gap by providing an inverse of
    acpi_get_table() from ACPICA, so that the two Linux sequences can be
    combined:
     acpi_get_table();
     parse the table
     acpi_put_table();
    In order to work easier with the current Linux code, acpi_get_table() and
    acpi_put_table() is implemented in a usage counting based style:
     1. When the usage count of the table is increased from 0 to 1, table is
        mapped and .Pointer is set with the mapping address (VALIDATED);
     2. When the usage count of the table is decreased from 1 to 0, .Pointer
        is unset and the mapping address is unmapped (INVALIDATED).
    So that we can deploy the new APIs to Linux with minimal effort by just
    invoking acpi_get_table() in acpi_get_table_with_size() and invoking
    acpi_put_table() in early_acpi_os_unmap_memory(). Lv Zheng.
    
    Link: https://github.com/acpica/acpica/commit/cac67909
    Signed-off-by: Lv Zheng <lv.zh...@intel.com>
    Signed-off-by: Bob Moore <robert.mo...@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

:040000 040000 b675d430a498bccd8a019eda7e48d8fb09854f8b 
720808399136a9d0b4e9b4e52439fea2414d8be4 M      drivers
:040000 040000 b0b35ecad595dfe85ceb7d0defc0d018820a1498 
2263f006f9f48d19afd5603e75cc6af3de5a3a61 M      include

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1822363

Title:
  Booting hangs when USB 3.0 Etron EJ168 PCI card is detected

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  I have installed Etron EJ168 PCI USB 3.0 [1B6F:7023] which briliantly works 
in any Windows OS (I use multiboot PC) on my Conroe865PE AGP/PCI Intel 
Kentsfield QX6800 system with classic BIOS (non UEFI).
  There are no devices connected to PCI USB card during boot.

  The desktop Ubuntu 18.04 kernel 4.15.0-46-generic freezes with this
  card during boot (see attached "photo log" with boot and grub
  options). I can't access/login Ubuntu or console. It was checked and
  confirmed on ubuntu-18.04.1-desktop-amd64.iso LIVE CD desktop (with
  acpi=off option too).

  Previously I was used and removed USB 3.0 NEC Renesas upd720200 PCI card 
[1033:0194], which was partially workable under my installation of Ubuntu 18.04 
and Windows. It had problems from time to time with FW load from card on start 
and not detecting USB devices connected even if FW present.
  I tried and also removed USB 3.0 NEC Renesas upd720202 PCI card [1912:0015] 
which also was partially workable in the same way (other card bios and newer 
NEC chip). System was fully bootable with NEC cards.

  The Etron EJ168 works superb on Windows OS's with directly or with hub 
connections with USB devices.
  I can assist in any way to solve this bug as IT Professional.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822363/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to