Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 06 6月, 2006 30 次提交
  3. 05 6月, 2006 1 次提交
    • D
      [SPARC64]: Fix missing fold at end of checksums. · ae5de0ff
      由 David S. Miller 提交于 
      Both csum_partial() and the csum_partial_copy*() family of routines
forget to do a final fold on the computed checksum value on sparc64.
So do the standard Sparc "add + set condition codes, add carry"
sequence, then make sure the high 32-bits of the return value are
clear.

Based upon some excellent detective work and debugging done by
Richard Braun and Samuel Thibault.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ae5de0ff
  5. 04 6月, 2006 1 次提交
    • L
      Merge master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6 · 672c6108
      由 Linus Torvalds 提交于 
      * master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6:
  [SCSI] scsi_lib.c: properly count the number of pages in scsi_req_map_sg()
  [SCSI] scsi_transport_sas: make write attrs writeable
  [SCSI] scsi_transport_sas; fix user_scan
  [SCSI] ppa: fix for machines with highmem
  [SCSI] mptspi: reset handler shouldn't be called for other bus protocols
  [SCSI] Blacklist entry for HP dat changer
      672c6108
  7. 03 6月, 2006 8 次提交
    • S
      [TCP] tcp_highspeed: Fix problem observed by Xiaoliang (David) Wei · fb80a6e1
      由 Stephen Hemminger 提交于 
      When snd_cwnd is smaller than 38 and the connection is in
congestion avoidance phase (snd_cwnd > snd_ssthresh), the snd_cwnd
seems to stop growing.

The additive increase was confused because C array's are 0 based.
Signed-off-by: NStephen Hemminger <shemminger@osdl.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fb80a6e1
    • L
      Merge master.kernel.org:/home/rmk/linux-2.6-serial · 0f326215
      由 Linus Torvalds 提交于 
      * master.kernel.org:/home/rmk/linux-2.6-serial:
  [SERIAL] Update parity handling documentation
      0f326215
    • L
      Merge master.kernel.org:/home/rmk/linux-2.6-arm · 891eca14
      由 Linus Torvalds 提交于 
      * master.kernel.org:/home/rmk/linux-2.6-arm:
  [ARM] 3540/1: ixp23xx: deal with gap in interrupt bitmasks
  [ARM] 3539/1: ixp23xx: fix __arch_ixp23xx_is_coherent() for A1 stepping
      891eca14
    • L
      Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6 · 48e49ead
      由 Linus Torvalds 提交于 
      * master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
  [SPARC64]: Fix D-cache corruption in mremap
  [SPARC64]: Make smp_processor_id() functional before start_kernel()
      48e49ead
    • L
      [ARM] 3540/1: ixp23xx: deal with gap in interrupt bitmasks · ec8510f6
      由 Lennert Buytenhek 提交于 
      Patch from Lennert Buytenhek

On the ixp23xx, the microengine thread interrupt sources are numbered
56..119, but their mask/status bits are located in bit positions 64..127
in the various registers in the interrupt controller (bit positions
56..63 are unused.)

We don't deal with this, so currently, when asked to enable IRQ 64, we
will enable IRQ 56 instead.

The only interrupts >= 64 are the thread interrupt sources, and there
are no in-tree users of those yet, so this is fortunately not a big
problem, but this needs fixing anyway.
Signed-off-by: NLennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ec8510f6
    • L
      [ARM] 3539/1: ixp23xx: fix __arch_ixp23xx_is_coherent() for A1 stepping · a77bc691
      由 Lennert Buytenhek 提交于 
      Patch from Lennert Buytenhek

The current __ixp23xx_arch_is_coherent() check assumes that the
lower byte of IXP23XX_PRODUCT_ID is identical to the lower byte of
processor_id, but this is not the case, and because of this we were
incorrectly enabling coherency on A1 stepping CPUs.

Stepping A1 of the ixp2350, which has a PRODUCT_ID of 0x401, has '02'
in the lower byte of processor_id, while A2, with a PRODUCT_ID of
0x402, has '04' in the lower byte of processor_id.

So, to check for >= A2, we really need to check the lower byte of
processor_id against >= 4.
Signed-off-by: NLennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a77bc691
    • I
      [PATCH] slab.c: fix offslab_limit bug · b1ab41c4
      由 Ingo Molnar 提交于 
      mm/slab.c's offlab_limit logic is totally broken.

Firstly, "offslab_limit" is a global variable while it should either be
calculated in situ or should be passed in as a parameter.

Secondly, the more serious problem with it is that the condition for
calculating it:

               if (!(OFF_SLAB(sizes->cs_cachep))) {
                       offslab_limit = sizes->cs_size - sizeof(struct slab);
                       offslab_limit /= sizeof(kmem_bufctl_t);

is in total disconnect with the condition that makes use of it:

               /* More than offslab_limit objects will cause problems */
               if ((flags & CFLGS_OFF_SLAB) && num > offslab_limit)
                       break;

but due to offslab_limit being a global variable this breakage was
hidden.

Up until lockdep came along and perturbed the slab sizes sufficiently so
that the first off-slab cache would still see a (non-calculated) zero
value for offslab_limit and would panic with:

  kmem_cache_create: couldn't create cache size-512.

  Call Trace:
   [<ffffffff8020a5b9>] show_trace+0x96/0x1c8
   [<ffffffff8020a8f0>] dump_stack+0x13/0x15
   [<ffffffff8022994f>] panic+0x39/0x21a
   [<ffffffff80270814>] kmem_cache_create+0x5a0/0x5d0
   [<ffffffff80aced62>] kmem_cache_init+0x193/0x379
   [<ffffffff80abf779>] start_kernel+0x17f/0x218
   [<ffffffff80abf263>] _sinittext+0x263/0x26a

  Kernel panic - not syncing: kmem_cache_create(): failed to create slab `size-512'

Paolo Ornati's config on x86_64 managed to trigger it.

The fix is to move the calculation to the place that makes use of it.
This also makes slab.o 54 bytes smaller.

Btw., the check itself is quite silly. Its intention is to test whether
the number of objects per slab would be higher than the number of slab
control pointers possible. In theory it could be triggered: if someone
tried to allocate 4-byte objects cache and explicitly requested with
CFLGS_OFF_SLAB. So i kept the check.

Out of historic interest i checked how old this bug was and it's
ancient, 10 years old! It is the oldest hidden and then truly triggering
bugs i ever saw being fixed in the kernel!
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b1ab41c4
    • P
      [SERIAL] Update parity handling documentation · 89f3da3e
      由 Peter Korsgaard 提交于 
      Update documentation to match reality. INPCK controls whether input
parity checking is enabled.
Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      89f3da3e