Framebuffer, mmap(), hanging in D state, root FS unmount failure.
#include <assert.h>
#include <sys/mman.h>
#include <fcntl.h>
int main(void)
{
char *p;
assert((p = mmap(0, 1, PROT_READ|PROT_WRITE, MAP_SHARED, open("/dev/fb/0", O_RDWR), 0)) != MAP_FAILED);
p[4096] = 0; /* this hangs */
return 0;
}When I run this on my 2.4.17rc2aa2 kernel with a Voodoo3000 framebuffer, the process hangs forever in D state. ps and top will then hang the same way when they read the /proc/pid files for the hung process. And my root filesystem won't unmount.
It only happens when PROT_READ|PROT_WRITE is specified - when I use only PROT_WRITE, the program segfaults like you'd expect.... but once the PROT_READ|PROT_WRITE version has hung, PROT_WRITE-only versions will also hang.
Quoted 12 lines · Mark J Roberts
#include <
assert.h>
#include <sys/mman.h>
#include <fcntl.h>
int main(void){ char *p; assert((p = mmap(0, 1, PROT_READ|PROT_WRITE, MAP_SHARED, open("/dev/fb/0", O_RDWR), 0)) != MAP_FAILED); p[4096] = 0; /* this hangs */ return 0; }
Quoted 5 lines
When I run this on my 2.4.17rc2aa2 kernel with a Voodoo3000 framebuffer, the process hangs forever in D state. ps and top will then hang the same way when they read the
/proc/pidfiles for the hung process. And my root filesystem won't unmount.
OK, the framebuffer driver is failing to mark the mmapped vma as VM_IO, so the kernel is trying to dump the framebuffer device to the core file, takes a recursive fault and deadlocks.
Simplest possible fix is to mark the framebuffer as not dumpable for x86.
drivers/video/fbmem.c +1 -0
@@ -600,6 +600,7 @@ fb_mmap(struct file *file, struct vm_are#elif defined(__alpha__)/* Caching is off in the I/O space quadrant by design. */ #elif defined(__i386__) || defined(__x86_64__) + vma->vm_flags |=VM_IO ;if (boot_cpu_data.x86 >3 )pgprot_val (vma->vm_page_prot) |= _PAGE_PCD;#elif defined(__mips__)
However I don't see why _any_ architecture wants framebuffer contents to be included in core files. It sounds risky.
So the setting of VM_IO could be simply hoisted outside the forest of ifdefs. Comments, anyone?
-
Quoted 6 lines · Andrew Morton
However I don't see why _any_ architecture wants framebuffer contents to be included in core files. It sounds risky.
So the setting of
VM_IOcould be simply hoisted outside the forest of ifdefs. Comments, anyone?
Well nobody has objected....
The patch marks fbdev mappings as VM_IO for *all* architectures.
This prevents a kernel deadlock (mmap_sem) which occurs on x86 when a program which has mmapped an fbdev tries to dump core.
drivers/video/fbmem.c +2 -3
@@ -576,12 +576,13 @@ fb_mmap(struct file *file, struct vm_arereturn -EINVAL ; off += start; vma->vm_pgoff = off >>PAGE_SHIFT ; +/* This is an IO map - tell maydump to skip this VMA */ + vma->vm_flags |=VM_IO ;#if defined(__sparc_v9__) vma->vm_flags |= (VM_SHM |VM_LOCKED );if (io_remap_page_range (vma->vm_start, off, vma->vm_end - vma->vm_start, vma->vm_page_prot,0 ))return -EAGAIN ; - vma->vm_flags |=VM_IO ;#else #if defined(__mc68000__)#if defined(CONFIG_SUN3 )
@@ -607,8 +608,6 @@ fb_mmap(struct file *file, struct vm_arepgprot_val (vma->vm_page_prot) |= _CACHE_UNCACHED;#elif defined(__arm__) vma->vm_page_prot =pgprot_noncached (vma->vm_page_prot); -/* This is an IO map - tell maydump to skip this VMA */ - vma->vm_flags |=VM_IO ;#elif defined(__sh__)pgprot_val (vma->vm_page_prot) &= ~_PAGE_CACHABLE;#else
-
Re: [patch] Re: Framebuffer...Why oh Why???
In reply to Mark J RobertsQuoted 4 lines · Andrew Morton
Quoted 3 lines · Andrew Morton
However I don't see why _any_ architecture wants framebuffer contents to be included in core files. It sounds risky.
[snip]
When X11 locks up, I can still kill it and my box lives. When
framebuffers crash, their is no recovery save rebooting. Back in 1995 I thought that linux VTs and X11 implemenation blew Solaris out of the water, and now we want throw away our progress? I'm still astounded by the whole "oooh I can see a penquin while I boot-up" thing? Granted, frame buffers have usage in embedded systems, but do they really have to be so deeply integrated??
Signature · 1 line
[email protected].
Re: [patch] Re: Framebuffer...Why oh Why???
Quoted 8 lines · Timothy Covell
When X11 locks up, I can still kill it and my box lives. When
framebuffers crash, their is no recovery save rebooting. Back in 1995 I thought that linux VTs and X11 implemenation blew Solaris out of the water, and now we want throw away our progress? I'm still astounded by the whole "oooh I can see a penquin while I boot-up" thing? Granted, frame buffers have usage in embedded systems, but do they really have to be so deeply integrated??
They aren't.
No sane person should use frame buffers if they have the choice.
Like your mama told you: "Just say no". Use text-mode and X11, and be happy.
Some people don't have the choice, of course.
Linus
Re: [Linux-fbdev-devel] Re: [patch] Re: Framebuffer...Why oh Why???
Quoted 4 lines
Quoted 3 lines
Granted, frame buffers have usage in embedded systems, but do they really have to be so deeply integrated??
Quoted 8 lines
They aren't.
No sane person should use frame buffers if they have the choice.
Like your mama told you: "Just say no". Use text-mode and X11, and be happy.
Some people don't have the choice, of course.
Some. Try pretty much every platform except ix86. Plus now that M$ doesn't support DOS you are starting to see graphics card manufactures dropping VGA support. Even BIOS setup interfaces use the VESA graphics interface these days. So VGA text days are numbered. I agree the framebuffer/console layer really needs to reworked to do the right things. I plan to do that for 2.5.X.
Re: [patch] Re: Framebuffer...Why oh Why???
In reply to Linus TorvaldsQuoted 11 lines · Timothy Covell
Quoted 8 lines
When X11 locks up, I can still kill it and my box lives. When
framebuffers crash, their is no recovery save rebooting. Back in 1995 I thought that linux VTs and X11 implemenation blew Solaris out of the water, and now we want throw away our progress? I'm still astounded by the whole "oooh I can see a penquin while I boot-up" thing? Granted, frame buffers have usage in embedded systems, but do they really have to be so deeply integrated??
Quoted 8 lines
They aren't.
No sane person should use frame buffers if they have the choice.
Like your mama told you: "Just say no". Use text-mode and X11, and be happy.
Some people don't have the choice, of course.
Heh... well, text mode isn't that nice regarding the need for having the "ISA memory" window available on the bus, and in general, those legacy ISA memory and IO space needed by VGA text mode are rather a painful pile of hack to carry on on non-x86 platforms ;)
And just my 2 cents: X11 is perfectly able to lock up the box solid. It has root access to /dev/mem, it has direct access to video card registers, that is enough to lockup the bus in quite a number of cases (shame on nasty hardware). Add to that DRI with it's kernel module and bus mastering hardware, and you obtain something with has as much chances as fbdev to kill your box once it starts behaving erratically.
Ben.
Re: [patch] Re: Framebuffer...Why oh Why???
In reply to Linus TorvaldsQuoted 22 lines · Linus Torvalds
Date: Sun, 30 Dec 2001 16:19:15 -0800 (PST)
From: Linus Torvalds <[email protected]>
To: Timothy Covell <[email protected]>
Cc: Andrew Morton <[email protected]>, [email protected],
Linux Frame Buffer Device Development
<[email protected]>,
Marcelo Tosatti <[email protected]>
Subject: Re: [patch] Re: Framebuffer...Why oh Why???Quoted 8 lines · Timothy Covell
When X11 locks up, I can still kill it and my box lives. When
framebuffers crash, their is no recovery save rebooting. Back in 1995 I thought that linux VTs and X11 implemenation blew Solaris out of the water, and now we want throw away our progress? I'm still astounded by the whole "oooh I can see a penquin while I boot-up" thing? Granted, frame buffers have usage in embedded systems, but do they really have to be so deeply integrated??They aren't.
Quoted 8 lines
No sane person should use frame buffers if they have the choice.
Like your mama told you: "Just say no". Use text-mode and X11, and be happy.
Some people don't have the choice, of course.
Linus
Like the no choice if having one's 11 year old syster try to use the thing?
Text-mode and X11 seem to work fine if you walk on egg shells but just try switching from console to text mode and back again several times. Eventually it _will_ crash. Or worse yet mix svgalib and X11.
My brother and sister both used to crash my system at least 3 times a week before framebuffer + fbdev came into play.
Gerhard
--
Gerhard Mack
<>< As a computer I find your faith in technology amusing.
Re: [patch] Re: Framebuffer...Why oh Why???
In reply to Linus TorvaldsQuoted 11 lines · Linus Torvalds
Quoted 7 lines · Timothy Covell
When X11 locks up, I can still kill it and my box lives. When
framebuffers crash, their is no recovery save rebooting. Back in 1995 I thought that linux VTs and X11 implemenation blew Solaris out of the water, and now we want throw away our progress? I'm still astounded by the whole "oooh I can see a penquin while I boot-up" thing? Granted, frame buffers have usage in embedded systems, but do they really have to be so deeply integrated??They aren't.
Quoted 8 lines
No sane person should use frame buffers if they have the choice.
Like your mama told you: "Just say no". Use text-mode and X11, and be happy.
Some people don't have the choice, of course.
Linus
X11 isn't always an improvement. I've got an X hang on my laptop (about once a week) that freezes the keyboard and ignores mouse clicks. Numlock doesn't change the keyboard LEDs, CTRL-ALT-BACKSPACE won't do a thing, and although I can ssh in and run top (and see the CPU-eating loop), kill won't take X down and kill-9 leaves the video display up so the console that thinks it's in text mode, but isn't, is still useless. (And that's assuming I'm plugged into the network and have another box around to ssh in from...)
Compiling a debug version of X to run under gdb via ssh is on my to-do list...
A userspace program that takes over your main I/O devices modally and keeps them if it hangs isn't THAT much better than having the kernel ignore you directly...
Rob
Re: [patch] Re: Framebuffer...Why oh Why???
Quoted 29 lines · Rob Landley
Quoted 11 lines · Linus Torvalds
Quoted 7 lines · Timothy Covell
When X11 locks up, I can still kill it and my box lives. When
framebuffers crash, their is no recovery save rebooting. Back in 1995 I thought that linux VTs and X11 implemenation blew Solaris out of the water, and now we want throw away our progress? I'm still astounded by the whole "oooh I can see a penquin while I boot-up" thing? Granted, frame buffers have usage in embedded systems, but do they really have to be so deeply integrated??They aren't.
Quoted 8 lines
No sane person should use frame buffers if they have the choice.
Like your mama told you: "Just say no". Use text-mode and X11, and be happy.
Some people don't have the choice, of course.
Linus
X11 isn't always an improvement. I've got an X hang on my laptop (about once a week) that freezes the keyboard and ignores mouse clicks. Numlock doesn't change the keyboard LEDs, CTRL-ALT-BACKSPACE won't do a thing, and although I can ssh in and run top (and see the CPU-eating loop), kill won't take X down and kill-9 leaves the video display up so the console that thinks it's in text mode, but isn't, is still useless. (And that's assuming I'm plugged into the network and have another box around to ssh in from...)
Quoted 5 lines
Compiling a debug version of X to run under gdb via ssh is on my to-do list...
A userspace program that takes over your main I/O devices modally and keeps them if it hangs isn't THAT much better than having the kernel ignore you directly...
I'm having the exact same problems on my ThinkPad 390X. Sometimes it freezes several times a day with the exact same symptoms. RedHat 6.2 worked fine on this laptop. The problems started with 7.1 which uses XFree86 4.0, and it didn't get better with 7.2 (XFree86 4.1). What makes it even worse is that after a warm reboot, the screen and keyboard locks up again as soon as gdm gets started (Numlock doesn't work etc.). So I always have to turn off the power to get the laptop working again.
Werner
Re: [patch] Re: Framebuffer...Why oh Why???
On Tue, 1 Jan 2002 02:00:01 -0500 (EST), Werner Puschitz <[email protected]> wrote:
[...]
Quoted 8 lines
I'm having the exact same problems on my ThinkPad 390X. Sometimes it freezes several times a day with the exact same symptoms. RedHat 6.2 worked fine on this laptop. The problems started with 7.1 which uses XFree86 4.0, and it didn't get better with 7.2 (XFree86 4.1). What makes it even worse is that after a warm reboot, the screen and keyboard locks up again as soon as gdm gets started (Numlock doesn't work etc.). So I always have to turn off the power to get the laptop working again.
A similar things happened to me. I have a Toshiba Satellite 4080 XCDT, and switching from XFree to console and back to XFree becomed impossibile with the upgrade to Redhat 7.x and XFree 4. The problem is that the apm script use to switch to console mode when I suspend (es. closing the laptop) and when it resumes it tries to switch to XFree again, but this messes the screen. I am still able to come back to console and killall X, but of course I'll lose my current not saved works under X.
Under XFree 3 I could switch from X to console and back without problems - anyway, after a couple of switches my laptop used to hang. I think X writes to the uncorrect memory regions causing my laptop to hang.
ciao
Signature · 3 lines
Marco Ermini http://www.markoer.org Perche' perdere tempo ad imparare quando l'ignoranza e' istantanea? (Hobbes)
[OT] Re: [patch] Re: Framebuffer...Why oh Why???
Quoted 18 lines
[...]
Quoted 8 lines
I'm having the exact same problems on my ThinkPad 390X. Sometimes it freezes several times a day with the exact same symptoms. RedHat 6.2 worked fine on this laptop. The problems started with 7.1 which uses XFree86 4.0, and it didn't get better with 7.2 (XFree86 4.1). What makes it even worse is that after a warm reboot, the screen and keyboard locks up again as soon as gdm gets started (Numlock doesn't work etc.). So I always have to turn off the power to get the laptop working again.
A similar things happened to me. I have a Toshiba Satellite 4080 XCDT, and switching from XFree to console and back to XFree becomed impossibile with the upgrade to Redhat 7.x and XFree 4. The problem is that the apm script use to switch to console mode when I suspend (es. closing the laptop) and when it resumes it tries to switch to XFree again, but this messes the screen. I am still able to come back to console and killall X, but of course I'll lose my current not saved works under X.
Quoted 3 lines
Under XFree 3 I could switch from X to console and back without problems - anyway, after a couple of switches my laptop used to hang. I think X writes to the uncorrect memory regions causing my laptop to hang.
This really is offtopic, because the above symptoms are caused solely by XFree 4.1. The was discussion about this in XFree mailing lists.
A quick fix is to get a newer RedHat Rawhide XFree86 rpm (atleast 4.1.0-8 and later have that bug fixed) or better yet get a newer tarball of X from xfree86.org
yers,
another member of "Linux on a Toshiba Satellite 4080xcdt (TM)" :)
Signature · 3 lines
Tommi "Kynde" Kyntola
/* A man alone in the forest talking to himself and
no women around to hear him. Is he still wrong? */Re: [OT] Re: [patch] Re: Framebuffer...Why oh Why???
On Fri, 4 Jan 2002 15:27:03 +0200 (EET), Tommi Kyntola <[email protected]> wrote:
[...]
Quoted 12 lines
Quoted 11 lines
A similar things happened to me. I have a Toshiba Satellite 4080 XCDT, and switching from XFree to console and back to XFree becomed impossibile with the upgrade to Redhat 7.x and XFree 4. The problem is that the apm script use to switch to console mode when I suspend (es. closing the laptop) and when it resumes it tries to switch to XFree again, but this messes the screen. I am still able to come back to console and killall X, but of course I'll lose my current not saved works under X.
Under XFree 3 I could switch from X to console and back without problems - anyway, after a couple of switches my laptop used to hang. I think X writes to the uncorrect memory regions causing my laptop to hang.
Quoted 6 lines
This really is offtopic, because the above symptoms are caused solely by XFree 4.1. The was discussion about this in XFree mailing lists.
A quick fix is to get a newer RedHat Rawhide XFree86 rpm (atleast 4.1.0-8 and later have that bug fixed) or better yet get a newer tarball of X from xfree86.org
Anyway, thanks. I'll try it when I'll have a fast connection next week (it's more than 18 MB download).
Quoted 2 lines
yers,
another member of "Linux on a Toshiba Satellite 4080xcdt (TM)" :)
You are missing "proud" ;-)
thanks
Signature · 4 lines
Marco Ermini http://www.markoer.org Never attribute to malice that which is adequately explained by stupidity. (a sig from Slashdot postings)
Re: [patch] Re: Framebuffer...Why oh Why???
In reply to Linus TorvaldsQuoted 5 lines · Linus Torvalds
No sane person should use frame buffers if they have the choice.
Like your mama told you: "Just say no". Use text-mode and X11, and be happy.
But how else can I get a legible 128x48 console on a 1024x768 display
? 8-)
Ken
Signature · 3 lines
The crypt() function is unimplemented due to excessive paranoia. 2.4.17-preempt 12:20am up 2:08, 1 user, load average: 0.00, 0.00, 0.00
Re: [patch] Re: Framebuffer...Why oh Why???
Quoted 10 lines · Ken Moffat
Quoted 4 lines · Linus Torvalds
No sane person should use frame buffers if they have the choice.
Like your mama told you: "Just say no". Use text-mode and X11, and be happy.
But how else can I get a legible 128x48 console on a 1024x768 display
? 8-)Ken
Those 132 char wide displays are great when I connect to the Vax that I keep in the basement. Oh wait, I haven't used a Vax in three years. I sure do miss executive mode, that made feel a big and useless fat cat. ;-)
Signature · 1 line
[email protected].
Re: [patch] Re: Framebuffer...Why oh Why???
In reply to Linus TorvaldsQuoted 30 lines · Rob Landley
Quoted 11 lines · Linus Torvalds
Quoted 7 lines · Timothy Covell
When X11 locks up, I can still kill it and my box lives. When
framebuffers crash, their is no recovery save rebooting. Back in 1995 I thought that linux VTs and X11 implemenation blew Solaris out of the water, and now we want throw away our progress? I'm still astounded by the whole "oooh I can see a penquin while I boot-up" thing? Granted, frame buffers have usage in embedded systems, but do they really have to be so deeply integrated??They aren't.
Quoted 8 lines
No sane person should use frame buffers if they have the choice.
Like your mama told you: "Just say no". Use text-mode and X11, and be happy.
Some people don't have the choice, of course.
Linus
X11 isn't always an improvement. I've got an X hang on my laptop (about once a week) that freezes the keyboard and ignores mouse clicks. Numlock doesn't change the keyboard LEDs, CTRL-ALT-BACKSPACE won't do a thing, and although I can ssh in and run top (and see the CPU-eating loop), kill won't take X down and kill-9 leaves the video display up so the console that thinks it's in text mode, but isn't, is still useless. (And that's assuming I'm plugged into the network and have another box around to ssh in from...)
Quoted 8 lines
Compiling a debug version of X to run under gdb via ssh is on my to-do list...
A userspace program that takes over your main I/O devices modally and keeps them if it hangs isn't THAT much better than having the kernel ignore you directly...
Rob
Well laptops traditionally are made with some rather funky stuff. And laptops are made to be shutdown and restarted often, so I'd just make sure that I ran ReiserFS and/or ext3 on it and be happy when it works at all.
Signature · 1 line
[email protected].
Re: [patch] Re: Framebuffer...Why oh Why???
Quoted 8 lines
Quoted 8 lines
X11 isn't always an improvement. I've got an X hang on my laptop (about once a week) that freezes the keyboard and ignores mouse clicks. Numlock doesn't change the keyboard LEDs, CTRL-ALT-BACKSPACE won't do a thing, and although I can ssh in and run top (and see the CPU-eating loop), kill won't take X down and kill-9 leaves the video display up so the console that thinks it's in text mode, but isn't, is still useless. (And that's assuming I'm plugged into the network and have another box around to ssh in from...)
Neomagic Magicgraph 128XD ? If so check man neomagic first 8)
Re: [patch] Re: Framebuffer...Why oh Why???
Quoted 10 lines · Alan Cox
Quoted 8 lines
Quoted 8 lines
X11 isn't always an improvement. I've got an X hang on my laptop (about once a week) that freezes the keyboard and ignores mouse clicks. Numlock doesn't change the keyboard LEDs, CTRL-ALT-BACKSPACE won't do a thing, and although I can ssh in and run top (and see the CPU-eating loop), kill won't take X down and kill-9 leaves the video display up so the console that thinks it's in text mode, but isn't, is still useless. (And that's assuming I'm plugged into the network and have another box around to ssh in from...)
Neomagic Magicgraph 128XD ? If so check man neomagic first 8)
Right, and check out the [email protected] mailing list archives.
I feel your pain ;)
--
Daniel
Re: [patch] Re: Framebuffer...Why oh Why???
In reply to Alan CoxQuoted 10 lines · Alan Cox
Quoted 8 lines
Quoted 8 lines
X11 isn't always an improvement. I've got an X hang on my laptop (about once a week) that freezes the keyboard and ignores mouse clicks.
Numlock doesn't change the keyboard LEDs, CTRL-ALT-BACKSPACE won't do
a thing, and although I can ssh in and run top (and see the CPU-eating loop), kill won't take X down and kill-9 leaves the video display up so the console that thinks it's in text mode, but isn't, is still useless.
(And that's assuming I'm plugged into the network and have another box
around to ssh in from...)Neomagic Magicgraph 128XD ? If so check man neomagic first 8)
Neomagic 256AV. I'll feed it the two disables the man page recommends and see if that makes the problem go away. (I can trigger it almost at will by playing around with kmail with the threaded view of 2500+ linux-kernel messages and paging up and down really fast. Or by switching the display when )
Kmail seems to be the only thing that actually triggers it. I can't think of a lockup where kmail wasn't involved, but killing kmail (or the whole of kde) won't unfreeze the display and keyboard once it's borked, and when I ssh in and run top it's X that's got the cpu pegged at 99%, not any of the kde toys...
Rob
Re: [patch] Re: Framebuffer...Why oh Why???
In reply to Linus TorvaldsQuoted 7 lines · Rob Landley
X11 isn't always an improvement. I've got an X hang on my laptop (about once a week) that freezes the keyboard and ignores mouse clicks. Numlock doesn't change the keyboard LEDs, CTRL-ALT-BACKSPACE won't do a thing, and although I can ssh in and run top (and see the CPU-eating loop), kill won't take X down and kill-9 leaves the video display up so the console that thinks it's in text mode, but isn't, is still useless. (And that's assuming I'm plugged into the network and have another box around to ssh in from...)
I sometimes get a similar problem on my desktop when switching between text and X11 virtual consoles. Keyboard + mouse die (PS/2 counter becomes stuck according to /proc/interrupts). ssh followed by chvt helps.
Marius Gedminas
Signature · 1 line
Of course I use Microsoft. Setting up a stable unix network is no challenge ;p
Re: [patch] Re: Framebuffer...Why oh Why???
In reply to Timothy CovellQuoted 2 lines · Timothy Covell
When X11 locks up, I can still kill it and my box lives. When
framebuffers crash, their is no recovery save rebooting. Back in 1995
When your SCSI driver crashes, their is no recovery save rebooting. When your IDE driver crashes, their is no recovery save rebooting. When your Ethernet driver crashes, their is no recovery save rebooting.
...
If a frame buffer device crashes, it's a bug in the frame buffer device driver (unless the kernel got `tainted' by a user space application with root
privileges that messed with the graphics card without the frame buffer device driver being aware of that).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [patch] Re: Framebuffer...Why oh Why???
In reply to Timothy CovellLinus Torvalds on Sun 30/12 16:19 -0800:
Quoted 1 line
No sane person should use frame buffers if they have the choice.
Text mode is slow and has poor resolution, yes even svga text mode stuff is way slower than accelerated fbconsole for me, I don't like having to wait for the screen to update when I page a file and go to the next page.
And why require me to load X just to have a usuable system? Yes I think when I have to switch consoles so a program doing a lot of screen output doesn't block endlessly on my slow textmode display is unusable.
Re: [patch] Re: Framebuffer...Why oh Why???
In reply to Timothy CovellEm Mon, Dec 31, 2001 at 04:42:58PM -0500, Scott McDermott escreveu:
Quoted 7 lines
Linus Torvalds on Sun 30/12 16:19 -0800:
Quoted 1 line
No sane person should use frame buffers if they have the choice.
Text mode is slow and has poor resolution, yes even svga text mode stuff is way slower than accelerated fbconsole for me, I don't like having to wait for the screen to update when I page a file and go to the next page.
ouch, this hasn't been the case for me for ages, maybe I should try this accelerated fbconsole thing again...
Quoted 1 line
And why require me to load X just to have a usuable system? Yes I think
yes, why? Use lynx + zgv(in the rare cases where it is needed to see images) ;)
Quoted 2 lines
when I have to switch consoles so a program doing a lot of screen output doesn't block endlessly on my slow textmode display is unusable.
Thats what I feel when I use fbconsoles, and not the good old 80x25 text mode console.
- Arnaldo
Re: [patch] Re: Framebuffer...Why oh Why???
Quoted 8 lines
Quoted 5 lines
Text mode is slow and has poor resolution, yes even svga text mode stuff is way slower than accelerated fbconsole for me, I don't like having to wait for the screen to update when I page a file and go to the next page.
ouch, this hasn't been the case for me for ages, maybe I should try this accelerated fbconsole thing again...
Which framebuffer driver? Soem are good and some suck. Vesafb is really bad. It far better to use a native card dr4iver if it is avaliable.
Re: [patch] Re: Framebuffer...Why oh Why???
In reply to Arnaldo Carvalho de MeloEm Mon, Dec 31, 2001 at 02:26:04PM -0800, James Simmons escreveu:
Quoted 11 lines
Quoted 8 lines
Quoted 5 lines
Text mode is slow and has poor resolution, yes even svga text mode stuff is way slower than accelerated fbconsole for me, I don't like having to wait for the screen to update when I page a file and go to the next page.
ouch, this hasn't been the case for me for ages, maybe I should try this accelerated fbconsole thing again...
Which framebuffer driver? Soem are good and some suck. Vesafb is really bad. It far better to use a native card dr4iver if it is avaliable.
My card is a Neomagic, so I use vesafb...
Please let me know if somebody has specs for:
00:08.0 VGA compatible controller: Neomagic Corporation NM2160 [MagicGraph 128XD] (rev 01)
If they're enough to write a fb driver for this card... Well, I can try and write a driver. 8)
Humm, there are XFree86 drivers (that sucks lately, but I'm lazy so maybe its my fault)...
- Arnaldo
Re: [patch] Re: Framebuffer...Why oh Why???
Quoted 2 lines
Humm, there are XFree86 drivers (that sucks lately, but I'm lazy so maybe its my fault)...
XFree is pretty much the only documentation I've seen for the neotragic chipsets, although there are some interesting errata only mention in man neomagic
Re: [patch] Re: Framebuffer...Why oh Why???
In reply to Arnaldo Carvalho de MeloQuoted 6 lines · Arnaldo Carvalho de Melo
My card is a Neomagic, so I use vesafb...
Please let me know if somebody has specs for:
00:08.0 VGA compatible controller: Neomagic Corporation NM2160 [MagicGraph 128XD] (rev 01)
Someone wrote a neomagic framebuffer driver at some point; ISTR the patch showing up on linux-kernel. Mind you, I don't know that it was accelerated at all...
Bill
Re: [patch] Re: Framebuffer...Why oh Why???
i didn't wrote it, i can only give you a hint where to find it so you can try it
http://directfb.org/cgi-bin/cvsweb.cgi/~checkout~/
DirectFB/patches/neofb-0.3-linux-2.4.17.patch.bz2
it applys fine an i have i patched it in out own working tree as far as i know it is tested on acer, sony vaio and some thinkpad and works great.
since 0.3 move and clear is implemented by using the acclerator on nm2200 and above so you really gain speed when scrolling though your consoles
there is also some patch for aty128fb i use some time now without any problems... anyway... now my ati works, before it doesnt.
have fun testing, and yes... a textconsole at native resolution is that what i need to work with an lc-monitor.... 1600x1024 looks great booting at native resolution:
Console: switching to colour frame buffer device 200x64
Quoted 13 lines · Bill Nottingham
Quoted 6 lines · Arnaldo Carvalho de Melo
My card is a Neomagic, so I use vesafb...
Please let me know if somebody has specs for:
00:08.0 VGA compatible controller: Neomagic Corporation NM2160 [MagicGraph 128XD] (rev 01)
Someone wrote a neomagic framebuffer driver at some point; ISTR the patch showing up on linux-kernel. Mind you, I don't know that it was accelerated at all...
Bill
Re: [patch] Re: Framebuffer...Why oh Why???
In reply to Arnaldo Carvalho de MeloEm Mon, Dec 31, 2001 at 09:43:22PM -0500, Bill Nottingham escreveu:
Quoted 11 lines
Quoted 6 lines · Arnaldo Carvalho de Melo
My card is a Neomagic, so I use vesafb...
Please let me know if somebody has specs for:
00:08.0 VGA compatible controller: Neomagic Corporation NM2160 [MagicGraph 128XD] (rev 01)
Someone wrote a neomagic framebuffer driver at some point; ISTR the patch showing up on linux-kernel. Mind you, I don't know that it was accelerated at all...
Indeed, I've found it at
http://www.uwsg.iu.edu/hypermail/linux/kernel/0104.0/0658.html
and it seems to be accelerated, will test tomorrow and post the results.
Should be interesting to use konqueror/qt on a framebuffer console...
- Arnaldo
Re: [patch] Re: Framebuffer...Why oh Why???
In reply to Mark J RobertsQuoted 9 lines · you
Quoted 7 lines · Timothy Covell
When X11 locks up, I can still kill it and my box lives. When
framebuffers crash, their is no recovery save rebooting. Back in 1995 I thought that linux VTs and X11 implemenation blew Solaris out of the water, and now we want throw away our progress? I'm still astounded by the whole "oooh I can see a penquin while I boot-up" thing? Granted, frame buffers have usage in embedded systems, but do they really have to be so deeply integrated??
Quoted 4 lines
Well that's news to me....
If you can send me a simple step-by-step means by which to reproduce this, I'll take a shot at fixing it.
Andrew,
Well, I was making reference to Solaris where I have seen
lots of X11 crashes mean framebuffer crashes which means the console
is unusable. I haven't played with it on Linux enough to know for sure that
Linux doesn't suffer the same problems. If that's true, then hats off to you all for again showing how Solaris sucks.
Signature · 1 line
[email protected].
Re: [patch] Re: Framebuffer...Why oh Why???
Quoted 6 lines
Well, I was making reference to Solaris where I have seen
lots of X11 crashes mean framebuffer crashes which means the console
is unusable. I haven't played with it on Linux enough to know for sure that
Linux doesn't suffer the same problems. If that's true, then hats off to you all for again showing how Solaris sucks.
Usually the problem with X11 and framebuffer is people forget they need to use the UseFBDev option for XFree86. You need to tell the X server please use the fbdev layer to restore the video mode. Otherwise X will try to reset the card back to the VGA state.
Re: [patch] Re: Framebuffer...Why oh Why???
In reply to Timothy CovellQuoted 5 lines · James Simmons
Usually the problem with X11 and framebuffer is people forget they need to use the UseFBDev option for XFree86. You need to tell the X server please use the fbdev layer to restore the video mode. Otherwise X will try to reset the card back to the VGA state.
Couldn't the X server query the kernel for this info when it starts up?
Re: [patch] Re: Framebuffer...Why oh Why???
Quoted 7 lines
Quoted 5 lines
Usually the problem with X11 and framebuffer is people forget they need to use the UseFBDev option for XFree86. You need to tell the X server please use the fbdev layer to restore the video mode. Otherwise X will try to reset the card back to the VGA state.
Couldn't the X server query the kernel for this info when it starts up?
Personally I like to the console system restore the console itself. It is so easy to do since the console system already has the code to do this. The code just has to be reorgainzed. The point is that it is there.
Re: [patch] Re: Framebuffer...Why oh Why???
In reply to Andrew MortonQuoted 7 lines · Andrew Morton
Quoted 4 lines · James Simmons
Usually the problem with X11 and framebuffer is people forget they need to use the UseFBDev option for XFree86. You need to tell the X server please use the fbdev layer to restore the video mode. Otherwise X will try to reset the card back to the VGA state.
Couldn't the X server query the kernel for this info when it starts up?
Yes, it's perfectly possible for the X server to do that.
The main problem is that the X server shouldn't touch things that are controlled by a fbdev driver.
It's a bit weird... No one thinks about implementing SCSI or Ethernet drivers in user space, but for graphics that's all OK. Worse, for graphics it's even considered normal that the user space driver plays with the hardware behind the kernel driver's back...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [patch] Re: Framebuffer...Why oh Why???
Quoted 4 lines
It's a bit weird... No one thinks about implementing SCSI or Ethernet drivers in user space, but for graphics that's all OK. Worse, for graphics it's even considered normal that the user space driver plays with the hardware behind the kernel driver's back...
Have a look at the iscsi back end. There are good reasons to do a lot of the graphics from user space via X11 or via DRM. Performance is one very significant case.
Alan
Re: [patch] Re: Framebuffer...Why oh Why???
Quoted 6 lines · Alan Cox
Quoted 4 lines
It's a bit weird... No one thinks about implementing SCSI or Ethernet drivers in user space, but for graphics that's all OK. Worse, for graphics it's even considered normal that the user space driver plays with the hardware behind the kernel driver's back...
Have a look at the iscsi back end.
Which one?
Signature · 1 line
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."