request_mem_region problem ...

request_mem_region problem ...

[Sven Luther]

Hello, ...

I have begun porting pm3fb to the new api, well, more exactly i am
adapting tdfxfb to handle pm3 chips, and will port parts of pm3fb to it
as i need them.

I have a problem when loading pm3fb as a module, and that is that
request_mem_region fails. I know that pm3_fix.mmio_start and
pm3_fix.mmio_len are correct, but request_mem_region still fails.

I am still searching the definition of request_mem_region in the source,
but any help would be most welcome.

Note, this is with stock 2.5.44.

Also, if i register the framebuffer, without defining any of the
fillrect, copyarea and imageblit functions (even the generic ones) i
suppose it is normal i only get a black screen, isn't it ?

Friendly,

Sven Luther


-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en

Re: request_mem_region problem ...

[Antonino Daplas]

On Wed, 2002-10-30 at 21:00, Sven Luther wrote:
> Hello, ...
> 
> I have begun porting pm3fb to the new api, well, more exactly i am
> adapting tdfxfb to handle pm3 chips, and will port parts of pm3fb to it
> as i need them.
> 
> I have a problem when loading pm3fb as a module, and that is that
> request_mem_region fails. I know that pm3_fix.mmio_start and
> pm3_fix.mmio_len are correct, but request_mem_region still fails.
> 
> I am still searching the definition of request_mem_region in the source,
> but any help would be most welcome.
> 
> Note, this is with stock 2.5.44.
> 
Try doing a pci_enable_device() before request_mem_region, maybe that
will help.

> Also, if i register the framebuffer, without defining any of the
> fillrect, copyarea and imageblit functions (even the generic ones) i
> suppose it is normal i only get a black screen, isn't it ?
> 
Yes.

Tony




-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en

Re: request_mem_region problem ...

[Sven Luther]

On Thu, Oct 31, 2002 at 08:34:05AM +0800, Antonino Daplas wrote:
> On Wed, 2002-10-30 at 21:00, Sven Luther wrote:
> > Hello, ...
> > 
> > I have begun porting pm3fb to the new api, well, more exactly i am
> > adapting tdfxfb to handle pm3 chips, and will port parts of pm3fb to it
> > as i need them.
> > 
> > I have a problem when loading pm3fb as a module, and that is that
> > request_mem_region fails. I know that pm3_fix.mmio_start and
> > pm3_fix.mmio_len are correct, but request_mem_region still fails.
> > 
> > I am still searching the definition of request_mem_region in the source,
> > but any help would be most welcome.
> > 
> > Note, this is with stock 2.5.44.
> > 
> Try doing a pci_enable_device() before request_mem_region, maybe that
> will help.

I already solutioned this problem.

BTW, i don't understand how the tdfxfb does not have this problem, as it
is from there that i tried to sole this.

The problem was that i did :

        /* Find the mmio register area */
	pm3_fix.mmio_start = pci_resource_start(pdev, 0);
	pm3_fix.mmio_len = pci_resource_len(pdev, 0);

