Re: 2.6.13.1 locks machine after some time, 2.6.12.5 work fine

From: Linus Torvalds (torvalds_at_osdl.org)
Date: 09/13/05

  • Next message: James Bottomley: "Re: [2.6.14-rc1] sym scsi boot hang" 
    Date:	Tue, 13 Sep 2005 10:23:40 -0700 (PDT)
To: Norbert Kiesel <nkiesel@tbdnetworks.com>

    On Tue, 13 Sep 2005, Norbert Kiesel wrote:
    >
    > Ok, I applied the patch and I'm running it right now, so far so good.
    > Here is the the output of lspci from the patched 2.6.13.1 (not sure if a
    > diff to the unpatched 2.6.13.1 or the 2.6.12.5 would be more useful, so
    > I settled for no diff :-).

    Yes, now it looks better, except for a lspci quirk. You have:

    > 0000:00:10.0 RAID bus controller: Silicon Image, Inc. SiI 0649
    > Ultra ATA/100 PCI to ATA Host Controller (rev 01)

    and lspci reports:

    > Expansion ROM at 40000000 [disabled] [size=512K]

    where the "disabled" comes from the fact that it looks at the sysfs data
    structures, and the resource is indeed marked as disabled there (because
    nothing enabled it explicitly).

    But then reading the HW registers, we see:

    > 30: 01 00 00 40 60 00 00 00 00 00 00 00 0c 01 02 04

    Ie now the ROM address value is 0x40000001, which means that as far as the
    _hardware_ is concerned, the ROM is actually enabled.

    That's because the cmd64x driver enabled the ROM by just writing the
    enable bit directly, and never actually told the resource layer that it
    had done so. Not a big deal - we've properly allocated the resource
    region, so there's no overlap, there's just this strange disconnect
    between what the hardware thinks and what the resource handling things.

    Anyway, it all looks reasonable. Of course, exactly like with the hpt
    driver, there doesn't seem to be any real _reason_ to enable the ROM in
    the first place, and that code is #ifdef __i386__ anyway (so if there
    _was_ a reason, it wouldn't work on anything else than an x86), so I
    suspect we should just remove the ROM enable entirely.

    But it really shouldn't matter - at least we now enable the ROM
    _correctly_, and I'm pretty sure (and certainly sincerely hope ;) that
    your lockup is gone.

                            Linus
    -
    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/

  • Next message: James Bottomley: "Re: [2.6.14-rc1] sym scsi boot hang"

    Relevant Pages

    • Re: [PATCH] add PCI ROMs to sysfs
      ... Shouldn't we do this only if we find that the device has a ROM resource? ... scan all resources for the COPY flag instead? ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.13.1 locks machine after some time, 2.6.12.5 work fine
      ... >> Ok, I applied the patch and I'm running it right now, so far so good. ... and the resource is indeed marked as disabled there (because ... > Ie now the ROM address value is 0x40000001, which means that as far as the ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Ignore disabled ROM resources at setup
      ... > Ignore disabled ROM resources at setup ... It may be a card-related issue, but we may also be writing ... > code defaulted to not doing any resource allocations at all for ROM ...
      (Linux-Kernel)
    • Re: [PATCH] add PCI ROMs to sysfs
      ... If you follow the code path of pci_assign_resourceit will program ... If you can read the ROM without a resource assigned it is just luck ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] add PCI ROMs to sysfs
      ... The static resource was from an old version that I ... There's not much sense to the ROM accessing code ... Do you Yahoo!? ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)