Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 3 年多

通知 13
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 28 10月, 2005 3 次提交
  3. 25 10月, 2005 2 次提交
    • J
      [SERIAL] new hp diva console port · 551f8f0e
      由 Justin Chen 提交于 
      Add the new ID 0x132a and configure the new PCI Diva console port.  This
device supports only 1 single console UART.
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      551f8f0e
    • B
      [SERIAL] support the Exsys EX-4055 4S four-port card · add7b58e
      由 Bjorn Helgaas 提交于 
      Tested by Wolfgang Denk with this device:

    00:0f.0 Network controller: PLX Technology, Inc. PCI <-> IOBus Bridge (rev 01)
        Subsystem: Exsys EX-4055 4S(16C550) RS-232
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin A routed to IRQ 10
        Region 0: Memory at 80100000 (32-bit, non-prefetchable) [size=128]
        Region 1: I/O ports at 7080 [size=128]
        Region 2: I/O ports at 7400 [size=32]

    00:0f.0 Class 0280: 10b5:9050 (rev 01)
        Subsystem: d84d:4055

Results with this patch:

    Serial: 8250/16550 driver $Revision: 1.90 $ 32 ports, IRQ sharing enabled
    ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
    PCI: Found IRQ 10 for device 0000:00:0f.0
    ttyS4 at I/O 0x7400 (irq = 10) is a 16550A
    ttyS5 at I/O 0x7408 (irq = 10) is a 16550A
    ttyS6 at I/O 0x7410 (irq = 10) is a 16550A
    ttyS7 at I/O 0x7418 (irq = 10) is a 16550A
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      add7b58e
  5. 24 10月, 2005 1 次提交
    • A
      [PATCH] inotify/idr leak fix · 8d3b3591
      由 Andrew Morton 提交于 
      Fix a bug which was reported and diagnosed by
Stefan Jones <stefan.jones@churchillrandoms.co.uk>

IDR trees include a cache of idr_layer objects.  There's no way to destroy
this cache, so when we discard an overall idr tree we end up leaking some
memory.

Add and use idr_destroy() for this.  v9fs and infiniband also need to use
idr_destroy() to avoid leaks.

Or, we make the cache global, like radix_tree_preload().  Which is probably
better.  Later.

Cc: Eric Van Hensbergen <ericvh@ericvh.myip.org>
Cc: Roland Dreier <rolandd@cisco.com>
Cc: Robert Love <rml@novell.com>
Cc: John McCutchan <ttb@tentacle.dhs.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8d3b3591
  7. 21 10月, 2005 1 次提交
  9. 20 10月, 2005 2 次提交
    • Y
      [PATCH] swiotlb: make sure initial DMA allocations really are in DMA memory · 281dd25c
      由 Yasunori Goto 提交于 
      This introduces a limit parameter to the core bootmem allocator; The new
parameter indicates that physical memory allocated by the bootmem
allocator should be within the requested limit.

We also introduce alloc_bootmem_low_pages_limit, alloc_bootmem_node_limit,
alloc_bootmem_low_pages_node_limit apis, but alloc_bootmem_low_pages_limit
is the only api used for swiotlb.

The existing alloc_bootmem_low_pages() api could instead have been
changed and made to pass right limit to the core allocator.  But that
would make the patch more intrusive for 2.6.14, as other arches use
alloc_bootmem_low_pages().  We may be done that post 2.6.14 as a
cleanup.

With this, swiotlb gets memory within 4G for both x86_64 and ia64
arches.
Signed-off-by: NYasunori Goto <y-goto@jp.fujitsu.com>
Cc: Ravikiran G Thirumalai <kiran@scalex86.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      281dd25c
    • S
      [PATCH] Handle spurious page fault for hugetlb region · 3359b54c
      由 Seth, Rohit 提交于 
      The hugetlb pages are currently pre-faulted.  At the time of mmap of
hugepages, we populate the new PTEs.  It is possible that HW has already
cached some of the unused PTEs internally.  These stale entries never
get a chance to be purged in existing control flow.

This patch extends the check in page fault code for hugepages.  Check if
a faulted address falls with in size for the hugetlb file backing it.
We return VM_FAULT_MINOR for these cases (assuming that the arch
specific page-faulting code purges the stale entry for the archs that
need it).
Signed-off-by: NRohit Seth <rohit.seth@intel.com>

