controlfb and X

controlfb and X

[Robert E Brose II]

I've been doing some testing of the controlfb driver in the
2.2.17 tree as well as the 2.4.0-test10 paulus tree.

The problem is that the controlfb driver doesn't recognize more than
2 megs of vram. This particular Mac 7500 has 4 megs installed which
works perfectly in MacOS.

With 2.2.18pre18, 2 megs only is available. Running XFree86-3.3.6-11.2
on the Mac 7500 will do 800x600 in 24 bits as expected and 1024x768 in
16 bits but not 1024x768 in 24 bits (not enough ram).

With 2.4.0-test10 (which includes dma and parameter line changes in
controlfb) forcing the video ram to 4 megs works fine for console
modes (for example vmode 17 32) HOWEVER when the XF86_FBdev server
is run it locks up the machine with a black screen of death. (not
pingable, keyboard is dead, etc).
Also, building my own Xfree 4.01 server results in the same black
screen of death.
OTOH Xpmac rev 10 works fine (but doesn't support serial mice AFAIK).

I'm assuming the problem is in the dma code added to controlfb.c in the
2.4.x version. Has anyone run into this or had different results?

Bob
--
Robert E. Brose II    N0QBJ
http://www.jriver.com/~bob/
bob@kunk.jriver.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: controlfb and X

[Michel Lanners]

On   5 Nov, this message from Robert E Brose II echoed through cyberspace:
> The problem is that the controlfb driver doesn't recognize more than
> 2 megs of vram. This particular Mac 7500 has 4 megs installed which
> works perfectly in MacOS.

Strange. It should detect 4 meg in 2.2 kernels; but maybe not 2.4
kernels.

> With 2.2.18pre18, 2 megs only is available. Running XFree86-3.3.6-11.2
> on the Mac 7500 will do 800x600 in 24 bits as expected and 1024x768 in
> 16 bits but not 1024x768 in 24 bits (not enough ram).

Correct according to what it detects. Wrong detection, however :-(

> With 2.4.0-test10 (which includes dma and parameter line changes in
> controlfb)

Which are those?

> forcing the video ram to 4 megs works fine for console
> modes (for example vmode 17 32) HOWEVER when the XF86_FBdev server
> is run it locks up the machine with a black screen of death. (not
> pingable, keyboard is dead, etc).
> Also, building my own Xfree 4.01 server results in the same black
> screen of death.

Strange....

> I'm assuming the problem is in the dma code added to controlfb.c in the
> 2.4.x version. Has anyone run into this or had different results?

I have only problems with 2.4, but not with controlfb ;-)

Can you be more specific as to hwta version of 2.4 you're running? Where
did you get it from?

Also, do you se anything in your logs (kernel panic, maybe)? If not, can
you attach a serial console to one of the serial ports, and add this to
your kernel command line:

console=ttyS0,19200n8 console=tty0

This would be for a 19200 console, obviously. Try to capture the panic
message (if there is one) when you start X.

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: controlfb and X

[bob]

Hi Michael....

> On   5 Nov, this message from Robert E Brose II echoed through cyberspace:

> > The problem is that the controlfb driver doesn't recognize more than
> > 2 megs of vram. This particular Mac 7500 has 4 megs installed which
> > works perfectly in MacOS.
>
> Strange. It should detect 4 meg in 2.2 kernels; but maybe not 2.4
> kernels.

Is that with a patch that produces a different controlfb.c that the
one on the paulus site?

> > With 2.2.18pre18, 2 megs only is available. Running XFree86-3.3.6-11.2
> > on the Mac 7500 will do 800x600 in 24 bits as expected and 1024x768 in
> > 16 bits but not 1024x768 in 24 bits (not enough ram).
>
> Correct according to what it detects. Wrong detection, however :-(

Yeah, I just wanted to see if it would do 24/32 bit color at all....

> > With 2.4.0-test10 (which includes dma and parameter line changes in
> > controlfb)
>
> Which are those?

Yours I think. I passed through your website looking. I guess I was not
very clear here, sorry. I was looking at the 2.2.18pre18 paulus code.
the controlfb.c did not have the dma routines in it. The 2.4.0-test10
paulus tree did. I diffed the 2 controlfb.c files from these 2 versions.

> > forcing the video ram to 4 megs works fine for console
> > modes (for example vmode 17 32) HOWEVER when the XF86_FBdev server
> > is run it locks up the machine with a black screen of death. (not
> > pingable, keyboard is dead, etc).
> > Also, building my own Xfree 4.01 server results in the same black
> > screen of death.
>
> Strange....
>
> Also, do you se anything in your logs (kernel panic, maybe)? If not, can
> you attach a serial console to one of the serial ports, and add this to
> your kernel command line:
>
> console=ttyS0,19200n8 console=tty0
>
> This would be for a 19200 console, obviously. Try to capture the panic
> message (if there is one) when you start X.

Nothing in the logs. I'll try the console as you suggest and post
the results. I try not to do this too much because it crashes hard
enough that I have to do a manual fsck to get it back up.

--
Bob Brose
bob@kunk.jriver.com


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: controlfb and X

[Brad Boyer]

Michel Lanners wrote:
>
>
> On   5 Nov, this message from Robert E Brose II echoed through cyberspace:
> > The problem is that the controlfb driver doesn't recognize more than
> > 2 megs of vram. This particular Mac 7500 has 4 megs installed which
> > works perfectly in MacOS.
>
> Strange. It should detect 4 meg in 2.2 kernels; but maybe not 2.4
> kernels.
>

There's been a long standing issue on detecting the full 4M on controlfb
that regularly pops up. I happen to have a 7600 with the video upgraded to
4M, so I've been interested in this as well. I've seen several patches
float over the list, and I don't think any of them actually worked for
everyone. I believe the conclusion was that control just didn't act the
same on every machine. I suspect that if you look back through the list
archives, you'll find lots of discussion on this topic.

	Brad Boyer
	flar@pants.nu

P.S.: Try the following search on lists.linuxppc.org in linuxppc-dev:

controlfb;patch;detect


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: controlfb and X

[bob]

User Brad Boyer says:
>
> There's been a long standing issue on detecting the full 4M on controlfb
> that regularly pops up. I happen to have a 7600 with the video upgraded to
> 4M, so I've been interested in this as well. I've seen several patches
> float over the list, and I don't think any of them actually worked for
> everyone. I believe the conclusion was that control just didn't act the
> same on every machine. I suspect that if you look back through the list
> archives, you'll find lots of discussion on this topic.
>
> 	Brad Boyer
> 	flar@pants.nu
>
> P.S.: Try the following search on lists.linuxppc.org in linuxppc-dev:

Brad,
I've done the search already. That is how I found out that Michael has
been working on it.

What it boils down to is this:
2 trees, one the stable(2.2) and dev(2.4) paulus sources.

The memory detect/override/dma changes do not appear to be
 in the stable tree.

Without being able to override the video mem from 2 to 4 megs in
the stable tree, I can't test that kernel version with XF68_FBdev

Using the dev kernel, the override works and the text mode change
to mode 17,32 (which requires more than 2 megs) works but both
Xfree 3.6 and 4.01 lock up trying to do 24/32 bit mode.

I'm trying to give feedback and to see if Michael or anyone else has
ideas about other things to test to pin the problem down further.


Bob
--
Robert E. Brose II    N0QBJ
http://www.jriver.com/~bob/
bob@kunk.jriver.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: controlfb and X

[Michel Lanners]

On   6 Nov, this message from Brad Boyer echoed through cyberspace:
> Michel Lanners wrote:
>> On   5 Nov, this message from Robert E Brose II echoed through cyberspace:
>> > The problem is that the controlfb driver doesn't recognize more than
>> > 2 megs of vram. This particular Mac 7500 has 4 megs installed which
>> > works perfectly in MacOS.
>>
>> Strange. It should detect 4 meg in 2.2 kernels; but maybe not 2.4
>> kernels.
>
> There's been a long standing issue on detecting the full 4M on controlfb
> that regularly pops up.

Yup. AFAICT, there are two versions of the detect code that have been
alternating between 2.1 kernel versions in the past, then the 2.2
kernels stabilized on the 7x00-friendly version, but the 2.4 kernels
went for the 8x00-savvy version.

> I happen to have a 7600 with the video upgraded to
> 4M, so I've been interested in this as well. I've seen several patches
> float over the list, and I don't think any of them actually worked for
> everyone.

No. Either 7x00-style machines worked, or 8x00.

> I believe the conclusion was that control just didn't act the
> same on every machine. I suspect that if you look back through the list
> archives, you'll find lots of discussion on this topic.

I know; I've participated in most of those discussions ;-)

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: controlfb and X

[bob]

User Michel Lanners says:
> Yup. AFAICT, there are two versions of the detect code that have been
> alternating between 2.1 kernel versions in the past, then the 2.2
> kernels stabilized on the 7x00-friendly version, but the 2.4 kernels
> went for the 8x00-savvy version.

I don't know see then why I cannot get the paulus 2.2 stable kernel to
take a bootx 4m override or to automatically detect 4m on the 7500.

> No. Either 7x00-style machines worked, or 8x00.

Is there any easy way to see that in the code?

Bob
--
Robert E. Brose II    N0QBJ
http://www.jriver.com/~bob/
bob@kunk.jriver.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: controlfb and X

[Michel Lanners]

Hi all,

On   5 Nov, this message from Robert E Brose II echoed through cyberspace:
> With 2.4.0-test10 (which includes dma and parameter line changes in
> controlfb) forcing the video ram to 4 megs works fine for console
> modes (for example vmode 17 32) HOWEVER when the XF86_FBdev server
> is run it locks up the machine with a black screen of death. (not
> pingable, keyboard is dead, etc).
> Also, building my own Xfree 4.01 server results in the same black
> screen of death.
> OTOH Xpmac rev 10 works fine (but doesn't support serial mice AFAIK).

I'm now having the same problem with benh's dev tree. The really ugly
part is that there is no information on what happened nowehere: nothing
in X's log files, no oops in the syslog, no kernel panic on the serial
console... the kernel just seems to stop hard.

I've diffed benh's tree against Paul's latest copy I have (which doesn't
lockup with X), but without any clue so far. controlfb is identical
between the two....

I'll keep on investigating.

Cheers

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: controlfb and X (fixed)

[Michel Lanners]

[-- Attachment #1: Type: TEXT/plain, Size: 920 bytes --]

Hi all,

Some time ago, there were reports of crashes with controlfb and 2.4
kernels, while starting XF4.0.

I've taken a look, and it seems that indeed the mmap code recently added
to controlfb is to blame.

Below is the patch that fixes the hanging box while starting X for me.
It seems while implementing mmap() for 2.4 kernels in controlfb, I
forgot to copy 2 lines :-((

Ben and Paul, could you apply this patch to all your 2.4 / 2.5 trees? It
also fixes the 7_spaces_instead_of_tab problem in the mmap() code ;-)

Cheers, happy hacking, and sorry for this bug :-)

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "

[-- Attachment #2: 2.4-control-mmap-fix.diff --]
[-- Type: TEXT/plain, Size: 2497 bytes --]

--- /mnt/r4/usr/src/linux-2.4.paul/drivers/video/controlfb.c	Thu Oct 19 03:36:07 2000
+++ linux-2.4.0-test10/drivers/video/controlfb.c	Sat Nov 18 19:23:10 2000
@@ -338,38 +343,41 @@
 static int control_mmap(struct fb_info *info, struct file *file,
                        struct vm_area_struct *vma)
 {
-       struct fb_ops *fb = info->fbops;
-       struct fb_fix_screeninfo fix;
-       struct fb_var_screeninfo var;
-       unsigned long off, start;
-       u32 len;
-
-       fb->fb_get_fix(&fix, PROC_CONSOLE(info), info);
-       off = vma->vm_pgoff << PAGE_SHIFT;
-
-       /* frame buffer memory */
-       start = fix.smem_start;
-       len = PAGE_ALIGN((start & ~PAGE_MASK)+fix.smem_len);
-       if (off >= len) {
-               /* memory mapped io */
-               off -= len;
-               fb->fb_get_var(&var, PROC_CONSOLE(info), info);
-               if (var.accel_flags)
-                       return -EINVAL;
-               start = fix.mmio_start;
-               len = PAGE_ALIGN((start & ~PAGE_MASK)+fix.mmio_len);
-               pgprot_val(vma->vm_page_prot) |= _PAGE_NO_CACHE|_PAGE_GUARDED;
-       } else {
-               /* framebuffer */
-               pgprot_val(vma->vm_page_prot) |= _PAGE_WRITETHRU;
-       }
-       start &= PAGE_MASK;
-       vma->vm_pgoff = off >> PAGE_SHIFT;
-       if (io_remap_page_range(vma->vm_start, off,
-           vma->vm_end - vma->vm_start, vma->vm_page_prot))
-               return -EAGAIN;
+	struct fb_ops *fb = info->fbops;
+	struct fb_fix_screeninfo fix;
+	struct fb_var_screeninfo var;
+	unsigned long off, start;
+	u32 len;

-       return 0;
+	fb->fb_get_fix(&fix, PROC_CONSOLE(info), info);
+	off = vma->vm_pgoff << PAGE_SHIFT;
+
+	/* frame buffer memory */
+	start = fix.smem_start;
+	len = PAGE_ALIGN((start & ~PAGE_MASK)+fix.smem_len);
+	if (off >= len) {
+		/* memory mapped io */
+		off -= len;
+		fb->fb_get_var(&var, PROC_CONSOLE(info), info);
+		if (var.accel_flags)
+			return -EINVAL;
+		start = fix.mmio_start;
+		len = PAGE_ALIGN((start & ~PAGE_MASK)+fix.mmio_len);
+		pgprot_val(vma->vm_page_prot) |= _PAGE_NO_CACHE|_PAGE_GUARDED;
+	} else {
+		/* framebuffer */
+		pgprot_val(vma->vm_page_prot) |= _PAGE_WRITETHRU;
+	}
+	start &= PAGE_MASK;
+	if ((vma->vm_end - vma->vm_start + off) > len)
+		return -EINVAL;
+	off += start;
+	vma->vm_pgoff = off >> PAGE_SHIFT;
+	if (io_remap_page_range(vma->vm_start, off,
+	    vma->vm_end - vma->vm_start, vma->vm_page_prot))
+		return -EAGAIN;
+
+	return 0;
 }