[PATCH v2 3/4] drm/exynos: added userptr feature.
Hi Dave, 2012. 4. 25. ?? 7:15 Dave Airlie ??: > On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae wrote: >> this feature could be used to use memory region allocated by malloc() in user >> mode and mmaped memory region allocated by other memory allocators. userptr >> interface can identify memory type through vm_flags value and would get >> pages or page frame numbers to user space appropriately. > > Is there anything to stop the unpriviledged userspace driver locking > all the RAM in the machine inside userptr? > you mean that there is something that it can stop user space driver locking some memory region of RAM? and if any user space driver locked some region then anyone on user space can't access the region? could you please tell me about your concerns in more detail so that we can solve the issue? I guess you mean that any user level driver such as specific EGL library can allocate some memory region and also lock the region so that other user space applications can't access the region until rendering is completed by hw accelerator such as 2d/3d core or opposite case. actually, this feature has already been used by v4l2 so I didn't try to consider we could face with any problem with this and I've got a feeling maybe there is something I missed so I'd be happy for you or anyone give me any advices. Thanks, Inki Dae. > seems like a very bad plan, I know TTM has code to address this sort > of things with limits. > > Dave. > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Intel-gfx] [PATCH] drm/i915: enable semaphores on gen6 if dmar is not active
On Fri, Apr 27, 2012 at 07:54:59PM +0200, Daniel Vetter wrote: > On Tue, Apr 17, 2012 at 11:31:00AM +0200, Daniel Vetter wrote: > > On Tue, Apr 03, 2012 at 12:32:05AM +0200, Daniel Vetter wrote: > > > On Mon, Apr 02, 2012 at 02:44:14PM -0700, Andrew Lutomirski wrote: > > > > On Mon, Apr 2, 2012 at 1:52 PM, Daniel Vetter > > > > wrote: > > > > > On Mon, Apr 02, 2012 at 01:45:39PM -0700, Andrew Lutomirski wrote: > > > > I've had a hard time reproducing the problems lately. The > > > > unconditional instant hard hang went away a few months ago, I think. > > > > I'll give it another shot when I get home to that machine. > > > > > > Well, I've managed to kill my machine shortly after login with semaphores, > > > rc6 and dmar enabled. It hasn't died in the same configuration after a few > > > hours of light usage (in my case that seems to be the best killer) with > > > dmar disabled for just the gpu. > > > > > > So if you can give your machine some serious beating with the different > > > options, that's really great. > > > > Do you already have some preliminary results or has your machine not yet > > died with this patch applied? > > Ping? Even more ping. I'd really like to merge this, and a tested-by from you would be awesome for this. Otherwise I'll just merge and we'll wait if it actually blows up. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
Linux 3.4-rc4
On 2012-05-04 10:20 +0100, Dave Airlie wrote: > >> > >> FWIW, for me EDID failure on new kernels is 100% reproducible, and there > >> are no such checksum errors in the log. ?It's just missing. > >> > >> > Just a crazy thought, but didn't we change some timings related to > >> > EDID retrieval? To make it faster. > >> > >> OK, this time bisecting started off relatively smoothly (doing the same > >> "backwards" bisect on the branch-o-reverts as last time), but then my > >> disk died halfway through... > > [...] > > > > OK, system is back online and I finished the bisection. ?The commit that > > broke it for me is the following, and reverting it on top of 3.3.4 + the > > "make VGA work at all" patch fixes this particular issue for me. > > > Can you test with the attached patch? its a revert mostly of Ben's patch, and > he says with the i2c core change stuff is working for him again. Yup, this one seems to work on top of Linus' master. Thanks, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
[PATCH v2 3/4] drm/exynos: added userptr feature.
On Sat, May 5, 2012 at 11:19 AM, wrote: > Hi Dave, > > 2012. 4. 25. ?? 7:15 Dave Airlie ??: > >> On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae wrote: >>> this feature could be used to use memory region allocated by malloc() in >>> user >>> mode and mmaped memory region allocated by other memory allocators. userptr >>> interface can identify memory type through vm_flags value and would get >>> pages or page frame numbers to user space appropriately. >> >> Is there anything to stop the unpriviledged userspace driver locking >> all the RAM in the machine inside userptr? >> > > you mean that there is something that it can stop user space driver locking > some memory region of RAM? and if any user space driver locked some region > then anyone on user space can't access the region? could you please tell me > about your concerns in more detail so that we can solve the issue? I guess > you mean that any user level driver such as specific EGL library can allocate > some memory region and also lock the region so that other user space > applications can't access the region until rendering is completed by hw > accelerator such as 2d/3d core or opposite case. > > actually, this feature has already been used by v4l2 so I didn't try to > consider we could face with any problem with this and I've got a feeling > maybe there is something I missed so I'd be happy for you or anyone give me > any advices. Well v4l get to make their own bad design decisions. The problem is if an unprivledged users accessing the drm can lock all the pages it allocates into memory, by passing them to the kernel as userptrs., thus bypassing the swap and blocking all other users on the system. Dave.
[Bug 43207] radeon driver on HD6570 shows pixel noise
https://bugzilla.kernel.org/show_bug.cgi?id=43207 --- Comment #1 from Vladislav Tcendrovskii 2012-05-05 09:07:30 --- Created an attachment (id=73191) --> (https://bugzilla.kernel.org/attachment.cgi?id=73191) screenshot of problem -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 43207] New: radeon driver on HD6570 shows pixel noise
https://bugzilla.kernel.org/show_bug.cgi?id=43207 Summary: radeon driver on HD6570 shows pixel noise Product: Drivers Version: 2.5 Kernel Version: 3.* Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: ccvs at mail.ru Regression: No Videocard HD6570. when I call "modprobe radeon", I see pixel noise on the screen and, if try more, it's possible to see some characters from framebuffer console. dmesg shows, that firmware loads right without firmware module loads, but it's useless, besause X driver needs KMS, which is disabled without firmware -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #54 from Alexandre Demers 2012-05-04 21:21:18 PDT --- On latest git (3cd7bee48f7caf7850ea64d40f43875d4c975507), in src/gallium/drivers/r600/r66_hw_context.c, on line 194, shouldn't it be: - int offset + unsigned offset Also, at line 1259, I'm not quite sure why it is shifted by 2. Most of the time, offset is usually shifted by 8. Just looking through the code to see if something could have been missed... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43207] radeon driver on HD6570 shows pixel noise
https://bugzilla.kernel.org/show_bug.cgi?id=43207 --- Comment #1 from Vladislav Tcendrovskii c...@mail.ru 2012-05-05 09:07:30 --- Created an attachment (id=73191) -- (https://bugzilla.kernel.org/attachment.cgi?id=73191) screenshot of problem -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/exynos: added userptr feature.
Hi Dave, 2012. 4. 25. 오후 7:15 Dave Airlie airl...@gmail.com 작성: On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae inki@samsung.com wrote: this feature could be used to use memory region allocated by malloc() in user mode and mmaped memory region allocated by other memory allocators. userptr interface can identify memory type through vm_flags value and would get pages or page frame numbers to user space appropriately. Is there anything to stop the unpriviledged userspace driver locking all the RAM in the machine inside userptr? you mean that there is something that it can stop user space driver locking some memory region of RAM? and if any user space driver locked some region then anyone on user space can't access the region? could you please tell me about your concerns in more detail so that we can solve the issue? I guess you mean that any user level driver such as specific EGL library can allocate some memory region and also lock the region so that other user space applications can't access the region until rendering is completed by hw accelerator such as 2d/3d core or opposite case. actually, this feature has already been used by v4l2 so I didn't try to consider we could face with any problem with this and I've got a feeling maybe there is something I missed so I'd be happy for you or anyone give me any advices. Thanks, Inki Dae. seems like a very bad plan, I know TTM has code to address this sort of things with limits. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/exynos: added userptr feature.
On Sat, May 5, 2012 at 11:19 AM, daei...@gmail.com wrote: Hi Dave, 2012. 4. 25. 오후 7:15 Dave Airlie airl...@gmail.com 작성: On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae inki@samsung.com wrote: this feature could be used to use memory region allocated by malloc() in user mode and mmaped memory region allocated by other memory allocators. userptr interface can identify memory type through vm_flags value and would get pages or page frame numbers to user space appropriately. Is there anything to stop the unpriviledged userspace driver locking all the RAM in the machine inside userptr? you mean that there is something that it can stop user space driver locking some memory region of RAM? and if any user space driver locked some region then anyone on user space can't access the region? could you please tell me about your concerns in more detail so that we can solve the issue? I guess you mean that any user level driver such as specific EGL library can allocate some memory region and also lock the region so that other user space applications can't access the region until rendering is completed by hw accelerator such as 2d/3d core or opposite case. actually, this feature has already been used by v4l2 so I didn't try to consider we could face with any problem with this and I've got a feeling maybe there is something I missed so I'd be happy for you or anyone give me any advices. Well v4l get to make their own bad design decisions. The problem is if an unprivledged users accessing the drm can lock all the pages it allocates into memory, by passing them to the kernel as userptrs., thus bypassing the swap and blocking all other users on the system. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: broken nouveau dependency on power supply
Hello Benjamin,
Sorry, it took me some time to get to it.
On Mon, Apr 02, 2012 at 01:53:23PM +1000, Benjamin Herrenschmidt wrote:
[...]
With CONFIG_POWER_SUPPLY=m nouveau built-in we get a build failure:
drivers/built-in.o: In function `.nouveau_pm_trigger':
(.text+0xa56e8): undefined reference to `.power_supply_is_system_supplied'
nouveau probably needs to depends on CONFIG_POWER_SUPPLY to force a module
build with the latter is =m
Ok, not that trivial...
The problem is more like POWER_SUPPLY should be a bool, not a tristate.
I see that nouveau already selects POWER_SUPPLY, but your points are
still valid. Let's make the power supply thing simple. I've applied
the following patch:
- - - -
[PATCH] power_supply: Make the core a boolean instead of a tristate
On Mon, Apr 02, 2012 at 01:53:23PM +1000, Benjamin Herrenschmidt wrote:
drivers/built-in.o: In function `.nouveau_pm_trigger':
(.text+0xa56e8): undefined reference to `.power_supply_is_system_supplied'
nouveau probably needs to depends on CONFIG_POWER_SUPPLY to force a module
build with the latter is =m
Ok, not that trivial...
The problem is more like POWER_SUPPLY should be a bool, not a tristate.
If you think about it: you don't want things like nouveau to depend on a
random subsystem like that, people will never get it. In fact,
POWER_SUPPLY provides empty inline stubs when not enabled, so that's
really designed to not have depends...
However that -cannot- work if POWER_SUPPLY is modular and the drivers
who use it are not.
The only fixes here that make sense I can think of
that don't also involve Kconfig horrors are:
- Ugly: in power_supply.h, use the extern variant if
defined(CONFIG_POWER_SUPPLY) ||
(defined(CONFIG_POWER_SUPPLY_MODULE) defined(MODULE))
IE. use the stub if power supply is a module and what is being built is
built-in. Of course that's not only ugly, it somewhat sucks from a user
perspective as the subsystem now exists but can't be used by some
drivers...
- Better: Just make the bloody thing a bool :-) The power supply
framework itself is small enough, just make it a boolean option and
avoid the problem entirely. The actual power supply sub drivers can
remain modular of course.
Suggested-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Signed-off-by: Anton Vorontsov cbouatmai...@gmail.com
---
drivers/power/Kconfig|2 +-
include/linux/power_supply.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 99dc29f..0c52a40 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -1,5 +1,5 @@
menuconfig POWER_SUPPLY
- tristate Power supply class support
+ bool Power supply class support
help
Say Y here to enable power supply class support. This allows
power supply (batteries, AC, USB) monitoring by userspace
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index fd17ae0..3b912be 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -212,7 +212,7 @@ extern void power_supply_changed(struct power_supply *psy);
extern int power_supply_am_i_supplied(struct power_supply *psy);
extern int power_supply_set_battery_charged(struct power_supply *psy);
-#if defined(CONFIG_POWER_SUPPLY) || defined(CONFIG_POWER_SUPPLY_MODULE)
+#ifdef CONFIG_POWER_SUPPLY
extern int power_supply_is_system_supplied(void);
#else
static inline int power_supply_is_system_supplied(void) { return -ENOSYS; }
--
1.7.9.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
