On 2013-08-23, Hugo Osvaldo Barrera <h...@osvaldobarrera.com.ar> wrote:
> On 2013-08-23 17:43, Stuart Henderson wrote:
>> On 2013-08-23, Hugo Osvaldo Barrera <h...@osvaldobarrera.com.ar> wrote:
>> > When I conect my PC to the server, I see BIOS and POST output properly,
>> > I then see the OpenBSD bootloader properly, and all the kernel messages
>> > come
>> > out fine (ie: the white-on-blue text), however, AFTER the kernel messages,
>> > I only see the following sixteen characters and nothing else (though
>> > later kernel messages like plugging in a USB are shown properly).
>> >
>> > In single user mode, this would be:
>> > "Enter pathname o"
>> >
>> > In non-single user mode, this would be
>> > "Automatic boot i"
>> >
>> > It's extremely odd. I'm cleary not having cable issues, wrong rates,
>> > or anything alike, because I'm seeing kernel output just fine.
>>
>> This is exactly what you would see if the IRQ assignment is wrong.
>> There are other possibilities too, but this is easy to check in the
>> BIOS, and is a somewhat likely problem.
>>
>> The first port (known as com0 in OpenBSD, com1 in MSDOS) should be at
>> 0x3f8 irq 4, the second should be 0x2f8 irq 3. Sometimes vendors
>> (I've seen it with Jetway) have been known to screw up and reverse
>> the irq assignments.
>
> Ah, thanks! I had checked that 0x3f8 was being used, but the irqs were
> mixed up (ie: they were swapped).
>
> Oddly I'm not seeing the first bit of the bootloader any more ("Using
> drive 0, partition 3..."), but I *am* seeing the important part which
> is the prompt for a boot commands.
>
> I'm curious though; why were kernel outputs being outputted
> properly? Shouldn't those have failed to display as well?
This may not be 100% correct but I think it's not far off (corrections
welcome): interrupts are off during the earlier printfs so the serial
port is driven in polling mode instead. When interrupts are enabled we
start sending a buffer full at once and wait for a completion interrupt,
which never comes (or at least never comes on the correct irq line).
When I first ran into this, I discovered what the problem was after
noticing that input on the *other* serial port made it start printing
more...
> > Some other OS take these from ISAPNP but OpenBSD hardcodes the
> > standard values for a PC-compatible machine and expects the port to
> > be there.
hmm, sorry, think-o: that should be s/ISAPNP/ACPI/...
> Why doesn't OpenBSD attempt to do this as well? Is there some reason to
> avoid that, or is it simply because nobody's gotten around to it?
Not really my area but my take on it is that it's overcomplicated, and
it's not going to be fully useful for the system console anyway because
we need to know at least the address of the uart well before acpi tables
are read.
