anand lalgondar asked;

> ctfb0 at pci0 dev 18 function 0
> PCI_COMMAND_STATUS_REG = 2a001c3
> PCI_COMMAND_STATUS_REG = 2a001c3
> : Chips and Technologies 69030 (rev. 0x61)
> ...
> After this message I assume that the ouput terminal will be redirected to 
> frambuffer, but it gets stuck. 
> ...

I expect the whole message, that is, what you see in /var/run/dmesg.boot
is redirected on display.

>   ctfb_common_init(sc);
>
>   /*
	 >    * XXX: console attachment needs rethinking
>    */
>   if (isconsole) {
		>       long defattr;
>       (*ri->ri_ops.allocattr)(ri, 0, 0, 0, &defattr);
>       wsdisplay_cnattach(&ctfb_stdscreen, ri, 0, 0, defattr);
> }

It's wrong to call wsdisplay_cnattach() there.  There is a reason
why ctfb_common_init() exists.   It should encapsulate whole
hardware initialization and WSCONS display subsystem binding
(I donno why ctfb_hw_setup(sc) exists separately).  The point
is this can be called in two ways.

1. If the graphics display was console, ABCcnattach() must be called
-before- configure() device emulation is started.  Later configure()
calls ctfb_pci_attach().  This time the device must notice console binding
has been already done.  It's the sole reason why isconsole variable exists.
2. If the display was -not- console, your ctfb_pci_attach() would be called
for the very first time initialization.  In this case malloc() API is available.

Toru Nishimura/ALKYL Technology