Bug#949019: marked as done (firmware-linux-nonfree: Missing firmware for Ice Lake sound card renders it disabled)

2021-03-04 Thread Debian Bug Tracking System
Your message dated Thu, 4 Mar 2021 22:30:59 +0100
with message-id 
and subject line Re:   firmware-linux-nonfree: Missing firmware for Ice Lake 
sound card renders it disabled
has caused the Debian Bug report #949019,
regarding firmware-linux-nonfree: Missing firmware for Ice Lake sound card 
renders it disabled
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
949019: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949019
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: firmware-linux-nonfree
Version: 20190717-2
Severity: normal

Missing firmware intel/sof/sof-icl.ri makes that the sound card is not
working in kernel 5.5 (only sound output is "dummy", until I plug in an
USB sound card).

Please update the firmware packages with more recent blobs than those of
six months ago :-) recent hardware depends on it.




-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.5.0-rc5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firmware-linux-nonfree depends on:
ii  firmware-amd-graphics  20190717-2
ii  firmware-misc-nonfree  20190717-2

Versions of packages firmware-linux-nonfree recommends:
ii  amd64-microcode  3.20191218.1
ii  intel-microcode  3.20191115.2

firmware-linux-nonfree suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---
firmware-sof-signed is available, hence closing.--- End Message ---


Bug#980205: #980205 installation missing "non free" drivers.

2021-03-04 Thread maximilian attems
On Thu, Mar 04, 2021 at 10:08:39AM -0800, Dave Dyer wrote:
> 
> I no longer have the (damaged and useless) installation attempt
> that led to this report.   I recall that when I succeeded in
> supplying brcmfmac43340-sdio.bin, the next installation attempt
> presented the same type of error message, asking for brcmfmac43340-sdio.txt

missing brcmfmac43340-sdio.txt depends on the device, see for example
https://bugs.debian.org/982579

-- snipp
> [   10.534664] brcmfmac mmc2:0001:1: Direct firmware load for  
> brcm/brcmfmac43430-sdio.sinovoip,bpi-m2-ultra.txt failed with error -2
> [   10.551207] brcmfmac mmc2:0001:1: firmware: failed to load 
> brcm/brcmfmac43430-sdio.txt (-2)
--

if you have still the device around let us know, otherwise
the bug report will closed.

 
> I found a file with that name on github, and there was some evidence
> that it worked.  I believe it's attacked to the bug report thread.

I relooked for it but didn't see the error log message.
thank you for your prompt reply.

-- 
maks


signature.asc
Description: PGP signature


Bug#980205: #980205 installation missing "non free" drivers.

2021-03-04 Thread Dave Dyer


I no longer have the (damaged and useless) installation attempt
that led to this report.   I recall that when I succeeded in
supplying brcmfmac43340-sdio.bin, the next installation attempt
presented the same type of error message, asking for brcmfmac43340-sdio.txt

I found a file with that name on github, and there was some evidence
that it worked.  I believe it's attacked to the bug report thread.

--

At 06:10 AM 3/4/2021, maximilian attems wrote:
>tags 980205 moreinfo
>thanks
>
>
>> Yes.   brcm/brcmfmac43340-sdio.bin is not currently part of the package
>> either, and I think there's no logic to copy .txt files even if they
>> are present.
>
>The file you mentioned is the ancient firmware that got updated with
>the cypress one fixing amongst other things (CVE-2019-15126):
>
> Link: brcm/brcmfmac43340-sdio.bin -> ../cypress/cyfmac43340-sdio.bin
>
>This symlink is inside of firmware-brcm80211_20210208-3_all.deb
>(shipped in unstable and soon in testing).
>
>
>Now the open question is which configuration file where you missing,
>could you please post the error message of that?
>Without the filename/path of the needed config this report will not
>help to improve the firmware packages.
>
>
>thank you + kind regards
>
>-- 
>maks



Processed: Re: #980205 installation missing "non free" drivers.

2021-03-04 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> tags 980205 moreinfo
Bug #980205 [firmware-nonfree] firmware: missing txt file for 
brcm/brcmfmac43340-sdio.bin
Added tag(s) moreinfo.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
980205: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980205
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#980205: #980205 installation missing "non free" drivers.

2021-03-04 Thread maximilian attems
tags 980205 moreinfo
thanks


> Yes.   brcm/brcmfmac43340-sdio.bin is not currently part of the package
> either, and I think there's no logic to copy .txt files even if they
> are present.

The file you mentioned is the ancient firmware that got updated with
the cypress one fixing amongst other things (CVE-2019-15126):

 Link: brcm/brcmfmac43340-sdio.bin -> ../cypress/cyfmac43340-sdio.bin

This symlink is inside of firmware-brcm80211_20210208-3_all.deb
(shipped in unstable and soon in testing).


Now the open question is which configuration file where you missing,
could you please post the error message of that?
Without the filename/path of the needed config this report will not
help to improve the firmware packages.


thank you + kind regards

-- 
maks



Bug#983885:

2021-03-04 Thread Mateusz Łącki
It seems to me that passing "crashkernel=1024M nmi_watchdog=1 
crashkernel=384M-:128M” as a kernel boot parameter makes the system way more 
stable (but this is based on fairly short test period - perhaps 6 times the 
expected failure time).

Best,
Mateusz


Bug#983923: linux-image-4.19.0-13-cloud-amd64: Please add CONFIG_MAXSMP to the linux-image-cloud-amd64 kernel

2021-03-04 Thread Louis Bouchard

Hello,



Do any of the cloud providers supported by the cloud kernel build
(primarily AWS and Azure) offer VMs with >64 physical cores?

noah



After doing more research, it appears that the use of the -smp 96 option 
without any other precision creates a VM with one core and 96 sockets.


When using the option --smp cores=96 the VM is created with 96 cores and 
one socket and the 4.19.0-13 boots correctly.


So the addition of MAXSMP is not required to have a VM correctly started 
with more than 64 cpus.


Thanks for you attention,

Kind regards,

...Louis