linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Calin Demian <c.demian20@gmail.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	USB list <linux-usb@vger.kernel.org>,
	linux-pci@vger.kernel.org
Subject: Re: PROBLEM: OHCI HCD - computer freezes during boot
Date: Thu, 26 Apr 2012 01:26:55 +0300	[thread overview]
Message-ID: <CAD52pS815u61dfPnTJuGPED+Rvspn4CyHfzLZFVd5u2uy_afeg@mail.gmail.com> (raw)
In-Reply-To: <CAErSpo46AzF9aifaMyDbCe2dXwfdvE68mgWwiUrxnzoTyKJktg@mail.gmail.com>

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

      parent reply	other threads:[~2012-04-25 22:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAD52pS-CJBSz3EhFf4Mt3=o8=-3soa-b=XjDjdra=BP=M-4RLw@mail.gmail.com>
2012-04-11 19:38 ` PROBLEM: OHCI HCD - computer freezes during boot Alan Stern
2012-04-23 16:36   ` Bjorn Helgaas
2012-04-25 13:00     ` Calin Demian
2012-04-25 15:22       ` Alan Stern
2012-04-25 22:59         ` Calin Demian
2012-04-26 14:25           ` Alan Stern
2012-04-26 14:43             ` Greg KH
2012-04-26 15:16               ` Alan Stern
2012-04-26 15:25                 ` Greg KH
2012-04-26 15:53                   ` Calin Demian
2012-04-26 15:49                 ` Calin Demian
2012-04-26 15:59             ` Calin Demian
2012-04-26 17:05               ` Alan Stern
2012-04-26 17:50                 ` Calin Demian
2012-04-25 22:26     ` Calin Demian [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAD52pS815u61dfPnTJuGPED+Rvspn4CyHfzLZFVd5u2uy_afeg@mail.gmail.com \
    --to=c.demian20@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).