And later :

	if (!request_mem_region(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0), ...

Changing this to :

	if (!request_mem_region(pm3_fix.mmio_start, pm3_fix.mmio_len, ...

Solved the problem, so it seems that the pci_resource_ functions can be
called only one time. Is this true ?

Now, i seem to have everything fine, but it still hangs in
register_framebuffer, a bit of searching has it that it is when
register_framebuffer calls take_over_console. I didn't have time for
looking into it more yesterday.

Still the screen is black, and i see a small (underscore) blinking
cursor at the bottom left of the screen. The machine was dead though :

Oct 30 23:15:53 iliana kernel:  printing eip:
Oct 30 23:15:53 iliana kernel: c023affc
Oct 30 23:15:53 iliana kernel: Oops: 0000
Oct 30 23:15:53 iliana kernel: pm3fb nls_iso8859-15 nls_cp437 sym53c8xx
Oct 30 23:15:53 iliana kernel: CPU:    0
Oct 30 23:15:53 iliana kernel: EIP:    0060:[fbcon_cursor+108/480] Not tainted
Oct 30 23:15:53 iliana kernel: EFLAGS: 00010246
Oct 30 23:15:53 iliana kernel: eax: 00000000   ebx: 00000000   ecx: 00000000   edx: c1143240
Oct 30 23:15:53 iliana kernel: esi: c042d280   edi: 00000002   ebp: 00000018   esp: c4dcbc10
Oct 30 23:15:53 iliana kernel: ds: 0068   es: 0068   ss: 0068
Oct 30 23:15:53 iliana kernel: Process modprobe (pid: 495, threadinfo=c4dca000 task=c6bec040)
Oct 30 23:15:53 iliana kernel: Stack: 00000000 c04156c0 00000000 00000000 c01f21f8 c1143240 00000002 00000000
Oct 30 23:15:53 iliana kernel:        c04156c0 c01f5435 00000000 c039ef20 c03dfe9f 0000339f 000033cf c0414a30
Oct 30 23:15:53 iliana kernel:        00002adf c01275e1 00000000 c0119439 c039ef20 c03dfe9f 00000030 000033cf

How, well, maybe i should wait for the new patches from James to be
accepted into the linus tree.

Notice, maybe this is due to me not having defined yet any of the
check_var, set_par, blank, ... functions, but my idea, for the howto
afterward, was to write first the most minimal working fbdev.

BTW, should i work on james BK tree directly ? Is there an howto on how
to do that ? Or could it be possible to get a patch against 2.5.44 ?

> > Also, if i register the framebuffer, without defining any of the
> > fillrect, copyarea and imageblit functions (even the generic ones) i
> > suppose it is normal i only get a black screen, isn't it ?
> > 
> Yes.

Ok, as i thought, still :

when i try to use the cfb_xxx functions, it does not work. i copied the
neofb line in the Makefile so that pm3fb should have added the 3 cfbxxx
objects, but it does not work. When loading the cfbxxx.o object files as
modules, insmod complains about lack of version in them, so i guess they
are not modules. Still, they don't get linked with the pm3fb.o (and
neither with the neofb.o when i tried it), and when loading pm3fb.o, i
get a message about missing symbols cfb_xxx.

So, does the cfb_xxx generic accel stuff get linked correctly when
building as modules or am i missing something ?

Anyway, thanks for your help.

Friendly,

Sven Luther


-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en

Re: request_mem_region problem ...

[Antonino Daplas]

On Thu, 2002-10-31 at 16:10, Sven Luther wrote:
> On Thu, Oct 31, 2002 at 08:34:05AM +0800, Antonino Daplas wrote:
[...]
> 
> I already solutioned this problem.
> 
> BTW, i don't understand how the tdfxfb does not have this problem, as it
> is from there that i tried to sole this.
> 
> The problem was that i did :
> 
>         /* Find the mmio register area */
> 	pm3_fix.mmio_start = pci_resource_start(pdev, 0);
> 	pm3_fix.mmio_len = pci_resource_len(pdev, 0);
> 
> And later :
> 
> 	if (!request_mem_region(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0), ...
> 
> Changing this to :
> 
> 	if (!request_mem_region(pm3_fix.mmio_start, pm3_fix.mmio_len, ...
> 
> Solved the problem, so it seems that the pci_resource_ functions can be
> called only one time. Is this true ?
> 
Strange.  pci_resource_* are just macros, so they should be usable as
long as the pci_dev pointer is valid.

> Now, i seem to have everything fine, but it still hangs in
> register_framebuffer, a bit of searching has it that it is when
> register_framebuffer calls take_over_console. I didn't have time for
> looking into it more yesterday.
> 
> Still the screen is black, and i see a small (underscore) blinking
> cursor at the bottom left of the screen. The machine was dead though :
> 
> Oct 30 23:15:53 iliana kernel:  printing eip:
> Oct 30 23:15:53 iliana kernel: c023affc
> Oct 30 23:15:53 iliana kernel: Oops: 0000
> Oct 30 23:15:53 iliana kernel: pm3fb nls_iso8859-15 nls_cp437 sym53c8xx
> Oct 30 23:15:53 iliana kernel: CPU:    0
> Oct 30 23:15:53 iliana kernel: EIP:    0060:[fbcon_cursor+108/480] Not tainted
> Oct 30 23:15:53 iliana kernel: EFLAGS: 00010246
> Oct 30 23:15:53 iliana kernel: eax: 00000000   ebx: 00000000   ecx: 00000000   edx: c1143240
> Oct 30 23:15:53 iliana kernel: esi: c042d280   edi: 00000002   ebp: 00000018   esp: c4dcbc10
> Oct 30 23:15:53 iliana kernel: ds: 0068   es: 0068   ss: 0068
> Oct 30 23:15:53 iliana kernel: Process modprobe (pid: 495, threadinfo=c4dca000 task=c6bec040)
> Oct 30 23:15:53 iliana kernel: Stack: 00000000 c04156c0 00000000 00000000 c01f21f8 c1143240 00000002 00000000
> Oct 30 23:15:53 iliana kernel:        c04156c0 c01f5435 00000000 c039ef20 c03dfe9f 0000339f 000033cf c0414a30
> Oct 30 23:15:53 iliana kernel:        00002adf c01275e1 00000000 c0119439 c039ef20 c03dfe9f 00000030 000033cf
> 
Running ksymoops on that might help.  The source can be found at
ftp.kernel.org.  

If you define FBCON_HAS_ACCEL, then fb_imageblit, fb_copyarea and
fb_fillrect in info->fbops must not be null.  Otherwise, you'll always
get an oops. If you don't define FBCON_HAS_ACCEL, you'll end up with
fbcon_dummy, which is totally safe but will not show anything at all. 
This is all assuming you use gen_set_var.  

If you did not define fb_set_var at all, then info->disp.dispsw must
point to valid console drawing hooks before you register the
framebuffer.  (Actually, all fields in struct display must be valid
before you register the framebuffer)

Your oops tracing points to fbcon_cursor as the culprit.  If
dispsw->cursor is NULL, then you must have a valid dispsw->revc.
  
> How, well, maybe i should wait for the new patches from James to be
> accepted into the linus tree.
> 
> Notice, maybe this is due to me not having defined yet any of the
> check_var, set_par, blank, ... functions, but my idea, for the howto
> afterward, was to write first the most minimal working fbdev.
> 
> BTW, should i work on james BK tree directly ? Is there an howto on how
> to do that ? Or could it be possible to get a patch against 2.5.44 ?
> 
Try Documentation/BK-usage.  You will need a very fat pipe, then for a
start, 

bk clone bk://fbdev.bkbits.net/fbdev-2.5

> 
> when i try to use the cfb_xxx functions, it does not work. i copied the
> neofb line in the Makefile so that pm3fb should have added the 3 cfbxxx
> objects, but it does not work. When loading the cfbxxx.o object files as
> modules, insmod complains about lack of version in them, so i guess they
> are not modules. Still, they don't get linked with the pm3fb.o (and
> neither with the neofb.o when i tried it), and when loading pm3fb.o, i
> get a message about missing symbols cfb_xxx.
> 
> So, does the cfb_xxx generic accel stuff get linked correctly when
> building as modules or am i missing something ?
> 
You're correct, the neofb line in the Makefile is for static building
only.  The cfb_xxx will not compile as modules, yet.  If your driver has
its own Makefile, just add cfb_xxx.o objects to directly link to them.

Tony



-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en

Re: request_mem_region problem ...

[Sven Luther]

On Thu, Oct 31, 2002 at 07:05:13PM +0800, Antonino Daplas wrote:
> On Thu, 2002-10-31 at 16:10, Sven Luther wrote:
> > On Thu, Oct 31, 2002 at 08:34:05AM +0800, Antonino Daplas wrote:
> [...]
> > 
> > I already solutioned this problem.
> > 
> > BTW, i don't understand how the tdfxfb does not have this problem, as it
> > is from there that i tried to sole this.
> > 
> > The problem was that i did :
> > 
> >         /* Find the mmio register area */
> > 	pm3_fix.mmio_start = pci_resource_start(pdev, 0);
> > 	pm3_fix.mmio_len = pci_resource_len(pdev, 0);
> > 
> > And later :
> > 
> > 	if (!request_mem_region(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0), ...
> > 
> > Changing this to :
> > 
> > 	if (!request_mem_region(pm3_fix.mmio_start, pm3_fix.mmio_len, ...
> > 
> > Solved the problem, so it seems that the pci_resource_ functions can be
> > called only one time. Is this true ?
> > 
> Strange.  pci_resource_* are just macros, so they should be usable as
> long as the pci_dev pointer is valid.

Yes, thought so also, but then i may have been another problem, will
look into this more tomorrow.

> > Now, i seem to have everything fine, but it still hangs in
> > register_framebuffer, a bit of searching has it that it is when
> > register_framebuffer calls take_over_console. I didn't have time for
> > looking into it more yesterday.
> > 
> > Still the screen is black, and i see a small (underscore) blinking
> > cursor at the bottom left of the screen. The machine was dead though :
> > 
> > Oct 30 23:15:53 iliana kernel:  printing eip:
> > Oct 30 23:15:53 iliana kernel: c023affc
> > Oct 30 23:15:53 iliana kernel: Oops: 0000
> > Oct 30 23:15:53 iliana kernel: pm3fb nls_iso8859-15 nls_cp437 sym53c8xx
> > Oct 30 23:15:53 iliana kernel: CPU:    0
> > Oct 30 23:15:53 iliana kernel: EIP:    0060:[fbcon_cursor+108/480] Not tainted
> > Oct 30 23:15:53 iliana kernel: EFLAGS: 00010246
> > Oct 30 23:15:53 iliana kernel: eax: 00000000   ebx: 00000000   ecx: 00000000   edx: c1143240
> > Oct 30 23:15:53 iliana kernel: esi: c042d280   edi: 00000002   ebp: 00000018   esp: c4dcbc10
> > Oct 30 23:15:53 iliana kernel: ds: 0068   es: 0068   ss: 0068
> > Oct 30 23:15:53 iliana kernel: Process modprobe (pid: 495, threadinfo=c4dca000 task=c6bec040)
> > Oct 30 23:15:53 iliana kernel: Stack: 00000000 c04156c0 00000000 00000000 c01f21f8 c1143240 00000002 00000000
> > Oct 30 23:15:53 iliana kernel:        c04156c0 c01f5435 00000000 c039ef20 c03dfe9f 0000339f 000033cf c0414a30
> > Oct 30 23:15:53 iliana kernel:        00002adf c01275e1 00000000 c0119439 c039ef20 c03dfe9f 00000030 000033cf
> > 
> Running ksymoops on that might help.  The source can be found at
> ftp.kernel.org.  

Yes, ... (altoug i do old style debuging (with printk) takes more time,
but work also.

> If you define FBCON_HAS_ACCEL, then fb_imageblit, fb_copyarea and
> fb_fillrect in info->fbops must not be null.  Otherwise, you'll always
> get an oops. If you don't define FBCON_HAS_ACCEL, you'll end up with
> fbcon_dummy, which is totally safe but will not show anything at all. 

Mmm, ok, 

> This is all assuming you use gen_set_var.  

Yes, i use this one.

> If you did not define fb_set_var at all, then info->disp.dispsw must
> point to valid console drawing hooks before you register the
> framebuffer.  (Actually, all fields in struct display must be valid
> before you register the framebuffer)
> 
> Your oops tracing points to fbcon_cursor as the culprit.  If
> dispsw->cursor is NULL, then you must have a valid dispsw->revc.

Ok, but will look more at it, tomorrow.

> > How, well, maybe i should wait for the new patches from James to be
> > accepted into the linus tree.
> > 
> > Notice, maybe this is due to me not having defined yet any of the
> > check_var, set_par, blank, ... functions, but my idea, for the howto
> > afterward, was to write first the most minimal working fbdev.
> > 
> > BTW, should i work on james BK tree directly ? Is there an howto on how
> > to do that ? Or could it be possible to get a patch against 2.5.44 ?
> > 
> Try Documentation/BK-usage.  You will need a very fat pipe, then for a
> start, 
> 
> bk clone bk://fbdev.bkbits.net/fbdev-2.5

Ok, ...

i have ADSL 512K, i suppose it will have to be enough, anyway, the other
solution would be to just be patient, isn't it ?

> > when i try to use the cfb_xxx functions, it does not work. i copied the
> > neofb line in the Makefile so that pm3fb should have added the 3 cfbxxx
> > objects, but it does not work. When loading the cfbxxx.o object files as
> > modules, insmod complains about lack of version in them, so i guess they
> > are not modules. Still, they don't get linked with the pm3fb.o (and
> > neither with the neofb.o when i tried it), and when loading pm3fb.o, i
> > get a message about missing symbols cfb_xxx.
> > 
> > So, does the cfb_xxx generic accel stuff get linked correctly when
> > building as modules or am i missing something ?
> > 
> You're correct, the neofb line in the Makefile is for static building
> only.  The cfb_xxx will not compile as modules, yet.  If your driver has
> its own Makefile, just add cfb_xxx.o objects to directly link to them.

It is just one file, i think i will just copy the cfb_xxx functions into
my file for now, it should work as well, anyway, i plan to add my own
accel functions later on.

Friendly,

Sven Luther


-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en

Re: request_mem_region problem ...

[Sven Luther]

On Thu, Oct 31, 2002 at 07:05:13PM +0800, Antonino Daplas wrote:
> Running ksymoops on that might help.  The source can be found at
> ftp.kernel.org.  

Ok, got it from the debian package :)))

Erm, i am no more running the same kernel, so i specified the -o and the
-m options, but it looks at the wrong /proc/ksyms, should i save the
/proc/ksyms of kernel before/after insmodding the pm3fb module ?

> If you define FBCON_HAS_ACCEL, then fb_imageblit, fb_copyarea and
> fb_fillrect in info->fbops must not be null.  Otherwise, you'll always
> get an oops. If you don't define FBCON_HAS_ACCEL, you'll end up with
> fbcon_dummy, which is totally safe but will not show anything at all. 
> This is all assuming you use gen_set_var.  

Ok, i did copy the cfb_ functions to the driver, it works better (the
box does not hang anymore), the console apprently works (the cursor
blinks in the right place, and it could type stuff, switch VT and
shutdown the box) but there is nothing else written.

BTW, what is the difference between the full cursor and the underline
one ?

Anyway, here are the two Oops :


Nov  1 11:16:10 iliana kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000024
Nov  1 11:16:10 iliana kernel:  printing eip:
Nov  1 11:16:10 iliana kernel: c023a5a5
Nov  1 11:16:10 iliana kernel: *pde = 00000000
Nov  1 11:16:10 iliana kernel: Oops: 0000
Nov  1 11:16:10 iliana kernel: pm3fb nls_iso8859-15 nls_cp437 sym53c8xx  
Nov  1 11:16:10 iliana kernel: CPU:    0
Nov  1 11:16:10 iliana kernel: EIP:    0060:[fbcon_setup+677/2368]    Not tainted
Nov  1 11:16:10 iliana kernel: EFLAGS: 00010212
Nov  1 11:16:10 iliana kernel: eax: 00000080   ebx: 00000008   ecx: 00000007   edx: 00000000
Nov  1 11:16:10 iliana kernel: esi: 0000003f   edi: c042d37c   ebp: c1143240   esp: c3cfbdbc
Nov  1 11:16:10 iliana kernel: ds: 0068   es: 0068   ss: 0068
Nov  1 11:16:10 iliana kernel: Process modprobe (pid: 561, threadinfo=c3cfa000 task=c5aeacc0)
Nov  1 11:16:10 iliana kernel: Stack: c7941000 c7941294 c042d37c c1143240 00003389 000033af 00000004 00003386 
Nov  1 11:16:10 iliana kernel:        c00beea0 00000001 00000100 00000000 c03dfeaf 00000000 c1143240 c7941000 
Nov  1 11:16:10 iliana kernel:        c042d280 c023a1f7 00000000 00000000 00000000 00000000 00000000 c04156c0 
Nov  1 11:16:10 iliana kernel: Call Trace: [fbcon_init+151/192]  [visual_init+138/224]  [take_over_console+170/400]  [register_framebuffer+353/432]  [<c887b6f1>]  [<c887b123>]  [<c887b9e8>]  [pci_device_probe+65/96]  [<c887b980>]  [<c887b9e8>]  [<c887b9e8>]  [<c887b9c0>]  [bus_match+52/96]  [driver_attach+64/128]  [<c887b9e8>]  [<c887b9e8>]  [bus_add_driver+87/128]  [<c887b9e8>]  [<c887b9e8>]  [<c887a066>]  [driver_register+50/80]  [<c887b9e8>]  [pci_register_driver+54/80]  [<c887b9e8>]  [<c887b287>]  [<c887b9c0>]  [sys_init_module+1309/1536]  [<c887a060>]  [syscall_call+7/11] 
Nov  1 11:16:10 iliana kernel: Code: 85 42 24 75 1c 53 68 00 41 33 c0 e8 4b f0 ed ff 8b 74 24 48 

And :

Nov  1 11:16:30 iliana kernel:  <1>Unable to handle kernel NULL pointer dereference<1>Unable to handle kernel NULL pointer dereference at virtual address 00000018
Nov  1 11:16:30 iliana kernel:  printing eip:
Nov  1 11:16:30 iliana kernel: c023b00c
Nov  1 11:16:30 iliana kernel: *pde = 00000000
Nov  1 11:16:30 iliana kernel: Oops: 0000
Nov  1 11:16:30 iliana kernel: pm3fb nls_iso8859-15 nls_cp437 sym53c8xx  
Nov  1 11:16:30 iliana kernel: CPU:    0
Nov  1 11:16:30 iliana kernel: EIP:    0060:[fbcon_cursor+108/480]    Not tainted
Nov  1 11:16:30 iliana kernel: EFLAGS: 00010246
Nov  1 11:16:30 iliana kernel: eax: 00000000   ebx: 00000000   ecx: 00000000   edx: c1143240
Nov  1 11:16:30 iliana kernel: esi: c042d280   edi: 00000002   ebp: 00000018   esp: c7fb1d78
Nov  1 11:16:30 iliana kernel: ds: 0068   es: 0068   ss: 0068
Nov  1 11:16:30 iliana kernel: Process events/0 (pid: 3, threadinfo=c7fb0000 task=c7fbccc0)
Nov  1 11:16:30 iliana kernel: Stack: 00000000 c04156c0 00000000 0000000e c01f21f8 c1143240 00000002 00000000 
Nov  1 11:16:30 iliana kernel:        c04156c0 c01f5435 00000000 c039efa0 c03e0387 00003887 000038ba c795e040 
Nov  1 11:16:30 iliana kernel:        00000000 c5a69e5c 00000000 c0119439 c039efa0 c03e0387 00000033 000038ba 
Nov  1 11:16:30 iliana kernel: Call Trace: [hide_cursor+120/128]  [vt_console_print+165/736]  [__call_console_drivers+57/80]  [_call_console_drivers+87/96]  [call_console_drivers+217/224]  [release_console_sem+77/192]  [printk+303/352]  [do_page_fault+618/1076]  [do_page_fault+0/1076]  [run_timer_tasklet+231/304]  [delayed_work_timer_fn+0/96]  [tasklet_hi_action+61/112]  [do_softirq+90/176]  [do_IRQ+240/272]  [apic_timer_interrupt+26/32]  [error_code+45/56]  [fbcon_switch+335/448]  [redraw_screen+224/336]  [complete_change_console+43/192]  [change_console+137/144]  [console_callback+58/176]  [worker_thread+482/720]  [worker_thread+0/720]  [console_callback+0/176]  [default_wake_function+0/64]  [default_wake_function+0/64]  [kernel_thread_helper+5/16] 
Nov  1 11:16:30 iliana kernel: Code: 83 7b 18 00 74 4e 8b 54 24 14 8b 8e cc 00 00 00 0f b7 42 2c 

I don't believe the result of running ksymoops on these are valid, i
will have to reboot in the 2.5.44 kernel for it.

> If you did not define fb_set_var at all, then info->disp.dispsw must
> point to valid console drawing hooks before you register the
> framebuffer.  (Actually, all fields in struct display must be valid
> before you register the framebuffer)

Mmm, still need to check those.

> Your oops tracing points to fbcon_cursor as the culprit.  If
> dispsw->cursor is NULL, then you must have a valid dispsw->revc.

There where two oops, the first in fbcon_setup, and the second in
fbcon_cursor, i think i will be looking in the first oops first.

Anyway, thanks for your help.

Friendly,

Sven Luther


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: request_mem_region problem ...

[Antonino Daplas]

On Fri, 2002-11-01 at 18:52, Sven Luther wrote:
> On Thu, Oct 31, 2002 at 07:05:13PM +0800, Antonino Daplas wrote:
> > Running ksymoops on that might help.  The source can be found at
> > ftp.kernel.org.  
> 
> Ok, got it from the debian package :)))
> 
> Erm, i am no more running the same kernel, so i specified the -o and the
> -m options, but it looks at the wrong /proc/ksyms, should i save the
> /proc/ksyms of kernel before/after insmodding the pm3fb module ?
> 
Save the symbols after the insmod.
  
[..]
> 
> Ok, i did copy the cfb_ functions to the driver, it works better (the
> box does not hang anymore), the console apprently works (the cursor
> blinks in the right place, and it could type stuff, switch VT and
> shutdown the box) but there is nothing else written.
> 
> BTW, what is the difference between the full cursor and the underline
> one ?
The block cursor most probably comes from fbcon's software cursor, the
underline is probably your hardware's?

> 
> Anyway, here are the two Oops :
> 
> 
[...]
> I don't believe the result of running ksymoops on these are valid, i
> will have to reboot in the 2.5.44 kernel for it.
> 
> > If you did not define fb_set_var at all, then info->disp.dispsw must
> > point to valid console drawing hooks before you register the
> > framebuffer.  (Actually, all fields in struct display must be valid
> > before you register the framebuffer)
> 
> Mmm, still need to check those.
> 
> > Your oops tracing points to fbcon_cursor as the culprit.  If
> > dispsw->cursor is NULL, then you must have a valid dispsw->revc.
> 
> There where two oops, the first in fbcon_setup, and the second in
> fbcon_cursor, i think i will be looking in the first oops first.
> 
Might as well try to port your driver using the latest fbdev patch
posted by James, hopefully, this is the last major change.  This should
give you less things to worry about.

Tony  




-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: request_mem_region problem ...

[Sven Luther]

On Sat, Nov 02, 2002 at 03:42:14AM +0800, Antonino Daplas wrote:
> On Fri, 2002-11-01 at 18:52, Sven Luther wrote:
> > On Thu, Oct 31, 2002 at 07:05:13PM +0800, Antonino Daplas wrote:
> > > Running ksymoops on that might help.  The source can be found at
> > > ftp.kernel.org.  
> > 
> > Ok, got it from the debian package :)))
> > 
> > Erm, i am no more running the same kernel, so i specified the -o and the
> > -m options, but it looks at the wrong /proc/ksyms, should i save the
> > /proc/ksyms of kernel before/after insmodding the pm3fb module ?
> > 
> Save the symbols after the insmod.

