BUG: fb_imageblit called before fb_check_var and fb_set_par function

BUG: fb_imageblit called before fb_check_var and fb_set_par function

[Knut Petersen]

Hi everybody,

under certain circumstances the X trident driver does disable mmio
upon returning to a linux console. As mapped ioports are no longer
available, this is an immediate problem.

I never had expected that upon switching from X to a linux console
drawing functions like fb_imageblit would be called before the
fb_check_var and  fb_set_par functions have been called. But that´s
definitely the case.

Cyblafb now has a workaround for the problem, but I do believe that
this odd behaviour could also be the reason for failure or problems of
some other drivers  that do work fine as long as X is not involved,
but fail or show problems upon switching between the linux console
and X.

Please have a look at the code.

cu,
 Knut


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: BUG: fb_imageblit called before fb_check_var and fb_set_par function

[Antonino A. Daplas]

Knut Petersen wrote:
> Hi everybody,
> 
> under certain circumstances the X trident driver does disable mmio
> upon returning to a linux console. As mapped ioports are no longer
> available, this is an immediate problem.
> 
> I never had expected that upon switching from X to a linux console
> drawing functions like fb_imageblit would be called before the
> fb_check_var and  fb_set_par functions have been called. But that´s
> definitely the case.
> 

I'm surprised.  That was a problem in earlier versions of the kernel
but I think that was fixed.  If you look at fbcon code, all calls to
drawing functions:

putcs, bmove, scroll, cursor, flashcursor, etc has an 

if (fbcon_is_inactive()) in the beginning.

And everytime the vt switches from KD_GRAPHICS to KD_TEXT (ie from X),
a set_var()/ set_par() will be called automatically to reset the fbdev
drivers before the "drawing" functions are called.

Can you instrument where this is happening?  Because if it still is,
then that is a show-stopping bug.

Tony 


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: BUG: fb_imageblit called before fb_check_var and fb_set_par function

[Knut Petersen]

Hi Antonino,

BTW: Thanks to Jochen Hein for testing cyblafb and reporting the
very long timeout after switching from X to console!

>> I never had expected that upon switching from X to a linux console
>> drawing functions like fb_imageblit would be called before the
>> fb_check_var and  fb_set_par functions have been called. But that´s
>> definitely the case.
>
> I'm surprised.  That was a problem in earlier versions of the kernel
> but I think that was fixed.  If you look at fbcon code, all calls to
> drawing functions:

My system is based on SuSE 9.2.
Kernel 2.6.13-rc7

1. If I do compile cyblafb as a module, there is no problem.

2. If I compile cyblafb into the kernel, there is no problem if
the first runlevel is 3 and I switch to runlevel 5 after login to
a console.

3. If I compile cyblafb into the kernel, the problem is 100% reproducible
if the first runlevel is 5. ps ax -H in that case:

1342 ?        Ss       0:00   /usr/sbin/cron
1352 ?        Ss       0:00   /usr/sbin/gpm -m /dev/ttyS0 -t ms
1362 ?        S        0:00   /opt/kde3/bin/kdm
1385 ?        S        0:20     /usr/X11R6/bin/X -nolisten tcp -br vt7 
-auth /var/lib/xdm/authdir/authfiles/A:0-Zgg52m
1392 ?        S        0:00     -:0             
1681 ?        S        0:00       /bin/sh /usr/X11R6/bin/kde
1716 ?        S        0:00         gpg-agent --daemon --no-detach 
--keep-display /bin/bash /etc/X11/xinit/xinitrc
1786 ?        S        0:00         kwrapper ksmserver
1648 ?        Ss       0:00   login -- root    
1744 tty1    Ss+    0:00     -bash
1649 tty2    Ss+    0:00   /sbin/mingetty tty2

The very first time I switch back from X to a linux console the bug
is triggered. cyblafb_sync() , called from cyblafb_imageblit(), times
out because mmio is switched off. Then a number of drawing functions
is called before the checkvar() and the setpar() are executed.

