Menu
▾
▴
linuxconsole-dev
|
From: James S. <jsi...@tr...> - 2001-09-04 17:03:08
|
> I added some printk's into the __fb_try_mode function, and the last message
> displayed before the OOPS was SVEN : 19, which is just before the if line :
>
> printk ("SVEN : 18\n");
> var->vmode = mode->vmode
> printk ("SVEN : 19\n");
> if (info->fbops->fb_check_var)
> err = info->fbops->fb_check_var(var, info);
> printk ("SVEN : 20\n");
> return !err;
> }
>
> So, i hope this gives you more information to tackle this bug.
That sounds like a bug in the check_var function. When I get the chance I
will go threw the code.
|
|
From: Sven L. <lu...@la...> - 2001-09-05 09:21:34
|
On Tue, Sep 04, 2001 at 10:03:02AM -0700, James Simmons wrote:
>
> > I added some printk's into the __fb_try_mode function, and the last message
> > displayed before the OOPS was SVEN : 19, which is just before the if line :
> >
> > printk ("SVEN : 18\n");
> > var->vmode = mode->vmode
> > printk ("SVEN : 19\n");
> > if (info->fbops->fb_check_var)
> > err = info->fbops->fb_check_var(var, info);
> > printk ("SVEN : 20\n");
> > return !err;
> > }
> >
> > So, i hope this gives you more information to tackle this bug.
>
> That sounds like a bug in the check_var function. When I get the chance I
> will go threw the code.
mmm, from my reading of the code and the bug and the stack trace and code
pointer, it seems that if fb_check_var was buggy, then the OOPS would happen
after the call to fb_check_var, and the code pointer returned by the OOPS
would be one inside the fb_check_var function.
my guess, but again, i didin't have time to look at it more in detail, would
be either info or info->fbops are null pointer. Or maybe even
info->fbops->fb_check_var is one, not sure if that would have the same
effect.
I will add some tests and printks here and report back.
But then maybe i misinterpreted the OOPS stuff, and it is possible that the
code pointer value is not the real one or something such ? i have no
experience in kernel debugging this kind of stuff.
Friendly,
Sven Luther
|
|
From: Romain D. <do...@ir...> - 2001-09-05 15:52:02
|
James Simmons wrote: > That sounds like a bug in the check_var function. When I get the chance I > will go threw the code. Dunno if it was the bug, but my ugly code had an ugly bug that needed an ugly fix (commited). if set_par was ever called prior to that check_var, then it was the bug (the pointer to the hardware-specific state got erased and never restored...) HTH -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Sven L. <lu...@la...> - 2001-09-11 11:40:00
|
On Wed, Sep 05, 2001 at 05:51:53PM +0200, Romain Dolbeau wrote: > James Simmons wrote: > > > That sounds like a bug in the check_var function. When I get the chance I > > will go threw the code. > > Dunno if it was the bug, but my ugly code had an ugly bug that > needed an ugly fix (commited). if set_par was ever called prior > to that check_var, then it was the bug (the pointer > to the hardware-specific state got erased and never restored...) More checking gave the following : 1) the bug number one seem to be because some of the __fb_try_mode call are done with a NULL info->fbops pointer. I don't understand why that is so, but anyway naturally it will hang when trying to acceess info->fbops->fb_check_var. When returning 0 when info->fpops is null, i managed to get a bit further, but could not see more than the last lines of the debug because of the oops. Is there a way to access the log in this case, apart from a serial console, which i don't have ? On amiga, it was possible to get access to a log saved in memory with the amigaOS version of the dmesg program, i suppose this is not possible on i386,at least not with lilo/grub ? mmm, maybe grub can look at the memory at some location, and i can read it there. Anyway, i returned 0, and it followed a bit, but again hang as follows : kernel_thread init pm3fb_open pm3fb_detect pm3fb_common_init fb_copy_cmap. -> here it hangs in the first line, where we access tyo->start and from-> start to calculate tooff, to and from don't seem to be NULL though, which seems strange to me because nothing more happens there, but then maybe i botched soem of the printks i used. Also, Romain, when enabling MASTER_DEBUG=3, i had to do some file editing, because there were various problems which hindered the compilation, but the last message i got where : pm3fb_realsetup : setting mode for board #0. (but i think this was still without the workaround to bug #1, don't remember exactly). Hope this helps somewhat, please keep me informed on further evolution, and i will hapilly test them. BTW, is it possible to build a modular fb stuff + pm3fb, so as to shorten build and test time, and maybe get more informative log messages, or will this not work/not show the right info ? Friendly, Sven Luther |
|
From: Romain D. <do...@ir...> - 2001-09-11 11:59:33
|
Sven Luther wrote: > 1) the bug number one seem to be because some of the __fb_try_mode call are > done with a NULL info->fbops pointer. I don't understand why that is so, but > anyway naturally it will hang when trying to acceess > info->fbops->fb_check_var. Yes, this come from a conceptual bug ; I shouldn't have take the easy way and ported the old pm3fb. The old one used an integrated database of mode that didn't require all the data required by modedb. Of course I forgot to check that, and now, if you put a 'mode:' option, hell break loose. <sigh> I'll fix that ASAP ; in the meantime, you might want to try without any 'mode:' option, that _should_ bypass the bug and use 640x480@60... Thanks for the report, -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Romain D. <do...@ir...> - 2001-09-11 12:18:13
|
Romain Dolbeau wrote: > Yes, this come from a conceptual bug ; > > I'll fix that ASAP it was 'easier' than I thought. It's commited and _should_ fix that problem... -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Sven L. <lu...@la...> - 2001-09-13 05:51:36
|
On Tue, Sep 11, 2001 at 02:18:08PM +0200, Romain Dolbeau wrote: > Romain Dolbeau wrote: > > > Yes, this come from a conceptual bug ; > > > > I'll fix that ASAP > > it was 'easier' than I thought. It's commited and _should_ > fix that problem... Ok, i will try it, what about the second bug ? the one about fb_cmap_copy ? Friendly, Sven Luther |
|
From: Romain D. <do...@ir...> - 2001-09-13 08:53:38
|
Sven Luther wrote: > Ok, i will try it, what about the second bug ? the one about fb_cmap_copy ? It shouldn't have been a copy but an alloc. I think :-) It's in the latest CVS. -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Sven L. <lu...@la...> - 2001-09-14 05:21:34
|
On Thu, Sep 13, 2001 at 10:53:31AM +0200, Romain Dolbeau wrote: > Sven Luther wrote: > > > Ok, i will try it, what about the second bug ? the one about fb_cmap_copy ? > > It shouldn't have been a copy but an alloc. I think :-) ??? > It's in the latest CVS. Ok, will try it, the previous correction did solve the problem, but it still hanged at cmap copy as before. Friendly, Sven Luther |
|
From: Romain D. <do...@ir...> - 2001-09-14 09:21:02
|
Sven Luther wrote: > On Thu, Sep 13, 2001 at 10:53:31AM +0200, Romain Dolbeau wrote: > > It shouldn't have been a copy but an alloc. I think :-) > > ??? I wrote buggy code :-) I was copying a default cmap to unallocated space... now it (properly I hope) allocate the cmap which by default is the default cmap... -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Sven <lu...@dp...> - 2001-09-14 09:51:14
|
On Fri, Sep 14, 2001 at 11:20:54AM +0200, Romain Dolbeau wrote: > Sven Luther wrote: > > On Thu, Sep 13, 2001 at 10:53:31AM +0200, Romain Dolbeau wrote: > > > It shouldn't have been a copy but an alloc. I think :-) > > > > ??? > > I wrote buggy code :-) I was copying a default cmap > to unallocated space... now it (properly I hope) > allocate the cmap which by default is the default cmap... mmm, i tested it, it is now dying at c01e7ee3, the relevant portion of the System.map file is : c01e7de8 t pm3fb_common_init c01e7fd8 t pm3fb_decode_var so it is in pm3fb_common_init, i am just building a kernel with debug messages (printk's, not your debug stuff) enabled to know more about it. BTW, could you send me diffs, or maybe have the pm3fb.c file available as a standalone, yesterday's ruby died at build time in ksym.c. Also, i am really curious of what happens on your box when you try it out ? Apparently you don't even come that far ? Friendly, Sven Luther |
|
From: Romain D. <do...@ir...> - 2001-09-14 09:54:18
|
Sven wrote: > BTW, could you send me diffs, or maybe have the pm3fb.c file available as a > standalone, yesterday's ruby died at build time in ksym.c. Huh ? the current ruby is against 2.4.8, and I fixed the only typos that prevented it to build... > Also, i am really curious of what happens on your box when you try it out ? > Apparently you don't even come that far ? It crash to xmon very early, with pm3fb or with offb (I should try again offb maybe it's better now...) -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Sven <lu...@dp...> - 2001-09-14 09:58:09
|
On Fri, Sep 14, 2001 at 11:54:12AM +0200, Romain Dolbeau wrote: > Sven wrote: > > > BTW, could you send me diffs, or maybe have the pm3fb.c file available as a > > standalone, yesterday's ruby died at build time in ksym.c. > > Huh ? the current ruby is against 2.4.8, and I fixed the only typos > that prevented it to build... Arg, ... surely that's why, why not against 2.4.9 ? BTW, did you fix also the debugging stuff in pm3fb, so i could enable the master_debug variable ? In the meantime i just copied the more recent pm3fb files to my working 2.4.7+older ruby tree. > > Also, i am really curious of what happens on your box when you try it out ? > > Apparently you don't even come that far ? > > It crash to xmon very early, with pm3fb or with offb (I should > try again offb maybe it's better now...) what is xmon ? let's hope we will fix this nextly, BTW, will ruby fix dual head (i guess so) and the vga garbage stuff, or do i still need to go after it ? Friendly, Sven Luther > > -- > DOLBEAU Romain | l'histoire est entierement vraie, puisque > ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre > do...@ir... | -- Boris Vian |
|
From: James S. <jsi...@tr...> - 2001-09-14 16:06:12
|
> > Huh ? the current ruby is against 2.4.8, and I fixed the only typos > > that prevented it to build... > > Arg, ... surely that's why, why not against 2.4.9 ? I haven't ported it yet to 2.4.9. I plan to this weekend. > BTW, will ruby fix dual head (i guess so) and the vga garbage stuff, or do i > still need to go after it ? It should. |
|
From: Sven <lu...@dp...> - 2001-09-15 06:17:34
|
On Fri, Sep 14, 2001 at 09:05:51AM -0700, James Simmons wrote: > > > > Huh ? the current ruby is against 2.4.8, and I fixed the only typos > > > that prevented it to build... > > > > Arg, ... surely that's why, why not against 2.4.9 ? > > I haven't ported it yet to 2.4.9. I plan to this weekend. Ok, i was surprised because the passage to 2.4.8 for ruby was done well after the 2.4.9 release, but i suppose you import the kernel patch into the ruby tree gradually ? > > BTW, will ruby fix dual head (i guess so) and the vga garbage stuff, or do i > > still need to go after it ? > > It should. And i will also be able to use a second keyboard and mouse and have a second independent console, isn't it ? I will gladly test anything like that, and see how X needs to be modified accordyingly ? Right now it blanks all the heads of the same board, when running ... Friendly, Sven Luther |
|
From: James S. <jsi...@tr...> - 2001-09-16 02:41:13
|
> Ok, i was surprised because the passage to 2.4.8 for ruby was done well after > the 2.4.9 release, but i suppose you import the kernel patch into the ruby > tree gradually ? Well the reason I did this was I was doing ARM ruby developement. Unfortunely Russell King moved over to the AC tree so I continued to do developement on the ARM branch against Linus tree until just recently. > And i will also be able to use a second keyboard and mouse and have a second > independent console, isn't it ? I will gladly test anything like that, and see > how X needs to be modified accordyingly ? Right now it blanks all the heads of > the same board, when running ... Yes. I believe using the -vt flag would allow X to run on two seperate consoles at the same time. As for blanking well that is more of a problem. Unfortunely you can't run a X server across multiple desktops at the same time. |
|
From: Sven <lu...@dp...> - 2001-09-17 15:30:52
|
On Sat, Sep 15, 2001 at 07:40:52PM -0700, James Simmons wrote: > > > Ok, i was surprised because the passage to 2.4.8 for ruby was done well after > > the 2.4.9 release, but i suppose you import the kernel patch into the ruby > > tree gradually ? > > Well the reason I did this was I was doing ARM ruby developement. > Unfortunely Russell King moved over to the AC tree so I continued to do > developement on the ARM branch against Linus tree until just recently. > > > And i will also be able to use a second keyboard and mouse and have a second > > independent console, isn't it ? I will gladly test anything like that, and see > > how X needs to be modified accordyingly ? Right now it blanks all the heads of > > the same board, when running ... > > Yes. I believe using the -vt flag would allow X to run on two seperate > consoles at the same time. As for blanking well that is more of a problem. > Unfortunely you can't run a X server across multiple desktops at the same > time. As soon as it works, i will be testing it< As for X, even when you run two X servers (one as :1.0 on the first head, the other on :0.0 omn the second head, it will blank the not current head. bnut then maybe the fact that i had only one mouse and keybord to test it my be the xcause of it. Friendlym Sven Luther |
|
From: Sven <lu...@dp...> - 2001-09-14 10:30:55
|
On Fri, Sep 14, 2001 at 11:54:12AM +0200, Romain Dolbeau wrote:
> Sven wrote:
>
> > BTW, could you send me diffs, or maybe have the pm3fb.c file available as a
> > standalone, yesterday's ruby died at build time in ksym.c.
>
> Huh ? the current ruby is against 2.4.8, and I fixed the only typos
> that prevented it to build...
>
> > Also, i am really curious of what happens on your box when you try it out ?
> > Apparently you don't even come that far ?
>
> It crash to xmon very early, with pm3fb or with offb (I should
> try again offb maybe it's better now...)
Nope, it still is a problem with cmap ...
the culprit code is :
cmap = &(l_fb_info->current_par->f_fb_info->cmap);
> the cmap takes an 9x130 value here
cmap->red = cmap->green = cmap->blue = cmap->transp = NULL;
> well the kernel oops with unable to handle kernel NULL pointer
dereference at virtual address 144 here
cmap->len = 0; cmap->start = 0;
fb_alloc_cmap(cmap, 16, 0);
So, i don't know, but i guess the cmap is not of the right type, or maybe you
should let the & away, or more simply the
l_fb_info->current_par->f_fb_info->cmap value is NULL. I guess it is this last
one that is the case, i did not test it though ...
Friendly,
Sven Luther
|
|
From: James S. <jsi...@tr...> - 2001-09-14 16:47:00
|
> > I wrote buggy code :-) I was copying a default cmap > > to unallocated space... now it (properly I hope) > > allocate the cmap which by default is the default cmap... A note about initalizing a video card. The fb console system does this for you. You don't need to set the video mode or the color map. A small note. You need the framebuffer console enable to do this. If you have a stand alone fbdev system you at present have to set the video mode with some userland application like fbset. I do plan to add a patch that sets the mode in register_framebuffer if the var.activate field is FB_ACTIVATE_NOW. This makes sense for embedded devices. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X