Page MenuHomeFreeBSD

Handle misconfigured/noexistent pcidev for comconsole instead of BTX panic
ClosedPublic

Authored by sbruno on Jan 5 2018, 7:14 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Dec 14, 6:43 PM
Unknown Object (File)
Wed, Dec 4, 10:53 PM
Unknown Object (File)
Nov 21 2024, 6:53 AM
Unknown Object (File)
Oct 30 2024, 10:35 AM
Unknown Object (File)
Oct 29 2024, 1:11 PM
Unknown Object (File)
Sep 28 2024, 7:58 AM
Unknown Object (File)
Sep 25 2024, 8:55 PM
Unknown Object (File)
Sep 24 2024, 4:28 PM
Subscribers
None

Details

Test Plan

Tested on AMT host with working comconsole_pcidev setting and host with physical RS-232 com port:

console="comconsole"
comconsole_speed="115200"
comconsole_pcidev="0:22:3"

No change to working AMT host.
Real serial no longer explodes in BTX and emits useable errors:

Consoles: serial port  
BIOS drive C: is disk0

PXE version 2.1, real mode entry point @98d1:0106
BIOS 632kB/3134016kB available memory

FreeBSD/x86 bootstrap loader, Revision 1.1
(Sat Dec 16 11:20:40 MST 2017 sbruno@lab)
Loading /boot/defaults/loader.conf
Cannot find specified pcidev
Warning: bad definition on file /boot/loader.conf
comconsole_pcidev="0:22:3"

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 14141
Build 14314: arc lint + arc unit

Event Timeline

This revision is now accepted and ready to land.Jan 5 2018, 7:24 PM

Good sleuthing!

stand/i386/libi386/comconsole.c
270

Newline before comment. I would perhaps adjust the comment to say something like "biospci_read_config() returns 0xffffffff for PCI devices that aren't present". It's also slightly better to compare against 0xffffffff. The -1 just happens to work by accident in this case. (If we were reading a 2 byte config register then you would only get 0xffff for example, and someone might use this as a reference for something else someday)

Check against 0xffffffff instead of -1.

Flush out comments to be a bit more precise.

This revision now requires review to proceed.Jan 5 2018, 8:12 PM

Updated for comments and tested to validate functional AMT console and functional serial console. All looks good from here.

Looks good to me.

Though the more I think about it, how the heck did biospci_read_config find a config entry at all to extract the port info from the BAR?

This revision is now accepted and ready to land.Jan 5 2018, 8:25 PM
In D13776#288516, @imp wrote:

Looks good to me.

Though the more I think about it, how the heck did biospci_read_config find a config entry at all to extract the port info from the BAR?

That question crossed my mind. :-)

biospci_readconfig() doesn't look for a matching entry, it just invokes a BIOS routine that probably just translates the register arguments into the right values for writing to 0xcf8 and reading from 0xcfc.

In D13776#288529, @jhb wrote:

biospci_readconfig() doesn't look for a matching entry, it just invokes a BIOS routine that probably just translates the register arguments into the right values for writing to 0xcf8 and reading from 0xcfc.

Gotcha. It's not looking for a valid BAR, it's just doing what it's told. Adding the check for 0xffffffff is the special case where the hardware isn't even there.

Another question, why are we passing '2' there to read a two byte quantity for the width parameter for biospci_read_config? And if so, why did Sean's testing show that this code works testing against 0xffffffff which is 4 bytes?

Ah, looking at the biospci_read_config code I see that its 0 for 1 byte, 1 for 2 bytes, 2 for 4 bytes based on the opcode sent to the BIOS. n/m about that question.

This revision was automatically updated to reflect the committed changes.