Let´s count in /var/log/messages .... exactly 64 calls.

64 (rows) * 16 (font height) = 1024 (screen height). I have not verified 
that
all those calls are imageblits, but  it seems that somebody wants to redraw
the screen.

After that the bug never triggers again.

I wonder why there should be a difference between kdm executed first
or login executed first, but that´s the case.

Feel free to send patches.

cu,
 Knut


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: BUG: fb_imageblit called before fb_check_var and fb_set_par function

[Antonino A. Daplas]

Knut Petersen wrote:
> Hi Antonino,
> 
> BTW: Thanks to Jochen Hein for testing cyblafb and reporting the
> very long timeout after switching from X to console!
> 
>>> I never had expected that upon switching from X to a linux console
>>> drawing functions like fb_imageblit would be called before the
>>> fb_check_var and  fb_set_par functions have been called. But that´s
>>> definitely the case.
>>
>> I'm surprised.  That was a problem in earlier versions of the kernel
>> but I think that was fixed.  If you look at fbcon code, all calls to
>> drawing functions:
> 
> My system is based on SuSE 9.2.
> Kernel 2.6.13-rc7
> 
> 1. If I do compile cyblafb as a module, there is no problem.
> 
> 2. If I compile cyblafb into the kernel, there is no problem if
> the first runlevel is 3 and I switch to runlevel 5 after login to
> a console.
> 
> 3. If I compile cyblafb into the kernel, the problem is 100% reproducible
> if the first runlevel is 5. ps ax -H in that case:
> 
> 1342 ?        Ss       0:00   /usr/sbin/cron
> 1352 ?        Ss       0:00   /usr/sbin/gpm -m /dev/ttyS0 -t ms
> 1362 ?        S        0:00   /opt/kde3/bin/kdm
> 1385 ?        S        0:20     /usr/X11R6/bin/X -nolisten tcp -br vt7 
> -auth /var/lib/xdm/authdir/authfiles/A:0-Zgg52m
> 1392 ?        S        0:00     -:0             1681 ?        S        
> 0:00       /bin/sh /usr/X11R6/bin/kde
> 1716 ?        S        0:00         gpg-agent --daemon --no-detach 
> --keep-display /bin/bash /etc/X11/xinit/xinitrc
> 1786 ?        S        0:00         kwrapper ksmserver
> 1648 ?        Ss       0:00   login -- root    1744 tty1    Ss+    
> 0:00     -bash
> 1649 tty2    Ss+    0:00   /sbin/mingetty tty2
> 
> The very first time I switch back from X to a linux console the bug
> is triggered. cyblafb_sync() , called from cyblafb_imageblit(), times
> out because mmio is switched off. Then a number of drawing functions
> is called before the checkvar() and the setpar() are executed.
> 
> Let´s count in /var/log/messages .... exactly 64 calls.
> 
> 64 (rows) * 16 (font height) = 1024 (screen height). I have not verified 
> that
> all those calls are imageblits, but  it seems that somebody wants to redraw
> the screen.
> 
> After that the bug never triggers again.
> 
> I wonder why there should be a difference between kdm executed first
> or login executed first, but that´s the case.

I tried to duplicate the problem, but failed.

First, I inserted stub calls, disable_device(info). I inserted it in fbcon_blank(),
if blank != 0 and mode_switch != 0. I also inserted another one in fbcon_switch(),
if vc->vc_mode == KD_GRAPHICS. These are the circumstances when the console is
about to be acquired by a graphics apps like X.  Then the stub function,
disable_device(), in the fbdev driver, just sets a flag.  This flag is cleared
on a set_par(). This flag is also checked by the sync, imageblit, fillrect and
copyarea functions, which prints something when this flag != 0. I'm not getting
any messages.  Which, if I interpret this correctly, that a set_par will always
be called before any of the drawing functions.

