Matrox Oopsed when using kernel with ACPI support...

Matrox Oopsed when using kernel with ACPI support...

[Dawid Kuroczko]

I'm running kernel 2.4.19 and I'm exeriencing repeatable kernel Oops
with Matrox Mystique card.  Kernel appears OK when compiled with
APM, but oopses whem compiled with ACPI...  More below oops dump.

ksymoops 2.4.4 on i686 2.4.19.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.19/ (default)
     -m /boot/System.map-2.4.19 (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

No modules in ksyms, skipping objects
Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file?
Aug  7 02:08:34 atlantis kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000200
Aug  7 02:08:34 atlantis kernel: c024d739
Aug  7 02:08:34 atlantis kernel: *pde = 00000000
Aug  7 02:08:34 atlantis kernel: Oops: 0000
Aug  7 02:08:34 atlantis kernel: CPU:    1
Aug  7 02:08:34 atlantis kernel: EIP:    0010:[matrox_cfbX_putcs+393/640]    Not tainted
Aug  7 02:08:34 atlantis kernel: EIP:    0010:[<c024d739>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
Aug  7 02:08:34 atlantis kernel: EFLAGS: 00010202
Aug  7 02:08:34 atlantis kernel: eax: 00000010   ebx: f0809000   ecx: 00000004   edx: 01200010
Aug  7 02:08:34 atlantis kernel: esi: 00000200   edi: f0809000   ebp: 00000010   esp: c1857e60
Aug  7 02:08:34 atlantis kernel: ds: 0018   es: 0018   ss: 0018
Aug  7 02:08:34 atlantis kernel: Process keventd (pid: 2, stackpage=c1857000)
Aug  7 02:08:34 atlantis kernel: Stack: 00000001 011f0118 0000007f 00000010 01200010 00000001 07070707 c03ec65c 
Aug  7 02:08:34 atlantis kernel:        e607ae10 00000012 c024d88d 07070707 00000000 c03ec65c e607ae58 00000040 
Aug  7 02:08:34 atlantis kernel:        00000012 00000000 c03f0970 c03ec65c 00000000 c0246f44 efde7600 c03ec65c 
Aug  7 02:08:34 atlantis kernel: Call Trace:    [matrox_cfb8_putcs+93/112] [fbcon_putcs+148/256] [do_update_region+295/400] [redraw_screen+244/336] [complete_change_console+43/192]
Aug  7 02:08:34 atlantis kernel: Call Trace:    [<c024d88d>] [<c0246f44>] [<c0205257>] [<c0205d74>] [<c020378b>]
Aug  7 02:08:34 atlantis kernel:   [<c020907a>] [<c011f8cd>] [<c01286aa>] [<c01284a0>] [<c0105000>] [<c01073c6>]
Aug  7 02:08:34 atlantis kernel:   [<c01284a0>]
Aug  7 02:08:34 atlantis kernel: Code: f3 a5 a8 02 74 02 66 a5 a8 01 74 01 a4 8b 74 24 34 0f b7 96 

>>EIP; c024d739 <matrox_cfbX_putcs+189/280>   <=====
Trace; c024d88d <matrox_cfb8_putcs+5d/70>
Trace; c0246f44 <fbcon_putcs+94/100>
Trace; c0205257 <do_update_region+127/190>
Trace; c0205d74 <redraw_screen+f4/150>
Trace; c020378b <complete_change_console+2b/c0>
Trace; c020907a <console_callback+3a/b0>
Trace; c011f8cd <__run_task_queue+5d/70>
Trace; c01286aa <context_thread+20a/220>
Trace; c01284a0 <context_thread+0/220>
Trace; c0105000 <_stext+0/0>
Trace; c01073c6 <kernel_thread+26/30>
Trace; c01284a0 <context_thread+0/220>
Code;  c024d739 <matrox_cfbX_putcs+189/280>
00000000 <_EIP>:
Code;  c024d739 <matrox_cfbX_putcs+189/280>   <=====
   0:   f3 a5                     repz movsl %ds:(%esi),%es:(%edi)   <=====
Code;  c024d73b <matrox_cfbX_putcs+18b/280>
   2:   a8 02                     test   $0x2,%al
Code;  c024d73d <matrox_cfbX_putcs+18d/280>
   4:   74 02                     je     8 <_EIP+0x8> c024d741 <matrox_cfbX_putcs+191/280>
Code;  c024d73f <matrox_cfbX_putcs+18f/280>
   6:   66 a5                     movsw  %ds:(%esi),%es:(%edi)
Code;  c024d741 <matrox_cfbX_putcs+191/280>
   8:   a8 01                     test   $0x1,%al
Code;  c024d743 <matrox_cfbX_putcs+193/280>
   a:   74 01                     je     d <_EIP+0xd> c024d746 <matrox_cfbX_putcs+196/280>
Code;  c024d745 <matrox_cfbX_putcs+195/280>
   c:   a4                        movsb  %ds:(%esi),%es:(%edi)
Code;  c024d746 <matrox_cfbX_putcs+196/280>
   d:   8b 74 24 34               mov    0x34(%esp,1),%esi
Code;  c024d74a <matrox_cfbX_putcs+19a/280>
  11:   0f b7 96 00 00 00 00      movzwl 0x0(%esi),%edx

OK, and now for more information.  The system is SMP 2 x PIII 733
machine with:
   matroxfb: Matrox Mystique (PCI) detected
   matroxfb: MTRR's turned on
   matroxfb: 640x480x8bpp (virtual: 640x3270)
   matroxfb: framebuffer at 0xD6000000, mapped to 0xc8805000, size 2097152
Everything works just fine, there is an fbdev X server running on one of
the consoles.  The oops results when following script is run (please note
that it works fine when ACPI is not compiled in):

--- >8 --- CUT here --- /etc/rc.d/init.d/fbset
#!/bin/sh
#
# hdpram        Sets up fbcon video modes.
#
#
# chkconfig:	2345 5 30
# description:	fbset is a utility with which fbcons video modes can be read\
#		and changed


# Source function library
. /etc/rc.d/init.d/functions

# Get service config
[ -f /etc/sysconfig/fbset ] && . /etc/sysconfig/fbset

# See how we were called.
case "$1" in
  start)
	# Check if we have framebuffer in kernel.
	if [ -f /proc/fb ]; then
		# /proc files show as files with size=0, this is a workaround.
		cat /proc/fb | grep -q "." || exit 0
	else
		exit 0
	fi

	if [ -n "${FBMODE_default}" ]; then
		show "Setting default video mode"
		busy
		/usr/sbin/fbset -a ${FBMODE_default}
		deltext
		ok
	fi
	for tty in /dev/tty[1-9] /dev/tty[1-6][0-9]; do
		eval FBMODE=\${FBMODE_${tty#/dev/}}
		if [ -n "${FBMODE}" ]; then
			echo "settking $tty to $FBMODE"
			# XXX fuser $tty <- sprawdziæ, czy tty jest wolna.
			show "Setting $tty video mode to $FBMODE" 
			busy
			echo -n > $tty
			/usr/bin/open -s -c ${tty#/dev/tty} -- /usr/sbin/fbset ${FBMODE}
			deltext
			ok
		fi
	done
	touch /var/lock/subsys/fbset
	;;
    stop)	
	rm -f /var/lock/subsys/fbset
	;;
  status)
	# Check if we have framebuffer in kernel.
	if [ -f /proc/fb ]; then
		# /proc files show as files with size=0, this is a workaround.
		cat /proc/fb | grep -q "." || exit 0
		echo "Frame buffer present."
	fi
	;;
  restart|reload)
	$0 stop
	$0 start
	;;
  *)
	echo "Usage: $0 {start|stop|status|restart|reload}"
	exit 1
