Re: staging: udlfb -- staging version does not work, external does

Re: staging: udlfb -- staging version does not work, external does

[Pavel Machek]

Hi!

> Thanks for the bug report!

You are welcome :-).

> > I tried getting udlfb to work in 2.6.34-rc*, and could not.
> 
> What CPU arch are you on, and is it 32 or 64?

32bit Intel Core Duo.

> > 1) it hates vga console. If text-mode vga console is used (not
> > vesafb), system dies immeditaly during insmod or during boot if
> > monolithic kernel is used.
> 
> It is a kernel oops? Where does the crash happen?  Can you email any
> udlfb-specific output in logs (especially /var/log/kern.log)?

It just locks :-(.

> > 2) it does not display anything. With vesafb, it will not lockup the
> > system, and /dev/fb1 is created... Unfortunately, all I get is green
> > screen.
> 
> The green screen means udlfb has initialized device and started
> rendering.   So what this likely means is everything is fine -- just
> fbcon has matched against fb0, which is why it's not using the fb1
> udlfb screen.

Yep, but I still should be able to produce output on it.

> > (I tried testing with cat /bin/bash > /dev/fb1 and cat /dev/fb0 >
> > /dev/fb1).
> 
> I don't think redirects like that will work.  The fbcon module loads
> against one fb, and can only be switch with utilities like "fbset"

IMO they should work. First one should fill the screen with ~random
noise, and second should copy graphical representation on fb0 to
fb1. If they have same resolution and color depth, I should be looking
at copy of my console...

(And it does work with this driver:

> > So I tried
> >
> >    Roberto De Ioris roberto at unbit.it
> >    Wed Jun 10 08:00:07 PDT 2009 

).

								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: staging: udlfb -- staging version does not work, external does

[Pavel Machek]

Hi!

> Thanks for the bug report!

Thanks for trying to solve it :-).

> > (I tried testing with cat /bin/bash > /dev/fb1 and cat /dev/fb0 >
> > /dev/fb1).
> 
> I don't think redirects like that will work.  The fbcon module loads
> against one fb, and can only be switch with utilities like "fbset"
> 
> > So I tried
> >
> >    Roberto De Ioris roberto at unbit.it
> >    Wed Jun 10 08:00:07 PDT 2009
> 
> It's good to know Roberto's works. This will be a solvable problem.
> 
> OK - this may be this bug (fixed at
> http://git.plugable.com/gitphp/index.php?p=udlfb&a=commit&h=ac7f578b51ce5738386b571d096da4d8889c48e0).
>  Can you try latest udlfb (git clone
> http://git.plugable.com/webdav/udlfb ) to see if that's it?

I tried with that patch, no change. dmesg from insmod and cat /dev/fb0
> /dev/fb1 attempt are:

Apr 11 18:39:02 amd kernel: udlfb: module is from the staging
directory, the quality is unknown, you have been warned.
Apr 11 18:39:02 amd kernel: udlfb 1-1:1.0: usb_probe_interface
Apr 11 18:39:02 amd kernel: udlfb 1-1:1.0: usb_probe_interface - got
id
Apr 11 18:39:02 amd kernel: usb 1-1: dlfb: allocated 4 65024 byte urbs
Apr 11 18:39:02 amd kernel: usb 1-1: dlfb: set_par mode 1024x768
Apr 11 18:39:02 amd kernel: usb 1-1: dlfb: DisplayLink USB device
/dev/fb1 attached. 1024x768 resolution. Using 3072K framebuffer memory
Apr 11 18:39:02 amd kernel: usbcore: registered new interface driver
udlfb
Apr 11 18:39:02 amd kernel: VMODES initialized
Apr 11 18:39:08 amd kernel: usb 1-1: dlfb: open /dev/fb1 user=1
fb_info=f5087bf0 count=1
Apr 11 18:39:08 amd kernel: usb 1-1: dlfb: release /dev/fb1 user=1
count=0

I tried to play with /dev/fb1 a bit more:

root@amd:~# cat /dev/zero > /dev/fb1
cat: write error: No space left on device
root@amd:~# cat /dev/fb1
root@amd:~# echo ahoj > /dev/fb1
root@amd:~# cat /dev/fb1
ahoj
root@amd:~#

...but still not change on usb connected display, and nothing really
interesting in dmesg:

Apr 11 18:41:39 amd kernel: usb 1-1: dlfb: open /dev/fb1 user=1
fb_info=f5087bf0 count=1
Apr 11 18:41:40 amd kernel: usb 1-1: dlfb: release /dev/fb1 user=1
count=0
Apr 11 18:41:46 amd kernel: usb 1-1: dlfb: open /dev/fb1 user=1
fb_info=f5087bf0 count=1
Apr 11 18:41:46 amd kernel: usb 1-1: dlfb: release /dev/fb1 user=1
count=0
Apr 11 18:41:51 amd kernel: usb 1-1: dlfb: open /dev/fb1 user=1
fb_info=f5087bf0 count=1
Apr 11 18:41:51 amd kernel: usb 1-1: dlfb: release /dev/fb1 user=1
count=0
Apr 11 18:41:52 amd kernel: usb 1-1: dlfb: open /dev/fb1 user=1
fb_info=f5087bf0 count=1
Apr 11 18:41:53 amd kernel: usb 1-1: dlfb: release /dev/fb1 user=1
count=0
Apr 11 18:41:59 amd kernel: usb 1-1: dlfb: open /dev/fb1 user=1
fb_info=f5087bf0 count=1
Apr 11 18:41:59 amd kernel: usb 1-1: dlfb: release /dev/fb1 user=1
count=0
Apr 11 18:42:01 amd kernel: usb 1-1: dlfb: open /dev/fb1 user=1
fb_info=f5087bf0 count=1
Apr 11 18:42:01 amd kernel: usb 1-1: dlfb: release /dev/fb1 user=1
count=0


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: staging: udlfb -- staging version does not work, external does

[Bernie Thompson]

Pavel,

There are two separate issues you're discussing. Can you check the
lockup issue with the git.plugable.com code?

Thanks,
Bernie

On Sun, Apr 11, 2010 at 9:42 AM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> Thanks for the bug report!
>
> Thanks for trying to solve it :-).
>
>> > (I tried testing with cat /bin/bash > /dev/fb1 and cat /dev/fb0 >
>> > /dev/fb1).
>>
>> I don't think redirects like that will work.  The fbcon module loads
>> against one fb, and can only be switch with utilities like "fbset"
>>
>> > So I tried
>> >
>> >    Roberto De Ioris roberto at unbit.it
>> >    Wed Jun 10 08:00:07 PDT 2009
>>
>> It's good to know Roberto's works. This will be a solvable problem.
>>
>> OK - this may be this bug (fixed at
>> http://git.plugable.com/gitphp/index.php?p=udlfb&a=commit&h=ac7f578b51ce5738386b571d096da4d8889c48e0).
>>  Can you try latest udlfb (git clone
>> http://git.plugable.com/webdav/udlfb ) to see if that's it?
>
> I tried with that patch, no change. dmesg from insmod and cat /dev/fb0
>> /dev/fb1 attempt are:
>
> Apr 11 18:39:02 amd kernel: udlfb: module is from the staging
> directory, the quality is unknown, you have been warned.
> Apr 11 18:39:02 amd kernel: udlfb 1-1:1.0: usb_probe_interface
> Apr 11 18:39:02 amd kernel: udlfb 1-1:1.0: usb_probe_interface - got
> id
> Apr 11 18:39:02 amd kernel: usb 1-1: dlfb: allocated 4 65024 byte urbs
> Apr 11 18:39:02 amd kernel: usb 1-1: dlfb: set_par mode 1024x768
> Apr 11 18:39:02 amd kernel: usb 1-1: dlfb: DisplayLink USB device
> /dev/fb1 attached. 1024x768 resolution. Using 3072K framebuffer memory
> Apr 11 18:39:02 amd kernel: usbcore: registered new interface driver
> udlfb
> Apr 11 18:39:02 amd kernel: VMODES initialized
> Apr 11 18:39:08 amd kernel: usb 1-1: dlfb: open /dev/fb1 user=1
> fb_info=f5087bf0 count=1
> Apr 11 18:39:08 amd kernel: usb 1-1: dlfb: release /dev/fb1 user=1
> count=0
>
> I tried to play with /dev/fb1 a bit more:
>
> root@amd:~# cat /dev/zero > /dev/fb1
> cat: write error: No space left on device
> root@amd:~# cat /dev/fb1
> root@amd:~# echo ahoj > /dev/fb1
> root@amd:~# cat /dev/fb1
> ahoj
> root@amd:~#
>
> ...but still not change on usb connected display, and nothing really
> interesting in dmesg:
>
> Apr 11 18:41:39 amd kernel: usb 1-1: dlfb: open /dev/fb1 user=1
> fb_info=f5087bf0 count=1
> Apr 11 18:41:40 amd kernel: usb 1-1: dlfb: release /dev/fb1 user=1
> count=0
> Apr 11 18:41:46 amd kernel: usb 1-1: dlfb: open /dev/fb1 user=1
> fb_info=f5087bf0 count=1
> Apr 11 18:41:46 amd kernel: usb 1-1: dlfb: release /dev/fb1 user=1
> count=0
> Apr 11 18:41:51 amd kernel: usb 1-1: dlfb: open /dev/fb1 user=1
> fb_info=f5087bf0 count=1
> Apr 11 18:41:51 amd kernel: usb 1-1: dlfb: release /dev/fb1 user=1
> count=0
> Apr 11 18:41:52 amd kernel: usb 1-1: dlfb: open /dev/fb1 user=1
> fb_info=f5087bf0 count=1
> Apr 11 18:41:53 amd kernel: usb 1-1: dlfb: release /dev/fb1 user=1
> count=0
> Apr 11 18:41:59 amd kernel: usb 1-1: dlfb: open /dev/fb1 user=1
> fb_info=f5087bf0 count=1
> Apr 11 18:41:59 amd kernel: usb 1-1: dlfb: release /dev/fb1 user=1
> count=0
> Apr 11 18:42:01 amd kernel: usb 1-1: dlfb: open /dev/fb1 user=1
> fb_info=f5087bf0 count=1
> Apr 11 18:42:01 amd kernel: usb 1-1: dlfb: release /dev/fb1 user=1
> count=0
>
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>

Re: staging: udlfb -- staging version does not work, external does

[Pavel Machek]

On Sun 2010-04-11 10:01:34, Bernie Thompson wrote:
> Pavel,
> 
> There are two separate issues you're discussing. Can you check the
> lockup issue with the git.plugable.com code?

Not easily, can we debug the "framebuffer does not work at all" before
debugging the "it also crashes the machine when compiled in" issue?

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: staging: udlfb -- staging version does not work, external does

[Pavel Machek]

On Sun 2010-04-11 10:05:12, Bernie Thompson wrote:
> Roberto - why would any mmap'd writes get immediately displayed on the
> older code?  I wouldn't expect that.
> 
> I'm assuming this is mmio path, and that there's no triggers for
> repaint in the older code?
> 
> Pavel - the issue for mmio access is when to trigger repaint.

I'm not doing any memory mapped access (that's what mmio means,
right?). I even checked with strace -- cat uses plain old
read()/write() syscalls.

cat /bin/bash > /dev/fb1

(can you try it on your system? do we agree that it should fill cca
half of screen with noise?)

> Repainting the entire screen is extremely expensive, and mmio doesn't
> have any built-in trigger point.  This issue is what the whole defio
> circus (page-fault based trigger) has been about for the last few
> months.  Some history at:  http://plugable.com/category/project/udlfb/

Ok, I'll take a look.... ...

   Todo

(this should really go to udlfb/TODO).

  ...
     * Disable defio by default, unfortunately, because of several
bugs without obvious solutions
          * rendering problems with pages (lines) that no longer get
updated - writes to those are
            no longer triggering deferred processing
          * When running 2 USB adapters, dirty pages for one instance
seem to affect the other, and
            vice versa (udlfb has no common state, so appears to be in
defio or mmu handling)
          * cases where we hit a kernel oops in the deferred io
handler when it tries to touch the
            pages it's been asked to handle.
  ...

Aha, so this one is even known. How do I re-enable defio support, so
that it can be debugged?

And... can we do something stupid like full repaint once a second to
get basically working driver?

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: staging: udlfb -- staging version does not work, external does

[Pavel Machek]

Hi!

> >> I don't think redirects like that will work.  The fbcon module loads
> >> against one fb, and can only be switch with utilities like
> >> "fbset"

I tried playing with fbset, but it seems to only set
videomodes. Ideally, I'd like to send kernel consoles to /dev/fb1, but
that does not seem possible.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: staging: udlfb -- staging version does not work, external does

[Bernie Thompson]

Hi Pavel,

Thanks again for reporting this.

Because neither X nor fbcon uses the char read/write path, this broke
a while ago and it didn't get noticed.  I even highlighted this case
when trying to enumerate the different fbdev access models
(http://plugable.com/2010/01/30/linux-kernel-framebuffer-rendering-apis/
), yet still botched it.

But this is definitely something that should work, as it's a nice way
to drop a test image to hardware when perf doesn't matter.

A patch which restores the functionality is here:
http://git.plugable.com/gitphp/index.php?p=udlfb&a=commitdiff&h=cd5e3761bb6b0132ba72d45b26ff55d22c9d727b

Will get it cleaned up and moving downstream.  Any feedback is welcome.

On fbcon -- sorry its con2fbmap, not fbset, to look for how to assign
a console to a framebuffer. fbcon uses blit and copy operations, so it
doesn't hit the paths you're seeing problems on.

On defio -- it would be great to get experienced help with the
problems we've been having there.  Defio is essential for standard
mmap clients (xf86-video-fbdev, kdrive, or fbi, etc.) when we have a
system memory framebuffer like this -- timer-based updates aren't
practical, as there's just too much data involved here, so the system
load is unacceptable if we're entirely ignorant of what pixels are
changing.  Defio's page-fault-based dirty detection is a nice
compromise.

Testing defio to recreate the problems is easy, just use any of the
standard fbdev clients mentioned above.  Defio is enabled by default
in 2.6.34 as it stands.  Defio can also be enabled/disabled with a
switch in the code.
http://git.plugable.com/gitphp/index.php?p=udlfb&a=commitdiff&h=38e6da578178f439e6613d27fa946c0107394420
to see example of switching it.

We don't have enough eyes on these problems, because most people are
using udlfb with the custom X server written to it, which doesn't hit
any of these issues.

Again, any feedback, suggestions, or udlfb patches (direct to the
staging tree or here) are very welcome.

Thanks,
Bernie
http://plugable.com/