Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 15 11月, 2005 6 次提交
    • S
      [PATCH] x86-64/i386: Intel HT, Multi core detection fixes · 94605eff
      由 Siddha, Suresh B 提交于 
      Fields obtained through cpuid vector 0x1(ebx[16:23]) and
vector 0x4(eax[14:25], eax[26:31]) indicate the maximum values and might not
always be the same as what is available and what OS sees.  So make sure
"siblings" and "cpu cores" values in /proc/cpuinfo reflect the values as seen
by OS instead of what cpuid instruction says. This will also fix the buggy BIOS
cases (for example where cpuid on a single core cpu says there are "2" siblings,
even when HT is disabled in the BIOS.
http://bugzilla.kernel.org/show_bug.cgi?id=4359)
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      94605eff
    • A
      [PATCH] x86_64: Speed up numa_node_id by putting it directly into the PDA · 69d81fcd
      由 Andi Kleen 提交于 
      Not go from the CPU number to an mapping array.
Mode number is often used now in fast paths.

This also adds a generic numa_node_id to all the topology includes

Suggested by Eric Dumazet
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      69d81fcd
    • A
      [PATCH] x86_64: Remove obsolete ARCH_HAS_ATOMIC_UNSIGNED and page_flags_t · 07808b74
      由 Andi Kleen 提交于 
      Has been introduced for x86-64 at some point to save memory
in struct page, but has been obsolete for some time. Just
remove it.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      07808b74
    • A
      [PATCH] x86_64: Add 4GB DMA32 zone · a2f1b424
      由 Andi Kleen 提交于 
      Add a new 4GB GFP_DMA32 zone between the GFP_DMA and GFP_NORMAL zones.

As a bit of historical background: when the x86-64 port
was originally designed we had some discussion if we should
use a 16MB DMA zone like i386 or a 4GB DMA zone like IA64 or
both. Both was ruled out at this point because it was in early
2.4 when VM is still quite shakey and had bad troubles even
dealing with one DMA zone.  We settled on the 16MB DMA zone mainly
because we worried about older soundcards and the floppy.

But this has always caused problems since then because
device drivers had trouble getting enough DMA able memory. These days
the VM works much better and the wide use of NUMA has proven
it can deal with many zones successfully.

So this patch adds both zones.

This helps drivers who need a lot of memory below 4GB because
their hardware is not accessing more (graphic drivers - proprietary
and free ones, video frame buffer drivers, sound drivers etc.).
Previously they could only use IOMMU+16MB GFP_DMA, which
was not enough memory.

Another common problem is that hardware who has full memory
addressing for >4GB misses it for some control structures in memory
(like transmit rings or other metadata).  They tended to allocate memory
in the 16MB GFP_DMA or the IOMMU/swiotlb then using pci_alloc_consistent,
but that can tie up a lot of precious 16MB GFPDMA/IOMMU/swiotlb memory
(even on AMD systems the IOMMU tends to be quite small) especially if you have
many devices.  With the new zone pci_alloc_consistent can just put
this stuff into memory below 4GB which works better.

One argument was still if the zone should be 4GB or 2GB. The main
motivation for 2GB would be an unnamed not so unpopular hardware
raid controller (mostly found in older machines from a particular four letter
company) who has a strange 2GB restriction in firmware. But
that one works ok with swiotlb/IOMMU anyways, so it doesn't really
need GFP_DMA32. I chose 4GB to be compatible with IA64 and because
it seems to be the most common restriction.

The new zone is so far added only for x86-64.

For other architectures who don't set up this
new zone nothing changes. Architectures can set a compatibility
define in Kconfig CONFIG_DMA_IS_DMA32 that will define GFP_DMA32
as GFP_DMA. Otherwise it's a nop because on 32bit architectures
it's normally not needed because GFP_NORMAL (=0) is DMA able
enough.

One problem is still that GFP_DMA means different things on different
architectures. e.g. some drivers used to have #ifdef ia64  use GFP_DMA
(trusting it to be 4GB) #elif __x86_64__ (use other hacks like
the swiotlb because 16MB is not enough) ... . This was quite
ugly and is now obsolete.

These should be now converted to use GFP_DMA32 unconditionally. I haven't done
this yet. Or best only use pci_alloc_consistent/dma_alloc_coherent
which will use GFP_DMA32 transparently.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a2f1b424
    • H
      [NETFILTER] nfnetlink: unconditionally require CAP_NET_ADMIN · 37d2e7a2
      由 Harald Welte 提交于 
      This patch unconditionally requires CAP_NET_ADMIN for all nfnetlink
messages.  It also removes the per-message cap_required field, since all
existing subsystems use CAP_NET_ADMIN for all their messages anyway.

Patrick McHardy owes me a beer if we ever need to re-introduce this.
Signed-off-by: NHarald Welte <laforge@netfilter.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      37d2e7a2
    • P
      [NETFILTER] nfnetlink: skip size check if size not specified (== 0) · c0400c4f
      由 Pablo Neira Ayuso 提交于 
      Skip sizecheck if the size of the attribute wasn't specified, ie. zero.
Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: NHarald Welte <laforge@netfilter.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c0400c4f
  3. 14 11月, 2005 19 次提交
  5. 13 11月, 2005 3 次提交
    • R
      [ARM] 3160/1: SharpSL: Add driver for Akita specific GPIOs · bd5d080a
      由 Richard Purdie 提交于 
      Patch from Richard Purdie

Add a driver for the extra GPIOs found on the Sharp SL-C1000 (Akita).
These GPIOs are found on a Maxim MAX7310 I2C i/o expander chip. A
generic GPIO driver for the MAX7310 was attempted but this mini
driver is a much simpler and much more effective solution avoiding
several issues and complexity the generic driver had (as discussed
on LKML).

The platform device is required so the device parent can be set
correctly which ensures the device is one of the last to suspend
and first to resume. Whilst the i2c suspend/resume calls can be
influenced, nothing guarantees this is easlier/later than the
subsystems the gpios are used on which are all independent of i2c
(sound, irda, video/backlight etc.).
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      bd5d080a
    • C
      [SPARC]: Fix RTC compat ioctl kernel log spam. · 535f8d65
      由 Christoph Hellwig 提交于 
      On Fri, Nov 11, 2005 at 12:58:40PM -0800, David S. Miller wrote:
> 
> This change:
> 
> diff-tree 8ca2bdc7 (from feee207e44d3643d19e648aAuthor: Christoph Hellwig <hch@lst.de>
> Date:   Wed Nov 9 12:07:18 2005 -0800
> 
>     [SPARC] sbus rtc: implement ->compat_ioctl
>     
>     Signed-off-by: Christoph Hellwig <hch@lst.de>
>     Signed-off-by: David S. Miller <davem@davemloft.net>
> 
> results in the console now getting spewed on sparc64 systems
> with messages like:
> 
> [   11.968298] ioctl32(hwclock:464): Unknown cmd fd(3) cmd(401c7014){00} arg(efc
> What's happening is hwclock tries first the SBUS rtc device ioctls
> then the normal rtc driver ones.
> 
> So things actually worked better when we had the SBUS rtc compat ioctl
> directly handled via the generic compat ioctl code.
> 
> There are _so_ many rtc drivers in the kernel implementing the
> generic rtc ioctls that I don't think putting a ->compat_ioctl
> into all of them to fix this problem is feasible.  Unless we
> write a single rtc_compat_ioctl(), export it to modules, and hook
> it into all of those somehow.
> 
> But even that doesn't appear to have any pretty implementation.
> 
> Any better ideas?

We had similar problems with other ioctls where userspace did things
like that.  What we did there was to put the compat handler to generic
code.  The patch below does that, adding a big comment about what's
going on and removing the COMPAT_IOCTL entires for these on powerpc
that not only weren't ever useful but are duplicated now aswell.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      535f8d65
    • L
      Revert "[PATCH] fbcon: Add rl (Roman Large) font" · 0fde7f59
      由 Linus Torvalds 提交于 
      This reverts 998e6d51 commit.
      0fde7f59
  7. 12 11月, 2005 3 次提交
  9. 11 11月, 2005 9 次提交