The circumstance I can think of that this can happen is when the app fails to
set the VT to KD_GRAPHICS mode, but I'm pretty sure kdm does it properly, in 
my machine at least (Suse 9.0).

Perhaps, if you have the time, you can instrument it better so we can pinpoint
where this unwanted calls are coming from.  Months were spent trying to fix this
problem, mainly by BenH, and I don't want any stones left unturned.

Tony

PS: I don't know the console subsystem that well, so there may be pathways that
I don't know about.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: BUG: fb_imageblit called before fb_check_var and fb_set_par function

[Knut Petersen]

Hi Antonio,

> Perhaps, if you have the time, you can instrument it better so we can 
> pinpoint
> where this unwanted calls are coming from.  Months were spent trying 
> to fix this
> problem, mainly by BenH, and I don't want any stones left unturned. 

So lets conclude: The problem is _not_ fixed and still present in 
2.6.13-rc7.
I added BenH and Andrew Morton to the cc-list.

I added a printk at the start of redraw_screen() and a show_trace() in 
cyblafb_sync().

Imho
   - there is a bug of the trident driver in X that should _never_ 
disable mmio for
     the cyberblade core if it is started with mmio enabled.  A bug Alan 
Hourihane
     should fix.
  - there also is a serious kernel bug as no drawing function must be called
     prior to setting up the framebuffer driver by executing the 
set_par() call.

I´m happy to have learned enough about the low -level framebuffer layer,
but I´m definitely not qualified to do fixed in char/vt.c, 
char/vt_ioctl.c etc.

Read some shortened dmesg logs:
(cyblafb: Switching ... marks the start of the fb_set_par function)

==========
First log:
==========
1-init to runlevel 3
2-login as root on tty1
3-init 5
4-switching back to tty1 with ctrl-alt-f1

...
Detected 533.506 MHz processor.
Using tsc for high-res timesource
redraw_screen: called with is_switch 0 and vc->vc_mode 0
Console: colour dummy device 80x25
...
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
...
cyblafb: CyblaFB version 0.53 initializing
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level, 
low) -> IRQ 11
cyblafb: framebuffer size = 8192 Kb
cyblafb: detected startup mode: fbset -g 1280 1024 1280 ??? 8 -t 7407 
232 16 39 0 160 3
redraw_screen: called with is_switch 0 and vc->vc_mode 0
cyblafb: Switching to new mode: fbset -g 1280 1024 1280 2662 8 -t 7407 
232 16 39 0 160 3
redraw_screen: called with is_switch 0 and vc->vc_mode 0
redraw_screen: called with is_switch 0 and vc->vc_mode 0
Console: switching to colour frame buffer device 160x64
...
ACPI: PCI Interrupt 0000:00:11.5[C] -> Link [LNKC] -> GSI 12 (level, 
low) -> IRQ 12
PCI: Setting latency timer of device 0000:00:11.5 to 64
redraw_screen: called with is_switch 0 and vc->vc_mode 0
eth0: no IPv6 routers present
redraw_screen: called with is_switch 0 and vc->vc_mode 0
******** Now logged in as root on tty1
redraw_screen: called with is_switch 1 and vc->vc_mode 0
******** X has been started here, we are in xterm. Now ctrl-alt-f1:
redraw_screen: called with is_switch 1 and vc->vc_mode 0
cyblafb: Switching to new mode: fbset -g 1280 1024 1280 2662 8 -t 7407 
232 16 39 0 160 3
redraw_screen: called with is_switch 0 and vc->vc_mode 0
******** We switched back to tty1

As you can see, redraw_screen is called prior to cyblafb_setpar, but 
nothing bad is
triggered because the X trident buffer does not disable mmio.
===========
Second log:
===========
1-init to runlevel 5
2-switching to tty1 with ctrl-alt-f1

...
Detected 533.508 MHz processor.
Using tsc for high-res timesource
redraw_screen: called with is_switch 0 and vc->vc_mode 0
Console: colour dummy device 80x25
...
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
...
cyblafb: CyblaFB version 0.53 initializing
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level, 
low) -> IRQ 11
cyblafb: framebuffer size = 8192 Kb
cyblafb: detected startup mode: fbset -g 1280 1024 1280 ??? 8 -t 7407 
232 16 39 0 160 3
redraw_screen: called with is_switch 0 and vc->vc_mode 0
cyblafb: Switching to new mode: fbset -g 1280 1024 1280 2662 8 -t 7407 
232 16 39 0 160 3
redraw_screen: called with is_switch 0 and vc->vc_mode 0
redraw_screen: called with is_switch 0 and vc->vc_mode 0
Console: switching to colour frame buffer device 160x64
...
ACPI: PCI Interrupt 0000:00:11.5[C] -> Link [LNKC] -> GSI 12 (level, 
low) -> IRQ 12
PCI: Setting latency timer of device 0000:00:11.5 to 64
redraw_screen: called with is_switch 0 and vc->vc_mode 0
eth0: no IPv6 routers present
redraw_screen: called with is_switch 1 and vc->vc_mode 0
******** X has been started here, we are in xterm
******** ctrl-alt-f1
redraw_screen: called with is_switch 1 and vc->vc_mode 0
cyblafb: GRAPHICS ENGINE TIMED OUT!
 [<c0246abd>] cyblafb_imageblit+0xad/0x230
 [<c0241a3b>] bit_putcs+0x2eb/0x560
 [<c01138a5>] __wake_up_common+0x35/0x70
 [<c023dba8>] fbcon_putcs+0x168/0x210
 [<c028c11b>] do_update_region+0x11b/0x180
 [<c028cc13>] redraw_screen+0x143/0x1e0
 [<c0288788>] complete_change_console+0x28/0xd0
 [<c0287cbd>] vt_ioctl+0x111d/0x1aa0
 [<c014886e>] __handle_mm_fault+0x13e/0x180
 [<c011174d>] do_page_fault+0x19d/0x550
 [<c03a7dd7>] schedule+0x337/0x670
 [<c0286ba0>] vt_ioctl+0x0/0x1aa0
 [<c0281fbc>] tty_ioctl+0x17c/0x410
 [<c011364a>] scheduler_tick+0x17a/0x310
 [<c0169d98>] do_ioctl+0x48/0x80
 [<c0169f2a>] vfs_ioctl+0x5a/0x1d0
 [<c016a0e6>] sys_ioctl+0x46/0x60
 [<c0102909>] syscall_call+0x7/0xb
cyblafb: Switching to new mode: fbset -g 1280 1024 1280 2662 8 -t 7407 
232 16 39 0 160 3
redraw_screen: called with is_switch 0 and vc->vc_mode 0
******** Now logged in as root on tty1
redraw_screen: called with is_switch 1 and vc->vc_mode 1
******** switched to xterm
redraw_screen: called with is_switch 1 and vc->vc_mode 0
cyblafb: Switching to new mode: fbset -g 1280 1024 1280 2662 8 -t 7407 
232 16 39 0 160 3
redraw_screen: called with is_switch 0 and vc->vc_mode 0
******** switched back to tty1

cu,
 Knut



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: BUG: fb_imageblit called before fb_check_var and fb_set_par function

[Antonino A. Daplas]

