* Re: Using s3virge card in Sun Blade 2000
From: Francois Romieu @ 2011-01-06 20:42 UTC (permalink / raw)
To: Alex Buell; +Cc: David Miller, linux-fbdev, linux-kernel
In-Reply-To: <1294274029.24378.11.camel@lithium>
Hi Alex,
Alex Buell <alex.buell@munted.org.uk> :
[...]
> The above code seems to work, and crashes after this point:
>
> /* Identify chip type */
> par->chip = id->driver_data & CHIP_MASK;
> par->rev = vga_rcrt(par->vga_iobase, 0x2f);
> if (par->chip & CHIP_UNDECIDED_FLAG)
> par->chip = s3_identification(par->chip);
^^^^^^^^^ ?
Sorry for the obvious but you modified s3_identification() so that it
stops emitting vga_rcrt(NULL, ...), right ?
--
Ueimor
^ permalink raw reply
* Re: Using s3virge card in Sun Blade 2000
From: Alex Buell @ 2011-01-06 20:50 UTC (permalink / raw)
To: Francois Romieu; +Cc: David Miller, linux-fbdev, linux-kernel
In-Reply-To: <20110106204240.GA6361@electric-eye.fr.zoreil.com>
On Thu, 2011-01-06 at 21:42 +0100, Francois Romieu wrote:
> Alex Buell <alex.buell@munted.org.uk> :
> [...]
> > The above code seems to work, and crashes after this point:
> >
> > /* Identify chip type */
> > par->chip = id->driver_data & CHIP_MASK;
> > par->rev = vga_rcrt(par->vga_iobase, 0x2f);
> > if (par->chip & CHIP_UNDECIDED_FLAG)
> > par->chip = s3_identification(par->chip);
> ^^^^^^^^^ ?
> Sorry for the obvious but you modified s3_identification() so that it
> stops emitting vga_rcrt(NULL, ...), right ?
I must have missed that one - thank you for pointing that one out to me!
Regards
Alex
--
Tactical Nuclear Kittens
^ permalink raw reply
* Re: [RESEND #2] [PATCH v2] LEDS: Add output invertion option to
From: Andrew Morton @ 2011-01-06 21:04 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: Richard Purdie, linux-fbdev@vger.kernel.org, linux-kernel,
linux-omap@vger.kernel.org, Paul Mundt
In-Reply-To: <201012091441.51846.jkrzyszt@tis.icnet.pl>
On Thu, 9 Dec 2010 14:41:50 +0100
Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> wrote:
> This patch extends the LED backlight tirgger driver with an option that allows
> for inverting the trigger output polarity.
>
> With the invertion option provided, I (ab)use the backlight trigger for
> driving a LED that indicates LCD display blank condtition on my Amstrad Delta
> videophone. Since the machine has no dedicated power LED, it was not possible
> to distinguish if the display was blanked, or the machine was turned off,
> without touching it.
>
> The invert sysfs control is patterned after a similiar function of the GPIO
> trigger driver.
>
> Created and tested against linux-2.6.36-rc5 on Amstrad Delta.
> Retested on linux-2.6.37-rc4.
>
> Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
> Cc: Richard Purdie <rpurdie@rpsys.net>
> ---
>
> Resent because I still can't see any response received, while yet another
> merge window is going to pass away soon.
>
> Applies cleanly on top of 2.6.37-rc4, so no need for yet another refresh. Only
> tried to clean up the commit message slightly - maybe my English is not good
> enough to bother with, if not the code?
>
> v1 -> v2 changes:
> - improve some conditional expressions to be more readable; thanks to Ralph
> Corderoy (from e3-hacking) and Lars-Peter Clausen for their suggestions,
> - refresh against linux-2.6.36-rc5.
>
> drivers/leds/ledtrig-backlight.c | 60
> ++++++++++++++++++++++++++++++++++++---
> 1 file changed, 56 insertions(+), 4 deletions(-)
>
> diff -upr linux-2.6.36-rc5.orig/drivers/leds/ledtrig-backlight.c linux-2.6.36-rc5/drivers/leds/ledtrig-backlight.c
> --- linux-2.6.36-rc5.orig/drivers/leds/ledtrig-backlight.c 2010-09-24 15:35:13.000000000 +0200
> +++ linux-2.6.36-rc5/drivers/leds/ledtrig-backlight.c 2010-10-03 15:59:49.000000000 +0200
> @@ -26,6 +26,7 @@ struct bl_trig_notifier {
> int brightness;
> int old_status;
> struct notifier_block notifier;
> + unsigned invert;
> };
>
> static int fb_notifier_callback(struct notifier_block *p,
> @@ -36,23 +37,63 @@ static int fb_notifier_callback(struct n
> struct led_classdev *led = n->led;
> struct fb_event *fb_event = data;
> int *blank = fb_event->data;
> + int new_status = *blank ? BLANK : UNBLANK;
>
> switch (event) {
> case FB_EVENT_BLANK :
> - if (*blank && n->old_status = UNBLANK) {
> + if (new_status = n->old_status)
> + break;
> +
> + if ((n->old_status = UNBLANK) ^ n->invert) {
> n->brightness = led->brightness;
> led_set_brightness(led, LED_OFF);
> - n->old_status = BLANK;
> - } else if (!*blank && n->old_status = BLANK) {
> + } else {
> led_set_brightness(led, n->brightness);
> - n->old_status = UNBLANK;
> }
> +
> + n->old_status = new_status;
> +
> break;
> }
>
> return 0;
> }
>
> +static ssize_t bl_trig_invert_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct led_classdev *led = dev_get_drvdata(dev);
> + struct bl_trig_notifier *n = led->trigger_data;
> +
> + return sprintf(buf, "%s\n", n->invert ? "yes" : "no");
> +}
I think this should show "0" or "1", to match the thing which the user
wrote here.
> +static ssize_t bl_trig_invert_store(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t num)
> +{
> + struct led_classdev *led = dev_get_drvdata(dev);
> + struct bl_trig_notifier *n = led->trigger_data;
> + unsigned invert;
> + int ret;
> +
> + ret = sscanf(buf, "%u", &invert);
Here we should use strict_strtoul() so the kernel correctly rejects
input of the form "42foo".
> + if (ret < 1) {
> + dev_err(dev, "invalid value\n");
> + return -EINVAL;
> + }
And here it would be better to disallow any input other than 0 or 1.
Because "2" makes no sense and who knows, some time in the future we
might *want* to permit 2.
So...
--- a/drivers/leds/ledtrig-backlight.c~leds-add-output-inversion-option-to-backlight-trigger-fix
+++ a/drivers/leds/ledtrig-backlight.c
@@ -65,7 +65,7 @@ static ssize_t bl_trig_invert_show(struc
struct led_classdev *led = dev_get_drvdata(dev);
struct bl_trig_notifier *n = led->trigger_data;
- return sprintf(buf, "%s\n", n->invert ? "yes" : "no");
+ return sprintf(buf, "%u\n", n->invert);
}
static ssize_t bl_trig_invert_store(struct device *dev,
@@ -73,16 +73,17 @@ static ssize_t bl_trig_invert_store(stru
{
struct led_classdev *led = dev_get_drvdata(dev);
struct bl_trig_notifier *n = led->trigger_data;
- unsigned invert;
+ unsigned long invert;
int ret;
- ret = sscanf(buf, "%u", &invert);
- if (ret < 1) {
- dev_err(dev, "invalid value\n");
+ ret = strict_strtoul(buf, 10, &invert);
+ if (ret < 0)
+ return ret;
+
+ if (invert > 1)
return -EINVAL;
- }
- n->invert = !!invert;
+ n->invert = invert;
/* After inverting, we need to update the LED. */
if ((n->old_status = BLANK) ^ n->invert)
_
Could you help test it please?
> +static DEVICE_ATTR(invert, 0644, bl_trig_invert_show, bl_trig_invert_store);
This new sysfs file should be documented. Where would be an
appropriate place for that? Documentation/leds-class.txt doesn't
mention a sysfs API at all.
^ permalink raw reply
* Re: [RESEND #2] [PATCH v2] LEDS: Add output invertion option to
From: Randy Dunlap @ 2011-01-06 21:08 UTC (permalink / raw)
To: Andrew Morton
Cc: Janusz Krzysztofik, Richard Purdie, linux-fbdev@vger.kernel.org,
linux-kernel, linux-omap@vger.kernel.org, Paul Mundt
In-Reply-To: <20110106130440.cfd77c8e.akpm@linux-foundation.org>
On Thu, 6 Jan 2011 13:04:40 -0800 Andrew Morton wrote:
> On Thu, 9 Dec 2010 14:41:50 +0100
> Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> wrote:
>
> > +static DEVICE_ATTR(invert, 0644, bl_trig_invert_show, bl_trig_invert_store);
>
> This new sysfs file should be documented. Where would be an
> appropriate place for that? Documentation/leds-class.txt doesn't
> mention a sysfs API at all.
> --
in Documentation/ABI/, where all sysfs interface info lives.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [RESEND #2] [PATCH v2] LEDS: Add output invertion option to
From: Andrew Morton @ 2011-01-06 21:16 UTC (permalink / raw)
To: Randy Dunlap
Cc: Janusz Krzysztofik, Richard Purdie, linux-fbdev@vger.kernel.org,
linux-kernel, linux-omap@vger.kernel.org, Paul Mundt
In-Reply-To: <20110106130856.22b92a8b.randy.dunlap@oracle.com>
On Thu, 6 Jan 2011 13:08:56 -0800
Randy Dunlap <randy.dunlap@oracle.com> wrote:
> On Thu, 6 Jan 2011 13:04:40 -0800 Andrew Morton wrote:
>
> > On Thu, 9 Dec 2010 14:41:50 +0100
> > Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> wrote:
> >
> > > +static DEVICE_ATTR(invert, 0644, bl_trig_invert_show, bl_trig_invert_store);
> >
> > This new sysfs file should be documented. Where would be an
> > appropriate place for that? Documentation/leds-class.txt doesn't
> > mention a sysfs API at all.
> > --
>
> in Documentation/ABI/, where all sysfs interface info lives.
>
Spose so. Documentation/ABI/stable/sysfs-class-backlight does have
some stuff in it.
Personally I tend to regard Documentation/ABI/ as fairly useless
incomprehensible stuff, maintained to keep Greg happy ;) It'd be better
to have a nice little well-maintained document for a subsystem such as
this which actually explains its operation in a useful-to-humans way.
Rather than just mechanically filling out forms.
But a Documentation/ABI update is a heck of a lot better than nothing.
^ permalink raw reply
* Re: [RESEND #2] [PATCH v2] LEDS: Add output invertion option to backlight
From: Randy Dunlap @ 2011-01-06 21:19 UTC (permalink / raw)
To: Andrew Morton
Cc: Janusz Krzysztofik, Richard Purdie, linux-fbdev@vger.kernel.org,
linux-kernel, linux-omap@vger.kernel.org, Paul Mundt
In-Reply-To: <20110106131659.cedf8500.akpm@linux-foundation.org>
On 01/06/11 13:16, Andrew Morton wrote:
> On Thu, 6 Jan 2011 13:08:56 -0800
> Randy Dunlap <randy.dunlap@oracle.com> wrote:
>
>> On Thu, 6 Jan 2011 13:04:40 -0800 Andrew Morton wrote:
>>
>>> On Thu, 9 Dec 2010 14:41:50 +0100
>>> Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> wrote:
>>>
>>>> +static DEVICE_ATTR(invert, 0644, bl_trig_invert_show, bl_trig_invert_store);
>>>
>>> This new sysfs file should be documented. Where would be an
>>> appropriate place for that? Documentation/leds-class.txt doesn't
>>> mention a sysfs API at all.
>>> --
>>
>> in Documentation/ABI/, where all sysfs interface info lives.
>>
>
> Spose so. Documentation/ABI/stable/sysfs-class-backlight does have
> some stuff in it.
>
> Personally I tend to regard Documentation/ABI/ as fairly useless
> incomprehensible stuff, maintained to keep Greg happy ;) It'd be better
> to have a nice little well-maintained document for a subsystem such as
> this which actually explains its operation in a useful-to-humans way.
> Rather than just mechanically filling out forms.
>
> But a Documentation/ABI update is a heck of a lot better than nothing.
Yes, I was giving you the "where it currently lives", not "what is best."
I agree with you.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* [PATCH 10/36] VIDEO: xen-fb, switch to for_each_console
From: Greg Kroah-Hartman @ 2011-01-06 22:22 UTC (permalink / raw)
To: linux-kernel
Cc: Jiri Slaby, Jeremy Fitzhardinge, Chris Wright, virtualization,
xen-devel, linux-fbdev, Greg Kroah-Hartman
In-Reply-To: <20110106215404.GA30624@kroah.com>
From: Jiri Slaby <jslaby@suse.cz>
Use newly added for_each_console for iterating consoles.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
Cc: Chris Wright <chrisw@sous-sol.org>
Cc: virtualization@lists.osdl.org
Cc: xen-devel@lists.xensource.com
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/video/xen-fbfront.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
index 428d273..4abb0b9 100644
--- a/drivers/video/xen-fbfront.c
+++ b/drivers/video/xen-fbfront.c
@@ -492,7 +492,7 @@ xenfb_make_preferred_console(void)
return;
acquire_console_sem();
- for (c = console_drivers; c; c = c->next) {
+ for_each_console(c) {
if (!strcmp(c->name, "tty") && c->index = 0)
break;
}
--
1.7.3.2
^ permalink raw reply related
* Re: Using s3virge card in Sun Blade 2000
From: Alex Buell @ 2011-01-06 22:24 UTC (permalink / raw)
To: Francois Romieu; +Cc: David Miller, linux-fbdev, linux-kernel
In-Reply-To: <1294347036.24378.13.camel@lithium>
On Thu, 2011-01-06 at 20:50 +0000, Alex Buell wrote:
> > Sorry for the obvious but you modified s3_identification() so that
> it
> > stops emitting vga_rcrt(NULL, ...), right ?
>
> I must have missed that one - thank you for pointing that one out to
> me!
Sweet smell of success:
Jan 6 22:09:20 sodium kernel: fb1: S3 Virge/GX on 0000:00:03.0, 6 MB
RAM, 14 MHz MCLK
s3fb now loads OK and correctly identifies the graphic adapter, now that
I fixed s3_identification and others.
It now crashes elsewhere when the framebuffer device is opened, the logs
shows that:
ERROR(0): Cheetah error trap taken afsr[0010100000000000] afar[00000000000003c0] TL1(0)
Jan 6 22:10:05 sodium kernel: ERROR(0): TPC[10575140] TNPC[10575144] O7[105750e8] TSTATE[4411001604]
Jan 6 22:10:05 sodium kernel: ERROR(0): TPC<save_vga+0x8c/0xf90 [vgastate]>
Jan 6 22:10:05 sodium kernel: ERROR(0): M_SYND(0), E_SYND(0), Privileged
Jan 6 22:10:05 sodium kernel: ERROR(0): Highest priority error (0000100000000000) "Unmapped error from system bus"
Jan 6 22:10:05 sodium kernel: ERROR(0): D-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000]
Jan 6 22:10:05 sodium kernel: ERROR(0): D-cache data0[0000000000000000] data1[0000000000000000] data2[0000000000000000] data3[0000000000000000]
Jan 6 22:10:05 sodium kernel: ERROR(0): I-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] u[0000000000000000] l[0000000000000000]
Jan 6 22:10:05 sodium kernel: ERROR(0): I-cache INSN0[0000000000000000] INSN1[0000000000000000] INSN2[0000000000000000] INSN3[0000000000000000]
Jan 6 22:10:05 sodium kernel: ERROR(0): I-cache INSN4[0000000000000000] INSN5[0000000000000000] INSN6[0000000000000000] INSN7[0000000000000000]
Jan 6 22:10:05 sodium kernel: ERROR(0): E-cache idx[3c0] tag[0000000313924924]
Jan 6 22:10:05 sodium kernel: ERROR(0): E-cache data0[6c6f6e672e682069] data1[6e636c7564652f6c] data2[696e75782f706f73] data3[69785f7479706573]
Jan 6 22:10:05 sodium kernel: Kernel panic - not syncing: Irrecoverable deferred error trap.
Looks like there's a bug in save_vga which is in
drivers/video/vgastate.c. I'll be sprinkling printk()s through
save_vga() to find the offending line of code.
Still, I'm pleased the module loads.
--
Tactical Nuclear Kittens
^ permalink raw reply
* Re: Using s3virge card in Sun Blade 2000
From: David Miller @ 2011-01-06 22:29 UTC (permalink / raw)
To: alex.buell; +Cc: romieu, linux-fbdev, linux-kernel
In-Reply-To: <1294352651.24378.17.camel@lithium>
You have to initialize par->state.vgabase in the s3fb driver to the
VGA area iomem pointer you calculated at boot time.
^ permalink raw reply
* Re: Using s3virge card in Sun Blade 2000
From: Alex Buell @ 2011-01-06 23:25 UTC (permalink / raw)
To: David Miller; +Cc: romieu, linux-fbdev, linux-kernel
In-Reply-To: <20110106.142906.226774601.davem@davemloft.net>
On Thu, 2011-01-06 at 14:29 -0800, David Miller wrote:
> You have to initialize par->state.vgabase in the s3fb driver to the
> VGA area iomem pointer you calculated at boot time.
Thanks for that, I've just got past that, now it's changing modes that
crashes the driver. I can load and unload the driver, and it
automatically selects 640x480.
How do I track down the offending line of code from the following entry
in the logs:
TPC<s3fb_set_par+0x1a0/0xf78 [s3fb]>
Also, oddly enough, before calling save_vga it clears par->state, which
was why it was crashing. Explicitly setting the par->state.vgabase to
the vga_iobase address solved the problem as below. I also noticed that
having VGA_SAVE_FONTS crashes the driver, so I left it out - a quick
look through the code in vgastate.c indicate it needs rework to make it
work but I've left that for later.
(in s3fb_open)
if (par->ref_count = 0) {
memset(&(par->state), 0, sizeof(struct vgastate));
/* save_vga/restore_vga needs this to function */
par->state.vgabase = par->vga_iobase;
/*par->state.flags = VGA_SAVE_MODE | VGA_SAVE_FONTS | VGA_SAVE_CMAP;*/
par->state.flags = VGA_SAVE_MODE | VGA_SAVE_CMAP;
par->state.num_crtc = 0x70;
par->state.num_seq = 0x20;
save_vga(&(par->state));
Thanks, seems it's starting to work bit by bit!
--
Tactical Nuclear Kittens
^ permalink raw reply
* Re: Using s3virge card in Sun Blade 2000
From: Alex Buell @ 2011-01-06 23:34 UTC (permalink / raw)
To: David Miller; +Cc: romieu, linux-fbdev, linux-kernel
In-Reply-To: <20110106.142906.226774601.davem@davemloft.net>
On Thu, 2011-01-06 at 14:29 -0800, David Miller wrote:
> You have to initialize par->state.vgabase in the s3fb driver to the
> VGA area iomem pointer you calculated at boot time.
I just had a look through the svgalib.c. It makes a lot of calls to
vgastate with the NULL parameter for the vga iobase, I guess that's
definitely why it's crashing the driver.
Also, svga.h has inline functions that needs modifying. Looks like a big
change to let it work with the vga iobase or NULL. Perhaps just passing
the par->state.vgabase into those functions could make it work. Usually
this gets initialised as zero at boot or driver load so the default
could be NULL anyway for those drivers that assume it is located at 0.
--
Tactical Nuclear Kittens
^ permalink raw reply
* Re: [PATCH 1/3] fbdev: sh_mobile_hdmi: add command line option to use the preferred EDID mode
From: Paul Mundt @ 2011-01-07 2:15 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <Pine.LNX.4.64.1101061919490.1248@axis700.grange>
On Thu, Jan 06, 2011 at 07:23:54PM +0100, Guennadi Liakhovetski wrote:
> Currently, if no command-line option is specified, the sh_mobile_hdmi
> will use the default 720p video mode. If a command line option of the
> form "video=sh_mobile_lcdc:<width>x<height>@<refresh>" is provided,
> the driver will look for that mode among those, available in the
> monitor EDID. This patch adds the ability to request the driver to
> use monitor's preferred mode by specifying 0 as width and hight in
> the above string. If that mode is not supported by the system, the
> driver will continue scanning through EDID modes, until it finds a
> suitable one.
>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Ok, I tried applying this against all of the fbdev topic branches in the
sh tree, the fbdev tree, and Linus's tree (where the fbdev tree was just
merged), and it doesn't apply to any of them, so I have no idea what tree
you are working with, or if there are some dependencies or something that
you haven't specified.
^ permalink raw reply
* Re: Memory sharing issue by application on V4L2 based device driver
From: InKi Dae @ 2011-01-07 2:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <002201cbadfd$6d59e490$480dadb0$%han@samsung.com>
thank you for your comments.
your second comment has no any problem as I said before, user virtual
addess could be translated in page unit. but the problem, as you said,
is that when cpu access to the memory in user mode, the memory
allocated by malloc, page fault occurs so we can't find pfn to user
virtual address. I missed that. but I think we could resolve this one.
as before, user application allocates memory through malloc function
and then send it to device driver(using userptr feature). if the pfn
is null when device driver translated user virtual address in page
unit then it allocates phsical memory in page unit using some
interface such as alloc_page() and then mapping them. when pfn is
null, to check it and allocate physical memory in page unit could be
processed by videobuf2.
of course, videobuf2 has no any duty considered for system mmu. so
videobuf2 just provides callback for 3rd party and any platform with
system mmu such as Samsung SoC C210 implements the function(allocating
physical memory and mapping it) and registers it to callback of
videobuf2. by doing so, I think your first comment could be cleared.
please, feel free to give me your opinion and pointing out.
thank you.
2011년 1월 7일 오전 8:57, Jonghun Han <jonghun.han@samsung.com>님의 말:
>
> Hello,
>
> There are two reasons why malloc isn't suitable for it.
>
> The first is that malloc doesn't allocate memory when malloc is called.
> So driver or vb2 cannot find PFN for it in the VIDIOC_QBUF.
>
> The second is that malloc uses 4KB page allocation.
> SYS.MMU(IO-MMU) can handle scattered memory. But it has a penalty when TLB
> miss is occurred.
> So as possible as physically contiguous pages are needed for performance
> enhancement.
>
> So new allocator which can clear two main issues is needed.
>
> Best regards,
>
>> -----Original Message-----
>> From: linux-media-owner@vger.kernel.org [mailto:linux-media-
>> owner@vger.kernel.org] On Behalf Of InKi Dae
>> Sent: Thursday, January 06, 2011 10:25 PM
>> To: linux-media@vger.kernel.org
>> Subject: Memory sharing issue by application on V4L2 based device driver
> with
>> system mmu.
>>
>> Hello, all.
>>
>> I'd like to discuss memory sharing issue by application on v4l2 based
> device driver
>> with system mmu and get some advices about that.
>>
>> Now I am working on Samsung SoC C210 platform and this platform has some
>> multimedia devices with system mmu such as fimc, and mfc also we have
>> implemented device drivers for them. those drivers are based on V4L2
> framework
>> with videobuf2. for system mmu of each device, we used VCM(Virtual
> Contiguous
>> Memory) framework.
>>
>> Simply, VCM framework provides physical memory, device virtual memory
>> allocation and memory mapping between them. when device driver is
> initialized or
>> operated by user application, each driver allocates physical memory and
> device
>> virtual memory and then mapping using VCM interface.
>>
>> refer to below link for more detail.
>> http://www.spinics.net/lists/linux-media/msg26548.html
>>
>> Physical memory access process is as the following.
>> DVA PA
>> device --------------> system mmu ------------------> physical memory
>>
>> DVA : device virtual address.
>> PA : physical address.
>>
>> like this, device virtual address should be set to buffer(source or
>> destination) register of multimedia device.
>>
>> the problem is that application want to share own memory with any device
> driver to
>> avoid memory copy. in other words, user-allocated memory could be source
> or
>> destination memory of multimedia device driver.
>>
>>
>> let's see the diagram below.
>>
>> user application
>>
>> |
>> |
>> |
>> |
>> | 1. UVA(allocated by malloc)
>> |
>> |
>> ＼|/ 2. UVA(in page unit)
>>
>> -----> multimedia device driver -------------------> videobuf2
>> |
>> | | ^ |
>> | | | |
>> | | -------------------------------------------
>> | | 3. PA(in page unit)
>> | |
>> | | 4. PA(in page unit)
>> 6. DVA | |
>> | |
>> | |
>> | ＼|/
>> |
>> | Virtual Contiguous Memory ---------
>> | |
>> | | ^ |
>> | | | | 5. map PA to DVA
>> | | | |
>> | | | |
>> ------------- -------------------------
>>
>> PA : physical address.
>> UVA : user virtual address.
>> DVA : device virtual address.
>>
>> 1. user application allocates user space memory through malloc function
> and
>> sending it to multimedia device driver based on v4l2 framework through
> userptr
>> feature.
>>
>> 2, 3. multimedia device driver gets translated physical address from
>> videobuf2 framework in page unit.
>>
>> 4, 5. multimedia device driver gets allocated device virtual address and
> mapping it
>> to physical address and then mapping them through VCM interface.
>>
>> 6. multimedia device driver sets device virtual address from VCM to
> buffer register.
>>
>> the diagram above is fully theoretical so I wonder that this way is
> reasonable and
>> has some problems also what should be considered.
>>
>> thank you for your interesting.
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body
>> of a message to majordomo@vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: A query on frame buffers
From: Prasad Joshi @ 2011-01-07 2:42 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <AANLkTimBpZHwS81BeFxC0dG7mvMg6UaAnFMv6oj04j+Z@mail.gmail.com>
On Mon, Dec 27, 2010 at 3:30 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Tue, Dec 21, 2010 at 04:51:04AM +0000, Prasad Joshi wrote:
>> Hello All,
>>
>> This is probably my first mail on this mailing list. I am working on a
>> university project on Nvidia or any GPU Pass-through in KVM. I have a
>
> You picking the hard ones first, eh? I would suggest you do Intel
> or ATI as they have actually posted patches for this.
Thanks a lot for your reply.
Yes indeed, I started with the ATI Radeon RV370 card. Passing the
Nvidia card is the ultimate aim of the project.
>
>> question related to framebuffer.
>>
>> I was reading few documents on XEN VGA pass-through, the document says
>> the first step for pass-through is mapping the framebuffers in the VM
>> at specific address, specifically speaking 0xA0000 till 0xC0000.
>
> I would suggest you look at the code - there have been some patches
> posted by AMD engineers on xen-devel for this.
>
Yes I am looking at those patches as well, including some research
papers on the same topic.
Here is what I have tried so far.
I have 2 graphics cards connected to my machine
1. Nvidia: This is being used by host machine.
2. ATI: Want to pass-through this card to the VM.
I tried to pass-through the ATI card to VM. First, there was a problem
with ROM BIOS. Then I passed a correct ROM BIOS to QEMU-KVM. Now when
I start the VM with ATI card in pass-through mode.
I see some garbage output on the monitor attached to the ATI card. I
also saw following messages in the system log.
[ 2.162294] [drm] Initialized drm 1.1.0 20060810
[ 2.459594] [drm] radeon defaulting to kernel modesetting.
[ 2.459596] [drm] radeon kernel modesetting enabled.
[ 2.766698] radeon 0000:00:04.0: PCI INT A -> Link[LNKD] -> GSI 10
(level, high) -> IRQ 10
[ 2.766734] radeon 0000:00:04.0: setting latency timer to 64
[ 2.783512] [drm] initializing kernel modesetting (RV380 0x1002:0x5B64).
[ 2.792407] [drm] register mmio base: 0x40000000
[ 2.792408] [drm] register mmio size: 65536
[ 2.797177] [drm] Generation 2 PCI interface, using max accessible memory
[ 2.797275] radeon 0000:00:04.0: VRAM: 128M 0x00000000F8000000 -
0x00000000FFFFFFFF (128M used)
[ 2.797284] radeon 0000:00:04.0: GTT: 512M 0x00000000D8000000 -
0x00000000F7FFFFFF
[ 2.798370] radeon 0000:00:04.0: irq 40 for MSI/MSI-X
[ 2.870703] radeon 0000:00:04.0: radeon: using MSI.
[ 3.151162] [drm] radeon: irq initialized.
[ 3.151539] [drm] Detected VRAM RAM\x128M, BAR\x128M
[ 3.151541] [drm] RAM width 128bits DDR
[ 3.151610] [drm] radeon: 128M of VRAM memory ready
[ 3.151611] [drm] radeon: 512M of GTT memory ready.
[ 3.151627] [drm] GART: num cpu pages 131072, num gpu pages 131072
[ 3.152701] [drm] radeon: 1 quad pipes, 1 Z pipes initialized.
[ 3.544943] [drm] PCIE GART of 512M enabled (table at 0xF8040000).
[ 3.548479] radeon 0000:00:04.0: WB enabled
[ 3.549020] [drm] Loading R300 Microcode
[ 3.554278] [drm] radeon: ring at 0x00000000D8001000
[ 3.778476] [drm:r100_ring_test] *ERROR* radeon: ring test failed
(sracth(0x15E4)=0xCAFEDEAD)
[ 3.781010] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
[ 3.782542] radeon 0000:00:04.0: failled initializing CP (-22).
[ 3.784006] radeon 0000:00:04.0: Disabling GPU acceleration
[ 3.793709] [drm] radeon: cp finalized
[ 3.834875] radeon 0000:00:04.0: ffff8800320b4c00 unpin not necessary
[ 3.841759] [drm] Radeon Display Connectors
[ 3.841766] [drm] Connector 0:
[ 3.841771] [drm] VGA
[ 3.841777] [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
[ 3.841781] [drm] Encoders:
[ 3.841785] [drm] CRT1: INTERNAL_DAC1
[ 3.841788] [drm] Connector 1:
[ 3.841791] [drm] DVI-I
[ 3.841794] [drm] HPD1
[ 3.841799] [drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
[ 3.841803] [drm] Encoders:
[ 3.841806] [drm] CRT2: INTERNAL_DAC2
[ 3.841809] [drm] DFP1: INTERNAL_TMDS1
[ 6.158753] [drm] fb mappable at 0xF8040000
[ 6.158756] [drm] vram apper at 0xF8000000
[ 6.158757] [drm] size 5242880
[ 6.158758] [drm] fb depth is 24
[ 6.158759] [drm] pitch is 5120
[ 13.914196] fb0: radeondrmfb frame buffer device
[ 13.914198] drm: registered panic notifier
[ 13.914683] [drm] Initialized radeon 2.7.0 20080528 for
0000:00:04.0 on minor 0
The errors
[ 3.778476] [drm:r100_ring_test] *ERROR* radeon: ring test failed
(sracth(0x15E4)=0xCAFEDEAD)
[ 3.781010] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
[ 3.782542] radeon 0000:00:04.0: failled initializing CP (-22).
[ 3.784006] radeon 0000:00:04.0: Disabling GPU acceleration
Seem to be disabling GPU functionality. For now, I am interested in
Graphics functionality of the ATI card and not GPGPU functionality.
I will appreciate if you can help me with some information on solving
this problem. Let me know if I should be asking this question on
another forum. Please keep me in CC.
Thanks and Regards,
Prasad
^ permalink raw reply
* RE: Memory sharing issue by application on V4L2 based device driver
From: Jonghun Han @ 2011-01-07 3:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinsduJkynwwEeM5K9f3D7C6jtBgkAyZ0-_0z2X-@mail.gmail.com>
Hello,
That's not a translation issue. What I mention is the size of allocation.
The malloc uses 4KB page allocation and SYS.MMU can handle it.
But 64KB or 1MB physically contiguous memory is better than 4KB page in the
point of performance.
Best regards,
> -----Original Message-----
> From: linux-media-owner@vger.kernel.org [mailto:linux-media-
> owner@vger.kernel.org] On Behalf Of InKi Dae
> Sent: Friday, January 07, 2011 11:17 AM
> To: Jonghun Han
> Cc: linux-media@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
linux-fbdev;
> kyungmin.park@samsung.com
> Subject: Re: Memory sharing issue by application on V4L2 based device
driver
> with system mmu.
>
> thank you for your comments.
>
> your second comment has no any problem as I said before, user virtual
addess
> could be translated in page unit. but the problem, as you said, is that
when cpu
> access to the memory in user mode, the memory allocated by malloc, page
fault
> occurs so we can't find pfn to user virtual address. I missed that. but I
think we
> could resolve this one.
>
> as before, user application allocates memory through malloc function and
then
> send it to device driver(using userptr feature). if the pfn is null when
device driver
> translated user virtual address in page unit then it allocates phsical
memory in
> page unit using some interface such as alloc_page() and then mapping
them. when
> pfn is null, to check it and allocate physical memory in page unit could
be
> processed by videobuf2.
>
> of course, videobuf2 has no any duty considered for system mmu. so
> videobuf2 just provides callback for 3rd party and any platform with
system mmu
> such as Samsung SoC C210 implements the function(allocating physical
memory
> and mapping it) and registers it to callback of videobuf2. by doing so, I
think your
> first comment could be cleared.
>
> please, feel free to give me your opinion and pointing out.
>
> thank you.
>
> 2011년 1월 7일 오전 8:57, Jonghun Han <jonghun.han@samsung.com>님의 말:
> >
> > Hello,
> >
> > There are two reasons why malloc isn't suitable for it.
> >
> > The first is that malloc doesn't allocate memory when malloc is called.
> > So driver or vb2 cannot find PFN for it in the VIDIOC_QBUF.
> >
> > The second is that malloc uses 4KB page allocation.
> > SYS.MMU(IO-MMU) can handle scattered memory. But it has a penalty when
> > TLB miss is occurred.
> > So as possible as physically contiguous pages are needed for
> > performance enhancement.
> >
> > So new allocator which can clear two main issues is needed.
> >
> > Best regards,
> >
> >> -----Original Message-----
> >> From: linux-media-owner@vger.kernel.org [mailto:linux-media-
> >> owner@vger.kernel.org] On Behalf Of InKi Dae
> >> Sent: Thursday, January 06, 2011 10:25 PM
> >> To: linux-media@vger.kernel.org
> >> Subject: Memory sharing issue by application on V4L2 based device
> >> driver
> > with
> >> system mmu.
> >>
> >> Hello, all.
> >>
> >> I'd like to discuss memory sharing issue by application on v4l2 based
> > device driver
> >> with system mmu and get some advices about that.
> >>
> >> Now I am working on Samsung SoC C210 platform and this platform has
> >> some multimedia devices with system mmu such as fimc, and mfc also we
> >> have implemented device drivers for them. those drivers are based on
> >> V4L2
> > framework
> >> with videobuf2. for system mmu of each device, we used VCM(Virtual
> > Contiguous
> >> Memory) framework.
> >>
> >> Simply, VCM framework provides physical memory, device virtual
> >> memory allocation and memory mapping between them. when device driver
> >> is
> > initialized or
> >> operated by user application, each driver allocates physical memory
> >> and
> > device
> >> virtual memory and then mapping using VCM interface.
> >>
> >> refer to below link for more detail.
> >> http://www.spinics.net/lists/linux-media/msg26548.html
> >>
> >> Physical memory access process is as the following.
> >> DVA PA
> >> device --------------> system mmu ------------------> physical memory
> >>
> >> DVA : device virtual address.
> >> PA : physical address.
> >>
> >> like this, device virtual address should be set to buffer(source or
> >> destination) register of multimedia device.
> >>
> >> the problem is that application want to share own memory with any
> >> device
> > driver to
> >> avoid memory copy. in other words, user-allocated memory could be
> >> source
> > or
> >> destination memory of multimedia device driver.
> >>
> >>
> >> let's see the diagram below.
> >>
> >> user application
> >>
> >> |
> >> |
> >> |
> >> |
> >> | 1. UVA(allocated by malloc)
> >> |
> >> |
> >> ＼|/ 2. UVA(in page unit)
> >>
> >> -----> multimedia device driver -------------------> videobuf2
> >> |
> >> | | ^ |
> >> | | | |
> >> | | -------------------------------------------
> >> | | 3. PA(in page unit)
> >> | |
> >> | | 4. PA(in page unit)
> >> 6. DVA | |
> >> | |
> >> | |
> >> | ＼|/
> >> |
> >> | Virtual Contiguous Memory ---------
> >> | |
> >> | | ^ |
> >> | | | | 5. map PA to DVA
> >> | | | |
> >> | | | |
> >> ------------- -------------------------
> >>
> >> PA : physical address.
> >> UVA : user virtual address.
> >> DVA : device virtual address.
> >>
> >> 1. user application allocates user space memory through malloc
> >> function
> > and
> >> sending it to multimedia device driver based on v4l2 framework
> >> through
> > userptr
> >> feature.
> >>
> >> 2, 3. multimedia device driver gets translated physical address from
> >> videobuf2 framework in page unit.
> >>
> >> 4, 5. multimedia device driver gets allocated device virtual address
> >> and
> > mapping it
> >> to physical address and then mapping them through VCM interface.
> >>
> >> 6. multimedia device driver sets device virtual address from VCM to
> > buffer register.
> >>
> >> the diagram above is fully theoretical so I wonder that this way is
> > reasonable and
> >> has some problems also what should be considered.
> >>
> >> thank you for your interesting.
> >>
> >> _______________________________________________
> >> linux-arm-kernel mailing list
> >> linux-arm-kernel@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe
> >> linux-media" in
> > the body
> >> of a message to majordomo@vger.kernel.org More majordomo info at
> >> http://vger.kernel.org/majordomo-info.html
> >
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body
> of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Memory sharing issue by application on V4L2 based device driver
From: daeinki @ 2011-01-07 4:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <003201cbae19$bda3dfc0$38eb9f40$%han@samsung.com>
Hello, Mr. Jonghun.
please, note that user process's pgd and device's pgd with system mmu
are differnent. first, the memory allocated by user malloc should be
mapped to physical memory in page unit because user app also should be
accessed to own memory region. and when mapping the physical memory to
device virtual address, it creates page table entry for 64k or 1M and
then could map physical address to those entries. therefore what you
mention has no problem.
actual issue is not to need demend paging, some issues we don't
understand may exist as side effects.
thank you.
Jonghun Han 쓴 글:
> Hello,
>
> That's not a translation issue. What I mention is the size of allocation.
> The malloc uses 4KB page allocation and SYS.MMU can handle it.
> But 64KB or 1MB physically contiguous memory is better than 4KB page in the
> point of performance.
>
> Best regards,
>
>> -----Original Message-----
>> From: linux-media-owner@vger.kernel.org [mailto:linux-media-
>> owner@vger.kernel.org] On Behalf Of InKi Dae
>> Sent: Friday, January 07, 2011 11:17 AM
>> To: Jonghun Han
>> Cc: linux-media@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> linux-fbdev;
>> kyungmin.park@samsung.com
>> Subject: Re: Memory sharing issue by application on V4L2 based device
> driver
>> with system mmu.
>>
>> thank you for your comments.
>>
>> your second comment has no any problem as I said before, user virtual
> addess
>> could be translated in page unit. but the problem, as you said, is that
> when cpu
>> access to the memory in user mode, the memory allocated by malloc, page
> fault
>> occurs so we can't find pfn to user virtual address. I missed that. but I
> think we
>> could resolve this one.
>>
>> as before, user application allocates memory through malloc function and
> then
>> send it to device driver(using userptr feature). if the pfn is null when
> device driver
>> translated user virtual address in page unit then it allocates phsical
> memory in
>> page unit using some interface such as alloc_page() and then mapping
> them. when
>> pfn is null, to check it and allocate physical memory in page unit could
> be
>> processed by videobuf2.
>>
>> of course, videobuf2 has no any duty considered for system mmu. so
>> videobuf2 just provides callback for 3rd party and any platform with
> system mmu
>> such as Samsung SoC C210 implements the function(allocating physical
> memory
>> and mapping it) and registers it to callback of videobuf2. by doing so, I
> think your
>> first comment could be cleared.
>>
>> please, feel free to give me your opinion and pointing out.
>>
>> thank you.
>>
>> 2011년 1월 7일 오전 8:57, Jonghun Han <jonghun.han@samsung.com>님의 말:
>>> Hello,
>>>
>>> There are two reasons why malloc isn't suitable for it.
>>>
>>> The first is that malloc doesn't allocate memory when malloc is called.
>>> So driver or vb2 cannot find PFN for it in the VIDIOC_QBUF.
>>>
>>> The second is that malloc uses 4KB page allocation.
>>> SYS.MMU(IO-MMU) can handle scattered memory. But it has a penalty when
>>> TLB miss is occurred.
>>> So as possible as physically contiguous pages are needed for
>>> performance enhancement.
>>>
>>> So new allocator which can clear two main issues is needed.
>>>
>>> Best regards,
>>>
>>>> -----Original Message-----
>>>> From: linux-media-owner@vger.kernel.org [mailto:linux-media-
>>>> owner@vger.kernel.org] On Behalf Of InKi Dae
>>>> Sent: Thursday, January 06, 2011 10:25 PM
>>>> To: linux-media@vger.kernel.org
>>>> Subject: Memory sharing issue by application on V4L2 based device
>>>> driver
>>> with
>>>> system mmu.
>>>>
>>>> Hello, all.
>>>>
>>>> I'd like to discuss memory sharing issue by application on v4l2 based
>>> device driver
>>>> with system mmu and get some advices about that.
>>>>
>>>> Now I am working on Samsung SoC C210 platform and this platform has
>>>> some multimedia devices with system mmu such as fimc, and mfc also we
>>>> have implemented device drivers for them. those drivers are based on
>>>> V4L2
>>> framework
>>>> with videobuf2. for system mmu of each device, we used VCM(Virtual
>>> Contiguous
>>>> Memory) framework.
>>>>
>>>> Simply, VCM framework provides physical memory, device virtual
>>>> memory allocation and memory mapping between them. when device driver
>>>> is
>>> initialized or
>>>> operated by user application, each driver allocates physical memory
>>>> and
>>> device
>>>> virtual memory and then mapping using VCM interface.
>>>>
>>>> refer to below link for more detail.
>>>> http://www.spinics.net/lists/linux-media/msg26548.html
>>>>
>>>> Physical memory access process is as the following.
>>>> DVA PA
>>>> device --------------> system mmu ------------------> physical memory
>>>>
>>>> DVA : device virtual address.
>>>> PA : physical address.
>>>>
>>>> like this, device virtual address should be set to buffer(source or
>>>> destination) register of multimedia device.
>>>>
>>>> the problem is that application want to share own memory with any
>>>> device
>>> driver to
>>>> avoid memory copy. in other words, user-allocated memory could be
>>>> source
>>> or
>>>> destination memory of multimedia device driver.
>>>>
>>>>
>>>> let's see the diagram below.
>>>>
>>>> user application
>>>>
>>>> |
>>>> |
>>>> |
>>>> |
>>>> | 1. UVA(allocated by malloc)
>>>> |
>>>> |
>>>> ＼|/ 2. UVA(in page unit)
>>>>
>>>> -----> multimedia device driver -------------------> videobuf2
>>>> |
>>>> | | ^ |
>>>> | | | |
>>>> | | -------------------------------------------
>>>> | | 3. PA(in page unit)
>>>> | |
>>>> | | 4. PA(in page unit)
>>>> 6. DVA | |
>>>> | |
>>>> | |
>>>> | ＼|/
>>>> |
>>>> | Virtual Contiguous Memory ---------
>>>> | |
>>>> | | ^ |
>>>> | | | | 5. map PA to DVA
>>>> | | | |
>>>> | | | |
>>>> ------------- -------------------------
>>>>
>>>> PA : physical address.
>>>> UVA : user virtual address.
>>>> DVA : device virtual address.
>>>>
>>>> 1. user application allocates user space memory through malloc
>>>> function
>>> and
>>>> sending it to multimedia device driver based on v4l2 framework
>>>> through
>>> userptr
>>>> feature.
>>>>
>>>> 2, 3. multimedia device driver gets translated physical address from
>>>> videobuf2 framework in page unit.
>>>>
>>>> 4, 5. multimedia device driver gets allocated device virtual address
>>>> and
>>> mapping it
>>>> to physical address and then mapping them through VCM interface.
>>>>
>>>> 6. multimedia device driver sets device virtual address from VCM to
>>> buffer register.
>>>> the diagram above is fully theoretical so I wonder that this way is
>>> reasonable and
>>>> has some problems also what should be considered.
>>>>
>>>> thank you for your interesting.
>>>>
>>>> _______________________________________________
>>>> linux-arm-kernel mailing list
>>>> linux-arm-kernel@lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe
>>>> linux-media" in
>>> the body
>>>> of a message to majordomo@vger.kernel.org More majordomo info at
>>>> http://vger.kernel.org/majordomo-info.html
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body
>> of a message to majordomo@vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [patch] xenfb: fix xenfb suspend/resume race.
From: Joe Jin @ 2011-01-07 6:40 UTC (permalink / raw)
To: jeremy, ian.campbell, Andrew Morton
Cc: linux-fbdev, xen-devel, gurudas.pai, guru.anbalagane,
greg.marsden, joe.jin, linux-kernel, Konrad Rzeszutek Wilk
Hi,
when do migration test, we hit the panic as below:
<1>BUG: unable to handle kernel paging request at 0000000b819fdb98
<1>IP: [<ffffffff812a588f>] notify_remote_via_irq+0x13/0x34
<4>PGD 94b10067 PUD 0
<0>Oops: 0000 [#1] SMP
<0>last sysfs file: /sys/class/misc/autofs/dev
<4>CPU 3
<4>Modules linked in: autofs4(U) hidp(U) nfs(U) fscache(U) nfs_acl(U)
auth_rpcgss(U) rfcomm(U) l2cap(U) bluetooth(U) rfkill(U) lockd(U) sunrpc(U)
nf_conntrack_netbios_ns(U) ipt_REJECT(U) nf_conntrack_ipv4(U)
nf_defrag_ipv4(U) xt_state(U) nf_conntrack(U) iptable_filter(U) ip_tables(U)
ip6t_REJECT(U) xt_tcpudp(U) ip6table_filter(U) ip6_tables(U) x_tables(U)
ipv6(U) parport_pc(U) lp(U) parport(U) snd_seq_dummy(U) snd_seq_oss(U)
snd_seq_midi_event(U) snd_seq(U) snd_seq_device(U) snd_pcm_oss(U)
snd_mixer_oss(U) snd_pcm(U) snd_timer(U) snd(U) soundcore(U)
snd_page_alloc(U) joydev(U) xen_netfront(U) pcspkr(U) xen_blkfront(U)
uhci_hcd(U) ohci_hcd(U) ehci_hcd(U)
Pid: 18, comm: events/3 Not tainted 2.6.32
RIP: e030:[<ffffffff812a588f>] [<ffffffff812a588f>]
ify_remote_via_irq+0x13/0x34
RSP: e02b:ffff8800e7bf7bd0 EFLAGS: 00010202
RAX: ffff8800e61c8000 RBX: ffff8800e62f82c0 RCX: 0000000000000000
RDX: 00000000000001e3 RSI: ffff8800e7bf7c68 RDI: 0000000bfffffff4
RBP: ffff8800e7bf7be0 R08: 00000000000001e2 R09: ffff8800e62f82c0
R10: 0000000000000001 R11: ffff8800e6386110 R12: 0000000000000000
R13: 0000000000000007 R14: ffff8800e62f82e0 R15: 0000000000000240
FS: 00007f409d3906e0(0000) GS:ffff8800028b8000(0000)
GS:0000000000000000
CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000b819fdb98 CR3: 000000003ee3b000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process events/3 (pid: 18, threadinfo ffff8800e7bf6000, task
f8800e7bf4540)
Stack:
0000000000000200 ffff8800e61c8000 ffff8800e7bf7c00 ffffffff812712c9
<0> ffffffff8100ea5f ffffffff81438d80 ffff8800e7bf7cd0 ffffffff812714ee
<0> 0000000000000000 ffffffff81270568 000000000000e030 0000000000010202
Call Trace:
[<ffffffff812712c9>] xenfb_send_event+0x5c/0x5e
[<ffffffff8100ea5f>] ? xen_restore_fl_direct_end+0x0/0x1
[<ffffffff81438d80>] ? _spin_unlock_irqrestore+0x16/0x18
[<ffffffff812714ee>] xenfb_refresh+0x1b1/0x1d7
[<ffffffff81270568>] ? sys_imageblit+0x1ac/0x458
[<ffffffff81271786>] xenfb_imageblit+0x2f/0x34
[<ffffffff8126a3e5>] soft_cursor+0x1b5/0x1c8
[<ffffffff8126a137>] bit_cursor+0x4b6/0x4d7
[<ffffffff8100ea5f>] ? xen_restore_fl_direct_end+0x0/0x1
[<ffffffff81438d80>] ? _spin_unlock_irqrestore+0x16/0x18
[<ffffffff81269c81>] ? bit_cursor+0x0/0x4d7
[<ffffffff812656b7>] fb_flashcursor+0xff/0x111
[<ffffffff812655b8>] ? fb_flashcursor+0x0/0x111
[<ffffffff81071812>] worker_thread+0x14d/0x1ed
[<ffffffff81075a8c>] ? autoremove_wake_function+0x0/0x3d
[<ffffffff81438d80>] ? _spin_unlock_irqrestore+0x16/0x18
[<ffffffff810716c5>] ? worker_thread+0x0/0x1ed
[<ffffffff810756e3>] kthread+0x6e/0x76
[<ffffffff81012dea>] child_rip+0xa/0x20
[<ffffffff81011fd1>] ? int_ret_from_sys_call+0x7/0x1b
[<ffffffff8101275d>] ? retint_restore_args+0x5/0x6
[<ffffffff81012de0>] ? child_rip+0x0/0x20
Code: 6b ff 0c 8b 87 a4 db 9f 81 66 85 c0 74 08 0f b7 f8 e8 3b ff ff ff c9
c3 55 48 89 e5 48 83 ec 10 0f 1f 44 00 00 89 ff 48 6b ff 0c <8b> 87 a4 db 9f
81 66 85 c0 74 14 48 8d 75 f0 0f b7 c0 bf 04 00
RIP [<ffffffff812a588f>] notify_remote_via_irq+0x13/0x34
RSP <ffff8800e7bf7bd0>
CR2: 0000000b819fdb98
---[ end trace 098b4b74827595d0 ]---
The root cause of the panic is try to refresh xenfb when suspend/resume.
Clear refresh flag of xenfb before disconnect backend would fix this issue.
Also below patch will fixed mem leak when connect to xenfb backend failed.
Please review and comment.
Signed-off-by: Joe Jin <joe.jin@oracle.com>
Tested-by: Gurudas Pai <gurudas.pai@oracle.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
xen-fbfront.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
index dc72563..6f23797 100644
--- a/drivers/video/xen-fbfront.c
+++ b/drivers/video/xen-fbfront.c
@@ -561,26 +561,24 @@ static void xenfb_init_shared_page(struct xenfb_info *info,
static int xenfb_connect_backend(struct xenbus_device *dev,
struct xenfb_info *info)
{
- int ret, evtchn;
+ int ret, evtchn, irq;
struct xenbus_transaction xbt;
ret = xenbus_alloc_evtchn(dev, &evtchn);
if (ret)
return ret;
- ret = bind_evtchn_to_irqhandler(evtchn, xenfb_event_handler,
+ irq = bind_evtchn_to_irqhandler(evtchn, xenfb_event_handler,
0, dev->devicetype, info);
- if (ret < 0) {
+ if (irq < 0) {
xenbus_free_evtchn(dev, evtchn);
xenbus_dev_fatal(dev, ret, "bind_evtchn_to_irqhandler");
- return ret;
+ return irq;
}
- info->irq = ret;
-
again:
ret = xenbus_transaction_start(&xbt);
if (ret) {
xenbus_dev_fatal(dev, ret, "starting transaction");
- return ret;
+ goto unbind_irq;
}
ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
virt_to_mfn(info->page));
@@ -602,20 +600,27 @@ static int xenfb_connect_backend(struct xenbus_device *dev,
if (ret = -EAGAIN)
goto again;
xenbus_dev_fatal(dev, ret, "completing transaction");
- return ret;
+ goto unbind_irq;
}
xenbus_switch_state(dev, XenbusStateInitialised);
+ info->irq = irq;
return 0;
error_xenbus:
xenbus_transaction_end(xbt, 1);
xenbus_dev_fatal(dev, ret, "writing xenstore");
+ unbind_irq:
+ printk(KERN_ERR "xenfb_connect_backend failed!\n");
+ unbind_from_irqhandler(irq, info);
+ xenbus_free_evtchn(dev, evtchn);
return ret;
}
static void xenfb_disconnect_backend(struct xenfb_info *info)
{
+ /* Prevent refresh xenfb */
+ info->update_wanted = 0;
if (info->irq >= 0)
unbind_from_irqhandler(info->irq, info);
info->irq = -1;
^ permalink raw reply related
* Re: [Xen-devel] Re: [patch] xenfb: fix xenfb suspend/resume race
From: Joe Jin @ 2011-01-07 6:43 UTC (permalink / raw)
To: Joe Jin
Cc: Ian Campbell, jeremy@goop.org, xen-devel@lists.xensource.com,
gurudas.pai@oracle.com, Konrad Rzeszutek Wilk,
guru.anbalagane@oracle.com, greg.marsden@oracle.com,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
Andrew Morton
In-Reply-To: <4D2579F1.50900@oracle.com>
On 01/06/11 16:14, Joe Jin wrote:
>
>>
>> No, it papers over the issue, the code should never have been allowed to
>> get this far if the connection to the backend is not yet fully resumed
>> (i.e. when irq = -1).
>>
>> The call to xenfb_send_event should have been gated further up the call
>> chain, AFAICT by the check of info->update_wanted in xenfb_refresh. This
>> suggests that the correct fix is to set info->update_wanted = 0 in
>> xenfb_resume.
>>
>> I said all this in my previous mail and you ignored it. Did you try this
>> approach?
>
Disable xenfb refresh flag before suspend will fix this issue, sent new patch
to you by another mail, please review it.
Thanks,
Joe
^ permalink raw reply
* [patch] xen-event: validate irq before get evtchn by irq
From: Joe Jin @ 2011-01-07 6:50 UTC (permalink / raw)
To: jeremy, ian.campbell, Andrew Morton
Cc: linux-fbdev, xen-devel, gurudas.pai, guru.anbalagane,
greg.marsden, joe.jin, linux-kernel
Hi,
When get event channel by irq by irq, may irq is not a valid one under
some condition -- so far we found irq is -1 during suspend/resume, so
worth to validate it rather than return incorrect data.
Please review and comment.
Signed-off-by: Joe Jin <joe.jin@oracle.com>
Tested-by: Gurudas Pai <gurudas.pai@oracle.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
events.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index ac7b42f..006dd7b 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -175,6 +175,9 @@ static struct irq_info *info_for_irq(unsigned irq)
static unsigned int evtchn_from_irq(unsigned irq)
{
+ if (WARN(irq < 0 || irq >= nr_irqs, "Invalid irq %d!\n", irq))
+ return 0;
+
return info_for_irq(irq)->evtchn;
}
^ permalink raw reply related
* Re: Memory sharing issue by application on V4L2 based device
From: Michel Dänzer @ 2011-01-07 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinsduJkynwwEeM5K9f3D7C6jtBgkAyZ0-_0z2X-@mail.gmail.com>
On Fre, 2011-01-07 at 11:17 +0900, InKi Dae wrote:
> thank you for your comments.
>
> your second comment has no any problem as I said before, user virtual
> addess could be translated in page unit. but the problem, as you said,
> is that when cpu access to the memory in user mode, the memory
> allocated by malloc, page fault occurs so we can't find pfn to user
> virtual address. I missed that. but I think we could resolve this one.
>
> as before, user application allocates memory through malloc function
> and then send it to device driver(using userptr feature). if the pfn
> is null when device driver translated user virtual address in page
> unit then it allocates phsical memory in page unit using some
> interface such as alloc_page() and then mapping them. when pfn is
> null, to check it and allocate physical memory in page unit could be
> processed by videobuf2.
>
> of course, videobuf2 has no any duty considered for system mmu. so
> videobuf2 just provides callback for 3rd party and any platform with
> system mmu such as Samsung SoC C210 implements the function(allocating
> physical memory and mapping it) and registers it to callback of
> videobuf2. by doing so, I think your first comment could be cleared.
FWIW, TTM (drivers/gpu/drm/ttm, include/drm/ttm) is designed and used
for managing memory between CPU/GPU and kernel/userspace access. I
haven't looked at your requirements in detail, but if you haven't looked
at TTM yet, it sounds like it might be worth a look.
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: A query on frame buffers
From: Michel Dänzer @ 2011-01-07 9:00 UTC (permalink / raw)
To: Prasad Joshi; +Cc: linux-fbdev, dri-devel, Konrad Rzeszutek Wilk
In-Reply-To: <AANLkTim38gpvun=QwWcnwz719a2NYBcpiSvPYtgR6jMj@mail.gmail.com>
On Fre, 2011-01-07 at 02:42 +0000, Prasad Joshi wrote:
> On Mon, Dec 27, 2010 at 3:30 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Tue, Dec 21, 2010 at 04:51:04AM +0000, Prasad Joshi wrote:
> >> Hello All,
> >>
> >> This is probably my first mail on this mailing list. I am working on a
> >> university project on Nvidia or any GPU Pass-through in KVM. I have a
> >
> > You picking the hard ones first, eh? I would suggest you do Intel
> > or ATI as they have actually posted patches for this.
>
> Thanks a lot for your reply.
>
> Yes indeed, I started with the ATI Radeon RV370 card. Passing the
> Nvidia card is the ultimate aim of the project.
>
> >
> >> question related to framebuffer.
> >>
> >> I was reading few documents on XEN VGA pass-through, the document says
> >> the first step for pass-through is mapping the framebuffers in the VM
> >> at specific address, specifically speaking 0xA0000 till 0xC0000.
> >
> > I would suggest you look at the code - there have been some patches
> > posted by AMD engineers on xen-devel for this.
> >
>
> Yes I am looking at those patches as well, including some research
> papers on the same topic.
>
> Here is what I have tried so far.
> I have 2 graphics cards connected to my machine
> 1. Nvidia: This is being used by host machine.
> 2. ATI: Want to pass-through this card to the VM.
>
> I tried to pass-through the ATI card to VM. First, there was a problem
> with ROM BIOS. Then I passed a correct ROM BIOS to QEMU-KVM. Now when
> I start the VM with ATI card in pass-through mode.
>
> I see some garbage output on the monitor attached to the ATI card. I
> also saw following messages in the system log.
>
> [ 2.162294] [drm] Initialized drm 1.1.0 20060810
> [ 2.459594] [drm] radeon defaulting to kernel modesetting.
> [ 2.459596] [drm] radeon kernel modesetting enabled.
> [ 2.766698] radeon 0000:00:04.0: PCI INT A -> Link[LNKD] -> GSI 10
> (level, high) -> IRQ 10
> [ 2.766734] radeon 0000:00:04.0: setting latency timer to 64
> [ 2.783512] [drm] initializing kernel modesetting (RV380 0x1002:0x5B64).
> [ 2.792407] [drm] register mmio base: 0x40000000
> [ 2.792408] [drm] register mmio size: 65536
> [ 2.797177] [drm] Generation 2 PCI interface, using max accessible memory
> [ 2.797275] radeon 0000:00:04.0: VRAM: 128M 0x00000000F8000000 -
> 0x00000000FFFFFFFF (128M used)
> [ 2.797284] radeon 0000:00:04.0: GTT: 512M 0x00000000D8000000 -
> 0x00000000F7FFFFFF
> [ 2.798370] radeon 0000:00:04.0: irq 40 for MSI/MSI-X
> [ 2.870703] radeon 0000:00:04.0: radeon: using MSI.
> [ 3.151162] [drm] radeon: irq initialized.
> [ 3.151539] [drm] Detected VRAM RAM\x128M, BAR\x128M
> [ 3.151541] [drm] RAM width 128bits DDR
> [ 3.151610] [drm] radeon: 128M of VRAM memory ready
> [ 3.151611] [drm] radeon: 512M of GTT memory ready.
> [ 3.151627] [drm] GART: num cpu pages 131072, num gpu pages 131072
> [ 3.152701] [drm] radeon: 1 quad pipes, 1 Z pipes initialized.
> [ 3.544943] [drm] PCIE GART of 512M enabled (table at 0xF8040000).
> [ 3.548479] radeon 0000:00:04.0: WB enabled
> [ 3.549020] [drm] Loading R300 Microcode
> [ 3.554278] [drm] radeon: ring at 0x00000000D8001000
> [ 3.778476] [drm:r100_ring_test] *ERROR* radeon: ring test failed
> (sracth(0x15E4)=0xCAFEDEAD)
> [ 3.781010] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
> [ 3.782542] radeon 0000:00:04.0: failled initializing CP (-22).
> [ 3.784006] radeon 0000:00:04.0: Disabling GPU acceleration
> [ 3.793709] [drm] radeon: cp finalized
> [ 3.834875] radeon 0000:00:04.0: ffff8800320b4c00 unpin not necessary
> [ 3.841759] [drm] Radeon Display Connectors
> [ 3.841766] [drm] Connector 0:
> [ 3.841771] [drm] VGA
> [ 3.841777] [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
> [ 3.841781] [drm] Encoders:
> [ 3.841785] [drm] CRT1: INTERNAL_DAC1
> [ 3.841788] [drm] Connector 1:
> [ 3.841791] [drm] DVI-I
> [ 3.841794] [drm] HPD1
> [ 3.841799] [drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
> [ 3.841803] [drm] Encoders:
> [ 3.841806] [drm] CRT2: INTERNAL_DAC2
> [ 3.841809] [drm] DFP1: INTERNAL_TMDS1
> [ 6.158753] [drm] fb mappable at 0xF8040000
> [ 6.158756] [drm] vram apper at 0xF8000000
> [ 6.158757] [drm] size 5242880
> [ 6.158758] [drm] fb depth is 24
> [ 6.158759] [drm] pitch is 5120
> [ 13.914196] fb0: radeondrmfb frame buffer device
> [ 13.914198] drm: registered panic notifier
> [ 13.914683] [drm] Initialized radeon 2.7.0 20080528 for
> 0000:00:04.0 on minor 0
>
> The errors
>
> [ 3.778476] [drm:r100_ring_test] *ERROR* radeon: ring test failed
> (sracth(0x15E4)=0xCAFEDEAD)
> [ 3.781010] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
> [ 3.782542] radeon 0000:00:04.0: failled initializing CP (-22).
> [ 3.784006] radeon 0000:00:04.0: Disabling GPU acceleration
>
> Seem to be disabling GPU functionality. For now, I am interested in
> Graphics functionality of the ATI card and not GPGPU functionality.
>
> I will appreciate if you can help me with some information on solving
> this problem. Let me know if I should be asking this question on
> another forum. Please keep me in CC.
Looks like dri-devel material, added to CC.
As a first guess, maybe the system memory pages accessed by the GPU GART
aren't the same ones intended for this by the VM.
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: [patch] xenfb: fix xenfb suspend/resume race.
From: Ian Campbell @ 2011-01-07 9:17 UTC (permalink / raw)
To: Joe Jin
Cc: jeremy@goop.org, Andrew Morton, linux-fbdev@vger.kernel.org,
xen-devel@lists.xensource.com, gurudas.pai@oracle.com,
guru.anbalagane@oracle.com, greg.marsden@oracle.com,
linux-kernel@vger.kernel.org, Konrad Rzeszutek Wilk
In-Reply-To: <4D26B577.5060105@oracle.com>
On Fri, 2011-01-07 at 06:40 +0000, Joe Jin wrote:
> Hi,
>
> when do migration test, we hit the panic as below:
> <1>BUG: unable to handle kernel paging request at 0000000b819fdb98
> <1>IP: [<ffffffff812a588f>] notify_remote_via_irq+0x13/0x34
> <4>PGD 94b10067 PUD 0
> <0>Oops: 0000 [#1] SMP
> <0>last sysfs file: /sys/class/misc/autofs/dev
> <4>CPU 3
> <4>Modules linked in: autofs4(U) hidp(U) nfs(U) fscache(U) nfs_acl(U)
> auth_rpcgss(U) rfcomm(U) l2cap(U) bluetooth(U) rfkill(U) lockd(U) sunrpc(U)
> nf_conntrack_netbios_ns(U) ipt_REJECT(U) nf_conntrack_ipv4(U)
> nf_defrag_ipv4(U) xt_state(U) nf_conntrack(U) iptable_filter(U) ip_tables(U)
> ip6t_REJECT(U) xt_tcpudp(U) ip6table_filter(U) ip6_tables(U) x_tables(U)
> ipv6(U) parport_pc(U) lp(U) parport(U) snd_seq_dummy(U) snd_seq_oss(U)
> snd_seq_midi_event(U) snd_seq(U) snd_seq_device(U) snd_pcm_oss(U)
> snd_mixer_oss(U) snd_pcm(U) snd_timer(U) snd(U) soundcore(U)
> snd_page_alloc(U) joydev(U) xen_netfront(U) pcspkr(U) xen_blkfront(U)
> uhci_hcd(U) ohci_hcd(U) ehci_hcd(U)
> Pid: 18, comm: events/3 Not tainted 2.6.32
> RIP: e030:[<ffffffff812a588f>] [<ffffffff812a588f>]
> ify_remote_via_irq+0x13/0x34
> RSP: e02b:ffff8800e7bf7bd0 EFLAGS: 00010202
> RAX: ffff8800e61c8000 RBX: ffff8800e62f82c0 RCX: 0000000000000000
> RDX: 00000000000001e3 RSI: ffff8800e7bf7c68 RDI: 0000000bfffffff4
> RBP: ffff8800e7bf7be0 R08: 00000000000001e2 R09: ffff8800e62f82c0
> R10: 0000000000000001 R11: ffff8800e6386110 R12: 0000000000000000
> R13: 0000000000000007 R14: ffff8800e62f82e0 R15: 0000000000000240
> FS: 00007f409d3906e0(0000) GS:ffff8800028b8000(0000)
> GS:0000000000000000
> CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000b819fdb98 CR3: 000000003ee3b000 CR4: 0000000000002660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process events/3 (pid: 18, threadinfo ffff8800e7bf6000, task
> f8800e7bf4540)
> Stack:
> 0000000000000200 ffff8800e61c8000 ffff8800e7bf7c00 ffffffff812712c9
> <0> ffffffff8100ea5f ffffffff81438d80 ffff8800e7bf7cd0 ffffffff812714ee
> <0> 0000000000000000 ffffffff81270568 000000000000e030 0000000000010202
> Call Trace:
> [<ffffffff812712c9>] xenfb_send_event+0x5c/0x5e
> [<ffffffff8100ea5f>] ? xen_restore_fl_direct_end+0x0/0x1
> [<ffffffff81438d80>] ? _spin_unlock_irqrestore+0x16/0x18
> [<ffffffff812714ee>] xenfb_refresh+0x1b1/0x1d7
> [<ffffffff81270568>] ? sys_imageblit+0x1ac/0x458
> [<ffffffff81271786>] xenfb_imageblit+0x2f/0x34
> [<ffffffff8126a3e5>] soft_cursor+0x1b5/0x1c8
> [<ffffffff8126a137>] bit_cursor+0x4b6/0x4d7
> [<ffffffff8100ea5f>] ? xen_restore_fl_direct_end+0x0/0x1
> [<ffffffff81438d80>] ? _spin_unlock_irqrestore+0x16/0x18
> [<ffffffff81269c81>] ? bit_cursor+0x0/0x4d7
> [<ffffffff812656b7>] fb_flashcursor+0xff/0x111
> [<ffffffff812655b8>] ? fb_flashcursor+0x0/0x111
> [<ffffffff81071812>] worker_thread+0x14d/0x1ed
> [<ffffffff81075a8c>] ? autoremove_wake_function+0x0/0x3d
> [<ffffffff81438d80>] ? _spin_unlock_irqrestore+0x16/0x18
> [<ffffffff810716c5>] ? worker_thread+0x0/0x1ed
> [<ffffffff810756e3>] kthread+0x6e/0x76
> [<ffffffff81012dea>] child_rip+0xa/0x20
> [<ffffffff81011fd1>] ? int_ret_from_sys_call+0x7/0x1b
> [<ffffffff8101275d>] ? retint_restore_args+0x5/0x6
> [<ffffffff81012de0>] ? child_rip+0x0/0x20
> Code: 6b ff 0c 8b 87 a4 db 9f 81 66 85 c0 74 08 0f b7 f8 e8 3b ff ff ff c9
> c3 55 48 89 e5 48 83 ec 10 0f 1f 44 00 00 89 ff 48 6b ff 0c <8b> 87 a4 db 9f
> 81 66 85 c0 74 14 48 8d 75 f0 0f b7 c0 bf 04 00
> RIP [<ffffffff812a588f>] notify_remote_via_irq+0x13/0x34
> RSP <ffff8800e7bf7bd0>
> CR2: 0000000b819fdb98
> ---[ end trace 098b4b74827595d0 ]---
>
> The root cause of the panic is try to refresh xenfb when suspend/resume.
perhaps work "... between the resume and reconnecting to the backend."
into that sentence somewhere.
> Clear refresh flag of xenfb before disconnect backend would fix this issue.
s/refresh/update_wanted/
> Also below patch will fixed mem leak when connect to xenfb backend failed.
>
> Please review and comment.
>
> Signed-off-by: Joe Jin <joe.jin@oracle.com>
> Tested-by: Gurudas Pai <gurudas.pai@oracle.com>
Looks good. But please separate the mem leak fix into its own patch, it
has nothing to do with this crash (hiding a 1 line fix for a crash in
amongst 30 lines of something else does nobody any favours, as the
length of this thread testifies).
You can add
Acked-by: Ian Campbell <ian.campbell@citrix.com>
to the xenfb_disconnect_backend change once you've split it out.
I have some further comments on the xenfb_connect_backend change below.
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
>
> ---
> xen-fbfront.c | 21 +++++++++++++--------
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
> index dc72563..6f23797 100644
> --- a/drivers/video/xen-fbfront.c
> +++ b/drivers/video/xen-fbfront.c
> @@ -561,26 +561,24 @@ static void xenfb_init_shared_page(struct xenfb_info *info,
> static int xenfb_connect_backend(struct xenbus_device *dev,
> struct xenfb_info *info)
> {
> - int ret, evtchn;
> + int ret, evtchn, irq;
> struct xenbus_transaction xbt;
>
> ret = xenbus_alloc_evtchn(dev, &evtchn);
> if (ret)
> return ret;
> - ret = bind_evtchn_to_irqhandler(evtchn, xenfb_event_handler,
> + irq = bind_evtchn_to_irqhandler(evtchn, xenfb_event_handler,
> 0, dev->devicetype, info);
> - if (ret < 0) {
> + if (irq < 0) {
> xenbus_free_evtchn(dev, evtchn);
> xenbus_dev_fatal(dev, ret, "bind_evtchn_to_irqhandler");
> - return ret;
> + return irq;
> }
> - info->irq = ret;
> -
> again:
> ret = xenbus_transaction_start(&xbt);
> if (ret) {
> xenbus_dev_fatal(dev, ret, "starting transaction");
> - return ret;
> + goto unbind_irq;
> }
> ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
> virt_to_mfn(info->page));
> @@ -602,20 +600,27 @@ static int xenfb_connect_backend(struct xenbus_device *dev,
> if (ret = -EAGAIN)
> goto again;
> xenbus_dev_fatal(dev, ret, "completing transaction");
> - return ret;
> + goto unbind_irq;
> }
>
> xenbus_switch_state(dev, XenbusStateInitialised);
> + info->irq = irq;
> return 0;
>
> error_xenbus:
> xenbus_transaction_end(xbt, 1);
> xenbus_dev_fatal(dev, ret, "writing xenstore");
> + unbind_irq:
> + printk(KERN_ERR "xenfb_connect_backend failed!\n");
If anything this should be xenbus_dev_BLAH(). However all the places
which "goto unbind_irq" already include a xenbus_dev_fatal with more
specific context information and so does the case which falls through
from error_xenbus so I think this new message is redundant.
> + unbind_from_irqhandler(irq, info);
> + xenbus_free_evtchn(dev, evtchn);
unbind_from_irqhandler will also close the event channel for you so the
call to xenbus_free_evtchn is not necessary here.
Thanks,
Ian.
^ permalink raw reply
* Re: [patch] xen-event: validate irq before get evtchn by irq
From: Ian Campbell @ 2011-01-07 9:24 UTC (permalink / raw)
To: Joe Jin
Cc: jeremy@goop.org, Andrew Morton, linux-fbdev@vger.kernel.org,
xen-devel@lists.xensource.com, gurudas.pai@oracle.com,
guru.anbalagane@oracle.com, greg.marsden@oracle.com,
linux-kernel@vger.kernel.org
In-Reply-To: <4D26B7A4.9000209@oracle.com>
On Fri, 2011-01-07 at 06:50 +0000, Joe Jin wrote:
> Hi,
>
> When get event channel by irq by irq, may irq is not a valid one under
> some condition -- so far we found irq is -1 during suspend/resume, so
> worth to validate it rather than return incorrect data.
You've accidentally got "by irq" twice there and "may irq is not a valid
one" doesn't read quite right.
Perhaps something like:
"When getting an event channel from an IRQ if the IRQ is not valid then
warn and return an error in the form of the invalid event channel.
This catches errors such as trying to notify an IRQ before connecting to
the backend (e.g. during suspend/resume)."
> Please review and comment.
>
> Signed-off-by: Joe Jin <joe.jin@oracle.com>
> Tested-by: Gurudas Pai <gurudas.pai@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Thanks,
Ian.
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
>
> ---
> events.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index ac7b42f..006dd7b 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -175,6 +175,9 @@ static struct irq_info *info_for_irq(unsigned irq)
>
> static unsigned int evtchn_from_irq(unsigned irq)
> {
> + if (WARN(irq < 0 || irq >= nr_irqs, "Invalid irq %d!\n", irq))
> + return 0;
> +
> return info_for_irq(irq)->evtchn;
> }
>
>
^ permalink raw reply
* Re: Memory sharing issue by application on V4L2 based device driver
From: daeinki @ 2011-01-07 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294390465.6019.212.camel@thor.local>
Michel Dänzer 쓴 글:
> On Fre, 2011-01-07 at 11:17 +0900, InKi Dae wrote:
>> thank you for your comments.
>>
>> your second comment has no any problem as I said before, user virtual
>> addess could be translated in page unit. but the problem, as you said,
>> is that when cpu access to the memory in user mode, the memory
>> allocated by malloc, page fault occurs so we can't find pfn to user
>> virtual address. I missed that. but I think we could resolve this one.
>>
>> as before, user application allocates memory through malloc function
>> and then send it to device driver(using userptr feature). if the pfn
>> is null when device driver translated user virtual address in page
>> unit then it allocates phsical memory in page unit using some
>> interface such as alloc_page() and then mapping them. when pfn is
>> null, to check it and allocate physical memory in page unit could be
>> processed by videobuf2.
>>
>> of course, videobuf2 has no any duty considered for system mmu. so
>> videobuf2 just provides callback for 3rd party and any platform with
>> system mmu such as Samsung SoC C210 implements the function(allocating
>> physical memory and mapping it) and registers it to callback of
>> videobuf2. by doing so, I think your first comment could be cleared.
>
> FWIW, TTM (drivers/gpu/drm/ttm, include/drm/ttm) is designed and used
> for managing memory between CPU/GPU and kernel/userspace access. I
> haven't looked at your requirements in detail, but if you haven't looked
> at TTM yet, it sounds like it might be worth a look.
>
>
Thank you for your advice. I would look at TTM driver.
^ permalink raw reply
* [patch] xenfb: fix xenfb suspend/resume race.
From: Joe Jin @ 2011-01-07 10:17 UTC (permalink / raw)
To: jeremy, ian.campbell, Andrew Morton
Cc: linux-fbdev, xen-devel, gurudas.pai, guru.anbalagane,
greg.marsden, joe.jin, linux-kernel, Konrad Rzeszutek Wilk
In-Reply-To: <4D26B577.5060105@oracle.com>
Hi,
when do migration test, we hit the panic as below:
<1>BUG: unable to handle kernel paging request at 0000000b819fdb98
<1>IP: [<ffffffff812a588f>] notify_remote_via_irq+0x13/0x34
<4>PGD 94b10067 PUD 0
<0>Oops: 0000 [#1] SMP
<0>last sysfs file: /sys/class/misc/autofs/dev
<4>CPU 3
<4>Modules linked in: autofs4(U) hidp(U) nfs(U) fscache(U) nfs_acl(U)
auth_rpcgss(U) rfcomm(U) l2cap(U) bluetooth(U) rfkill(U) lockd(U) sunrpc(U)
nf_conntrack_netbios_ns(U) ipt_REJECT(U) nf_conntrack_ipv4(U)
nf_defrag_ipv4(U) xt_state(U) nf_conntrack(U) iptable_filter(U) ip_tables(U)
ip6t_REJECT(U) xt_tcpudp(U) ip6table_filter(U) ip6_tables(U) x_tables(U)
ipv6(U) parport_pc(U) lp(U) parport(U) snd_seq_dummy(U) snd_seq_oss(U)
snd_seq_midi_event(U) snd_seq(U) snd_seq_device(U) snd_pcm_oss(U)
snd_mixer_oss(U) snd_pcm(U) snd_timer(U) snd(U) soundcore(U)
snd_page_alloc(U) joydev(U) xen_netfront(U) pcspkr(U) xen_blkfront(U)
uhci_hcd(U) ohci_hcd(U) ehci_hcd(U)
Pid: 18, comm: events/3 Not tainted 2.6.32
RIP: e030:[<ffffffff812a588f>] [<ffffffff812a588f>]
ify_remote_via_irq+0x13/0x34
RSP: e02b:ffff8800e7bf7bd0 EFLAGS: 00010202
RAX: ffff8800e61c8000 RBX: ffff8800e62f82c0 RCX: 0000000000000000
RDX: 00000000000001e3 RSI: ffff8800e7bf7c68 RDI: 0000000bfffffff4
RBP: ffff8800e7bf7be0 R08: 00000000000001e2 R09: ffff8800e62f82c0
R10: 0000000000000001 R11: ffff8800e6386110 R12: 0000000000000000
R13: 0000000000000007 R14: ffff8800e62f82e0 R15: 0000000000000240
FS: 00007f409d3906e0(0000) GS:ffff8800028b8000(0000)
GS:0000000000000000
CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000b819fdb98 CR3: 000000003ee3b000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process events/3 (pid: 18, threadinfo ffff8800e7bf6000, task
f8800e7bf4540)
Stack:
0000000000000200 ffff8800e61c8000 ffff8800e7bf7c00 ffffffff812712c9
<0> ffffffff8100ea5f ffffffff81438d80 ffff8800e7bf7cd0 ffffffff812714ee
<0> 0000000000000000 ffffffff81270568 000000000000e030 0000000000010202
Call Trace:
[<ffffffff812712c9>] xenfb_send_event+0x5c/0x5e
[<ffffffff8100ea5f>] ? xen_restore_fl_direct_end+0x0/0x1
[<ffffffff81438d80>] ? _spin_unlock_irqrestore+0x16/0x18
[<ffffffff812714ee>] xenfb_refresh+0x1b1/0x1d7
[<ffffffff81270568>] ? sys_imageblit+0x1ac/0x458
[<ffffffff81271786>] xenfb_imageblit+0x2f/0x34
[<ffffffff8126a3e5>] soft_cursor+0x1b5/0x1c8
[<ffffffff8126a137>] bit_cursor+0x4b6/0x4d7
[<ffffffff8100ea5f>] ? xen_restore_fl_direct_end+0x0/0x1
[<ffffffff81438d80>] ? _spin_unlock_irqrestore+0x16/0x18
[<ffffffff81269c81>] ? bit_cursor+0x0/0x4d7
[<ffffffff812656b7>] fb_flashcursor+0xff/0x111
[<ffffffff812655b8>] ? fb_flashcursor+0x0/0x111
[<ffffffff81071812>] worker_thread+0x14d/0x1ed
[<ffffffff81075a8c>] ? autoremove_wake_function+0x0/0x3d
[<ffffffff81438d80>] ? _spin_unlock_irqrestore+0x16/0x18
[<ffffffff810716c5>] ? worker_thread+0x0/0x1ed
[<ffffffff810756e3>] kthread+0x6e/0x76
[<ffffffff81012dea>] child_rip+0xa/0x20
[<ffffffff81011fd1>] ? int_ret_from_sys_call+0x7/0x1b
[<ffffffff8101275d>] ? retint_restore_args+0x5/0x6
[<ffffffff81012de0>] ? child_rip+0x0/0x20
Code: 6b ff 0c 8b 87 a4 db 9f 81 66 85 c0 74 08 0f b7 f8 e8 3b ff ff ff c9
c3 55 48 89 e5 48 83 ec 10 0f 1f 44 00 00 89 ff 48 6b ff 0c <8b> 87 a4 db 9f
81 66 85 c0 74 14 48 8d 75 f0 0f b7 c0 bf 04 00
RIP [<ffffffff812a588f>] notify_remote_via_irq+0x13/0x34
RSP <ffff8800e7bf7bd0>
CR2: 0000000b819fdb98
---[ end trace 098b4b74827595d0 ]---
The root cause of race between the resume and reconnecting to the backend
Clear update_wanted flag of xenfb before disconnect backend would fix this issue.
Also below patch will fixed mem leak when connect to xenfb backend failed.
Signed-off-by: Joe Jin <joe.jin@oracle.com>
Tested-by: Gurudas Pai <gurudas.pai@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
xen-fbfront.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
index dc72563..f2d9eb5 100644
--- a/drivers/video/xen-fbfront.c
+++ b/drivers/video/xen-fbfront.c
@@ -616,6 +616,8 @@ static int xenfb_connect_backend(struct xenbus_device *dev,
static void xenfb_disconnect_backend(struct xenfb_info *info)
{
+ /* Prevent xenfb refresh */
+ info->update_wanted = 0;
if (info->irq >= 0)
unbind_from_irqhandler(info->irq, info);
info->irq = -1;
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox