11 May, 2006

3 commits


09 May, 2006

9 commits

  • Taking the cpu hotplug semaphore in a normal events workqueue
    is unsafe because other tasks can wait for any workqueues with
    it hold. This results in a deadlock.

    Move the DBS timer into its own work queue which is not
    affected by other work queue flushes to avoid this.

    Has been acked by Venkatesh.

    Cc: venkatesh.pallipadi@intel.com
    Cc: cpufreq@lists.linux.org.uk
    Signed-off-by: Andi Kleen
    Signed-off-by: Linus Torvalds

    Andi Kleen
     
  • Based on analysis&patch from Robert Hentosch

    Observed on a Dell PE6850 with 16GB

    The problem occurs very early on, when the kernel allocates space for the
    temporary memory map called bootmap. The bootmap overlaps the EBDA region.
    EBDA region is not historically reserved in the e820 mapping. When the
    bootmap is freed it marks the EBDA region as usable.

    If you notice in setup.c there is already code to work around the EBDA
    in reserve_ebda_region(), this check however occurs after the bootmap
    is allocated and doesn't prevent the bootmap from using this range.

    AK: I redid the original patch. Thanks also to Jan Beulich for
    spotting some mistakes.

    Cc: Robert_Hentosch@dell.com
    Cc: jbeulich@novell.com
    Signed-off-by: Andi Kleen
    Signed-off-by: Linus Torvalds

    Andi Kleen
     
  • Playing with NMI watchdog on x86_64, I discovered that it didn't
    do what I expected. It always panic-ed, even when it didn't
    happen from interrupt context. This patch solves that
    problem for me. Also, in this case, do_exit() will be called
    with interrupts disabled, I believe. Would it be wise to also
    call local_irq_enable() after nmi_exit()?
    [Yes I added it -AK]

    Currently, on x86_64, any NMI watchdog timeout will cause a panic
    because the irq count will always be set to be in an interrupt
    when do_exit() is called from die_nmi(). If we add nmi_exit() to
    the die_nmi() call (since the nmi will never exit "normally")
    it seems to solve this problem. The following small program
    can be used to trigger the NMI watchdog to reproduce this:
    main ()
    {
    iopl(3);
    for (;;) asm("cli");
    }

    Signed-off-by: Andi Kleen
    Signed-off-by: Linus Torvalds

    Corey Minyard
     
  • I noticed this when poking around in this area.

    The oops_begin() function in x86_64 would only conditionally claim
    the die_lock if the call is nested, but oops_end() would always
    release the spinlock. This patch adds a nest count for the die lock
    so that the release of the lock is only done on the final oops_end().

    Signed-off-by: Corey Minyard
    Signed-off-by: Andi Kleen
    Signed-off-by: Linus Torvalds

    Corey Minyard
     
  • The IOMMU code can only deal with 8 northbridges. Error out when
    more are found.

    Signed-off-by: Andi Kleen
    Signed-off-by: Linus Torvalds

    Andi Kleen
     
  • The patch addresses a problem with ACPI SCI interrupt entry, which gets
    re-used, and the IRQ is assigned to another unrelated device. The patch
    corrects the code such that SCI IRQ is skipped and duplicate entry is
    avoided. Second issue came up with VIA chipset, the problem was caused by
    original patch assigning IRQs starting 16 and up. The VIA chipset uses
    4-bit IRQ register for internal interrupt routing, and therefore cannot
    handle IRQ numbers assigned to its devices. The patch corrects this
    problem by allowing PCI IRQs below 16.

    Cc: len.brown@intel.com

    Signed-off by: Natalie Protasevich
    Signed-off-by: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kimball Murray
     
  • * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6:
    [IA64] remove asm-ia64/bitops.h self-inclusion
    [IA64] strcpy returns NULL pointer and not destination pointer

    Linus Torvalds
     
  • * master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
    [IRDA] irda-usb: use NULL instead of 0
    [IPV4]: Remove likely in ip_rcv_finish()
    [NET]: Create netdev attribute_groups with class_device_add
    [CLASS DEVICE]: add attribute_group creation

    Linus Torvalds
     
  • * git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild:
    kbuild: Do not overwrite makefile as anohter user
    kbuild: drivers/video/logo/ - fix ident glitch
    kbuild: fix gen_initramfs_list.sh
    kbuild modpost - relax driver data name
    kbuild: removing .tmp_versions considered harmful
    kbuild: fix modpost segfault for 64bit mipsel kernel

    Linus Torvalds
     

08 May, 2006

10 commits


07 May, 2006

4 commits

  • Use NULL instead of 0 for a null pointer value (sparse warning):

    drivers/net/irda/irda-usb.c:1781:30: warning: Using plain integer as NULL pointer

    Also, correct timeout argument to use milliseconds instead of jiffies.

    Signed-off-by: Randy Dunlap
    Signed-off-by: David S. Miller

    Randy Dunlap
     
  • This is another result from my likely profiling tool
    (dwalker@mvista.com just sent the patch of the profiling tool to
    linux-kernel mailing list, which is similar to what I use).

    On my system (not very busy, normal development machine within a
    VMWare workstation), I see a 6/5 miss/hit ratio for this "likely".

    Signed-off-by: Hua Zhong
    Signed-off-by: David S. Miller

    Hua Zhong
     
  • Atomically create attributes when class device is added. This avoids
    the race between registering class_device (which generates hotplug
    event), and the creation of attribute groups.

    Signed-off-by: Stephen Hemminger
    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: David S. Miller

    Stephen Hemminger
     
  • Extend the support of attribute groups in class_device's to allow
    groups to be created as part of the registration process. This allows
    network device's to avoid race between registration and creating
    groups.

    Note that unlike attributes that are a property of the class object,
    the groups are a property of the class_device object. This is done
    because there are different types of network devices (wireless for
    example).

    Signed-off-by: Stephen Hemminger
    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: David S. Miller

    Stephen Hemminger
     

06 May, 2006

14 commits

  • Fix:
    drivers/rtc/rtc-sa1100.c: In function `sa1100_rtc_proc':
    drivers/rtc/rtc-sa1100.c:298: warning: unsigned int format, long unsigned int arg (arg 3)

    and arrange for sa1100_rtc_open() to pass the devid to free_irq()
    rather than NULL.

    Signed-off-by: Russell King

    Russell King
     
  • The SA1100 RTC alarm can be configured to wake up the CPU
    from sleep mode, and the RTC driver has been using the
    API to configure this mode. Unfortunately, the code was
    which sets the required bit in the hardware was missing.

    Signed-off-by: Russell King

    Russell King
     
  • Xiaoliang (David) Wei wrote:
    > Hi gurus,
    >
    > I am reading the code of tcp_highspeed.c in the kernel and have a
    > question on the hstcp_cong_avoid function, specifically the following
    > AI part (line 136~143 in net/ipv4/tcp_highspeed.c ):
    >
    > /* Do additive increase */
    > if (tp->snd_cwnd < tp->snd_cwnd_clamp) {
    > tp->snd_cwnd_cnt += ca->ai;
    > if (tp->snd_cwnd_cnt >= tp->snd_cwnd) {
    > tp->snd_cwnd++;
    > tp->snd_cwnd_cnt -= tp->snd_cwnd;
    > }
    > }
    >
    > In this part, when (tp->snd_cwnd_cnt == tp->snd_cwnd),
    > snd_cwnd_cnt will be -1... snd_cwnd_cnt is defined as u16, will this
    > small chance of getting -1 becomes a problem?
    > Shall we change it by reversing the order of the cwnd++ and cwnd_cnt -=
    > cwnd?

    Absolutely correct. Thanks.

    Signed-off-by: John Heffner
    Signed-off-by: David S. Miller

    John Heffner
     
  • There are out of date and don't tell the user anything useful.
    The similar messages which IPV4 and the core networking used
    to output were killed a long time ago.

    Signed-off-by: Ralf Baechle
    Signed-off-by: David S. Miller

    Ralf Baechle
     
  • Calling sock_orphan inside bh_lock_sock in dccp_close can lead to dead
    locks. For example, the inet_diag code holds sk_callback_lock without
    disabling BH. If an inbound packet arrives during that admittedly tiny
    window, it will cause a dead lock on bh_lock_sock. Another possible
    path would be through sock_wfree if the network device driver frees the
    tx skb in process context with BH enabled.

    We can fix this by moving sock_orphan out of bh_lock_sock.

    The tricky bit is to work out when we need to destroy the socket
    ourselves and when it has already been destroyed by someone else.

    By moving sock_orphan before the release_sock we can solve this
    problem. This is because as long as we own the socket lock its
    state cannot change.

    So we simply record the socket state before the release_sock
    and then check the state again after we regain the socket lock.
    If the socket state has transitioned to DCCP_CLOSED in the time being,
    we know that the socket has been destroyed. Otherwise the socket is
    still ours to keep.

    This problem was discoverd by Ingo Molnar using his lock validator.

    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     
  • It makes sense to add this simple statistic to keep track of received
    multicast packets.

    Signed-off-by: Stephen Hemminger
    Signed-off-by: David S. Miller

    Stephen Hemminger
     
  • Discard an unexpected chunk in CLOSED state rather can calling BUG().

    Signed-off-by: Sridhar Samudrala
    Signed-off-by: David S. Miller

    Sridhar Samudrala
     
  • Use pskb_pull() to handle incoming COOKIE_ECHO and HEARTBEAT chunks that
    are received as skb's with fragment list.

    Signed-off-by: Sridhar Samudrala
    Signed-off-by: David S. Miller

    Sridhar Samudrala
     
  • There is a rare situation that causes lksctp to go into infinite recursion
    and crash the system. The trigger is a packet that contains at least the
    first two DATA fragments of a message bundled together. The recursion is
    triggered when the user data buffer is smaller that the full data message.
    The problem is that we clone the skb for every fragment in the message.
    When reassembling the full message, we try to link skbs from the "first
    fragment" clone using the frag_list. However, since the frag_list is shared
    between two clones in this rare situation, we end up setting the frag_list
    pointer of the second fragment to point to itself. This causes
    sctp_skb_pull() to potentially recurse indefinitely.

    Proposed solution is to make a copy of the skb when attempting to link
    things using frag_list.

    Signed-off-by: Vladislav Yasevich
    Signed-off-by: Sridhar Samudrala
    Signed-off-by: David S. Miller

    Vladislav Yasevich
     
  • This patch fixes a deadlock situation in the receive path by allowing
    temporary spillover of the receive buffer.

    - If the chunk we receive has a tsn that immediately follows the ctsn,
    accept it even if we run out of receive buffer space and renege data with
    higher TSNs.
    - Once we accept one chunk in a packet, accept all the remaining chunks
    even if we run out of receive buffer space.

    Signed-off-by: Neil Horman
    Acked-by: Mark Butler
    Acked-by: Vlad Yasevich
    Signed-off-by: Sridhar Samudrala
    Signed-off-by: David S. Miller

    Neil Horman
     
  • * master.kernel.org:/home/rmk/linux-2.6-mmc:
    [BLOCK] Fix oops on removal of SD/MMC card

    Linus Torvalds
     
  • Patch from Nicolas Pitre

    ... but only for user space.

    Signed-off-by: Nicolas Pitre
    Signed-off-by: Russell King

    Nicolas Pitre
     
  • Patch from Nicolas Pitre

    Intel PXA27x developers manual section 5.4.1.1 lists a priority
    distribution for the DMA channels differently than what the code
    currently assumes. This patch fixes that.

    Noticed by Simon Vogl

    Signed-off-by: Nicolas Pitre
    Signed-off-by: Russell King

    Nicolas Pitre
     
  • Patch from George G. Davis

    The ARM VFP FPSCR register is corrupted when a condition flags modifying
    VFP instruction is followed by a non-condition flags modifying VFP
    instruction and both instructions raise exceptions. The fix is to
    read the current FPSCR in between emulation of these two instructions
    and use the current FPSCR value when handling the second exception.

    Signed-off-by: George G. Davis
    Signed-off-by: Russell King

    George G. Davis