lkml.org 
[lkml]   [2007]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: PROBLEM: kernel hang in ohci init
    Date
    On Thursday 12 July 2007, Satyam Sharma wrote:
    >
    > > [2.] The version 2.6.22 of the linux kernel hangs when initializing the
    > > integrated ohci controller of the nvidia MCP51 chipset (pci device ids
    > > vendor:product == 10de:26d). I have traced through various printks that
    > > pci_init calls pci_fixup_device, later on in quirk_usb_ohci_handoff
    > > (file linux/drivers/usb/host/pci-quirks.c) kernel freezes in this
    > > section:

    Note that hangs in that file almost always mean "your BIOS is goofy".
    Hunt for BIOS settings related to USB, and change them. As a rule, if
    you tell your BIOS to ignore USB devices (mostly keyboards and disks),
    it will have even less of an excuse to break like that.


    > > ...
    > > if (control & OHCI_CTRL_IR) {
    > > int wait_time = 500;
    > > writel(OHCI_INTR_OC, base + OHCI_INTRENABLE);
    > > writel(OHCI_ORC, base + OHCI_CMDSTATUS); // this never returns
    > > ...
    > > after this, kernel apparently goes into busy waiting (fans gradually
    > > turn louder) and hangs indefinitely. I have also made sure that writel
    > > (in linux/include/asm/io.h) really is entered, but never returns.

    Does the current kernel.org GIT tree do the same thing? A bunch
    of USB patches were recently merged, including ISTR one in that
    area ...


    > > I can only guess that it might
    > > have to do with the patch
    > > "commit 4302a595cd9c6363b495460497ecbda49fa16858
    > > Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    > > Date: Fri Dec 15 06:53:55 2006 +1100
    > > USB: Rework the OHCI quirk mecanism as suggested by David
    > > "
    > > but I don't really have a clue, so this might be groundless suspicion.

    Should be unrelated. That patch related to how vendor-specific
    implementation differences get detected and handled ... basically
    just switching to a table-driven approach that can even handle
    board-specific wiring braindamage, rather than the original scheme
    which was just a big if/then/else looking only at chip vendors.

    - Dave
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-07-13 05:49    [W:0.021 / U:31.316 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site