Re: Problem with Intel WiFi card

["John D. Baker" <jdbaker%mylinuxisp.com@localhost>]

On Fri, 10 Feb 2017, Rocky Hotas wrote:

> > Sent: Thursday, February 09, 2017 at 9:24 PM
> > From: "John D. Baker" <jdbaker%mylinuxisp.com@localhost>
> >
> > After following this thread, I didn't see one particular item
> > mentioed. Does the affected machine's BIOS have a "Plug'n'Play OS"
> > setting? If so, I have found that on such machines, it should be
> > set to "No" for NetBSD.

> I checked all the BIOS entries and no, that setting is not present.

None of the ones you mentioned for yours seem to be related.

Just to provide my own counter-example, the closest machine to hand (an
HP Pavilion dv2000 laptop w/PhoenixBIOS) doesn't have such a setting
either.  Nor does my ThinkPad T42, IBM eServer x306, Dell Optiplex 760,
Optiplex GX260 or Optiplex GX110 . 

Of machines I can check easily, Intel D946GZIS and D845EBG2 boards have
a "Plug & Play O/S" setting under the "Boot" section.  An ancient Sony
VAIO (PCG-9401) has this setting under the "Advanced" section.

Past experience with other machines which had this setting had me set
it to "No" before ever trying to boot it with NetBSD.  The Intel D845EBG2
board's help for this item describes it plainly.  Setting to "No" causes
the BIOS to configure all PCI devices (a proper PCI BIOS).  Setting to
"Yes" configures only those devices needed to boot and assumes the OS
will configure anything else.

> > I've also seen similar issues on a machine that had previously booted
> > Linux. A subsequent boot of NetBSD would encounter similar problems,
> > usually with network hardware.
> 
> This machine had Linux before, but with the NetBSD installation I
> erased all the hard disk contents, so I don't think it matters what
> was the previous OS.

In the case of the machines I worked with, the act of booting Linux left
the machines in a state where a subsequent boot of NetBSD would produce
a "can't map i/o space" or "can't map mem space" message for one or more
devices--usually an ethernet interface.

It persisted across power-cycles, so it was something Linux did to the
battery-backed BIOS settings.  On these machines, resetting to BIOS
defaults was the simplest solution as I didn't have time to research
it (machines used in a classroom environment).

> > I suspect the same setting, if available, will correct that although
> > at the time our workaround was to reset to BIOS defaults (or reset
> > ESC data if the option is available). Just my $0.02.
> 
> Sorry, what do you mean by "reset ESC data"?  Being this BIOS maybe
> different than yours, I don't know if a reset to defaults would be
> useful.

The "Reset ESC data" or "ESCD Reset" or "Reset Configuration Data" option
was something some machines' BIOSes had.  "ESCD" is "Extended System
Configuration Data".  I think it saved PCI configuration data in some
non-volatile memory and would restore device configuration to that.  I
have an IBM eServer x306 which has a "Reset Configuration Data" option.
IIRC, an HP Pavilion "Lomita" has an "ESCD Reset" option.

When I'd run into such a machine, I recall having similar failures unless
I chose this option in the BIOS setup before the next boot.  It defaults
to "No" and although it's presented as a "Yes/No" option, when set to
"Yes", it resets the data upon exiting BIOS Setup and will again default
to "No" the next time BIOS Setup is entered.


Regardless of BIOS differences, performing a "Reset to defaults" operation
and then choosing preferred settings may still be a useful exercise.

Otherwise, you may have a machine that only works for its redmond masters.

-- 
|/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645