Re: Information About The Linux Kernel Maintenance In Debian

[maximilian attems]

Dear Federico,

> can't easily find the following information:
> 
> - Criteria to select a kernel version for a Debian release. It looks to me you
>   are following LTS releases, but as you know kernel LTS is a moving target in
>   terms of duration. So, how you choose?

this depends on the Debian release cycle, which the Debian release
team sets. This is announced in the debian-release mailing list.
Once the release date cycle are known, the Debian kernel
team tries to optimise to have a recent enough LTS release balanced
with conservative exposure to enough hardware.
 
> - How much a Debian kernel diverges from kernel.org release overtime?

The stable kernel does not in general add hardware backports.
The amount in debian depends on the vested interests. If we
get enough bug reports or someone making it easy in gitlab
to merge newer hardware support that happens too. The driver
has to be released in mainline to qualify.
 
> - I see you explain how to build and run any kernel from kernel.org, but I do
>   not see and discouragement in doing so. Is this because you do not see any
>   known incompatibilities ?

For security maintenance we encourage to use the Debian one.
Of course if you have in house capabilities to follow whatever
LTS release you choose there will not be trouble (unless you set HZ to
some funny value or disable features glibc assumes).

We did optimize certain architectures for size but due to the
involved time constraints this got dropped.

Hope this helps, do not hesitate to follow-up.


