From: Olaf Hering <hidden> Date: 2005-02-25 17:29:58
On Fri, Feb 25, Benjamin Herrenschmidt wrote:
On Fri, 2005-02-25 at 08:08 +0100, Olaf Hering wrote:
quoted
On Fri, Feb 25, Benjamin Herrenschmidt wrote:
quoted
On Thu, 2005-02-24 at 15:50 +0100, Olaf Hering wrote:
quoted
On Wed, Feb 23, Linus Torvalds wrote:
quoted
This time it's really supposed to be a quickie, so people who can, please
check it out, and we'll make the real 2.6.11 asap.
radeonfb oopses on intel.
Havent checked yet when it started with it.
ACPI: PCI interrupt 0000:00:12.0[A] -> GSI 11 (level, low) -> IRQ 11
eth0: VIA Rhine II at 0x1c400, 00:11:5b:83:1e:76, IRQ 11.
eth0: MII PHY found at address 1, status 0x7869 advertising 05e1 Link 45e1.
usb 5-1: new low speed USB device using uhci_hcd and address 2
ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11
radeonfb: Found Intel x86 BIOS ROM Image
radeonfb: Retreived PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=133.00 Mhz, System=133.00 MHz
radeonfb: PLL min 12000 max 35000
NET: Registered protocol family 23
radeonfb: Monitor 1 type DFP found
radeonfb: EDID probed
radeonfb: Monitor 2 type no found
radeonfb: Assuming panel size 8x1
Hrm... that's totally bogus. What machine is this ?
Some i386 box with radeon 7000.
It seem to detect the flat panel incorrectly, or the EDID data is bogus,
maybe that's wrecking something in the new modelist management in
fbdev ? It might be causing us to use a bogus mode that itself casues
atyfb to crash. Tried forcing a mode ?
cfb_imageblit(320) dst1 fa51a800 base e0b80000 bitstart 1999a800
fast_imageblit(237) s daea4000 dst1 fa51a800
fast_imageblit(269) j 1 fa51a800 0
Unable to handle kernel paging request at virtual address fa51a800
is bitstart incorrect or is the thing just not (yet) mapped?
radeonfb: Found Intel x86 BIOS ROM Image
radeonfb: Retreived PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=133.00 Mhz, System=133.00 MHz
radeonfb: PLL min 12000 max 35000
radeonfb: Monitor 1 type DFP found
radeonfb: EDID probed
radeonfb: Monitor 2 type no found
radeonfb: Assuming panel size 8x1
radeonfb: Can't find mode for panel size, going back to CRT
cfb_imageblit(320) dst1 fa51a800 base e0b80000 bitstart 1999a800
fast_imageblit(237) s daea4000 dst1 fa51a800
fast_imageblit(269) j 1 fa51a800 0
Unable to handle kernel paging request at virtual address fa51a800
printing eip:
c020f17e
*pde = 00000000
Oops: 0002 [#1]
Modules linked in: ohci1394 ieee1394 radeonfb i2c_algo_bit i2c_core ehci_hcd uhci_hcd capability usbcore
CPU: 0
EIP: 0060:[<c020f17e>] Tainted: G U VLI
EFLAGS: 00010282 (2.6.11-rc5-20050225-default)
EIP is at cfb_imageblit+0x57e/0x67c
eax: 00000000 ebx: 00000001 ecx: 00000000 edx: fa51a800
esi: fa51a804 edi: daea4000 ebp: 00000004 esp: dcae9c14
ds: 007b es: 007b ss: 0068
Process modprobe (pid: 2080, threadinfo=dcae8000 task=dc4a7550)
Stack: c01110ac 00000001 c0321d60 dcae9c20 dcae9c20 c01303a2 00000001 c03c87a8
0000000a dae23ca8 c011c783 00000046 00000000 dc202000 00000046 dcae9c64
c010513d 0000384d dc202290 00000007 c032db20 daea4000 00000000 0000000f
Call Trace:
[<c01110ac>] smp_local_timer_interrupt+0xc/0x50
[<c01303a2>] handle_IRQ_event+0x32/0x70
[<c011c783>] __do_softirq+0x43/0xa0
[<c010513d>] do_IRQ+0x3d/0x60
[<c020d790>] soft_cursor+0x190/0x200
[<c02043cc>] bit_cursor+0x48c/0x4f0
[<e0b26c01>] radeonfb_prim_fillrect+0xf1/0x120 [radeonfb]
[<c012043f>] msleep+0x2f/0x40
[<c01fff28>] fbcon_cursor+0x1a8/0x280
[<c023ad08>] hide_cursor+0x18/0x30
[<c023b014>] redraw_screen+0x174/0x200
[<c01fed4a>] fbcon_prepare_logo+0x39a/0x3a0
[<c01ff8a0>] fbcon_init+0x2b0/0x370
[<c023b1a9>] visual_init+0xe9/0x170
From: James Simmons <hidden> Date: 2005-02-25 17:59:15
cfb_imageblit(320) dst1 fa51a800 base e0b80000 bitstart 1999a800
fast_imageblit(237) s daea4000 dst1 fa51a800
fast_imageblit(269) j 1 fa51a800 0
Unable to handle kernel paging request at virtual address fa51a800
is bitstart incorrect or is the thing just not (yet) mapped?
From: Olaf Hering <hidden> Date: 2005-02-25 20:24:36
On Fri, Feb 25, James Simmons wrote:
quoted
cfb_imageblit(320) dst1 fa51a800 base e0b80000 bitstart 1999a800
fast_imageblit(237) s daea4000 dst1 fa51a800
fast_imageblit(269) j 1 fa51a800 0
Unable to handle kernel paging request at virtual address fa51a800
is bitstart incorrect or is the thing just not (yet) mapped?
Looks like the screen_base is not mapped to.
rc3 worked ok, rc4 does not. testing the -bk snapshots now.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
From: Olaf Hering <hidden> Date: 2005-02-25 21:23:00
On Fri, Feb 25, Olaf Hering wrote:
On Fri, Feb 25, James Simmons wrote:
quoted
quoted
cfb_imageblit(320) dst1 fa51a800 base e0b80000 bitstart 1999a800
fast_imageblit(237) s daea4000 dst1 fa51a800
fast_imageblit(269) j 1 fa51a800 0
Unable to handle kernel paging request at virtual address fa51a800
is bitstart incorrect or is the thing just not (yet) mapped?
Looks like the screen_base is not mapped to.
rc3 worked ok, rc4 does not. testing the -bk snapshots now.
bk8 works, bk9 breaks, it contains the radeonfb update.
it works ok if the driver is compiled into the kernel.
From: Olaf Hering <hidden> Date: 2005-02-25 23:30:53
On Fri, Feb 25, Olaf Hering wrote:
On Fri, Feb 25, Olaf Hering wrote:
quoted
On Fri, Feb 25, James Simmons wrote:
quoted
quoted
cfb_imageblit(320) dst1 fa51a800 base e0b80000 bitstart 1999a800
fast_imageblit(237) s daea4000 dst1 fa51a800
fast_imageblit(269) j 1 fa51a800 0
Unable to handle kernel paging request at virtual address fa51a800
is bitstart incorrect or is the thing just not (yet) mapped?
Looks like the screen_base is not mapped to.
rc3 worked ok, rc4 does not. testing the -bk snapshots now.
bk8 works, bk9 breaks, it contains the radeonfb update.
it works ok if the driver is compiled into the kernel.
modedb = rinfo->mon1_modedb; passes some shit to fb_find_mode() which
kills my screen(1) when DPRINTK is enabled. it dies because bitstart
relies on xres_virtual which is 0xcccccc or whatever.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2005-02-26 00:55:34
quoted
It seem to detect the flat panel incorrectly, or the EDID data is bogus,
maybe that's wrecking something in the new modelist management in
fbdev ? It might be causing us to use a bogus mode that itself casues
atyfb to crash. Tried forcing a mode ?
cfb_imageblit(320) dst1 fa51a800 base e0b80000 bitstart 1999a800
fast_imageblit(237) s daea4000 dst1 fa51a800
fast_imageblit(269) j 1 fa51a800 0
Unable to handle kernel paging request at virtual address fa51a800
is bitstart incorrect or is the thing just not (yet) mapped?
It should be all mapped, i suspect the mode set is totally bogus. To
check it, can you enable radeonfb verbose debug ?
radeonfb: Found Intel x86 BIOS ROM Image
radeonfb: Retreived PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=133.00 Mhz, System=133.00 MHz
radeonfb: PLL min 12000 max 35000
radeonfb: Monitor 1 type DFP found
radeonfb: EDID probed
radeonfb: Monitor 2 type no found
radeonfb: Assuming panel size 8x1
radeonfb: Can't find mode for panel size, going back to CRT
cfb_imageblit(320) dst1 fa51a800 base e0b80000 bitstart 1999a800
fast_imageblit(237) s daea4000 dst1 fa51a800
fast_imageblit(269) j 1 fa51a800 0
Unable to handle kernel paging request at virtual address fa51a800
printing eip:
c020f17e
*pde = 00000000
Oops: 0002 [#1]
Modules linked in: ohci1394 ieee1394 radeonfb i2c_algo_bit i2c_core ehci_hcd uhci_hcd capability usbcore
CPU: 0
EIP: 0060:[<c020f17e>] Tainted: G U VLI
EFLAGS: 00010282 (2.6.11-rc5-20050225-default)
EIP is at cfb_imageblit+0x57e/0x67c
eax: 00000000 ebx: 00000001 ecx: 00000000 edx: fa51a800
esi: fa51a804 edi: daea4000 ebp: 00000004 esp: dcae9c14
ds: 007b es: 007b ss: 0068
Process modprobe (pid: 2080, threadinfo=dcae8000 task=dc4a7550)
Stack: c01110ac 00000001 c0321d60 dcae9c20 dcae9c20 c01303a2 00000001 c03c87a8
0000000a dae23ca8 c011c783 00000046 00000000 dc202000 00000046 dcae9c64
c010513d 0000384d dc202290 00000007 c032db20 daea4000 00000000 0000000f
Call Trace:
[<c01110ac>] smp_local_timer_interrupt+0xc/0x50
[<c01303a2>] handle_IRQ_event+0x32/0x70
[<c011c783>] __do_softirq+0x43/0xa0
[<c010513d>] do_IRQ+0x3d/0x60
[<c020d790>] soft_cursor+0x190/0x200
[<c02043cc>] bit_cursor+0x48c/0x4f0
[<e0b26c01>] radeonfb_prim_fillrect+0xf1/0x120 [radeonfb]
[<c012043f>] msleep+0x2f/0x40
[<c01fff28>] fbcon_cursor+0x1a8/0x280
[<c023ad08>] hide_cursor+0x18/0x30
[<c023b014>] redraw_screen+0x174/0x200
[<c01fed4a>] fbcon_prepare_logo+0x39a/0x3a0
[<c01ff8a0>] fbcon_init+0x2b0/0x370
[<c023b1a9>] visual_init+0xe9/0x170
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2005-02-26 00:59:04
On Fri, 2005-02-25 at 21:24 +0100, Olaf Hering wrote:
On Fri, Feb 25, James Simmons wrote:
quoted
quoted
cfb_imageblit(320) dst1 fa51a800 base e0b80000 bitstart 1999a800
fast_imageblit(237) s daea4000 dst1 fa51a800
fast_imageblit(269) j 1 fa51a800 0
Unable to handle kernel paging request at virtual address fa51a800
is bitstart incorrect or is the thing just not (yet) mapped?
Looks like the screen_base is not mapped to.
rc3 worked ok, rc4 does not. testing the -bk snapshots now.
Oh, it's probably the new radeonfb, I have no doubt about that, but I
think the problems has to do with a bogus mode. Maybe set_par is simply
failing and the fbdev layer still tries to tap the card or something
like that. Please, enable verbose debug, add some printk's around
set_par to check what the mode looks like and what gets ioremap'ed.
Ben.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2005-02-26 01:00:56
On Fri, 2005-02-25 at 22:21 +0100, Olaf Hering wrote:
On Fri, Feb 25, Olaf Hering wrote:
quoted
On Fri, Feb 25, James Simmons wrote:
quoted
quoted
cfb_imageblit(320) dst1 fa51a800 base e0b80000 bitstart 1999a800
fast_imageblit(237) s daea4000 dst1 fa51a800
fast_imageblit(269) j 1 fa51a800 0
Unable to handle kernel paging request at virtual address fa51a800
is bitstart incorrect or is the thing just not (yet) mapped?
Looks like the screen_base is not mapped to.
rc3 worked ok, rc4 does not. testing the -bk snapshots now.
bk8 works, bk9 breaks, it contains the radeonfb update.
it works ok if the driver is compiled into the kernel.
Ah, that's a good point. Can you send me the dmesg outputs of in kernel
vs. in module with radeonfb verbose debug enabled ?
Ben.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2005-02-26 01:04:37
On Sat, 2005-02-26 at 00:30 +0100, Olaf Hering wrote:
On Fri, Feb 25, Olaf Hering wrote:
quoted
On Fri, Feb 25, Olaf Hering wrote:
quoted
On Fri, Feb 25, James Simmons wrote:
quoted
quoted
cfb_imageblit(320) dst1 fa51a800 base e0b80000 bitstart 1999a800
fast_imageblit(237) s daea4000 dst1 fa51a800
fast_imageblit(269) j 1 fa51a800 0
Unable to handle kernel paging request at virtual address fa51a800
is bitstart incorrect or is the thing just not (yet) mapped?
Looks like the screen_base is not mapped to.
rc3 worked ok, rc4 does not. testing the -bk snapshots now.
bk8 works, bk9 breaks, it contains the radeonfb update.
it works ok if the driver is compiled into the kernel.
modedb = rinfo->mon1_modedb; passes some shit to fb_find_mode() which
kills my screen(1) when DPRINTK is enabled. it dies because bitstart
relies on xres_virtual which is 0xcccccc or whatever.
I think the problem is that you have totally bogus EDID data coming from
DDC. I'm still curious what makes a difference between module and
built-in. Either we try to set a bogus mode, or we just fail setting a
mode at all and fbdev doesn't deal with that properly.
Did you try plugging a different monitor ? Also, do you have output with
a recent X.org (6.8.2 for example) ? Can you send me that log too ?
Ben.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
From: Giuseppe Bilotta <hidden> Date: 2005-02-26 09:52:58
Benjamin Herrenschmidt wrote:
I'm still curious what makes a difference between module and
built-in.
There seems to be quite some difference between module and
built-in for framebuffer drivers. Quite some time ago I
reported a problem with nVidia framebuffer driver making the
screen go nuts or simply blank (but no lock-up; could still
blind type). I finally discovered that the problem only
happened when the driver was compiled as a module.
--
Giuseppe "Oblomov" Bilotta
Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
(Roger Waters)