Ok,

> > Ok, i did copy the cfb_ functions to the driver, it works better (the
> > box does not hang anymore), the console apprently works (the cursor
> > blinks in the right place, and it could type stuff, switch VT and
> > shutdown the box) but there is nothing else written.
> > 
> > BTW, what is the difference between the full cursor and the underline
> > one ?
> The block cursor most probably comes from fbcon's software cursor, the
> underline is probably your hardware's?

Mmm, maybe the other way around ? i get block cursor with the old
accelerated pm3fb, and since i did enter no acceleration whatsoever yet
in the new driver, i don't believe it can be using the hardware cursor.

> > Anyway, here are the two Oops :
> > 
> > 
> [...]
> > I don't believe the result of running ksymoops on these are valid, i
> > will have to reboot in the 2.5.44 kernel for it.
> > 
> > > If you did not define fb_set_var at all, then info->disp.dispsw must
> > > point to valid console drawing hooks before you register the
> > > framebuffer.  (Actually, all fields in struct display must be valid
> > > before you register the framebuffer)
> > 
> > Mmm, still need to check those.
> > 
> > > Your oops tracing points to fbcon_cursor as the culprit.  If
> > > dispsw->cursor is NULL, then you must have a valid dispsw->revc.
> > 
> > There where two oops, the first in fbcon_setup, and the second in
> > fbcon_cursor, i think i will be looking in the first oops first.
> > 
> Might as well try to port your driver using the latest fbdev patch
> posted by James, hopefully, this is the last major change.  This should
> give you less things to worry about.

Well, yes, i was going to donwload the BK tree, but james was speaking
about a 2.5.45 diff, which was finally not the right one.

Will do that nextly.

Friendly,

Sven Luther


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: request_mem_region problem ...

[Antonino Daplas]

On Sat, 2002-11-02 at 03:52, Sven Luther wrote:

[...]
> > > Ok, i did copy the cfb_ functions to the driver, it works better (the
> > > box does not hang anymore), the console apprently works (the cursor
> > > blinks in the right place, and it could type stuff, switch VT and
> > > shutdown the box) but there is nothing else written.
> > > 
> > > BTW, what is the difference between the full cursor and the underline
> > > one ?
> > The block cursor most probably comes from fbcon's software cursor, the
> > underline is probably your hardware's?
> 
> Mmm, maybe the other way around ? i get block cursor with the old
> accelerated pm3fb, and since i did enter no acceleration whatsoever yet
> in the new driver, i don't believe it can be using the hardware cursor.
> 
The fbcon software cursor is always a block cursor, well at least before
the latest patch James posted.  The newest patch should give you an
underline cursor by default.

> > > Anyway, here are the two Oops :
> > > 
> > > 
> > [...]
> > > I don't believe the result of running ksymoops on these are valid, i
> > > will have to reboot in the 2.5.44 kernel for it.
> > > 
> > > > If you did not define fb_set_var at all, then info->disp.dispsw must
> > > > point to valid console drawing hooks before you register the
> > > > framebuffer.  (Actually, all fields in struct display must be valid
> > > > before you register the framebuffer)
> > > 
> > > Mmm, still need to check those.
> > > 
> > > > Your oops tracing points to fbcon_cursor as the culprit.  If
> > > > dispsw->cursor is NULL, then you must have a valid dispsw->revc.
> > > 
> > > There where two oops, the first in fbcon_setup, and the second in
> > > fbcon_cursor, i think i will be looking in the first oops first.
> > > 
> > Might as well try to port your driver using the latest fbdev patch
> > posted by James, hopefully, this is the last major change.  This should
> > give you less things to worry about.
> 
> Well, yes, i was going to donwload the BK tree, but james was speaking
> about a 2.5.45 diff, which was finally not the right one.
> 
I downloaded the patch 12 hours ago and actually ported a driver to
that.  So unless James changed it again, it should be the right one.

