Bug#870523: linux-image-4.11.0-1-amd64 confirmed broken on another computer

2017-08-05 Thread Gilles Sadowski
Hi.

I've just upgraded another computer from "jessie" to "stretch"; this
installed 4.11.0-1 by default, and on that machine the problem immediately
showed up:
 * load average going up within seconds after the boot
 * trying to install "nvidia-legacy-check" led to "apt" hanging (and and
   next reboot, it reported the package as broken, wanting to reinstall it
   before removing it leading to hanging again...)

$ uname -a
Linux night 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x86_64 
GNU/Linux

That one seems to work, for now...

Regards,
Gilles
   



Bug#870523: linux-image-4.11.0-1-amd64 confirmed broken on another computer

2017-08-05 Thread Bastian Blank
On Sat, Aug 05, 2017 at 08:22:36PM +0200, Gilles Sadowski wrote:
> I've just upgraded another computer from "jessie" to "stretch"; this
> installed 4.11.0-1 by default, and on that machine the problem immediately

No, it does not and never will. 4.11.0-1 is testing and unstable, aka
Buster and Sid.

> $ uname -a
> Linux night 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x86_64 
> GNU/Linux
> That one seems to work, for now...

This is the kernel from Stretch, so you are good.

Bastian

-- 
Actual war is a very messy business.  Very, very messy business.
-- Kirk, "A Taste of Armageddon", stardate 3193.0



Bug#869658: linux: system freezes when dell-smm-hwmon reads fan speed

2017-08-05 Thread Carmelo C
In my system, dell-smm-hwmon is linked to the following folder:

/sys/class/hwmon/hwmon2/

The freeze occurs only when I type the following commands:

cat /sys/class/hwmon/hwmon2/fan1_input
cat /sys/class/hwmon/hwmon2/fan2_input
cat /sys/class/hwmon/hwmon2/fan3_input

In these commands, the freeze does not occur:

cat /sys/class/hwmon/hwmon2/temp1_input
cat /sys/class/hwmon/hwmon2/temp2_input
cat /sys/class/hwmon/hwmon2/temp3_input
cat /sys/class/hwmon/hwmon2/temp4_input

In this link, more information:
https://bugzilla.kernel.org/show_bug.cgi?id=112021


Bug#870523: linux-image-4.11.0-1-amd64: Same problem on "4.11.0-1-amd64"

2017-08-05 Thread Gilles
Package: src:linux
Followup-For: Bug #870523

Dear Maintainer,

   * What led up to the situation?

Running for about 10 days without the problem appearing.
Then, executing commands such as
 * mvn
 * ps
 * df
 * kill
 * sync
 * reboot

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

The terminal freezes.

Load average is reported with insanely high values:
$ uptime
 13:28:26 up 10 days, 11:02, 17 users,  load average: 48.13, 48.05, 47.62

Only a hard-reboot is effective to come back to a usable state.

