13 Oct, 2005

9 commits


12 Oct, 2005

14 commits

  • Linus Torvalds
     
  • We were not doing alignment properly when remapping the kernel image.

    What we want is a 4MB aligned physical address to map at KERNBASE.
    Mistakedly we were 4MB aligning the virtual address where the kernel
    initially sits, that's wrong.

    Instead, we should PAGE align the virtual address, then 4MB align the
    physical address result the prom gives to us.

    Signed-off-by: David S. Miller

    David S. Miller
     
  • Refuse to install a page into a mapping if the mapping count is already
    ridiculously large.

    You probably cannot trigger this on 32-bit architectures, but on a
    64-bit setup we should protect against it.

    Signed-off-by: Hugh Dickins
    Signed-off-by: Linus Torvalds

    Hugh Dickins
     
  • Newer gcc's are generating this relocation, so the module loader needs to
    handle it.

    Signed-off-by: Peter Bergner
    Signed-off-by: Anton Blanchard
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Peter Bergner
     
  • * bttv-cards.c:
    - Enable S-Video input on DViCO FusionHDTV5 Lite

    Signed-off-by: Michael Krufky
    Signed-off-by: Mauro Carvalho Chehab
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael Krufky
     
  • This patch prevents illegal traps from causing m32r kernel's infinite loop
    execution.

    Signed-off-by: Naoto Sugai
    Signed-off-by: Hirokazu Takata
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hirokazu Takata
     
  • Nir Tzachar points out that if an ELF file specifies a
    zero-length bss at a whacky address, we cannot load that binary because
    padzero() tries to zero out the end of the page at the whacky address, and
    that may not be writeable.

    See also http://bugzilla.kernel.org/show_bug.cgi?id=5411

    So teach load_elf_binary() to skip the bss settng altogether if the elf file
    has a zero-length bss segment.

    Cc: Roland McGrath
    Cc: Daniel Jacobowitz
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    akpm@osdl.org
     
  • I've noticed that the calculations for seg_size and nr_segs in
    __dma_sync_page_highmem() (arch/ppc/kernel/dma-mapping.c) are wrong. The
    incorrect calculations can result in either an oops or a panic when running
    fsck depending on the size of the partition.

    The problem with the seg_size calculation is that it can result in a
    negative number if size is offset > size. The problem with the nr_segs
    caculation is returns the wrong number of segments, e.g. it returns 1 when
    size is 200 and offset is 4095, when it should return 2 or more.

    Acked-by: Benjamin Herrenschmidt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paolo Galtieri
     
  • Revert this recent correctness change: Douglas Crosher
    reported that it broke an existing application, and that madvise() works
    without error on anonymous mappings on Solaris.

    This means that madvise() will remain non-standards-compliant: we should
    return -EBADF for all requests against non-file-backed vma's, but Linux only
    does this for MADV_WILLNEED requests.

    Signed-off-by: Suzuki K P
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Suzuki
     
  • Here is a compatibility fix between Linux and Solaris when used with VxFS
    filesystems: Solaris usually accepts acl entries in any order, but with
    VxFS it replies with NFSERR_INVAL when it sees a four-entry acl that is not
    in canonical form. It may also fail with other non-canonical acls -- I
    can't tell, because that case never triggers: We only send non-canonical
    acls when we fake up an ACL_MASK entry.

    Instead of adding fake ACL_MASK entries at the end, inserting them in the
    correct position makes Solaris+VxFS happy. The Linux client and server
    sides don't care about entry order. The three-entry-acl special case in
    which we need a fake ACL_MASK entry was handled in xdr_nfsace_encode. The
    patch moves this into nfsacl_encode.

    Signed-off-by: Andreas Gruenbacher
    Acked-by: Trond Myklebust
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andreas Gruenbacher
     
  • v9fs_file_read and v9fs_file_write use kmalloc to allocate buffers as big
    as the data buffer received as parameter. kmalloc cannot be used to
    allocate buffers bigger than 128K, so reading/writing data in chunks bigger
    than 128k fails.

    This patch reorganizes v9fs_file_read and v9fs_file_write to allocate only
    buffers as big as the maximum data that can be sent in one 9P message.

    Signed-off-by: Latchesar Ionkov
    Cc: Eric Van Hensbergen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Latchesar Ionkov
     
  • In the current dell_rbu code ver 2.0 the packet update mechanism makes the
    user app dump every individual packet in to the driver.

    This adds in efficiency as every packet update makes the
    /sys/class/firmware/dell_rbu/loading and data files to disappear and reappear
    again. Thus the user app needs to wait for the files to reappear to dump
    another packet. This slows down the packet update tremendously in case of
    large number of packets. I am submitting a new patch for dell_rbu which will
    change the way we do packet updates;

    In the new method the user app will create a new single file which has already
    packetized the rbu image and all the packets are now staged in this file.

    This driver also creates a new entry in
    /sys/devices/platform/dell_rbu/packet_size ; the user needs to echo the packet
    size here before downloading the packet file.

    The user should do the following:

    create one single file which has all the packets stacked together.
    echo the packet size in to /sys/devices/platform/dell_rbu/packet_size.
    echo 1 > /sys/class/firmware/dell_rbu/loading
    cat the packetfile > /sys/class/firmware/dell_rbu/data
    echo 0 > /sys/class/firmware/dell_rbu/loading

    The driver takes the file which came through /sys/class/firmware/dell_rbu/data
    and takes chunks of paket_size data from it and place in contiguous memory.

    This makes packet update process very efficient and fast. As all the packet
    update happens in one single operation. The user can still read back the
    downloaded file from /sys/devices/platform/dell_rbu/data.

    Signed-off-by: Abhay Salunke
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Abhay Salunke
     
  • pSeries_irq_bus_setup is marked __devinit but references s7a_workaround
    which is marked __initdata.

    Depending on who got the memory for s7a_workaround (and if the value was
    now positive), it was possible for PCI hotplugged devices to have 3
    subtracted from their interrupt number. This would happen randomly and
    caused me much confusion :)

    Signed-off-by: Anton Blanchard
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Anton Blanchard
     
  • Search for a disconnect ccw_device on the ccw bus rather than on the css
    bus (was a typo in patch I did for the klist conversion). A cast to an
    embedding ccw_device from an embedded device in a struct subchannel will
    lead us to oopses.

    Signed-off-by: Cornelia Huck
    Signed-off-by: Martin Schwidefsky
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Cornelia Huck
     

11 Oct, 2005

17 commits