OpenBSD Journal

t2k19 Hackathon Report: Stefan Sperling on 802.11? progress, suspend/resume and more

Contributed by Peter N. M. Hansteen on from the a better wakeup in the east dept.

A new hackathon report has arrived, this time from Stefan Sperling (stsp@), who writes:

This hackathon was an exceptional opportunity for several developers involved in 802.11 wireless to meet face to face. I spent a lot of time collaborating with Kevin Lo and Jonathan Matthew throughout the week.

The three of us kicked the hackathon off with a refresher on how the 802.11n feature set extends upon 11a/b/g, which parts are covered by our current implementation, and what needs to be done to add 11n support to a wifi device driver. We also discussed plans for 11n Tx aggregation and wide channel support, both of which are needed for a full 11n implementation. When the realization that everyone else had long disappeared for lunch finally hit us, we did the same.

Kevin guided us on several visits to sites in Taipei and provided helpful assistance with navigating local shops in search of fancy laptops and wifi gadgets. Taipei being such a great place for buying hardware, throughout the week we swapped several unsupported USB and miniPCI wifi devices amongst ourselves so we can easily help each other should one of us decide to start writing a driver for them.

With OKs for wifi diffs being relatively easy to come by in this hackroom, I first committed a fix for A-MPDU verification in the net80211 input path which I had already written before the hackathon but which hadn't received any OKs yet.

I then spent an afternoon debugging an issue with an athn(4) device Kevin had brought along.

This device should have already been working but was failing to attach with an EEPROM checksum error. I first cross-checked our firmware checksum calculation code with Linux and it seemed to be correct. Digging further I found out the driver was reading EEPROM data from the wrong offset. AR9287 devices have different EEPROM offsets depending on whether they are attached over PCI or USB, and our driver was only handling the PCI case.

With that fixed, Kevin's device could successfully associate and move packets. Kevin promptly fixed another problem to make the device's LED work as expected, as there is another small difference how GPIO pins are wired up between PCI and USB devices.

Taking a detour from wifi I spent a couple of days trying to complete a work-in-progress patch by Ben Pye aiming to get suspend and resume working with the root filesystem on emmc devices.

The essential problem which needed solving was this: Upon resume, the root filesystem backed by sdmmc(4) storage got detached, and consequently the init(8) process died, which then caused a kernel panic.

I unsuccessfully tried to get Ben's patch working on my tiny King Jim laptop, which has the caveat that it cannot suspend (i.e. enter ACPI S3 state).

However, it does hibernate to disk (i.e. enter ACPI S4 state), so that's what I tried to get working.

Eventually, after 3 days of frustration and with help from 3 experts (deraadt@, kettenis@, and mlarkin@) on relevant topics, I ended up with a proof-of-concept diff which deleted 3 lines of code to make things work.

Simply skipping the entire suspend/resume logic in the sdmmc(4) layer allowed my laptop to come back from hibernation in operational state. The hardware is powered down during hibernation, and the kernel which boots the machine will initialize the emmc storage device, retrieve the hibernated kernel image stored there, and then jump into the restored kernel image.

The waking kernel will find the emmc device fully operational and won't have to do anything further to start sending commands for block transfers.

Of course, we will only want to skip the suspend/resume logic if an SD card is in fact a non-removable device. Mark Kettenis helpfully pointed me at ACPI support code which was already detecting non-removable devices in sdhc(4), so I could simply add a new flag and pass it from sdhc(4) to sdmmc(4) to make hibernate work on systems with the root filesystem on emmc storage without breaking other cases.

I rounded off my trip by visiting Taipei's Zoo, where the plant life is just as impressive as the various kinds of Koalas and Panda bears.

Thanks to Kevin Lo and the OpenBSD Foundation for hosting a great hackathon!

Thanks Stefan!

(Comments are closed)

  1. By BadMojo (badmojo) on

    Did the suspend/resume emmc support make it into 6.5?

    1. By Stefan Sperling (stsp) on

      Yes it did.


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]