you wrote
----------------------
Please try my patch I sent to Ben. I attached it to this email for people
to try it.
diff -urN -X /home/jsimmons/dontdiff
linus-2.5/drivers/video/console/fbcon.c \
fbdev-2.5/drivers/video/console/fbcon.c
--- linus-2.5/drivers/video/console/fbcon.c Sat Mar 22 21:45:23 2003
+++ fbdev-2.5/drivers/video/console/fbcon.c Tue Mar 25 12:03:56 2003
--------------------
One hunk applied with fuzz and two hunks were rejected when applied both
to 2.5.66 stock and bk-latest. I fixed up the rejects by hand and
compiled a new kernel against bk-latest. I am running with that version
now, which doesn't emit the string of messages I reported originally. The
only minor anomaly I note is the cursor is a three-segment underscore
rather than a solid underscore.
Am Mittwoch, 26. M?rz 2003 15:31 schrieb Thomas Molina:
> One hunk applied with fuzz and two hunks were rejected when applied both
> to 2.5.66 stock and bk-latest. I fixed up the rejects by hand and
> compiled a new kernel against bk-latest. I am running with that version
> now, which doesn't emit the string of messages I reported originally. The
> only minor anomaly I note is the cursor is a three-segment underscore
> rather than a solid underscore.
I had the same problems patching my 2.5.66 and so applied the patch by hand,
too. The problem with the wrong shaped cursor was here, too, I solved it with
the attached patch. The 'data' area was not initialized correctly. The patch
also uses 'memset()' to generate the 'mask' instead of writing the bytes by
hand...
I hope this helps you,too!
Thomas Schlichter
On Wed, 26 Mar 2003, Thomas Schlichter wrote:
Running with the patch as posted by Mr. Simmons I didn't get any further
instances of the sleeping function call from illegal context messages I
reported before, until screenblanking went into effect. I then got the
following:
Mar 26 10:45:03 dad kernel: Debug: sleeping function called from illegal
context at mm/slab.c:1723
Mar 26 10:45:03 dad kernel: Call Trace:
Mar 26 10:45:03 dad kernel: [<c011d7bf>] __might_sleep+0x4f/0x90
Mar 26 10:45:03 dad kernel: [<c0149611>] kmalloc+0x1a1/0x1c0
Mar 26 10:45:03 dad kernel: [<c0233b65>] accel_cursor+0xd5/0x320
Mar 26 10:45:03 dad kernel: [<c0233edf>] fbcon_cursor+0x12f/0x160
Mar 26 10:45:03 dad kernel: [<c011b74a>] __wake_up_common+0x3a/0x60
Mar 26 10:45:03 dad kernel: [<c01ef99b>] clear_selection+0x1b/0x60
Mar 26 10:45:03 dad kernel: [<c01f2623>] hide_cursor+0x63/0xa0
Mar 26 10:45:03 dad kernel: [<c01f65df>] timer_do_blank_screen+0x4f/0x1b0
Mar 26 10:45:03 dad kernel: [<c01f6870>] blank_screen+0x0/0x20
Mar 26 10:45:03 dad kernel: [<c01f688a>] blank_screen+0x1a/0x20
Mar 26 10:45:03 dad kernel: [<c012ab32>] run_timer_softirq+0x132/0x3c0
Mar 26 10:45:03 dad kernel: [<c0125de1>] do_softirq+0xa1/0xb0
Mar 26 10:45:03 dad kernel: [<c010bdec>] do_IRQ+0x1fc/0x320
Mar 26 10:45:03 dad kernel: [<c0109fdc>] common_interrupt+0x18/0x20
Mar 26 10:45:03 dad kernel: [<c0116c1b>] apm_bios_call_simple+0x7b/0xa0
Mar 26 10:45:03 dad kernel: [<c0116d99>] apm_do_idle+0x29/0x80
Mar 26 10:45:03 dad kernel: [<c0116ead>] apm_cpu_idle+0x7d/0x150
Mar 26 10:45:03 dad kernel: [<c0116e30>] apm_cpu_idle+0x0/0x150
Mar 26 10:45:03 dad kernel: [<c0106fc0>] default_idle+0x0/0x30
Mar 26 10:45:03 dad kernel: [<c0107061>] cpu_idle+0x31/0x40
Mar 26 10:45:03 dad kernel: [<c0105000>] rest_init+0x0/0x30
> Running with the patch as posted by Mr. Simmons I didn't get any further
> instances of the sleeping function call from illegal context messages I
> reported before, until screenblanking went into effect. I then got the
> following:
Oh no!!! I just look at the console timer blanking code. It calls alot of
stuff. Not only does this mean we are limited in using kmalloc if we need
it but also using a semaphore to sync up the fb_pixmap stuff. At present
we use a spinlock. I tried it with a semphore but it kept hosing my
system. Now I know why.
What should be done is the console blank timer be passed onto
console_callback.
P.S
I reversed some of the cursor changes. It uses static buffers again
until we have these issues solved. The code works as long as you don't use
more than one framebuffer device but it is rock solid like before for a
single framebuffer device. I will have a patch ready in the hour.
On Wed, 2003-03-26 at 19:33, James Simmons wrote:
> > Running with the patch as posted by Mr. Simmons I didn't get any further
> > instances of the sleeping function call from illegal context messages I
> > reported before, until screenblanking went into effect. I then got the
> > following:
>
> Oh no!!! I just look at the console timer blanking code. It calls alot of
> stuff. Not only does this mean we are limited in using kmalloc if we need
> it but also using a semaphore to sync up the fb_pixmap stuff. At present
> we use a spinlock. I tried it with a semphore but it kept hosing my
> system. Now I know why.
Junk. Move that console blanking stuff to process context too.
Actually, I've never fully understood some of the console blanking
code, especially the PM callback in there which does really weird
things. On pmacs, this code cause the screen to first blank, then
unblank, then blank again when the machine is going to sleep.
Ben.