>same issue with cfag12864bfb. behaviour is a little bit different, but 
>console is also unusable afterwards.
confirmed by the author. he thinks this could have been introduced by frambuffer api change and investigates into the problem.

i found that console can be restored with vga16fb

just curious why mdacon is detecting MDA hardware when there is no such:

mdacon: MDA with 8K of memory detected.

there are others, who have had issues:
https://bugzilla.novell.com/show_bug.cgi?id=224522
http://www.ussg.iu.edu/hypermail/linux/kernel/0411.1/1998.html


minor, tough - but everytime i`m testing kernel modules i step into that trap that the module detects something, which isn`t there...

interesting - i found that this driver is meant to be used only for a second card:


config MDA_CONSOLE
        depends on !M68K && !PARISC && ISA
        tristate "MDA text console (dual-headed) (EXPERIMENTAL)"
        ---help---
          Say Y here if you have an old MDA or monochrome Hercules graphics
          adapter in your system acting as a second head ( = video card). You
          will then be able to use two monitors with your Linux system. Do not
          say Y here if your MDA card is the primary card in your system; the
          normal VGA driver will handle it.

          To compile this driver as a module, choose M here: the
          module will be called mdacon.

          If unsure, say N.


so - if mdacon is meant for a second, additional card, why does it touch the the primary, especially if a second card isn`t there at all... ?

seems, this change from Edward Betts in year 2000 is causing the problem:

if i remove those ifdefs, modprobe mdacon returns with "mdacon: MDA card not detected." - as it should

#ifdef TEST_MDA_B
        /* Edward: These two mess `tests' mess up my cursor on bootup */

        /* cursor low register */
        if (! test_mda_b(0x66, 0x0f)) {
                return 0;
        }

        /* cursor low register */
        if (! test_mda_b(0x99, 0x0f)) {
                return 0;
        }
#endif

the following mail has been send to lkml.
no reply so far - so i`m putting it here (including the patch) so it won´t get lost.

> -----Ursprüngliche Nachricht-----
> Von: devzero@web.de
> Gesendet: 03.05.08 22:09:25
> An: Linux-fbdev-devel@lists.sourceforge.net,linux-kernel@vger.kernel.org
> CC:
> jsimmons@infradead.org,adaplas@gmail.com,alan@lxorguk.ukuu.org.uk,matan@svgalib.org,
> edward@debian.org, Soeren Sonnenburg <kernel@nn7.de>
> Betreff: [PATCH] mdacon messing up default vc's, set default to vc13-16 again

> mdacon incorrectly detects MDA hardware on systems without such graphics
> card.
> 
> one may load this module by chance, for example when doing some systematical 
> module-testing, and if there is no Monochrome Display Adapter attached ,
> module init 
> renders vc1-16 completely unusable. 
> 
> me and others have run into this more than once. see [Bug 224522 - modprobe
> mdacon 
> freezes machine -> https://bugzilla.novell.com/show_bug.cgi?id=224522 ] for
> example
> 
> apparently, proper MDA detection seems to be broken for a long time - seems
> to be 
> related to those #ifdef TEST_MDA_B statements added by Edward Betts.
> 
> this commit back in 2002 made things even worse :
>
> http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commit;h=c72757b49c88914433244757fb4967fc63546685
>  
> it changed default vc allocation from 13-16 to 1-16  for no apparent reason
> (!?) , and 
> with that (and without X), mdacon grabs the vc you`re currently sitting on
> and locks you out.
> 
> this is from Kconfig :
> >config MDA_CONSOLE
> >        depends on !M68K && !PARISC && ISA
> >        tristate "MDA text console (dual-headed) (EXPERIMENTAL)"
> >        ---help---
> >          Say Y here if you have an old MDA or monochrome Hercules graphics
> >          adapter in your system acting as a second head ( = video card).
> You
> >          will then be able to use two monitors with your Linux system. Do
> not
> >          say Y here if your MDA card is the primary card in your system;
> the
> >          normal VGA driver will handle it.
> 
> As we can see mdacon is just meant as an additional driver for dual-head
> setup, 
> and since kernel 2.4.36 still defaults to vc13-16 ,  setting the default back
> to that value 
> again shouldn`t  do any harm. 
> 
> hereby i`m reverting that change, setting default back to to vc13-16 again.
> 
> Besides the fact that mdacon may be rarely or never be used these days and
> could 
> perhaps put to trash anyway (pre-dinosaur hardware!), indeed this is not a
> real solution,  
> but at least it removes the unfortunate side-effect of messing up the vc
> you`re working on.
> 
> 
> Signed-off-by: Roland Kletzing <devzero@web.de>
> 
> --- drivers/video/console/mdacon.c.orig 2008-05-03 15:47:20.000000000 +0200
> +++ drivers/video/console/mdacon.c      2008-05-03 15:55:27.000000000 +0200
> @@ -71,13 +71,15 @@
> 
>  /* console information */
> 
> -static int     mda_first_vc = 1;
> +static int     mda_first_vc = 13;
>  static int     mda_last_vc  = 16;
> 
>  static struct vc_data  *mda_display_fg = NULL;
> 
>  module_param(mda_first_vc, int, 0);
> +MODULE_PARM_DESC(mda_first_vc, "First virtual console. Default: 13");
>  module_param(mda_last_vc, int, 0);
> +MODULE_PARM_DESC(mda_last_vc, "Last virtual console. Default: 16");
> 
>  /* MDA register values
>   */
> 

Created attachment 16021 [details]
[PATCH] mdacon messing up default vc's, set default to vc13-16 again

it`s in -mm now:

http://userweb.kernel.org/~akpm/mmotm/broken-out/mdacon-messing-up-default-vcs-set-default-to-vc13-16-again.patch

Great, thanks Roland. Closing the bug.

wouldn`t it make sense to leave that open until the patch being merged in mainline ? (to track merging)

it`s quite a while in -mm now - i wonder how long it will stay there....

Hmm, this is ok if it's in -mm I think. Requirements for regressions are stricter, but for the regular priority bugs it should be fine. However, this is your choice Roland, you can definitely keep it open if you feel this way it will be better tracking for the bug.