Thank you for your interest (:
maximilian

Re: Git repository request for carl9170fw

[maximilian attems]

Dear John,

On Sat, Oct 09, 2021 at 09:30:51PM +, John Scott wrote:
> On Fri, 2021-10-08 at 14:35 +0200, maximilian attems wrote:
> >> By the way, can you also add a Recommends on
> >> firmware-ath9k-htc in that upload (you can close #900171)?
> > I haven't followed carl9170fw at all. I thought you would want a
> > Recommends on firmware-carl9170fw or something?
> We're talking about two different things. Indeed, a recommends on
> firmware-carl9170 (that's what the binary package will be called) would
> be nice. It's up to you whether you'd like to add the Recommends now
> with the package not being in the archive yet.

finally will upload today 20210919-1 as discussed

Concerning the recommneds I'll wait for firmware-carl9170 to show up.
 
> What I was just referring to is ath9k_htc, another libre wireless
> firmware for USB adapters which I already maintain. In my opinion, it
> would be nice if we could get all free firmware building from source 
> (probably in their own source packages as necessary) and eventually
> someday turn firmware-linux-free into a metapackage.

It is not good to mix too much packaging stuff in one upload,
so will keep this for the next.

thank you.
 

Re: Git repository request for carl9170fw

[maximilian attems]

On Fri, Oct 08, 2021 at 08:06:57AM +, John Scott wrote:
>
> By the way, can you also add a Recommends on
> firmware-ath9k-htc in that upload (you can close #900171)?

Could you please reexplain this point?
I haven't followed carl9170fw at all. I thought you would want a
Recommends on firmware-carl9170fw or something?

Re: Git repository request for carl9170fw

[maximilian attems]

hello,

> As previously announced, I'm planning to package the carl9170 firmware
> such that we build it from source using gcc-sh-elf. The package is
> starting to take shape, and I would appreciate if you could make an
> empty repository at
> https://salsa.debian.org/kernel-team/carl9170fw and grant me access; my
> username is 'jscott'.

done, you should have gotten mail confirmation, please confirm.
 
> By the way, I was wondering if we could agree to drop carl9170-1.fw
> from firmware-linux-free in the next upload so that I can add a
> Breaks+Replaces: linux-firmware-free (<= 20200122-1) in my package? If
> not, I'll have to upload an uninstallable package to experimental just
> to clear NEW, and we'll have to arrange the handover of carl9170.fw
> some other time.

I plan to upload current 20210919-1 very soon (probably sunday night)
and can drop carl9170.fw for that upcoming release, clearing the door
for above.


kind regards,
maximilian


signature.asc
Description: PGP signature

Bug#990127: mt76x0 crashes repeatedly

[maximilian attems]

reassign 990127 linux 4.19.181-1
tags 990127 moreinfo
stop

> Package: firmware-misc-nonfree
> Version: 20190114-2
> kernel module: mt76x0

The firmware did not change for ages, hence reassigning to linux.
 
 
> Following an update recently, this driver stopped working correctly.  I can
> now only get a working WiFi connection for a few seconds after reboot, or
> after waiting several minutes, making anything that requires the internet
> almost impossible. This was working fine until the update.

the Linux version in buster you are using is outdated, there exists
4.19.194-3 and in buster backports 5.10.46-4~bpo10+1.

> Once the interface is up, the driver crashes almost immediately.  It does
> not matter whether I use NetworkManager or do things manually with
> /etc/network/interfaces and then ifup.

please try to reproduce with up to date kernel, thank you.
 

Bug#989087: rtw_8822ce: firmware crash

[maximilian attems]

tags 989087 moreinfo
stop

the updated firmware got into 20210716 verison, which is
included in latest unstable package.

Could you please test it out if it improves your situation?


thank you.

-- 
maks

Bug#987116: firmware-iwlwifi: AX20* bluetooth random disconnects

[maximilian attems]

On Thu, Jun 17, 2021 at 03:25:11PM +0200, Maxime Brugidou wrote:
> Arch users found that the more recent firmware fixes the issue
> 
> See https://bbs.archlinux.org/viewtopic.php?id=263040=4
> Firmware has been updated on 2021-04-26
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=fa0efeff4894e36b9c3964376f2c99fae101d147
> 
> This firmware version is not available yet on firmware-iwlwifi package

This morning I uploaded to unstable the newer 20210427-1

Could you try it out?


signature.asc
Description: PGP signature

Bug#991943: klibc: please consider including machine-readable copyright file

[maximilian attems]

On Wed, Aug 11, 2021 at 02:40:20PM +0200, Andrej Shadura wrote:
> On 11/08/2021 14:30, Andrej Shadura wrote:
> > On Fri, 06 Aug 2021 14:31:26 +0200 Andrej Shadura 
> > wrote:
> >> Please consider including the attached machine-readable copyright file.
> >> I tried to make it as precise as I can based on the information in the
> >> source and accompanying text files; improve it as you see fit.
> > 
> > I’ve noticed a few issues with the proposed copyright file. I have fixed
> > them; please find the attached patch to the packaging.
> 
> Of course, once again I’ve forgotten something:
> 
> Files: debian/*
> Copyright:
>  2005  Jeff Bailey 
>  2005-2014 maximilian attems 
>  2015-2021 Ben Hutchings 
> 
> I’m not sure what the license of the packaging is.

please use whatever is canonical, I'm fine with GPL as well as BSD,
as it is mostly glue to just bring things to the enduser.

please use this email adress of mine, thank you.

also the patch should be submitted to klibc upstream ;)

Bug#963025: fixed in firmware-nonfree 20210315-1~exp1

[maximilian attems]

reopen 963025
found -1 20210315-2
tags -1 moreinfo
stop

> [18661.586025] CPU: 0 PID: 8408 Comm: hostapd Tainted: GW 
> 5.10.0-5-amd64 #1 Debian 5.10.24-1
> [18661.586029] Hardware name: LENOVO 20N2007GGE/20N2007GGE, BIOS N2IET81W 
> (1.59 ) 11/29/2019


Please could you upgrade the BIOS to latest for T490, 1.72 2021/03/17
to exclude this guy fault.

firmware-nonfree 20210315-2 upload

[maximilian attems]

Hello,

uploading 20210315-2 now with several important fixes.
Once it has again enough unstable exposure will ask for unblock.

There is a known issue with Raspberry Pi 4 5 Ghz wlan,
which has no known solution yet.

best,



signature.asc
Description: PGP signature

Bug#885958: hostapd: iwlwifi 5GHz hw_mode=a causes microcode fault

[maximilian attems]

tags 885958 moreinfo
stop

> [51085.431413] iwlwifi :03:00.0: Loaded firmware version: 29.541020.0

Can you reproduce this with up to date Debian testing?

thank you for your report.

Bug#772917: iwlwifi: iwl4965 crashes when network usage is intense

[maximilian attems]

tags 772917 moreinfo
stop

> [584941.834142] iwl4965 :03:00.0: Loaded firmware version:  228.61.2.24

Can you reproduce this with an up to date debian testing?


thank you.

Bug#969264: firmware-iwlwifi:

[maximilian attems]

tags 969264 moreinfo
stop

> Version: 20200721-1

> Wi-Fi connection has been behaving erratically, lots of lags - for
> instance - in LAN-SSH connections.

> $ lspci | grep "Network controller"
> 03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205
> [Taylor Peak] (rev 34)

Is this reproducible with current Debian testing?

thank you for your report.

Bug#839662: [firmware-atheros] ath10k_pci firmware crashes when ap changes bandwith

[maximilian attems]

tags 839662 moreinfo
stop

> The same problem here with firmware-atheros version 20170823-1~bpo9+1 
> and kernel 4.14.0-2-amd64.
> It's a dell xps 13 8th gen, with a:

Is this reproducible with an up to date Debian Testing?


Sorry for the late reply and thank you for the reports.

Bug#973529: firmware-atheros: Link wifi rate limited at 1MB/s

[maximilian attems]

tags 973529 moreinfo
stop

> Version: 20200918-1


How about latest Debian testing version, is that still the case?


thank you.

Bug#920937: firmware-atheros: Firmware QCA6174 crashes on wakeup from suspend

[maximilian attems]

> I seem to have the same problem with version 20190717 (debian testing 
> 5.4.13-1 amd64).

How about firmware 20210208-4, which should have an upgrade and
latest linux in Debian Bullseye?

thanks for your reports.

Bug#985627: firmware-linux-free: firmware....ver imagen

[maximilian attems]

reassign 985627 firmware-iwlwifi
tags 985627 moreinfo
stop

Buenas tardes,

La imagen no dice mucho, cual es la version de Debian?
(y de firmware-iwlwifi) cuando funcionó?
Ademas la error esta reproducible?

Bug#921004: AMD Radeon RX 580: no GL display, "amdgpu: The CS has been cancelled because the context is lost"

[maximilian attems]

tags 921004 moreinfo
stop

can you still reproduce this trouble with uptodate Debian 11 Testing?


thank you for your report and sorry for the late reply.

Bug#802937: firmware-linux-nonfree: radeon tahiti firmware fails to load

[maximilian attems]

tags 802937 moreinfo
stop

> Several months ago I got a new case that allowed me to reinstall the 
> graphics card. The old case wasn't big enough to accommodate the card + 
> the disk drives so I used an older, shorter card.

Can you reproduce with uptodate Debian bullseye?


sorry for the late reply and thank you for your report.

Bug#985632: firmware-brcm80211: [REGRESSION] RPi4B 5GHz WiFi stopped working with 20210208-4, 20201218-3 was fine

[maximilian attems]

Dear Ryutaroh,

> It is Raspberry Pi 4B 8GB model.

I see thank you for all the dmesg.
 
> > please show affected dmesg output working and non working,
> > the difference between 20210208-3 20210208-4 is minimal,
> > hence it should be easy to find out what broke?
> 
> Not at all, unfortunately.
> 20210208-3 was completely broken on RPi4B as
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984489
> 20210208-1 to 20210208-3 were broken...
> The last working version was 20201218-3, and I apt-mark-holded 
> firmware-brcm80211.
> I unhold it in the weekend and found this issue.

please excuse my ignorance first, but are you sure that these
bootflags are still adequate for the latest cypress firmware?

concerning bluetooth unfortunately this seems missing firmware
in latest upstream firmware git (see #962038 ) or possible wget info
https://wiki.debian.org/RaspberryPi4#Bluetooth
 
> I attach dmesg of 20201218-3, 20210208-4, and 20210315-1.
> It was also interesting that installation of 20210315-1 causes boot failure
> and showed "Give root password for maintainance"...
> Should I file a separete report against 20210315-1?
> 20210315-1~exp1 was booted fine...

this should not be reproducible as 20210315-1 and 20210315-1~exp1 are
unchanged (just uploaded into experimental before unstable).
 
Thank you for your report!
maximilian

Bug#985632: firmware-brcm80211: [REGRESSION] RPi4B 5GHz WiFi stopped working with 20210208-4, 20201218-3 was fine

[maximilian attems]

severity 985632 important
tags 985632 moreinfo
stop

On Sun, Mar 21, 2021 at 09:59:45AM +0900, Ryutaroh Matsumoto wrote:
> Package: firmware-brcm80211
> Version: 20210208-4
> Severity: grave
> Tags: sid bullseye
> Justification: renders package unusable

please provide info on the affected hardware,
also using apropriate bug levels would be nice.

> 5GHz WiFi stopped working with 20210208-4.
> iw wlan0 scan does not show SSID of 5GHz WiFi.
> With 20201218-3, 5GHz worked fine,
> provided that vc4.ko is blacklisted (see #981616).

please show affected dmesg output working and non working,
the difference between 20210208-3 20210208-4 is minimal,
hence it should be easy to find out what broke?

thank you for your report + kind regards,



signature.asc
Description: PGP signature

Re: firmware-nonfree 20210208-1 upload

[maximilian attems]

Dear release team,

> thank you for unblocking 20210208-4 firmware-nofree.

this landed in testing. (:
 
> > or have it together with latest 20210315-1, which includes thoses fixes,
> > but adds more support for intel iwlwifi/bluetooth and AMD green sardine
> > support - (gpu seen on current lenovo laptops)?
> 
> the latest hardware support with 20210315 is uploaded to experimental
> for further processing.

As experimental gives only mild coverage (tried to increase via
bug pings), and that the additional hardware support would be great
for upcoming bullseye, I plan to upload this weekend 20210315-1 to sid.
The source diff is quite minor (mainly removing patches from 20210208-4
that went upstream) and the new additional hardware support.

I will sent an unblock request once everything looks good.

thank you.

-- 
maks


signature.asc
Description: PGP signature

Bug#913711: firmware-brcm80211: firmware failed to load: NULL pointer dereference with brcmfmac4356

[maximilian attems]

tags 913711 moreinfo
stop

> Version: 20161130-4

There has been quite some updates since.

> latest firmware blobs from linux-firmare git, but only a downgrade to
> firmware-brcm80211:20161130-3 allowed the firmware to be correctly
> loaded.


Is this still reproducible with current Debian Testing (upcoming
Bullseye)?


Thank you for your report and sorry for the late reply.

Bug#922559: Firmware locks up on Vega 8

[maximilian attems]

tags 922559 moreinfo
stop


> Version: 20180825+dfsg-1~bpo9+1

Is this still reproducible with current Testing, upcoming bullseye
release? If so can you produce the corresponding log?


Thank you for your report and sorry for the late reply.

Bug#910272: firmware-amd-graphics: Error raised in amdgpu module

[maximilian attems]

tags 910272 moreinfo
stop

> Version: 20180825+dfsg-1

> I have HP EliteBook 755 G5, with AMD Ryzen 7 PRO 2700U w/ Radeon Vega
> Mobile

Is this still reproducible with current Debian Testing?

Sorry for the late reply and thank you for the report!

Bug#949973: firmware-realtek: kernel error caught

[maximilian attems]

tags 949973 moreinfo
stop


> Version: 20190114-2

Can you still reproduce with newest testing?


Sorry for the late reply and thank you for your report.


-- 
maks

Bug#942173: firmware-amd-graphics: seg fault with ati picasso grafic card and libqt5 software

[maximilian attems]

tags 942173 moreinfo
stop

> Version: 20190717-2~bpo10+1


This should have seen quite some updates since, is this still
reproducible?

Sorry for the late reply, thank you for your report!

Re: firmware-nonfree 20210208-1 upload

[maximilian attems]

thank you for unblocking 20210208-4 firmware-nofree.

> or have it together with latest 20210315-1, which includes thoses fixes,
> but adds more support for intel iwlwifi/bluetooth and AMD green sardine
> support - (gpu seen on current lenovo laptops)?

the latest hardware support with 20210315 is uploaded to experimental
for further processing.


-- 
maks


signature.asc
Description: PGP signature

Bug#963025: firmware-iwlwifi: Microcode SW error detected / 9000-pu-b0-jf-b0-46.ucode

[maximilian attems]

> Some context:
> * the error occured right after laptop boot
> * My Wifi setup: AP was forced to use frequency of 5240GHz and offered
> 20/40/80MHz channel width. Moving AP to 5180GHz solve the issue.
> 
> My understanding:
> It *seems* that iwlwifi could have issues with DFS frequencies, not with
> channel width.
> My last report was also linked to DFS channels being used.
> Moving away from DFS channel solve the issue, at least for me.

Upstream says this should be fixed in unstable linux version with
latest 20210315 iwlwifi firmare. If not please let us know.

Re: firmware-nonfree 20210208-1 upload

[maximilian attems]

> 20210208-4 upload happening now.

Would debian-release prefer a bug report pushing that into testing
or have it together with latest 20210315-1, which includes thoses fixes,
but adds more support for intel iwlwifi/bluetooth and AMD green sardine
support - (gpu seen on current lenovo laptops)?

please let me know of the preference?


thank you.

-- 
maks


signature.asc
Description: PGP signature

Bug#983255: firmware-realtek: Direct firmware load for rtw88/rtw8821c_fw.bin failed with error -2

[maximilian attems]

tags 983255 moreinfo
stop

On Tue, Feb 23, 2021 at 09:20:30AM +0100, maximilian attems wrote:
> > lspci | grep -i wire
> > 02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821CE 
> > 802.11ac PCIe Wireless Network Adapter
> > 
> > dmesg contains these lines: 
> > 
> > [4.938468] rtw_8821ce :02:00.0: Direct firmware load for 
> > rtw88/rtw8821c_fw.bin failed with error -2
> > [4.938472] rtw_8821ce :02:00.0: failed to request firmware
> > [4.938543] rtw_8821ce :02:00.0: failed to load firmware
> > [4.938571] rtw_8821ce :02:00.0: failed to setup chip efuse info
> > [4.938599] rtw_8821ce :02:00.0: failed to setup chip information
> > [4.939514] rtw_8821ce: probe of :02:00.0 failed with error -22
> > 
> > tried to install also latest firmware-realtek from unstable 
> > ii  firmware-realtek20210208-1  
> > all  Binary firmware for Realtek wired/wifi/BT adapters
> > but this did also not change anything. 
> 
> there is a newer version of this firmware v9.9.5 in the upstream repository,
> could you test commit 80cb579614ee576ae74e650fa0b43d9f7c212039
> in linux-firmware git:
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
 
Have you tried the newer firmware?

-- 
maks

Re: firmware-nonfree 20210208-1 upload

[maximilian attems]

> Tomorrow once firmware-nonfree has migrated 20210208-4 will be uploaded
> with important small fixes to Raspberry Pi 4B and BananaPi M2 ultra and
> BananaPi M3 supports. 

20210208-4 upload happening now.

-- 
maks


signature.asc
Description: PGP signature

Bug#984852: firmware-amd-graphics: Please add cezanne ("green sardine")

[maximilian attems]

severity 984852 important
tags 984852 pending
thanks

> Package: firmware-amd-graphics
> Version: 20210208-3
> 
> I've received my new laptop with a Ryzen R7 5800U and the display stopped 
> updating as soon as amdgpu took over, and it never came back.
> The firmware is needed of course, and as a side note, it could be nice if the 
> kernel could fail more gracefully, somehow bringing the display back (it 
> works fine with amdgpu blacklisted, just no acceleration) such that it takes 
> me less than two days to figure it all out.

this is a linux bug, you might want to submit it upstream to AMD guys.

 
> The relevant files are amdgpu/green_sardine_*

right, they only got pushed upstream in linux-firmware git on 11/2/2021
after the latest 20210208 release, hence unfortunately they miss out the
next debian release
https://release.debian.org/bullseye/freeze_policy.html

They will land in the next upstream release upload of 202103XX to
experimental, backports and then after bullseye release to unstable
(plus next testing).
 
Thank you for your report!

-- 
maks


signature.asc
Description: PGP signature

Re: firmware-nonfree 20210208-1 upload

[maximilian attems]

> https://udd.debian.org/cgi-bin/key_packages.yaml.cgi disagrees. The
> release team uses this list as the canonical source for the
> implementation for the automatic blocks.

so please unblock firmware-nonfree 20210208-3

it is the version that has the relevant firmware packages for
the targeted version of linux in bullseye.

It will need a small amount of fixes on top that are preprared
in git and will be uploaded as soon it has migrated.

thank you.

-- 
maks


signature.asc
Description: PGP signature

Re: firmware-nonfree 20210208-1 upload

[maximilian attems]

On Mon, Mar 08, 2021 at 06:52:33PM +0100, Paul Gevers wrote:
> On 08-03-2021 10:39, maximilian attems wrote:
> > Tomorrow once firmware-nonfree has migrated 20210208-4 will be uploaded
> > with important small fixes to Raspberry Pi 4B and BananaPi M2 ultra and
> > BananaPi M3 supports. As all changes are quite small and current window
> > allows important fixes, I do not expect to need an unblock.
> 
> Ehm, firmware-nonfree is a key package. If the upload didn't happen
> somewhere before 2-3-2021 it will require an unblock.

the upload of 20210208-3 happened on 26/2/2021 [1].
[1] https://tracker.debian.org/pkg/firmware-nonfree

the next upload will happen *after* 2-3-2021, as it it is planned for
tomorrow. non-free packages were never considered key by Debian afair.
of course I am happy to ask for unblock for 20210208-4 should that be.

best,

-- 
maks


signature.asc
Description: PGP signature

Re: firmware-nonfree 20210208-1 upload

[maximilian attems]

Tomorrow once firmware-nonfree has migrated 20210208-4 will be uploaded
with important small fixes to Raspberry Pi 4B and BananaPi M2 ultra and
BananaPi M3 supports. As all changes are quite small and current window
allows important fixes, I do not expect to need an unblock.

best,

-- 
maks


signature.asc
Description: PGP signature

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

[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.

[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#984489: firmware-brcm80211: newer versions fail to load on raspberry pi 4b with "brcmf_sdio_htclk: HT Avail timeout"

[maximilian attems]

Dear Andres,

> 
> [   12.471809] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100):
> clkctl 0x50
> 
> 
> You can specifically see that the driver times out after one second
> with that error message, then times out again with the error and gives
> up. No wlan0 is available.
> 
> There are some pretty major firmware updates between those two
> versions, and they are generally Good. However, there's also some minor
> updates to the raspi4 board file
> /lib//firmware/brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt
> 
> If we revert the line "boardflags3=0x48200100" in that file back to
> what was in the 20201218-3 version (so it would instead be
> "boardflags3=0x44200100"), and then reboot, the driver now loads:

upstream indeed resets this line too,
boardflags3=0x44200100
seen in 58825f74eb0156822065c449a770644a69044d88 of linux-firmware.git.
 
 
> [   23.961230] br0: port 3(wlan1) entered blocking state
> [   23.963358] br0: port 3(wlan1) entered disabled state
> [   23.966488] device wlan1 entered promiscuous mode
> [   29.417766] br0: port 2(wlan0) entered blocking state
> [   29.419853] br0: port 2(wlan0) entered forwarding state
> 
> 
> 
> I'm not sure if the driver needs fixing, or if the boardflags need
> fixing, but the boardflags thing seems to be a functional workaround
> for users hitting this issue. Thanks to Steev Klimaszewski for helping
> me figure out the workaround.

I will upload -4 with that fix as soon as -3 finaly hits testing
to push that minor change to upcoming release.


Thank you for your report!

-- 
maks

Bug#982579: Solution for loading firmware

[maximilian attems]

> Both patches applied and pushed out.

great thank you.
 
> In the future, could you please send the patches either as direct
> emails or as attachments or as pull requests?  When you embed them in
> the body of the email I have to manually adjust them to get the commit
> log properly included.

sure, will do as pull request.

Re: firmware-nonfree 20210208-1 upload

[maximilian attems]

Following up today with 20210208-3 due to missing cxgb4 config files
pointed at with the new symlinks. The search led into important missing
firmwares in intel-sound, misc-nonfree and atheros, which are now added.

-- 
maks


signature.asc
Description: PGP signature

Bug#983561: firmware-misc-nonfree: broken-symlink /lib/firmware/cxgb4/t4-config.txt and others

[maximilian attems]

On Fri, Feb 26, 2021 at 12:17:50PM +0100, Cyril Brulebois wrote:
> kibi@tokyo:~/debian-kernel/firmware-nonfree.git$ 
> ./debian/bin/check_upstream.py | sort | grep 'in any binary package'
> I: amd/amd_sev_fam17h_model0xh.sbin is not included in any binary package
> I: amd/amd_sev_fam17h_model3xh.sbin is not included in any binary package

need to recheck if those are not meant to be in the microcode amd64 guy.

> I: cadence/mhdp8546.bin is not included in any binary package

hmm

> →   I: cxgb4/configs/t4-config-default.txt is not included in any binary 
> package
> →   I: cxgb4/configs/t5-config-default.txt is not included in any binary 
> package
> I: cxgb4/configs/t5-config-hashfilter.txt is not included in any binary 
> package
> →   I: cxgb4/configs/t6-config-default.txt is not included in any binary 
> package
> I: cxgb4/configs/t6-config-hashfilter.txt is not included in any binary 
> package

fixed.

> I: inside-secure/eip197_minifw/ifpp.bin is not included in any binary 
> package
> I: inside-secure/eip197_minifw/ipue.bin is not included in any binary 
> package

no idea.

> I: intel/dsp_fw_cnl_v1191.bin is not included in any binary package
> I: intel/fw_sst_0f28_ssp0.bin is not included in any binary package
> I: intel/irci_irci_ecr-master_20161208_0213_20170112_1500.bin is not 
> included in any binary package
> I: iwlwifi-9000-pu-b0-jf-b0-43.ucode is not included in any binary package
> I: iwlwifi-9260-th-b0-jf-b0-43.ucode is not included in any binary package

will fix soonish.

> I: mediatek/mt7622_n9.bin is not included in any binary package
> I: mediatek/mt7622_rom_patch.bin is not included in any binary package
> I: mediatek/mt8183/scp.img is not included in any binary package

hmm.

> I: mellanox/mlxsw_spectrum2-29.2000.2308.mfa2 is not included in any 
> binary package

mellanox is kind of excluded irc.

> I: meson/vdec/g12a_h264.bin is not included in any binary package
> I: meson/vdec/g12a_hevc_mmu.bin is not included in any binary package
> I: meson/vdec/g12a_vp9.bin is not included in any binary package
> I: meson/vdec/gxbb_h264.bin is not included in any binary package
> I: meson/vdec/gxl_h263.bin is not included in any binary package
> I: meson/vdec/gxl_h264.bin is not included in any binary package
> I: meson/vdec/gxl_hevc.bin is not included in any binary package
> I: meson/vdec/gxl_hevc_mmu.bin is not included in any binary package
> I: meson/vdec/gxl_mjpeg.bin is not included in any binary package
> I: meson/vdec/gxl_mpeg12.bin is not included in any binary package
> I: meson/vdec/gxl_mpeg4_5.bin is not included in any binary package
> I: meson/vdec/gxl_vp9.bin is not included in any binary package
> I: meson/vdec/gxm_h264.bin is not included in any binary package
> I: meson/vdec/sm1_hevc_mmu.bin is not included in any binary package
> I: meson/vdec/sm1_vp9_mmu.bin is not included in any binary package
> I: microchip/mscc_vsc8574_revb_int8051_29e8.bin is not included in any 
> binary package
> I: microchip/mscc_vsc8584_revb_int8051_fb48.bin is not included in any 
> binary package

another hmm

> I: qca/nvm_00230302.bin is not included in any binary package
> I: qca/nvm_00440302_eu.bin is not included in any binary package
> I: qca/nvm_00440302_i2s_eu.bin is not included in any binary package
> I: qca/nvm_usb_0302_eu.bin is not included in any binary package

those I'll fix too.

> I: qed/qed_init_values_zipped-8.37.7.0.bin is not included in any binary 
> package
> I: r8a779x_usb3_v1.dlmem is not included in any binary package
> I: r8a779x_usb3_v2.dlmem is not included in any binary package
> I: r8a779x_usb3_v3.dlmem is not included in any binary package
> I: rtw88/README is not included in any binary package
> I: ti-keystone/ks2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin is not included in 
> any binary package

oh well none of those appear to generate much attention.


thank you!

-- 
maks


signature.asc
Description: PGP signature

Bug#983561: firmware-misc-nonfree: broken-symlink /lib/firmware/cxgb4/t4-config.txt and others

[maximilian attems]

On Fri, Feb 26, 2021 at 12:08:55PM +0100, Cyril Brulebois wrote:
> > 
> > Link: cxgb4/t4-config.txt -> configs/t4-config-default.txt
> > Link: cxgb4/t5-config.txt -> configs/t5-config-default.txt
> > Link: cxgb4/t6-config.txt -> configs/t6-config-default.txt
> 
> debian/config/misc-nonfree/defines looks like it might be missing the
> targets of the symlinks (cxgb4/configs/t?-config-default.txt), meaning
> the File entries get installed in the build directory through the WHENCE
> processing, but those files aren't listed in the FILES variable when
> building the binary package, so they don't end up being actually shipped,
> hence the broken symlinks?

thank you a lot for the prompt look and indeed those config files
were not added, updated the repo to fix that in next upload.

are there other dangling symlinks besides this three mentioned ones?

best,

-- 
maks


signature.asc
Description: PGP signature

Bug#983561: firmware-misc-nonfree: broken-symlink /lib/firmware/cxgb4/t4-config.txt and others

[maximilian attems]

> Usertags: adequate broken-symlink
> X-Debbugs-Cc: t...@mirbsd.de
> 
> firmware-misc-nonfree: broken-symlink /lib/firmware/cxgb4/t4-config.txt -> 
> configs/t4-config-default.txt
> firmware-misc-nonfree: broken-symlink /lib/firmware/cxgb4/t5-config.txt -> 
> configs/t5-config-default.txt
> firmware-misc-nonfree: broken-symlink /lib/firmware/cxgb4/t6-config.txt -> 
> configs/t6-config-default.txt

why is this a broken symlink? this is what upstream wants in WHENCE:

Link: cxgb4/t4-config.txt -> configs/t4-config-default.txt
Link: cxgb4/t5-config.txt -> configs/t5-config-default.txt
Link: cxgb4/t6-config.txt -> configs/t6-config-default.txt

-- 
maks

Re: firmware-nonfree 20210208-1 upload

[maximilian attems]

Following up today with a quite targeted 20210208-2 with only minimal
changes fixing the RC bug and adding a missing config file.

best,

-- 
maks


signature.asc
Description: PGP signature

Bug#983255: firmware-realtek: Direct firmware load for rtw88/rtw8821c_fw.bin failed with error -2

[maximilian attems]

> lspci | grep -i wire
> 02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821CE 
> 802.11ac PCIe Wireless Network Adapter
> 
> dmesg contains these lines: 
> 
> [4.938468] rtw_8821ce :02:00.0: Direct firmware load for 
> rtw88/rtw8821c_fw.bin failed with error -2
> [4.938472] rtw_8821ce :02:00.0: failed to request firmware
> [4.938543] rtw_8821ce :02:00.0: failed to load firmware
> [4.938571] rtw_8821ce :02:00.0: failed to setup chip efuse info
> [4.938599] rtw_8821ce :02:00.0: failed to setup chip information
> [4.939514] rtw_8821ce: probe of :02:00.0 failed with error -22
> 
> tried to install also latest firmware-realtek from unstable 
> ii  firmware-realtek20210208-1
>   all  Binary firmware for Realtek wired/wifi/BT adapters
> but this did also not change anything. 

there is a newer version of this firmware v9.9.5 in the upstream repository,
could you test commit 80cb579614ee576ae74e650fa0b43d9f7c212039
in linux-firmware git:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

It only says "Refine firmware to improve performance." so if it still
does not work upstream realtek should be informed.
 
 
>* What outcome did you expect instead?
> 
> wlan working as before. 
> 
> 

Thank you for your report.


signature.asc
Description: PGP signature

Bug#982579: Solution for loading firmware

[maximilian attems]

please also add BananaPi M3 support.


>From 216a0bda280e7b361c335f545156e86a059d9551 Mon Sep 17 00:00:00 2001
From: maximilian attems 
Date: Mon, 22 Feb 2021 22:18:36 +0100
Subject: [PATCH 2/2] WHENCE: add missing symlink for BananaPi M3

Fixes (Debian bug #982579):
> [   11.957171] brcmfmac mmc2:0001:1: firmware: failed to load
brcm/brcmfmac43430-sdio.sinovoip,bpi-m3.txt (-2)
> [   11.967106] firmware_class: See https://wiki.debian.org/Firmware for
information about missing firmware
> [   11.977035] brcmfmac mmc2:0001:1: firmware: failed to load
brcm/brcmfmac43430-sdio.txt (-2)
> [   12.994756] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100): clkctl
0x50

Reported-by: Bernhard 
Signed-off-by: maximilian attems 
---
 WHENCE | 1 +
 1 file changed, 1 insertion(+)

diff --git a/WHENCE b/WHENCE
index 11c0970..b569990 100644
--- a/WHENCE
+++ b/WHENCE
@@ -2717,6 +2717,7 @@ File: "brcm/brcmfmac43430-sdio.AP6212.txt"
 Link: brcm/brcmfmac43430-sdio.sinovoip,bpi-m2-plus.txt -> 
brcmfmac43430-sdio.AP6212.txt
 Link: brcm/brcmfmac43430-sdio.sinovoip,bpi-m2-zero.txt -> 
brcmfmac43430-sdio.AP6212.txt
 Link: brcm/brcmfmac43430-sdio.sinovoip,bpi-m2-ultra.txt -> 
brcmfmac43430-sdio.AP6212.txt
+Link: brcm/brcmfmac43430-sdio.sinovoip,bpi-m3.txt -> 
brcmfmac43430-sdio.AP6212.txt
 File: "brcm/brcmfmac43430-sdio.Hampoo-D2D3_Vi8A1.txt"
 File: "brcm/brcmfmac43430-sdio.MUR1DX.txt"
 File: "brcm/brcmfmac43430-sdio.raspberrypi,3-model-b.txt"
-- 
2.30.0

Bug#982579: Solution for loading firmware

[maximilian attems]

> The additional symlink bpi-m3 is for an additional device.
> 
> This is for the Banana Pi M3.

great, please post the dmesg error message, happy to submit upstream. (:
 
> Should i create an additional Bug report?

no need, this bug report can be cloned.

Bug#982579: Solution for loading firmware

[maximilian attems]

> > 1. Copy file brcmfmac43430-sdio.AP6212.txt from upstream to 
> > lib/firmware/brcm
> 
> so indeed it is a bug that we don't ship this one from upstream,
> will fix this in next Debian upload.

this needs to go in the debian git, will do soonish. (:
 
> > 2. Create symbolic link named brcmfmac43430-sdio.sinovoip.bpi-m3.txt to the 
> > AP6212-file

I am confused by this, as you did *not* submit an error log that showed
a request for this file, is this to add support to another device,
please be specific.

> > 3. Create symbolic link named brcmfmac43430-sdio.sinovoip.bpi-m2-ultra.txt 
> > to the AP6212-file
> this should be reported upstream, so that everyone takes advantage of
> it, hence adding linux-firmware mailinglist on Cc, happy to cook up
> a patch next 24hs.

sent, to add that symlink upstream.


thank you!

-- 
maks


signature.asc
Description: PGP signature

Bug#982579: Solution for loading firmware

[maximilian attems]

please find patch to add banana ultra support below

>From b549a10838edc4f97d4a3b49b572fc613c7c703d Mon Sep 17 00:00:00 2001
From: maximilian attems 
Date: Tue, 16 Feb 2021 19:35:27 +0100
Subject: [PATCH] Add symlink for BananaPi M2 to brcmfmac43430-sdio config

Fixes ( Debian bug #982579 [1]):
 [   10.514530] brcmfmac mmc2:0001:1: firmware: direct-loading firmware 
brcm/brcmfmac43430-sdio.bin
 [   10.514732] brcmfmac mmc2:0001:1: firmware: failed to load 
brcm/brcmfmac43430-sdio.sinovoip,bpi-m2-ultra.txt ( -2)

Refs:
[1] https://bugs.debian.org/982579

Reported-by: Bernhard 
Signed-off-by: maximilian attems 
---
 WHENCE | 1 +
 1 file changed, 1 insertion(+)

diff --git a/WHENCE b/WHENCE
index aa96404..11c0970 100644
--- a/WHENCE
+++ b/WHENCE
@@ -2716,6 +2716,7 @@ File: "brcm/brcmfmac43430a0-sdio.ONDA-V80 PLUS.txt"
 File: "brcm/brcmfmac43430-sdio.AP6212.txt"
 Link: brcm/brcmfmac43430-sdio.sinovoip,bpi-m2-plus.txt -> 
brcmfmac43430-sdio.AP6212.txt
 Link: brcm/brcmfmac43430-sdio.sinovoip,bpi-m2-zero.txt -> 
brcmfmac43430-sdio.AP6212.txt
+Link: brcm/brcmfmac43430-sdio.sinovoip,bpi-m2-ultra.txt -> 
brcmfmac43430-sdio.AP6212.txt
 File: "brcm/brcmfmac43430-sdio.Hampoo-D2D3_Vi8A1.txt"
 File: "brcm/brcmfmac43430-sdio.MUR1DX.txt"
 File: "brcm/brcmfmac43430-sdio.raspberrypi,3-model-b.txt"
-- 
2.30.0

Bug#982757: firmware-brcm80211: [REGRESSION] brcm/brcmfmac43340-sdio.bin missing in sid (20210208-1)

[maximilian attems]

severity 982757 critical
stop

> Version: 20201218-3
> Severity: normal

thank you for the report, oh boy this one is opens a can of trouble.
It seems I was blissfully unaware that the Debian packaging did not
take into account the symlinks of upstream linux-firmware WHENCE file.
So this means we are missing a *lot* - all the symlinks!?!?
 
> after latest update wifi stopped working and I saw that 
> brcm/brcmfmac43340-sdio.bin was missing,

right it was replaced by newer cypress version and there should be
a symlink of that guy from the older name:

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

Could you please test latest 2021 upstream package with this symlink?

kind regards,

-- 
maks


signature.asc
Description: PGP signature

Bug#982579: Solution for loading firmware

[maximilian attems]

Dear Bernhard,

Thank you very much for your clear and helpful report!

> I tested the following:
> 
> 1. Copy file brcmfmac43430-sdio.AP6212.txt from upstream to lib/firmware/brcm

so indeed it is a bug that we don't ship this one from upstream,
will fix this in next Debian upload.

> 2. Create symbolic link named brcmfmac43430-sdio.sinovoip.bpi-m3.txt to the 
> AP6212-file
> 3. Create symbolic link named brcmfmac43430-sdio.sinovoip.bpi-m2-ultra.txt to 
> the AP6212-file

this should be reported upstream, so that everyone takes advantage of
it, hence adding linux-firmware mailinglist on Cc, happy to cook up
a patch next 24hs.
 
> After that, the wlan0 interface is available and scanning of the WLAN-ESSIDs 
> works.

great!

 
> Please either do it like described above or add the files directly instead of 
> the symbolic links.

The symbolic links are better than duplicated files, but there seem to
be on the Debian side an opened can of trouble on them, see #982757
(I'll post there soonish)
 
Thank you for the kind words, the test and your report!

-- 
maks


signature.asc
Description: PGP signature

Bug#982579: Failed to load firmware brcmfmac43430-sdio at BananaPi M2

[maximilian attems]

> > [   10.514530] brcmfmac mmc2:0001:1: firmware: direct-loading firmware 
> > brcm/brcmfmac43430-sdio.bin
> > [   10.514732] brcmfmac mmc2:0001:1: firmware: failed to load 
> > brcm/brcmfmac43430-sdio.sinovoip,bpi-m2-ultra.txt (
> > -2)

this txt file is missing upstream, once someone (preferrably its
author submits it to linux-firmware) w appropriate license we are
happy to ship it -> latest git is here:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

> Please add the corresponding firmware.

once it is upstream, sure. please feel free to bug the bpi m2 guys
to do so.

thank you,

-- 
maks

Bug#893912: missing rtl_bt/rtl8821a_config.bin

[maximilian attems]

Dear Yang,

Would it be possible to add rtl8821a_config.bin config file?

According to two bug reports, current state results in the following
failure:
--
[2.574742] Bluetooth: hci0: rtl: loading rtl_bt/rtl8821a_config.bin
[2.575137] bluetooth hci0: firmware: failed to load
rtl_bt/rtl8821a_config.bin (-2)
[2.575143] bluetooth hci0: Direct firmware load for
rtl_bt/rtl8821a_config.bin failed with error -2
[2.575145] Bluetooth: hci0: Failed to load
rtl_bt/rtl8821a_config.bin
--

According to bug reporter symlink of rtl8821c_config.bin to
rtl8821a_config.bin (
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893912#32 )
solves the issue.
Or do you have this specific files and could push it upstream to
linux-firmware?


Thank you in advance.

-- 
maks


signature.asc
Description: PGP signature

firmware-nonfree 20210208-1 upload

[maximilian attems]

Hello everyone,

Just quick notice that newest upstream will be uploaded tomorrow to sid.
It has relevant updates for Intel bluetooth && realtek.
I plan to ask for a freeze exception to have the corresponding firmwares
for current linux.

best,

-- 
maks


signature.asc
Description: PGP signature

Re: Processed: firmware-nonfree: Add brcm-bluetooth (for RaspberryPi)

[maximilian attems]

> Bug #962038 [raspi-firmware] firmware-nonfree: Add brcm-bluetooth (for 
> RaspberryPi)

that be very possible to add and create a firmware package for that,
but first this
https://github.com/RPi-Distro/bluez-firmware/tree/master/broadcom
would have to land upstream in linux-firmware.

Have you tried to submit them, phil?


signature.asc
Description: PGP signature

Bug#981005: linux-image-5.10.0-2-amd64: Bluetooth stopped working

[maximilian attems]

> After upgrading to Linux 5.10, Bluetooth no longer works. Bluetooth
> adapter still shows up in rfkill:
> 
> When booting from Linux 5.9, Bluetooth works fine.
> 
> During start-up with Linux 5.10, there's an error message about
> Bluetooth firmware.

please provide 5.10.9 dmesg.

Bug#973454: firmware-iwlwifi: firmware does not load with error -110 with Intel 8260

[maximilian attems]

On Fri, Jan 22, 2021 at 10:16:36PM +0100, Paweł Różański wrote:
> On 22.01.2021 21:44, maximilian attems wrote:
> > > Version: 20200918-1
> > 
> > > [   12.411452] iwlwifi :01:00.0: Failed to start INIT ucode: -110
> > > [   12.411500] iwlwifi :01:00.0: Collecting data: trigger 16 fired.
> > > [   13.566350] iwlwifi :01:00.0: Failed to run INIT ucode: -110
> > > uanme -rvm
> > > 5.9.0-1-amd64 #1 SMP Debian 5.9.1-1 (2020-10-17) x86_64
> > > (also tested on 5.7.0-2-amd64 #1 SMP Debian 5.7.10-1 (2020-07-26) x86_64 
> > > - the same)
> > > 
> > > Used to work fine before reboot with 5.7 kernel.
> > > Can provide additional information if needed.
> > 
> > Is this still happening with 5.10 linux and newer iwlwifi version >=
> > 202011?
> 
> 
>  Using 5.10.0-1-amd64 and 20200918-1 till now. Just upgraded to 20201218-2,
> but didn't reboot yet.
>  Issue never repeated since I sent this report.

thanks for patience and prompt report, this looks like to be fixed in
iwlwifi then.

I'll leave it open for a week and will then proceed to close unless
repeatable.

Bug#963025: firmware-iwlwifi: Microcode SW error detected / 9000-pu-b0-jf-b0-46.ucode

[maximilian attems]

> Firmware 9000-pu-b0-jf-b0-46.ucode stops working when used with
> hostapd as soon as a wireless client connects.

Is that still happening with latest 5.10 linux and newer
firmware-iwlwifi version >= 202011?

thank you.

Bug#973454: firmware-iwlwifi: firmware does not load with error -110 with Intel 8260

[maximilian attems]

> Version: 20200918-1

> [   12.411452] iwlwifi :01:00.0: Failed to start INIT ucode: -110
> [   12.411500] iwlwifi :01:00.0: Collecting data: trigger 16 fired.
> [   13.566350] iwlwifi :01:00.0: Failed to run INIT ucode: -110
 
> uanme -rvm
> 5.9.0-1-amd64 #1 SMP Debian 5.9.1-1 (2020-10-17) x86_64 
> (also tested on 5.7.0-2-amd64 #1 SMP Debian 5.7.10-1 (2020-07-26) x86_64 - 
> the same)
> 
> Used to work fine before reboot with 5.7 kernel.
> Can provide additional information if needed.

Is this still happening with 5.10 linux and newer iwlwifi version >=
202011?

thank you.

Re: firmware-nonfree 20201118-1 upload

[maximilian attems]

> As soon as 20201022-1 migrates will upload 20201118-1 to sid,
> current git allmost ready for it with big ath11k dumps
> (after that will prepare 20201218-1 which has more intel bt updates).

Now that 20201118-1 migrated, I am uploading today 20201218-1.

best,

-- 
maks


signature.asc
Description: PGP signature

firmware-nonfree 20201118-1 upload

[maximilian attems]

Hello everyone,

As soon as 20201022-1 migrates will upload 20201118-1 to sid,
current git allmost ready for it with big ath11k dumps
(after that will prepare 20201218-1 which has more intel bt updates).

best,

-- 
maks


signature.asc
Description: PGP signature

firmware-nonfree 20201022-1 upload

[maximilian attems]

Happy 2021 everyone.

Today will upload this release.
sorry for short notice, anything falling through cracks will be
in the following nov release.

best,

-- 
maks


signature.asc
Description: PGP signature

Re: Bug#970395: firmware-nonfree: Please add AMD-SEV firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs

[maximilian attems]

Dear Henrique,

It be great to get your input, hence repinging (;

Especially as linux-firmware is the common upstream source, it be ideal to ship
the amd64 mircrocode out of our firmware packages.

Thanks for letting us know.

kind regards,
maximilian

On Sun, Sep 20, 2020 at 10:36:12AM +0200, maximilian attems wrote:
> Dear Henrique, dear debian kernel maintainers, Cc: Michael,
> 
> Would you agree to generate the amd64-firmware packages directly out of the 
> debian
> linux-firmware source package?
> 
> This way the microcode would be updated on every linux-firmware non-free 
> upload?
> I am asking as it keeps nugging me to have to outcomment the updates of that
> microcode in the changelog (there is again a new one for the upcoming 
> 20200918).
> 
> Would you want to be added in counterpart to the uploaders of 
> firmware-nonfree?
> 
> Thank you very much for your amd64 microcode work.
> 
> kind regards,
> maximilian
> 
> On Tue, Sep 15, 2020 at 04:55:43PM +0200, Michael Musenbrock wrote:
> > Source: firmware-nonfree
> > Severity: important
> > 
> > Dear maintainer,
> > 
> > first of all thanks for maintaining and packaging the linux-firmware files 
> > repository as debian packages.
> > 
> > We currently need to manually obtain the 
> > linux-firmware.git:amd/amd_sev_fam17h_model3xh.sbin [1] file on
> > our AMD EPYC servers. The firmware files containing the AMD SEV firmware 
> > closing security vulnerabilities [2]
> > and fixes bugs and adds improvements to the AMD SEV implementation.
> > 
> > I'm most likely unqualified for legal questions but the LICENSE.amd-sev [3] 
> > reads quite similar to the already
> > added amdgpu license [4]. So I hope this is not the reason, why those files 
> > were not added in the past.
> > 
> > The severity was choosen because it fixes a security vulnerability, please 
> > change accordingly if you think
> > it is wrong.
> > 
> > Thanks in advance. Best regards,
> > michael
> > 
> > [1] 
> > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amd
> > [2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9836
> > [3] 
> > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENSE.amd-sev
> > [4] 
> > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENSE.amdgpu
> > 




signature.asc
Description: PGP signature

firmware-nonfree 20200918-1 upload

[maximilian attems]

Tomorrow will upload this release.
 
best,
 
-- 
maks


signature.asc
Description: PGP signature

Re: Bug#970395: firmware-nonfree: Please add AMD-SEV firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs

[maximilian attems]

Dear Henrique, dear debian kernel maintainers, Cc: Michael,

Would you agree to generate the amd64-firmware packages directly out of the 
debian
linux-firmware source package?

This way the microcode would be updated on every linux-firmware non-free upload?
I am asking as it keeps nugging me to have to outcomment the updates of that
microcode in the changelog (there is again a new one for the upcoming 20200918).

Would you want to be added in counterpart to the uploaders of firmware-nonfree?

Thank you very much for your amd64 microcode work.

kind regards,
maximilian

On Tue, Sep 15, 2020 at 04:55:43PM +0200, Michael Musenbrock wrote:
> Source: firmware-nonfree
> Severity: important
> 
> Dear maintainer,
> 
> first of all thanks for maintaining and packaging the linux-firmware files 
> repository as debian packages.
> 
> We currently need to manually obtain the 
> linux-firmware.git:amd/amd_sev_fam17h_model3xh.sbin [1] file on
> our AMD EPYC servers. The firmware files containing the AMD SEV firmware 
> closing security vulnerabilities [2]
> and fixes bugs and adds improvements to the AMD SEV implementation.
> 
> I'm most likely unqualified for legal questions but the LICENSE.amd-sev [3] 
> reads quite similar to the already
> added amdgpu license [4]. So I hope this is not the reason, why those files 
> were not added in the past.
> 
> The severity was choosen because it fixes a security vulnerability, please 
> change accordingly if you think
> it is wrong.
> 
> Thanks in advance. Best regards,
> michael
> 
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amd
> [2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9836
> [3] 
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENSE.amd-sev
> [4] 
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENSE.amdgpu
> 


signature.asc
Description: PGP signature

Bug#969961: firmware-amd-graphics: amdgpu requires firmware installed even it already has been installed

[maximilian attems]

>* What led up to the situation?
>   None, just boot up.
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>   1. Go to tty2, login. Enter "sudo modprobe -r amdgpu"
>   2. Then, Enter "sudo modprobe -i amdgpu"
>* What was the outcome of this action?
>   None graphics shows up..Startx failed too.
>* What outcome did you expect instead?
>   No error shows and graphics shows up.

Have you tried newer amd microcode (as far as I remember Debian has an 2019 
outdated one)?


also linux 5.8 in unstable would be worth a try.


thanks.

-- 
maks
 

Bug#969979: linux-image-4.19.0-6-amd64: checkarray on degraded RAID array crashes the system

[maximilian attems]

On Wed, Sep 09, 2020 at 08:34:16PM +0200, Seb wrote:
> 
> > > Package: src:linux
> > > Version: 4.19.67-2+deb10u2
> > [...]
> > This version is 10 months old; please upgrade and try again as the bug
> > may have been fixed already.
> 
> OK, I will, but I do not know how to properly upgrade the kernel on a
> Debain-stable system (which is up-to-date with respect to "apt upgrade").
> Could you enlighten me and say which kernel version I should try?

How about: apt-get dist-upgrade
What is its output?
of course reboot after upgrade.

best,

-- 
maks

firmware-nonfree 20200817-1 upload

[maximilian attems]

Tomorrow will upload this release.
 
best,
 
-- 
maks


signature.asc
Description: PGP signature

upload firmware-nonfree 20200721-1

[maximilian attems]

Hello,

Plan to upload tomorrow 20200721-1 to unstable
and then move repository to 20200817.

best,

-- 
maks


signature.asc
Description: PGP signature

Re: Support for Intel WiFi 6 AX201 160 MHz

[maximilian attems]

hello,

> when can Debian support for Intel WiFi 6 AX201 160 MHz be expected?

what are you missing in testing / bullseye?


--
maks

Re: [PATCH v2] deb-pkg: generate correct build dependencies

[maximilian attems]

On Wed, Jan 02, 2019 at 07:48:12PM +, Ben Hutchings wrote:
> On Wed, 2019-01-02 at 11:23 +0200, riku.voi...@linaro.org wrote:
> > From: Riku Voipio 
> > 
> > bison/flex is now needed always for building for kconfig. Some build
> > dependencies depend on kernel configuration, enable them as needed:
> > 
> > - libelf-dev when UNWINDER_ORC is set
> > - libssl-dev for SYSTEM_TRUSTED_KEYRING
> > 
> > Since the libssl-dev is needed for extract_cert binary, denote with
> > :native to install the libssl-dev for the build machines
> > architecture,
> > rather than for the architecture of the kernel being built.
> > 
> > Tested-by: Manivannan Sadhasivam 
> > Signed-off-by: Riku Voipio 
> 
> Reviewed-by: Ben Hutchings 

Acked-by: maximilian attems 
 
> > ---
> > v2: commit message updated
> > ---
> >  scripts/package/mkdebian | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/scripts/package/mkdebian b/scripts/package/mkdebian
> > index edcad61fe3cd..c858abf4569e 100755
> > --- a/scripts/package/mkdebian
> > +++ b/scripts/package/mkdebian
> > @@ -134,6 +134,8 @@ fi
> >  
> >  mkdir -p debian/
> >  echo $debarch > debian/arch
> > +extra_build_depends=", $(if_enabled_echo UNWINDER_ORC libelf-dev)"
> > +extra_build_depends="$extra_build_depends, $(if_enabled_echo 
> > SYSTEM_TRUSTED_KEYRING libssl-dev:native)"
> >  
> >  # Generate a simple changelog template
> >  cat < debian/changelog
> > @@ -170,7 +172,7 @@ Source: $sourcename
> >  Section: kernel
> >  Priority: optional
> >  Maintainer: $maintainer
> > -Build-Depends: bc, kmod, cpio
> > +Build-Depends: bc, kmod, cpio, bison, flex $extra_build_depends
> >  Homepage: http://www.kernel.org/
> >  
> >  Package: $packagename
> -- 
> Ben Hutchings
> Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer
> 
> 

Re: enabling orange-fs support

[maximilian attems]

Dear Alois Schlögl,

On Sat, Oct 20, 2018 at 02:36:05PM +0200, Alois Schloegl wrote:
> 
> We are looking into distributed, parallel filesystems like beegfs and
> orangefs. I'd prefer orangefs (mainly because of its license terms).
> 
> We'd like to use Debian/stable for this set up, unfortunately, the
> current debian kernel has orange-fs support disabled.

I see it got merged in 4.9 hence stable would be possible.
 
 
> Is there a chance that orange-fs will be supported in future
> debian-kernel releases ? What is  the reason for not enabling orange-fs
> (except that the configuration resides only in the "miscellaneous
> filesystem") ?

Unless it has other dependencies, which I haven't checked,
it is very likely an oversight.
 
> What would be needed in order to enable orange-fs support in the debian
> kernel releases ?

Would you mind filling a wishlist bug against the unstable linux-image?
Then once changed this would propagate into Testing.
Afterwards this could be considered for a next stable update.
 
Thanks for your input!

Kind regards,
maximilian

Re: [ad...@alioth-lists.debian.net: Notice of mailing list closure: kernel-svn-changes]

[maximilian attems]

On Wed, Apr 04, 2018 at 01:40:09PM +0100, Ben Hutchings wrote:
> 
> 
> On 4 April 2018 11:04:33 BST, maximilian attems <m...@stro.at> wrote:
> >Dear Ben,
> >
> >Anything we'd want to migrate from the old list?
> [...]
> 
> All VCS changes on Salsa are mailed out via tracker.debian.org so there's no 
> need for a new mailing list.

right, just wanted to make sure everything is fine.
So will let the maling-list expire, just emailed out the
last held bigger changelogs.

thanks,
maks

[ad...@alioth-lists.debian.net: Notice of mailing list closure: kernel-svn-changes]

[maximilian attems]

Dear Ben,

Anything we'd want to migrate from the old list?

thanks,
maks

- Forwarded message from alioth lists migration team 
 -

Date: Mon, 2 Apr 2018 16:21:19 +0100
From: alioth lists migration team 
To: kernel-svn-chan...@lists.alioth.debian.org
Subject: Notice of mailing list closure: kernel-svn-changes
X-Mailer: MIME::Lite 3.030 (F2.85; T2.13; A2.18; B3.15; Q3.13)

Dear list subscribers,

As per the announcement on debian-devel-announce[1] and as part of
the shutdown of the alioth service, the migration of
lists.alioth.debian.org mailing lists to alioth-lists.debian.net is now
underway.

We tried to contact the designated list owner via
kernel-svn-changes-ow...@lists.alioth.debian.org but got either no reply,
or a bounce message. Accordingly, this list will not be migrated to the
new system and will stop working on 14th April.

Information about alternatives to this service which may be more suitable
for the list can be found at
.

In the event that this list should be migrated to the new system,
please first appoint a Debian developer as a list owner, then let us know
by replying to this email, copying in the list.

More information about the new service can be found here:


Thanks,
the alioth-lists migration team.

[1] 



___
Kernel-svn-changes mailing list
kernel-svn-chan...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/kernel-svn-changes

- End forwarded message -

Re: Intel Vulnerability

[maximilian attems]

Dear Ozgur,

On Fri, Jan 05, 2018 at 10:29:56AM +0300, Ozgur wrote:
> 
> thanks for reply and I'm using the stable version (Debian stretch). I updated 
> last night and I don't seen any new kernel patch yet.
> 

Please use a user list for your support, this mailing list is for development 
purpose.

thank you,

-- 
maks

Re: recommends for apparmor in newest linux-image-4.13

[maximilian attems]

On Thu, Nov 23, 2017 at 03:00:49PM +0100, Wouter Verhelst wrote:
> On Thu, Nov 23, 2017 at 02:18:46PM +0100, Christoph Hellwig wrote:
> > Hi all,
> > 
> > is there any good reason for the recommends of apparmor in the latest
> > linux packages?
> 
> This is in response to a discussion that happened on this list. The
> thread started in august last year[1], but really picked up speed last
> month[2] and this one[3].
> 
> The idea is that, if no critical issues are found, buster would release
> with AppArmor enabled by default. If critical issues are found, however,
> I expect the decision will be reversed (or at the least, postponed).
> 
> [1] https://lists.debian.org/debian-devel/2017/08/msg00090.html
> [2] https://lists.debian.org/debian-devel/2017/10/threads.html#00086
> [3] https://lists.debian.org/debian-devel/2017/11/threads.html#0
> 

This doesn't strike me as a discussion, but looks more like a predetermined 
setup.

Re: Linux 4.9 will be next LTS

[maximilian attems]

On Sat, Aug 13, 2016 at 07:48:07PM +0100, Ben Hutchings wrote:
> On Fri, 2016-08-12 at 12:15 -0700, Martin Michlmayr wrote:
> > 
> > Greg KH announced that 4.9 would become the next LTS release:
> > 
> > https://plus.google.com/+gregkroahhartman/posts/DjCWwSo7kqY
> 
> Then that should be the version to use in stretch, and we have a rather
> less tight schedule to prepare for release.
 

sounds good indeed.

-- 
maks


signature.asc
Description: PGP signature

Re: Kernel version for stretch

[maximilian attems]

On Sat, Jan 30, 2016 at 03:30:37PM +0100, Moritz Muehlenhoff wrote:
> On Thu, Jan 28, 2016 at 11:42:13PM +0100, maximilian attems wrote:
> > 
> > Well, those efforts have not a good track record, afais Ben is maintaining
> > their lts Linus.
> 
> I don't really understand the second half of your sentence,

one funny typo, here s/Linus/Linux/.

> but they certainly
> have a good track record: After all Jessie is based on their ckt 3.16 series
> and their 3.19 kernel is also working very well (we're using it at work 
> on top of jessie since 3.16 has some mm problems under high load). I've been 
> forwarding patches for merging to Luis and Kamal for quite a while now and 
> they've always been really responsive and helpful.

It is not an upstream sanctioned stable release and Jessie ended up squeezed.

Re: Kernel version for stretch

[maximilian attems]

On Thu, Jan 28, 2016 at 08:01:13PM +0100, Moritz Mühlenhoff wrote:
> Ben Hutchings  wrote:
> > For stretch, I would very much like to choose a kernel version for
> > stretch that gets longterm maintenance by Greg Kroah-Hartman. That
> > lasts 2 years from release, after which someone else (maybe me) can
> > take over.
> 
> Luis Henriques and Kamal Mostafa maintain the ckt stable kernels
> for Ubuntu-non-LTS releases for two years.
> 

Well, those efforts have not a good track record, afais Ben is maintaining
their lts Linus.

-- 
maks

Re: erro bluetooth

[maximilian attems]

exceptional answer in spanish below.

--

Olá,

la lista es in inglés, adémas tu mail no contiene información útil
per resolvar la causa. si tu eres fisico debe hablar inglés?

On Wed, Oct 21, 2015 at 11:30:41AM -0200, Manoel Pedro de Araújo wrote:
> Olá amigos estou com um problema em meu Bluetooth. Nao consigo
> fazer transferência de dados,
> 
> quando eu ligo meu pc aparece a mensagem: *Bluetooth hci0
>  hardware error 0x37*
> 
> Uso Debian8 com interface KDE
> 
> Ja atualizei o kernel e continua aparecendo a mesma mensagem.
> 
> Alguém sabe como resolver isso?

el bluetooth on mi thinkpad functiona, no sé quel systema no
messages lo ves.

-- 
maks

Re: Upstream source handling

[maximilian attems]

On Tue, Sep 08, 2015 at 10:52:57PM +0200, Bastian Blank wrote:
> During the linux packaging BoF at DebConf, Ben asked for usefull
> upstream source handling.  No compeling ones were mentioned.
> 
> Some years ago (yes, years), I proposed some schema based on submodules,
> but never got around to actually implement it.  I finally managed to do
> an initial implementation.  It currently lives in the linux.git in
> branch waldi/submodule.

shouldn't one use subtrees these days and not submodules.
submodules only live in contrib. subtrees got merged in
main git. 


-- 
maks

Re: Converting kernel svn to git

[maximilian attems]

On Thu, Aug 06, 2015 at 06:10:01PM +0100, Ben Hutchings wrote:
 
 No, I want that history and a break in history will just make my life
 harder.  If you only want some of the branches you can get those.

Ok, so let's go for history.
 
   Known bugs:
 [...]
  On the other hand, none of the known bugs you mention is a show-stopper
  for the transition from my side.
 
 Yes but they would be harder to fix later.  (git filter-branch is
 powerful but it invalidates everyone else's clones.)

can you fix some of them in svn (preimport)? or does it need git-filter
changes?


-- 
maks


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150810200147.GA7913@gluino

Re: Converting kernel svn to git

[maximilian attems]

Hello everyone,

On Wed, Aug 05, 2015 at 12:46:47PM +0100, Ben Hutchings wrote:
 We've been talking about this for at least 6 years, and it's well past
 time to do it.

thanks a lot Ben for pushing this.
 
 (I think most developers are already using git-svn, but that doesn't
 properly handle tags and merges so I've never been able to make use of
 it.)

I'd be delighted to fully forget svn usage, as git svn is still a
foreign git.
 
 I started on a conversion that would include stitching in the upstream
 history for the linux package, but that depends on how we store patches
 in git and there isn't yet an obvious winner there (git-dpm vs git
 -debcherry vs dgit vs ...).  If the patches should be applied as git
 commits, then we can't represent all of history because sometimes the
 patches didn't apply.  And featuresets don't fit into this at all.
 
 I think that the best thing to do now is to do a straight conversion of
 the debian directory only.  We can stitch in upstream later.
 
 Here's where I am with the conversion:
 https://anonscm.debian.org/cgit/kernel/temp/

cool.

One proposition why not keep this as linux-debian-history-git
and start from scratch with what is inside of the latest svn.
This would reduce the number of branches and tags and might
be a cleaner restart. What do you think?

 
 Known bugs:
 
 linux.git
 -
 
 Commits tagged 2.6.12-2, 2.6.16-{15,16,17}, 2.6.18.dfsg.1-24etch2,
 2.6.26-{17,20} are detached.
 
 Several weird merges in early history.
 
 Many merges in svn are not recorded in git, but this is presumably due
 to lack of mergeinfo in old svn versions.
 
 Commit tagged 2.6.24-7 looks like a 4-way merge which shouldn't be
 possible in svn!  This might be due to svn mergeinfo accumulating
 branches.
 
 linux-latest.git
 
 
 Tip of wheezy branch is detached from its parent
 
 Many merges from sid to wheezy-backports are not recorded
 
 No squeeze branch
 
 linux-tools.git
 ---
 
 Many merges from sid to trunk are not recorded
 
 firmware-nonfree.git
 
 
 Tip of wheezy branch is detached from its parent
 
 What do we do with the sid branch?
 
 The 0.19 tag is in a firmware-nonfree subdirectory
 
 Merge before 0.4+etchnhalf.1 should not be recorded as a merge

On the other hand, none of the known bugs you mention is a show-stopper
for the transition from my side.

kind regards,

-- 
maks


signature.asc
Description: Digital signature

Re: Build kernel with clang(sid)

[maximilian attems]

On Thu, Jun 04, 2015 at 04:00:18PM +0800, Joseph Lee wrote:
 
 I am working on GSOC project bootable clang built debian and need to
 build Linux with clang. I used patches from LLVMLinux and add a new Kconfig
 file, modified debian/rules and debian/rules.real. May I report this as a
 bug(I attached the patch I made)?

dude break up this patch in logic parts. this an unreadable mess.
I don't get why a clang patch should patch a fs!?


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150604102120.GB14499@gluino

Re: Build kernel with clang(sid)

[maximilian attems]

On Thu, Jun 04, 2015 at 04:00:18PM +0800, Joseph Lee wrote:
 
 I am working on GSOC project bootable clang built debian and need to
 build Linux with clang. I used patches from LLVMLinux and add a new Kconfig
 file, modified debian/rules and debian/rules.real. May I report this as a
 bug(I attached the patch I made)?

the patch as is is unacceptable, why do you create a full new copy
of a config, this is certainly not needed.

best,

-- 
maks


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150604101901.GA14499@gluino

Re: Build kernel with clang(sid)

[maximilian attems]

On Thu, Jun 04, 2015 at 07:44:13PM +0800, Joseph Lee wrote:
 Hello,
 
 Thanks for reply.
 
 why do you create a full new copy of a config, this is certainly not
 needed.
 An option in standard config file must be disable to pass compilation. I am
 not very familiar with how these options are used. This is the way I found.
 It's a little ugly indeed. I will try another way.

it is unneeded. Please don't add more noise.

see https://wiki.debian.org/DebianKernel for docs
 
 dude break up this patch in logic parts. this an unreadable mess.
 Sorry for that, I gather everything in one patch make this patch a little
 big. Should I send them in different parts?

of course !

nobody is going to seriously review a 100k patch.
 
 I don't get why a clang patch should patch a fs!?
 You mean patch files in fs? This is for removing valais that clang doesn't
 support.

I do not care about whatever patchset you want to promote, our
policy concerning that is pretty clear:
https://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines

Hence if you want any non bugfix patches, get them upstream accepted first.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150604115029.gg10...@stro.at

Re: Out-of-tree kernel module udeb

[maximilian attems]

On Sun, May 17, 2015 at 01:36:53PM +0100, Ben Hutchings wrote:
 On Sun, 2015-05-17 at 13:25 +0200, Cyril Brulebois wrote:
 
   At the moment only spl is available in the archive, using dkms, and
   for zfs it's similar in the way of packaging though not uploaded yet.
   What we have (code ready to go) is a mechanism that detects/gets
   definition of a current KVERS and generate a source package with
   dependencies and binary packages with names corresponding to it.
   
   What do you guys think?
  
  My personal stance on kernel related things would be “upstream first”.
  If it ain't going to be merged into mainline, or at least accepted as a
  patchset (like e.g. aufs3 or rt in wheezy) for src:linux, I'm not sure
  we want to support that.
  
  Cc-ing debian-kernel@ to see what they think.
 
 I strongly oppose adding OOT modules this way as a supposed workaround
 for licence incompatibility.
 

this has been indeed our general conensus. we reject OOT modules or
patchsets that have zero or near zero probability of getting merged upstream.

-- 
maks


signature.asc
Description: Digital signature

Bug#783620: initramfs-tools: initramfs broken on first boot into Jessie, Unable to mount root fs on unknown-block(0, 0)

[maximilian attems]

On Wed, Apr 29, 2015 at 01:06:07PM +0200, Bernhard Schmidt wrote:
 Hi,
 
 [ copied from debian-user again ]
 
 ---
 Got another system with the symptoms and managed to get a snapshot.
 
 It is really extremely weird. The kernel output is
 
 List of all partitions:
 No filesystem could mount root, tried:
 Kernel panic - not syncing: VFS: Unable to mount root fs on
 unknown-block(0,0)
 
 This is reproducible. To fix it it is enough to boot into the Wheezy
 kernel (even with init=/bin/sh), then reboot. It apparently does
 something to the root-fs (fsck?) which allows the Jessie kernel to boot.
 
 I have asked our Windows guys to make a screencast, it is uploaded here.
 
 http://users.birkenwald.de/~berni/volatile/783620.mkv
 
 We still have the snapshot available, if you have an idea please drop me
 a note.

this means linux didn't get the initramfs passed by the bootloader.

In the old days this happened when lilo was not run, these days it could
be some grub modules out of sync (very wild guess).
did you try before botting into that image to run install-grub in it?


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150429144533.gd10...@stro.at

Re: [PATCH 2/2] deb-pkg: add source package

[maximilian attems]

On Thu, Apr 23, 2015 at 12:01:10PM +0300, Riku Voipio wrote:
 On 22 April 2015 at 18:50, maximilian attems m...@stro.at wrote:
 
  great this is a much requested feature for wider adoption of make
  deb-pkg. In general acked-by me, just minor comment below.
 
  I do not like the BUILD_SOURCE=y variable,
  I think it should just be like the other scripts and do it by default.
 
  What we do need is a target that *only* compiles the linux image.
 
 So a bin-debpkg target in scripts/package/Makefile ?

yes, please.
 
   scripts/package/builddeb | 42 ++
   1 file changed, 42 insertions(+)
 
  diff --git a/scripts/package/builddeb b/scripts/package/builddeb
  index e397815..3d77fd3 100755
  --- a/scripts/package/builddeb
  +++ b/scripts/package/builddeb
  @@ -272,12 +272,23 @@ On Debian GNU/Linux systems, the complete text of 
  the GNU General Public
   License version 2 can be found in \`/usr/share/common-licenses/GPL-2'.
   EOF
 
  +
  +build_depends=bc, 
  +if [ -n $BUILD_TOOLS ]
 
  why this dual stage?
 
 That variable was introduced in RFC: builddeb: add linux-tools
 package with perf [1]. Building perf
 as part of deb-pkg was kind of the major motivation for these series.

With adding the very specific image target, I don't think this variable
is needed.
 
  +then
  + build_depends=$build_depends python-dev, libperl-dev, bison, flex, \
  +libaudit-dev, libdw-dev, libelf-dev, libiberty-dev, libnewt-dev, 
  autoconf, \
  +automake, libtool, libglib2.0-dev, libudev-dev, libwrap0-dev, 
  libiberty-dev, \
  +libunwind8-dev [amd64 arm64 i386], libnuma-dev [amd64 arm64 i386 powerpc 
  ppc64 ppc64el] 
 
  how did you generate this list, this seems bogus to me?!
 
  python-dev should probably be python
  why would you need automake?
 
 These are build-depends of linux-tools (perf etc).

Hmm, ok.
 
  plus I do seem to miss cpio, kmod.
 
 I'll add kmod and cpio to the non-tools case.

good.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150423104358.gr27...@stro.at

Re: [PATCH 2/2] deb-pkg: add source package

[maximilian attems]

On Fri, Apr 10, 2015 at 04:15:14PM +0300, riku.voi...@linaro.org wrote:
 From: Riku Voipio riku.voi...@linaro.org
 
 By passing BUILD_SOURCE=y variable, make deb-pkg builds a debian source
 package. It will generate a minimal debian/rules file that calls back
 to make deb-pkg. Generated source package will build the same kernel
 .config than what was available for make deb-pkg.
 
 The source package is useful for gpl compliance, or for feeding to a
 automated debian package builder.
 
 Patch depends on the deb-pkg: move setting debarch for a separate function
 for correct changelog filenames.
 
 Signed-off-by: Riku Voipio riku.voi...@linaro.org
 ---

great this is a much requested feature for wider adoption of make
deb-pkg. In general acked-by me, just minor comment below.

I do not like the BUILD_SOURCE=y variable,
I think it should just be like the other scripts and do it by default.

What we do need is a target that *only* compiles the linux image.

  scripts/package/builddeb | 42 ++
  1 file changed, 42 insertions(+)
 
 diff --git a/scripts/package/builddeb b/scripts/package/builddeb
 index e397815..3d77fd3 100755
 --- a/scripts/package/builddeb
 +++ b/scripts/package/builddeb
 @@ -272,12 +272,23 @@ On Debian GNU/Linux systems, the complete text of the 
 GNU General Public
  License version 2 can be found in \`/usr/share/common-licenses/GPL-2'.
  EOF
  
 +
 +build_depends=bc, 
 +if [ -n $BUILD_TOOLS ]

why this dual stage?

 +then
 + build_depends=$build_depends python-dev, libperl-dev, bison, flex, \
 +libaudit-dev, libdw-dev, libelf-dev, libiberty-dev, libnewt-dev, autoconf, \
 +automake, libtool, libglib2.0-dev, libudev-dev, libwrap0-dev, libiberty-dev, 
 \
 +libunwind8-dev [amd64 arm64 i386], libnuma-dev [amd64 arm64 i386 powerpc 
 ppc64 ppc64el] 

how did you generate this list, this seems bogus to me?!

python-dev should probably be python
why would you need automake?

plus I do seem to miss cpio, kmod.

 +fi
 +
  # Generate a control file
  cat EOF  debian/control
  Source: linux-upstream
  Section: kernel
  Priority: optional
  Maintainer: $maintainer
 +Build-Depends: $build_depends
  Standards-Version: 3.8.4
  Homepage: http://www.kernel.org/
  EOF
 @@ -425,4 +436,35 @@ EOF
   create_package $tools_packagename $tools_dir
  fi
  
 +if [ -n $BUILD_SOURCE ]
 +then
 +cat EOF  debian/rules
 +#!/usr/bin/make -f
 +
 +build:
 + cp debian/config .config
 + \$(MAKE) oldconfig
 +
 +binary-arch:
 + \$(MAKE) KDEB_PKGVERSION=${packageversion} BUILD_TOOLS=$BUILD_TOOLS 
 deb-pkg
 +
 +clean:
 + \$(MAKE) clean
 +
 +binary: binary-arch
 +EOF
 +
 + (cd $KBUILD_SRC; git archive --prefix=linux-upstream-${version}/ 
 HEAD)|gzip -9  ../linux-upstream_${version}.orig.tar.gz
 + cp $KCONFIG_CONFIG debian/config
 + tar caf ../linux-upstream_${packageversion}.debian.tar.gz 
 debian/{config,copyright,rules,changelog,control}
 + dpkg-source -cdebian/control -ldebian/changelog --format=3.0 (custom) 
 --target-format=3.0 (quilt) \
 + -b / ../linux-upstream_${version}.orig.tar.gz  
 ../linux-upstream_${packageversion}.debian.tar.gz
 + mv linux-upstream_${packageversion}*dsc ..
 + dpkg-genchanges  ../linux-upstream_${packageversion}_${debarch}.changes
 +else
 + dpkg-genchanges -b  
 ../linux-upstream_${packageversion}_${debarch}.changes
 +fi
 +
 +
 +
  exit 0
 -- 
 2.1.4
 
 
 -- 
 To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: 
 https://lists.debian.org/34017611f8a0056a09d2c38412efd7828efe00fe.1428671643.git.riku.voi...@linaro.org
 


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150422155057.GA32026@gluino

Re: [PATCH] deb-pkg: v2: move setting debarch for a separate function

[maximilian attems]

On Wed, Apr 22, 2015 at 04:45:38PM +0200, Michal Marek wrote:
 On 2015-04-16 15:42, riku.voi...@linaro.org wrote:
  From: Riku Voipio riku.voi...@linaro.org
  
  create_package() function tries to resolve used architecture
  for everry package. Split the setting the architecture to a
  new function, set_debarch(), called once on startup.
  
  This allows using debarch from other parts of script as
  needed.
  
  v2: Follow Michals suggestion on setting variables at
  top scope and also setting the fallback $debarch in the
  new function
  
  Signed-off-by: Riku Voipio riku.voi...@linaro.org
 
 Thanks, applied to kbuild.git#misc. But please base your patches on
 Linus's or the maintainer's tree next time. Your patch had some
 conflicts, because it was based on some non-upstream patches.

thanks, acked.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150422155201.GB32026@gluino

linux 4.0 exp

[maximilian attems]

hello,

upload sometime after 22UT today.

-- 
maks


signature.asc
Description: Digital signature

Bug#778588: Linux 4.0 compat

[maximilian attems]

On Sat, Apr 04, 2015 at 07:30:11PM +0200, Lukas Wunner wrote:
 FWIW, the attached patch enables compatibility with 4.0.

The plan is to upload the next 3.19 stable as soon as it is out,
and then jump to 4.0 to experimental and soon unstable
(after 8.0 release).

best,

-- 
maks


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150404203654.GA31831@gluino

Bug#781002: initramfs-tools: no kernel modules are insert into initrd

[maximilian attems]

On Wed, Apr 01, 2015 at 06:10:05PM -0700, Marc MERLIN wrote:
 Could I make a few suggestions while we're at it?
 1) I sometimes build an initrd for a kernel I haven't installed yet. Yes,
 it's a mistake, but it happily succeeds and creates an initrd without any
 modules which then creates a non booting system.
 = initramfs should abort if its generated /lib/modules/kernel is empty

I thought this was caught.
 
 2) initramfs creates a temporary directory where it puts everything, and
 then deletes it before you can inspect it for debugging.
 = Add a --debug that leaves that directory behind for inspection.
 Right now I have to unpack the initrd image which is more and more of a
 pain as it becomes a bundled binary of concatenated cpio images and god
 knows what.

-k :P
as usual read the nice man mkinitramfs (;
 
 3) document the binwalk method of unpacking initrd to debug if needed
 (somewhere in the manpage):
 http://unix.stackexchange.com/questions/163346/why-is-it-that-my-initrd-only-has-one-directory-namely-kernel
 .
 Or for the archives:
 legolas [mc]# binwalk initrd.img
 pick up the offset of the 2nd initrd image, and unpack like so:
 legolas [mc]# cd subdir; dd if=../initrd.img bs=21136 skip=1 | gunzip |
 cpio -idv

lsinitramfs shows you the content.

sunny greetings,

-- 
maks


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150402122928.GA31518@gluino

Re: Linux 3.19.2

[maximilian attems]

On Tue, Mar 24, 2015 at 02:02:48PM +, Ben Hutchings wrote:
 On Tue, 2015-03-24 at 16:33 +0530, Ritesh Raj Sarraf wrote:
  Hello Kernel Team,
  
  Are there plans to upload kernel 3.19.2 into experimental ? Or will it
  be skipped for 4.0 ?
  3.19.2 stable release seems to have a bunch of bug fixes that affect
  Intel Graphics cards, which has been affecting me very badly.
 
 I've rebased trunk onto 3.19.2 but didn't get round to uploading.  It
 will probably happen soon.

I was tempted, but than saw that stable-queue has a bunch of things.
So will upload after 3.19.3 happens.

best,

-- 
maks


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150325055144.GA6477@gluino

Re: Linux 3.19.2

[maximilian attems]

On Wed, Mar 25, 2015 at 08:52:53AM +, Ben Hutchings wrote:
 On Wed, 2015-03-25 at 06:51 +0100, maximilian attems wrote:
  On Tue, Mar 24, 2015 at 02:02:48PM +, Ben Hutchings wrote:
   On Tue, 2015-03-24 at 16:33 +0530, Ritesh Raj Sarraf wrote:
Hello Kernel Team,

Are there plans to upload kernel 3.19.2 into experimental ? Or will it
be skipped for 4.0 ?
3.19.2 stable release seems to have a bunch of bug fixes that affect
Intel Graphics cards, which has been affecting me very badly.
   
   I've rebased trunk onto 3.19.2 but didn't get round to uploading.  It
   will probably happen soon.
  
  I was tempted, but than saw that stable-queue has a bunch of things.
  So will upload after 3.19.3 happens.
 
 3.19.2 has net: validate the range we feed to iov_iter_init() in
 sys_sendto/sys_recvfrom which fixes a privilege escalation in - I think
 - Bluetooth.

sure sure, please go ahead.
personally, I want the next.

-- 
maks


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150325091828.GA18078@gluino

Re: Replacing aufs with overlayfs

[maximilian attems]

On Thu, Mar 12, 2015 at 03:57:21PM +0100, intrigeri wrote:
 
 [dropping -live@ from the Cc list, as this is not specific to Live
 systems, and affects e.g. some setups based on Linux containers.]
 
 Ben Hutchings wrote (09 Dec 2014 19:55:10 GMT) :
  Please try the Linux 3.18 packages from experimental (they're not there
  yet, but should be soon) and check that overlayfs does what you need.
 
 FYI, at the upstream AppArmor IRC meeting a few days ago, I've learnt
 that overlayfs and AppArmor don't play well together yet.
 
 * Some IRC log excerpts that provide more detail:
   https://labs.riseup.net/code/issues/9045
 
 * The AppArmor bug that tracks this issue:
   https://bugs.launchpad.net/apparmor/+bug/1408106

Apparmor is not critical, hence it is not a regression blocker.
btw 3.19 is out and soon you'll have 3.20. Plenty of time to
fix such thingies.

Better check how it affects Selinux while you'd care about security!

-- 
maks


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150312205204.GA7568@gluino

Re: Debian 8/jessie - SECCOMP_FILTER_FLAG_TSYNC

[maximilian attems]

On Sat, Mar 07, 2015 at 07:17:13PM +0200, Georgi Naplatanov wrote:
 On 03/07/2015 06:38 PM, Ben Hutchings wrote:
  On Sat, 2015-03-07 at 16:09 +0100, D. F. wrote:
  Hello, Julien Tinnes from google says that next releases of
  chromium will drops support for kernels without TSYNC
  
  ubuntu 14.10 already has been patched
  
  
  Can I to expect that debian 8/jessie will have support for
  TSYNC?
  
  Sounds like another good reason to not use Google spyware.
 
 Google Chrome for Linux is the only possibility to use latest version
 of Adobe flash player for Linux as far as I know.

another good reason not to use it.

-- 
maks


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150307234059.GA14155@gluino

Bug#779799: linux: Older patches causing FTBFS on armhf

[maximilian attems]

On Wed, Mar 04, 2015 at 09:29:43PM +, B.R. Oake wrote:
 Source: linux
 Version: 3.19-1~exp1
 Justification: fails to build from source
 Severity: serious
 
 Hello,
 
 The two patches:
 
 features/arm/dts-sun7i-Add-spi0_pins_a-pinctrl-setting.patch
 features/arm/dts-sun7i-Add-uart3_pins_b-pinctrl-setting.patch
 
 are no longer needed in 3.19-1~exp1 because they were accepted upstream in
 v3.19 as these commits:
 
 2dad53b54a
 0510e4b52a
 
 Keeping the patches means getting duplicate nodes in the device tree which
 causes this build failure on armhf:
 
 https://buildd.debian.org/status/fetch.php?pkg=linuxarch=armhfver=3.19-1~exp1stamp=1424044478
 
 Please could you remove the patches from the next experimental version?

they are already removed in the repository for experimental,
waiting for 3.19.X for the next upload.

in any case thanks for the details.


-- 
maks


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150304222046.GA24290@gluino