Bug#917941: Installation Buster on HP 17-by Notebook
Hi, Just adding some info to this bug, for whoever stumbles upon it - I just got a new HP laptop (HP Pavillion X360, 14", specific model 14-cd0004la) with this same wifi chip. I was able to install and use the (very not official, run at your own risk!) drivers available at https://github.com/tomaspinho/rtl8821ce via DKMS. So far, so good (not that it's been very far yet ;-) ) Other than this driver, the laptop works very well with a stock Debian Buster 10.4. Will submit a separate installation report, of course. Thanks!
Processed: tagging 960702
Processing commands for cont...@bugs.debian.org: > tags 960702 - patch Bug #960702 [src:linux] ethtool -m values change when output is redirected Removed tag(s) patch. > thanks Stopping processing here. Please contact me if you need assistance. -- 960702: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960702 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: severity of 960871 is important
Processing commands for cont...@bugs.debian.org: > severity 960871 important Bug #960871 [src:linux] linux-image-amd64: iwlwifi: iwl_mvm_enable_txq NULL pointer dereference, address: 0068 Severity set to 'important' from 'grave' > thanks Stopping processing here. Please contact me if you need assistance. -- 960871: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960871 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: reassign 960900 to src:linux
Processing commands for cont...@bugs.debian.org: > reassign 960900 src:linux 5.6.7-1 Bug #960900 [linux-image-amd64] black screen after s2ram while 3D graphics (amdgpu - workaround: no_console_suspend) Bug reassigned from package 'linux-image-amd64' to 'src:linux'. No longer marked as found in versions linux-signed-amd64/5.6.7+1. Ignoring request to alter fixed versions of bug #960900 to the same values previously set Bug #960900 [src:linux] black screen after s2ram while 3D graphics (amdgpu - workaround: no_console_suspend) Marked as found in versions linux/5.6.7-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 960900: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960900 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#960702: [PATCH net] mlx4: Fix information leak on failure to read module EEPROM
On Mon, 2020-05-18 at 16:47 +, Saeed Mahameed wrote:
> On Sun, 2020-05-17 at 18:20 +0100, Ben Hutchings wrote:
> > mlx4_en_get_module_eeprom() returns 0 even if it fails. This results
> > in copying an uninitialised (or partly initialised) buffer back to
> > user-space.
[...]
> I am not sure i see the issue in here, and why we need the partial
> memset ?
> first thing in this function we do:
> memset(data, 0, ee->len);
>
> and then mlx4_get_module_info() will only copy valid data only on
> success.
Wow, sorry, I don't know how I missed that. So this is not the bug I
was looking for.
>
> > - if (!ret) /* Done reading */
> > + if (!ret) {
> > + /* DOM was not readable after all */
>
> actually if mlx4_get_module_info() returns any non-negative value it
> means how much data was read, so if it returns 0, it means that this
> was the last iteration and we are done reading the eeprom..
>
> so i would remove the above comment and the memset below is redundant
> since we already memset the whole buffer before the while loop.
Right.
> > + memset(data + i, 0, ee->len - i);
> > return 0;
> > + }
> >
> > if (ret < 0) {
> > en_err(priv,
> >"mlx4_get_module_info i(%d) offset(%d)
> > bytes_to_read(%d) - FAILED (0x%x)\n",
> >i, offset, ee->len - i, ret);
> > - return 0;
> > + return ret;
>
> I think returning error in here was the actual solution for your
> problem. you can verify by looking in the kernel log and verify you see
> the log message.
The original bug report (https://bugs.debian.org/960702) says that
ethtool reports different values depending on whether its output is
redirected. Although returning all-zeroes for the unreadable part
might be wrong, it doesn't explain that behaviour.
Perhaps if the timing of the I²C reads is marginal, varying numbers of
bytes of DOM information might be readable? But I don't see how
redirection of ethtool's output would affect that. It uses a single
ioctl to read everything, and the kernel controls timing within that.
So I am mystified about what is going on here. Maybe there is a bug in
ethtool, but I'm not seeing it.
Ben.
> > }
> >
> > i += ret;
--
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.
signature.asc
Description: This is a digitally signed message part
Processed: tagging 960702
Processing commands for cont...@bugs.debian.org: > tags 960702 - security Bug #960702 [src:linux] ethtool -m values change when output is redirected Removed tag(s) security. > thanks Stopping processing here. Please contact me if you need assistance. -- 960702: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960702 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#960702: [PATCH net] mlx4: Fix information leak on failure to read module EEPROM
On Sun, 2020-05-17 at 18:20 +0100, Ben Hutchings wrote:
> mlx4_en_get_module_eeprom() returns 0 even if it fails. This results
> in copying an uninitialised (or partly initialised) buffer back to
> user-space.
>
> Change it so that:
>
> * In the special case that the DOM turns out not to be readable, the
> remaining part of the buffer is cleared. This should avoid a
> regression when reading modules with this problem.
>
> * In other error cases, the error code is propagated.
>
> Reported-by: Yannis Aribaud
> References: https://bugs.debian.org/960702
> Fixes: 7202da8b7f71 ("ethtool, net/mlx4_en: Cable info,
> get_module_info/...")
> Signed-off-by: Ben Hutchings
> ---
> This is compile-tested only. It should go to stable, if it is a
> correct fix.
>
> Ben.
>
> drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
> b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
> index 8a5ea2543670..6edc3177af1c 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
> @@ -2078,14 +2078,17 @@ static int mlx4_en_get_module_eeprom(struct
> net_device *dev,
> ret = mlx4_get_module_info(mdev->dev, priv->port,
> offset, ee->len - i, data +
> i);
>
I am not sure i see the issue in here, and why we need the partial
memset ?
first thing in this function we do:
memset(data, 0, ee->len);
and then mlx4_get_module_info() will only copy valid data only on
success.
> - if (!ret) /* Done reading */
> + if (!ret) {
> + /* DOM was not readable after all */
actually if mlx4_get_module_info() returns any non-negative value it
means how much data was read, so if it returns 0, it means that this
was the last iteration and we are done reading the eeprom..
so i would remove the above comment and the memset below is redundant
since we already memset the whole buffer before the while loop.
> + memset(data + i, 0, ee->len - i);
> return 0;
> + }
>
> if (ret < 0) {
> en_err(priv,
> "mlx4_get_module_info i(%d) offset(%d)
> bytes_to_read(%d) - FAILED (0x%x)\n",
> i, offset, ee->len - i, ret);
> - return 0;
> + return ret;
I think returning error in here was the actual solution for your
problem. you can verify by looking in the kernel log and verify you see
the log message.
> }
>
> i += ret;
Bug#956511: linux-image-5.5.0-1-amd64: general protection fault in i915_active_ref with 5.5
On Sun, 12 Apr 2020 19:24:03 +0100 Ben Hutchings wrote: Is this reproducible without the nvidia drivers loaded at all? Sorry, idk, I cannot reproduce it any more.
Bug#960935: linux: please enable CONFIG_NUMA on sparc64
Source: linux Severity: wishlist Hi! While discussing porting one of my packages to sparc64 (I wanted to run its tests, requiring the NUMA API, at least on a single machine) I was told that a lot of sparc64 machines in the wild have multiple sockets. Sparc architecture in general tends to have a lot of slow CPUs, using many-way SMT and NUMA nodes. As cross-socket accesses are in general a same-week service, it would be a good idea to enable this API so programs can be aware of NUMA setups. Thus: could you please set CONFIG_NUMA=y on linux-image-sparc64-smp? Meow!
Bug#960702: ethtool -m values change when output is redirected
17 mai 2020 18:04 "Ben Hutchings" a écrit: > [...] Just in case that could be usefull. We change the transceiver for an other model also known to work correctly. root@localhost:~# ethtool -m enp10s0 Identifier: 0x03 (SFP) Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID) Connector : 0x07 (LC) Transceiver codes : 0x10 0x00 0x00 0x00 0x40 0x00 0x0c 0x00 0x00 Transceiver type : 10G Ethernet: 10G Base-SR Transceiver type : FC: short distance (S) Transceiver type : FC: Multimode, 62.5um (M6) Transceiver type : FC: Multimode, 50um (M5) Encoding : 0x06 (64B/66B) BR, Nominal : 10300MBd Rate identifier : 0x00 (unspecified) Length (SMF,km) : 0km Length (SMF) : 0m Length (50um) : 300m Length (62.5um) : 150m Length (Copper) : 0m Length (OM3) : 0m Laser wavelength : 850nm Vendor name : FiberStore Vendor OUI: 00:90:65 Vendor PN : SFP-10GSR-85 Vendor rev: A Option values : 0x00 0x1a Option: RX_LOS implemented Option: TX_FAULT implemented Option: TX_DISABLE implemented BR margin, max: 0% BR margin, min: 0% Vendor SN : N3612030002 Date code : 161203 Optical diagnostics support : Yes Laser bias current: 16.480 mA Laser output power: 3.0768 mW / 4.88 dBm Receiver signal average optical power : 1.2298 mW / 0.90 dBm Module temperature: 48.47 degrees C / 119.24 degrees F Module voltage: 1.2336 V Alarm/warning flags implemented : Yes Laser bias current high alarm : Off Laser bias current low alarm : Off Laser bias current high warning : Off Laser bias current low warning: Off Laser output power high alarm : Off Laser output power low alarm : Off Laser output power high warning : Off Laser output power low warning: Off Module temperature high alarm : Off Module temperature low alarm : Off Module temperature high warning : Off Module temperature low warning: Off Module voltage high alarm : Off Module voltage low alarm : Off Module voltage high warning : Off Module voltage low warning: Off Laser rx power high alarm : Off Laser rx power low alarm : Off Laser rx power high warning : Off Laser rx power low warning: Off Laser bias current high alarm threshold : 4.744 mA Laser bias current low alarm threshold: 49.896 mA Laser bias current high warning threshold : 51.776 mA Laser bias current low warning threshold : 50.910 mA Laser output power high alarm threshold : 2.5701 mW / 4.10 dBm Laser output power low alarm threshold: 0.8224 mW / -0.85 dBm Laser output power high warning threshold : 0.8224 mW / -0.85 dBm Laser output power low warning threshold : 0.8224 mW / -0.85 dBm Module temperature high alarm threshold : 0.00 degrees C / 32.00 degrees F Module temperature low alarm threshold: 0.00 degrees C / 32.00 degrees F Module temperature high warning threshold : 0.00 degrees C / 32.00 degrees F Module temperature low warning threshold : 0.00 degrees C / 32.00 degrees F Module voltage high alarm threshold : 0.4356 V Module voltage low alarm threshold: 0. V Module voltage high warning threshold : 0. V Module voltage low warning threshold : 0. V Laser rx power high alarm threshold : 0.8224 mW / -0.85 dBm Laser rx
Bug#960912: (no subject)
I'd like to add that this feels like a regression, perhaps with the 5.x series of Debian kernels. With a 4.19 kernel, I never had this.
