From: Knut Petersen <Knut_Petersen@t-online.de>
To: linux-fbdev-devel@lists.sourceforge.net
Cc: "Antonino A. Daplas" <adaplas@gmail.com>,
Andrew Morton <akpm@osdl.org>,
benh@kernel.crashing.org
Subject: Re: BUG: fb_imageblit called before fb_check_var and fb_set_par function
Date: Fri, 26 Aug 2005 10:23:26 +0200 [thread overview]
Message-ID: <430ED17E.6000504@t-online.de> (raw)
In-Reply-To: <430E094A.9030603@gmail.com>
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
next prev parent reply other threads:[~2005-08-26 8:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-25 12:26 BUG: fb_imageblit called before fb_check_var and fb_set_par function Knut Petersen
2005-08-25 14:05 ` Antonino A. Daplas
2005-08-25 15:59 ` Knut Petersen
2005-08-25 18:09 ` Antonino A. Daplas
2005-08-26 8:23 ` Knut Petersen [this message]
2005-08-26 14:01 ` Antonino A. Daplas
2005-08-26 16:30 ` Knut Petersen
2005-08-26 17:00 ` Antonino A. Daplas
2005-08-26 18:21 ` Knut Petersen
2005-08-27 0:36 ` Antonino A. Daplas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=430ED17E.6000504@t-online.de \
--to=knut_petersen@t-online.de \
--cc=adaplas@gmail.com \
--cc=akpm@osdl.org \
--cc=benh@kernel.crashing.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.