I got a paging request oops while hitting Control-D (page down) in VIM. I was
at the end of the file and I got the oops and nothing worked accept the SysRq
key combination. I was able to repeat this several times. The only
difference was that sometimes I could not use SysRq, and it (the computer)
would reboot it self after a few seconds of being frozen.
I am using the matroxfb driver as a module for two monitors. The first device
is a Matrox Millennium, and the second is a Mystique. I have a symbolic link
from matroxfb to matroxfb2 and I load the module like this:
insmod matroxfb vesa=0x107 blink=0 hwcursor=0 grayscale dev=0
insmod matroxfb2 vesa=0x105 blink=0 hwcursor=0 grayscale dev=1
The first head is a 21" and the second is a 17" which is why I am using the
different modes. Anyhow I now remap the consoles with con2fbmap like so:
Consoles 1-12 are mapped to fb2 (Millenium)
Consoles 13-24 are mapped to fb3 (Mystique)
I can then login on those consoles and it shows up on the appropriated head.
The problem comes about when I am using vim (as root btw) and am hitting
control-d (maybe control-u to I don't remember) as I said above. Some times
it will be a few minutes of editing the file and moving around before it
happens.
Here is the kernel oops I wrote down on the last lock (that did not
auto-reboot). I messed up and missed a few things when writing this down (I
can redo it if necessary)!:
---
Unable to handle paging request at virtual address 07200720
current->tss.cr3=00101000, %cr3=001010000
*pde=00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c01121fb>]
EFLAGS: 00010002
eax: 07200720 ebx: 07200720 ecx: 07200720 edx: d7fd3f88
esi: 07200720 edi: ???????? ebp: ???????? esp: ????????
ds: ???? es: 0018 ss: 0018
Process swapper (pid: 0, process nr: 0, stackpage=c01e3000)
Stack: c0205694 c01e2000 c01e2000 0000ffda c01e3efc 00000000 c01e3f04 00000004
00000000 c0118655 00000000 c01e2000 0000ffda c01e3f30 c01e2000 ffffff9d
c01e2000 c0111549 c01e2000 0000ffda 00000018 ffffff00 c0108518 ????????
Call Trace: [<c01186b55>] [<c0111549>] [<c0108518>] [<c0108529>] [<0108577>]
[<c0106000>] [<c0108ccd>]
[<c0108be>] [<c0109de0>] [<c0109d98>] [<c0106000>] [<c0106088>]
[<c0106000>] [<c0100175>]
Code: 89 01 85 c0 74 03 89 48 04 c7 42 04 00 00 00 00 c7 02 00 00
Aiee, killing interrupt handler
Kernel panic: Attempted to kill the idle task!
In swapper task - not syncing
---
Wel I think I messed up on the first part of the third line int the Call
Trace, and the last part of the Stack, besudes the edi, ebp, etc. I guess I
should have taken a little more time to double check what I wrote against what
was on the screen.
When trying a "SysRq sync" after the above oops I got a "Unable to handle NULL
pointer dereference at virtual address 00000000" oops.
Here is some other system info:
Debian (Potato)
Linux village.oftheInter.net 2.2.14 #1 Sun Mar 19 19:56:57 CST 2000 i586 unknown
/lib/libc-2.1.3.so
fbset Version 2.1 (23/06/1999)
/proc/pci -
PCI devices found:
Bus 0, device 0, function 0:
Host bridge: VIA Technologies VT 82C597 Apollo VP3 (rev 4).
Medium devsel. Fast back-to-back capable. Master Capable. Latency=16.
Prefetchable 32 bit memory at 0xe0000000 [0xe0000008].
Bus 0, device 1, function 0:
PCI bridge: VIA Technologies VT 82C598 Apollo MVP3 AGP (rev 0).
Medium devsel. Master Capable. No bursts. Min Gnt=4.
Bus 0, device 7, function 0:
ISA bridge: VIA Technologies VT 82C586 Apollo ISA (rev 65).
Medium devsel. Master Capable. No bursts.
Bus 0, device 7, function 1:
IDE interface: VIA Technologies VT 82C586 Apollo IDE (rev 6).
Medium devsel. Fast back-to-back capable. Master Capable. Latency=64.
I/O at 0xe000 [0xe001].
Bus 0, device 7, function 3:
Bridge: VIA Technologies VT 82C586B Apollo ACPI (rev 16).
Medium devsel. Fast back-to-back capable.
Bus 0, device 8, function 0:
VGA compatible controller: Matrox Millennium (rev 1).
Medium devsel. Fast back-to-back capable. IRQ 10.
Non-prefetchable 32 bit memory at 0xe4000000 [0xe4000000].
Prefetchable 32 bit memory at 0xe5000000 [0xe5000008].
Bus 0, device 9, function 0:
Multimedia audio controller: Ensoniq AudioPCI (rev 0).
Slow devsel. IRQ 11. Master Capable. Latency=64. Min Gnt=12.Max Lat=128.
I/O at 0xe800 [0xe801].
Bus 0, device 10, function 0:
Ethernet controller: 3Com 3C595 100bTX (rev 0).
Medium devsel. IRQ 5. Master Capable. Latency=248. Min Gnt=3.Max Lat=8.
I/O at 0xec00 [0xec01].
Bus 0, device 11, function 0:
VGA compatible controller: Matrox Mystique (rev 2).
Medium devsel. Fast back-to-back capable. IRQ 7. Master Capable. Latency=64.
Non-prefetchable 32 bit memory at 0xe8000000 [0xe8000000].
Prefetchable 32 bit memory at 0xe9000000 [0xe9000008].
Non-prefetchable 32 bit memory at 0xea000000 [0xea000000].
/proc/interrupts -
CPU0
0: 201354 XT-PIC timer
1: 10782 XT-PIC keyboard
2: 0 XT-PIC cascade
4: 8930 XT-PIC serial
5: 220 XT-PIC eth0
8: 1 XT-PIC rtc
11: 0 XT-PIC es1370
12: 0 XT-PIC PS/2 Mouse
13: 1 XT-PIC fpu
14: 10710 XT-PIC ide0
15: 10 XT-PIC ide1
NMI: 0
Here is the info from /var/log/messages when insmoding the module:
Apr 17 22:44:59 village kernel: matroxfb: Matrox Millennium (PCI) detected
Apr 17 22:44:59 village kernel: matroxfb: MTRR's turned on
Apr 17 22:44:59 village kernel: matroxfb: 1280x1024x8bpp (virtual: 1280x3276)
Apr 17 22:44:59 village kernel: matroxfb: framebuffer at 0xE5000000, mapped to 0xd8793000, size 4194304
Apr 17 22:44:59 village kernel: fb2: MATROX VGA frame buffer device
Apr 17 22:44:59 village kernel: fb2: initializing hardware
Apr 17 22:44:59 village kernel: matroxfb: Matrox Mystique (PCI) detected
Apr 17 22:44:59 village kernel: matroxfb: MTRR's turned on
Apr 17 22:44:59 village kernel: matroxfb: 1024x768x8bpp (virtual: 1024x4096)
Apr 17 22:44:59 village kernel: matroxfb: framebuffer at 0xE9000000, mapped to 0xd8ba3000, size 4194304
Apr 17 22:44:59 village kernel: fb3: MATROX VGA frame buffer device
Apr 17 22:44:59 village kernel: fb3: initializing hardware
Here is another (earlier) bit from /var/log/messages when insmoding the module
including an oops:
Apr 17 21:48:43 village kernel: matroxfb: Matrox Millennium (PCI) detected
Apr 17 21:48:43 village kernel: matroxfb: MTRR's turned on
Apr 17 21:48:43 village kernel: matroxfb: 1280x1024x8bpp (virtual: 1280x3276)
Apr 17 21:48:43 village kernel: matroxfb: framebuffer at 0xE5000000, mapped to 0xd8793000, size 4194304
Apr 17 21:48:43 village kernel: fb2: MATROX VGA frame buffer device
Apr 17 21:48:43 village kernel: fb2: initializing hardware
Apr 17 21:48:52 village kernel: matroxfb: Matrox Mystique (PCI) detected
Apr 17 21:48:52 village kernel: matroxfb: MTRR's turned on
Apr 17 21:48:52 village kernel: matroxfb: 1024x768x8bpp (virtual: 1024x4096)
Apr 17 21:48:52 village kernel: matroxfb: framebuffer at 0xE9000000, mapped to 0xd8ba3000, size 4194304
Apr 17 21:48:52 village kernel: fb3: MATROX VGA frame buffer device
Apr 17 21:48:52 village kernel: fb3: initializing hardware
Apr 17 21:49:41 village kernel: Oops: 0002
Apr 17 21:49:41 village kernel: CPU: 0
Apr 17 21:49:41 village kernel: EIP: 0010:[set_con2fb_map+357/472]
Apr 17 21:49:41 village kernel: EFLAGS: 00010286
Apr 17 21:49:41 village kernel: eax: 00000000 ebx: c0204180 ecx: 00000000 edx: d484a048
Apr 17 21:49:41 village kernel: esi: 00000000 edi: 00000012 ebp: d484a000 esp: d48b7e1c
Apr 17 21:49:41 village kernel: ds: 0018 es: 0018 ss: 0018
Apr 17 21:49:41 village kernel: Process con2fbmap (pid: 920, process nr: 49, stackpage=d48b7000)
Apr 17 21:49:41 village kernel: Stack: d48b7e88 d48b7e80 d7e74800 0000000e 00000000 00000000 00000000 00000000
Apr 17 21:49:41 village kernel: 00000000 00000000 d4acc280 00004000 400f1000 c01a47b4 00000012 00000003
Apr 17 21:49:41 village kernel: 0000000d 0d57ed41 d541b680 bffffb34 00004610 ffffffe7 d4acce40 c01e1b60
Apr 17 21:49:41 village kernel: Call Trace: [fb_ioctl+1200/1356] [do_follow_link+134/148] [lookup_dentry+365/504] [fb_open+73/92] [do_no_page+194/212] [chrdev_open+72/88] [handle_mm_fault+200/316]
Apr 17 21:49:41 village kernel: [do_page_fault+263/944] [sys_ioctl+363/392] [error_code+45/52] [system_call+52/56]
Apr 17 21:49:41 village kernel: Code: 89 90 00 01 00 00 83 7d 48 00 75 03 89 45 48 39 eb 74 58 8b
Apr 17 21:50:49 village kernel: Vesafb does not support changing the video mode
Apr 17 21:57:05 village syslogd 1.3-3#33: restart.
Well, I am going to stay away from multihead fb until this is fixed. If
someone needs anymore info or onces me to test then I would be willing to do
that. BTW, I am not on linux-fbdev nor linux-kernel so CC
taylorcc@codecafe.com for any replies you wish me to see. Thanks.
Taylor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:12 EST