Knut Petersen wrote:
> Hi Antonio,
> 
>> Perhaps, if you have the time, you can instrument it better so we can 
>> pinpoint
>> where this unwanted calls are coming from.  Months were spent trying 
>> to fix this
>> problem, mainly by BenH, and I don't want any stones left unturned. 
> 
> So lets conclude: The problem is _not_ fixed and still present in 
> 2.6.13-rc7.
> I added BenH and Andrew Morton to the cc-list.
> 
> I added a printk at the start of redraw_screen() and a show_trace() in 
> cyblafb_sync().
> 
> Imho
>   - there is a bug of the trident driver in X that should _never_ 
> disable mmio for
>     the cyberblade core if it is started with mmio enabled.  A bug Alan 
> Hourihane
>     should fix.
>  - there also is a serious kernel bug as no drawing function must be called
>     prior to setting up the framebuffer driver by executing the 
> set_par() call.
> 
> I´m happy to have learned enough about the low -level framebuffer layer,
> but I´m definitely not qualified to do fixed in char/vt.c, 
> char/vt_ioctl.c etc.
> 
> Read some shortened dmesg logs:
> (cyblafb: Switching ... marks the start of the fb_set_par function)
> 
> ==========
> First log:
> ==========
> 1-init to runlevel 3
> 2-login as root on tty1
> 3-init 5
> 4-switching back to tty1 with ctrl-alt-f1
> 
> ...
> Detected 533.506 MHz processor.
> Using tsc for high-res timesource
> redraw_screen: called with is_switch 0 and vc->vc_mode 0
> Console: colour dummy device 80x25
> ...
> ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
> Boot video device is 0000:01:00.0
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
> ...
> cyblafb: CyblaFB version 0.53 initializing
> ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
> PCI: setting IRQ 11 as level-triggered
> ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level, 
> low) -> IRQ 11
> cyblafb: framebuffer size = 8192 Kb
> cyblafb: detected startup mode: fbset -g 1280 1024 1280 ??? 8 -t 7407 
> 232 16 39 0 160 3
> redraw_screen: called with is_switch 0 and vc->vc_mode 0
> cyblafb: Switching to new mode: fbset -g 1280 1024 1280 2662 8 -t 7407 
> 232 16 39 0 160 3
> redraw_screen: called with is_switch 0 and vc->vc_mode 0
> redraw_screen: called with is_switch 0 and vc->vc_mode 0
> Console: switching to colour frame buffer device 160x64
> ...
> ACPI: PCI Interrupt 0000:00:11.5[C] -> Link [LNKC] -> GSI 12 (level, 
> low) -> IRQ 12
> PCI: Setting latency timer of device 0000:00:11.5 to 64
> redraw_screen: called with is_switch 0 and vc->vc_mode 0
> eth0: no IPv6 routers present
> redraw_screen: called with is_switch 0 and vc->vc_mode 0
> ******** Now logged in as root on tty1
> redraw_screen: called with is_switch 1 and vc->vc_mode 0
> ******** X has been started here, we are in xterm. Now ctrl-alt-f1:
> redraw_screen: called with is_switch 1 and vc->vc_mode 0
> cyblafb: Switching to new mode: fbset -g 1280 1024 1280 2662 8 -t 7407 
> 232 16 39 0 160 3
> redraw_screen: called with is_switch 0 and vc->vc_mode 0
> ******** We switched back to tty1
> 
> As you can see, redraw_screen is called prior to cyblafb_setpar, but 
> nothing bad is
> triggered because the X trident buffer does not disable mmio.
> ===========
> Second log:
> ===========
> 1-init to runlevel 5
> 2-switching to tty1 with ctrl-alt-f1
> 
> ...
> Detected 533.508 MHz processor.
> Using tsc for high-res timesource
> redraw_screen: called with is_switch 0 and vc->vc_mode 0
> Console: colour dummy device 80x25
> ...
> ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
> Boot video device is 0000:01:00.0
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
> ...
> cyblafb: CyblaFB version 0.53 initializing
> ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
> PCI: setting IRQ 11 as level-triggered
> ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level, 
> low) -> IRQ 11
> cyblafb: framebuffer size = 8192 Kb
> cyblafb: detected startup mode: fbset -g 1280 1024 1280 ??? 8 -t 7407 
> 232 16 39 0 160 3
> redraw_screen: called with is_switch 0 and vc->vc_mode 0
> cyblafb: Switching to new mode: fbset -g 1280 1024 1280 2662 8 -t 7407 
> 232 16 39 0 160 3
> redraw_screen: called with is_switch 0 and vc->vc_mode 0
> redraw_screen: called with is_switch 0 and vc->vc_mode 0
> Console: switching to colour frame buffer device 160x64
> ...
> ACPI: PCI Interrupt 0000:00:11.5[C] -> Link [LNKC] -> GSI 12 (level, 
> low) -> IRQ 12
> PCI: Setting latency timer of device 0000:00:11.5 to 64
> redraw_screen: called with is_switch 0 and vc->vc_mode 0
> eth0: no IPv6 routers present
> redraw_screen: called with is_switch 1 and vc->vc_mode 0
> ******** X has been started here, we are in xterm

So X is already started here, but vc->vc_mode is still KD_TEXT.

> ******** ctrl-alt-f1
> redraw_screen: called with is_switch 1 and vc->vc_mode 0

Back to console mode, vc->vc_mode is correctly KD_TEXT.  But
the kernel never detected a mode change. How could it, if the
previous mode was also KD_TEXT?
 
> cyblafb: GRAPHICS ENGINE TIMED OUT!
> [<c0246abd>] cyblafb_imageblit+0xad/0x230
> [<c0241a3b>] bit_putcs+0x2eb/0x560
> [<c01138a5>] __wake_up_common+0x35/0x70
> [<c023dba8>] fbcon_putcs+0x168/0x210
> [<c028c11b>] do_update_region+0x11b/0x180
> [<c028cc13>] redraw_screen+0x143/0x1e0
> [<c0288788>] complete_change_console+0x28/0xd0
> [<c0287cbd>] vt_ioctl+0x111d/0x1aa0
> [<c014886e>] __handle_mm_fault+0x13e/0x180
> [<c011174d>] do_page_fault+0x19d/0x550
> [<c03a7dd7>] schedule+0x337/0x670
> [<c0286ba0>] vt_ioctl+0x0/0x1aa0
> [<c0281fbc>] tty_ioctl+0x17c/0x410
> [<c011364a>] scheduler_tick+0x17a/0x310
> [<c0169d98>] do_ioctl+0x48/0x80
> [<c0169f2a>] vfs_ioctl+0x5a/0x1d0
> [<c016a0e6>] sys_ioctl+0x46/0x60
> [<c0102909>] syscall_call+0x7/0xb

And there you go, without a mode change (KD_GRAPHICS->KD_TEXT),
the console thinks a set_var/set_par is unnecessary.  This triggers
the bug (ouch).

> cyblafb: Switching to new mode: fbset -g 1280 1024 1280 2662 8 -t 7407 
> 232 16 39 0 160 3
> redraw_screen: called with is_switch 0 and vc->vc_mode 0
> ******** Now logged in as root on tty1
> redraw_screen: called with is_switch 1 and vc->vc_mode 1
> ******** switched to xterm

At this point, everything works. In this case, X is active, so
vc->vc_mode is correctly set to KD_GRAPHICS.. .

> redraw_screen: called with is_switch 1 and vc->vc_mode 0

... and when it switches to KD_TEXT, the kernel detects the change,...

> cyblafb: Switching to new mode: fbset -g 1280 1024 1280 2662 8 -t 7407 
> 232 16 39 0 160 3

...calls set_var()/set_par...

> redraw_screen: called with is_switch 0 and vc->vc_mode 0
> ******** switched back to tty1
> 

...and the driver happily draws to the screen. No bug. 

I believe, from here on, everything will work as expected.

So it seems that when kdm loads the first time, it failed to set the
mode to KD_GRAPHICS which triggered the bug. Maybe it's a bug in
kdm then?

Tony 


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: BUG: fb_imageblit called before fb_check_var and fb_set_par function

[Knut Petersen]

Hi Antonino,

