Re: PROBLEM: OHCI HCD - computer freezes during boot

Re: PROBLEM: OHCI HCD - computer freezes during boot

[Alan Stern]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8, Size: 2640 bytes --]

On Wed, 11 Apr 2012, Calin Demian wrote:

> Hi!
> Yes, in fact I did allready follow the execution, and it looks like this:
> function                                file
> pci_apply_final_quirks           /drivers/pci/quirks.c
> pci_fixup_device                    ~
> pci_do_fixups                        ~
> here, for the ohci busses 2 functions are called:
>   nv_msi_ht_cap_quirk_all       /drivers/usb/host/pci-quirks.c

What is that?  It's not present in my copy of the kernel source.

>   quirk_usb_early_handoff        ~
> quirk_usb_early_handoff calls the following 3 functions:
>   pci_enable_device(pdev)         /drivers/pci/pci.c
>   quirk_usb_handoff_ohci(pdev)    /drivers/usb/host/pci-quirks.c
>   pci_disable_device(pdev)
> 
> The execution stops inside pci_disable_device, but because
> quirk_usb_handoff_ohci is the only function that has changed between
> versions 3.0.13 and 3.0.20 from the list of files mentioned above, it
> seems that this function changed behaviour in a way that my computer
> doesn't like.

That cannot be right.  The call to pci_disable_device was added after 
the change to quirk_usb_handoff_ohci.

>   Further trace:
>   pci_disable_device
>     do_pci_disable_device
>       pci_read_config_word

I have no idea why your computer would crash inside or after
pci_read_config_word.

Anyway, this is a PCI problem, not a USB problem.  Maybe the PCI 
experts can help.  I have CC'ed the linux-pci mailing list.

Alan Stern

> with respect,
> Calin Demian
> 
> 
> 2012/4/11 Alan Stern <stern@rowland.harvard.edu>:
> > On Wed, 11 Apr 2012, Calin Demian wrote:
> >
> >> 1.Boot problem: computer stops responding during boot.
> >>
> >> 2.The symptom doesn't occur allways, but when it does, it is at the
> >> same point during the boot process. The last messages displayed differ
> >> between different kernel versions, but are the same each time.
> >>   I would appreciate if you could take a look at function
> >> "quirk_usb_handoff_ohci" in file /drivers/usb/host/pci-quirks.c -
> >> which was modified in version 3.0.17 of the mainline kernel. The
> >> problem appeared when upgrading Ubuntu from mainline kernel version
> >> 3.0.13 to version 3.0.20. Searching the changelogs I found that this
> >> function was modified between the two releases. The  computer freezes
> >> durin applying the quirks (pci_apply_final_quirks) for bus
> >> 0000:00:13.1 (the 2nd OHCI bus). Controller is ALI  (EHCI 8 ports +
> >> OHCI 3x3 ports), dev_id 5237(OHCI).
> >
> > Can you figure out exactly where the computer stops, by adding printk
> > lines to the quirk_usb_handoff_ohci function?
> >
> > Alan Stern

Re: PROBLEM: OHCI HCD - computer freezes during boot

[Bjorn Helgaas]