[ This is apparently arguably an ia64 port bug. But the code won't
  hurt, and for now it fixes a real problem on some ia64 machines ]
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3359b54c
  11. 19 10月, 2005 14 次提交
  13. 18 10月, 2005 2 次提交
  15. 17 10月, 2005 1 次提交
    • H
      [PATCH] list: add missing rcu_dereference on first element · b24d18aa
      由 Herbert Xu 提交于 
      It seems that all the list_*_rcu primitives are missing a memory barrier
on the very first dereference.  For example,

#define list_for_each_rcu(pos, head) \
	for (pos = (head)->next; prefetch(pos->next), pos != (head); \
		pos = rcu_dereference(pos->next))

It will go something like:

	pos = (head)->next

	prefetch(pos->next)

	pos != (head)

	do stuff

We're missing a barrier here.

	pos = rcu_dereference(pos->next)

		fetch pos->next

		barrier given by rcu_dereference(pos->next)

		store pos

Without the missing barrier, the pos->next value may turn out to be stale.
In fact, if "do stuff" were also dereferencing pos and relying on
list_for_each_rcu to provide the barrier then it may also break.

So here is a patch to make sure that we have a barrier for the first
element in the list.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Acked-by: N"Paul E. McKenney" <paulmck@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b24d18aa
  17. 16 10月, 2005 1 次提交
    • A
      [PATCH]: highest_possible_processor_id() has to be a macro · 688ce17b
      由 Al Viro 提交于 
      	... otherwise, things like alpha and sparc64 break and break
badly.  They define cpu_possible_map to something else in smp.h
*AFTER* having included cpumask.h.

	If that puppy is a macro, expansion will happen at the actual
caller, when we'd already seen #define cpu_possible_map ... and we will
get the right thing used.

	As an inline helper it will be tokenized before we get to that
define and that's it; no matter what we define later, it won't affect
anything.  We get modules with dependency on cpu_possible_map instead
of the right symbol (phys_cpu_present_map in case of sparc64), or outright
link errors if they are built-in.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      688ce17b
  19. 15 10月, 2005 1 次提交
  21. 14 10月, 2005 1 次提交
  23. 13 10月, 2005 1 次提交
  25. 11 10月, 2005 7 次提交
  27. 10 10月, 2005 1 次提交
    • R
      [PATCH] x86_64: Set up safe page tables during resume · 3dd08325
      由 Rafael J. Wysocki 提交于 
      The following patch makes swsusp avoid the possible temporary corruption
of page translation tables during resume on x86-64.  This is achieved by
creating a copy of the relevant page tables that will not be modified by
swsusp and can be safely used by it on resume.

The problem is that during resume on x86-64 swsusp may temporarily
corrupt the page tables used for the direct mapping of RAM.  If that
happens, a page fault occurs and cannot be handled properly, which leads
to the solid hang of the affected system.  This leads to the loss of the
system's state from before suspend and may result in the loss of data or
the corruption of filesystems, so it is a serious issue.  Also, it
appears to happen quite often (for me, as often as 50% of the time).

The problem is related to the fact that (at least) one of the PMD
entries used in the direct memory mapping (starting at PAGE_OFFSET)
points to a page table the physical address of which is much greater
than the physical address of the PMD entry itself.  Moreover,
unfortunately, the physical address of the page table before suspend
(i.e.  the one stored in the suspend image) happens to be different to
the physical address of the corresponding page table used during resume
(i.e.  the one that is valid right before swsusp_arch_resume() in
arch/x86_64/kernel/suspend_asm.S is executed).  Thus while the image is
restored, the "offending" PMD entry gets overwritten, so it does not
point to the right physical address any more (i.e.  there's no page
table at the address pointed to by it, because it points to the address
the page table has been at during suspend).  Consequently, if the PMD
entry is used later on, and it _is_ used in the process of copying the
image pages, a page fault occurs, but it cannot be handled in the normal
way and the system hangs.

In principle we can call create_resume_mapping() from
swsusp_arch_resume() (ie.  from suspend_asm.S), but then the memory
allocations in create_resume_mapping(), resume_pud_mapping(), and
resume_pmd_mapping() must be made carefully so that we use _only_
NosaveFree pages in them (the other pages are overwritten by the loop in
swsusp_arch_resume()).  Additionally, we are in atomic context at that
time, so we cannot use GFP_KERNEL.  Moreover, if one of the allocations
fails, we should free all of the allocated pages, so we need to trace
them somehow.

All of this is done in the appended patch, except that the functions
populating the page tables are located in arch/x86_64/kernel/suspend.c
rather than in init.c.  It may be done in a more elegan way in the
future, with the help of some swsusp patches that are in the works now.

[AK: move some externs into headers, renamed a function]
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3dd08325
  29. 09 10月, 2005 2 次提交