From: Olaf H. <ol...@su...> - 2005-02-25 17:29:52
|
On Fri, Feb 25, Benjamin Herrenschmidt wrote: > On Fri, 2005-02-25 at 08:08 +0100, Olaf Hering wrote: > > On Fri, Feb 25, Benjamin Herrenschmidt wrote: > > > > > On Thu, 2005-02-24 at 15:50 +0100, Olaf Hering wrote: > > > > On Wed, Feb 23, Linus Torvalds wrote: > > > > > > > > > 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: Olaf H. <ol...@su...> - 2005-02-25 20:24:35
|
On Fri, Feb 25, James Simmons wrote: > > > 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. |
From: Benjamin H. <be...@ke...> - 2005-02-26 00:58:19
|
On Fri, 2005-02-25 at 21:24 +0100, Olaf Hering wrote: > On Fri, Feb 25, James Simmons wrote: > > > > > > 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. |
From: Olaf H. <ol...@su...> - 2005-02-25 21:22:09
Attachments:
config-radeonfb-i386.gz
|
On Fri, Feb 25, Olaf Hering wrote: > On Fri, Feb 25, James Simmons wrote: > > > > > > 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: Benjamin H. <be...@ke...> - 2005-02-26 00:59:33
|
On Fri, 2005-02-25 at 22:21 +0100, Olaf Hering wrote: > On Fri, Feb 25, Olaf Hering wrote: > > > On Fri, Feb 25, James Simmons wrote: > > > > > > > > > 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. |
From: Olaf H. <ol...@su...> - 2005-02-25 23:30:55
|
On Fri, Feb 25, Olaf Hering wrote: > On Fri, Feb 25, Olaf Hering wrote: > > > On Fri, Feb 25, James Simmons wrote: > > > > > > > > > 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 H. <be...@ke...> - 2005-02-26 01:02:07
|
On Sat, 2005-02-26 at 00:30 +0100, Olaf Hering wrote: > On Fri, Feb 25, Olaf Hering wrote: > > > On Fri, Feb 25, Olaf Hering wrote: > > > > > On Fri, Feb 25, James Simmons wrote: > > > > > > > > > > > > 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. |
From: Olaf H. <ol...@su...> - 2005-02-26 00:41:45
|
On Thu, Feb 24, Olaf Hering wrote: > On Wed, Feb 23, Linus Torvalds wrote: > > > 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 <ol...@su...> diff -purNx tags linux-2.6.11-rc5.orig/drivers/video/modedb.c linux-2.6.11-rc5/drivers/video/modedb.c --- linux-2.6.11-rc5.orig/drivers/video/modedb.c 2005-02-24 17:40:24.000000000 +0100 +++ linux-2.6.11-rc5/drivers/video/modedb.c 2005-02-26 01:37:43.138003474 +0100 @@ -37,7 +37,7 @@ const char *global_mode_option; #define DEFAULT_MODEDB_INDEX 0 -static const __init struct fb_videomode modedb[] = { +static const struct fb_videomode modedb[] = { { /* 640x400 @ 70 Hz, 31.5 kHz hsync */ NULL, 70, 640, 400, 39721, 40, 24, 39, 9, 96, 2, |
From: Linus T. <tor...@os...> - 2005-02-26 00:48:28
|
On Sat, 26 Feb 2005, Olaf Hering wrote: > > 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 |
From: Benjamin H. <be...@ke...> - 2005-02-26 01:14:17
|
On Sat, 2005-02-26 at 01:41 +0100, Olaf Hering wrote: > > 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. Ben. > Signed-off-by: Olaf Hering <eo...@su...> > > diff -purNx tags linux-2.6.11-rc5.orig/drivers/video/modedb.c linux-2.6.11-rc5/drivers/video/modedb.c > --- linux-2.6.11-rc5.orig/drivers/video/modedb.c 2005-02-24 17:40:24.000000000 +0100 > +++ linux-2.6.11-rc5/drivers/video/modedb.c 2005-02-26 01:37:43.138003474 +0100 > @@ -37,7 +37,7 @@ const char *global_mode_option; > > #define DEFAULT_MODEDB_INDEX 0 > > -static const __init struct fb_videomode modedb[] = { > +static const struct fb_videomode modedb[] = { > { > /* 640x400 @ 70 Hz, 31.5 kHz hsync */ > NULL, 70, 640, 400, 39721, 40, 24, 39, 9, 96, 2, -- Benjamin Herrenschmidt <be...@ke...> |
From: Geert U. <ge...@li...> - 2005-02-27 08:07:51
|
On Sat, 26 Feb 2005, Benjamin Herrenschmidt wrote: > On Sat, 2005-02-26 at 01:41 +0100, Olaf Hering wrote: > > 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 -- ge...@li... 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 |
From: Antonino A. D. <ad...@ho...> - 2005-02-28 05:11:28
|
On Saturday 26 February 2005 09:13, Benjamin Herrenschmidt wrote: > On Sat, 2005-02-26 at 01:41 +0100, Olaf Hering wrote: > > 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 |
From: Olaf H. <ol...@su...> - 2005-02-26 00:53:44
|
On Fri, Feb 25, Linus Torvalds wrote: > > > On Sat, 26 Feb 2005, Olaf Hering wrote: > > > > 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. sparse doesnt do that, yet? (I never looked at it.) |
From: Linus T. <tor...@os...> - 2005-02-26 01:03:23
|
On Sat, 26 Feb 2005, Olaf Hering wrote: > > 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 |
From: Buttchereit, A. (XL) <XL@XLsigned.net> - 2005-02-26 01:08:18
|
Linus Torvalds wrote: > > On Sat, 26 Feb 2005, Olaf Hering wrote: > >>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 |
From: Benjamin H. <be...@ke...> - 2005-02-26 01:18: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. |
From: Olaf H. <ol...@su...> - 2005-02-27 20:32:24
|
On Wed, Feb 23, Linus Torvalds wrote: > 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. Here is another one, probably not new. Is riva_get_EDID_i2c a bit too optimistic by not having a $i2cadapter_ok member in riva_par->riva_i2c_chan? It calls riva_probe_i2c_connector even if riva_create_i2c_busses fails to register all 3 busses. Feb 27 00:32:51 vdr kernel: ACPI-0367: *** Warning: Unable to derive IRQ for device 0000:01:00.0 Feb 27 00:32:51 vdr kernel: ACPI: PCI interrupt 0000:01:00.0[A]: no GSI - using IRQ 11 Feb 27 00:32:51 vdr kernel: rivafb: nVidia device/chipset 10DE0029 Feb 27 00:32:51 vdr kernel: rivafb: RIVA MTRR set to ON Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: (0) scl=60, sda=1 Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: (1) scl=53, sda=0 Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: (2) scl=63, sda=1 Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: (3) scl=59, sda=1 Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: SCL stuck high! Feb 27 00:32:51 vdr kernel: rivafb 0000:01:00.0: Failed to register I2C bus BUS1. Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: (0) scl=30, sda=1 Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: (1) scl=23, sda=0 Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: (2) scl=31, sda=1 Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: (3) scl=59, sda=1 Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: SCL stuck high! Feb 27 00:32:51 vdr kernel: rivafb 0000:01:00.0: Failed to register I2C bus BUS2. Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: (0) scl=0, sda=0 Feb 27 00:32:51 vdr kernel: i2c-algo-bit.o: BUS3 seems to be busy. Feb 27 00:32:51 vdr kernel: rivafb 0000:01:00.0: Failed to register I2C bus BUS3. Feb 27 00:32:51 vdr kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000024 Feb 27 00:32:51 vdr kernel: printing eip: Feb 27 00:32:51 vdr kernel: d09bcafc Feb 27 00:32:51 vdr kernel: *pde = 00000000 Feb 27 00:32:51 vdr kernel: Oops: 0000 [#1] Feb 27 00:32:51 vdr kernel: Modules linked in: usbhid evdev joydev sg st sd_mod sr_mod scsi_mod rivafb i2c_algo_bit vgastate dvb_ttpci dvb_core saa7146_vv video_buf saa7146 v4l1_compat v4l2_common v ideodev ves1820 stv0299 tda8083 stv0297 8139too mii sp8870 firmware_class ves1x93 i2c_piix4 ttpci_eeprom i2c_core intel_agp uhci_hcd pci_hotplug agpgart usbcore subfs dm_mod ide_cd cdrom ide_floppy ide_disk reiserfs piix ide_core Feb 27 00:32:51 vdr kernel: CPU: 0 Feb 27 00:32:51 vdr kernel: EIP: 0060:[<d09bcafc>] Not tainted VLI Feb 27 00:32:51 vdr kernel: EFLAGS: 00010286 (2.6.11-rc4-bk9-27-default) Feb 27 00:32:51 vdr kernel: EIP is at i2c_transfer+0xc/0x40 [i2c_core] Feb 27 00:32:51 vdr kernel: eax: 00000000 ebx: ffffffda ecx: 00000002 edx: cd6f3e18 Feb 27 00:32:51 vdr kernel: esi: cfa35624 edi: cfe40160 ebp: 00000003 esp: cd6f3e04 Feb 27 00:32:51 vdr kernel: ds: 007b es: 007b ss: 0068 Feb 27 00:32:51 vdr kernel: Process modprobe (pid: 2613, threadinfo=cd6f2000 task=cddfd080) Feb 27 00:32:51 vdr kernel: Stack: cd6f3e18 cfa3561c d0a1ce3f 00000246 003b5219 00000050 00000001 cd6f3e17 Feb 27 00:32:51 vdr kernel: 00010050 00000080 cfe40160 d0a1de98 cd6f3e40 00000000 000001e4 cfa35290 Feb 27 00:32:51 vdr kernel: cfa355f4 d0a1cec7 cfa35290 00000001 00000000 cfa355f4 d0a17de8 00000001 Feb 27 00:32:51 vdr kernel: Call Trace: Feb 27 00:32:51 vdr kernel: [<d0a1ce3f>] riva_do_probe_i2c_edid+0x7f/0xe0 [rivafb] Feb 27 00:32:51 vdr kernel: [<d0a1cec7>] riva_probe_i2c_connector+0x27/0xa0 [rivafb] Feb 27 00:32:51 vdr kernel: [<d0a17de8>] riva_get_EDID_i2c+0x48/0x90 [rivafb] Feb 27 00:32:51 vdr kernel: [<c010528d>] do_IRQ+0x3d/0x60 Feb 27 00:32:51 vdr kernel: [<c0103cba>] common_interrupt+0x1a/0x20 Feb 27 00:32:51 vdr kernel: [<c0228288>] poke_blanked_console+0x68/0xb0 Feb 27 00:32:51 vdr kernel: [<c02274c5>] vt_console_print+0x295/0x340 Feb 27 00:32:51 vdr kernel: [<c0227230>] vt_console_print+0x0/0x340 Feb 27 00:32:51 vdr kernel: [<c0119f51>] __call_console_drivers+0x41/0x50 Feb 27 00:32:51 vdr kernel: [<c011a028>] call_console_drivers+0x78/0x110 Feb 27 00:32:51 vdr kernel: [<c011a29b>] vprintk+0xeb/0x100 Feb 27 00:32:51 vdr kernel: [<d0a17ec5>] riva_get_EDID+0x5/0x20 [rivafb] Feb 27 00:32:51 vdr kernel: [<d0a182eb>] rivafb_probe+0x2db/0x510 [rivafb] Feb 27 00:32:51 vdr kernel: [<c01dab82>] pci_device_probe_static+0x32/0x50 Feb 27 00:32:51 vdr kernel: [<c01dabc7>] __pci_device_probe+0x27/0x40 Feb 27 00:32:51 vdr kernel: [<c01dabfb>] pci_device_probe+0x1b/0x40 Feb 27 00:32:51 vdr kernel: [<c0234531>] driver_probe_device+0x21/0x60 Feb 27 00:32:51 vdr kernel: [<c023465d>] driver_attach+0x4d/0x80 Feb 27 00:32:51 vdr kernel: [<c0234a4d>] bus_add_driver+0x6d/0xa0 Feb 27 00:32:51 vdr kernel: [<c0234f48>] driver_register+0x28/0x30 Feb 27 00:32:51 vdr kernel: [<c01dadc4>] pci_register_driver+0x54/0x70 Feb 27 00:32:51 vdr kernel: [<c012e774>] sys_init_module+0x104/0x180 Feb 27 00:32:51 vdr kernel: [<c0102c49>] sysenter_past_esp+0x52/0x79 Feb 27 00:32:51 vdr kernel: Code: 31 db 8b 50 70 85 d2 74 07 8b 4a 68 85 c9 75 04 89 d8 5b c3 31 d2 ff d1 89 c3 89 d8 5b c3 90 56 53 89 c6 8b 40 0c bb da ff ff ff <8b> 40 24 85 c0 74 1e ff 4e 1c 0f 88 59 13 00 00 8b 5e 0c 89 f0 |
From: Antonino A. D. <ad...@ho...> - 2005-02-28 14:42:20
|
On Monday 28 February 2005 04:32, Olaf Hering wrote: > On Wed, Feb 23, Linus Torvalds wrote: > > 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. > > Here is another one, probably not new. > Is riva_get_EDID_i2c a bit too optimistic by not having a $i2cadapter_ok > member in riva_par->riva_i2c_chan? It calls riva_probe_i2c_connector > even if riva_create_i2c_busses fails to register all 3 busses. > Thanks, Can you try this? Fixed error handling in rivafb-i2c.c if bus registration fails. Signed-off-by: Antonino Daplas <ad...@po...> --- rivafb-i2c.c | 11 +++++++++-- 1 files changed, 9 insertions(+), 2 deletions(-) diff -Nru a/drivers/video/riva/rivafb-i2c.c b/drivers/video/riva/rivafb-i2c.c --- a/drivers/video/riva/rivafb-i2c.c 2005-01-13 03:57:12 +08:00 +++ b/drivers/video/riva/rivafb-i2c.c 2005-02-28 08:22:06 +08:00 @@ -120,8 +120,12 @@ rc = i2c_bit_add_bus(&chan->adapter); if (rc == 0) dev_dbg(&chan->par->pdev->dev, "I2C bus %s registered.\n", name); - else - dev_warn(&chan->par->pdev->dev, "Failed to register I2C bus %s.\n", name); + else { + dev_warn(&chan->par->pdev->dev, + "Failed to register I2C bus %s.\n", name); + chan->par = NULL; + } + return rc; } @@ -171,6 +175,9 @@ }, }; u8 *buf; + + if (!chan->par) + return NULL; buf = kmalloc(EDID_LENGTH, GFP_KERNEL); if (!buf) { |
From: Olaf H. <ol...@su...> - 2005-03-01 12:02:35
|
On Mon, Feb 28, Antonino A. Daplas wrote: > On Monday 28 February 2005 04:32, Olaf Hering wrote: > > On Wed, Feb 23, Linus Torvalds wrote: > > > 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. > > > > Here is another one, probably not new. > > Is riva_get_EDID_i2c a bit too optimistic by not having a $i2cadapter_ok > > member in riva_par->riva_i2c_chan? It calls riva_probe_i2c_connector > > even if riva_create_i2c_busses fails to register all 3 busses. > > > > Thanks, > > Can you try this? > > Fixed error handling in rivafb-i2c.c if bus registration fails. I havent heard back from the reporter, yet. |
From: Olaf H. <ol...@su...> - 2005-03-01 20:59:09
|
On Mon, Feb 28, Antonino A. Daplas wrote: > On Monday 28 February 2005 04:32, Olaf Hering wrote: > > On Wed, Feb 23, Linus Torvalds wrote: > > > 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. > > > > Here is another one, probably not new. > > Is riva_get_EDID_i2c a bit too optimistic by not having a $i2cadapter_ok > > member in riva_par->riva_i2c_chan? It calls riva_probe_i2c_connector > > even if riva_create_i2c_busses fails to register all 3 busses. Side note: <lin...@li...>: connect to lists.surfsouth.com[216.128.200.12]: Connection timed out Is this one supposed to work? perhaps the MAINTAINERS entry needs an update. |
From: James S. <jsi...@ww...> - 2005-02-25 17:59:14
|
> 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. |
From: Benjamin H. <be...@ke...> - 2005-02-26 00:55:13
|
> > 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 > -- Benjamin Herrenschmidt <be...@ke...> |