Tony



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: request_mem_region problem ...

[Antonino Daplas]

On Sat, 2002-11-02 at 04:22, Sven Luther wrote:
[...]
> 
> > > Well, yes, i was going to donwload the BK tree, but james was speaking
> > > about a 2.5.45 diff, which was finally not the right one.
> > > 
> > I downloaded the patch 12 hours ago and actually ported a driver to
> > that.  So unless James changed it again, it should be the right one.
> 
> Mmm, yes, it was my fault.
> 
> BTW, is there something with the new kernel configuration process or
> something ? I get this error when trying to configure the kernel :
> 
> $ make oldconfig
> *
> * Unable to find the QT installation. Please make sure that the
> * QT development package is correctly installed and the QTDIR
> * environment variable is set to the correct location.
> *
> make[1]: *** [scripts/kconfig/.tmp_qtcheck] Erreur 1
> make: *** [scripts/kconfig/conf] Erreur 2
> 
> Is this something pulled in from james diff, or is it no more possible
> to configure the kernel with plain text console anymore ?
> 
It's an irritating bug in the new kernel configurator.  Try make -k if
it complains about the QT libs.



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: request_mem_region problem ...

[Antonino Daplas]

On Sat, 2002-11-02 at 05:23, Sven Luther wrote:
> On Sat, Nov 02, 2002 at 04:29:32AM +0800, Antonino Daplas wrote:
> > It's an irritating bug in the new kernel configurator.  Try make -k if
> > it complains about the QT libs.
> 
> Ok, it worked some, but debian's kernel-package command did not like it,
> o well, i will have to build it by hand until it is fixed.
> 
> BTW, in the old pm3fb driver (which i did not write) a pm3fb_info
> structure contained the driver local stuff. I suppose, from reading
> skeletonfb.c, that it is now in the xxx_par (that is pm3fb_par) that
> private driver info will be found ?
> 
Yes, you can stuff all your driver private data in info->par. (fb_info
can be stuffed in pci_device during pci_probe, I think).
  
