1. 22 Oct, 2008 23 commits
    • Jean Delvare's avatar
      hwmon: (it87) Prevent power-off on Shuttle SN68PT · 11601895
      Jean Delvare authored
      based on commit 98dd22c3 upstream
      
      On the Shuttle SN68PT, FAN_CTL2 is apparently not connected to a fan,
      but to something else. One user has reported instant system power-off
      when changing the PWM2 duty cycle, so we disable it.
      
      I use the board name string as the trigger in case the same board is
      ever used in other systems.
      
      This closes lm-sensors ticket #2349:
      pwmconfig causes a hard poweroff
      http://www.lm-sensors.org/ticket/2349Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      11601895
    • Linus Torvalds's avatar
      Check mapped ranges on sysfs resource files · fe261563
      Linus Torvalds authored
      commit b5ff7df3 upstream
      
      Check mapped ranges on sysfs resource files
      
      This is loosely based on a patch by Jesse Barnes to check the user-space
      PCI mappings though the sysfs interfaces.  Quoting Jesse's original
      explanation:
      
        It's fairly common for applications to map PCI resources through sysfs.
        However, with the current implementation, it's possible for an application
        to map far more than the range corresponding to the resourceN file it
        opened.  This patch plugs that hole by checking the range at mmap time,
        similar to what is done on platforms like sparc64 in their lower level
        PCI remapping routines.
      
        It was initially put together to help debug the e1000e NVRAM corruption
        problem, since we initially thought an X driver might be walking past the
        end of one of its mappings and clobbering the NVRAM.  It now looks like
        that's not the case, but doing the check is still important for obvious
        reasons.
      
      and this version of the patch differs in that it uses a helper function
      to clarify the code, and does all the checks in pages (instead of bytes)
      in order to avoid overflows when doing "<< PAGE_SHIFT" etc.
      
      [cebbert@redhat.com: backport, changing WARN() to printk()]
      Acked-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Chuck Ebbert <cebbert@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      fe261563
    • David Rientjes's avatar
      x86: avoid dereferencing beyond stack + THREAD_SIZE · 76d8cb9a
      David Rientjes authored
      commit 60e6258cd43f9b06884f04f0f7cefb9c40f17a32 upstream
      
      It's possible for get_wchan() to dereference past task->stack + THREAD_SIZE
      while iterating through instruction pointers if fp equals the upper boundary,
      causing a kernel panic.
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Chuck Ebbert <cebbert@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      76d8cb9a
    • Shaohua Li's avatar
      PCI: disable ASPM on pre-1.1 PCIe devices · 7a69c701
      Shaohua Li authored
      commit 149e1637 upstream
      
      Disable ASPM on pre-1.1 PCIe devices, as many of them don't implement it
      correctly.
      Tested-by: default avatarJack Howarth <howarth@bromo.msbb.uc.edu>
      Signed-off-by: default avatarShaohua Li <shaohua.li@intel.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Chuck Ebbert <cebbert@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      7a69c701
    • Shaohua Li's avatar
      PCI: disable ASPM per ACPI FADT setting · 7a17866e
      Shaohua Li authored
      commit 5fde244d upstream
      
      The ACPI FADT table includes an ASPM control bit. If the bit is set, do
      not enable ASPM since it may indicate that the platform doesn't actually
      support the feature.
      Tested-by: default avatarJack Howarth <howarth@bromo.msbb.uc.edu>
      Signed-off-by: default avatarShaohua Li <shaohua.li@intel.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Chuck Ebbert <cebbert@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      7a17866e
    • Ralph Loader's avatar
      V4L/DVB (9053): fix buffer overflow in uvc-video · 1a5f1e89
      Ralph Loader authored
      Commit fe6c700f upstream
      
      V4L/DVB (9053): fix buffer overflow in uvc-video
      
      There is a buffer overflow in drivers/media/video/uvc/uvc_ctrl.c:
      
      INFO: 0xf2c5ce08-0xf2c5ce0b. First byte 0xa1 instead of 0xcc
      INFO: Allocated in uvc_query_v4l2_ctrl+0x3c/0x239 [uvcvideo] age=13 cpu=1 pid=4975
      ...
      
      A fixed size 8-byte buffer is allocated, and a variable size field is read
      into it; there is no particular bound on the size of the field (it is
      dependent on hardware and configuration) and it can overflow [also
      verified by inserting printk's.]
      
      The patch attempts to size the buffer to the correctly.
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Acked-by: default avatarLaurent Pinchart <laurent.pinchart@skynet.be>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      Cc: Chuck Ebbert <cebbert@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      1a5f1e89
    • Laurent Pinchart's avatar
      V4L/DVB (8617): uvcvideo: don't use stack-based buffers for USB transfers. · 643c65d6
      Laurent Pinchart authored
      commit 04793dd0 upstream
      
      Data buffers on the stack are not allowed for USB I/O. Use dynamically
      allocated buffers instead.
      Signed-off-by: default avatarBruce Schmid <duck@freescale.com>
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart@skynet.be>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@infradead.org>
      Cc: Chuck Ebbert <cebbert@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      643c65d6
    • Laurent Pinchart's avatar
      V4L/DVB (8498): uvcvideo: Return sensible min and max values when querying a boolean control. · 372bd6a0
      Laurent Pinchart authored
      commit 54812c77 upstream
      
      [required to get the following two patches to apply]
      
      Although the V4L2 spec states that the minimum and maximum fields may not be
      valid for control types other than V4L2_CTRL_TYPE_INTEGER, it makes sense
      to set the bounds to 0 and 1 for boolean controls instead of returning
      uninitialized values.
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart@skynet.be>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@infradead.org>
      Cc: Chuck Ebbert <cebbert@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      372bd6a0
    • Linus Torvalds's avatar
      Don't allow splice() to files opened with O_APPEND · e1a85fcf
      Linus Torvalds authored
      commit efc968d4 upstream
      
      This is debatable, but while we're debating it, let's disallow the
      combination of splice and an O_APPEND destination.
      
      It's not entirely clear what the semantics of O_APPEND should be, and
      POSIX apparently expects pwrite() to ignore O_APPEND, for example.  So
      we could make up any semantics we want, including the old ones.
      
      But Miklos convinced me that we should at least give it some thought,
      and that accepting writes at arbitrary offsets is wrong at least for
      IS_APPEND() files (which always have O_APPEND set, even if the reverse
      isn't true: you can obviously have O_APPEND set on a regular file).
      
      So disallow O_APPEND entirely for now.  I doubt anybody cares, and this
      way we have one less gray area to worry about.
      Reported-and-argued-for-by: default avatarMiklos Szeredi <miklos@szeredi.hu>
      Acked-by: default avatarJens Axboe <ens.axboe@oracle.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      e1a85fcf
    • Jean Delvare's avatar
      V4L: zr36067: Fix RGBR pixel format · e35629b6
      Jean Delvare authored
      cherry picked from commit a30ee3c7
      
      The zr36067 driver is improperly declaring pixel format RGBP twice,
      once as "16-bit RGB LE" and once as "16-bit RGB BE". The latter is
      actually RGBR. Fix the code to properly map both pixel formats.
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Acked-by: default avatarTrent Piepho <xyzzy@speakeasy.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      Signed-off-by: default avatarMichael Krufky <mkrufky@linuxtv.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      e35629b6
    • Jean Delvare's avatar
      V4L: bttv: Prevent NULL pointer dereference in radio_open · 7da0ca57
      Jean Delvare authored
      (cherry picked from commit c37396c1)
      
      Fix the following crash in the bttv driver:
      
      BUG: unable to handle kernel NULL pointer dereference at 000000000000036c
      IP: [<ffffffffa037860a>] radio_open+0x3a/0x170 [bttv]
      
      This happens because radio_open assumes that all present bttv devices
      have a radio function. If a bttv device without radio and one with
      radio are installed on the same system, and the one without radio is
      registered first, then radio_open checks for the radio device number
      of a bttv device that has no radio function, and this breaks. All we
      have to do to fix it is to skip bttv devices without a radio function.
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      Signed-off-by: default avatarMichael Krufky <mkrufky@linuxtv.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      7da0ca57
    • Taisuke Yamada's avatar
      libata: LBA28/LBA48 off-by-one bug in ata.h · abcfbcb7
      Taisuke Yamada authored
      commit 97b697a1 upstream
      
      I recently bought 3 HGST P7K500-series 500GB SATA drives and
      had trouble accessing the block right on the LBA28-LBA48 border.
      Here's how it fails (same for all 3 drives):
      
        # dd if=/dev/sdc bs=512 count=1 skip=268435455 > /dev/null
        dd: reading `/dev/sdc': Input/output error
        0+0 records in
        0+0 records out
        0 bytes (0 B) copied, 0.288033 seconds, 0.0 kB/s
        # dmesg
        ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
        ata1.00: BMDMA stat 0x25
        ata1.00: cmd c8/00:08:f8:ff:ff/00:00:00:00:00/ef tag 0 dma 4096 in
        res 51/04:08:f8:ff:ff/00:00:00:00:00/ef Emask 0x1 (device error)
        ata1.00: status: { DRDY ERR }
        ata1.00: error: { ABRT }
        ata1.00: configured for UDMA/33
        ata1: EH complete
        ...
      
      After some investigations, it turned out this seems to be caused
      by misinterpretation of the ATA specification on LBA28 access.
      Following part is the code in question:
      
        === include/linux/ata.h ===
        static inline int lba_28_ok(u64 block, u32 n_block)
        {
          /* check the ending block number */
          return ((block + n_block - 1) < ((u64)1 << 28)) && (n_block <= 256);
        }
      
      HGST drive (sometimes) fails with LBA28 access of {block = 0xfffffff,
      n_block = 1}, and this behavior seems to be comformant. Other drives,
      including other HGST drives are not that strict, through.
      
      >From the ATA specification:
      (http://www.t13.org/Documents/UploadedDocuments/project/d1410r3b-ATA-ATAPI-6.pdf)
      
        8.15.29  Word (61:60): Total number of user addressable sectors
        This field contains a value that is one greater than the total number
        of user addressable sectors (see 6.2). The maximum value that shall
        be placed in this field is 0FFFFFFFh.
      
      So the driver shouldn't use the value of 0xfffffff for LBA28 request
      as this exceeds maximum user addressable sector. The logical maximum
      value for LBA28 is 0xffffffe.
      
      The obvious fix is to cut "- 1" part, and the patch attached just do
      that. I've been using the patched kernel for about a month now, and
      the same fix is also floating on the net for some time. So I believe
      this fix works reliably.
      
      Just FYI, many Windows/Intel platform users also seems to be struck
      by this, and HGST has issued a note pointing to Intel ICH8/9 driver.
      
        "28-bit LBA command is being used to access LBAs 29-bits in length"
      http://www.hitachigst.com/hddt/knowtree.nsf/cffe836ed7c12018862565b000530c74/b531b8bce8745fb78825740f00580e23
      
      Also, *BSDs seems to have similar fix included sometime around ~2004,
      through I have not checked out exact portion of the code.
      Signed-off-by: default avatarTaisuke Yamada <tai@rakugaki.org>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      Cc: Chuck Ebbert <cebbert@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      abcfbcb7
    • Tejun Heo's avatar
      libata: fix EH action overwriting in ata_eh_reset() · dcbe5f2d
      Tejun Heo authored
      Commit a674050e upstream
      
      ehc->i.action got accidentally overwritten to ATA_EH_HARD/SOFTRESET in
      ata_eh_reset().  The original intention was to clear reset action
      which wasn't selected.  This can cause unexpected behavior when other
      EH actions are scheduled together with reset.  Fix it.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      Cc: Chuck Ebbert <cebbert@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      dcbe5f2d
    • Tejun Heo's avatar
      libata: always do follow-up SRST if hardreset returned -EAGAIN · dd5d2d84
      Tejun Heo authored
      commit 5dbfc9cb upstream
      
      As an optimization, follow-up SRST used to be skipped if
      classification wasn't requested even when hardreset requested it via
      -EAGAIN.  However, some hardresets can't wait for device readiness and
      skipping SRST can cause timeout or other failures during revalidation.
      Always perform follow-up SRST if hardreset returns -EAGAIN.  This
      makes reset paths more predictable and thus less error-prone.
      
      While at it, move hardreset error checking such that it's done right
      after hardreset is finished.  This simplifies followup SRST condition
      check a bit and makes the reset path easier to modify.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      Cc: Chuck Ebbert <cebbert@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      dd5d2d84
    • Oleg Nesterov's avatar
      fbcon_set_all_vcs: fix kernel crash when switching the rotated consoles · c8d4a26c
      Oleg Nesterov authored
      commit 232fb69a upstream
      
      echo 3 >> /sys/class/graphics/fbcon/rotate_all, then switch to another
      console. Result:
      
      	BUG: unable to handle kernel paging request at ffffc20005d00000
      	IP: [bitfill_aligned+149/265] bitfill_aligned+0x95/0x109
      	PGD 7e228067 PUD 7e229067 PMD 7bc1f067 PTE 0
      	Oops: 0002 [1] SMP
      	CPU 1
      	Modules linked in: [...a lot...]
      	Pid: 10, comm: events/1 Not tainted 2.6.26.5-45.fc9.x86_64 #1
      	RIP: 0010:[bitfill_aligned+149/265]  [bitfill_aligned+149/265] bitfill_aligned+0x95/0x109
      	RSP: 0018:ffff81007d811bc8  EFLAGS: 00010216
      	RAX: ffffc20005d00000 RBX: 0000000000000000 RCX: 0000000000000400
      	RDX: 0000000000000000 RSI: ffffc20005d00000 RDI: ffffffffffffffff
      	RBP: ffff81007d811be0 R08: 0000000000000400 R09: 0000000000000040
      	R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000010000
      	R13: ffffffff811632f0 R14: 0000000000000006 R15: ffff81007cb85400
      	FS:  0000000000000000(0000) GS:ffff81007e004780(0000) knlGS:0000000000000000
      	CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      	CR2: ffffc20005d00000 CR3: 0000000000201000 CR4: 00000000000006e0
      	DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      	DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      	Process events/1 (pid: 10, threadinfo ffff81007d810000, task ffff81007d808000)
      	Stack:  ffff81007c9d75a0 0000000000000000 0000000000000000 ffff81007d811c80
      	 ffffffff81163a61 ffff810000000000 ffffffff8115f9c8 0000001000000000
      	 0000000100aaaaaa 000000007cd0d4a0 fffffd8a00000800 0001000000000000
      	Call Trace:
      	 [cfb_fillrect+523/798] cfb_fillrect+0x20b/0x31e
      	 [soft_cursor+416/436] ? soft_cursor+0x1a0/0x1b4
      	 [ccw_clear_margins+205/263] ccw_clear_margins+0xcd/0x107
      	 [fbcon_clear_margins+59/61] fbcon_clear_margins+0x3b/0x3d
      	 [fbcon_switch+1291/1466] fbcon_switch+0x50b/0x5ba
      	 [redraw_screen+261/481] redraw_screen+0x105/0x1e1
      	 [ccw_cursor+0/1869] ? ccw_cursor+0x0/0x74d
      	 [complete_change_console+48/190] complete_change_console+0x30/0xbe
      	 [change_console+115/120] change_console+0x73/0x78
      	 [console_callback+0/292] ? console_callback+0x0/0x124
      	 [console_callback+97/292] console_callback+0x61/0x124
      	 [schedule_delayed_work+25/30] ? schedule_delayed_work+0x19/0x1e
      	 [run_workqueue+139/282] run_workqueue+0x8b/0x11a
      	 [worker_thread+221/238] worker_thread+0xdd/0xee
      	 [autoremove_wake_function+0/56] ? autoremove_wake_function+0x0/0x38
      	 [worker_thread+0/238] ? worker_thread+0x0/0xee
      	 [kthread+73/118] kthread+0x49/0x76
      	 [child_rip+10/18] child_rip+0xa/0x12
      	 [kthread+0/118] ? kthread+0x0/0x76
      	 [child_rip+0/18] ? child_rip+0x0/0x12
      
      Because fbcon_set_all_vcs()->FBCON_SWAP() uses display->rotate == 0 instead
      of fbcon_ops->rotate, and vc_resize() has no effect because it is called with
      new_cols/rows == ->vc_cols/rows.
      
      Tested on 2.6.26.5-45.fc9.x86_64, but
      http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git seems to
      have the same problem.
      Signed-off-by: default avatarOleg Nesterov <oleg@tv-sign.ru>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      c8d4a26c
    • Alexey Dobriyan's avatar
      modules: fix module "notes" kobject leak · 7a67d6e8
      Alexey Dobriyan authored
      commit e9432093 upstream
      
      Fix "notes" kobject leak
      
      It happens every rmmod if KALLSYMS=y and SYSFS=y.
      
      	# modprobe foo
      
      kobject: 'foo' (ffffffffa00743d0): kobject_add_internal: parent: 'module', set: 'module'
      kobject: 'holders' (ffff88017e7c5770): kobject_add_internal: parent: 'foo', set: '<NULL>'
      kobject: 'foo' (ffffffffa00743d0): kobject_uevent_env
      kobject: 'foo' (ffffffffa00743d0): fill_kobj_path: path = '/module/foo'
      kobject: 'notes' (ffff88017fa9b668): kobject_add_internal: parent: 'foo', set: '<NULL>'
      	  ^^^^^
      
      	# rmmod foo
      
      kobject: 'holders' (ffff88017e7c5770): kobject_cleanup
      kobject: 'holders' (ffff88017e7c5770): auto cleanup kobject_del
      kobject: 'holders' (ffff88017e7c5770): calling ktype release
      kobject: (ffff88017e7c5770): dynamic_kobj_release
      kobject: 'holders': free name
      kobject: 'foo' (ffffffffa00743d0): kobject_cleanup
      kobject: 'foo' (ffffffffa00743d0): does not have a release() function, it is broken and must be fixed.
      kobject: 'foo' (ffffffffa00743d0): auto cleanup 'remove' event
      kobject: 'foo' (ffffffffa00743d0): kobject_uevent_env
      kobject: 'foo' (ffffffffa00743d0): fill_kobj_path: path = '/module/foo'
      kobject: 'foo' (ffffffffa00743d0): auto cleanup kobject_del
      kobject: 'foo': free name
      
      	[whooops]
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      7a67d6e8
    • Larry Finger's avatar
      b43legacy: Fix failure in rate-adjustment mechanism · c2fa492c
      Larry Finger authored
      commit c6a2afda upstream
      Date: Sat, 6 Sep 2008 16:51:22 -0500
      Subject: b43legacy: Fix failure in rate-adjustment mechanism
      
      A coding error present since b43legacy was incorporated into the
      kernel has prevented the driver from using the rate-setting mechanism
      of mac80211. The driver has been forced to remain at a 1 Mb/s rate.
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      c2fa492c
    • Steve French's avatar
      CIFS: make sure we have the right resume info before calling CIFSFindNext · 282333bd
      Steve French authored
      commit 0752f152 upstream
      
      When we do a seekdir() or equivalent, we usually end up doing a
      FindFirst call and then call FindNext until we get to the offset that we
      want. The problem is that when we call FindNext, the code usually
      doesn't have the proper info (mostly, the filename of the entry from the
      last search) to resume the search.
      
      Add a "last_entry" field to the cifs_search_info that points to the last
      entry in the search. We calculate this pointer by using the
      LastNameOffset field from the search parms that are returned. We then
      use that info to do a cifs_save_resume_key before we call CIFSFindNext.
      
      This patch allows CIFS to reliably pass the "telldir" connectathon test.
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      282333bd
    • Dario Faggioli's avatar
      sched_rt.c: resch needed in rt_rq_enqueue() for the root rt_rq · 3c03d1ac
      Dario Faggioli authored
      commit f6121f4f upstream
      
      While working on the new version of the code for SCHED_SPORADIC I
      noticed something strange in the present throttling mechanism. More
      specifically in the throttling timer handler in sched_rt.c
      (do_sched_rt_period_timer()) and in rt_rq_enqueue().
      
      The problem is that, when unthrottling a runqueue, rt_rq_enqueue() only
      asks for rescheduling if the runqueue has a sched_entity associated to
      it (i.e., rt_rq->rt_se != NULL).
      Now, if the runqueue is the root rq (which has a rt_se = NULL)
      rescheduling does not take place, and it is delayed to some undefined
      instant in the future.
      
      This imply some random bandwidth usage by the RT tasks under throttling.
      For instance, setting rt_runtime_us/rt_period_us = 950ms/1000ms an RT
      task will get less than 95%. In our tests we got something varying
      between 70% to 95%.
      Using smaller time values, e.g., 95ms/100ms, things are even worse, and
      I can see values also going down to 20-25%!!
      
      The tests we performed are simply running 'yes' as a SCHED_FIFO task,
      and checking the CPU usage with top, but we can investigate thoroughly
      if you think it is needed.
      
      Things go much better, for us, with the attached patch... Don't know if
      it is the best approach, but it solved the issue for us.
      Signed-off-by: default avatarDario Faggioli <raistlin@linux.it>
      Signed-off-by: default avatarMichael Trimarchi <trimarchimichael@yahoo.it>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      3c03d1ac
    • Alan Cox's avatar
      tty: Termios locking - sort out real_tty confusions and lock reads · 0c178500
      Alan Cox authored
      commit 8f520021 upstream
      
      (only the tty_io.c portion of this commit)
      
      This moves us towards sanity and should mean our termios locking is now
      complete and comprehensive.
      Signed-off-by: default avatarAlan Cox <alan@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      0c178500
    • Alan Cox's avatar
      x86, early_ioremap: fix fencepost error · 6cb603ed
      Alan Cox authored
      commit c613ec1a upstream
      
      The x86 implementation of early_ioremap has an off by one error. If we get
      an object which ends on the first byte of a page we undermap by one page and
      this causes a crash on boot with the ASUS P5QL whose DMI table happens to fit
      this alignment.
      
      The size computation is currently
      
      	last_addr = phys_addr + size - 1;
      	npages = (PAGE_ALIGN(last_addr) - phys_addr)
      
      (Consider a request for 1 byte at alignment 0...)
      
      Closes #11693
      
      Debugging work by Ian Campbell/Felix Geyer
      Signed-off-by: default avatarAlan Cox <alan@rehat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      6cb603ed
    • Thomas Gleixner's avatar
      x86: improve UP kernel when CPU-hotplug and SMP is enabled · b50094cc
      Thomas Gleixner authored
      commit 649c6653 upstream
      
      num_possible_cpus() can be > 1 when disabled CPUs have been accounted.
      
      Disabled CPUs are not in the cpu_present_map, so we can use
      num_present_cpus() as a safe indicator to switch to UP alternatives.
      Reported-by: default avatarChuck Ebbert <cebbert@redhat.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      b50094cc
    • Stefan Bader's avatar
      x86: Reserve FIRST_DEVICE_VECTOR in used_vectors bitmap. · 4c1f10b9
      Stefan Bader authored
      Not in upstream above 2.6.27 due to change in the way this code works
      (has been fixed differently there.)
      
      Someone from the community found out, that after repeatedly unloading
      and loading a device driver that uses MSI IRQs, the system eventually
      assigned the vector initially reserved for IRQ0 to the device driver.
      
      The reason for this is, that although IRQ0 is tied to the
      FIRST_DEVICE_VECTOR when declaring the irq_vector table, the
      corresponding bit in the used_vectors map is not set. So, if vectors are
      released and assigned often enough, the vector will get assigned to
      another interrupt. This happens more often with MSI interrupts as those
      are exclusively using a vector.
      
      Fix this by setting the bit for the FIRST_DEVICE_VECTOR in the bitmap.
      Signed-off-by: default avatarStefan Bader <stefan.bader@canonical.com>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      4c1f10b9
  2. 09 Oct, 2008 17 commits