iwm(4): Also reset sc_uc.uc_intr flag on 8000 hw. Gets rid of 1s tsleep.

Hi, The sc->sc_uc.uc_intr flag isn't getting reset to 0 in iwm_load_firmware_8000(), so the /* wait for the firmware to load */ for (w = 0; !sc->sc_uc.uc_intr && w < 10; w++) { err = tsleep(&sc->sc_uc, 0, "iwmuc", hz/10); } loop is immediately aborting on AC

iwm(4): Improve iwm_rx_addbuf() error handling.

Hi, This patch improves the error handling iwm_rx_addbuf(), specifically in out-of-memory and mbuf exhaustion cases. Keep an additional/spare bus_dmamap_t object around to make error handling for bus_dmamap_load_mbuf() failures easier in iwm_rx_addbuf(). This seems like an easy way to avoid having

iwm(4): iwm_firmware_load_chunk returns uninitialized error value.

Hi, The iwm_firmware_load_chunk() function returns the value of the uninitialized int error variable, when the "while (!sc->sc_fw_chunk_done)" loop terminates immediately. I saw this happen repeatedly in the init firmware loading during bootup. Example log output with iwm compiled with debugging ou

iwm(4): Fix iwm_poll_bit() error value check in iwm_attach().

The iwm_poll_bit() function in iwm(4) returns 1 on success, and 0 on failure. So instead of "if (ret < 0) {" we should check for "if (!ret) {". Index: sys/dev/pci/if_iwm.c === RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v retrieving revis

iwm(4): Fix off-by-one error in a range check in iwm_read_firmware().

This fixes an off-by-one error in the "if (idx > howmany(IWM_NUM_UCODE_TLV_CAPA, 32))" range check. Since IWM_NUM_UCODE_TLV_CAPA is defined as 128, for an idx value of 4, we would potentially try to set bits 159..128 in the sc->sc_enabled_capa bitmap (which is just IWM_NUM_UCODE_TLV_CAPA bits long)

iwm(4): Use htole16 for policy field in iwm_time_event_cmd_v2 struct.

Hi, The policy field in struct iwm_time_event_cmd_v2 is just a 16bit integer, so we should use htole16() when setting it, instead of htole32(). Index: sys/dev/pci/if_iwm.c === RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v retrieving revis

iwm(4): Use uint32_t instead of enum type in __packed struct iwm_sf_cfg_cmd.

Hi, Although this doesn't seem to cause any issue at the moment, using an enum type in a __packed struct should be avoided: Index: sys/dev/pci/if_iwmreg.h === RCS file: /cvs/src/sys/dev/pci/if_iwmreg.h,v retrieving revision 1.14 diff

iwm(4): gc struct iwm_rbuf and the wantresp field in struct iwm_rx_data.

Hi, The struct iwm_rbuf definition, and the wantresp field in struct iwm_rx_data aren't used anywhere and can be removed: Index: sys/dev/pci/if_iwmvar.h === RCS file: /cvs/src/sys/dev/pci/if_iwmvar.h,v retrieving revision 1.19 diff -

iwm(4): Add missing iwm_free_rx_ring(). Free nvm_sections[i].data buffers.

Hi, After parsing the nvm_sections data in iwm_nvm_init(), we can free the nvm_sections[i].data allocations again. In the iwm_attach() failure path, the iwm_free_rx_ring() call for freeing the rx ring memory was missing. Index: if_iwm.c ===

iwm(4): Add support for Intel Wireless 3165

Hi, This adds support for the AC 3165 Intel wireless chipset. Tested on a HP x2 210 tablet/detachable: iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless AC 3165" rev 0x81, msi iwm0: hw rev 0x210, fw ver 16.242414.0, address e0:94:67:bf:6f:76 Index: sys/dev/pci/if_iwm.c

iwm(4): The valid_{rx,tx}_ant values only be read from nvm for 8000 family

Hi, We only need to set the data->valid_tx_ant and data->valid_rx_ant values in iwm_parse_nvm_data() for the 8000 family chips. This matches what iwl_set_radio_cfg() in iwl-nvm-parse.c from Linux's iwlwifi does. Also the "if (!data->valid_tx_ant || !data->valid_rx_ant) {" check should be removed

Fix for a possible ahci issue on intel skylake hardware

For us, this patch fixed ahci getting stuck during high disk-IO load (mainly writes) from at least 2 threads in parallel. We can reproduce this on a Skylake notebook with a single SSD disk, but running openbsd within a custom virtualization solution. However, I so far failed to reproduce this is

Fix IWM_MAX_CMD_PAYLOAD_SIZE in iwm(4)

In iwm(4), IWM_MAX_PAYLOAD_SIZE needs to be at least one byte smaller. "IWM_MAX_CMD_PAYLOAD_SIZE + sizeof(struct iwm_cmdheader)" must be smaller than 4096, otherwise the payload length could get truncated to 0 in this assignment from iwm_send_cmd(), because 4096 doesn't fit into 12 bits:

Re: Better de(4) fix

On 22:27 Thu 25 Jun , Reyk Floeter wrote: > On Thu, Jun 25, 2015 at 09:21:11PM +0200, Mark Kettenis wrote: > > There really is no excuse for using dma_alloc(9) if you have the > > bus_dmatag_t available. > > > > This re-uses tulip_busdma_allocmem(), which simplifies the code for > > allocating the

acpi(4) Implicit _GL object should be named _GL_

Since aml_parsename calls __aml_search (and not __aml_searchname), no automatic padding with '_' is done on the names in aml_defobj. So we should also pad _GL correctly, otherwise we are creating a node which can't be found (since we would be searching for the node _GL_). Found this when trying out

Re: radeondrm errors (amd64) - Hoping bad things won't really happen

On 06:00 Sun 22 Feb , Jonathan Gray wrote: > On Sat, Feb 21, 2015 at 06:29:53PM +0100, Imre Vadasz wrote: > > > drm: initializing kernel modesetting (RS690 0x1002:0x791E 0x1458:0xD000). > > > radeondrm0: VRAM: 128M 0x7800 - 0x7FFF (128M used) > &

Re: radeondrm errors (amd64) - Hoping bad things won't really happen

> drm: initializing kernel modesetting (RS690 0x1002:0x791E 0x1458:0xD000). > radeondrm0: VRAM: 128M 0x7800 - 0x7FFF (128M used) > radeondrm0: GTT: 512M 0x8000 - 0x9FFF > drm: PCIE GART of 512M enabled (table at 0x052B1000). > error: [drm:pid0