aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* drm/i915: Disable pagefaults along execbuffer relocation fast pathChris Wilson2011-03-23
| | | | | | | | | | | | | | | | | | Along the fast path for relocation handling, we attempt to copy directly from the user data structures whilst holding our mutex. This causes lockdep to warn about circular lock dependencies if we need to pagefault the user pages. [Since when handling a page fault on a mmapped bo, we need to acquire the struct mutex whilst already holding the mm semaphore, it is then verboten to acquire the mm semaphore when already holding the struct mutex. The likelihood of the user passing in the relocations contained in a GTT mmaped bo is low, but conceivable for extreme pathology.] In order to force the mm to return EFAULT rather than handle the pagefault, we therefore need to disable pagefaults across the relocation fast path. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix computation of pitch for dumb bo creatorChris Wilson2011-03-23
| | | | | Cc: Dave Airlie <airlied@linux.ie> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915: report correct render clock frequencies on SNBJesse Barnes2011-03-23
| | | | | | | | | | | Fix up the debug file to report the right frequencies. On SNB, we program the PCU with a frequency ratio, which is multiplied by 100MHz on the CPU side. But GFX only runs at half that, so report it as such to avoid confusion. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com>
* drm/i915/dp: Correct the order of deletion for ghost eDP devicesTakashi Iwai2011-03-23
| | | | | | | | | | | | | The order of the calls does matter indeed. Swapping the call order of intel_dp_destroy() and intel_dp_encoder_destroy() fixes the problem. This is because i2c_del_adapter unregisters the device which parent is intel_connector, and connectors are removed in intel_dp_destroy(). Thus intel_dp_encoder_destroy() must be called before intel_dp_destroy(). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=24822 Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com>
* drm/i915: Fix tiling corruption from pipelined fencingChris Wilson2011-03-23
| | | | | | | | | | | | | | | | | | | ... even though it was disabled. A mistake in the handling of fence reuse caused us to skip the vital delay of waiting for the object to finish rendering before changing the register. This resulted in us changing the fence register whilst the bo was active and so causing the blits to complete using the wrong stride or even the wrong tiling. (Visually the effect is that small blocks of the screen look like they have been interlaced). The fix is to wait for the GPU to finish using the memory region pointed to by the fence before changing it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34584 Cc: Andy Whitcroft <apw@canonical.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> [Note for 2.6.38-stable, we need to reintroduce the interruptible passing] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Dave Airlie <airlied@linux.ie>
* drm/i915: Re-enable self-refreshYuanhan Liu2011-03-23
| | | | | | | | | | | | A broken implementation of is_pot() prevented the detection of when a singular pipe was enabled. Eric Anholt pointed out the existence of is_power_of_2() so use that instead of our broken code! Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35402 Signed-off-by: Yuanhan Liu <yuanhan.liu@intel.com> Tested-by: xunx.fang@intel.com Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915: Prevent racy removal of request from client listHerton Ronaldo Krzesinski2011-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When i915_gem_retire_requests_ring calls i915_gem_request_remove_from_client, the client_list for that request may already be removed in i915_gem_release. So we may call twice list_del(&request->client_list), resulting in an oops like this report: [126167.230394] BUG: unable to handle kernel paging request at 00100104 [126167.230699] IP: [<f8c2ce44>] i915_gem_retire_requests_ring+0xd4/0x240 [i915] [126167.231042] *pdpt = 00000000314c1001 *pde = 0000000000000000 [126167.231314] Oops: 0002 [#1] SMP [126167.231471] last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT1/current_now [126167.231901] Modules linked in: snd_seq_dummy nls_utf8 isofs btrfs zlib_deflate libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs exportfs reiserfs cryptd aes_i586 aes_generic binfmt_misc vboxnetadp vboxnetflt vboxdrv parport_pc ppdev snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep arc4 snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq uvcvideo videodev snd_timer snd_seq_device joydev iwlagn iwlcore mac80211 snd cfg80211 soundcore i915 drm_kms_helper snd_page_alloc psmouse drm serio_raw i2c_algo_bit video lp parport usbhid hid sky2 sdhci_pci ahci sdhci libahci [126167.232018] [126167.232018] Pid: 1101, comm: Xorg Not tainted 2.6.38-6-generic-pae #34-Ubuntu Gateway MC7833U / [126167.232018] EIP: 0060:[<f8c2ce44>] EFLAGS: 00213246 CPU: 0 [126167.232018] EIP is at i915_gem_retire_requests_ring+0xd4/0x240 [i915] [126167.232018] EAX: 00200200 EBX: f1ac25b0 ECX: 00000040 EDX: 00100100 [126167.232018] ESI: f1a2801c EDI: e87fc060 EBP: ef4d7dd8 ESP: ef4d7db0 [126167.232018] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [126167.232018] Process Xorg (pid: 1101, ti=ef4d6000 task=f1ba6500 task.ti=ef4d6000) [126167.232018] Stack: [126167.232018] f1a28000 f1a2809c f1a28094 0058bd97 f1aa2400 f1a2801c 0058bd7b 0058bd85 [126167.232018] f1a2801c f1a28000 ef4d7e38 f8c2e995 ef4d7e30 ef4d7e60 c14d1ebc f6b3a040 [126167.232018] f1522cc0 000000db 00000000 f1ba6500 ffffffa1 00000000 00000001 f1a29214 [126167.232018] Call Trace: Unfortunately the call trace reported was cut, but looking at debug symbols the crash is at __list_del, when probably list_del is called twice on the same request->client_list, as the dereferenced value is LIST_POISON1 + 4, and by looking more at the debug symbols before list_del call it should have being called by i915_gem_request_remove_from_client And as I can see in the code, it seems we indeed have the possibility to remove a request->client_list twice, which would cause the above, because we do list_del(&request->client_list) on both i915_gem_request_remove_from_client and i915_gem_release As Chris Wilson pointed out, it's indeed the case: "(...) I had thought that the actual insertion/deletion was serialised under the struct mutex and the intention of the spinlock was to protect the unlocked list traversal during throttling. However, I missed that i915_gem_release() is also called without struct mutex and so we do need the double check for i915_gem_request_remove_from_client()." This change does the required check to avoid the duplicate remove of request->client_list. Bugzilla: http://bugs.launchpad.net/bugs/733780 Cc: stable@kernel.org # 2.6.38 Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915: skip redundant operations whilst enabling pipes and planesChris Wilson2011-03-23
| | | | | | | | | | | | | | | | If the pipe or plane is already enabled, then we do not need to enable it again and can skip the delay. Similarly if it is already disabled when we want to disable it, we can also skip it. This fixes a regression from b24e717988, which caused the LVDS output on one PineView machine to become corrupt after changing orientation several times. References: https://bugs.freedesktop.org/show_bug.cgi?id=34601 Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com> Tested-by: mengmeng.meng@intel.com
* drm/i915: Remove surplus POSTING_READs before wait_for_vblankChris Wilson2011-03-23
| | | | | | | | | | | ... as wait_for_vblank (and friends) will do a flush of the MMIO writes anyway. References: https://bugs.freedesktop.org/show_bug.cgi?id=34601 Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* drm/kernel: vblank wait on crtc > 1Ilija Hadzic2011-03-20
| | | | | | | | | | | | | | | | | | | | | | Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds the capability to wait on vblank events for CRTCs that are greater than 1 and thus cannot be represented with primary/secondary flags in the legacy interface. It was discussed on the dri-devel list in these two threads: http://lists.freedesktop.org/archives/dri-devel/2011-March/009009.html http://lists.freedesktop.org/archives/dri-devel/2011-March/009025.html This patch extends the interface to drm_wait_vblank ioctl so that crtc>1 can be represented. It also adds a new capability to drm_getcap ioctl so that the user space can check whether the new interface to drm_wait_vblank is supported (and fall back to the legacy interface if not) Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com> Reviewed-by: Mario Kleiner <mario.kleiner at tuebingen.mpg.de> Acked-by: Mario Kleiner <mario.kleiner at tuebingen.mpg.de> Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Tested-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Fix use-after-free in drm_gem_vm_close()Chris Wilson2011-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As we may release the last reference, we need to store the device in a local variable in order to unlock afterwards. [ 60.140768] BUG: unable to handle kernel paging request at 6b6b6b9f [ 60.140973] IP: [<c1536d11>] __mutex_unlock_slowpath+0x5a/0x111 [ 60.141014] *pdpt = 0000000024a54001 *pde = 0000000000000000 [ 60.141014] Oops: 0002 [#1] PREEMPT SMP [ 60.141014] last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/PNP0C0A:00/power_supply/BAT0/voltage_now [ 60.141014] Modules linked in: uvcvideo ath9k pegasus ath9k_common ath9k_hw hid_egalax ath3k joydev asus_laptop sparse_keymap battery input_polldev [ 60.141014] [ 60.141014] Pid: 771, comm: meego-ux-daemon Not tainted 2.6.37.2-7.1 #1 EXOPC EXOPG06411/EXOPG06411 [ 60.141014] EIP: 0060:[<c1536d11>] EFLAGS: 00010046 CPU: 0 [ 60.141014] EIP is at __mutex_unlock_slowpath+0x5a/0x111 [ 60.141014] EAX: 00000100 EBX: 6b6b6b9b ECX: e9b4a1b0 EDX: e4a4e580 [ 60.141014] ESI: db162558 EDI: 00000246 EBP: e480be50 ESP: e480be44 [ 60.141014] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 [ 60.141014] Process meego-ux-daemon (pid: 771, ti=e480a000 task=e9b4a1b0 task.ti=e480a000) [ 60.141014] Stack: [ 60.141014] e4a4e580 db162558 f5a2f838 e480be58 c1536dd0 e480be68 c125ab1b db162558 [ 60.141014] db1624e0 e480be78 c10ba071 db162558 f760241c e480be94 c10bb0bc 000155fe [ 60.141014] f760241c f5a2f838 f5a2f8c8 00000000 e480bea4 c1037c24 00000000 f5a2f838 [ 60.141014] Call Trace: [ 60.141014] [<c1536dd0>] ? mutex_unlock+0x8/0xa [ 60.141014] [<c125ab1b>] ? drm_gem_vm_close+0x39/0x3d [ 60.141014] [<c10ba071>] ? remove_vma+0x2d/0x58 [ 60.141014] [<c10bb0bc>] ? exit_mmap+0x126/0x13f [ 60.141014] [<c1037c24>] ? mmput+0x37/0x9a [ 60.141014] [<c10d450d>] ? exec_mmap+0x178/0x19c [ 60.141014] [<c1537f85>] ? _raw_spin_unlock+0x1d/0x36 [ 60.141014] [<c10d4eb0>] ? flush_old_exec+0x42/0x75 [ 60.141014] [<c1104442>] ? load_elf_binary+0x32a/0x922 [ 60.141014] [<c10d3f76>] ? search_binary_handler+0x200/0x2ea [ 60.141014] [<c10d3ecf>] ? search_binary_handler+0x159/0x2ea [ 60.141014] [<c1104118>] ? load_elf_binary+0x0/0x922 [ 60.141014] [<c10d56b2>] ? do_execve+0x1ff/0x2e6 [ 60.141014] [<c100970e>] ? sys_execve+0x2d/0x55 [ 60.141014] [<c1002a5a>] ? ptregs_execve+0x12/0x18 [ 60.141014] [<c10029dc>] ? sysenter_do_call+0x12/0x3c [ 60.141014] [<c1530000>] ? init_centaur+0x9c/0x1ba [ 60.141014] Code: c1 00 75 0f ba 38 01 00 00 b8 8c 3a 6c c1 e8 cc 2e b0 ff 9c 58 8d 74 26 00 89 c7 fa 90 8d 74 26 00 e8 d2 b4 b2 ff b8 00 01 00 00 <f0> 66 0f c1 43 04 38 e0 74 07 f3 90 8a 43 04 eb f5 83 3d 64 ef [ 60.141014] EIP: [<c1536d11>] __mutex_unlock_slowpath+0x5a/0x111 SS:ESP 0068:e480be44 [ 60.141014] CR2: 000000006b6b6b9f Reported-by: Rusty Lynch <rusty.lynch@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon: fixup refcounts in radeon dumb create ioctl.Dave Airlie2011-03-16
| | | | | | | This was using old gem refcounting methods, fix it to be the same as the normal create ioctl. Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: radeon: *_cs_packet_parse_vline() cleanupPaul Bolle2011-03-16
| | | | | | | | Simplify the way the return value is set a number of times (mostly on error). Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Dave Airlie <airlied@redhat.com>
* radeon: merge list_del()/list_add_tail() to list_move_tail()Nicolas Kaiser2011-03-16
| | | | | | | Merge list_del() + list_add_tail() to list_move_tail(). Signed-off-by: Nicolas Kaiser <nikai@nikai.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
* Merge commit '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into drm-core-nextDave Airlie2011-03-15
|\ | | | | | | | | | | | | | | | | | | This commit changed an internal radeon structure, that meant a new driver in -next had to be fixed up, merge in the commit and fix up the driver. Also fixes a trivial nouveau merge. Conflicts: drivers/gpu/drm/nouveau/nouveau_mem.c
| * drm/radeon: fix problem with changing active VRAM size. (v2)Dave Airlie2011-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So we used to use lpfn directly to restrict VRAM when we couldn't access the unmappable area, however this was removed in 93225b0d7bc030f4a93165347a65893685822d70 as it also restricted the gtt placements. However it was only later noticed that this broke on some hw. This removes the active_vram_size, and just explicitly sets it when it changes, TTM/drm_mm will always use the real_vram_size, and the active vram size will change the TTM size used for lpfn setting. We should re-work the fpfn/lpfn to per-placement at some point I suspect, but that is too late for this kernel. Hopefully this addresses: https://bugs.freedesktop.org/show_bug.cgi?id=35254 v2: fix reported useful VRAM size to userspace to be correct. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/radeon: fix page flipping hangs on r300/r400Dave Airlie2011-03-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We've been getting reports of complete system lockups with rv3xx hw on AGP and PCIE when running gnome-shell or kwin with compositing. It appears the hw really doesn't like setting these registers while stuff is running, this moves the setting of the registers into the modeset since they aren't required to be changed anywhere else. fixes: https://bugs.freedesktop.org/show_bug.cgi?id=35183 Reported-and-tested-by: Álmos <aaalmosss@gmail.com Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/radeon: add pageflip hooks for fusionDave Airlie2011-03-11
| | | | | | | | | | | | | | | | | | | | | | | | Looks like these got passed over with both being merged at the same time but not quite meeting in the middle. should fix: https://bugs.freedesktop.org/show_bug.cgi?id=34137 along with Michael's phoronix article. Reported-by: Chi-Thanh Christopher Nguyen Article-written-by: Michael Larabel @ phoronix Signed-off-by: Dave Airlie <airlied@redhat.com>
| * Merge branch 'media_fixes' of ↵Linus Torvalds2011-03-10
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6 * 'media_fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6: [media] mantis_pci: remove asm/pgtable.h include [media] tda829x: fix regression in probe functions [media] mceusb: don't claim multifunction device non-IR parts [media] nuvoton-cir: fix wake from suspend [media] cx18: Add support for Hauppauge HVR-1600 models with s5h1411 [media] ivtv: Fix corrective action taken upon DMA ERR interrupt to avoid hang [media] cx25840: fix probing of cx2583x chips [media] cx23885: Remove unused 'err:' labels to quiet compiler warning [media] cx23885: Revert "Check for slave nack on all transactions" [media] DiB7000M: add pid filtering [media] Fix sysfs rc protocol lookup for rc-5-sz [media] au0828: fix VBI handling when in V4L2 streaming mode [media] ir-raw: Properly initialize the IR event (BZ#27202) [media] s2255drv: firmware re-loading changes [media] Fix double free of video_device in mem2mem_testdev [media] DM04/QQBOX memcpy to const char fix
| | * [media] mantis_pci: remove asm/pgtable.h includeArnaud Patard (Rtp)2011-03-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mantis_pci.c is including asm/pgtable.h and it's leading to a build failure on arm. It has been noticed here : https://buildd.debian.org/fetch.cgi?pkg=linux-2.6&arch=armel&ver=2.6.38~rc6-1~experimental.1&stamp=1298430952&file=log&as=raw As this header doesn't seem to be used, I'm removing it. I've build tested it with arm and x86. Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * [media] tda829x: fix regression in probe functionsJarod Wilson2011-03-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 567aba0b7997dad5fe3fb4aeb174ee9018df8c5b, the probe address for tda8290_probe and tda8295_probe was hard-coded to 0x4b, which is the default i2c address for those devices, but its possible for the device to be at an alternate address, 0x42, which is the case for the HVR-1950. If we probe the wrong address, probe fails and we have a non-working device. We have the actual address passed into the function by way of i2c_props, we just need to use it. Also fix up some copy/paste comment issues and streamline debug spew a touch. Verified to restore my HVR-1950 to full working order. Special thanks to Ken Bass for reporting the issue in the first place, and to both he and Gary Buhrmaster for aiding in debugging and analysis of the problem. Reported-by: Ken Bass <kbass@kenbass.com> Tested-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * [media] mceusb: don't claim multifunction device non-IR partsJarod Wilson2011-03-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's a Realtek combo card reader and IR receiver device with multiple usb interfaces on it. The mceusb driver is incorrectly grabbing all of them. This change should make it bind to only interface 2 (patch based on lsusb output on the linux-media list from Lucian Muresan). Tested regression-free with the six mceusb devices I have myself. Reported-by: Patrick Boettcher <pboettcher@kernellabs.com> Reported-by: Lucian Muresan <lucianm@users.sourceforge.net> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * [media] nuvoton-cir: fix wake from suspendJarod Wilson2011-03-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The CIR Wake FIFO is 67 bytes long, but the stock remote appears to only populate 65 of them. Limit comparison to 65 bytes, and wake from suspend works a whole lot better (it wasn't working at all for most folks). Fix based on comparison with the old lirc_wb677 driver from Nuvoton, debugging and testing done by Dave Treacy by way of the lirc mailing list. Reported-by: Dave Treacy <davetreacy@gmail.com> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * [media] cx18: Add support for Hauppauge HVR-1600 models with s5h1411Devin Heitmueller2011-03-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The newest variants of the HVR-1600 have an s5h1411/tda18271 for the digital frontend. Add support for these boards. Thanks to Hauppauge Computer Works for providing sample hardware. [awalls@md.metrocast.net: Changed an additional log message to clarify for the end user that the driver is defaulting to an original HVR-1600 for unknown model numbers.] Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Andy Walls <awalls@md.metrocast.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * [media] ivtv: Fix corrective action taken upon DMA ERR interrupt to avoid hangMichael2011-03-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After upgrading the kernel from stock Ubuntu 7.10 to 10.04, with no hardware changes, I started getting the dreaded DMA TIMEOUT errors, followed by inability to encode until the machine was rebooted. I came across a post from Andy in March (http://www.gossamer-threads.com/lists/ivtv/users/40943#40943) where he speculates that perhaps the corrective actions being taken after a DMA ERROR are not sufficient to recover the situation. After some testing I suspect that this is indeed the case, and that in fact the corrective action may be what hangs the card's DMA engine, rather than the original error. Specifically these DMA ERROR IRQs seem to present with two different values in the IVTV_REG_DMASTATUS register: 0x11 and 0x13. The current corrective action is to clear that status register back to 0x01 or 0x03, and then issue the next DMA request. In the case of a 0x13 this seems to result in a minor glitch in the encoded stream due to the failed transfer that was not retried, but otherwise things continue OK. In the case of a 0x11 the card's DMA write engine is never heard from again, and a DMA TIMEOUT follows shortly after. 0x11 is the killer. I suspect that the two cases need to be handled differently. The difference is in bit 1 (0x02), which is set when the error is about to be successfully recovered, and clear when things are about to go bad. Bit 1 of DMASTATUS is described differently in different places either as a positive "write finished", or an inverted "write busy". If we take the first definition, then when an error arises with state 0x11, it means that the write did not complete. It makes sense to start a new transfer, as in the current code. But if we take the second definition, then 0x11 means "an error but the write engine is still busy". Trying to feed it a new transfer in this situation might not be a good idea. As an experiment, I added code to ignore the DMA ERROR IRQ if DMASTATUS is 0x11. I.e., don't start a new transfer, don't clear our flags, etc. The hope was that the card would complete the transfer and issue a ENC DMA COMPLETE, either successfully or with an error condition there. However the card still hung. The only remaining corrective action being taken with a 0x11 status was then the write back to the status register to clear the error, i.e. DMASTATUS = DMASTATUS & ~3. This would have the effect of clearing the error bit 4, while leaving the lower bits indicating DMA write busy. Strangely enough, removing this write to the status register solved the problem! If the DMA ERROR IRQ with DMASTATUS=0x11 is completely ignored, with no corrective action at all, then the card will complete the transfer and issue a new IRQ. If the status register is written to when it has the value 0x11, then the DMA engine hangs. Perhaps it's illegal to write to DMASTATUS while the read or write busy bit is set? At any rate, it appears that the current corrective action is indeed making things worse rather than better. I put together a patch that modifies ivtv_irq_dma_err to do the following: - Don't write back to IVTV_REG_DMASTATUS. - If write-busy is asserted, leave the card alone. Just extend the timeout slightly. - If write-busy is de-asserted, retry the current transfer. This has completely fixed my DMA TIMEOUT woes. DMA ERR events still occur, but now they seem to be correctly handled. 0x11 events no longer hang the card, and 0x13 events no longer result in a glitch in the stream, as the failed transfer is retried. I'm happy. I've inlined the patch below in case it is of interest. As described above, I have a theory about why it works (based on a different interpretation of bit 1 of DMASTATUS), but I can't guarantee that my theory is correct. There may be another explanation, or it may be a fluke. Maybe ignoring that IRQ entirely would be equally effective? Maybe the status register read/writeback sequence is race condition if the card changes it in the mean time? Also as I am using a PVR-150 only, I have not been able to test it on other cards, which may be especially relevant for 350s that support concurrent decoding. Hopefully the patch does not break the DMA READ path. Mike [awalls@md.metrocast.net: Modified patch to add a verbose comment, make minor brace reformats, and clear the error flags in the IVTV_REG_DMASTATUS iff both read and write DMA were not in progress. Mike's conjecture about a race condition with the writeback is correct; it can confuse the DMA engine.] [Comment and analysis from the ML post by Michael <mike@rsy.com>] Signed-off-by: Andy Walls <awalls@md.metrocast.net> Cc: stable@kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * [media] cx25840: fix probing of cx2583x chipsSven Barth2011-03-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the probing of cx2583x chips, because two controls were clustered that are not created for these chips. This regression was introduced in 2.6.36. Signed-off-by: Sven Barth <pascaldragon@googlemail.com> Signed-off-by: Andy Walls <awalls@md.metrocast.net> Cc: stable@kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * [media] cx23885: Remove unused 'err:' labels to quiet compiler warningAndy Walls2011-03-02
| | | | | | | | | | | | | | | | | | | | | | | | The previous revert-commit, that affected cx23885-i2c.c, left some unused labels that the compiler griped about. Clean them up. Signed-off-by: Andy Walls <awalls@md.metrocast.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * [media] cx23885: Revert "Check for slave nack on all transactions"Andy Walls2011-03-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 44835f197bf1e3f57464f23dfb239fef06cf89be. With the CX23885 hardware I2C master, checking for I2C slave ACK/NAK is not valid when the I2C_EXTEND or I2C_NOSTOP bits are set. Revert the commit that checks for I2C slave ACK/NAK on all transactions, so that XC5000 tuners work with the CX23885 again. Thanks go to Mark Zimmerman for reporting and bisecting this problem. Bisected-by: Mark Zimmerman <markzimm@frii.com> Reported-by: Mark Zimmerman <markzimm@frii.com> Signed-off-by: Andy Walls <awalls@md.metrocast.net> Cc: stable@kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * [media] DiB7000M: add pid filteringOlivier Grenie2011-03-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the pid filtering for the dib7000M demod. It also corrects the pid filtering for the dib7700 based board. It should prevent an oops, when using dib7700p based board. References: https://bugzilla.novell.com/show_bug.cgi?id=644807 Signed-off-by: Olivier Grenie <olivier.grenie@dibcom.fr> Signed-off-by: Patrick Boettcher <patrick.boettcher@dibcom.fr> Tested-by: Pavel SKARKA <paul.sp@seznam.cz> Cc: stable@kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * [media] Fix sysfs rc protocol lookup for rc-5-szAntti Seppälä2011-03-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the current matching rules the lookup for rc protocol named rc-5-sz matches with "rc-5" before finding "rc-5-sz". Thus one is able to never enable/disable the rc-5-sz protocol via sysfs. Fix the lookup to require an exact match which allows the manipulation of sz protocol. Signed-off-by: Antti Seppälä <a.seppala@gmail.com> Cc: stable@kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * [media] au0828: fix VBI handling when in V4L2 streaming modeDevin Heitmueller2011-02-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | au0828: fix VBI handling when in V4L2 streaming mode It turns up V4L2 streaming mode (a.k.a mmap) was broken for VBI streaming. This was causing libzvbi to fall back to V4L1 capture mode, and is a blatent violation of the V4L2 specification. Make the implementation work properly in this mode. Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * [media] ir-raw: Properly initialize the IR event (BZ#27202)Mauro Carvalho Chehab2011-02-02
| | | | | | | | | | | | | | | | | | | | | | | | Changeset 4651918a4afdd49bdea21d2f919b189ef17a6399 changed the way events are stored. However, it forgot to fix ir_raw_event_store_edge() to work with the new way. Due to that, the decoders will likely do bad things. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * [media] s2255drv: firmware re-loading changessensoray-dev2011-02-02
| | | | | | | | | | | | | | | | | | | | | Change for firmware re-loading and updated firmware versions. Signed-off-by: Dean Anderson <linux-dev@sensoray.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * [media] Fix double free of video_device in mem2mem_testdevPawel Osciak2011-02-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | video_device is already being freed in video_device.release callback on release. Signed-off-by: Pawel Osciak <pawel@osciak.com> Reported-by: Roland Kletzing <devzero@web.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * [media] DM04/QQBOX memcpy to const char fixMalcolm Priestley2011-02-02
| | | | | | | | | | | | | | | | | | | | | | | | Driver Version v1.75 Kernel oops appears in 2.6.37-rc8 in lme_firmware_switch because of a memcpy to a const char. Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | ipmi: Fix IPMI errors due to timing problemsDoe, YiCheng2011-03-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes an issue in OpenIPMI module where sometimes an ABORT command is sent after sending an IPMI request to BMC causing the IPMI request to fail. Signed-off-by: YiCheng Doe <yicheng.doe@hp.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> Acked-by: Tom Mingarelli <thomas.mingarelli@hp.com> Tested-by: Andy Cress <andy.cress@us.kontron.com> Tested-by: Mika Lansirine <Mika.Lansirinne@stonesoft.com> Tested-by: Brian De Wolf <bldewolf@csupomona.edu> Cc: Jean Michel Audet <Jean-Michel.Audet@ca.Kontron.com> Cc: Jozef Sudelsky <jozef.sudolsky@elbiahosting.sk> Acked-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| * | Merge branch 'for-linus' of ↵Linus Torvalds2011-03-10
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6: fs/dcache: allow d_obtain_alias() to return unhashed dentries Check for immutable/append flag in fallocate path sysctl: the include of rcupdate.h is only needed in the kernel fat: fix d_revalidate oopsen on NFS exports jfs: fix d_revalidate oopsen on NFS exports ocfs2: fix d_revalidate oopsen on NFS exports gfs2: fix d_revalidate oopsen on NFS exports fuse: fix d_revalidate oopsen on NFS exports ceph: fix d_revalidate oopsen on NFS exports reiserfs xattr ->d_revalidate() shouldn't care about RCU /proc/self is never going to be invalidated...
| | * | fs/dcache: allow d_obtain_alias() to return unhashed dentriesJ. Bruce Fields2011-03-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Without this patch, inodes are not promptly freed on last close of an unlinked file by an nfs client: client$ mount -tnfs4 server:/export/ /mnt/ client$ tail -f /mnt/FOO ... server$ df -i /export server$ rm /export/FOO (^C the tail -f) server$ df -i /export server$ echo 2 >/proc/sys/vm/drop_caches server$ df -i /export the df's will show that the inode is not freed on the filesystem until the last step, when it could have been freed after killing the client's tail -f. On-disk data won't be deallocated either, leading to possible spurious ENOSPC. This occurs because when the client does the close, it arrives in a compound with a putfh and a close, processed like: - putfh: look up the filehandle.  The only alias found for the inode will be DCACHE_UNHASHED alias referenced by the filp this, so it creates a new DCACHE_DISCONECTED dentry and returns that instead. - close: closes the existing filp, which is destroyed immediately by dput() since it's DCACHE_UNHASHED. - end of the compound: release the reference to the current filehandle, and dput() the new DCACHE_DISCONECTED dentry, which gets put on the unused list instead of being destroyed immediately. Nick Piggin suggested fixing this by allowing d_obtain_alias to return the unhashed dentry that is referenced by the filp, instead of making it create a new dentry. Leave __d_find_alias() alone to avoid changing behavior of other callers. Also nfsd doesn't need all the checks of __d_find_alias(); any dentry, hashed or unhashed, disconnected or not, should work. Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
| | * | Check for immutable/append flag in fallocate pathMarco Stornelli2011-03-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the fallocate path the kernel doesn't check for the immutable/append flag. It's possible to have a race condition in this scenario: an application open a file in read/write and it does something, meanwhile root set the immutable flag on the file, the application at that point can call fallocate with success. In addition, we don't allow to do any unreserve operation on an append only file but only the reserve one. Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
| | * | sysctl: the include of rcupdate.h is only needed in the kernelStephen Rothwell2011-03-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes this built error: include/linux/sysctl.h:28: included file 'linux/rcupdate.h' is not exported Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
| | * | fat: fix d_revalidate oopsen on NFS exportsAl Viro2011-03-10
| | | | | | | | | | | | | | | | | | | | | | | | can't blindly check nd->flags in ->d_revalidate() Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
| | * | jfs: fix d_revalidate oopsen on NFS exportsAl Viro2011-03-10
| | | | | | | | | | | | | | | | | | | | | | | | can't blindly check nd->flags in ->d_revalidate() Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
| | * | ocfs2: fix d_revalidate oopsen on NFS exportsAl Viro2011-03-10
| | | | | | | | | | | | | | | | | | | | | | | | can't blindly check nd->flags in ->d_revalidate() Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
| | * | gfs2: fix d_revalidate oopsen on NFS exportsAl Viro2011-03-10
| | | | | | | | | | | | | | | | | | | | | | | | can't blindly check nd->flags in ->d_revalidate() Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
| | * | fuse: fix d_revalidate oopsen on NFS exportsAl Viro2011-03-10
| | | | | | | | | | | | | | | | | | | | | | | | can't blindly check nd->flags in ->d_revalidate() Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
| | * | ceph: fix d_revalidate oopsen on NFS exportsAl Viro2011-03-10
| | | | | | | | | | | | | | | | | | | | | | | | can't blindly check nd->flags in ->d_revalidate() Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
| | * | reiserfs xattr ->d_revalidate() shouldn't care about RCUAl Viro2011-03-10
| | | | | | | | | | | | | | | | | | | | | | | | ... it returns an error unconditionally Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
| | * | /proc/self is never going to be invalidated...Al Viro2011-03-10
| | | | | | | | | | | | | | | | Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
| * | | Merge branch 'x86-fixes-for-linus' of ↵Linus Torvalds2011-03-10
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86, UV: Initialize the broadcast assist unit base destination node id properly x86, numa: Fix numa_emulation code with memory-less node0 x86, build: Make sure mkpiggy fails on read error
| | * | | x86, UV: Initialize the broadcast assist unit base destination node id properlyCliff Wickman2011-03-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The BAU's initialization of the broadcast description header is lacking the coherence domain (high bits) in the nasid. This causes a catastrophic system failure when running on a system with multiple coherence domains. Signed-off-by: Cliff Wickman <cpw@sgi.com> LKML-Reference: <E1PxKBB-0005F0-3U@eag09.americas.sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>