> Also, since pm3fb_par is placed in include/video/pm3.h, this data will
> be shared with other entities, like the drm module for example.
> 
Yes, but it's optional.

> ...
> 
> Mmm, it does not compile :((((
> 
> drivers/video/console/vgacon.c: In function `vgacon_adjust_height':
> drivers/video/console/vgacon.c:890: `i' undeclared (first use in this function)
> drivers/video/console/vgacon.c:890: (Each undeclared identifier is reported only once
> drivers/video/console/vgacon.c:890: for each function it appears in.)
> make[3]: *** [drivers/video/console/vgacon.o] Erreur 1
> 
> O, well, i think i will wait another week or so that the new stuff has
> stabilized a bit more before continuing working on this.
> 
Just declare 'int i' and it should work.

Tony




-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: request_mem_region problem ...

[James Simmons]

> Yes, you can stuff all your driver private data in info->par. (fb_info
> can be stuffed in pci_device during pci_probe, I think).

Yeap!!

> > Mmm, it does not compile :((((
> >
> > drivers/video/console/vgacon.c: In function `vgacon_adjust_height':
> > drivers/video/console/vgacon.c:890: `i' undeclared (first use in this function)
> > drivers/video/console/vgacon.c:890: (Each undeclared identifier is reported only once
> > drivers/video/console/vgacon.c:890: for each function it appears in.)
> > make[3]: *** [drivers/video/console/vgacon.o] Erreur 1
> >
> > O, well, i think i will wait another week or so that the new stuff has
> > stabilized a bit more before continuing working on this.
> >
> Just declare 'int i' and it should work.

Fixed in the latest BK tree.




-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: request_mem_region problem ...

[James Simmons]

> If you did not define fb_set_var at all, then info->disp.dispsw must
> point to valid console drawing hooks before you register the
> framebuffer.  (Actually, all fields in struct display must be valid
> before you register the framebuffer)

The next set of change should help reduce these problems of missing
pointers as we move to the new api.

> > So, does the cfb_xxx generic accel stuff get linked correctly when
> > building as modules or am i missing something ?
>
> You're correct, the neofb line in the Makefile is for static building
> only.  The cfb_xxx will not compile as modules, yet.  If your driver has
> its own Makefile, just add cfb_xxx.o objects to directly link to them.

In the next set of changes the cfb* files should be able to be built as
modules!!!!




-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: request_mem_region problem ...

[Sven Luther]

On Fri, Nov 01, 2002 at 09:35:06AM -0800, James Simmons wrote:
> 
> > If you did not define fb_set_var at all, then info->disp.dispsw must
> > point to valid console drawing hooks before you register the
> > framebuffer.  (Actually, all fields in struct display must be valid
> > before you register the framebuffer)
> 
> The next set of change should help reduce these problems of missing
> pointers as we move to the new api.
> 
> > > So, does the cfb_xxx generic accel stuff get linked correctly when
> > > building as modules or am i missing something ?
> >
> > You're correct, the neofb line in the Makefile is for static building
> > only.  The cfb_xxx will not compile as modules, yet.  If your driver has
> > its own Makefile, just add cfb_xxx.o objects to directly link to them.
> 
> In the next set of changes the cfb* files should be able to be built as
> modules!!!!

The ones in the patches you failed to send or the one thereafter ?

BTW, do you think the latest set of changes will be in 2.4.46 or
something such ?

Friendly,

Sven Luther


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: request_mem_region problem ...

[James Simmons]

> > > You're correct, the neofb line in the Makefile is for static building
> > > only.  The cfb_xxx will not compile as modules, yet.  If your driver has
> > > its own Makefile, just add cfb_xxx.o objects to directly link to them.
> >
> > In the next set of changes the cfb* files should be able to be built as
> > modules!!!!
>
> The ones in the patches you failed to send or the one thereafter ?

None of them. Still in local tree. I will be sending up stuff in the next
few minutes.

> BTW, do you think the latest set of changes will be in 2.4.46 or
> something such ?

I hope so. I do know they are going in. When is the question. I don't mind
the deal since that means I can fix more things.



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: request_mem_region problem ...

[Sven Luther]

On Thu, Oct 31, 2002 at 07:05:13PM +0800, Antonino Daplas wrote:
> > How, well, maybe i should wait for the new patches from James to be
> > accepted into the linus tree.
> > 
> > Notice, maybe this is due to me not having defined yet any of the
> > check_var, set_par, blank, ... functions, but my idea, for the howto
> > afterward, was to write first the most minimal working fbdev.
> > 
> > BTW, should i work on james BK tree directly ? Is there an howto on how
> > to do that ? Or could it be possible to get a patch against 2.5.44 ?
> > 
> Try Documentation/BK-usage.  You will need a very fat pipe, then for a
> start, 
> 
> bk clone bk://fbdev.bkbits.net/fbdev-2.5

How the hell can i use this ? i don't have any bk installed, and i doubt
bk will ever be debian packaged so i will have to clutter my system, and
they ask me about some collection of stupid questions before i can download,
and finally it is not even possible to download this stuff.

I suppose there is another free solution for downloading the bk kernel,
does anyone have a link to it or to documentation about how to do it ?

Friendly,

Sven Luther


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf