From: Greg Kroah-Hartman Date: Wed, 3 Jun 2015 05:29:30 +0000 (+0900) Subject: 4.0-stable patches X-Git-Tag: v3.10.80~6 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=6b63ef381dee78d5ce0faeafafeaeb4689978ae7;p=thirdparty%2Fkernel%2Fstable-queue.git 4.0-stable patches added patches: firmware-dmi_scan-fix-ordering-of-product_uuid.patch md-raid0-fix-restore-to-sector-variable-in-raid0_make_request.patch md-raid5-don-t-record-new-size-if-resize_stripes-fails.patch nfsd-blocklayout-pretend-we-can-send-deviceid-notifications.patch nfsd-fix-the-check-for-confirmed-openowner-in-nfs4_preprocess_stateid_op.patch revert-hid-logitech-hidpp-support-combo-keyboard-touchpad-tk820.patch svcrpc-fix-potential-gssx_accept_sec_context-decoding-failures.patch thermal-armada-update-armada-380-thermal-sensor-coefficients.patch --- diff --git a/queue-4.0/firmware-dmi_scan-fix-ordering-of-product_uuid.patch b/queue-4.0/firmware-dmi_scan-fix-ordering-of-product_uuid.patch new file mode 100644 index 00000000000..4f6c04144fd --- /dev/null +++ b/queue-4.0/firmware-dmi_scan-fix-ordering-of-product_uuid.patch @@ -0,0 +1,68 @@ +From 5c1ac56b51b9d222ab202dec1ac2f4215346129d Mon Sep 17 00:00:00 2001 +From: Jean Delvare +Date: Thu, 14 May 2015 14:40:50 +0200 +Subject: firmware: dmi_scan: Fix ordering of product_uuid + +From: Jean Delvare + +commit 5c1ac56b51b9d222ab202dec1ac2f4215346129d upstream. + +In function dmi_present(), dmi_walk_early() calls dmi_table(), which +calls dmi_decode(), which ultimately calls dmi_save_uuid(). This last +function makes a decision based on the value of global variable +dmi_ver. The problem is that this variable is set right _after_ +dmi_walk_early() returns. So dmi_save_uuid() always sees dmi_ver == 0 +regardless of the actual version implemented. + +This causes /sys/class/dmi/id/product_uuid to always use the old +ordering even on systems implementing DMI/SMBIOS 2.6 or later, which +should use the new ordering. + +This is broken since kernel v3.8 for legacy DMI implementations and +since kernel v3.10 for SMBIOS 2 implementations. SMBIOS 3 +implementations with the 64-bit entry point are not affected. + +The first breakage does not matter much as in practice legacy DMI +implementations are always for versions older than 2.6, which is when +the UUID ordering changed. The second breakage is more problematic as +it affects the vast majority of x86 systems manufactured since 2009. + +Signed-off-by: Jean Delvare +Fixes: 9f9c9cbb6057 ("drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists") +Fixes: 79bae42d51a5 ("dmi_scan: refactor dmi_scan_machine(), {smbios,dmi}_present()") +Acked-by: Zhenzhong Duan +Cc: Ben Hutchings +Cc: Artem Savkov +Cc: Ivan Khoronzhuk +Cc: Matt Fleming +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/firmware/dmi_scan.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +--- a/drivers/firmware/dmi_scan.c ++++ b/drivers/firmware/dmi_scan.c +@@ -499,18 +499,19 @@ static int __init dmi_present(const u8 * + buf += 16; + + if (memcmp(buf, "_DMI_", 5) == 0 && dmi_checksum(buf, 15)) { ++ if (smbios_ver) ++ dmi_ver = smbios_ver; ++ else ++ dmi_ver = (buf[14] & 0xF0) << 4 | (buf[14] & 0x0F); + dmi_num = get_unaligned_le16(buf + 12); + dmi_len = get_unaligned_le16(buf + 6); + dmi_base = get_unaligned_le32(buf + 8); + + if (dmi_walk_early(dmi_decode) == 0) { + if (smbios_ver) { +- dmi_ver = smbios_ver; + pr_info("SMBIOS %d.%d present.\n", + dmi_ver >> 8, dmi_ver & 0xFF); + } else { +- dmi_ver = (buf[14] & 0xF0) << 4 | +- (buf[14] & 0x0F); + pr_info("Legacy DMI %d.%d present.\n", + dmi_ver >> 8, dmi_ver & 0xFF); + } diff --git a/queue-4.0/md-raid0-fix-restore-to-sector-variable-in-raid0_make_request.patch b/queue-4.0/md-raid0-fix-restore-to-sector-variable-in-raid0_make_request.patch new file mode 100644 index 00000000000..827776923d6 --- /dev/null +++ b/queue-4.0/md-raid0-fix-restore-to-sector-variable-in-raid0_make_request.patch @@ -0,0 +1,49 @@ +From a81157768a00e8cf8a7b43b5ea5cac931262374f Mon Sep 17 00:00:00 2001 +From: Eric Work +Date: Mon, 18 May 2015 23:26:23 -0700 +Subject: md/raid0: fix restore to sector variable in raid0_make_request + +From: Eric Work + +commit a81157768a00e8cf8a7b43b5ea5cac931262374f upstream. + +The variable "sector" in "raid0_make_request()" was improperly updated +by a call to "sector_div()" which modifies its first argument in place. +Commit 47d68979cc968535cb87f3e5f2e6a3533ea48fbd restored this variable +after the call for later re-use. Unfortunetly the restore was done after +the referenced variable "bio" was advanced. This lead to the original +value and the restored value being different. Here we move this line to +the proper place. + +One observed side effect of this bug was discarding a file though +unlinking would cause an unrelated file's contents to be discarded. + +Signed-off-by: NeilBrown +Fixes: 47d68979cc96 ("md/raid0: fix bug with chunksize not a power of 2.") +URL: https://bugzilla.kernel.org/show_bug.cgi?id=98501 +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/raid0.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/md/raid0.c ++++ b/drivers/md/raid0.c +@@ -517,6 +517,9 @@ static void raid0_make_request(struct md + ? (sector & (chunk_sects-1)) + : sector_div(sector, chunk_sects)); + ++ /* Restore due to sector_div */ ++ sector = bio->bi_iter.bi_sector; ++ + if (sectors < bio_sectors(bio)) { + split = bio_split(bio, sectors, GFP_NOIO, fs_bio_set); + bio_chain(split, bio); +@@ -524,7 +527,6 @@ static void raid0_make_request(struct md + split = bio; + } + +- sector = bio->bi_iter.bi_sector; + zone = find_zone(mddev->private, §or); + tmp_dev = map_sector(mddev, zone, sector, §or); + split->bi_bdev = tmp_dev->bdev; diff --git a/queue-4.0/md-raid5-don-t-record-new-size-if-resize_stripes-fails.patch b/queue-4.0/md-raid5-don-t-record-new-size-if-resize_stripes-fails.patch new file mode 100644 index 00000000000..bc0db29c55e --- /dev/null +++ b/queue-4.0/md-raid5-don-t-record-new-size-if-resize_stripes-fails.patch @@ -0,0 +1,40 @@ +From 6e9eac2dcee5e19f125967dd2be3e36558c42fff Mon Sep 17 00:00:00 2001 +From: NeilBrown +Date: Fri, 8 May 2015 18:19:34 +1000 +Subject: md/raid5: don't record new size if resize_stripes fails. + +From: NeilBrown + +commit 6e9eac2dcee5e19f125967dd2be3e36558c42fff upstream. + +If any memory allocation in resize_stripes fails we will return +-ENOMEM, but in some cases we update conf->pool_size anyway. + +This means that if we try again, the allocations will be assumed +to be larger than they are, and badness results. + +So only update pool_size if there is no error. + +This bug was introduced in 2.6.17 and the patch is suitable for +-stable. + +Fixes: ad01c9e3752f ("[PATCH] md: Allow stripes to be expanded in preparation for expanding an array") +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/raid5.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/md/raid5.c ++++ b/drivers/md/raid5.c +@@ -1933,7 +1933,8 @@ static int resize_stripes(struct r5conf + + conf->slab_cache = sc; + conf->active_name = 1-conf->active_name; +- conf->pool_size = newsize; ++ if (!err) ++ conf->pool_size = newsize; + return err; + } + diff --git a/queue-4.0/nfsd-blocklayout-pretend-we-can-send-deviceid-notifications.patch b/queue-4.0/nfsd-blocklayout-pretend-we-can-send-deviceid-notifications.patch new file mode 100644 index 00000000000..b51e20b1d48 --- /dev/null +++ b/queue-4.0/nfsd-blocklayout-pretend-we-can-send-deviceid-notifications.patch @@ -0,0 +1,47 @@ +From 40cdc7a530c7a075557651a071354bb42b99df08 Mon Sep 17 00:00:00 2001 +From: Christoph Hellwig +Date: Mon, 27 Apr 2015 14:50:13 +0200 +Subject: nfsd/blocklayout: pretend we can send deviceid notifications + +From: Christoph Hellwig + +commit 40cdc7a530c7a075557651a071354bb42b99df08 upstream. + +Commit df52699e4fcef ("NFSv4.1: Don't cache deviceids that have no +notifications") causes the Linux NFS client to stop caching deviceid's +unless a server pretends to support deviceid notifications. While this +behavior is stupid and the language around this area in rfc5661 is a +mess carified by an errata that I submittted, Trond insists on this +behavior. Not caching deviceids degrades block layout performance +massively as a GETDEVICEINFO is fairly expensive. + +So add this hack to make the Linux client happy again. + +Signed-off-by: Christoph Hellwig +Signed-off-by: J. Bruce Fields +Signed-off-by: Greg Kroah-Hartman + +--- + fs/nfsd/blocklayout.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/fs/nfsd/blocklayout.c ++++ b/fs/nfsd/blocklayout.c +@@ -181,6 +181,17 @@ nfsd4_block_proc_layoutcommit(struct ino + } + + const struct nfsd4_layout_ops bl_layout_ops = { ++ /* ++ * Pretend that we send notification to the client. This is a blatant ++ * lie to force recent Linux clients to cache our device IDs. ++ * We rarely ever change the device ID, so the harm of leaking deviceids ++ * for a while isn't too bad. Unfortunately RFC5661 is a complete mess ++ * in this regard, but I filed errata 4119 for this a while ago, and ++ * hopefully the Linux client will eventually start caching deviceids ++ * without this again. ++ */ ++ .notify_types = ++ NOTIFY_DEVICEID4_DELETE | NOTIFY_DEVICEID4_CHANGE, + .proc_getdeviceinfo = nfsd4_block_proc_getdeviceinfo, + .encode_getdeviceinfo = nfsd4_block_encode_getdeviceinfo, + .proc_layoutget = nfsd4_block_proc_layoutget, diff --git a/queue-4.0/nfsd-fix-the-check-for-confirmed-openowner-in-nfs4_preprocess_stateid_op.patch b/queue-4.0/nfsd-fix-the-check-for-confirmed-openowner-in-nfs4_preprocess_stateid_op.patch new file mode 100644 index 00000000000..491c73efd7d --- /dev/null +++ b/queue-4.0/nfsd-fix-the-check-for-confirmed-openowner-in-nfs4_preprocess_stateid_op.patch @@ -0,0 +1,68 @@ +From ebe9cb3bb13e7b9b281969cd279ce70834f7500f Mon Sep 17 00:00:00 2001 +From: Christoph Hellwig +Date: Tue, 28 Apr 2015 15:41:15 +0200 +Subject: nfsd: fix the check for confirmed openowner in nfs4_preprocess_stateid_op + +From: Christoph Hellwig + +commit ebe9cb3bb13e7b9b281969cd279ce70834f7500f upstream. + +If we find a non-confirmed openowner we jump to exit the function, but do +not set an error value. Fix this by factoring out a helper to do the +check and properly set the error from nfsd4_validate_stateid. + +Signed-off-by: Christoph Hellwig +Signed-off-by: J. Bruce Fields +Signed-off-by: Greg Kroah-Hartman + +--- + fs/nfsd/nfs4state.c | 21 +++++++++++---------- + 1 file changed, 11 insertions(+), 10 deletions(-) + +--- a/fs/nfsd/nfs4state.c ++++ b/fs/nfsd/nfs4state.c +@@ -4386,10 +4386,17 @@ static __be32 check_stateid_generation(s + return nfserr_old_stateid; + } + ++static __be32 nfsd4_check_openowner_confirmed(struct nfs4_ol_stateid *ols) ++{ ++ if (ols->st_stateowner->so_is_open_owner && ++ !(openowner(ols->st_stateowner)->oo_flags & NFS4_OO_CONFIRMED)) ++ return nfserr_bad_stateid; ++ return nfs_ok; ++} ++ + static __be32 nfsd4_validate_stateid(struct nfs4_client *cl, stateid_t *stateid) + { + struct nfs4_stid *s; +- struct nfs4_ol_stateid *ols; + __be32 status = nfserr_bad_stateid; + + if (ZERO_STATEID(stateid) || ONE_STATEID(stateid)) +@@ -4419,13 +4426,7 @@ static __be32 nfsd4_validate_stateid(str + break; + case NFS4_OPEN_STID: + case NFS4_LOCK_STID: +- ols = openlockstateid(s); +- if (ols->st_stateowner->so_is_open_owner +- && !(openowner(ols->st_stateowner)->oo_flags +- & NFS4_OO_CONFIRMED)) +- status = nfserr_bad_stateid; +- else +- status = nfs_ok; ++ status = nfsd4_check_openowner_confirmed(openlockstateid(s)); + break; + default: + printk("unknown stateid type %x\n", s->sc_type); +@@ -4517,8 +4518,8 @@ nfs4_preprocess_stateid_op(struct net *n + status = nfs4_check_fh(current_fh, stp); + if (status) + goto out; +- if (stp->st_stateowner->so_is_open_owner +- && !(openowner(stp->st_stateowner)->oo_flags & NFS4_OO_CONFIRMED)) ++ status = nfsd4_check_openowner_confirmed(stp); ++ if (status) + goto out; + status = nfs4_check_openmode(stp, flags); + if (status) diff --git a/queue-4.0/revert-hid-logitech-hidpp-support-combo-keyboard-touchpad-tk820.patch b/queue-4.0/revert-hid-logitech-hidpp-support-combo-keyboard-touchpad-tk820.patch new file mode 100644 index 00000000000..8e9ddc230f1 --- /dev/null +++ b/queue-4.0/revert-hid-logitech-hidpp-support-combo-keyboard-touchpad-tk820.patch @@ -0,0 +1,92 @@ +From 5006c1052aafa01dab5b0e643b7dac755b41f3bb Mon Sep 17 00:00:00 2001 +From: Benjamin Tissoires +Date: Wed, 6 May 2015 15:01:31 -0400 +Subject: Revert "HID: logitech-hidpp: support combo keyboard touchpad TK820" + +From: Benjamin Tissoires + +commit 5006c1052aafa01dab5b0e643b7dac755b41f3bb upstream. + +This reverts commit 3a61e97563d78a2ca10752902449570d8433ce76. + +The Logitech TK820 seems to be affected by a firmware bug which +delays the sending of the keys (pressed, or released, which triggers +a key-repeat) while holding fingers on the touch sensor. +This behavior can be observed while using the mouse emulation mode +if the user moves the finger while typing (highly improbable though). +Holding the finger still while in the mouse emulation mode does +not trigger the key repeat problem. +So better keep things in their previous state to not have to +explain users that the new key-repeat bug they see is a "feature". + +Furthermore, I noticed that I disabled the media keys whith +this patch. Sorry, my bad. + +I think it is best to revert the patch, in all the current +versions it has been shipped. + +Signed-off-by: Benjamin Tissoires +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hid/hid-logitech-hidpp.c | 20 -------------------- + 1 file changed, 20 deletions(-) + +--- a/drivers/hid/hid-logitech-hidpp.c ++++ b/drivers/hid/hid-logitech-hidpp.c +@@ -39,7 +39,6 @@ MODULE_AUTHOR("Nestor Lopez Casado quirks & HIDPP_QUIRK_MULTI_INPUT) && +- (field->application == HID_GD_KEYBOARD)) +- return 0; +- + return -1; + } + +@@ -715,10 +708,6 @@ static void wtp_populate_input(struct hi + { + struct wtp_data *wd = hidpp->private_data; + +- if ((hidpp->quirks & HIDPP_QUIRK_MULTI_INPUT) && origin_is_hid_core) +- /* this is the generic hid-input call */ +- return; +- + __set_bit(EV_ABS, input_dev->evbit); + __set_bit(EV_KEY, input_dev->evbit); + __clear_bit(EV_REL, input_dev->evbit); +@@ -1234,10 +1223,6 @@ static int hidpp_probe(struct hid_device + if (hidpp->quirks & HIDPP_QUIRK_DELAYED_INIT) + connect_mask &= ~HID_CONNECT_HIDINPUT; + +- /* Re-enable hidinput for multi-input devices */ +- if (hidpp->quirks & HIDPP_QUIRK_MULTI_INPUT) +- connect_mask |= HID_CONNECT_HIDINPUT; +- + ret = hid_hw_start(hdev, connect_mask); + if (ret) { + hid_err(hdev, "%s:hid_hw_start returned error\n", __func__); +@@ -1285,11 +1270,6 @@ static const struct hid_device_id hidpp_ + HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, + USB_DEVICE_ID_LOGITECH_T651), + .driver_data = HIDPP_QUIRK_CLASS_WTP }, +- { /* Keyboard TK820 */ +- HID_DEVICE(BUS_USB, HID_GROUP_LOGITECH_DJ_DEVICE, +- USB_VENDOR_ID_LOGITECH, 0x4102), +- .driver_data = HIDPP_QUIRK_DELAYED_INIT | HIDPP_QUIRK_MULTI_INPUT | +- HIDPP_QUIRK_CLASS_WTP }, + + { HID_DEVICE(BUS_USB, HID_GROUP_LOGITECH_DJ_DEVICE, + USB_VENDOR_ID_LOGITECH, HID_ANY_ID)}, diff --git a/queue-4.0/series b/queue-4.0/series index 438f075fe38..06f6a43bfd3 100644 --- a/queue-4.0/series +++ b/queue-4.0/series @@ -111,3 +111,11 @@ gfp-add-__gfp_noaccount.patch kernfs-do-not-account-ino_ida-allocations-to-memcg.patch tools-vm-fix-page-flags-build.patch mm-numa-really-disable-numa-balancing-by-default-on-single-node-machines.patch +nfsd-blocklayout-pretend-we-can-send-deviceid-notifications.patch +nfsd-fix-the-check-for-confirmed-openowner-in-nfs4_preprocess_stateid_op.patch +svcrpc-fix-potential-gssx_accept_sec_context-decoding-failures.patch +firmware-dmi_scan-fix-ordering-of-product_uuid.patch +thermal-armada-update-armada-380-thermal-sensor-coefficients.patch +md-raid5-don-t-record-new-size-if-resize_stripes-fails.patch +md-raid0-fix-restore-to-sector-variable-in-raid0_make_request.patch +revert-hid-logitech-hidpp-support-combo-keyboard-touchpad-tk820.patch diff --git a/queue-4.0/svcrpc-fix-potential-gssx_accept_sec_context-decoding-failures.patch b/queue-4.0/svcrpc-fix-potential-gssx_accept_sec_context-decoding-failures.patch new file mode 100644 index 00000000000..8c79a903928 --- /dev/null +++ b/queue-4.0/svcrpc-fix-potential-gssx_accept_sec_context-decoding-failures.patch @@ -0,0 +1,92 @@ +From 9507271d960a1911a51683888837d75c171cd91f Mon Sep 17 00:00:00 2001 +From: Scott Mayhew +Date: Tue, 28 Apr 2015 16:29:53 -0400 +Subject: svcrpc: fix potential GSSX_ACCEPT_SEC_CONTEXT decoding failures + +From: Scott Mayhew + +commit 9507271d960a1911a51683888837d75c171cd91f upstream. + +In an environment where the KDC is running Active Directory, the +exported composite name field returned in the context could be large +enough to span a page boundary. Attaching a scratch buffer to the +decoding xdr_stream helps deal with those cases. + +The case where we saw this was actually due to behavior that's been +fixed in newer gss-proxy versions, but we're fixing it here too. + +Signed-off-by: Scott Mayhew +Reviewed-by: Simo Sorce +Signed-off-by: J. Bruce Fields +Signed-off-by: Greg Kroah-Hartman + +--- + net/sunrpc/auth_gss/gss_rpc_xdr.c | 23 ++++++++++++++++------- + 1 file changed, 16 insertions(+), 7 deletions(-) + +--- a/net/sunrpc/auth_gss/gss_rpc_xdr.c ++++ b/net/sunrpc/auth_gss/gss_rpc_xdr.c +@@ -793,20 +793,26 @@ int gssx_dec_accept_sec_context(struct r + { + u32 value_follows; + int err; ++ struct page *scratch; ++ ++ scratch = alloc_page(GFP_KERNEL); ++ if (!scratch) ++ return -ENOMEM; ++ xdr_set_scratch_buffer(xdr, page_address(scratch), PAGE_SIZE); + + /* res->status */ + err = gssx_dec_status(xdr, &res->status); + if (err) +- return err; ++ goto out_free; + + /* res->context_handle */ + err = gssx_dec_bool(xdr, &value_follows); + if (err) +- return err; ++ goto out_free; + if (value_follows) { + err = gssx_dec_ctx(xdr, res->context_handle); + if (err) +- return err; ++ goto out_free; + } else { + res->context_handle = NULL; + } +@@ -814,11 +820,11 @@ int gssx_dec_accept_sec_context(struct r + /* res->output_token */ + err = gssx_dec_bool(xdr, &value_follows); + if (err) +- return err; ++ goto out_free; + if (value_follows) { + err = gssx_dec_buffer(xdr, res->output_token); + if (err) +- return err; ++ goto out_free; + } else { + res->output_token = NULL; + } +@@ -826,14 +832,17 @@ int gssx_dec_accept_sec_context(struct r + /* res->delegated_cred_handle */ + err = gssx_dec_bool(xdr, &value_follows); + if (err) +- return err; ++ goto out_free; + if (value_follows) { + /* we do not support upcall servers sending this data. */ +- return -EINVAL; ++ err = -EINVAL; ++ goto out_free; + } + + /* res->options */ + err = gssx_dec_option_array(xdr, &res->options); + ++out_free: ++ __free_page(scratch); + return err; + } diff --git a/queue-4.0/thermal-armada-update-armada-380-thermal-sensor-coefficients.patch b/queue-4.0/thermal-armada-update-armada-380-thermal-sensor-coefficients.patch new file mode 100644 index 00000000000..a7c3ca60f09 --- /dev/null +++ b/queue-4.0/thermal-armada-update-armada-380-thermal-sensor-coefficients.patch @@ -0,0 +1,37 @@ +From efa86858e1d8970411a140fa1e0c4dd18a8f2a89 Mon Sep 17 00:00:00 2001 +From: Nadav Haklai +Date: Wed, 15 Apr 2015 19:08:08 +0200 +Subject: thermal: armada: Update Armada 380 thermal sensor coefficients + +From: Nadav Haklai + +commit efa86858e1d8970411a140fa1e0c4dd18a8f2a89 upstream. + +Improve the Armada 380 thermal sensor accuracy by using updated formula. +The updated formula is: +Temperature[C degrees] = 0.4761 * tsen_vsen_out - 279.1 + +Signed-off-by: Nadav Haklai +Signed-off-by: Gregory CLEMENT +Signed-off-by: Eduardo Valentin +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/thermal/armada_thermal.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/thermal/armada_thermal.c ++++ b/drivers/thermal/armada_thermal.c +@@ -224,9 +224,9 @@ static const struct armada_thermal_data + .is_valid_shift = 10, + .temp_shift = 0, + .temp_mask = 0x3ff, +- .coef_b = 1169498786UL, +- .coef_m = 2000000UL, +- .coef_div = 4289, ++ .coef_b = 2931108200UL, ++ .coef_m = 5000000UL, ++ .coef_div = 10502, + .inverted = true, + }; +