staging: udlfb -- staging version does not work, external does
in [Kernel]
|
Prev: hid: add suspend/resume hooks for hid drivers
Next: Lockup inside of stop_machine() during modprobe aes (was Re: Another AR5008 hang)
From: Pavel Machek on 11 Apr 2010 11:10 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pavel Machek on 11 Apr 2010 12:50 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(a)amd:~# cat /dev/zero > /dev/fb1 cat: write error: No space left on device root(a)amd:~# cat /dev/fb1 root(a)amd:~# echo ahoj > /dev/fb1 root(a)amd:~# cat /dev/fb1 ahoj root(a)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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pavel Machek on 11 Apr 2010 13:10 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Bernie Thompson on 11 Apr 2010 13:10 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(a)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(a)amd:~# cat /dev/zero > /dev/fb1 > cat: write error: No space left on device > root(a)amd:~# cat /dev/fb1 > root(a)amd:~# echo ahoj > /dev/fb1 > root(a)amd:~# cat /dev/fb1 > ahoj > root(a)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 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pavel Machek on 11 Apr 2010 13:20
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |