Re: 2.6.11-rc5

Re: 2.6.11-rc5

[Olaf Hering]

 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

Re: [Linux-fbdev-devel] Re: 2.6.11-rc5

[James Simmons]

> 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.

Re: Re: 2.6.11-rc5

[Olaf Hering]

 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.


-------------------------------------------------------
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

Re: [Linux-fbdev-devel] Re: 2.6.11-rc5

[Olaf Hering]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

 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.

[-- Attachment #2: config-radeonfb-i386.gz --]
[-- Type: application/x-gunzip, Size: 6532 bytes --]

Re: [Linux-fbdev-devel] Re: 2.6.11-rc5

[Olaf Hering]

 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.

Re: 2.6.11-rc5

[Olaf Hering]

 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 <olh@suse.de>

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,


-------------------------------------------------------
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

Re: 2.6.11-rc5

[Linus Torvalds]

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

Re: 2.6.11-rc5

[Olaf Hering]

 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.)

Re: 2.6.11-rc5

[Benjamin Herrenschmidt]

> > 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 <benh@kernel.crashing.org>

Re: Re: 2.6.11-rc5

[Benjamin Herrenschmidt]

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.




-------------------------------------------------------
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

Re: Re: 2.6.11-rc5

[Benjamin Herrenschmidt]

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.




-------------------------------------------------------
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

Re: Re: 2.6.11-rc5

[Benjamin Herrenschmidt]

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.




-------------------------------------------------------
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

Re: 2.6.11-rc5

[Linus Torvalds]

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


-------------------------------------------------------
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

Re: Re: 2.6.11-rc5

[Buttchereit, Axel (XL)]

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



  

  


-------------------------------------------------------
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

Re: 2.6.11-rc5

[Benjamin Herrenschmidt]

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 <eolh@suse.de>
> 
> 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 <benh@kernel.crashing.org>



-------------------------------------------------------
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

Re: [Linux-fbdev-devel] Re: 2.6.11-rc5

[Benjamin Herrenschmidt]

> 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.

Re: [Linux-fbdev-devel] Re: 2.6.11-rc5

[Antonino A. Daplas]

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

Re: Re: 2.6.11-rc5

[Giuseppe Bilotta]

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)

Re: 2.6.11-rc5

[Geert Uytterhoeven]

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 -- 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

Re: 2.6.11-rc5, rivafb i2c oops, bogus error handling

[Olaf Hering]

 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  


-------------------------------------------------------
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

Re: Re: 2.6.11-rc5, rivafb i2c oops, bogus error handling

[Antonino A. Daplas]

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 <adaplas@pol.net>
---

 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) {




-------------------------------------------------------
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

Re: [Linux-fbdev-devel] Re: 2.6.11-rc5, rivafb i2c oops, bogus error handling

[Olaf Hering]

 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.

Re: [Linux-fbdev-devel] Re: 2.6.11-rc5, rivafb i2c oops, bogus error handling

[Olaf Hering]

 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:

<linux-nvidia@lists.surfsouth.com>: 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.