From: Olaf Hering <hidden> Date: 2005-02-26 00:42:31
On Thu, Feb 24, Olaf Hering wrote:
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
radeonfb: Can't find mode for panel size, going back to CRT
Unable to handle kernel paging request at virtual address f3fb4000
printing eip:
c01dec14
*pde = 00000000
Oops: 0002 [#1]
Modules linked in: via_ircc irda crc_ccitt snd_via82xx snd_ac97_codec snd_pcm snd_timer snd_page_alloc gameport snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore radeonfb i2c_algo_bit i2c_core via_rhine mii pci_hotplug ohci1394 ehci_hcd ieee1394 uhci_hcd via_agp agpgart usbcore reiserfs dm_mod ext3 jbd
CPU: 0
EIP: 0060:[<c01dec14>] Not tainted VLI
EFLAGS: 00010202 (2.6.11-rc4-bk10-200502230204-usbtest)
EIP is at cfb_imageblit+0x364/0x610
eax: 00000000 ebx: f3fb4004 ecx: 00000000 edx: f3fb4000
esi: 00000004 edi: df282000 ebp: 00000007 esp: dbef1c1c
ds: 007b es: 007b ss: 0068
Process modprobe (pid: 3180, threadinfo=dbef0000 task=da303580)
Stack: 00000001 00000008 00000001 00000008 00000001 c04a7428 0000000a da302628
c011b293 00000046 da36e23c da36e000 00000046 0000051f c01043cf c0102eca
0000051f 1c46ece9 0000002b c036a2c0 df282000 00000000 0000000f 00000001
Call Trace:
[<c011b293>] __do_softirq+0x43/0xa0
[<c01043cf>] do_IRQ+0x1f/0x30
[<c0102eca>] common_interrupt+0x1a/0x20
[<c01dd570>] soft_cursor+0x190/0x200
[<c01d9124>] bit_cursor+0x464/0x4e0
[<c011edbf>] msleep+0x2f/0x40
[<c01d4e18>] fbcon_cursor+0x1a8/0x280
[<c020eac8>] hide_cursor+0x18/0x30
[<c020edd4>] redraw_screen+0x174/0x200
[<c01d3caa>] fbcon_prepare_logo+0x39a/0x3a0
[<c01d47b0>] fbcon_init+0x260/0x300
[<c020ef69>] visual_init+0xe9/0x170
[<c02125e6>] take_over_console+0x176/0x350
[<c01d38da>] fbcon_takeover+0x5a/0x90
[<c01d846a>] fbcon_fb_registered+0x5a/0x70
[<c01d8542>] fbcon_event_notify+0x52/0x80
[<c0121898>] notifier_call_chain+0x18/0x30
[<c01da667>] register_framebuffer+0xd7/0x150
[<c0117713>] release_console_sem+0x13/0x90
[<c017f7c7>] sysfs_new_dirent+0x17/0x60
[<c017f820>] sysfs_make_dirent+0x10/0x70
[<c017f59a>] sysfs_add_file+0x3a/0x60
[<e0c4a698>] radeonfb_pci_register+0x308/0x510 [radeonfb]
[<c01ce482>] pci_device_probe_static+0x32/0x50
[<c01ce4c7>] __pci_device_probe+0x27/0x40
[<c01ce4fb>] pci_device_probe+0x1b/0x40
[<c021ef31>] driver_probe_device+0x21/0x60
[<c021f05d>] driver_attach+0x4d/0x80
[<c021f44d>] bus_add_driver+0x6d/0xa0
[<c021f948>] driver_register+0x28/0x30
[<c01ce6c4>] pci_register_driver+0x54/0x70
[<c012b1a2>] sys_init_module+0x112/0x190
[<c0102c49>] sysenter_past_esp+0x52/0x79
Code: 24 60 8b 54 24 58 29 ce 0f be 07 89 f1 d3 f8 21 d0 8b 54 24 4c 8b 4c 24 54 23 0c 82 8b 54 24 64 89 c8 31 d0 89 da 83 c3 04 85 f6 <89> 02 75 06 be 08 00 00 00 47 8b 04 24 48 89 04 24 83 3c 24 ff
<6>usbcore: registered new driver hiddev
input: USB HID v1.10 Mouse [Logitech Apple Optical USB Mouse] on usb-0000:00:10.2-1
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
modedb can not be __init because fb_find_mode() may get db == NULL.
fb_find_mode() is called from modules.
Signed-off-by: Olaf Hering <redacted>
diff -purNx tags linux-2.6.11-rc5.orig/drivers/video/modedb.c linux-2.6.11-rc5/drivers/video/modedb.c
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
sparse doesnt do that, yet? (I never looked at it.)
No, it doesn't look at the section info. I guess I could do it, but there
_is_ a "make buildcheck" which does it based on perl stuff and the link
information.
And I can do "make buildcheck" myself, but some people have done it before
and know which ones are false positives etc, so I was hoping..
Hint hint, wherever you are..
Linus
-------------------------------------------------------
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: Buttchereit, Axel (XL) <hidden> Date: 2005-02-26 01:13:29
Linus Torvalds wrote:
On Sat, 26 Feb 2005, Olaf Hering wrote:
quoted
modedb can not be __init because fb_find_mode() may get db == NULL.
fb_find_mode() is called from modules.
Ack. Maybe somebody should run the scripts again to check that we don't
reference __init data from non-init functions.
Linus
This patch has already been posted to linux-fbdev on 2005-02-10 by David Vrabel
and made me ask
Is there any reason why this has been originally flagged "__init"?
"vesa_modes" is not "__init". That's why I changed "intelfb" to
use "vesa_modes".
Maybe time has come to decide, if availability of "modedb" outside
of init functions is more important than freeing (unused) kernel memory.
--Axel
-------------------------------------------------------
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
--
Benjamin Herrenschmidt [off-list ref]
-------------------------------------------------------
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:19:44
This patch has already been posted to linux-fbdev on 2005-02-10 by David Vrabel
and made me ask
Is there any reason why this has been originally flagged "__init"?
"vesa_modes" is not "__init". That's why I changed "intelfb" to
use "vesa_modes".
Maybe time has come to decide, if availability of "modedb" outside
of init functions is more important than freeing (unused) kernel memory.
Well, I wonder why we need that mode db at all ... We should probably
use VESA modes and calculate using the standard formula if the user
requests a mode that isn't in the vesa table... Most monitors will
provide additional detailed timings for non-vesa modes they may
support.
Ben.
On Sat, 26 Feb 2005, Benjamin Herrenschmidt wrote:
On Sat, 2005-02-26 at 01:41 +0100, Olaf Hering wrote:
quoted
modedb can not be __init because fb_find_mode() may get db == NULL.
fb_find_mode() is called from modules.
Ahhh, good catch ! I though that was fixed long ago, looks like I was
wrong.
Yep, I was surprised by this bug as well...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
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: Antonino A. Daplas <hidden> Date: 2005-02-28 05:11:24
On Saturday 26 February 2005 09:13, Benjamin Herrenschmidt wrote:
On Sat, 2005-02-26 at 01:41 +0100, Olaf Hering wrote:
quoted
modedb can not be __init because fb_find_mode() may get db == NULL.
fb_find_mode() is called from modules.
Ahhh, good catch ! I though that was fixed long ago, looks like I was
wrong.
The 2.4 fix was for fb_find_mode to always return 640x480 if modular.
There's no fix yet for 2.6 except for the patch which is already in the mm
tree, which is for fb_find_mode() to always fail if driver is compiled as a
module. (patch below).
Both fixes will still crash if fb_find_mode() is called again, so this
function is really designed to be called only once.
As for the other patch that removes the __init from modedb, some of the
developers might disagree.
Olaf,
Can you send me your EDID block? You can use read-edid. Your monitor
may have a fixable EDID and can be a candidate for the broken display
database.
Tony