Synopsis #
Laptop suitability depends on behavior, not merely on a successful boot. Wireless attachment, association, throughput, suspend, resume, graphics restoration, battery reporting, and lid behavior are separate tests. A chipset listed in release hardware notes may still have feature or performance limits that matter to the intended workload.
Complete the hardware preflight
and configure the correct graphics driver
before treating suspend results as final. Kernel modesetting is part of the documented suspend/resume path for modern graphics with the vt console.
Identify the wireless device and driver #
Record the PCI network devices, available interfaces, and wireless parent devices:
$ pciconf -lv | grep -A1 -B3 network
$ ifconfig -l
$ sysctl net.wlan.devices
The text before @ in pciconf output is the attached driver. Compare the numeric device identifiers and driver manual page with the hardware notes for the installed release. Do not infer support from another chipset sold under the same laptop model.
If pciconf lists the wireless controller but net.wlan.devices is empty, inspect boot messages and loaded modules:
$ dmesg | grep -Ei 'wlan|wifi|802\.11|firmware|iwl|iwm|iwx|ath|rtw|rtwn'
$ kldstat
Resolve missing driver or firmware attachment before changing WPA configuration.
Separate association from IP configuration #
List the configured wireless interface and its status:
$ ifconfig wlan0
If wlan0 does not exist, follow the current FreeBSD network chapter for the actual parent driver. The wlans_ setting is driver-specific; copying an interface name from another machine will not attach the correct device.
After the interface exists, scan from a permitted test location:
# ifconfig wlan0 up list scan
Test in this order:
- The intended access point appears on its actual band and channel.
wpa_supplicantassociates using the intended security mode.- DHCP or static addressing completes.
- The default route and DNS work.
- Sustained traffic is adequate for the intended workload.
An IP failure after successful association is not a radio-driver failure. An absent 5 GHz or 6 GHz network may reflect channel, regulatory-domain, or driver capability rather than a wrong password.
Set the correct country and regulatory domain according to the official network procedure. This is a legal and radio-operational setting, not a throughput tuning shortcut.
Inspect power state without tuning it #
Check AC power, battery information, thermal state, and the current power daemon status:
$ sysctl hw.acpi.acline
$ acpiconf -i 0
$ sysctl dev.cpu | grep temperature
# service powerd status
Some systems expose temperature under different device trees, so an empty temperature result does not establish a sensor failure. Record idle behavior on AC and battery before adding power tunables.
Do not copy graphics power-management settings from another GPU generation. A lower reported idle number is not useful if the display, external connectors, or resume becomes unreliable.
Test suspend manually first #
List sleep states reported by ACPI:
$ sysctl hw.acpi.supported_sleep_state
FreeBSD does not support S4 hibernation. If S3 appears, save work, stop time-sensitive operations, and arrange for a forced power cycle to be recoverable. Test from a local console before relying on remote access:
# acpiconf -s 3
After resume, verify more than the screen:
$ date
$ ifconfig wlan0
$ cat /dev/sndstat
$ dmesg | tail -100
Also test keyboard, touchpad, audio playback and recording, external displays, storage, and USB devices. Repeat the cycle on AC power and battery. A single successful resume is useful evidence, not a reliability result.
Enable lid behavior only after repeated success #
Do not set hw.acpi.lid_switch_state to S3 until manual suspend and resume work repeatedly. Otherwise closing the lid can turn a diagnostic problem into an automatic failure on every use.
When manual tests are successful, follow the current FreeBSD power-management chapter to place the documented lid setting in /etc/sysctl.conf. The persistent settings guide
explains why a runtime sysctl belongs there.
Keep a record of the firmware version, FreeBSD release, graphics and wireless packages or modules, and every device that fails after resume. A resume failure after a release or package upgrade should be compared with that last known-working record.
Qualify the result #
Classify the laptop for the actual use case:
- Ready: required bands, authentication, throughput, battery reporting, and repeated suspend/resume work.
- Ready with a limitation: the limitation is explicit and has an acceptable operational workaround, such as wired networking at a dock.
- Not ready: a required component lacks a maintained driver or resume is unreliable enough to risk work.
- Untested: evidence is incomplete; do not relabel this as supported.
Bluetooth, fingerprint readers, cellular modems, docking stations, and vendor hotkeys deserve separate tests. Their presence in the chassis does not follow from wireless or ACPI support.