Re: QVSS driver and kernel autoconf

[Charles Dickman <chd%chdickman.com@localhost>]

I got sidetracked by a kernel panic that I still can't completely explain.

Kernel option DEBUG is turned on, so there is a little more checking
going on. One of the checks in uvm_map() is that the system page table
entries used in the kernel memory map are not already pointing at
something. The check is in uvm_km_check_empty() where a range of
virtual address are check to see if they are already mapped in the
system page table. This check failed consistently.

Tracing backwards, I found that there was garbage in the system page
table at a consistent physical address 0x002FF380. This is supposed to
be cleared by a memset() in pmap_bootstrap() in vax/pmap.c I added
some halts to pmap_bootstrap() and saw the garbage even after the
memset.

Here's the weird part: If I put a halt before the call to memset()
then memset will clear the garbage, but if I only have a halt after
the call, the garbage is still there after the call and the kernel
panics. I do not understand this.

On the other hand, when it does work, I get eight wscons using genfb,
but all the characters on the screen are backwards. The font genfb
chooses must have the bit ordering swapped from the hardware frame
buffer.

-chuck


On Thu, Feb 5, 2015 at 9:01 AM, David Brownlee <abs%absd.org@localhost> wrote:
> On 26 January 2015 at 00:02, Charles Dickman <chd%chdickman.com@localhost> wrote:
>> Is there a good discussion of the kernel autoconf process somewhere? I
>> can't seem to figure out how to get config and the kernel to do what I
>> want it to do.
>>
>> The qv has 3 parts: frame buffer, dual serial port, and increment mouse port.
>>
>> I was trying for something like:
>>
>> qv* at uba? csr 177400
>> qvfb* at qv?
>> qvaux* at qv?
>> qvmouse* at qv?
>>
>> but I couldn't get it to work.
>>
>> I ended up with
>>
>> qv* at uba? csr 177400
>> qvaux* at uba? csr 177420
>>
>> and no hardware mouse. qv and qvaux are kind of intermixed which I don't like.
>>
>> According to the manuals for config, devices can only attach at
>> interface attributes. How do I create an interface attribute? I think
>> that { } makes an attribute an interface attribute.
>>
>> Here is what I have added to files.vax:
>>
>> # Monochrome QVSS framebuffer on qbus (VCB01)
>> device  qvaux { line=-1 }: tty
>> attach  qvaux at uba
>> file    arch/vax/uba/qvaux.c            qvaux needs-flag
>>
>> device qv: displaydev, wsdisplaydev
>> attach  qv at uba
>> file    arch/vax/uba/qv.c               qv  needs-flag
>> file    arch/vax/uba/qv_ic.c            qv | qvaux
>>
>> This works, but there is something about splitting the QVSS into two
>> devices that doesn't set right. Especially since the interrupt
>> controller is shared and so it has to be initialized independent of
>> which half is first or even if the other half is ever attached to.
>>
>> What I am going to try next is:
>>
>> device qv {}:
>> attach qv at uba
>>
>> device qvfb: displaydev, wsdisplaydev
>> attach qvfb at qv
>>
>> device qvaux { line=-1 }: tty
>> attach qvaux at qv
>>
>> I have tried to follow autoconf and I get lost in twisty passages.
>>
>> I want to have genfb attach to qvfb. When wscons is attached qv using
>> code from smg, the display is 128 x 57 characters and is pretty small.
>> I was hoping that genfb would give more options.
>
> Did you have any luck with this?
>
> Showing some serendipitous timing, on the day before you emailed this
> a nice vt220-alike console font was committed to the tree
>
> http://mail-index.netbsd.org/source-changes/2015/01/25/msg062660.html :)