On Wed, Apr 11, 2012 at 1:38 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Wed, 11 Apr 2012, Calin Demian wrote:
>
>> Hi!
>> Yes, in fact I did allready follow the execution, and it looks like this:
>> function                                file
>> pci_apply_final_quirks           /drivers/pci/quirks.c
>> pci_fixup_device                    ~
>> pci_do_fixups                        ~
>> here, for the ohci busses 2 functions are called:
>>   nv_msi_ht_cap_quirk_all       /drivers/usb/host/pci-quirks.c
>
> What is that?  It's not present in my copy of the kernel source.
>
>>   quirk_usb_early_handoff        ~
>> quirk_usb_early_handoff calls the following 3 functions:
>>   pci_enable_device(pdev)         /drivers/pci/pci.c
>>   quirk_usb_handoff_ohci(pdev)    /drivers/usb/host/pci-quirks.c
>>   pci_disable_device(pdev)
>>
>> The execution stops inside pci_disable_device, but because
>> quirk_usb_handoff_ohci is the only function that has changed between
>> versions 3.0.13 and 3.0.20 from the list of files mentioned above, it
>> seems that this function changed behaviour in a way that my computer
>> doesn't like.
>
> That cannot be right.  The call to pci_disable_device was added after
> the change to quirk_usb_handoff_ohci.
>
>>   Further trace:
>>   pci_disable_device
>>     do_pci_disable_device
>>       pci_read_config_word
>
> I have no idea why your computer would crash inside or after
> pci_read_config_word.
>
> Anyway, this is a PCI problem, not a USB problem.  Maybe the PCI
> experts can help.  I have CC'ed the linux-pci mailing list.
>
> Alan Stern
>
>> with respect,
>> Calin Demian
>>
>>
>> 2012/4/11 Alan Stern <stern@rowland.harvard.edu>:
>> > On Wed, 11 Apr 2012, Calin Demian wrote:
>> >
>> >> 1.Boot problem: computer stops responding during boot.
>> >>
>> >> 2.The symptom doesn't occur allways, but when it does, it is at the
>> >> same point during the boot process. The last messages displayed differ
>> >> between different kernel versions, but are the same each time.
>> >>   I would appreciate if you could take a look at function
>> >> "quirk_usb_handoff_ohci" in file /drivers/usb/host/pci-quirks.c -
>> >> which was modified in version 3.0.17 of the mainline kernel. The
>> >> problem appeared when upgrading Ubuntu from mainline kernel version
>> >> 3.0.13 to version 3.0.20. Searching the changelogs I found that this
>> >> function was modified between the two releases. The  computer freezes
>> >> durin applying the quirks (pci_apply_final_quirks) for bus
>> >> 0000:00:13.1 (the 2nd OHCI bus). Controller is ALI  (EHCI 8 ports +
>> >> OHCI 3x3 ports), dev_id 5237(OHCI).

It sounds like this is a regression between 3.0.13 and 3.0.20.  Can
you please open a bug report here:

https://bugzilla.kernel.org/enter_bug.cgi?product=Drivers&component=PCI

and attach dmesg or serial console logs with "debug ignore_loglevel
initcall_debug" for both kernels?  For 3.0.20 you probably can't get a
dmesg log because of the hang, so a digital photo would be fine, too.

Thanks,
  Bjorn

Re: PROBLEM: OHCI HCD - computer freezes during boot

[Calin Demian]

I have reported the issue in bugzilla, before (bug 43073). Because the
problem does not appear every time, I am able to boot with new kernels
(sometimes).
I also found that the problem is triggered by a specific sequence of
io read/write operations (including the software reset) related to the
host controller (during init) and by changing the operations or
inserting delays between them it can be solved.
However, since I wasn't able to duplicate the issue on other computers
(which I know I should have done first) it could be a hardware failure
(a weird one) brought to surface by that software change (I know for
sure it's the function I mentioned below). If that is true, than I
appologize for not having it tested in more detail first.
 On the other hand, (I don't know the exact specs) if it is not the
hardware, I can provide further details if needed.

Calin Demian

2012/4/23 Bjorn Helgaas <bhelgaas@google.com>:
> On Wed, Apr 11, 2012 at 1:38 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>> On Wed, 11 Apr 2012, Calin Demian wrote:
>>
>>> Hi!
>>> Yes, in fact I did allready follow the execution, and it looks like this:
>>> function                                file
>>> pci_apply_final_quirks           /drivers/pci/quirks.c
>>> pci_fixup_device                    ~
>>> pci_do_fixups                        ~
>>> here, for the ohci busses 2 functions are called:
>>>   nv_msi_ht_cap_quirk_all       /drivers/usb/host/pci-quirks.c
>>
>> What is that?  It's not present in my copy of the kernel source.
>>
>>>   quirk_usb_early_handoff        ~
>>> quirk_usb_early_handoff calls the following 3 functions:
>>>   pci_enable_device(pdev)         /drivers/pci/pci.c
>>>   quirk_usb_handoff_ohci(pdev)    /drivers/usb/host/pci-quirks.c
>>>   pci_disable_device(pdev)
>>>
>>> The execution stops inside pci_disable_device, but because
>>> quirk_usb_handoff_ohci is the only function that has changed between
>>> versions 3.0.13 and 3.0.20 from the list of files mentioned above, it
>>> seems that this function changed behaviour in a way that my computer
>>> doesn't like.
>>
>> That cannot be right.  The call to pci_disable_device was added after
>> the change to quirk_usb_handoff_ohci.
>>
>>>   Further trace:
>>>   pci_disable_device
>>>     do_pci_disable_device
>>>       pci_read_config_word
>>
>> I have no idea why your computer would crash inside or after
>> pci_read_config_word.
>>
>> Anyway, this is a PCI problem, not a USB problem.  Maybe the PCI
>> experts can help.  I have CC'ed the linux-pci mailing list.
>>
>> Alan Stern
>>
>>> with respect,
>>> Calin Demian
>>>
>>>
>>> 2012/4/11 Alan Stern <stern@rowland.harvard.edu>:
>>> > On Wed, 11 Apr 2012, Calin Demian wrote:
>>> >
>>> >> 1.Boot problem: computer stops responding during boot.
>>> >>
>>> >> 2.The symptom doesn't occur allways, but when it does, it is at the
>>> >> same point during the boot process. The last messages displayed differ
>>> >> between different kernel versions, but are the same each time.
>>> >>   I would appreciate if you could take a look at function
>>> >> "quirk_usb_handoff_ohci" in file /drivers/usb/host/pci-quirks.c -
>>> >> which was modified in version 3.0.17 of the mainline kernel. The
>>> >> problem appeared when upgrading Ubuntu from mainline kernel version
>>> >> 3.0.13 to version 3.0.20. Searching the changelogs I found that this
>>> >> function was modified between the two releases. The  computer freezes
>>> >> durin applying the quirks (pci_apply_final_quirks) for bus
>>> >> 0000:00:13.1 (the 2nd OHCI bus). Controller is ALI  (EHCI 8 ports +
>>> >> OHCI 3x3 ports), dev_id 5237(OHCI).
>
> It sounds like this is a regression between 3.0.13 and 3.0.20.  Can
> you please open a bug report here:
>
> https://bugzilla.kernel.org/enter_bug.cgi?product=Drivers&component=PCI
>
> and attach dmesg or serial console logs with "debug ignore_loglevel
> initcall_debug" for both kernels?  For 3.0.20 you probably can't get a
> dmesg log because of the hang, so a digital photo would be fine, too.
>
> Thanks,
>  Bjorn

Re: PROBLEM: OHCI HCD - computer freezes during boot

[Alan Stern]

On Wed, 25 Apr 2012, Calin Demian wrote:

> I have reported the issue in bugzilla, before (bug 43073). Because the
> problem does not appear every time, I am able to boot with new kernels
> (sometimes).
> I also found that the problem is triggered by a specific sequence of
> io read/write operations (including the software reset) related to the
> host controller (during init) and by changing the operations or
> inserting delays between them it can be solved.

What delays do you need, and where should they be inserted?

Alan Stern

Re: PROBLEM: OHCI HCD - computer freezes during boot

[Calin Demian]

I don't know how, but adding the following line in function
quirk_usb_handoff_ohci makes the system work fine:

	/* reset requires max 10 us delay */
+	udelay(1);
	for (cnt = 30; cnt > 0; --cnt) {	/* ... allow extra time */
		if ((readl(base + OHCI_CMDSTATUS) & OHCI_HCR) == 0)

I observed thad the condition in the for loop is allways true, so the
delay inside the loop is never executed.
With the unmodified source, the execution doesn't stop at this point
but at the next readl (I tried inserting printk and readl instructions
after the writel which restores the fminterval and the execution
stopped before exiting quirk_usb_handoff_ohci).
I don't know how it relates to the ACPI message... (see bug 43073 in
bugzilla.kernel.org).

Calin Demian

2012/4/25 Alan Stern <stern@rowland.harvard.edu>:
> On Wed, 25 Apr 2012, Calin Demian wrote:
>
>> I have reported the issue in bugzilla, before (bug 43073). Because the
>> problem does not appear every time, I am able to boot with new kernels
>> (sometimes).
>> I also found that the problem is triggered by a specific sequence of
>> io read/write operations (including the software reset) related to the
>> host controller (during init) and by changing the operations or
>> inserting delays between them it can be solved.
>
> What delays do you need, and where should they be inserted?
>
> Alan Stern
>

Re: PROBLEM: OHCI HCD - computer freezes during boot

[Alan Stern]

On Thu, 26 Apr 2012, Calin Demian wrote:

> I don't know how, but adding the following line in function
> quirk_usb_handoff_ohci makes the system work fine:
> 
> 	/* reset requires max 10 us delay */
> +	udelay(1);
> 	for (cnt = 30; cnt > 0; --cnt) {	/* ... allow extra time */
> 		if ((readl(base + OHCI_CMDSTATUS) & OHCI_HCR) == 0)
> 
> I observed thad the condition in the for loop is allways true, so the
> delay inside the loop is never executed.
> With the unmodified source, the execution doesn't stop at this point
> but at the next readl (I tried inserting printk and readl instructions
> after the writel which restores the fminterval and the execution
> stopped before exiting quirk_usb_handoff_ohci).
> I don't know how it relates to the ACPI message... (see bug 43073 in
> bugzilla.kernel.org).

I don't know just what the problem is either, but there's nothing wrong 
with delaying startup by 1 us.  In fact, all we have to do is reorder 
the statements within the loop.  Is this patch okay for you?

Alan Stern



Index: usb-3.4/drivers/usb/host/pci-quirks.c
===================================================================
--- usb-3.4.orig/drivers/usb/host/pci-quirks.c
+++ usb-3.4/drivers/usb/host/pci-quirks.c
@@ -520,9 +520,10 @@ static void __devinit quirk_usb_handoff_
 
 	/* reset requires max 10 us delay */
 	for (cnt = 30; cnt > 0; --cnt) {	/* ... allow extra time */
+		/* Some controllers enable HCR too soon, so always delay 1 us */
+		udelay(1);
 		if ((readl(base + OHCI_CMDSTATUS) & OHCI_HCR) == 0)
 			break;
-		udelay(1);
 	}
 	writel(fminterval, base + OHCI_FMINTERVAL);
 

Re: PROBLEM: OHCI HCD - computer freezes during boot

[Greg KH]

On Thu, Apr 26, 2012 at 10:25:41AM -0400, Alan Stern wrote:
> On Thu, 26 Apr 2012, Calin Demian wrote:
> 
> > I don't know how, but adding the following line in function
> > quirk_usb_handoff_ohci makes the system work fine:
> > 
> > 	/* reset requires max 10 us delay */
> > +	udelay(1);
> > 	for (cnt = 30; cnt > 0; --cnt) {	/* ... allow extra time */
> > 		if ((readl(base + OHCI_CMDSTATUS) & OHCI_HCR) == 0)
> > 
> > I observed thad the condition in the for loop is allways true, so the
> > delay inside the loop is never executed.

That implies that something is wrong with the complier here, and it
optimized out the loop?  Are you sure that really happened?

greg k-h

Re: PROBLEM: OHCI HCD - computer freezes during boot

[Alan Stern]

On Thu, 26 Apr 2012, Greg KH wrote:

> On Thu, Apr 26, 2012 at 10:25:41AM -0400, Alan Stern wrote:
> > On Thu, 26 Apr 2012, Calin Demian wrote:
> > 
> > > I don't know how, but adding the following line in function
> > > quirk_usb_handoff_ohci makes the system work fine:
> > > 
> > > 	/* reset requires max 10 us delay */
> > > +	udelay(1);
> > > 	for (cnt = 30; cnt > 0; --cnt) {	/* ... allow extra time */
> > > 		if ((readl(base + OHCI_CMDSTATUS) & OHCI_HCR) == 0)
> > > 
> > > I observed thad the condition in the for loop is allways true, so the
> > > delay inside the loop is never executed.
> 
> That implies that something is wrong with the complier here, and it
> optimized out the loop?  Are you sure that really happened?

Here's the complete context:

	/* reset requires max 10 us delay */
	for (cnt = 30; cnt > 0; --cnt) {	/* ... allow extra time */
		if ((readl(base + OHCI_CMDSTATUS) & OHCI_HCR) == 0)
			break;
		udelay(1);
	}

I think Calim means that the "(readl(base + OHCI_CMDSTATUS) & OHCI_HCR)  
== 0" test succeeds on the first pass through the loop, so we break out
early and the udelay(1) statement never gets executed.

Alan Stern

Re: PROBLEM: OHCI HCD - computer freezes during boot

[Greg KH]

On Thu, Apr 26, 2012 at 11:16:17AM -0400, Alan Stern wrote:
> On Thu, 26 Apr 2012, Greg KH wrote:
> 
> > On Thu, Apr 26, 2012 at 10:25:41AM -0400, Alan Stern wrote:
> > > On Thu, 26 Apr 2012, Calin Demian wrote:
> > > 
> > > > I don't know how, but adding the following line in function
> > > > quirk_usb_handoff_ohci makes the system work fine:
> > > > 
> > > > 	/* reset requires max 10 us delay */
> > > > +	udelay(1);
> > > > 	for (cnt = 30; cnt > 0; --cnt) {	/* ... allow extra time */
> > > > 		if ((readl(base + OHCI_CMDSTATUS) & OHCI_HCR) == 0)
> > > > 
> > > > I observed thad the condition in the for loop is allways true, so the
> > > > delay inside the loop is never executed.
> > 
> > That implies that something is wrong with the complier here, and it
> > optimized out the loop?  Are you sure that really happened?
> 
> Here's the complete context:
> 
> 	/* reset requires max 10 us delay */
> 	for (cnt = 30; cnt > 0; --cnt) {	/* ... allow extra time */
> 		if ((readl(base + OHCI_CMDSTATUS) & OHCI_HCR) == 0)
> 			break;
> 		udelay(1);
> 	}
> 
> I think Calim means that the "(readl(base + OHCI_CMDSTATUS) & OHCI_HCR)  
> == 0" test succeeds on the first pass through the loop, so we break out
> early and the udelay(1) statement never gets executed.

Ok, but if the readl() succeeds, then all should be fine?

Ah, unless the hardware is really lying, but no, that would never
happen, right?

Nevermind,

greg k-h

Re: PROBLEM: OHCI HCD - computer freezes during boot

[Calin Demian]

I admit it might be a hardware problem. As I said in another mail, I
couldn't duplicate the problem on other computers...
If that's true than I'm sorry for bothering you.

2012/4/26 Greg KH <greg@kroah.com>:
> On Thu, Apr 26, 2012 at 11:16:17AM -0400, Alan Stern wrote:
>> On Thu, 26 Apr 2012, Greg KH wrote:
>>
>> > On Thu, Apr 26, 2012 at 10:25:41AM -0400, Alan Stern wrote:
>> > > On Thu, 26 Apr 2012, Calin Demian wrote:
>> > >
>> > > > I don't know how, but adding the following line in function
>> > > > quirk_usb_handoff_ohci makes the system work fine:
>> > > >
>> > > >         /* reset requires max 10 us delay */
>> > > > +       udelay(1);
>> > > >         for (cnt = 30; cnt > 0; --cnt) {        /* ... allow extra time */
>> > > >                 if ((readl(base + OHCI_CMDSTATUS) & OHCI_HCR) == 0)
>> > > >
>> > > > I observed thad the condition in the for loop is allways true, so the
>> > > > delay inside the loop is never executed.
>> >
>> > That implies that something is wrong with the complier here, and it
>> > optimized out the loop?  Are you sure that really happened?
>>
>> Here's the complete context:
>>
>>       /* reset requires max 10 us delay */
>>       for (cnt = 30; cnt > 0; --cnt) {        /* ... allow extra time */
>>               if ((readl(base + OHCI_CMDSTATUS) & OHCI_HCR) == 0)
>>                       break;
>>               udelay(1);
>>       }
>>
>> I think Calim means that the "(readl(base + OHCI_CMDSTATUS) & OHCI_HCR)
>> == 0" test succeeds on the first pass through the loop, so we break out
>> early and the udelay(1) statement never gets executed.
>
> Ok, but if the readl() succeeds, then all should be fine?
>
> Ah, unless the hardware is really lying, but no, that would never
> happen, right?
>
> Nevermind,
>
> greg k-h

Re: PROBLEM: OHCI HCD - computer freezes during boot

[Calin Demian]

2012/4/26 Alan Stern <stern@rowland.harvard.edu>:
> On Thu, 26 Apr 2012, Greg KH wrote:
>
>> On Thu, Apr 26, 2012 at 10:25:41AM -0400, Alan Stern wrote:
>> > On Thu, 26 Apr 2012, Calin Demian wrote:
>> >
>> > > I don't know how, but adding the following line in function
>> > > quirk_usb_handoff_ohci makes the system work fine:
>> > >
>> > >   /* reset requires max 10 us delay */
>> > > + udelay(1);
>> > >   for (cnt = 30; cnt > 0; --cnt) {        /* ... allow extra time */
>> > >           if ((readl(base + OHCI_CMDSTATUS) & OHCI_HCR) == 0)
>> > >
>> > > I observed thad the condition in the for loop is allways true, so the
>> > > delay inside the loop is never executed.
>>
>> That implies that something is wrong with the complier here, and it
>> optimized out the loop?  Are you sure that really happened?
>
> Here's the complete context:
>
>        /* reset requires max 10 us delay */
>        for (cnt = 30; cnt > 0; --cnt) {        /* ... allow extra time */
>                if ((readl(base + OHCI_CMDSTATUS) & OHCI_HCR) == 0)
>                        break;
>                udelay(1);
>        }
>
> I think Calim means that the "(readl(base + OHCI_CMDSTATUS) & OHCI_HCR)
> == 0" test succeeds on the first pass through the loop, so we break out
> early and the udelay(1) statement never gets executed.
>
> Alan Stern
>

Yes, that's what I was saying. Storing the readl result in a variable
and displaying it later shows that the (readl_result & OHCI_HCR) is 0
at first pass, but that doesn't imply reset is finished, I think. It
would be too fast. Maybe the readl doesn't work for some reason...

Re: PROBLEM: OHCI HCD - computer freezes during boot

[Calin Demian]

Yes, it's ok. Thank you.
Nevertheless, I think I will try to find out exactly what's happening.

2012/4/26 Alan Stern <stern@rowland.harvard.edu>:
> On Thu, 26 Apr 2012, Calin Demian wrote:
>
>> I don't know how, but adding the following line in function
>> quirk_usb_handoff_ohci makes the system work fine:
>>
>>       /* reset requires max 10 us delay */
>> +     udelay(1);
>>       for (cnt = 30; cnt > 0; --cnt) {        /* ... allow extra time */
>>               if ((readl(base + OHCI_CMDSTATUS) & OHCI_HCR) == 0)
>>
>> I observed thad the condition in the for loop is allways true, so the
>> delay inside the loop is never executed.
>> With the unmodified source, the execution doesn't stop at this point
>> but at the next readl (I tried inserting printk and readl instructions
>> after the writel which restores the fminterval and the execution
>> stopped before exiting quirk_usb_handoff_ohci).
>> I don't know how it relates to the ACPI message... (see bug 43073 in
>> bugzilla.kernel.org).
>
> I don't know just what the problem is either, but there's nothing wrong
> with delaying startup by 1 us.  In fact, all we have to do is reorder
> the statements within the loop.  Is this patch okay for you?
>
> Alan Stern
>
>
>
> Index: usb-3.4/drivers/usb/host/pci-quirks.c
> ===================================================================
> --- usb-3.4.orig/drivers/usb/host/pci-quirks.c
> +++ usb-3.4/drivers/usb/host/pci-quirks.c
> @@ -520,9 +520,10 @@ static void __devinit quirk_usb_handoff_
>
>        /* reset requires max 10 us delay */
>        for (cnt = 30; cnt > 0; --cnt) {        /* ... allow extra time */
> +               /* Some controllers enable HCR too soon, so always delay 1 us */
> +               udelay(1);
>                if ((readl(base + OHCI_CMDSTATUS) & OHCI_HCR) == 0)
>                        break;
> -               udelay(1);
>        }
>        writel(fminterval, base + OHCI_FMINTERVAL);
>
>

Re: PROBLEM: OHCI HCD - computer freezes during boot

[Alan Stern]

On Thu, 26 Apr 2012, Calin Demian wrote:

> Yes, it's ok. Thank you.
> Nevertheless, I think I will try to find out exactly what's happening.

Okay.  It may be that your hardware never turns on the HCR bit in the 
first place.

Remember, there will be no problem merging that patch, if it helps your
system.

Alan Stern

Re: PROBLEM: OHCI HCD - computer freezes during boot

[Calin Demian]

Ok, then. In my case it solves the problem.
Thank you again.

Calin Demian

2012/4/26 Alan Stern <stern@rowland.harvard.edu>:
> On Thu, 26 Apr 2012, Calin Demian wrote:
>
>> Yes, it's ok. Thank you.
>> Nevertheless, I think I will try to find out exactly what's happening.
>
> Okay.  It may be that your hardware never turns on the HCR bit in the
> first place.
>
> Remember, there will be no problem merging that patch, if it helps your
> system.
>
> Alan Stern
>

Re: PROBLEM: OHCI HCD - computer freezes during boot

[Calin Demian]

I have some interesting news. I tested the latest source (available
via git) with the requested commandline arguments. I attached the
results to bug 43073 in bugzilla.kernel.org: an image of frozen boot
attempt and the dmesg of a successfull boot (same source).

2012/4/23 Bjorn Helgaas <bhelgaas@google.com>:
> On Wed, Apr 11, 2012 at 1:38 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>> On Wed, 11 Apr 2012, Calin Demian wrote:
>>
>>> Hi!
>>> Yes, in fact I did allready follow the execution, and it looks like this:
>>> function                                file
>>> pci_apply_final_quirks           /drivers/pci/quirks.c
>>> pci_fixup_device                    ~
>>> pci_do_fixups                        ~
>>> here, for the ohci busses 2 functions are called:
>>>   nv_msi_ht_cap_quirk_all       /drivers/usb/host/pci-quirks.c
>>
>> What is that?  It's not present in my copy of the kernel source.
>>
>>>   quirk_usb_early_handoff        ~
>>> quirk_usb_early_handoff calls the following 3 functions:
>>>   pci_enable_device(pdev)         /drivers/pci/pci.c
>>>   quirk_usb_handoff_ohci(pdev)    /drivers/usb/host/pci-quirks.c
>>>   pci_disable_device(pdev)
>>>
>>> The execution stops inside pci_disable_device, but because
>>> quirk_usb_handoff_ohci is the only function that has changed between
>>> versions 3.0.13 and 3.0.20 from the list of files mentioned above, it
>>> seems that this function changed behaviour in a way that my computer
>>> doesn't like.
>>
>> That cannot be right.  The call to pci_disable_device was added after
>> the change to quirk_usb_handoff_ohci.
>>
>>>   Further trace:
>>>   pci_disable_device
>>>     do_pci_disable_device
>>>       pci_read_config_word
>>
>> I have no idea why your computer would crash inside or after
>> pci_read_config_word.
>>
>> Anyway, this is a PCI problem, not a USB problem.  Maybe the PCI
>> experts can help.  I have CC'ed the linux-pci mailing list.
>>
>> Alan Stern
>>
>>> with respect,
>>> Calin Demian
>>>
>>>
>>> 2012/4/11 Alan Stern <stern@rowland.harvard.edu>:
>>> > On Wed, 11 Apr 2012, Calin Demian wrote:
>>> >
>>> >> 1.Boot problem: computer stops responding during boot.
>>> >>
>>> >> 2.The symptom doesn't occur allways, but when it does, it is at the
>>> >> same point during the boot process. The last messages displayed differ
>>> >> between different kernel versions, but are the same each time.
>>> >>   I would appreciate if you could take a look at function
>>> >> "quirk_usb_handoff_ohci" in file /drivers/usb/host/pci-quirks.c -
>>> >> which was modified in version 3.0.17 of the mainline kernel. The
>>> >> problem appeared when upgrading Ubuntu from mainline kernel version
>>> >> 3.0.13 to version 3.0.20. Searching the changelogs I found that this
>>> >> function was modified between the two releases. The  computer freezes
>>> >> durin applying the quirks (pci_apply_final_quirks) for bus
>>> >> 0000:00:13.1 (the 2nd OHCI bus). Controller is ALI  (EHCI 8 ports +
>>> >> OHCI 3x3 ports), dev_id 5237(OHCI).
>
> It sounds like this is a regression between 3.0.13 and 3.0.20.  Can
> you please open a bug report here:
>
> https://bugzilla.kernel.org/enter_bug.cgi?product=Drivers&component=PCI
>
> and attach dmesg or serial console logs with "debug ignore_loglevel
> initcall_debug" for both kernels?  For 3.0.20 you probably can't get a
> dmesg log because of the hang, so a digital photo would be fine, too.
>
> Thanks,
>  Bjorn