1. 19 3月, 2009 1 次提交
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6 · 99dbe109
      Linus Torvalds 提交于
      * git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6:
        USB: storage: Unusual USB device Prolific 2507 variation added
        USB: Add device id for Option GTM380 to option driver
        USB: Add Vendor/Product ID for new CDMA U727 to option driver
        USB: Updated unusual-devs entry for USB mass storage on Nokia 6233
        USB: Option: let cdc-acm handle Sony Ericsson F3507g / Dell 5530
        USB: EHCI: expedite unlinks when the root hub is suspended
        USB: EHCI: Fix isochronous URB leak
        USB: option.c: add ZTE 622 modem device
        USB: wusbcore/wa-xfer, fix lock imbalance
        USB: misc/vstusb, fix lock imbalance
        USB: misc/adutux, fix lock imbalance
        USB: image/mdc800, fix lock imbalance
        USB: atm/cxacru, fix lock imbalance
        USB: unusual_devs: Add support for GI 0431 SD-Card interface
        USB: serial: new cp2101 device id
        USB: serial: ftdi: enable UART detection on gnICE JTAG adaptors blacklist interface0
        USB: serial: add FTDI USB/Serial converter devices
        USB: usbfs: keep async URBs until the device file is closed
        USB: usbtmc: add protocol 1 support
        USB: usbtmc: fix stupid bug in open()
      99dbe109
  2. 18 3月, 2009 32 次提交
  3. 17 3月, 2009 7 次提交
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-2.6-dm · 18439c39
      Linus Torvalds 提交于
      * git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-2.6-dm:
        dm crypt: wait for endio to complete before destruction
        dm crypt: fix kcryptd_async_done parameter
        dm io: respect BIO_MAX_PAGES limit
        dm table: rework reference counting fix
        dm ioctl: validate name length when renaming
      18439c39
    • L
      Fast TSC calibration: calculate proper frequency error bounds · 9e8912e0
      Linus Torvalds 提交于
      In order for ntpd to correctly synchronize the clocks, the frequency of
      the system clock must not be off by more than 500 ppm (or, put another
      way, 1:2000), or ntpd will end up giving up on trying to synchronize
      properly, and ends up reseting the clock in jumps instead.
      
      The fast TSC PIT calibration sometimes failed this test - it was
      assuming that the PIT reads always took about one microsecond each (2us
      for the two reads to get a 16-bit timer), and that calibrating TSC to
      the PIT over 15ms should thus be sufficient to get much closer than
      500ppm (max 2us error on both sides giving 4us over 15ms: a 270 ppm
      error value).
      
      However, that assumption does not always hold: apparently some hardware
      is either very much slower at reading the PIT registers, or there was
      other noise causing at least one machine to get 700+ ppm errors.
      
      So instead of using a fixed 15ms timing loop, this changes the fast PIT
      calibration to read the TSC delta over the individual PIT timer reads,
      and use the result to calculate the error bars on the PIT read timing
      properly.  We then successfully calibrate the TSC only if the maximum
      error bars fall below 500ppm.
      
      In the process, we also relax the timing to allow up to 25ms for the
      calibration, although it can happen much faster depending on hardware.
      Reported-and-tested-by: NJesper Krogh <jesper@krogh.cc>
      Cc: john stultz <johnstul@us.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9e8912e0
    • L
      Fix potential fast PIT TSC calibration startup glitch · a6a80e1d
      Linus Torvalds 提交于
      During bootup, when we reprogram the PIT (programmable interval timer)
      to start counting down from 0xffff in order to use it for the fast TSC
      calibration, we should also make sure to delay a bit afterwards to allow
      the PIT hardware to actually start counting with the new value.
      
      That will happens at the next CLK pulse (1.193182 MHz), so the easiest
      way to do that is to just wait at least one microsecond after
      programming the new PIT counter value.  We do that by just reading the
      counter value back once - which will take about 2us on PC hardware.
      Reported-and-tested-by: Njohn stultz <johnstul@us.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a6a80e1d
    • K
      ALSA: opl3sa2 - Fix NULL dereference when suspending snd_opl3sa2 · dde332b6
      Krzysztof Helt 提交于
      Fix the OOPS during a opl3sa2 card suspend
      and resume if the driver is loaded but the card
      is not found.
      Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
      Cc: <stable@kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      dde332b6
    • E
      ext4: fix bb_prealloc_list corruption due to wrong group locking · d33a1976
      Eric Sandeen 提交于
      This is for Red Hat bug 490026: EXT4 panic, list corruption in
      ext4_mb_new_inode_pa
      
      ext4_lock_group(sb, group) is supposed to protect this list for
      each group, and a common code flow to remove an album is like
      this:
      
          ext4_get_group_no_and_offset(sb, pa->pa_pstart, &grp, NULL);
          ext4_lock_group(sb, grp);
          list_del(&pa->pa_group_list);
          ext4_unlock_group(sb, grp);
      
      so it's critical that we get the right group number back for
      this prealloc context, to lock the right group (the one 
      associated with this pa) and prevent concurrent list manipulation.
      
      however, ext4_mb_put_pa() passes in (pa->pa_pstart - 1) with a 
      comment, "-1 is to protect from crossing allocation group".
      
      This makes sense for the group_pa, where pa_pstart is advanced
      by the length which has been used (in ext4_mb_release_context()),
      and when the entire length has been used, pa_pstart has been
      advanced to the first block of the next group.
      
      However, for inode_pa, pa_pstart is never advanced; it's just
      set once to the first block in the group and not moved after
      that.  So in this case, if we subtract one in ext4_mb_put_pa(),
      we are actually locking the *previous* group, and opening the
      race with the other threads which do not subtract off the extra
      block.
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      d33a1976
    • L
      Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 · 19695ec0
      Linus Torvalds 提交于
      * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
        acpi-wmi: unsigned cannot be less than 0
        thinkpad-acpi: fix module autoloading for older models
        acer-wmi: Unmark as 'experimental'
        acpi-wmi: Unmark as 'experimental'
        acer-wmi: double free in acer_rfkill_exit()
        platform/x86: depends instead of select for laptop platform drivers
        asus-laptop: use select instead of depends on
        eeepc-laptop: restore acpi_generate_proc_event()
        asus-laptop: restore acpi_generate_proc_event()
        acpi: check for pxm_to_node_map overflow
        ACPI: remove doubled status checking
        ACPI suspend: Blacklist Toshiba Satellite L300 that requires to set SCI_EN directly on resume
        Revert "ACPI: make some IO ports off-limits to AML"
        suspend: switch the Asus Pundit P1-AH2 to old ACPI sleep ordering
      19695ec0
    • M
      dm crypt: wait for endio to complete before destruction · b35f8caa
      Milan Broz 提交于
      The following oops has been reported when dm-crypt runs over a loop device.
      
      ...
      [   70.381058] Process loop0 (pid: 4268, ti=cf3b2000 task=cf1cc1f0 task.ti=cf3b2000)
      ...
      [   70.381058] Call Trace:
      [   70.381058]  [<d0d76601>] ? crypt_dec_pending+0x5e/0x62 [dm_crypt]
      [   70.381058]  [<d0d767b8>] ? crypt_endio+0xa2/0xaa [dm_crypt]
      [   70.381058]  [<d0d76716>] ? crypt_endio+0x0/0xaa [dm_crypt]
      [   70.381058]  [<c01a2f24>] ? bio_endio+0x2b/0x2e
      [   70.381058]  [<d0806530>] ? dec_pending+0x224/0x23b [dm_mod]
      [   70.381058]  [<d08066e4>] ? clone_endio+0x79/0xa4 [dm_mod]
      [   70.381058]  [<d080666b>] ? clone_endio+0x0/0xa4 [dm_mod]
      [   70.381058]  [<c01a2f24>] ? bio_endio+0x2b/0x2e
      [   70.381058]  [<c02bad86>] ? loop_thread+0x380/0x3b7
      [   70.381058]  [<c02ba8a1>] ? do_lo_send_aops+0x0/0x165
      [   70.381058]  [<c013754f>] ? autoremove_wake_function+0x0/0x33
      [   70.381058]  [<c02baa06>] ? loop_thread+0x0/0x3b7
      
      When a table is being replaced, it waits for I/O to complete
      before destroying the mempool, but the endio function doesn't
      call mempool_free() until after completing the bio.
      
      Fix it by swapping the order of those two operations.
      
      The same problem occurs in dm.c with md referenced after dec_pending.
      Again, we swap the order.
      
      Cc: stable@kernel.org
      Signed-off-by: NMilan Broz <mbroz@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      b35f8caa