> ...and the driver happily draws to the screen. No bug.
> I believe, from here on, everything will work as expected.
>
> So it seems that when kdm loads the first time, it failed to set the
> mode to KD_GRAPHICS which triggered the bug. Maybe it's a bug in
> kdm then?

Well, it might be a kdm bug, but that bug is widely spread then. SuSE 
9.2 and Debian Sarge
are affected at least. I would call it a kernel design flaw / bug if we 
allow this kind of
situation to happen. But why does this happen only if kdm is started 
early? This question
must be answered. Even if the answer is that kdm does something wrong, 
it would be
a good idea to call e.g. *fb_set_par() unconditionally for every console 
switch ...

cu,
 Knut


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: BUG: fb_imageblit called before fb_check_var and fb_set_par function

[Antonino A. Daplas]

Knut Petersen wrote:
> Hi Antonino,
> 
>> ...and the driver happily draws to the screen. No bug.
>> I believe, from here on, everything will work as expected.
>>
>> So it seems that when kdm loads the first time, it failed to set the
>> mode to KD_GRAPHICS which triggered the bug. Maybe it's a bug in
>> kdm then?
> 
> Well, it might be a kdm bug, but that bug is widely spread then. SuSE 
> 9.2 and Debian Sarge
> are affected at least. I would call it a kernel design flaw / bug if we 
> allow this kind of
> situation to happen.

Well, that's why X runs as root, and the kernel will practically do anything
for root.
 
>  But why does this happen only if kdm is started early?

I don't know. The kdm I in suse 9.0 seems not to exhibit this behavior.

> This question
> must be answered. Even if the answer is that kdm does something wrong, 
> it would be
> a good idea to call e.g. *fb_set_par() unconditionally for every console 
> switch ...

This has been discussed before.  Not all hardware can do a set_par()
instantaneously, some may require seconds.  And that will become a usability
problem. Just imagine switching from one console to another and it takes
5 seconds.

Tony



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: BUG: fb_imageblit called before fb_check_var and fb_set_par function

[Knut Petersen]

> This has been discussed before.  Not all hardware can do a set_par()
> instantaneously, some may require seconds.  And that will become a 
> usability
> problem. Just imagine switching from one console to another and it takes
> 5 seconds.

That would be unacceptable, agreed. But it´s also not really acceptable 
to risk to execute a few
dozend imageblits in redraw_screen() while the hardware might be in an 
unusable state. Checking
for that situation every imageblit would have a big performance penalty.

knut


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: BUG: fb_imageblit called before fb_check_var and fb_set_par function

[Antonino A. Daplas]

Knut Petersen wrote:
> 
>> This has been discussed before.  Not all hardware can do a set_par()
>> instantaneously, some may require seconds.  And that will become a 
>> usability
>> problem. Just imagine switching from one console to another and it takes
>> 5 seconds.
> 
> That would be unacceptable, agreed. But it´s also not really acceptable 
> to risk to execute a few
> dozend imageblits in redraw_screen() while the hardware might be in an 
> unusable state.

It doesn't. but it depends what you mean by unusable state. In the
console/fbcon/fbdev subsystem an unusable state can be any of the ff:

	- KD_GRAPHICS mode
	- between coming from KD_GRAPHICS to KD_TEXT and before set_par()
	- graphics device in a suspended state 

If any the above are true, no drawing functions gets called.

> Checking
> for that situation every imageblit would have a big performance penalty.
> 

Maybe. I've measured this before, you lose something like 3-5%.  Hardly
noticeable in real-world usage. So I would gladly sacrifice a little
performance for stability. Doing a set_par() for each switch, in turn,
will be noticeable and is a great blow to usability.  It really boils down
to a balance between usability, stability and performance.  Throw in code
readability and maintainability also.

(Note: In the case of a bug in an app that runs as root, I think everyone will
agree that the bug must be fixed in the app, not the kernel.)

(Note 2: Even with those checks in place, the 2.6 framebuffer system is still
faster than 2.4)

Tony


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf