Bug 71965 - (DRI I810)kernel oops on exiting X (i810)
(DRI I810)kernel oops on exiting X (i810)
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-08-20 10:50 EDT by Jure Pecar
Modified: 2008-08-01 12:22 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:39:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jure Pecar 2002-08-20 10:50:51 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417

Description of problem:
On i810/815 onboard AGP graphic, i see a kernel oops on exiting X that somehow
blocks agp (X cant be started again without reboot).

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.startx
2.exit x
3.startx
	

Actual Results:  I get black screen after step 2, switching virtual consoles
helps. At the next startx, X says GARTInit: 'AGPIOC_INFO failed (Invalid
argument)', 'AGP GART support not available' and thus the final 'no screens found'.

Expected Results:  Should work as expected.

Additional info:

I have this reproducible on 2.4.18-5 on an intel 810 board and on intel 815 board.

Oops on i815:

ksymoops 2.4.4 on i686 2.4.18-5.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.18-5/ (default)
     -m /boot/System.map-2.4.18-5 (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.

Error (expand_objects): cannot stat(/lib/ext3.o) for ext3
Error (expand_objects): cannot stat(/lib/jbd.o) for jbd
Warning (map_ksym_to_module): cannot match loaded module ext3 to a unique module
object.  Trace may not be reliable.
Unable to handle kernel paging request at virtual address 0100001b
c0128962
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c0128962>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00013246
eax: 01000000   ebx: c1299308   ecx: c1299308   edx: 00000000
esi: cbe0d000   edi: cd81f800   ebp: 00000000   esp: cd79fee4
ds: 0018   es: 0018   ss: 0018
Process X (pid: 1062, stackpage=cd79f000)
Stack: c1299308 cbe0d000 d09cb953 c1299308 cdcadf20 cce4a000 d09cb9af cd81f800 
       cbe0d000 00000000 bffffa30 cd79ff60 d09cbf0c cd81f800 cd81f800 00000002 
       00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
Call Trace: [<d09cb953>] i810_free_page [i810] 0x33 
[<d09cb9af>] i810_dma_cleanup [i810] 0x3f 
[<d09cbf0c>] i810_dma_init [i810] 0xac 
[<d09c7924>] i810_ioctl [i810] 0xe4 
[<c0145c47>] sys_ioctl [kernel] 0x217 
[<c0109e1c>] do_IRQ [kernel] 0x9c 
[<c0108913>] system_call [kernel] 0x33 
Code: 0f b6 50 1b 8b 1c 95 2c 55 33 c0 89 c2 69 d2 01 00 37 9e 8b

>>EIP; c0128962 <unlock_page+2/80>   <=====
Trace; d09cb953 <[i810]i810_free_page+33/50>
Trace; d09cb9af <[i810]i810_dma_cleanup+3f/b0>
Trace; d09cbf0c <[i810]i810_dma_init+ac/c0>
Trace; d09c7924 <[i810]i810_ioctl+e4/f0>
Trace; c0145c47 <sys_ioctl+217/230>
Trace; c0109e1c <do_IRQ+9c/b0>
Trace; c0108913 <system_call+33/38>
Code;  c0128962 <unlock_page+2/80>
00000000 <_EIP>:
Code;  c0128962 <unlock_page+2/80>   <=====
   0:   0f b6 50 1b               movzbl 0x1b(%eax),%edx   <=====
Code;  c0128966 <unlock_page+6/80>
   4:   8b 1c 95 2c 55 33 c0      mov    0xc033552c(,%edx,4),%ebx
Code;  c012896d <unlock_page+d/80>
   b:   89 c2                     mov    %eax,%edx
Code;  c012896f <unlock_page+f/80>
   d:   69 d2 01 00 37 9e         imul   $0x9e370001,%edx,%edx
Code;  c0128975 <unlock_page+15/80>
  13:   8b 00                     mov    (%eax),%eax

2 warnings and 2 errors issued.  Results may not be reliable.

Oops on i810:

ksymoops 2.4.4 on i686 2.4.18-5.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.18-5/ (default)
     -m /boot/System.map-2.4.18-5 (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.

Error (expand_objects): cannot stat(/lib/ext3.o) for ext3
Error (expand_objects): cannot stat(/lib/jbd.o) for jbd
Error (pclose_local): find_objects pclose failed 0x100
Warning (map_ksym_to_module): cannot match loaded module ext3 to a unique module
object.  Trace may not be reliable.
Unable to handle kernel paging request at virtual address 0100001b
c0128962
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c0128962>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00013246
eax: 01000000   ebx: c1656858   ecx: c1656858   edx: 00000000
esi: dcf93000   edi: deda0000   ebp: 00000000   esp: db58dee4
ds: 0018   es: 0018   ss: 0018
Process X (pid: 1145, stackpage=db58d000)
Stack: c1656858 dcf93000 e0953953 c1656858 df704140 deca4000 e09539af deda0000 
       dcf93000 00000000 bffff900 db58df60 e0953f0c deda0000 deda0000 00000002 
       00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
Call Trace: [<e0953953>] i810_free_page [i810] 0x33 
[<e09539af>] i810_dma_cleanup [i810] 0x3f 
[<e0953f0c>] i810_dma_init [i810] 0xac 
[<e094f924>] i810_ioctl [i810] 0xe4 
[<c0145c47>] sys_ioctl [kernel] 0x217 
[<c0108913>] system_call [kernel] 0x33 
Code: 0f b6 50 1b 8b 1c 95 2c 55 33 c0 89 c2 69 d2 01 00 37 9e 8b

>>EIP; c0128962 <unlock_page+2/80>   <=====
Trace; e0953953 <[i810]i810_free_page+33/50>
Trace; e09539af <[i810]i810_dma_cleanup+3f/b0>
Trace; e0953f0c <[i810]i810_dma_init+ac/c0>
Trace; e094f924 <[i810]i810_ioctl+e4/f0>
Trace; c0145c47 <sys_ioctl+217/230>
Trace; c0108913 <system_call+33/38>
Code;  c0128962 <unlock_page+2/80>
00000000 <_EIP>:
Code;  c0128962 <unlock_page+2/80>   <=====
   0:   0f b6 50 1b               movzbl 0x1b(%eax),%edx   <=====
Code;  c0128966 <unlock_page+6/80>
   4:   8b 1c 95 2c 55 33 c0      mov    0xc033552c(,%edx,4),%ebx
Code;  c012896d <unlock_page+d/80>
   b:   89 c2                     mov    %eax,%edx
Code;  c012896f <unlock_page+f/80>
   d:   69 d2 01 00 37 9e         imul   $0x9e370001,%edx,%edx
Code;  c0128975 <unlock_page+15/80>
  13:   8b 00                     mov    (%eax),%eax


2 warnings and 3 errors issued.  Results may not be reliable.


The most funny thing is that this worked fine on 2.4.18-3. I guess it's one of
those tiny changes that wasn't worth to be put into the changelog ...
Comment 1 Roberto Ugoccioni 2002-10-25 11:18:34 EDT
After un up2date to kernel 2.4.18-17.7.x on my Compaq Deskpro
with i815 Graphics chip on the motherboard running redhat 7.2 I get
kernel panic each time X11 exits, both from a session (gnome,
kde, fvwm I tried) or just exiting (via reboot or Ctrl-Alt-Backspace) the gdm
login screen.
The error is:

  Aiee, killing interrupt handler!
  In interrupt handler - not syncing

The dump shows X as the process, and the call trace shows several
functions related to i810 and agp. (I can add more info on this if
requested).

The panic happens consistently at every shutdown of X11. It happens
also on another PC identical to mine (identical both in hardware and
software). It happens also after an
upgrade to redhat 7.3, which uses the same 2.4.18-17.7.x kernel.
Booting with a previous kernel (2.4.9-34) solves the problem.
(I am presently running redhat 7.3 with kernel 2.4.9-34 leftover from 7.2)

I also tried replacing the onboard chip i815 using a Matrox 450 AGP card,
and the panic does NOT happen with either kernel in this case.
Comment 2 Alexei Dets 2002-11-22 13:50:14 EST
Seems that we have the same (?) problem in our company on _all_ i810-based     
computers (Dell OptiPlex GX110) with RH-7.3 with all updates, kernel 
2.4.18-18.7.x (same with other kernels too).  
For example, if X is crashing it is not possible to restart it (at least on    
runlevel 5) - init will try to restart X but the only result will be messages    
like "i810 drm lockup" on the screen. It is necessary to restart computer :-(   
Also, if I'm choosing in KDE (doesn't matter, can be any session, even   
failsafe without any windowmanager) "log off", it should put me into my KDM  
login screen, but this never happens - KDE shuts down, screen becomes blank 
but KDM never appears. But it _is_ running (ps shows kdm_greet process 
running) and my monitor (ViewSonic E790) shows that it is in 1280x1024x85Hz 
mode (unlike 640x400x75 in console window where I can switch with 
Ctrl-Alt-Fn). Just the screen is blank... 
I can also add that this _never_ happens with unpatched kernels from 
kernel.org (I've used lots of them) in particular it never happens with 2.4.18 
& 2.4.19. Also X is loading significantly faster with kernel.org's kernels. 
Probably I can add any additional required information to solve this ANNOYING 
problem.
Comment 3 Alexei Dets 2002-11-22 13:56:40 EST
BTW, forgot one thing: after this "log off" with blank X screen it is possible 
to switch to VT1, for example, login as root, telinit 3, telinit 5 - X will 
start as usual 
Comment 4 Bugzilla owner 2004-09-30 11:39:51 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

Note You need to log in before you can comment on or make changes to this bug.