Framebuffer, mmap(), hanging in D state, root FS unmount failure.

Framebuffer, mmap(), hanging in D state, root FS unmount failure.

[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;
}

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.

Re: Framebuffer, mmap(), hanging in D state, root FS unmount failure.

[Andrew Morton]

Mark J Roberts wrote:
> 
> #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.
> 

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.

--- linux-2.4.18-pre1/drivers/video/fbmem.c	Fri Dec 21 11:19:14 2001
+++ linux-akpm/drivers/video/fbmem.c	Fri Dec 28 16:18:05 2001
@@ -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?

-

[patch] Re: Framebuffer, mmap(), hanging in D state, root FS unmount failure.

[Andrew Morton]

Andrew Morton wrote:
> 
> 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?

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.


--- linux-2.4.18-pre1/drivers/video/fbmem.c	Fri Dec 21 11:19:14 2001
+++ linux-akpm/drivers/video/fbmem.c	Sun Dec 30 00:23:15 2001
@@ -576,12 +576,13 @@ fb_mmap(struct file *file, struct vm_are
 		return -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_are
 	pgprot_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???

[Timothy Covell]

On Sunday 30 December 2001 02:34, Andrew Morton wrote:
> Andrew Morton wrote:
> > 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??

-- 
timothy.covell@ashavan.org.

Re: [patch] Re: Framebuffer...Why oh Why???

[Timothy Covell]

On Sunday 30 December 2001 15:29, you wrote:
> Timothy Covell wrote:
> >         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??
>
> 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.


-- 
timothy.covell@ashavan.org.

Re: [patch] Re: Framebuffer...Why oh Why???

[James Simmons]

> 	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???

[Andrew Morton]

James Simmons wrote:
> 
> 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???

[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?

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???

[Geert Uytterhoeven]

On Sun, 30 Dec 2001, Andrew Morton wrote:
> James Simmons wrote:
> > 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 -- geert@linux-m68k.org

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???

[Alan Cox]

> 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???

[Oliver Xymoron]

On Mon, 31 Dec 2001, Alan Cox wrote:

> > 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?

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: [patch] Re: Framebuffer...Why oh Why???

[Linus Torvalds]

On Sun, 30 Dec 2001, Timothy Covell wrote:
>
> 	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???

[James Simmons]

> > 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.

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???

[gmack]

On Sun, 30 Dec 2001, Linus Torvalds wrote:

> Date: Sun, 30 Dec 2001 16:19:15 -0800 (PST)
> From: Linus Torvalds <torvalds@transmeta.com>
> To: Timothy Covell <timothy.covell@ashavan.org>
> Cc: Andrew Morton <akpm@zip.com.au>, linux-kernel@vger.kernel.org,
>      Linux Frame Buffer Device Development
>     <linux-fbdev-devel@lists.sourceforge.net>,
>      Marcelo Tosatti <marcelo@conectiva.com.br>
> Subject: Re: [patch] Re: Framebuffer...Why oh Why???
> 
> 
> On Sun, 30 Dec 2001, Timothy Covell wrote:
> >
> > 	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

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

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: [patch] Re: Framebuffer...Why oh Why???

[Benjamin Herrenschmidt]

>
>On Sun, 30 Dec 2001, Timothy Covell wrote:
>>
>> 	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.

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???

[Rob Landley]

On Sunday 30 December 2001 07:19 pm, Linus Torvalds wrote:
> On Sun, 30 Dec 2001, Timothy Covell wrote:
> > 	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

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???

[Werner Puschitz]

On Mon, 31 Dec 2001, Rob Landley wrote:

> On Sunday 30 December 2001 07:19 pm, Linus Torvalds wrote:
> > On Sun, 30 Dec 2001, Timothy Covell wrote:
> > > 	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
> 
> 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...

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???

[Marco Ermini]

On Tue, 1 Jan 2002 02:00:01 -0500 (EST), Werner Puschitz
<werner.lx@verizon.net> wrote:

[...]
> 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

-- 
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???

[Tommi Kyntola]

> [...]
> > 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.

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)" :)

-- 
  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???

[Marco Ermini]

[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]

On Fri, 4 Jan 2002 15:27:03 +0200 (EET), Tommi Kyntola <kynde@ts.ray.fi>
wrote:

[...]
> > 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.
> 
> 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).

> yers,
>  another member of "Linux on a Toshiba Satellite 4080xcdt (TM)" :)

You are missing "proud" ;-)


thanks

-- 
Marco Ermini
http://www.markoer.org
Never attribute to malice that which is adequately explained
by stupidity. (a sig from Slashdot postings)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [patch] Re: Framebuffer...Why oh Why???

[Timothy Covell]

On Monday 31 December 2001 15:41, Rob Landley wrote:
> On Sunday 30 December 2001 07:19 pm, Linus Torvalds wrote:
> > On Sun, 30 Dec 2001, Timothy Covell wrote:
> > > 	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
>
> 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

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.

-- 
timothy.covell@ashavan.org.

Re: [patch] Re: Framebuffer...Why oh Why???

[Alan Cox]

> > 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???

[Rob Landley]

On Tuesday 01 January 2002 05:42 am, Alan Cox wrote:
> > > 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???

[Daniel Phillips]

On January 1, 2002 11:42 am, Alan Cox wrote:
> > > 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 neomagic@XFree86.Org mailing list archives.

I feel your pain ;)

--
Daniel

Re: [patch] Re: Framebuffer...Why oh Why???

[Marius Gedminas]

On Mon, Dec 31, 2001 at 04:41:19PM -0500, Rob Landley wrote:
> 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
-- 
Of course I use Microsoft. Setting up a stable unix network is no challenge ;p

Re: [patch] Re: Framebuffer...Why oh Why???

[Scott McDermott]

Linus Torvalds on Sun 30/12 16:19 -0800:
> 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???

[Arnaldo Carvalho de Melo]

Em Mon, Dec 31, 2001 at 04:42:58PM -0500, Scott McDermott escreveu:
> Linus Torvalds on Sun 30/12 16:19 -0800:
> > 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...
 
> 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) ;)

> 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???

[James Simmons]

> > 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???

[Arnaldo Carvalho de Melo]

Em Mon, Dec 31, 2001 at 02:26:04PM -0800, James Simmons escreveu:
> 
> > > 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???

[Bill Nottingham]

Arnaldo Carvalho de Melo (acme@conectiva.com.br) said: 
> 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???

[Arnaldo Carvalho de Melo]

Em Mon, Dec 31, 2001 at 09:43:22PM -0500, Bill Nottingham escreveu:
> Arnaldo Carvalho de Melo (acme@conectiva.com.br) said: 
> > 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???

[Joachim Steiger]

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

On Mon, 31 Dec 2001, Bill Nottingham wrote:

> Arnaldo Carvalho de Melo (acme@conectiva.com.br) said: 
> > 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???

[Alan Cox]

> 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???

[Ken Moffat]

On Sun, 30 Dec 2001, Linus Torvalds wrote:

> 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
-- 
        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???

[Timothy Covell]

On Monday 31 December 2001 18:23, Ken Moffat wrote:
> On Sun, 30 Dec 2001, Linus Torvalds wrote:
> > 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.  ;-)

-- 
timothy.covell@ashavan.org.

Re: [patch] Re: Framebuffer...Why oh Why???

[Geert Uytterhoeven]

On Sun, 30 Dec 2001, Timothy Covell wrote:
> 	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 -- geert@linux-m68k.org

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