1. 26 Dec, 2006 36 commits
  2. 24 Dec, 2006 2 commits
  3. 23 Dec, 2006 2 commits
    • OGAWA Hirofumi's avatar
      [PATCH] arch/i386/pci/mmconfig.c tlb flush fix · 8d1c4819
      OGAWA Hirofumi authored
      We use the fixmap for accessing pci config space in pci_mmcfg_read/write().
      The problem is in pci_exp_set_dev_base(). It is caching a last
      accessed address to avoid calling set_fixmap_nocache() whenever
      pci_mmcfg_read/write() is used.
      
        static inline void pci_exp_set_dev_base(int bus, int devfn)
        {
      	u32 dev_base = base | (bus << 20) | (devfn << 12);
      	if (dev_base != mmcfg_last_accessed_device) {
      		mmcfg_last_accessed_device = dev_base;
      		set_fixmap_nocache(FIX_PCIE_MCFG, dev_base);
      	}
        }
      
                  cpu0                                        cpu1
        ---------------------------------------------------------------------------
          pci_mmcfg_read("device-A")
              pci_exp_set_dev_base()
                  set_fixmap_nocache()
                                                    pci_mmcfg_read("device-B")
                                                        pci_exp_set_dev_base()
                                                            set_fixmap_nocache()
          pci_mmcfg_read("device-B")
              pci_exp_set_dev_base()
                  /* doesn't flush tlb */
      
      But if cpus accessed the above order, the second pci_mmcfg_read() on
      cpu0 doesn't flush the TLB, because "mmcfg_last_accessed_device" is
      device-B.  So, second pci_mmcfg_read() on cpu0 accesses a device-A via
      a previous TLB cache. This problem became the cause of several strange
      behavior.
      
      This patches fixes this situation by adds "mmcfg_last_accessed_cpu" check.
      
      [ Alternatively, we could make a per-cpu mapping area or something. Not
        that it's probably worth it, but if we wanted to avoid all locking and
        instead just disable preemption, that would be the way to go. --Linus ]
      Signed-off-by: default avatarOGAWA Hirofumi <hogawa@miraclelinux.com>
      Signed-off-by: default avatarOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      8d1c4819
    • Ingo Molnar's avatar
      [PATCH] suspend: fix suspend on single-CPU systems · e1d9fd2e
      Ingo Molnar authored
      Clark Williams reported that suspend doesnt work on his laptop on
      2.6.20-rc1-rt kernels. The bug was introduced by the following cleanup
      commit:
      
       commit 112cecb2
       Author: Siddha, Suresh B <suresh.b.siddha@intel.com>
       Date:   Wed Dec 6 20:34:31 2006 -0800
      
          [PATCH] suspend: don't change cpus_allowed for task initiating the suspend
      
      because with this change 'error' is not initialized to 0 anymore, if
      there are no other online CPUs. (i.e. if the system is single-CPU).
      
      the fix is the initialize it to 0. The really weird thing is that my
      version of gcc does not warn about this non-initialized variable
      situation ...
      
      (also fix the kernel printk in the error branch, it was missing a
       newline)
      Reported-by: default avatarClark Williams <williams@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      e1d9fd2e