1. 08 1月, 2008 1 次提交
  2. 07 1月, 2008 9 次提交
    • H
      V4L/DVB (6916): ivtv: udelay has to be changed *after* the eeprom was read, not before · 89dab357
      Hans Verkuil 提交于
      The eeprom decides which Hauppauge model it is, so the decision whether to
      use an udelay of 5 or 10 needs to be taken after reading the eeprom, not
      before.
      Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      89dab357
    • G
      V4L/DVB (6944a): Fix Regression VIDIOCGMBUF ioctl hangs on bttv driver · d9030f57
      Gregor Jasny 提交于
      Fix bttv VIDIOCGMBUF locking like done in commit
      820eacd8. 
      Signed-off-by: NGregor Jasny <gjasny@web.de>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      d9030f57
    • L
      Merge master.kernel.org:/home/rmk/linux-2.6-arm · 2b300d20
      Linus Torvalds 提交于
      * master.kernel.org:/home/rmk/linux-2.6-arm:
        [ARM] 4691/1: add missing i2c_board_info struct for at91rm9200
        [ARM] 4735/1: Unbreak pxa25x suspend/resume
      2b300d20
    • L
      Linux 2.6.24-rc7 · 3ce54450
      Linus Torvalds 提交于
      3ce54450
    • I
      CPU hotplug: fix cpu_is_offline() on !CONFIG_HOTPLUG_CPU · a263898f
      Ingo Molnar 提交于
      make randconfig bootup testing found that the cpufreq code
      crashes on bootup, if the powernow-k8 driver is enabled and
      if maxcpus=1 passed on the boot line to a !CONFIG_HOTPLUG_CPU
      kernel.
      
      First lockdep found out that there's an inconsistent unlock
      sequence:
      
       =====================================
       [ BUG: bad unlock balance detected! ]
       -------------------------------------
       swapper/1 is trying to release lock (&per_cpu(cpu_policy_rwsem, cpu)) at:
       [<ffffffff806ffd8e>] unlock_policy_rwsem_write+0x3c/0x42
       but there are no more locks to release!
      
      Call Trace:
       [<ffffffff806ffd8e>] unlock_policy_rwsem_write+0x3c/0x42
       [<ffffffff80251c29>] print_unlock_inbalance_bug+0x104/0x12c
       [<ffffffff80252f3a>] mark_held_locks+0x56/0x94
       [<ffffffff806ffd8e>] unlock_policy_rwsem_write+0x3c/0x42
       [<ffffffff807008b6>] cpufreq_add_dev+0x2a8/0x5c4
       ...
      
      then shortly afterwards the cpufreq code crashed on an assert:
      
       ------------[ cut here ]------------
       kernel BUG at drivers/cpufreq/cpufreq.c:1068!
       invalid opcode: 0000 [1] SMP
       [...]
       Call Trace:
        [<ffffffff805145d6>] sysdev_driver_unregister+0x5b/0x91
        [<ffffffff806ff520>] cpufreq_register_driver+0x15d/0x1a2
        [<ffffffff80cc0596>] powernowk8_init+0x86/0x94
       [...]
       ---[ end trace 1e9219be2b4431de ]---
      
      the bug was caused by maxcpus=1 bootup, which brought up the
      secondary core as !cpu_online() but !cpu_is_offline() either,
      which on on !CONFIG_HOTPLUG_CPU is always 0 (include/linux/cpu.h):
      
        /* CPUs don't go offline once they're online w/o CONFIG_HOTPLUG_CPU */
        static inline int cpu_is_offline(int cpu) { return 0; }
      
      but the cpufreq code uses cpu_online() and cpu_is_offline() in
      a mixed way - the low-level drivers use cpu_online(), while
      the cpufreq core uses cpu_is_offline(). This opened up the
      possibility to add the non-initialized sysdev device of the
      secondary core:
      
       cpufreq-core: trying to register driver powernow-k8
       cpufreq-core: adding CPU 0
       powernow-k8: BIOS error - no PSB or ACPI _PSS objects
       cpufreq-core: initialization failed
       cpufreq-core: adding CPU 1
       cpufreq-core: initialization failed
      
      which then blew up. The fix is to make cpu_is_offline() always
      the negation of cpu_online(). With that fix applied the kernel
      boots up fine without crashing:
      
       Calling initcall 0xffffffff80cc0510: powernowk8_init+0x0/0x94()
       powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ processors (1 cpu cores) (version 2.20.00)
       powernow-k8: BIOS error - no PSB or ACPI _PSS objects
       initcall 0xffffffff80cc0510: powernowk8_init+0x0/0x94() returned -19.
       initcall 0xffffffff80cc0510 ran for 19 msecs: powernowk8_init+0x0/0x94()
       Calling initcall 0xffffffff80cc328f: init_lapic_nmi_sysfs+0x0/0x39()
      
      We could fix this by making CPU enumeration aware of max_cpus, but that
      would be more fragile IMO, and the cpu_online(cpu) != cpu_is_offline(cpu)
      possibility was quite confusing and a continuous source of bugs too.
      
      Most distributions have kernels with CPU hotplug enabled, so this bug
      remained hidden for a long time.
      
      Bug forensics:
      
      The broken cpu_is_offline() API variant was introduced via:
      
       commit a59d2e4e6977e7b94e003c96a41f07e96cddc340
       Author: Rusty Russell <rusty@rustcorp.com.au>
       Date:   Mon Mar 8 06:06:03 2004 -0800
      
           [PATCH] minor cleanups for hotplug CPUs
      
      ( this predates linux-2.6.git, this commit is available from Thomas's
        historic git tree. )
      
      Then 1.5 years later the cpufreq code made use of it:
      
       commit c32b6b8e
       Author: Ashok Raj <ashok.raj@intel.com>
       Date:   Sun Oct 30 14:59:54 2005 -0800
      
           [PATCH] create and destroy cpufreq sysfs entries based on cpu notifiers
      
       +       if (cpu_is_offline(cpu))
       +               return 0;
      
      which is a correct use of the subtly broken new API. v2.6.15 then
      shipped with this bug included.
      
      then it took two more years for random-kernel qa to hit it.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a263898f
    • I
      hda_intel suspend latency: shorten codec read · 57a04513
      Ingo Molnar 提交于
      not sleeping for every codec read/write but doing a short udelay and
      a conditional reschedule has cut suspend+resume latency by about 1
      second on my T60.
      
      The patch also fixes the unexpected codec-connection errors that
      happen more often in the new power-save mode:
          http://lkml.org/lkml/2007/11/8/255
          http://bugzilla.kernel.org/show_bug.cgi?id=9332Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      57a04513
    • J
      [ARM] 4691/1: add missing i2c_board_info struct for at91rm9200 · 430cb436
      Jan Altenberg 提交于
      - Add missing i2c_board_info struct for at91rm9200
      Signed-off-by: NJan Altenberg <jan.altenberg@linutronix.de>
      Acked-by: NAndrew Victor <avictor.za@gmail.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      430cb436
    • A
      fix: using joysticks in 32 bit applications on 64 bit systems · 3fee37c1
      Akos Maroy 提交于
      unfortunately 32 bit apps don't see the joysticks on a 64 bit system.
      this prevents one playing X-Plane (http://www.x-plane.com/) or other
      32-bit games with joysticks.
      
      this is a known issue, and already raised several times:
      
       http://readlist.com/lists/vger.kernel.org/linux-kernel/28/144411.html
      
       http://www.brettcsmith.org/wiki/wiki.cgi?action=browse&diff=1&id=OzyComputer/Joystick
      
      unfortunately this is still not fixed in the mainline kernel.
      
      it would be nice to have this fixed, so that people can play these games
      without having to patch their kernel.
      
      the following patch solves the problem on 2.6.22.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NChristoph Hellwig <hch@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3fee37c1
    • L
      Revert "scsi: revert "[SCSI] Get rid of scsi_cmnd->done"" · 7b3d9545
      Linus Torvalds 提交于
      This reverts commit ac40532e, which gets
      us back the original cleanup of 6f5391c2.
      
      It turns out that the bug that was triggered by that commit was
      apparently not actually triggered by that commit at all, and just the
      testing conditions had changed enough to make it appear to be due to it.
      
      The real problem seems to have been found by Peter Osterlund:
      
        "pktcdvd sets it [block device size] when opening the /dev/pktcdvd
         device, but when the drive is later opened as /dev/scd0, there is
         nothing that sets it back.  (Btw, 40944 is possible if the disk is a
         CDRW that was formatted with "cdrwtool -m 10236".)
      
         The problem is that pktcdvd opens the cd device in non-blocking mode
         when pktsetup is run, and doesn't close it again until pktsetup -d is
         run.  The effect is that if you meanwhile open the cd device,
         blkdev.c:do_open() doesn't call bd_set_size() because
         bdev->bd_openers is non-zero."
      
      In particular, to repeat the bug (regardless of whether commit
      6f5391c2 is applied or not):
      
        " 1. Start with an empty drive.
          2. pktsetup 0 /dev/scd0
          3. Insert a CD containing an isofs filesystem.
          4. mount /dev/pktcdvd/0 /mnt/tmp
          5. umount /mnt/tmp
          6. Press the eject button.
          7. Insert a DVD containing a non-writable filesystem.
          8. mount /dev/scd0 /mnt/tmp
          9. find /mnt/tmp -type f -print0 | xargs -0 sha1sum >/dev/null
          10. If the DVD contains data beyond the physical size of a CD, you
              get I/O errors in the terminal, and dmesg reports lots of
              "attempt to access beyond end of device" errors."
      
      which in turn is because the nested open after the media change won't
      cause the size to be set properly (because the original open still holds
      the block device, and we only do the bd_set_size() when we don't have
      other people holding the device open).
      
      The proper fix for that is probably to just do something like
      
      	bdev->bd_inode->i_size = (loff_t)get_capacity(disk)<<9;
      
      in fs/block_dev.c:do_open() even for the cases where we're not the
      original opener (but *not* call bd_set_size(), since that will also
      change the block size of the device).
      
      Cc: Peter Osterlund <petero2@telia.com>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: Matthew Wilcox <matthew@wil.cx>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7b3d9545
  3. 05 1月, 2008 2 次提交
  4. 04 1月, 2008 22 次提交
  5. 03 1月, 2008 6 次提交
    • T
      NFSv4: Fix open_to_lock_owner sequenceid allocation... · e6e21970
      Trond Myklebust 提交于
      NFSv4 file locking is currently completely broken since it doesn't respect
      the OPEN sequencing when it is given an unconfirmed lock_owner and needs to
      do an open_to_lock_owner. Worse: it breaks the sunrpc rules by doing a
      GFP_KERNEL allocation inside an rpciod callback.
      
      Fix is to preallocate the open seqid structure in nfs4_alloc_lockdata if we
      see that the lock_owner is unconfirmed.
      Then, in nfs4_lock_prepare() we wait for either the open_seqid, if
      the lock_owner is still unconfirmed, or else fall back to waiting on the
      standard lock_seqid.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      e6e21970
    • T
      NFSv4: nfs4_open_confirm must not set the open_owner as confirmed on error · bb22629e
      Trond Myklebust 提交于
      RFC3530 states that the open_owner is confirmed if and only if the client
      sends an OPEN_CONFIRM request with the appropriate sequence id and stateid
      within the lease period.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      bb22629e
    • J
      NFS: add newline to kernel warning message in auth_gss code · 3392c349
      James Morris 提交于
      Add newline to kernel warning message in gss_create().
      Signed-off-by: NJames Morris <jmorris@namei.org>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      3392c349
    • T
      NFSv4: Fix circular locking dependency in nfs4_kill_renewd · b274b48f
      Trond Myklebust 提交于
      Erez Zadok reports:
      
      =======================================================
      [ INFO: possible circular locking dependency detected ]
      2.6.24-rc6-unionfs2 #80
      -------------------------------------------------------
      umount.nfs4/4017 is trying to acquire lock:
       (&(&clp->cl_renewd)->work){--..}, at: [<c0223e53>]
      __cancel_work_timer+0x83/0x17f
      
      but task is already holding lock:
       (&clp->cl_sem){----}, at: [<f8879897>] nfs4_kill_renewd+0x17/0x29 [nfs]
      
      which lock already depends on the new lock.
      
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&clp->cl_sem){----}:
             [<c0230699>] __lock_acquire+0x9cc/0xb95
             [<c0230c39>] lock_acquire+0x5f/0x78
             [<c0397cb8>] down_read+0x3a/0x4c
             [<f88798e6>] nfs4_renew_state+0x1c/0x1b8 [nfs]
             [<c0223821>] run_workqueue+0xd9/0x1ac
             [<c0224220>] worker_thread+0x7a/0x86
             [<c0226b49>] kthread+0x3b/0x62
             [<c02033a3>] kernel_thread_helper+0x7/0x10
             [<ffffffff>] 0xffffffff
      
      -> #0 (&(&clp->cl_renewd)->work){--..}:
             [<c0230589>] __lock_acquire+0x8bc/0xb95
             [<c0230c39>] lock_acquire+0x5f/0x78
             [<c0223e87>] __cancel_work_timer+0xb7/0x17f
             [<c0223f5a>] cancel_delayed_work_sync+0xb/0xd
             [<f887989e>] nfs4_kill_renewd+0x1e/0x29 [nfs]
             [<f885a8f6>] nfs_free_client+0x37/0x9e [nfs]
             [<f885ab20>] nfs_put_client+0x5d/0x62 [nfs]
             [<f885ab9a>] nfs_free_server+0x75/0xae [nfs]
             [<f8862672>] nfs4_kill_super+0x27/0x2b [nfs]
             [<c0258aab>] deactivate_super+0x3f/0x51
             [<c0269668>] mntput_no_expire+0x42/0x67
             [<c025d0e4>] path_release_on_umount+0x15/0x18
             [<c0269d30>] sys_umount+0x1a3/0x1cb
             [<c0269d71>] sys_oldumount+0x19/0x1b
             [<c02026ca>] sysenter_past_esp+0x5f/0xa5
             [<ffffffff>] 0xffffffff
      
      Looking at the code, it would seem that taking the clp->cl_sem in
      nfs4_kill_renewd is completely redundant, since we're already guaranteed to
      have exclusive access to the nfs_client (we're shutting down).
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      b274b48f
    • T
      NFS: Fix a possible Oops in fs/nfs/super.c · e9cc6c23
      Trond Myklebust 提交于
      Sigh... commit 4584f520 (NFS: Fix NFS
      mountpoint crossing...) had a slight flaw: server can be NULL if sget()
      returned an existing superblock.
      
      Fix the fix by dereferencing s->s_fs_info.
      
      Thanks to Coverity/Adrian Bunk and Frank Filz for spotting the bug.
      (See http://bugzilla.kernel.org/show_bug.cgi?id=9647)
      
      Also add in the same namespace Oops fix for NFSv4 in both the mountpoint
      crossing case, and the referral case.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      e9cc6c23
    • J
      hwmon: (w83627ehf) Be more careful when changing VID input level · 58e6e781
      Jean Delvare 提交于
      The VID input level change has been reported to cause trouble. Be more
      careful in this respect:
      * Only change the level on the W83627EHF/EHG. The W83627DHG is more
        complex in this respect.
      * Don't change the level if the VID pins are in output mode.
      * Only set the level to TTL if VRM 9.x is used.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Signed-off-by: NMark M. Hoffman <mhoffman@lightlink.com>
      58e6e781