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: Luben Tuikov: "Re: [PATCH 2.6.13 2/14] sas-class: README" 
    Date:	Tue, 13 Sep 2005 07:25:11 -0700 (PDT)
To: Norbert Kiesel <nkiesel@tbdnetworks.com>

    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: Luben Tuikov: "Re: [PATCH 2.6.13 2/14] sas-class: README"

    Relevant Pages

    • Re: 2.6.13.1 locks machine after some time, 2.6.12.5 work fine
      ... diff is appended. ... Regarding the -rc3 and friends, ... > relevant info from the diff, and you don't even need to show the two ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH 2.6.9-rc2-mm1 0/2] mm: memory policy for page cache allocation
      ... Patches done with the 'diff -p' option are slightly easier to ... Could you explain the for loop in alloc_page_roundrobin? ... pseudo-uniform distribution, without any need for the additional rr_next ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: ACPI S3 and ieee1394 dont get along
      ... It was the only thing even remotely relevant I found on the mailinglists tho. ... Here's what the diff gives: ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.4-mm1
      ... > NUMA performance would have some results by now but all seems to be silent. ... remove unused load and remove some warnings (due to type checking in ... diff -puN kernel/sched.c~sched-morefixes kernel/sched.c ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: swsusp bigdiff [was Re: [PATCH] Software Suspend split to two stage V2.]
      ... >> BTW here's my curent bigdiff. ... > Really big diff, I'll trying. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)