esac

exit 0
--- >8 --- END

--- >8 --- /etc/sysconfig/fbset
# This file lets you set your default console video mode and
# video modes for individual virtual consoles.
# See /etc/fb.modes for sample video mode definitions.

FBMODE_default="Q100x31"

FBMODE_tty1=
FBMODE_tty2=
FBMODE_tty3=
FBMODE_tty4=
FBMODE_tty5=
FBMODE_tty6=
FBMODE_tty7=
FBMODE_tty8=

FBMODE_tty12="Q128x48"

FBMODE_tty21="Q128x48"
FBMODE_tty22="Q80x25"
FBMODE_tty23="Q128x48"
FBMODE_tty24="Q128x48"
--- >8 --- END

If I missed any needed information, please ask. :-)

   Regards,
     Dawid
-- 
                 http://www.muppetlabs.com/~breadbox/bf/
+++++[>++++++<-]>++[>+>++>+++>++++<<<<-]>>++++.>+.>---------.<++++++++.--
---.<<.>+++++++.>>--.---.---.<-.>+++++++++++.<++++++++.++++.>>++++++++++.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Matrox Oopsed when using kernel with ACPI support...

[Petr Vandrovec]

On  7 Aug 02 at 10:57, Dawid Kuroczko wrote:
> No modules in ksyms, skipping objects
> Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file?
> Aug  7 02:08:34 atlantis kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000200
> Aug  7 02:08:34 atlantis kernel: c024d739
> Aug  7 02:08:34 atlantis kernel: *pde = 00000000
> >>EIP; c024d739 <matrox_cfbX_putcs+189/280>   <=====
> Trace; c024d88d <matrox_cfb8_putcs+5d/70>
> Trace; c0246f44 <fbcon_putcs+94/100>
> Trace; c0205257 <do_update_region+127/190>

> Code;  c024d739 <matrox_cfbX_putcs+189/280>   <=====
>    0:   f3 a5                     repz movsl %ds:(%esi),%es:(%edi)   <=====

Uh-oh. Impossible. Do you use multihead, or do all your ttyS belong
to /dev/fb0? If you are using /dev/fb1 (but you should do it anyway...)
please apply patch from
ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/fbset-through-vt-2.4.19-rc5.gz
to your kernel. Besides that it fixes (oopses|kernel corruption) if you do 
'fbset -fb /dev/fb0' while you are watching console on /dev/fb1, it also
allows you to do 'fbset -fb /dev/tty*' - this could simplify your
script a lot. And no, patch is not going to the kernel. James vetoed it
years ago...

And while you are on it, please try
ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/mga-2.4.19-rc5-tvout.gz
too. But I believe that fbset-through-vt patch will fix your oopses, and
this mga patch will not bring any new feature to your old MGA.
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz
                                                


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Matrox Oopsed when using kernel with ACPI support...

[Dawid Kuroczko]

On Wed, 7 Aug 2002, Petr Vandrovec wrote:

> > Code;  c024d739 <matrox_cfbX_putcs+189/280>   <=====
> >    0:   f3 a5                     repz movsl %ds:(%esi),%es:(%edi)   <=====
> 
> Uh-oh. Impossible. Do you use multihead, or do all your ttyS belong
> to /dev/fb0? If you are using /dev/fb1 (but you should do it anyway...)
> please apply patch from
> ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/fbset-through-vt-2.4.19-rc5.gz
> to your kernel. Besides that it fixes (oopses|kernel corruption) if you do 
> 'fbset -fb /dev/fb0' while you are watching console on /dev/fb1, it also
> allows you to do 'fbset -fb /dev/tty*' - this could simplify your

Actually I have only one fbdev:
[root@atlantis ~]# cat /proc/fb
0 MATROX VGA

...the trick with open/fbdev pair might

> script a lot. And no, patch is not going to the kernel. James vetoed it
> years ago...
Oh [ anyways the patch is great! and I runned the "ugly old script" and
it works fine too :) ]

> And while you are on it, please try
> ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/mga-2.4.19-rc5-tvout.gz
> too. But I believe that fbset-through-vt patch will fix your oopses, and
> this mga patch will not bring any new feature to your old MGA.

I applied it and appears to be rock solid.  If I experience any problems,
I'll write.  The card has no TV out, so only new feature are new things
in /proc:

[root@atlantis ~]# cat /proc/driver/mga/fb0/bios                                              
BIOS:   0.0.0
Output: 0x00
TVOut:  no
PINS:   found
Info:   c03f2a0c
[root@atlantis ~]# hexdump -c /proc/driver/mga/fb0/pins
0000000   .   A   @   ÿ  \0 002   .   Ä 003  \0  \0 021   A   B   C   1
0000010   7   3   5   1  \0 213   X  \0   4 213   X  \0   2   0   7  \0
0000020  \0  \0   ¢   &   ÿ   ÿ   ÿ   ÿ  \0   F   F   <   ÿ   <   2   7
0000030   ÿ   ÿ   ÿ   ÿ   î   ÿ   ÿ   ÿ   ÿ   ÿ   ÿ   ÿ   ÿ   ÿ   ÿ   à
0000040

And once again lots of thanks for quick response and solving my
problem (and for fbset-through-vt which is defenatley going to stay
in my copy of kernel :)).

   Regards,
      Dawid



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf