Re: BUG: EHCI Bios handoff fails and system gets stuck
Yes Alan, it works ok, thank you (: Are you going to propose this
patch for the mainline?
2014-06-02 11:39 GMT-03:00 Alan Stern :
> On Fri, 30 May 2014, Leandro Liptak wrote:
>
>> Adjunct is the output of dmidecode (:
>> I didn't try setting "try_handoff" to 0, but I think behavior is
>> predictable since in that case the kernel will never reach the
>> pci_write in question. I found a kernel compiling option named "Enable
>> PCI quirk workarounds". It seems what i've been looking for (i mean,
>> disabling of it), at least while i have this buggy bios...
>
> See if the patch below fixes your problem.
>
> Alan Stern
>
>
>
> Index: usb-3.15/drivers/usb/host/pci-quirks.c
> ===
> --- usb-3.15.orig/drivers/usb/host/pci-quirks.c
> +++ usb-3.15/drivers/usb/host/pci-quirks.c
> @@ -656,6 +656,14 @@ static const struct dmi_system_id ehci_d
> DMI_MATCH(DMI_BIOS_VERSION, "Lucid-"),
> },
> },
> + {
> + /* HASEE E200 */
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "HASEE"),
> + DMI_MATCH(DMI_BOARD_NAME, "E210"),
> + DMI_MATCH(DMI_BIOS_VERSION, "6.00"),
> + },
> + },
> { }
> };
>
> @@ -665,9 +673,14 @@ static void ehci_bios_handoff(struct pci
> {
> int try_handoff = 1, tried_handoff = 0;
>
> - /* The Pegatron Lucid tablet sporadically waits for 98 seconds trying
> -* the handoff on its unused controller. Skip it. */
> - if (pdev->vendor == 0x8086 && pdev->device == 0x283a) {
> + /*
> +* The Pegatron Lucid tablet sporadically waits for 98 seconds trying
> +* the handoff on its unused controller. Skip it.
> +*
> +* The HASEE E200 hangs when the semaphore is set (bugzilla #77021).
> +*/
> + if (pdev->vendor == 0x8086 && (pdev->device == 0x283a ||
> + pdev->device == 0x27cc)) {
> if (dmi_check_system(ehci_dmi_nohandoff_table))
> try_handoff = 0;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: EHCI Bios handoff fails and system gets stuck
On Fri, 30 May 2014, Leandro Liptak wrote:
> Adjunct is the output of dmidecode (:
> I didn't try setting "try_handoff" to 0, but I think behavior is
> predictable since in that case the kernel will never reach the
> pci_write in question. I found a kernel compiling option named "Enable
> PCI quirk workarounds". It seems what i've been looking for (i mean,
> disabling of it), at least while i have this buggy bios...
See if the patch below fixes your problem.
Alan Stern
Index: usb-3.15/drivers/usb/host/pci-quirks.c
===
--- usb-3.15.orig/drivers/usb/host/pci-quirks.c
+++ usb-3.15/drivers/usb/host/pci-quirks.c
@@ -656,6 +656,14 @@ static const struct dmi_system_id ehci_d
DMI_MATCH(DMI_BIOS_VERSION, "Lucid-"),
},
},
+ {
+ /* HASEE E200 */
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "HASEE"),
+ DMI_MATCH(DMI_BOARD_NAME, "E210"),
+ DMI_MATCH(DMI_BIOS_VERSION, "6.00"),
+ },
+ },
{ }
};
@@ -665,9 +673,14 @@ static void ehci_bios_handoff(struct pci
{
int try_handoff = 1, tried_handoff = 0;
- /* The Pegatron Lucid tablet sporadically waits for 98 seconds trying
-* the handoff on its unused controller. Skip it. */
- if (pdev->vendor == 0x8086 && pdev->device == 0x283a) {
+ /*
+* The Pegatron Lucid tablet sporadically waits for 98 seconds trying
+* the handoff on its unused controller. Skip it.
+*
+* The HASEE E200 hangs when the semaphore is set (bugzilla #77021).
+*/
+ if (pdev->vendor == 0x8086 && (pdev->device == 0x283a ||
+ pdev->device == 0x27cc)) {
if (dmi_check_system(ehci_dmi_nohandoff_table))
try_handoff = 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: EHCI Bios handoff fails and system gets stuck
Adjunct is the output of dmidecode (: I didn't try setting "try_handoff" to 0, but I think behavior is predictable since in that case the kernel will never reach the pci_write in question. I found a kernel compiling option named "Enable PCI quirk workarounds". It seems what i've been looking for (i mean, disabling of it), at least while i have this buggy bios... 2014-05-29 11:46 GMT-03:00 Alan Stern : > On Wed, 28 May 2014, Leandro Liptak wrote: > >> > If you comment out the pci_write and plug in a USB device, like a flash >> > drive, does it work okay? >> > >> > Have you checked for any BIOS updates available from the manufacturer? >> > This really sounds like a bug in the BIOS. >> >> Yes, any plugged USB device seems to work ok! I didn't find any BIOS >> update.. So I don't know if this line of code is really necessary at >> all, perhaps it could be a configuration option at kernel compilation >> time (?) > > It really is necessary. It is documented in section 5.1 of the EHCI > specification. If your computer hangs then your computer is not > compliant with the spec. This is undoubtedly caused by a BIOS bug. > > What happens if you initialize try_handoff (at the start of the > functionn) to 0 instead of 1, and leave the pci_write unchanged? > > Also, can you post the output from dmidecode? > > Alan Stern > # dmidecode 2.11 SMBIOS 2.6 present. 36 structures occupying 1377 bytes. Table at 0x000DC010. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: Phoenix Technologies LTD Version: 6.00 Release Date: 03/22/2011 Address: 0xE8000 Runtime Size: 96 kB ROM Size: 1024 kB Characteristics: ISA is supported PCI is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported BIOS ROM is socketed EDD is supported Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) USB legacy is supported Smart battery is supported BIOS boot specification is supported Targeted content distribution is supported Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: HASEE Product Name: E200 Version: Revision A Serial Number: 0123456789 UUID: Not Present Wake-up Type: Power Switch SKU Number: 1234567890 Family: 1234567890 Handle 0x0002, DMI type 2, 17 bytes Base Board Information Manufacturer: HASEE Product Name: E210 Version: Revision B Serial Number: 400 Asset Tag: PTL Nanjing Features: Board is a hosting board Board is replaceable Location In Chassis: Not Applicable Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 1 0x Handle 0x0003, DMI type 3, 21 bytes Chassis Information Manufacturer: No Enclosure Type: Other Lock: Not Present Version: N/A Serial Number: None Asset Tag: No Asset Tag Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x1234 Height: Unspecified Number Of Power Cords: Unspecified Contained Elements: 0 Handle 0x0004, DMI type 4, 42 bytes Processor Information Socket Designation: CPU 1 Type: Central Processor Family: Other Manufacturer: Intel ID: CA 06 01 00 FF FB EB BF Version: C1 Voltage: 1.8 V External Clock: 200 MHz Max Speed: 1800 MHz Current Speed: 1800 MHz Status: Populated, Enabled Upgrade: Socket LGA775 L1 Cache Handle: 0x0005 L2 Cache Handle: 0x0006 L3 Cache Handle: Not Provided Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified Core Count: 2 Core Enabled: 2 Thread Count: 4 Characteristics: 64-bit capable Handle 0x0005, DMI type 7, 19 bytes Cache Information Socket Designation: L1 Cache Configuration: Enabled, Socketed, Level 1 Operational Mode: Write Back Location: Internal Installed Size: 24 kB Maximum Size: 24 kB Supported SRAM Types: Burst Pipeline Burst Asynchronous Installed SRAM Type: Asynchronous Speed: Unknown Error Correction Type: Single-
Re: BUG: EHCI Bios handoff fails and system gets stuck
On Wed, 28 May 2014, Leandro Liptak wrote: > > If you comment out the pci_write and plug in a USB device, like a flash > > drive, does it work okay? > > > > Have you checked for any BIOS updates available from the manufacturer? > > This really sounds like a bug in the BIOS. > > Yes, any plugged USB device seems to work ok! I didn't find any BIOS > update.. So I don't know if this line of code is really necessary at > all, perhaps it could be a configuration option at kernel compilation > time (?) It really is necessary. It is documented in section 5.1 of the EHCI specification. If your computer hangs then your computer is not compliant with the spec. This is undoubtedly caused by a BIOS bug. What happens if you initialize try_handoff (at the start of the functionn) to 0 instead of 1, and leave the pci_write unchanged? Also, can you post the output from dmidecode? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: EHCI Bios handoff fails and system gets stuck
> If you comment out the pci_write and plug in a USB device, like a flash > drive, does it work okay? > > Have you checked for any BIOS updates available from the manufacturer? > This really sounds like a bug in the BIOS. Yes, any plugged USB device seems to work ok! I didn't find any BIOS update.. So I don't know if this line of code is really necessary at all, perhaps it could be a configuration option at kernel compilation time (?) Thanks for your time, Alan (: -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: EHCI Bios handoff fails and system gets stuck
On Wed, 28 May 2014, Leandro Liptak wrote: > Alan, pĺease excuse me. I'm a newbie in reporting kernel bugs, and my > domain with english does not help at all (i'm from Argentina). > I have a netbook that gets stuck there, it means that it stop responding at > all and i have to turn off by hand, pressing the power button. I know it > gets stuck at this point because i sailed into the kernel's code and > finally i put a printk before and other after this call; and the later is > never being shown. Moreover, if i comment that pci_write, the whole kernel > startup works ok (or at least it seems to)... If you comment out the pci_write and plug in a USB device, like a flash drive, does it work okay? Have you checked for any BIOS updates available from the manufacturer? This really sounds like a bug in the BIOS. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: EHCI Bios handoff fails and system gets stuck
Alan, pĺease excuse me. I'm a newbie in reporting kernel bugs, and my domain with english does not help at all (i'm from Argentina). I have a netbook that gets stuck there, it means that it stop responding at all and i have to turn off by hand, pressing the power button. I know it gets stuck at this point because i sailed into the kernel's code and finally i put a printk before and other after this call; and the later is never being shown. Moreover, if i comment that pci_write, the whole kernel startup works ok (or at least it seems to)... 2014-05-28 14:23 GMT-03:00 Alan Stern : > On Wed, 28 May 2014, Leandro Liptak wrote: > >> Greg Kroah-Hartman (g...@kroah.com) request me to send this bug to >> this mailing list. >> Link: https://bugzilla.kernel.org/show_bug.cgi?id=77021 > > Your bug report says: > >> Seems that kernel gets stuck here: >> >> (file drivers/usb/host/pci-quirks.c, function ehci_bios_handoff) >> >> -> pci_write_config_byte(pdev, offset + 3, 1); > > What does that mean? And how do you know that the kernel gets stuck > there? > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: EHCI Bios handoff fails and system gets stuck
On Wed, 28 May 2014, Leandro Liptak wrote: > Greg Kroah-Hartman (g...@kroah.com) request me to send this bug to > this mailing list. > Link: https://bugzilla.kernel.org/show_bug.cgi?id=77021 Your bug report says: > Seems that kernel gets stuck here: > > (file drivers/usb/host/pci-quirks.c, function ehci_bios_handoff) > > -> pci_write_config_byte(pdev, offset + 3, 1); What does that mean? And how do you know that the kernel gets stuck there? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
