1. 12 9月, 2009 1 次提交
    • R
      ARM: Fix pfn_valid() for sparse memory · b7cfda9f
      Russell King 提交于
      On OMAP platforms, some people want to declare to segment up the memory
      between the kernel and a separate application such that there is a hole
      in the middle of the memory as far as Linux is concerned.  However,
      they want to be able to mmap() the hole.
      
      This currently causes problems, because update_mmu_cache() thinks that
      there are valid struct pages for the "hole".  Fix this by making
      pfn_valid() slightly more expensive, by checking whether the PFN is
      contained within the meminfo array.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Tested-by: NKhasim Syed Mohammed <khasim@ti.com>
      b7cfda9f
  2. 07 9月, 2009 2 次提交
  3. 05 9月, 2009 1 次提交
    • N
      ARM: 5691/1: fix cache aliasing issues between kmap() and kmap_atomic() with highmem · 7929eb9c
      Nicolas Pitre 提交于
      Let's suppose a highmem page is kmap'd with kmap().  A pkmap entry is
      used, the page mapped to it, and the virtual cache is dirtied.  Then
      kunmap() is used which does virtually nothing except for decrementing a
      usage count.
      
      Then, let's suppose the _same_ page gets mapped using kmap_atomic().
      It is therefore mapped onto a fixmap entry instead, which has a
      different virtual address unaware of the dirty cache data for that page
      sitting in the pkmap mapping.
      
      Fortunately it is easy to know if a pkmap mapping still exists for that
      page and use it directly with kmap_atomic(), thanks to kmap_high_get().
      
      And actual testing with a printk in the added code path shows that this
      condition is actually met *extremely* frequently.  Seems that we've been
      quite lucky that things have worked so well with highmem so far.
      
      Cc: stable@kernel.org
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7929eb9c
  4. 02 9月, 2009 1 次提交
    • N
      ARM: 5687/1: fix an oops with highmem · 13f96d8f
      Nicolas Pitre 提交于
      In xdr_partial_copy_from_skb() there is that sequence:
      
      		kaddr = kmap_atomic(*ppage, KM_SKB_SUNRPC_DATA);
      		[...]
      		flush_dcache_page(*ppage);
      		kunmap_atomic(kaddr, KM_SKB_SUNRPC_DATA);
      
      Mixing flush_dcache_page() and kmap_atomic() is a bit odd,
      especially since kunmap_atomic() must deal with cache issues
      already.  OTOH the non-highmem case must use flush_dcache_page()
      as kunmap_atomic() becomes a no op with no cache maintenance.
      
      Problem is that with highmem the implementation of kmap_atomic()
      doesn't set page->virtual, and page_address(page) returns 0 in
      that case. Here flush_dcache_page() calls __flush_dcache_page()
      which calls __cpuc_flush_dcache_page(page_address(page)) resulting
      in a kernel oops.
      
      None of the kmap_atomic() implementations uses set_page_address().
      Hence we can assume page_address() is always expected to return 0 in
      that case. Let's conditionally call __cpuc_flush_dcache_page() only
      when the page address is non zero, and perform that test only when
      highmem is configured.
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      13f96d8f
  5. 24 8月, 2009 2 次提交
  6. 15 8月, 2009 2 次提交
    • L
      ARM: 5673/1: U300 fix initsection compile warning · a2bb9f4d
      Linus Walleij 提交于
      The u300_init_check_chip() function was not properly tagged with
      the __init macro and provided a initsection mismatch on
      compilation.
      Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a2bb9f4d
    • R
      ARM: Fix broken highmem support · dde5828f
      Russell King 提交于
      Currently, highmem is selectable, and you can request an increased
      vmalloc area.  However, none of this has any effect on the memory
      layout since a patch in the highmem series was accidentally dropped.
      Moreover, even if you did want highmem, all memory would still be
      registered as lowmem, possibly resulting in overflow of the available
      virtual mapping space.
      
      The highmem boundary is determined by the highest allowed beginning
      of the vmalloc area, which depends on its configurable minimum size
      (see commit 60296c71 for details on
      this).
      
      We should create mappings and initialize bootmem only for low memory,
      while the zone allocator must still be told about highmem.
      
      Currently, memory nodes which are completely located in high memory
      are not supported.  This is not a huge limitation since systems
      relying on highmem support are unlikely to have discontiguous memory
      with large holes.
      
      [ A similar patch was meant to be merged before commit 5f0fbf9e
        and be available  in Linux v2.6.30, however some git rebase screw-up
        of mine dropped the first commit of the series, and that goofage
        escaped testing somehow as well. -- Nico ]
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Reviewed-by: NNicolas Pitre <nico@marvell.com>
      dde5828f
  7. 14 8月, 2009 2 次提交
  8. 12 8月, 2009 1 次提交
    • M
      IXP4xx: Fix IO_SPACE_LIMIT for 2.6.31-rc core PCI changes · dee2b904
      Mikael Pettersson 提交于
      2.6.31-rc kernels don't boot on my ixp4xx box (ds101), because the libata
      driver doesn't find the PCI IDE controller any more. 2.6.30 was fine.
      I traced this to a PCI update (1f82de10)
      in 2.6.30-git19. Diffing the kernel boot logs from 2.6.30-git18 and
      2.6.30-git19 illustrates the breakage:
      
      > --- dmesg-2.6.30-git18	2009-08-04 01:45:22.000000000 +0200
      > +++ dmesg-2.6.30-git19	2009-08-04 01:45:46.000000000 +0200
      > @@ -26,6 +26,13 @@
      >  pci 0000:00:02.2: PME# supported from D0 D1 D2 D3hot
      >  pci 0000:00:02.2: PME# disabled
      >  PCI: bus0: Fast back to back transfers disabled
      > +pci 0000:00:01.0: BAR 0: can't allocate I/O resource [0x10000-0xffff]
      > +pci 0000:00:01.0: BAR 1: can't allocate I/O resource [0x10000-0xffff]
      > +pci 0000:00:01.0: BAR 2: can't allocate I/O resource [0x10000-0xffff]
      > +pci 0000:00:01.0: BAR 3: can't allocate I/O resource [0x10000-0xffff]
      > +pci 0000:00:01.0: BAR 4: can't allocate I/O resource [0x10000-0xffff]
      > +pci 0000:00:02.0: BAR 4: can't allocate I/O resource [0x10000-0xffff]
      > +pci 0000:00:02.1: BAR 4: can't allocate I/O resource [0x10000-0xffff]
      >  bio: create slab <bio-0> at 0
      >  SCSI subsystem initialized
      >  NET: Registered protocol family 2
      > @@ -44,11 +51,7 @@
      >  console [ttyS0] enabled
      >  serial8250.0: ttyS1 at MMIO 0xc8001000 (irq = 13) is a XScale
      >  Driver 'sd' needs updating - please use bus_type methods
      > -PCI: enabling device 0000:00:01.0 (0140 -> 0141)
      > -scsi0 : pata_artop
      > -scsi1 : pata_artop
      > -ata1: PATA max UDMA/100 cmd 0x1050 ctl 0x1060 bmdma 0x1040 irq 28
      > -ata2: PATA max UDMA/100 cmd 0x1058 ctl 0x1064 bmdma 0x1048 irq 28
      > +pata_artop 0000:00:01.0: no available native port
      >  Using configured DiskOnChip probe address 0x50000000
      >  DiskOnChip found at 0x50000000
      >  NAND device: Manufacturer ID: 0x98, Chip ID: 0x73 (Toshiba NAND 16MiB 3,3V 8-bit)
      
      The specific change in 1f82de10 responsible
      for this failure turned out to be the following:
      
      > --- a/drivers/pci/probe.c
      > +++ b/drivers/pci/probe.c
      > @@ -193,7 +193,7 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
      >  		res->flags |= pci_calc_resource_flags(l) | IORESOURCE_SIZEALIGN;
      >  		if (type == pci_bar_io) {
      >  			l &= PCI_BASE_ADDRESS_IO_MASK;
      > -			mask = PCI_BASE_ADDRESS_IO_MASK & 0xffff;
      > +			mask = PCI_BASE_ADDRESS_IO_MASK & IO_SPACE_LIMIT;
      >  		} else {
      >  			l &= PCI_BASE_ADDRESS_MEM_MASK;
      >  			mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
      
      Every arch except arm's ixp4xx defines IO_SPACE_LIMIT as an all-bits-one
      bitmask, typically -1UL but sometimes only a 16-bit 0x0000ffff. But ixp4xx
      defines it as 0xffff0000, which is now causing the PCI failures.
      
      Russell King noted that ixp4xx has 64KB PCI IO space, so IO_SPACE_LIMIT
      should be 0x0000ffff. This patch makes that change, which fixes the PCI
      failures on my ixp4xx box.
      Signed-off-by: NMikael Pettersson <mikpe@it.uu.se>
      Signed-off-by: NKrzysztof Hałasa <khc@pm.waw.pl>
      dee2b904
  9. 10 8月, 2009 7 次提交
  10. 08 8月, 2009 1 次提交
  11. 06 8月, 2009 17 次提交
  12. 05 8月, 2009 1 次提交
  13. 31 7月, 2009 2 次提交