Unfortunately, very few hints exist on the Web that could point
at the cause of the problem (searching for "blocked more than 120
seconds").

Here is the output of "dmesg":
[0.00] microcode: microcode updated early to revision 0x1c, date = 
2015-02-26
[0.00] Linux version 4.11.0-1-amd64 (debian-kernel@lists.debian.org) 
(gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.11.6-1 
(2017-06-19)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.11.0-1-amd64 
root=/dev/mapper/debian-root ro root=/dev/mapper/debian-root ro
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable
[0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xddc0efff] usable
[0.00] BIOS-e820: [mem 0xddc0f000-0xddfd8fff] reserved
[0.00] BIOS-e820: [mem 0xddfd9000-0xddfdcfff] usable
[0.00] BIOS-e820: [mem 0xddfdd000-0xde5e1fff] reserved
[0.00] BIOS-e820: [mem 0xde5e2000-0xde835fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xde836000-0xde842fff] ACPI data
[0.00] BIOS-e820: [mem 0xde843000-0xde861fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xde862000-0xde866fff] ACPI data
[0.00] BIOS-e820: [mem 0xde867000-0xde8a9fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xde8aa000-0xdecb9fff] usable
[0.00] BIOS-e820: [mem 0xdecba000-0xdeff3fff] reserved
[0.00] BIOS-e820: [mem 0xdeff4000-0xdeff] usable
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00021eff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.7 present.
[0.00] DMI: System manufacturer System Product Name/P8Z77-V LX, BIOS 
0610 05/08/2012
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x21f000 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C write-protect
[0.00]   D-E7FFF uncachable
[0.00]   E8000-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask E write-back
[0.00]   1 base 2 mask FF000 write-back
[0.00]   2 base 21000 mask FF800 write-back
[0.00]   3 base 21800 mask FFC00 write-back
[0.00]   4 base 21C00 mask FFE00 write-back
[0.00]   5 base 21E00 mask FFF00 write-back
[0.00]   6 base 0E000 mask FE000 uncachable
[0.00]   7 disabled
[0.00]   8 disabled
[0.00]   9 disabled
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
[0.00] e820: update [mem 0xe000-0x] usable ==> reserved
[0.00] e820: last_pfn = 0xdf000 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [mem 0x000fcd10-0x000fcd1f] mapped at 
[9e77c00fcd10]
[0.00] Base memory trampoline at [9e77c0097000] 97000 size 24576
[0.00] BRK [0x2df41000, 0x2df41fff] PGTABLE
[0.00] BRK [0x2df42000, 

Processed: Re: Bug#869084: linux-image-4.12.0-trunk-amd64: rtl8723be fails to work with old firmware

2017-08-05 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 + patch
Bug #869084 [src:linux] linux-image-4.12.0-trunk-amd64: rtl8723be fails to work 
with old firmware
Added tag(s) patch.

-- 
869084: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869084
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#869084: linux-image-4.12.0-trunk-amd64: rtl8723be fails to work with old firmware

2017-08-05 Thread Sven Joachim
Control: tags -1 + patch

On 2017-07-28 13:29 +0200, Sven Joachim wrote:

> Control: forwarded -1 
> https://marc.info/?l=linux-wireless=150124050420053=2
>
> On 2017-07-20 13:54 +0200, Sven Joachim wrote:
>
>> Package: src:linux
>> Version: 4.12.2-1~exp1
>> Severity: important
>>
>> As of commit f70e4df2b384d21e36a7c30a591639592692e0ec, the rtl8723be
>> driver uses a new firmware file rtlwifi/rtl8723befw_36.bin which is not
>> packaged for Debian yet.  There is fallback code to load the old
>> firmware file rtlwifi/rtl8723befw.bin, but does not seem to work, for
>> the wifi fails to come up on my laptop. :-(
>
> AFAICS the problem is that request_firmware_nowait() does not wait for
> the firmware to show up and returns 0 even if the file is not there, so
> the code to load the fallback file will never be reached.
>
> I have reported this upstream now.

And even managed to come up with a patch that got accepted in the
wireless-drivers-next tree[1].  It does not apply to 4.12, therefore I
have attached a version which does.  Alternatively you could cherry-pick
commit f2764f61fa10 ("rtlwifi: Fix memory leak when firmware request
fails")[2] before it.

Cheers,
   Sven


1. 
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/?id=1d9b168d8ea9a0f51947d0e2f84856e77d2fe7ff

2. 
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/?id=f2764f61fa10593204b0c5e4e9a68dba02112e50

>From 6fff98234b7a25b717714a9a504d1ca805765ef1 Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Sat, 29 Jul 2017 11:10:13 +0200
Subject: [PATCH] rtlwifi: Fix fallback firmware loading

Commit f70e4df2b384 ("rtlwifi: Add code to read new versions of
firmware") added code to load an old firmware file if the new one is
not available.  Unfortunately that code is never reached because
request_firmware_nowait() does not wait for the firmware to show up
and returns 0 even if the file is not there.

Use the existing fallback mechanism introduced by commit 62009b7f1279
("rtlwifi: rtl8192cu: Add new firmware") instead.

Fixes: f70e4df2b384 ("rtlwifi: Add code to read new versions of firmware")
Cc: sta...@vger.kernel.org
Signed-off-by: Sven Joachim 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c | 13 +++--
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c | 13 +++--
 2 files changed, 6 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c
index 8c0ac96b5430..c781105a8524 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c
@@ -187,16 +187,8 @@ int rtl8723be_init_sw_vars(struct ieee80211_hw *hw)
   rtlpriv->io.dev, GFP_KERNEL, hw,
   rtl_fw_cb);
 	if (err) {
-		/* Failed to get firmware. Check if old version available */
-		fw_name = "rtlwifi/rtl8723befw.bin";
-		pr_info("Using firmware %s\n", fw_name);
-		err = request_firmware_nowait(THIS_MODULE, 1, fw_name,
-	  rtlpriv->io.dev, GFP_KERNEL, hw,
-	  rtl_fw_cb);
-		if (err) {
-			pr_err("Failed to request firmware!\n");
-			return 1;
-		}
+		pr_err("Failed to request firmware!\n");
+		return 1;
 	}
 	return 0;
 }
@@ -287,6 +279,7 @@ static const struct rtl_hal_cfg rtl8723be_hal_cfg = {
 	.bar_id = 2,
 	.write_readback = true,
 	.name = "rtl8723be_pci",
+	.alt_fw_name = "rtlwifi/rtl8723befw.bin",
 	.ops = _hal_ops,
 	.mod_params = _mod_params,
 	.maps[SYS_ISO_CTRL] = REG_SYS_ISO_CTRL,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c
index abaf34cb1433..bc6dcac34924 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c
@@ -214,16 +214,8 @@ int rtl8821ae_init_sw_vars(struct ieee80211_hw *hw)
   rtlpriv->io.dev, GFP_KERNEL, hw,
   rtl_fw_cb);
 	if (err) {
-		/* Failed to get firmware. Check if old version available */
-		fw_name = "rtlwifi/rtl8821aefw.bin";
-		pr_info("Using firmware %s\n", fw_name);
-		err = request_firmware_nowait(THIS_MODULE, 1, fw_name,
-	  rtlpriv->io.dev, GFP_KERNEL, hw,
-	  rtl_fw_cb);
-		if (err) {
-			pr_err("Failed to request normal firmware!\n");
-			return 1;
-		}
+		pr_err("Failed to request normal firmware!\n");
+		return 1;
 	}
 	/*load wowlan firmware*/
 	pr_info("Using firmware %s\n", wowlan_fw_name);
@@ -325,6 +317,7 @@ static const struct rtl_hal_cfg rtl8821ae_hal_cfg = {
 	.bar_id = 2,
 	.write_readback = true,
 	.name = "rtl8821ae_pci",
+	.alt_fw_name = "rtlwifi/rtl8821aefw.bin",
 	.ops = _hal_ops,
 	.mod_params = _mod_params,
 	.maps[SYS_ISO_CTRL] = REG_SYS_ISO_CTRL,
-- 
2.13.3