From: Steven Walter <srwalter@yahoo.com>
To: Jordan Breeding <jordan.breeding@attbi.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Oops in 2.5.20 with radeon framebuffer
Date: Mon, 3 Jun 2002 12:19:22 -0500 [thread overview]
Message-ID: <20020603171922.GA30651@hapablap.dyn.dhs.org> (raw)
In-Reply-To: <3CFB72BE.20406@attbi.com>
The -dj branch includes a near-complete rewrite of the framebuffer layer
by James Simmons. This is almost certainly why -dj works where mainline
fails. To be sure, you can grab James' patch and apply it to mainline,
and see if that fixes the problem.
*Searches for the patch url*
Aha! This appears to be it: http://www.transvirtual.com/~jsimmons/fbdev.diff
See if that helps.
On Mon, Jun 03, 2002 at 08:44:30AM -0500, Jordan Breeding wrote:
> Hello,
>
> For the past couple of 2.5.x kernel versions I have been seeing an
> odd Oops on boot of a newly built kernel. The Oops only happens on
> stock kernels from ftp.kernel.org, if I wait until the -dj patch for the
> version in question it always boots fine. I guess the means that
> somewhere the framebuffer code in -dj is different enough from mainline
> to allow my machine to boot and to work perfectly. With a mainline
> kernel my system will start to boot and then as soon as video switches
> from text to framebuffer the Oops happens, the logo in the top left
> never even gets drawn. Attached is a copy of the oops which has been
> run through ksymoops already. Thank you for any help.
>
> Jordan
>
> ksymoops 2.4.4 on i686 2.5.18-dj1. Options used
> -v /usr/src/linux/vmlinux (specified)
> -K (specified)
> -L (specified)
> -o /lib/modules/2.5.20 (specified)
> -m /usr/src/linux/System.map (specified)
>
> No modules in ksyms, skipping objects
> Unable to handle kernel NULL pointer dereference at virtual address 00000040
> c02e4554
> *pde = 00000000
> Oops: 0002
> CPU: 0
> EIP: 0010:[<c02e4554>] Not Tainted
> Using defaults from ksymoops -t elf32-i386 -a i386
> eax: c053c6c0 ebx: 00000020 ecx: 00000008 edx: 00000020
> esi: c053c6c0 edi: 00000040 ebp: 00000000 esp: c17d7d94
> ds: 0018 es: 0018 ss: 0018
> Stack: 00000020 00002c2c 00003e3e 00000030 00000010 dfd06128 00000000 00000000
> dfd06000 c02e8fc8 c044530c dfd06128 00000000 00000010 00000010 00000010
> 00000010 c046dd84 c044530c 00000001 00000000 dfd06000 c0538340 c1507a40
> Call Trace: [<c02e8fc8>] [<c02e59b7>] [<c02eb7fd>] [<c02e73ad>] [<c02512b9>]
> [<c0254f4c>] [<c02e429c>] [<c02e9f59>] [<c022368d>] [<c024048e>] [<c02405d5>]
> [<c02415d6>] [<c02405f2>] [<c02405a0>] [<c0241cc0>] [<c0105000>] [<c0223776>]
> [<c01050de>] [<c0105000>] [<c0107386>] [<c0105080>]
> Code: f3 a5 f6 c3 02 74 02 66 a5 f6 c3 01 74 01 a4 eb 0b 53 56 57
>
> >>EIP; c02e4554 <fb_copy_cmap+a4/2c0> <=====
> Trace; c02e8fc8 <gen_set_cmap+88/a0>
> Trace; c02e59b7 <fbcon_setup+8c7/940>
> Trace; c02eb7fd <radeonfb_switch+fd/130>
> Trace; c02e73ad <fbcon_switch+17d/1c0>
> Trace; c02512b9 <redraw_screen+c9/140>
> Trace; c0254f4c <take_over_console+ec/180>
> Trace; c02e429c <register_framebuffer+fc/140>
> Trace; c02e9f59 <radeonfb_pci_register+679/7d0>
> Trace; c022368d <pci_device_probe+1d/30>
> Trace; c024048e <found_match+2e/b0>
> Trace; c02405d5 <do_driver_bind+35/40>
> Trace; c02415d6 <bus_for_each_dev+a6/120>
> Trace; c02405f2 <driver_bind+12/20>
> Trace; c02405a0 <do_driver_bind+0/40>
> Trace; c0241cc0 <driver_register+b0/c0>
> Trace; c0105000 <_stext+0/0>
> Trace; c0223776 <pci_register_driver+36/50>
> Trace; c01050de <init+5e/200>
> Trace; c0105000 <_stext+0/0>
> Trace; c0107386 <kernel_thread+26/30>
> Trace; c0105080 <init+0/200>
> Code; c02e4554 <fb_copy_cmap+a4/2c0>
> 00000000 <_EIP>:
> Code; c02e4554 <fb_copy_cmap+a4/2c0> <=====
> 0: f3 a5 repz movsl %ds:(%esi),%es:(%edi) <=====
> Code; c02e4556 <fb_copy_cmap+a6/2c0>
> 2: f6 c3 02 test $0x2,%bl
> Code; c02e4559 <fb_copy_cmap+a9/2c0>
> 5: 74 02 je 9 <_EIP+0x9> c02e455d <fb_copy_cmap+ad/2c0>
> Code; c02e455b <fb_copy_cmap+ab/2c0>
> 7: 66 a5 movsw %ds:(%esi),%es:(%edi)
> Code; c02e455d <fb_copy_cmap+ad/2c0>
> 9: f6 c3 01 test $0x1,%bl
> Code; c02e4560 <fb_copy_cmap+b0/2c0>
> c: 74 01 je f <_EIP+0xf> c02e4563 <fb_copy_cmap+b3/2c0>
> Code; c02e4562 <fb_copy_cmap+b2/2c0>
> e: a4 movsb %ds:(%esi),%es:(%edi)
> Code; c02e4563 <fb_copy_cmap+b3/2c0>
> f: eb 0b jmp 1c <_EIP+0x1c> c02e4570 <fb_copy_cmap+c0/2c0>
> Code; c02e4565 <fb_copy_cmap+b5/2c0>
> 11: 53 push %ebx
> Code; c02e4566 <fb_copy_cmap+b6/2c0>
> 12: 56 push %esi
> Code; c02e4567 <fb_copy_cmap+b7/2c0>
> 13: 57 push %edi
>
> <0>Kernel Panic: Attempted to kill init!
>
--
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell
He's alive. He's alive! Oh, that fellow at RadioShack said I was mad!
Well, who's mad now?
-- Montgomery C. Burns
next prev parent reply other threads:[~2002-06-03 17:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-03 13:44 Oops in 2.5.20 with radeon framebuffer Jordan Breeding
2002-06-03 17:19 ` Steven Walter [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-06-03 9:35 Jordan Breeding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020603171922.GA30651@hapablap.dyn.dhs.org \
--to=srwalter@yahoo.com \
--cc=jordan.breeding@attbi.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox