1. 17 11月, 2006 6 次提交
    • O
      [PATCH] set default video mode on PowerBook Wallstreet · 3b46f039
      Olaf Hering 提交于
      Finally add the third PowerBook Wallstreet 233MHz model to the list of
      known display resolutions.
      
      Without this change, a 640x480 video mode is used.  A workaround so far was
      to boot with 'video=atyfb:vmode:14'
      Signed-off-by: NOlaf Hering <olaf@aepfle.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Cc: Solomon Peachy <pizza@shaftnet.org>
      Cc: James Simmons <jsimmons@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3b46f039
    • M
      [PATCH] eCryptfs: dput() lower d_parent on rename · a9083081
      Michael Halcrow 提交于
      On rename, for both the old and new lower dentry objects, eCryptfs is
      missing a dput on the lower parent directory dentry.  This patch will
      prevent the BUG() at fs/dcache.c:613 from being hit after renaming a file
      inside eCryptfs and then doing a umount on the lower filesystem.
      Signed-off-by: NMichael Halcrow <mhalcrow@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a9083081
    • V
      [PATCH] pnx4008:fix NULL dereference in rgbfb · 3b9c10dc
      Vitaly Wool 提交于
      Fix possible NULL dereference in pnxrgbfb.
      Signed-off-by: NVitaly Wool <vwool@ru.mvista.com>
      Cc: James Simmons <jsimmons@infradead.org>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3b9c10dc
    • V
      [PATCH] pnx4008: rename driver · 84a763e3
      Vitaly Wool 提交于
      Make the drivers' names less generic to avoid possible confusion in future,
      as was requested by Russell King.
      Signed-off-by: NVitaly Wool <vwool@ru.mvista.com>
      Acked-by: NJames Simmons <jsimmons@infradead.org>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      84a763e3
    • Z
      [PATCH] some irq_chip variables point to NULL · b86432b4
      Zhang, Yanmin 提交于
      I got an oops when booting 2.6.19-rc5-mm1 on my ia64 machine.
      
      Below is the log.
      
      Oops 11012296146944 [1]
      Modules linked in: binfmt_misc dm_mirror dm_multipath dm_mod thermal processor f
      an container button sg eepro100 e100 mii
      
      Pid: 0, CPU 0, comm:              swapper
      psr : 0000121008022038 ifs : 800000000000040b ip  : [<a0000001000e1411>]    Not
      tainted
      ip is at __do_IRQ+0x371/0x3e0
      unat: 0000000000000000 pfs : 000000000000040b rsc : 0000000000000003
      rnat: 656960155aa56aa5 bsps: a00000010058b890 pr  : 656960155aa55a65
      ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c0270033f
      csd : 0000000000000000 ssd : 0000000000000000
      b0  : a0000001000e1390 b6  : a0000001005beac0 b7  : e00000007f01aa00
      f6  : 000000000000000000000 f7  : 0ffe69090000000000000
      f8  : 1000a9090000000000000 f9  : 0ffff8000000000000000
      f10 : 1000a908ffffff6f70000 f11 : 1003e0000000000000909
      r1  : a000000100fbbff0 r2  : 0000000000010002 r3  : 0000000000010001
      r8  : fffffffffffbffff r9  : a000000100bd8060 r10 : a000000100dd83b8
      r11 : fffffffffffeffff r12 : a000000100bcbbb0 r13 : a000000100bc4000
      r14 : 0000000000010000 r15 : 0000000000010000 r16 : a000000100c01aa8
      r17 : a000000100d2c350 r18 : 0000000000000000 r19 : a000000100d2c300
      r20 : a000000100c01a88 r21 : 0000000080010100 r22 : a000000100c01ac0
      r23 : a0000001000108e0 r24 : e000000477980004 r25 : 0000000000000000
      r26 : 0000000000000000 r27 : e00000000913400c r28 : e0000004799ee51c
      r29 : e0000004778b87f0 r30 : a000000100d2c300 r31 : a00000010005c7e0
      
      Call Trace:
       [<a000000100014600>] show_stack+0x40/0xa0
                                      sp=a000000100bcb760 bsp=a000000100bc4f40
       [<a000000100014f00>] show_regs+0x840/0x880
                                      sp=a000000100bcb930 bsp=a000000100bc4ee8
       [<a000000100037fb0>] die+0x250/0x320
                                      sp=a000000100bcb930 bsp=a000000100bc4ea0
       [<a00000010005e5f0>] ia64_do_page_fault+0x8d0/0xa20
                                      sp=a000000100bcb950 bsp=a000000100bc4e50
       [<a00000010000caa0>] ia64_leave_kernel+0x0/0x290
                                      sp=a000000100bcb9e0 bsp=a000000100bc4e50
       [<a0000001000e1410>] __do_IRQ+0x370/0x3e0
                                      sp=a000000100bcbbb0 bsp=a000000100bc4df0
       [<a000000100011f50>] ia64_handle_irq+0x170/0x220
                                      sp=a000000100bcbbb0 bsp=a000000100bc4dc0
       [<a00000010000caa0>] ia64_leave_kernel+0x0/0x290
                                      sp=a000000100bcbbb0 bsp=a000000100bc4dc0
       [<a000000100012390>] ia64_pal_call_static+0x90/0xc0
                                      sp=a000000100bcbd80 bsp=a000000100bc4d78
       [<a000000100015630>] default_idle+0x90/0x160
                                      sp=a000000100bcbd80 bsp=a000000100bc4d58
       [<a000000100014290>] cpu_idle+0x1f0/0x440
                                      sp=a000000100bcbe20 bsp=a000000100bc4d18
       [<a000000100009980>] rest_init+0xc0/0xe0
                                      sp=a000000100bcbe20 bsp=a000000100bc4d00
       [<a0000001009f8ea0>] start_kernel+0x6a0/0x6c0
                                      sp=a000000100bcbe20 bsp=a000000100bc4ca0
       [<a0000001000089f0>] __end_ivt_text+0x6d0/0x6f0
                                      sp=a000000100bcbe30 bsp=a000000100bc4c00
       <0>Kernel panic - not syncing: Aiee, killing interrupt handler!
      
      The root cause is that some irq_chip variables, especially ia64_msi_chip,
      initiate their memeber end to point to NULL. __do_IRQ doesn't check
      if irq_chip->end is null and just calls it after processing the interrupt.
      
      As irq_chip->end is called at many places, so I fix it by reinitiating
      irq_chip->end to dummy_irq_chip.end, e.g., a noop function.
      Signed-off-by: NZhang Yanmin <yanmin.zhang@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b86432b4
    • Z
      [PATCH] ipmi: use platform_device_add() instead of platform_device_register()... · b48f5457
      Zhang, Yanmin 提交于
      [PATCH] ipmi: use platform_device_add() instead of platform_device_register() to register device allocated dynamically
      
      I got below warning when running 2.6.19-rc5-mm1 on my ia64 machine.
      
      WARNING at lib/kobject.c:172 kobject_init()
      
      Call Trace:
       [<a0000001000137c0>] show_stack+0x40/0xa0
                                      sp=e0000002ff9f7bc0 bsp=e0000002ff9f0d10
       [<a000000100013850>] dump_stack+0x30/0x60
                                      sp=e0000002ff9f7d90 bsp=e0000002ff9f0cf8
       [<a000000100407bb0>] kobject_init+0x90/0x160
                                      sp=e0000002ff9f7d90 bsp=e0000002ff9f0cd0
       [<a0000001005ae080>] device_initialize+0x40/0x1c0
                                      sp=e0000002ff9f7da0 bsp=e0000002ff9f0cb0
       [<a0000001005b88c0>] platform_device_register+0x20/0x60
                                      sp=e0000002ff9f7dd0 bsp=e0000002ff9f0c90
       [<a000000100592560>] try_smi_init+0xbc0/0x11e0
                                      sp=e0000002ff9f7dd0 bsp=e0000002ff9f0c50
       [<a000000100594900>] init_ipmi_si+0xaa0/0x12e0
                                      sp=e0000002ff9f7de0 bsp=e0000002ff9f0bd8
       [<a000000100009910>] init+0x350/0x780
                                      sp=e0000002ff9f7e00 bsp=e0000002ff9f0ba8
       [<a000000100011d30>] kernel_thread_helper+0x30/0x60
                                      sp=e0000002ff9f7e30 bsp=e0000002ff9f0b80
       [<a0000001000090c0>] start_kernel_thread+0x20/0x40
                                      sp=e0000002ff9f7e30 bsp=e0000002ff9f0b80
      WARNING at lib/kobject.c:172 kobject_init()
      
      Call Trace:
       [<a0000001000137c0>] show_stack+0x40/0xa0
                                      sp=e0000002ff9f7b40 bsp=e0000002ff9f0db0
       [<a000000100013850>] dump_stack+0x30/0x60
                                      sp=e0000002ff9f7d10 bsp=e0000002ff9f0d98
       [<a000000100407bb0>] kobject_init+0x90/0x160
                                      sp=e0000002ff9f7d10 bsp=e0000002ff9f0d70
       [<a0000001005ae080>] device_initialize+0x40/0x1c0
                                      sp=e0000002ff9f7d20 bsp=e0000002ff9f0d50
       [<a0000001005b88c0>] platform_device_register+0x20/0x60
                                      sp=e0000002ff9f7d50 bsp=e0000002ff9f0d30
       [<a00000010058ac00>] ipmi_register_smi+0xcc0/0x18e0
                                      sp=e0000002ff9f7d50 bsp=e0000002ff9f0c90
       [<a000000100592600>] try_smi_init+0xc60/0x11e0
                                      sp=e0000002ff9f7dd0 bsp=e0000002ff9f0c50
       [<a000000100594900>] init_ipmi_si+0xaa0/0x12e0
                                      sp=e0000002ff9f7de0 bsp=e0000002ff9f0bd8
       [<a000000100009910>] init+0x350/0x780
                                      sp=e0000002ff9f7e00 bsp=e0000002ff9f0ba8
       [<a000000100011d30>] kernel_thread_helper+0x30/0x60
                                      sp=e0000002ff9f7e30 bsp=e0000002ff9f0b80
       [<a0000001000090c0>] start_kernel_thread+0x20/0x40
                                      sp=e0000002ff9f7e30 bsp=e0000002ff9f0b80
      
      The root cause is the device struct is initialized twice.
      
      If the device is allocated dynamically by platform_device_alloc,
      platform_device_alloc will initialize struct device, then,
      platform_device_add should be used to register the device.
      
      The difference between platform_device_register and platform_device_add is
      platform_device_register will initiate the device while platform_device_add
      won't.
      Signed-off-by: NZhang Yanmin <yanmin.zhang@intel.com>
      Cc: Corey Minyard <minyard@acm.org>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b48f5457
  2. 16 11月, 2006 5 次提交
  3. 15 11月, 2006 18 次提交
  4. 14 11月, 2006 11 次提交
    • A
      [PATCH] x86-64: Fix race in exit_idle · 9446868b
      Andi Kleen 提交于
      When another interrupt happens in exit_idle the exit idle notifier
      could be called an incorrect number of times.
      
      Add a test_and_clear_bit_pda and use it handle the bit
      atomically against interrupts to avoid this.
      
      Pointed out by Stephane Eranian
      Signed-off-by: NAndi Kleen <ak@suse.de>
      9446868b
    • A
      [PATCH] x86-64: Fix vgetcpu when CONFIG_HOTPLUG_CPU is disabled · 8c131af1
      Andi Kleen 提交于
      The vgetcpu per CPU initialization previously relied on CPU hotplug
      events for all CPUs to initialize the per CPU state. That only
      worked only on kernels with CONFIG_HOTPLUG_CPU enabled.  On the
      others some CPUs didn't get their state initialized properly
      and vgetcpu wouldn't work.
      
      Change the initialization sequence to instead run in a normal
      initcall (which runs after the normal CPU bootup) and initialize
      all running CPUs there. Later hotplug CPUs are still handled
      with an hotplug notifier.
      
      This actually simplifies the code somewhat.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      8c131af1
    • A
      [PATCH] x86: Add acpi_user_timer_override option for Asus boards · fa18f477
      Andi Kleen 提交于
      Timer overrides are normally disabled on Nvidia board because
      they are commonly wrong, except on new ones with HPET support.
      Unfortunately there are quite some Asus boards around that
      don't have HPET, but need a timer override.
      
      We don't know yet how to handle this transparently,
      but at least add a command line option to force the timer override
      and let them boot.
      
      Cc: len.brown@intel.com
      Signed-off-by: NAndi Kleen <ak@suse.de>
      fa18f477
    • M
      [PATCH] x86-64: setup saved_max_pfn correctly (kdump) · 15803a43
      Magnus Damm 提交于
      x86_64: setup saved_max_pfn correctly
      
      2.6.19-rc4 has broken CONFIG_CRASH_DUMP support on x86_64. It is impossible
      to read out the kernel contents from /proc/vmcore because saved_max_pfn is set
      to zero instead of the max_pfn value before the user map is setup.
      
      This happens because saved_max_pfn is initialized at parse_early_param() time,
      and at this time no active regions have been registered. save_max_pfn is setup
      from e820_end_of_ram(), more exact find_max_pfn_with_active_regions() which
      returns 0 because no regions exist.
      
      This patch fixes this by registering before and removing after the call
      to e820_end_of_ram().
      Signed-off-by: NMagnus Damm <magnus@valinux.co.jp>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      15803a43
    • A
      [PATCH] x86-64: Handle reserve_bootmem_generic beyond end_pfn · 5e58a02a
      Andi Kleen 提交于
      This can happen on kexec kernels with some configurations, in particularly
      on Unisys ES7000 systems.
      
      Analysis by Amul Shah
      
      Cc: Amul Shah <amul.shah@unisys.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      5e58a02a
    • S
      [PATCH] x86-64: shorten the x86_64 boot setup GDT to what the comment says · 51d67a48
      Steven Rostedt 提交于
      Stephen Tweedie, Herbert Xu, and myself have been struggling with a very
      nasty bug in Xen.  But it also pointed out a small bug in the x86_64
      kernel boot setup.
      
      The GDT limit being setup by the initial bzImage code when entering into
      protected mode is way too big.  The comment by the code states that the
      size of the GDT is 2048, but the actual size being set up is much bigger
      (32768). This happens simply because of one extra '0'.
      
      Instead of setting up a 0x800 size, 0x8000 is set up.  On bare metal this
      is fine because the CPU wont load any segments unless  they are
      explicitly used.  But unfortunately, this breaks Xen on vmx FV, since it
      (for now) blindly loads all the segments into the VMCS if they are less
      than the gdt limit. Since the real mode segments are around 0x3000, we are
      getting junk into the VMCS and that later causes an exception.
      
      Stephen Tweedie has written up a patch to fix the Xen side and will be
      submitting that to those folks. But that doesn't excuse the GDT limit
      being a magnitude too big.
      
      AK: changed to compute true gdt size in assembler, fixed comment
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      51d67a48
    • A
      [PATCH] x86-64: Fix PTRACE_[SG]ET_THREAD_AREA regression with ia32 emulation. · 14679eb3
      Andi Kleen 提交于
      ptrace(PTRACE_[SG]ET_THREAD_AREA) calls from ia32 code
      should be passed onto the x86_64 implementation.
      
      The default case in sys32_ptrace used to call to sys_ptrace(), but is
      now EINVAL.  This patch fixes a regression caused by that changed.
      Signed-off-by: NMike McCormack <mike@codeweavers.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      14679eb3
    • A
      [PATCH] x86-64: Fix partial page check to ensure unusable memory is not being marked usable. · 14f448e3
      Aaron Durbin 提交于
      Fix partial page check in e820_register_active_regions to ensure
      partial pages are
      not being marked as active in the memory pool.
      Signed-off-by: NAaron Durbin <adurbin@google.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      14f448e3
    • A
      Revert "[PATCH] MMCONFIG and new Intel motherboards" · 64e72e41
      Andi Kleen 提交于
      This reverts 4c6e052a commit.
      
      Following Linus' i386 change: revert resource reservation
      for mmcfg config now. Will be revisited in .20 hopefully.
      64e72e41
    • D
      libata: fix double-completion on error · 253b92ec
      Darrick J. Wong 提交于
      A curious thing happens, however, when ata_qc_new_init fails to get
      an ata_queued_cmd:
      
      First, ata_qc_new_init handles the failure like this:
          cmd->result = (DID_OK << 16) | (QUEUE_FULL << 1);
          done(cmd);
      
      Then, we return to ata_scsi_translate and do this:
          err_mem:
              cmd->result = (DID_ERROR << 16);
              done(cmd);
      
      It appears to me that first we set a status code indicating that we're
      ok but the device queue is full and finish the command,  but then
      we blow away that status code and replace it with an error flag and
      finish the command a second time!  That does not seem to be desirable
      behavior since we merely want the I/O to wait until a command slot
      frees up, not send errors up the block layer.
      
      In the err_mem case, we should simply exit out of ata_scsi_translate
      instead.
      Signed-off-by: NDarrick J. Wong <djwong@us.ibm.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      253b92ec
    • A
      [PATCH] pata_artop: fix "& (1 >>" typo · 3f9dd27a
      Alexey Dobriyan 提交于
      Signed-off-by: NAlexey Dobriyan <adobriyan@openvz.org>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      3f9dd27a