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

From: Norbert Kiesel (nkiesel_at_tbdnetworks.com)
Date: 09/13/05

  • Next message: iSteve: "Re: query_modules syscall gone? Any replacement?"
    Date:	Tue, 13 Sep 2005 09:27:14 -0700
    To: Linus Torvalds <torvalds@osdl.org>
    
    

    Hi,

    I'll apply the patch right away and will report back.

    Best,
      Norbert

    On Tue, Sep 13, 2005 at 07:25:11AM -0700, Linus Torvalds wrote:
    >
    >
    > On Mon, 12 Sep 2005, Norbert Kiesel wrote:
    > >
    > > diff is appended. Regarding the -rc3 and friends, currently I can't as
    > > I jumped directly from 12.5 to 13. This is my desktop at work, so I
    > > try to keep it somewhat stable. However, if you have a guess which
    > > versions to try, I can give it a spin. It takes some time though to
    > > test, as the lockup normally only happens after 1 hour or so (although
    > > I could propably speed this up by doing lots of disk IO).
    >
    > No need. The numbers made it clear: this is the same bug that hit the
    > hpt366 driver:
    >
    > 0000:00:10.0 RAID bus controller: Silicon Image, Inc. SiI 0649
    > Ultra ATA/100 PCI to ATA Host Controller (rev 01)
    > ...
    > 00: 95 10 49 06 07 00 90 02 01 00 04 01 00 40 00 00
    > 10: 01 b8 00 00 01 bc 00 00 01 c0 00 00 01 c4 00 00
    > 20: 01 c8 00 00 00 00 00 00 00 00 00 00 95 10 49 06
    > -30: 00 00 00 00 60 00 00 00 00 00 00 00 0c 01 02 04
    > +30: 01 00 00 00 60 00 00 00 00 00 00 00 0c 01 02 04
    >
    > and the exact same cause too.
    >
    > I wonder who the _hell_ has been sprinkling these _byte_ writes to the ROM
    > enable logic around?
    >
    > I bet this will fix it..
    >
    > Linus
    > ---
    > diff --git a/drivers/ide/pci/cmd64x.c b/drivers/ide/pci/cmd64x.c
    > --- a/drivers/ide/pci/cmd64x.c
    > +++ b/drivers/ide/pci/cmd64x.c
    > @@ -608,7 +608,7 @@ static unsigned int __devinit init_chips
    >
    > #ifdef __i386__
    > if (dev->resource[PCI_ROM_RESOURCE].start) {
    > - pci_write_config_byte(dev, PCI_ROM_ADDRESS, dev->resource[PCI_ROM_RESOURCE].start | PCI_ROM_ADDRESS_ENABLE);
    > + pci_write_config_dword(dev, PCI_ROM_ADDRESS, dev->resource[PCI_ROM_RESOURCE].start | PCI_ROM_ADDRESS_ENABLE);
    > printk(KERN_INFO "%s: ROM enabled at 0x%08lx\n", name, dev->resource[PCI_ROM_RESOURCE].start);
    > }
    > #endif
    >
    -
    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: iSteve: "Re: query_modules syscall gone? Any replacement?"

    Relevant Pages

    • Re: Linux-2.6.13-rc7
      ... > report in first, to verify if this patch works as advertised. ... m68k (and applies both to Linus' tree and m68k CVS); ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: RT patch acceptance
      ... >> responsiveness at all. ... > report a smoother desktop experience. ... run with RT patch or not or think they are running with patch when they ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: smp/swsusp done right
      ... >> Test this if you can, and report any problems. ... No, not in final patch. ... People were complaining that M$ turns users into beta-testers... ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [ACPI] If your ACPI-enabled machine does clean shutdown randomly...
      ... > It seems that acpi likes to report completely bogus value from time to ... The problem with that patch is that it is filling the logs, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.14-git4 suspend fails: kernel NULL pointer dereference
      ... >problem there, you are not using ACPI, right? ... i'òll try the patch and report asap. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)