Re: recommended way to find out whether one is "within" the initramfs?

[Romain Perier]

Hey,

Le jeu. 7 oct. 2021 à 01:38, Christoph Anton Mitterer
 a écrit :
>
> Hey Romain.
>
> Thanks for your ideas:
>
> On Wed, 2021-10-06 at 18:49 +0200, Romain Perier wrote:
> > Quickly, few ideas (perhaps not the perfect ones):
> > 1. Check for what is currently mounted as "/" ? (which technically
> > should differ between initramfs or real rootfs)
>
> That sounds like a pretty nice idea.
> I guess for the iniramfs it would be always:
>   none / rootfs
> ?

Don't remember in details, an initrd is /dev/root on /, normally

> Or maybe the "none" could be anything in theory.
>
>
> > 2. Check if your binaries are running inside a klibc or busybox
> > context (both are supported via an initramfs) ?
> > 3. Check if systemd is running ? (so you have started userspace
> > processes part of your real rootfs)
> >
>
> These two seem IMO a bit less "stable"... people might not use systemd
> (at least in derivates) and checking for the binaries sounds a bit
> ugly.

Yeah the point 3. about systemd is not generic enough, I agree.
For busybox that basically means resolving a symlink :) . Just resolve if
/sbin/init is a symlink to busybox or not : but checking for the
rootfs is definitively better, imho.





>
>
>
> So maybe I do a combination and check for several indicators:
> /scripts, /conf/initramfs.conf (which seems to be always there, update-
> initramfs fails if the main initramfs.conf is missing or empty) and the
> fs-type of the / fs.

I would say, just check a single indicator if you're sure about it,
and then test (several times)


Regards,
Romain

Re: recommended way to find out whether one is "within" the initramfs?

[Romain Perier]

Hey,

Le mer. 6 oct. 2021 à 17:57, Christoph Anton Mitterer
 a écrit :
>
> Hey.
>
> I've just wondered whether there is recommended way to find out whether
> one is currently "within" the initramfs (i.e. early boot) as generated
> by Debians initramfs-tools, or not?
>
> I'd have probably done something like checking for:
> if [ -f /conf/initramfs.conf ] && [ -f /scripts/init-top/ORDER ] && [ ! -e 
> /usr/bin/dpkg ]; then
> echo within initramfs
> else
> echo not within initramfs
> fi
>
> Or are /conf/initramfs.conf and /scripts/init-top/ORDER not necessarily
> included?
>
> The check for dpkg (which shouldn't be present in the initramfs, unless
> someone includes it for whichever reason) would have been to rule out
> the cases where someone created the other files in his normal
> userspace.
>
>
> Any better ideas? :D

Quickly, few ideas (perhaps not the perfect ones):
1. Check for what is currently mounted as "/" ? (which technically
should differ between initramfs or real rootfs)
2. Check if your binaries are running inside a klibc or busybox
context (both are supported via an initramfs) ?
3. Check if systemd is running ? (so you have started userspace
processes part of your real rootfs)
>
>
> Thanks,
> Chris.
>

Regards,
Romain

Bug#989152: linux: Mouse wheel support is broken after resume

[Romain Perier]

Le mer. 26 mai 2021 à 23:27, Julien AUBIN  a écrit :
>
> Source: linux
> Version: Mouse wheel behaviour is broken after resume
> Severity: normal
>
> Dear Maintainer,
>
> I've remarked that on a specific laptop the mouse wheel function is not
> restored after resume. This is a regression that has been introduced between
> Buster and Bullseye, and only occurs on one of my hosts.
>
> Laptop model : Dell Latitude e6540
> Mouse model : Microsoft Intellimouse 4500
> Desktop environment : KDE
>
> Steps to reproduce :
> DO : boot the computer and open KDE
> DO : open whatever application with a scrollbar and use the mouse scroll wheel
> EXPECT : the scrolling works.
> DO : suspend the computer to RAM for 5 minutes
> DO : resume your activity
> DO : open whatever application with a scrollbar and use the mouse scroll wheel
> EXPECT : the scrolling works.
> ACTUAL : the scrolling does not work.
>
> Workaround : unplug and plug the mouse, or use a tool like resetmsmice (it
> would be great to include it in the archive :
> https://github.com/paulrichards321/resetmsmice )

Hi,

Could you monitor the corresponding input device by the help of
"evtest" ? That's a userspace tool that
dumps evdev events reported by the kernel to userspace (so we can
check if the kernel exposes the scrolling
to userspace after resume or not... perhaps that's a kernel issue,
perhaps that's an issue in the upper layers)

Could you :
1. install evtest : apt install evtest
2. With evtest /dev/input/event  locate the device corresponding to
your mouse: when you scroll you should see events. Something like:

time 1622115506.006606, type 2 (EV_REL), code 8 (REL_WHEEL), value -1

3. Then when you have found the right device, check that the scrolling
event is working as expected before resume (via evtest)

Now test suspend and check if you see the scrolling event via evtest
after resume.
Once done, past your result here.

Regards,
Romain

Bug#970679: wireless-regdb: updating wireless-regdb to 2020.04.29-2~bpo10+1 makes AP mode impossible on ath10k wifi card

[Romain Perier]

On Mon, Sep 21, 2020 at 01:28:53PM +0200, Félix Sipma wrote:
> Package: wireless-regdb
> Version: 2016.06.10-1
> Severity: normal
> 
> Hello,
> 
> I have an ath10k wireless card, using QCA988X driver in firmware-atheros, 
> which 
> worked with wireless-regdb 2016.06.10-1. I tried to update linux-image-amd64 
> from 4.19+105+deb10u5 to 5.7.10-1~bpo10+1, which resulted in an updated 
> wireless-regdb (2020.04.29-2~bpo10+1). From then, The wifi card got 
> impossible 
> to use in 5Ghz AP mode (no frequency available). I tried to boot with 
> 4.19.0-10-amd64, and the same symptoms remained. Finally, downgrading 
> wireless-regdb to 2016.06.10-1 made the wifi functionnal again.
> 
> Using firmware-atheros from buster-backports or not made no difference.
> 
> Regards,
> 
> 
> -- System Information:
> Debian Release: 10.5
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> wireless-regdb depends on no packages.
> 
> wireless-regdb recommends no packages.
> 
> Versions of packages wireless-regdb suggests:
> ii  crda  3.18-1
> 
> -- no debconf information

Hi,

Could you, please, provide the output of 'dmesg' with the faulty kernel and the
faulty wiresless-regdb, it might give us more context and I am wondering if it
is not signing issue (perhaps not, just wondering, as we are now two
maintainers). Typically one dmesg with kernel 5.7.x and wireless-regdb 
2020.04.29,
one dmesg with kernel 4.19.x and wireless-regdb 2020.04.29 and one dmesg when it
works, would be perfect.


Thanks,
Romain


signature.asc
Description: PGP signature

Bug#963033: linux-image-arm64: kexec loses EFI system tables with Debian kernels

[Romain Perier]

On Wed, Jul 22, 2020 at 03:28:39PM -0400, Gabriel Krisman Bertazi wrote:

Hi,

Well, after an analyze on my side, the EFI mode is detected based on the EFI 
stub, right ?
Then the kernel populates the FDT with EFI properties into its own address 
space (based on
what was previously found from the stub). Kexec simply does not preserve the 
EFI mode at
all for arm64, it is only present for x86.

With the original debian patch, we suppose that the "secure-boot" property will 
always be
set in the FDT, simply because this information should be found in the EFI stub 
(unset,
disabled, enabled, etc...), so the corresponding FDT property will always have 
a value and
will always be present. So assume that it is always the case is correct, imho.

Now, if the EFI stubs informations are not passed to the second stage
kernel, either nor "system table" or "secure-boot" or the rest will be
found, explaining the issue of the first comment (read the first comment
it is "System table" that is not found).

We should have a "setup_efi_info" like it is the case in the kexec-tools
code base for x86, except we should have something similar for arm64.

Regards,
Romain


signature.asc
Description: PGP signature

Fwd: ITP: fsverity -- Userspace utilities for fs-verity

[Romain Perier]

CCing debian-kernel in case the team is interested.

-- Forwarded message -
De : Romain Perier 
Date: jeu. 16 avr. 2020 à 21:15
Subject: ITP: fsverity -- Userspace utilities for fs-verity
To: Debian Bug Tracking System 


Package: wnpp
Severity: wishlist
Owner: Romain Perier 

* Package name: fsverity
  Version : 1.0
  Upstream Author : Eric Biggers 
* URL :
https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/fsverity-utils.git
* License : GPL
  Programming Lang: C
  Description : Userspace utilities for fs-verity

This is fsverity, a userspace utility for fs-verity. fs-verity is a Linux kernel
feature that does transparent on-demand integrity/authenticity verification of
the contents of read-only files, using a hidden Merkle tree (hash
tree) associated
with the file. The mechanism is similar to dm-verity, but implemented
at the file
level rather than at the block device level. The fsverity utility allows you to
set up fs-verity protected files.

This package will be helpful for handling the fsverity feature on a file from
userspace.

I want to maintain this package. As DM, I need someone for the initial upload.
Packaging is currently hosted here
https://salsa.debian.org/rperier-guest/fsverity,
and will be developed at https://salsa.debian.org/debian/fsverity

Bug#931930: firmware-misc-nonfree: Please, include i915/icl_dmc_ver1_07.bin

[Romain Perier]

On Fri, Jan 31, 2020 at 06:10:01PM -0800, Todd Troxell wrote:
> Is there a reason why it's not included?  I can make a patch and try it...

Hi,

icl_dmc_ver1_07.bin and bxt_huc_ver01_8_2893.bin seems to be included already,
see 
https://salsa.debian.org/kernel-team/firmware-nonfree/blob/master/debian/config/misc-nonfree/defines

At least in 20190717-1.

Messages about "W: Possible missing firmware  for module " is
thrown by the hook functions of initramfs-tools, when a kmod requires
firmware images not found on your systemd in /lib/firmware. Are you sure
that your firmware packages are up-to-date ?

Regards,
Romain


signature.asc
Description: PGP signature

Re: RFH: wireless-regdb

[Romain Perier]

Hi Ben,

On my side, as DM, I would like to maintain more packages in Debian so I
can continue to improve my skills on this topic.
I am currently maintaining raspi-firmware, but that's a binary blob and a
package in non-free, even if I am happy with it, non-free
is not the most interesting place to learn things, imho..  :)  (at least
not completely compared to "main")

I am part of the kernel-team (at least, I think) and I would be very happy
to help you to co-maintain this package.
The only blocking issue I see is perhaps the fact that I am a DM (I mean,
regarding certificate of the kernel)

Regards,
Romain

Le ven. 31 janv. 2020 à 11:54, Ben Hutchings  a écrit :

> I've finally updated wireless-regdb this week, and it now provides the
> kernel-loadable regulatory.db file.  However, with the certificate
> embedded in the kernel, it's even less practical for anyone to NMU
> wireless-regdb if necessary.
>
> I don't want to be the single point of failure for this package.
> So I'm looking for a co-maintainer, preferably already in the kernel
> team.  You would need to generate a signing key pair and certificate
> (README.source has instructions for this) and we would then add this
> certificate to the kernel.
>
> Ben.
>
> --
> Ben Hutchings
> 73.46% of all statistics are made up.
>
>
>

Re: Proposal/Guidelines for working on *-security branches in packaging repository

[Romain Perier]

Le lun. 16 sept. 2019 à 22:00, Salvatore Bonaccorso
 a écrit :
>
> Hi
>
> I was pondering for a while to try to start this discussion. And it is
> more a collection of some thoughs.
>
> Recently more people have started to work to as well commit fixes for
> CVEs into the respective *-security branches. This is very good news
> indeed :) and is very encouraging to see contributions!
>
> I started to think we might want to outline some guidelines what to
> commit on *-security branches while we are yet UNRELEASED.
>
> Two preliminary points have to be stated to make the idea clear:
>
> - Not every CVE fix needs really a DSA or an "urgent" release via
>   security, many fixes go in as well via import of upstream stable
>   releases and scheduled in point releases.
> - If a security upload needs to be done, and there is in particular an
>   ABI bump involved, then more needs to be done (bump ABI, make a new
>   linux-latest upload, packages need to go through NEW on
>   security-master and need manual intervention from ftp-masters, the
>   later is as well then in twice instance needed for now from
>   ftp-masters for signed kernel as well).
>
> So my idea was to bring this up here for discussion: I think while
> working on *-security branches and keep the possibilty to release
> "fast" updates without ABI bump via security, whenever needed for an
> "urgent" fix -- I would propose as guideline -- commits can, and are
> *encouraged* to be added, if there is no ABI break. If there is an ABI
> break and the fix is not very urgent, then rather keep if off for the
> time beeing.
>
> Whenever then an urgent fix is needed which in any case requires an
> ABI bump then it's safe to add as well other less urgent commits for
> CVEs.

As a security and system linux engineer, for me any security breach is
a security breach.
There are no "less urgent" security fixes. Even if technically, I
agree that there are
critical security issues, like spectre typically, while some others
have a smaller
surface attack... or harder to exploit because it requires exotics hardwares
(I just share my opinion here)

Anyway, I understand that in some cases, it is more complicated to do
a new upload
in the security branch, mostly in case of ABI bump.

So a general rule to avoid the most all possible ABI bumps in security uploads,
is good to me. it does make sense to me to write a doc for this, yes :)


What is your definition of "less urgent" security issues ? (or important ones).
The fact is, there are products running buster now, so in case of
security issues,
these cannot really wait the next point releases (for some of these).

Can we propose to upload at maximum 1 or 2 security updates for the
kernel between
each point release ? (with maximum one ABI bump.. for example... ) 1
sec update at
maximum would be good and acceptable, imho..

Regards,
Romain

Bug#924913: trackpad on L480 unusable after upgrade to testing

[Romain Perier]

On Wed, May 29, 2019 at 05:54:22PM +0200, Alois Schlögl wrote:
> On 3/26/19 9:03 PM, Romain Perier wrote:
> > On Wed, Mar 20, 2019 at 08:24:33AM +0100, Alois Schlögl wrote:
> >> On 3/18/19 7:46 PM, Romain Perier wrote:
> >>> On Mon, Mar 18, 2019 at 12:43:10PM +0100, Alois Schlögl wrote:
> >>>> On 3/18/19 12:20 PM, Romain Perier wrote:
> >>>>> Hello,
> >>>>>
> >>>>> On Mon, Mar 18, 2019 at 11:27:41AM +0100, Alois Schlögl wrote:
> >>>>>> Source: linux
> >>>>>> Severity: normal
> >>>>>>
> >>>>>> Dear Maintainer,
> >>>>>>
> >>>>>>    On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10
> >>>>>> (testing).
> >>>>>>    After the upgrade, the touchpad and the trackpoint was not usable
> >>>>>> anymore.
> >>>>>>
> >>>>>>
> >>>>>>    This already has some bug report here,
> >>>>>>    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600
> >>>>>>
> >>>>>>    As a workaround, one can run the command,
> >>>>>>    sudo sh -c 'echo -n "elantech">
> >>>>>> /sys/bus/serio/devices/serio1/protocol'
> >>>>>>    in order to use the touchpad. However, on a GUI Interface and 
> >>>>>> without
> >>>>>>    an external mouse, it's impossible to apply this workaround
> >>>>>>   (switching to the terminal -F1, login, and run the command
> >>>>>> above might work)
> >>>>>>
> >>>>>>    I expect to be able to use the touchpad just out of the box, not 
> >>>>>> needing
> >>>>>>    to run the above workaround
> >>>>>>
> >>>>> Could you :
> >>>>>
> >>>>> - Test with the last kernel uploaded to unstable (4.19.0-4:4.19.28) and 
> >>>>> confirm or
> >>>>>   not is the problem still exists ?
> >>>> Dear Romain
> >>>>
> >>>>
> >>>> I upgraded the kernel and rebooted:
> >>>>
> >>>> schloegl@debian10:~$ uname -a
> >>>> Linux debian10 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15)
> >>>> x86_64 GNU/Linux
> >>>>
> >>>>
> >>>> With this kernel the trackpoint is working, the trackpad is still not
> >>>> usable.
> >>>>
> >>>> (This improves the situation because now at least one pointer device is
> >>>> available).
> >>>>
> >>>>
> >>> Good, we did some progress :)
> >>>
> >>>>> - According to the bug on launchpad and to the fix pushed upstream, the
> >>>>>   fix seems to be an hardware quirks, could you give me the output of 
> >>>>> the
> >>>>>   following command :
> >>>>>   $ /sys/bus/serio/devices/serio1/firmware_id
> >>>> root@debian10:~# cat /sys/bus/serio/devices/serio1/firmware_id
> >>>> PNP: LEN2036 PNP0f13
> >>>>
> >>> Could you test the patch attached to this reply ?
> >>> (if you don't know how to do this, I can provide support)
> >>>
> >>> Regards,
> >>> Romain
> >>
> >>
> >> I tried to followed these instructions:
> >>
> >> https://kernel-team.pages.debian.net/kernel-handbook/ch-comm
> >>
> >> 4.5. Building a custom kernel from Debian kernel source
> >>
> >> Specifically using the patched the sources,
> >>
> >> *scripts/config --disable MODULE_SIG*
> >> **scripts/config --disable DEBUG_INFO**
> >> ||*|make clean|* ||*|make deb-pkg
> >>
> >> |*
> >>
> >> and ended up with a kernel that does not boot (missing HD audio firmware),
> >>
> >>
> >> Which procedure do you recommend to build and install a modified kernel ?
> >>
> >>
> > Hi,
> >
> > Section 4.2 from
> > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official
> > , until test-patches should work. For the test-patches script, use the 
> > flavour and a
> > featur

Bug#928631: firmware-amd-graphics: Update to 20190502-1 causus hang of system directly after grub

[Romain Perier]

On Tue, May 21, 2019 at 09:59:21AM +0200, Diederik de Haas wrote:
> Got a new MB BIOS and after installing that, I made a new attempt with 
> firmware-amd-graphics version 20190502-1.
> It failed again, but it got slightly further this time.
> I saw a remount message, then a blinking cursor and then blank 
> screen+freeze+monitor in standby modus.
> I figured that would've produced a kern.log and it did; see attachment.
> 
> I have the upstream git repo on my machine and when I did
> "git log -- amdgpu/vega10_ce.bin" I noticed commit 
> 0f22c8527439eaaf5c3fcf87b31c89445b6fa84d with the following message:
> Revert "amdgpu: update vega10 fw for 18.50 release"
> 
> This reverts commit ec4b0cd394472ee1491df6ef5f215d1f0953f836.
> 
> This causes GPU hangs for some users.  Let's revert for now
> while we try and root cause the issue.
> 
> Sounds familiar.
> 
> What I could do is getting the various versions of amdgpu/vega10* from the 
> upstream git repo and place them in /lib/firmware/amdgpu/ to see which 
> versions 
> work and which don't.
> Would that be useful? Any specific tests I should do or data to gather 
> (please 
> indicate how I should do that)
> 
> Cheers,
>   Diederik

Hi,

firmware-amd-graphics 20190502-1 is based onto upstream commit
92e17d0dd2437140fab044ae62baf69b35d7d1fa, that is commit "amdgpu: update vega20 
to the latest 19.10 firmware"
. Two commits behind there is commit "amdgpu: update vega10 to the latest 19.10 
firmware", that is
already included in firmware-amd-graphics 20190502-1.

Could you try to revert "amdgpu: update vega10 to the latest 19.10
firmware" ? So try to use the firmware for vega10 that is before this commit. 
Does it work for you ?

1. Use linux-firmware.git with last HEAD in the master branch
2. git checkout 4ea5c73b96ed4a508f90047e22ccbaa477481310 (commit "amdgpu: 
update polaris11 to the latest 19.10 firmware", that is the commit before 
bumping vega10 to 19.10)
3. Copy vega10 binary blobs to /lib/firmware/amdgpu

Does it work ?


Thanks,
Regards,
Romain


> May 21 08:48:40 bagend kernel: [0.00] Linux version 4.19.0-5-amd64 
> (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-7)) #1 SMP 
> Debian 4.19.37-3 (2019-05-15)
> May 21 08:48:40 bagend kernel: [0.00] Command line: 
> BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 
> root=UUID=a2a5e481-0ac6-4e68-818f-38255bf7dd57 ro quiet
> May 21 08:48:40 bagend kernel: [0.00] x86/fpu: Supporting XSAVE 
> feature 0x001: 'x87 floating point registers'
> May 21 08:48:40 bagend kernel: [0.00] x86/fpu: Supporting XSAVE 
> feature 0x002: 'SSE registers'
> May 21 08:48:40 bagend kernel: [0.00] x86/fpu: Supporting XSAVE 
> feature 0x004: 'AVX registers'
> May 21 08:48:40 bagend kernel: [0.00] x86/fpu: xstate_offset[2]:  
> 576, xstate_sizes[2]:  256
> May 21 08:48:40 bagend kernel: [0.00] x86/fpu: Enabled xstate 
> features 0x7, context size is 832 bytes, using 'compacted' format.
> May 21 08:48:40 bagend kernel: [0.00] BIOS-provided physical RAM map:
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0x-0x0009d3ff] usable
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0x0009d400-0x0009] reserved
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0x000e-0x000f] reserved
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0x0010-0x09cf] usable
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0x09d0-0x09ff] reserved
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0x0a00-0x0a1f] usable
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0x0a20-0x0a20afff] ACPI NVS
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0x0a20b000-0x0aff] usable
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0x0b00-0x0b01] reserved
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0x0b02-0xd873efff] usable
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0xd873f000-0xdb030fff] reserved
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0xdb031000-0xdb137fff] ACPI data
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0xdb138000-0xdb244fff] usable
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0xdb245000-0xdb60afff] ACPI NVS
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0xdb60b000-0xdc68bfff] reserved
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 0xdc68c000-0xdeff] usable
> May 21 08:48:40 bagend kernel: [0.00] BIOS-e820: [mem 
> 

Bug#924913: trackpad on L480 unusable after upgrade to testing

[Romain Perier]

On Tue, Mar 26, 2019 at 09:03:59PM +0100, Romain Perier wrote:
> On Wed, Mar 20, 2019 at 08:24:33AM +0100, Alois Schlögl wrote:
> > On 3/18/19 7:46 PM, Romain Perier wrote:
> > > On Mon, Mar 18, 2019 at 12:43:10PM +0100, Alois Schlögl wrote:
> > >> On 3/18/19 12:20 PM, Romain Perier wrote:
> > >>> Hello,
> > >>>
> > >>> On Mon, Mar 18, 2019 at 11:27:41AM +0100, Alois Schlögl wrote:
> > >>>> Source: linux
> > >>>> Severity: normal
> > >>>>
> > >>>> Dear Maintainer,
> > >>>>
> > >>>>    On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10
> > >>>> (testing).
> > >>>>    After the upgrade, the touchpad and the trackpoint was not usable
> > >>>> anymore.
> > >>>>
> > >>>>
> > >>>>    This already has some bug report here,
> > >>>>    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600
> > >>>>
> > >>>>    As a workaround, one can run the command,
> > >>>>    sudo sh -c 'echo -n "elantech">
> > >>>> /sys/bus/serio/devices/serio1/protocol'
> > >>>>    in order to use the touchpad. However, on a GUI Interface and 
> > >>>> without
> > >>>>    an external mouse, it's impossible to apply this workaround
> > >>>>   (switching to the terminal -F1, login, and run the command
> > >>>> above might work)
> > >>>>
> > >>>>    I expect to be able to use the touchpad just out of the box, not 
> > >>>> needing
> > >>>>    to run the above workaround
> > >>>>
> > >>> Could you :
> > >>>
> > >>> - Test with the last kernel uploaded to unstable (4.19.0-4:4.19.28) and 
> > >>> confirm or
> > >>>   not is the problem still exists ?
> > >> Dear Romain
> > >>
> > >>
> > >> I upgraded the kernel and rebooted:
> > >>
> > >> schloegl@debian10:~$ uname -a
> > >> Linux debian10 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15)
> > >> x86_64 GNU/Linux
> > >>
> > >>
> > >> With this kernel the trackpoint is working, the trackpad is still not
> > >> usable.
> > >>
> > >> (This improves the situation because now at least one pointer device is
> > >> available).
> > >>
> > >>
> > > Good, we did some progress :)
> > >
> > >>> - According to the bug on launchpad and to the fix pushed upstream, the
> > >>>   fix seems to be an hardware quirks, could you give me the output of 
> > >>> the
> > >>>   following command :
> > >>>   $ /sys/bus/serio/devices/serio1/firmware_id
> > >> root@debian10:~# cat /sys/bus/serio/devices/serio1/firmware_id
> > >> PNP: LEN2036 PNP0f13
> > >>
> > > Could you test the patch attached to this reply ?
> > > (if you don't know how to do this, I can provide support)
> > >
> > > Regards,
> > > Romain
> > 
> > 
> > 
> > I tried to followed these instructions:
> > 
> > https://kernel-team.pages.debian.net/kernel-handbook/ch-comm
> > 
> > 4.5. Building a custom kernel from Debian kernel source
> > 
> > Specifically using the patched the sources,
> > 
> > *scripts/config --disable MODULE_SIG*
> > **scripts/config --disable DEBUG_INFO**
> > ||*|make clean|* ||*|make deb-pkg
> > 
> > |*
> > 
> > and ended up with a kernel that does not boot (missing HD audio firmware),
> > 
> > 
> > Which procedure do you recommend to build and install a modified kernel ?
> > 
> > 
> 
> Hi,
> 
> Section 4.2 from
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official
> , until test-patches should work. For the test-patches script, use the 
> flavour and a
> featureset as argument, when you invoke it, like this :
> 
> # debian/bin/test-patches -f amd64 -s none 
> /path/to/0001-Input-elantech-disable-elan-i2c-for-L480.patch
> 
> This will apply the patch on the fly, configure the kernel for amd64
> and build a version with a special changelog entry and a special suffix
> version dedicated to the test version you generate.
> 
> 
> In case of troubles, I can provide another way, from git with few
> commands.
> 
> 
> Hope this helps,
> Regards,
> Romain

Could you also provide the logs of the non booting kernel ?
If you want I can also build a kernel for you with the fix and then
send you a link via "firefox send" (something secure and free) for example.

Regards,
Romain


signature.asc
Description: PGP signature

Bug#925334: vc4: CMA fills up and screen not updated anymore on raspi3

[Romain Perier]

On Wed, Mar 27, 2019 at 03:29:21PM +0100, Fabian Pietsch wrote:
> Package: src:linux
> Version: 4.19.28-2
> Followup-For: Bug #925334
> 
> Dear Maintainer,
> 
> the bug is still present in the current version. It took a freshly
> booted, idle system 3304 seconds for the bug to occur, though,
> so this time rather an hour (than 10-30min as stated before).
> 
> After the bug has happened, I get the following information from sysfs:
> 
> | root@rpi3:/sys/bus/platform/drivers/vc4_v3d# for I in enabled status 
> active_time suspended_time; do echo -n "$I=$(cat 
> 3fc0.v3d/power/runtime_$I) "; done; echo
> | enabled=enabled status=error active_time=16800 suspended_time=55464216
> 
> And again:
> 
> | enabled=enabled status=error active_time=16800 suspended_time=55479160
> 
> So vc4_v3d which reported the error seems to be in status=error
> and counts as suspended. Manual attempts to get it to resume again,
> now that more cma is free again, failed, but there are probably ways
> I don't know about.
> 
> "echo on > .../power/control" changed runtime_enabled=forbidden
> (and echo auto > control changed it back to runtime_enabled=enabled),
> but runtime_status remained at "error".
> 
> Regards, Fabian
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: arm64 (aarch64)
> 
> Kernel: Linux 4.19.0-4-arm64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_CRAP
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled

Hi,

As discussed on IRC, thanks for your bug report and for the refresh.

Could you test, two stuffs for me ? :

1. The VC4 driver seems to use runtime pm operations, could you try to
disable runtime suspend completly (there are kernel parameters for this
if I remember correctly) ?

2. Your kernel cmdline are... weird, could you try with minimalistic
kernel cmdline ? Only keep console= for logging to uart and/or to your
tty0 and keep your rootfs.


Thanks,
Romain


signature.asc
Description: PGP signature

Bug#924913: trackpad on L480 unusable after upgrade to testing

[Romain Perier]

On Wed, Mar 20, 2019 at 08:24:33AM +0100, Alois Schlögl wrote:
> On 3/18/19 7:46 PM, Romain Perier wrote:
> > On Mon, Mar 18, 2019 at 12:43:10PM +0100, Alois Schlögl wrote:
> >> On 3/18/19 12:20 PM, Romain Perier wrote:
> >>> Hello,
> >>>
> >>> On Mon, Mar 18, 2019 at 11:27:41AM +0100, Alois Schlögl wrote:
> >>>> Source: linux
> >>>> Severity: normal
> >>>>
> >>>> Dear Maintainer,
> >>>>
> >>>>    On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10
> >>>> (testing).
> >>>>    After the upgrade, the touchpad and the trackpoint was not usable
> >>>> anymore.
> >>>>
> >>>>
> >>>>    This already has some bug report here,
> >>>>    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600
> >>>>
> >>>>    As a workaround, one can run the command,
> >>>>    sudo sh -c 'echo -n "elantech">
> >>>> /sys/bus/serio/devices/serio1/protocol'
> >>>>    in order to use the touchpad. However, on a GUI Interface and without
> >>>>    an external mouse, it's impossible to apply this workaround
> >>>>   (switching to the terminal -F1, login, and run the command
> >>>> above might work)
> >>>>
> >>>>    I expect to be able to use the touchpad just out of the box, not 
> >>>> needing
> >>>>    to run the above workaround
> >>>>
> >>> Could you :
> >>>
> >>> - Test with the last kernel uploaded to unstable (4.19.0-4:4.19.28) and 
> >>> confirm or
> >>>   not is the problem still exists ?
> >> Dear Romain
> >>
> >>
> >> I upgraded the kernel and rebooted:
> >>
> >> schloegl@debian10:~$ uname -a
> >> Linux debian10 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15)
> >> x86_64 GNU/Linux
> >>
> >>
> >> With this kernel the trackpoint is working, the trackpad is still not
> >> usable.
> >>
> >> (This improves the situation because now at least one pointer device is
> >> available).
> >>
> >>
> > Good, we did some progress :)
> >
> >>> - According to the bug on launchpad and to the fix pushed upstream, the
> >>>   fix seems to be an hardware quirks, could you give me the output of the
> >>>   following command :
> >>>   $ /sys/bus/serio/devices/serio1/firmware_id
> >> root@debian10:~# cat /sys/bus/serio/devices/serio1/firmware_id
> >> PNP: LEN2036 PNP0f13
> >>
> > Could you test the patch attached to this reply ?
> > (if you don't know how to do this, I can provide support)
> >
> > Regards,
> > Romain
> 
> 
> 
> I tried to followed these instructions:
> 
> https://kernel-team.pages.debian.net/kernel-handbook/ch-comm
> 
> 4.5. Building a custom kernel from Debian kernel source
> 
> Specifically using the patched the sources,
> 
> *scripts/config --disable MODULE_SIG*
> **scripts/config --disable DEBUG_INFO**
> ||*|make clean|* ||*|make deb-pkg
> 
> |*
> 
> and ended up with a kernel that does not boot (missing HD audio firmware),
> 
> 
> Which procedure do you recommend to build and install a modified kernel ?
> 
> 

Hi,

Section 4.2 from
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official
, until test-patches should work. For the test-patches script, use the flavour 
and a
featureset as argument, when you invoke it, like this :

# debian/bin/test-patches -f amd64 -s none 
/path/to/0001-Input-elantech-disable-elan-i2c-for-L480.patch

This will apply the patch on the fly, configure the kernel for amd64
and build a version with a special changelog entry and a special suffix
version dedicated to the test version you generate.


In case of troubles, I can provide another way, from git with few
commands.


Hope this helps,
Regards,
Romain


signature.asc
Description: PGP signature

Bug#924913: trackpad on L480 unusable after upgrade to testing

[Romain Perier]

On Mon, Mar 18, 2019 at 12:43:10PM +0100, Alois Schlögl wrote:
> On 3/18/19 12:20 PM, Romain Perier wrote:
> > Hello,
> >
> > On Mon, Mar 18, 2019 at 11:27:41AM +0100, Alois Schlögl wrote:
> >> Source: linux
> >> Severity: normal
> >>
> >> Dear Maintainer,
> >>
> >>    On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10
> >> (testing).
> >>    After the upgrade, the touchpad and the trackpoint was not usable
> >> anymore.
> >>
> >>
> >>    This already has some bug report here,
> >>    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600
> >>
> >>    As a workaround, one can run the command,
> >>    sudo sh -c 'echo -n "elantech">
> >> /sys/bus/serio/devices/serio1/protocol'
> >>    in order to use the touchpad. However, on a GUI Interface and without
> >>    an external mouse, it's impossible to apply this workaround
> >>   (switching to the terminal -F1, login, and run the command
> >> above might work)
> >>
> >>    I expect to be able to use the touchpad just out of the box, not needing
> >>    to run the above workaround
> >>
> > Could you :
> >
> > - Test with the last kernel uploaded to unstable (4.19.0-4:4.19.28) and 
> > confirm or
> >   not is the problem still exists ?
> 
> 
> Dear Romain
> 
> 
> I upgraded the kernel and rebooted:
> 
> schloegl@debian10:~$ uname -a
> Linux debian10 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15)
> x86_64 GNU/Linux
> 
> 
> With this kernel the trackpoint is working, the trackpad is still not
> usable.
> 
> (This improves the situation because now at least one pointer device is
> available).
> 
>

Good, we did some progress :)

> > - According to the bug on launchpad and to the fix pushed upstream, the
> >   fix seems to be an hardware quirks, could you give me the output of the
> >   following command :
> >   $ /sys/bus/serio/devices/serio1/firmware_id
> 
> 
> root@debian10:~# cat /sys/bus/serio/devices/serio1/firmware_id
> PNP: LEN2036 PNP0f13
> 

Could you test the patch attached to this reply ?
(if you don't know how to do this, I can provide support)

Regards,
Romain
From 79f7fa6db07e2ddb985c560ef48b5a33ddcaffd7 Mon Sep 17 00:00:00 2001
From: Romain Perier 
Date: Mon, 18 Mar 2019 13:36:00 +0100
Subject: [PATCH] Input: elantech - disable elan-i2c for L480

The current implementation of elan_i2c is known to not support this
laptop. Until this is fixed correctly, proceed like for P52 and P72
and disable elan_i2c for the devices we know are not behaving properly.

Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924913

Fixes: df077237cf55 (Input: elantech - detect new ICs and setup Host Notify for them)
Signed-off-by: Romain Perier 
---
 drivers/input/mouse/elantech.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index a7f8b1614559..faeda9cba813 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1781,6 +1781,7 @@ static const char * const i2c_blacklist_pnp_ids[] = {
 	 * These are known to not be working properly as bits are missing
 	 * in elan_i2c.
 	 */
+	"LEN2036", /* Thinkpad L480 */
 	"LEN2131", /* ThinkPad P52 w/ NFC */
 	"LEN2132", /* ThinkPad P52 */
 	"LEN2133", /* ThinkPad P72 w/ NFC */
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#924913: trackpad on L480 unusable after upgrade to testing

[Romain Perier]

Hello,

On Mon, Mar 18, 2019 at 11:27:41AM +0100, Alois Schlögl wrote:
> 
> Source: linux
> Severity: normal
> 
> Dear Maintainer,
> 
>    On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10
> (testing).
>    After the upgrade, the touchpad and the trackpoint was not usable
> anymore.
> 
> 
>    This already has some bug report here,
>    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600
> 
>    As a workaround, one can run the command,
>    sudo sh -c 'echo -n "elantech">
> /sys/bus/serio/devices/serio1/protocol'
>    in order to use the touchpad. However, on a GUI Interface and without
>    an external mouse, it's impossible to apply this workaround
>   (switching to the terminal -F1, login, and run the command
> above might work)
> 
>    I expect to be able to use the touchpad just out of the box, not needing
>    to run the above workaround
> 

Could you :

- Test with the last kernel uploaded to unstable (4.19.0-4:4.19.28) and confirm 
or
  not is the problem still exists ?

- According to the bug on launchpad and to the fix pushed upstream, the
  fix seems to be an hardware quirks, could you give me the output of the
  following command :
  $ /sys/bus/serio/devices/serio1/firmware_id


Thanks,
Regards,
Romain

> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled


signature.asc
Description: PGP signature

firmware-nonfree

[Romain Perier]

Hi all,

I know that's holidays, that's just a reminder to not forget to upload
firmware-nonfree 20181218-1 into archives.

The transition freeze for buster is soonish (it won't be blocking?).
Nowadays, a lot of laptop or dev boards might require these firmware
for some IP blocks.

Enjoy your holidays,
Regards,
Romain

Bug#908632: linux-image-4.19.0-rc3-amd64-unsigned: kernel 4.19 fails to load amdgpu driver on R9 270X.

[Romain Perier]

Hello,


On Fri, Sep 21, 2018 at 02:13:27PM -0300, felipe wrote:
> Tested again with experimental kernel 4.19-rc4 and the result is the same 
> (not able to find firmware) as with 4.19-rc3
> and 4.19-rc2.
> 
> Tried reinstalling the firmware-amd-graphics and firmware-linux packages.
> 
> Booting with kernel parameters 'radeon.si_support=0 amdgpu.si_support=1' and 
> kernel 4.19.rc-4 the system bails and
> cannot find the required firmware which is located at '/lib/firmware/radeon'.
> 
> If I copy the contents of '/lib/firmware/radeon' to '/lib/firmware/amdgpu' 
> and restart, the system boots, loads the
> firmware and works.
> 
> Since previous kernels (4.17, 4.18) the system had no problem finding the 
> correct firmware inside '/lib/firmware/radeon'
> when using amdgpu driver.
>

Yeah that's introduced by commit 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8eaf2b1faaf4358c6337785f2192055c6ef41e0d

Instead of copying all the content of /lib/firmware/radeon into
/lib/firmware/amdgpu, could you:

1. Uninstall firmware-amd-graphics properly so /lib/firmware/radeon and
/lib/firmware/amdgpu are empty
2. Re-install firmware-amd-graphics properly from archives (so,
basically, these two steps undo your changes)
3. Copy only /lib/firmware/radeon/pitcairn_mc.bin to
/lib/firmware/amdgpu/pitcairn_mc.bin

Does this work for you ? Otherwise try to find messages in dmesg
complaining about missing firmware for your amdgpu driver, then
copy the right missing firmwares from /lib/firmware/radeon to
/lib/firmware/amdgpu and then once it works, please paste a list here.

Thanks in advance,
Regards,
Romain

> 
> 
> 
> On 9/13/18 1:44 PM, felipe wrote:
> > Today I had some spare time and I did some tests.
> > 
> > On kernel 4.17 and 4.18 I can switch from radeonsi to amdgpu using/removing 
> > 'radeon.si_support=0 amdgpu.si_support=1'
> > and the system finds and loads the relevant firmware in 
> > /lib/firmware/radeon, giving this system a boost in performance,
> > correct HDMI output and no crashes.
> > 
> > Booting kernel 4.19, the system could not load the relevant firmware when I 
> > tried to use amdgpu, but booted using radeonsi.
> > 
> > Today I did copy all the firmware in '/lib/firmware/radeon' to 
> > '/lib/firmware/amdgpu' and the system booted in a working
> > state and has been stable for the last hour.
> > 
> > Since it is possible to use amdgpu with older GCN cards, the kernel should 
> > also look for the firmware inside
> > '/lib/firmware/radeon' when using 'amdgpu' driver.
> > 
> > 
> > '$ cat /var/log/syslog' of this working session with kernel 4.19-rc3 and 
> > 'cp /lib/firmware/radeon/* /lib/firmware/amdgpu'

Re: Kernel team meeting

[Romain Perier]

Hi,

The first kernel team meeting appended yesterday at 6h33 p.m UTC on
#debian-kernel, it ended at 8h32 p.m UTC.
A summary of the meeting can be found here
http://meetbot.debian.net/debian-kernel/2018/debian-kernel.2018-10-02-18.33.html
The IRC logs of the discussion can be found here
http://meetbot.debian.net/debian-kernel/2018/debian-kernel.2018-10-02-18.33.log.html

I have updated the wiki with informations regarding the meeting on the
wiki https://salsa.debian.org/kernel-team/kernel-team/wikis/Meetings

Regards,
Romain
Le dim. 30 sept. 2018 à 11:35, Romain Perier  a écrit :
>
> Hi,
>
> As everyone has voted on the framadate poll, I propose that the next
> meeting is on Tuesday 02/10 at 6h30 p.m UTC. It will take place on
> #debian-kernel on IRC.
> I will update the wiki about this.
>
> Regards,
> Romain
> Le ven. 28 sept. 2018 à 08:49, Romain Perier  a 
> écrit :
> >
> > Hi,
> >
> > I have opened a framadate for selecting the right date for the next
> > meeting (I can add more date if needed).
> > If you could vote by adding your name...  :)
> >
> > https://framadate.org/4OPvvgZA2CP8wCkB
> >
> > Thanks,
> > Romain
> > Le jeu. 20 sept. 2018 à 08:53, Romain Perier  a 
> > écrit :
> > >
> > > Hi,
> > >
> > > That's on the wiki, I have wrote this
> > > https://salsa.debian.org/kernel-team/kernel-team/wikis/Meetings,  if
> > > the agenda is okay for you, we can discuss about a date for the next
> > > meeting . Could all of you check that you have your name in the
> > > timezone section ?
> > >
> > > Thanks,
> > > Regards,
> > > Romain
> > > Le lun. 17 sept. 2018 à 19:46, Romain Perier  a 
> > > écrit :
> > > >
> > > > Could you (the team) put your timezone under
> > > > https://etherpad.net/p/DebianKernelMeetings please ? That's a temp
> > > > note, I will move everything to the wiki of the project (that's under
> > > > discussion with waldi and Corsac)
> > > >
> > > > Thanks,
> > > > Romain
> > > > Le lun. 17 sept. 2018 à 13:42, Salvatore Bonaccorso
> > > >  a écrit :
> > > > >
> > > > > Hi Romain,
> > > > >
> > > > > On Fri, Aug 31, 2018 at 08:43:50AM +0200, Romain Perier wrote:
> > > > > > Hello,
> > > > > >
> > > > > > I have started the discussion on IRC, but as suggested by Ben, 
> > > > > > that's
> > > > > > better to forward this on the ML.
> > > > > >
> > > > > > This could be interesting to organize kernel team meetings (few per
> > > > > > year for a beginning?). We could talk about the last discussions at
> > > > > > the debconf that might impact us (generally speaking, get feedback 
> > > > > > on
> > > > > > conferences, for example), or what are the current hot topics , or
> > > > > > what is the status the of the last security issues... etc (all of
> > > > > > these are just examples). That would improve communication in the
> > > > > > team, co-working, etc...
> > > > > >
> > > > > > I can help for organization,
> > > > >
> > > > > Thanks for raising that! I think that would be a good idea.
> > > > >
> > > > > Regards,
> > > > > Salvatore

Re: Kernel team meeting

[Romain Perier]

Hi,

As everyone has voted on the framadate poll, I propose that the next
meeting is on Tuesday 02/10 at 6h30 p.m UTC. It will take place on
#debian-kernel on IRC.
I will update the wiki about this.

Regards,
Romain
Le ven. 28 sept. 2018 à 08:49, Romain Perier  a écrit :
>
> Hi,
>
> I have opened a framadate for selecting the right date for the next
> meeting (I can add more date if needed).
> If you could vote by adding your name...  :)
>
> https://framadate.org/4OPvvgZA2CP8wCkB
>
> Thanks,
> Romain
> Le jeu. 20 sept. 2018 à 08:53, Romain Perier  a 
> écrit :
> >
> > Hi,
> >
> > That's on the wiki, I have wrote this
> > https://salsa.debian.org/kernel-team/kernel-team/wikis/Meetings,  if
> > the agenda is okay for you, we can discuss about a date for the next
> > meeting . Could all of you check that you have your name in the
> > timezone section ?
> >
> > Thanks,
> > Regards,
> > Romain
> > Le lun. 17 sept. 2018 à 19:46, Romain Perier  a 
> > écrit :
> > >
> > > Could you (the team) put your timezone under
> > > https://etherpad.net/p/DebianKernelMeetings please ? That's a temp
> > > note, I will move everything to the wiki of the project (that's under
> > > discussion with waldi and Corsac)
> > >
> > > Thanks,
> > > Romain
> > > Le lun. 17 sept. 2018 à 13:42, Salvatore Bonaccorso
> > >  a écrit :
> > > >
> > > > Hi Romain,
> > > >
> > > > On Fri, Aug 31, 2018 at 08:43:50AM +0200, Romain Perier wrote:
> > > > > Hello,
> > > > >
> > > > > I have started the discussion on IRC, but as suggested by Ben, that's
> > > > > better to forward this on the ML.
> > > > >
> > > > > This could be interesting to organize kernel team meetings (few per
> > > > > year for a beginning?). We could talk about the last discussions at
> > > > > the debconf that might impact us (generally speaking, get feedback on
> > > > > conferences, for example), or what are the current hot topics , or
> > > > > what is the status the of the last security issues... etc (all of
> > > > > these are just examples). That would improve communication in the
> > > > > team, co-working, etc...
> > > > >
> > > > > I can help for organization,
> > > >
> > > > Thanks for raising that! I think that would be a good idea.
> > > >
> > > > Regards,
> > > > Salvatore

Bug#908438: cubietruck wifi reversion

[Romain Perier]

Hello,

Could you retry with linux-image-4.18.0-1-armmp-lpae, please ?

Thanks,
Regards,
Romain

On Sun, Sep 09, 2018 at 06:24:41PM -0400, Joey Hess wrote:
> Source: linux
> Version: 4.17.17-1
> Severity: normal
> 
> On a cubietruck board, the linux-image-4.17.0-3-armmp-lpae kernel kernel
> fails to enable the builtin wifi:
> 
> Sep 09 17:52:52 honeybee kernel: brcmfmac: brcmf_fw_alloc_request: using 
> brcm/brcmfmac43362-sdio for chip BCM43362/1
> Sep 09 17:52:52 honeybee kernel: usbcore: registered new interface driver 
> brcmfmac
> Sep 09 17:52:52 honeybee kernel: brcmfmac mmc1:0001:1: firmware: 
> direct-loading firmware brcm/brcmfmac43362-sdio.bin
> Sep 09 17:52:52 honeybee kernel: brcmfmac mmc1:0001:1: firmware: 
> direct-loading firmware brcm/brcmfmac43362-sdio.txt
> Sep 09 17:52:55 honeybee kernel: brcmfmac: brcmf_sdio_bus_rxctl: resumed on 
> timeout
> Sep 09 17:52:55 honeybee kernel: brcmfmac: brcmf_bus_started: failed: -110
> Sep 09 17:52:55 honeybee kernel: brcmfmac: brcmf_attach: dongle is not 
> responding: err=-110
> Sep 09 17:52:55 honeybee kernel: brcmfmac: brcmf_sdio_firmware_callback: 
> brcmf_attach failed
> 
> This was working using linux-image-4.14.0-3-armmp-lpae and earlier kernels
> including stable's, so seems to be a reversion.
> 
> I have firmware-brcm80211 installed. I tried downgrading it to the same
> version I was using with the older kernel (20170823-1), but that did not help,
> so I don't think it's a problem with the firmware.
> 
> Here it is working with the older kernel, for comparison:
> 
> Sep 09 18:06:10 honeybee kernel: brcmfmac: brcmf_fw_map_chip_to_name: using 
> brcm/brcmfmac43362-sdio.bin for chip 0x00a962(43362) rev 0x01
> Sep 09 18:06:10 honeybee kernel: usbcore: registered new interface driver 
> brcmfmac
> Sep 09 18:06:10 honeybee kernel: brcmfmac mmc1:0001:1: firmware: 
> direct-loading firmware brcm/brcmfmac43362-sdio.bin
> Sep 09 18:06:10 honeybee kernel: brcmfmac mmc1:0001:1: firmware: 
> direct-loading firmware brcm/brcmfmac43362-sdio.txt
> Sep 09 18:06:10 honeybee kernel: brcmfmac: brcmf_c_preinit_dcmds: Firmware 
> version = wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
> 
> -- 
> see shy jo

Bug#908702: linux-image-4.18.0-1-amd64 prevents use of internet (more or less)

[Romain Perier]

Hi,

If reportbug is not usable for you, could you:
- attach the output of "dmesg" to this bug
- attach the output of "lspci" to this bug

Please,

Thanks,
Romain


On Wed, Sep 12, 2018 at 01:48:51PM -0400, g...@safe-mail.net wrote:
> Package: linux-image-4.18.0-1-amd64
> Version: 4.18.6-1
> Severity: Grave
> 
> 
> Dear maintainer,
> 
> after today's upgrade from 4.17.0-3 to 4.18.0-1 internet access is hardly 
> possible anymore. Speed is less than 5 % of what is used to be and for that 
> reason the browser frequently shows "No internet connection" instead of a 
> webpage.
> 
> Checking with another system at the same time shows that the internet 
> connection as such is working fine. Booting the system with the old kernel 
> 4.17.0-3 the problem does not arise, so the problem most probably is caused 
> by 4.18.0-1 (or a package used by 4.18.0-1 but not by 4.17.0-3) and not by 
> jointly used packages or hardware. Log files are identical as far as I can 
> see and my system is up to date (tracking testing, just missing the most 
> recent updates of irrelevant packages like libreoffice and vlc). Connection 
> to the internet is by LAN to a Huawei LTE router.
> 
> Due to bug #908578 I could not use reportbug to file this bug. Sorry if this 
> means that some information is missing.
> 
> Best regards
> G. Heine

Re: Kernel team meeting

[Romain Perier]

Hi,

That's on the wiki, I have wrote this
https://salsa.debian.org/kernel-team/kernel-team/wikis/Meetings,  if
the agenda is okay for you, we can discuss about a date for the next
meeting . Could all of you check that you have your name in the
timezone section ?

Thanks,
Regards,
Romain
Le lun. 17 sept. 2018 à 19:46, Romain Perier  a écrit :
>
> Could you (the team) put your timezone under
> https://etherpad.net/p/DebianKernelMeetings please ? That's a temp
> note, I will move everything to the wiki of the project (that's under
> discussion with waldi and Corsac)
>
> Thanks,
> Romain
> Le lun. 17 sept. 2018 à 13:42, Salvatore Bonaccorso
>  a écrit :
> >
> > Hi Romain,
> >
> > On Fri, Aug 31, 2018 at 08:43:50AM +0200, Romain Perier wrote:
> > > Hello,
> > >
> > > I have started the discussion on IRC, but as suggested by Ben, that's
> > > better to forward this on the ML.
> > >
> > > This could be interesting to organize kernel team meetings (few per
> > > year for a beginning?). We could talk about the last discussions at
> > > the debconf that might impact us (generally speaking, get feedback on
> > > conferences, for example), or what are the current hot topics , or
> > > what is the status the of the last security issues... etc (all of
> > > these are just examples). That would improve communication in the
> > > team, co-working, etc...
> > >
> > > I can help for organization,
> >
> > Thanks for raising that! I think that would be a good idea.
> >
> > Regards,
> > Salvatore

Re: Kernel team meeting

[Romain Perier]

Could you (the team) put your timezone under
https://etherpad.net/p/DebianKernelMeetings please ? That's a temp
note, I will move everything to the wiki of the project (that's under
discussion with waldi and Corsac)

Thanks,
Romain
Le lun. 17 sept. 2018 à 13:42, Salvatore Bonaccorso
 a écrit :
>
> Hi Romain,
>
> On Fri, Aug 31, 2018 at 08:43:50AM +0200, Romain Perier wrote:
> > Hello,
> >
> > I have started the discussion on IRC, but as suggested by Ben, that's
> > better to forward this on the ML.
> >
> > This could be interesting to organize kernel team meetings (few per
> > year for a beginning?). We could talk about the last discussions at
> > the debconf that might impact us (generally speaking, get feedback on
> > conferences, for example), or what are the current hot topics , or
> > what is the status the of the last security issues... etc (all of
> > these are just examples). That would improve communication in the
> > team, co-working, etc...
> >
> > I can help for organization,
>
> Thanks for raising that! I think that would be a good idea.
>
> Regards,
> Salvatore

Re: Kernel team meeting

[Romain Perier]

Le lun. 17 sept. 2018 à 09:22, Yves-Alexis Perez  a écrit :
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Sat, 2018-09-15 at 17:37 +0100, Ben Hutchings wrote:
> > Yes, let's do this.  I would be happy to meet for up to an hour with a
> > defined agenda.  Can you set up a poll for when people are available,
> > and an etherpad or other shared document for the agenda?
>
> Quick question for both: are we speaking physical or online meetings? Seems
> that “an hour” and “multiple time per year” indicate online, but a
> confirmation would be nice.

Hello,

I had in mind an online IRC meeting, so logs of the meeting can be
saved and retrieved
later by anyone.

Regards,
Romain

Re: Kernel team meeting

[Romain Perier]

Hello,

ping ? :)

Regards,
Romain
Le ven. 31 août 2018 à 08:43, Romain Perier  a écrit :
>
> Hello,
>
> I have started the discussion on IRC, but as suggested by Ben, that's
> better to forward this on the ML.
>
> This could be interesting to organize kernel team meetings (few per
> year for a beginning?). We could talk about the last discussions at
> the debconf that might impact us (generally speaking, get feedback on
> conferences, for example), or what are the current hot topics , or
> what is the status the of the last security issues... etc (all of
> these are just examples). That would improve communication in the
> team, co-working, etc...
>
> I can help for organization,
>
> Thanks,
> Regards,
> Romain

Bug#908248: Patch available but not part in mainstream

[Romain Perier]

On Mon, Sep 10, 2018 at 08:15:29PM +, tomas.lac...@binaryx.eu wrote:
> Hello team,
> 
> There seems to be patch available, but not part of upstream kernel source yet 
> (checked against 4.18.7 git), provided by AMD employee.
> Applied the patch listed from page below to 4.18.6 kernel from kernel.org and 
> no issues visible related to udev stuck as reported before.
> 
> https://lore.kernel.org/patchwork/patch/974869/ 
> (https://lore.kernel.org/patchwork/patch/974869/)
> 
> BRTL

Hello,

Merge request opened, see 
https://salsa.debian.org/kernel-team/linux/merge_requests/62
(it depends on previous opened merge request, just focus on the HEAD commit)

Thanks,
Regards,
Romain

Bug#904428: linux-image-4.17.0-1-amd64: sound pops/clicks with snd_hda_intel unless power saving is disabled

[Romain Perier]

Hi,

Just to let you know that 4.18.0-1 (that is kernel 4.18.6) is now in sid, so
you have to test this and no longer the one present in experimental.

Thanks,
Romain

On Sat, Sep 08, 2018 at 04:27:16PM +0200, Salvatore Bonaccorso wrote:
> tags 904428 + moreinfo
> thanks
> 
> 

Kernel team meeting

[Romain Perier]

Hello,

I have started the discussion on IRC, but as suggested by Ben, that's
better to forward this on the ML.

This could be interesting to organize kernel team meetings (few per
year for a beginning?). We could talk about the last discussions at
the debconf that might impact us (generally speaking, get feedback on
conferences, for example), or what are the current hot topics , or
what is the status the of the last security issues... etc (all of
these are just examples). That would improve communication in the
team, co-working, etc...

I can help for organization,

Thanks,
Regards,
Romain

Bug#904428: linux-image-4.17.0-1-amd64: sound pops/clicks with snd_hda_intel unless power saving is disabled

[Romain Perier]

Hi,

See:
1. https://bugzilla.kernel.org/show_bug.cgi?id=200687
and
2. 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/sound/pci/hda/hda_intel.c?id=38d9c12c0a6d41a82fb6d1278d430bbf35301ce5

as Hans de Goede said, this does not seems to be fixed in 4.17.x but it
is part of 4.18.x .

Could you test with 4.18.5-1~exp1 present in experimental ?
If you don't know how to do this, feel free to ask, I can
provide feedback.

Thanks,
Romain

On Tue, Jul 24, 2018 at 10:32:26AM +0200, Gard Spreemann wrote:
> Package: src:linux
> Version: 4.17.8-1
> Severity: important
> Tags: upstream
> 
> Dear Maintainer,
> 
> After upgrading from linux-image-4.16.0-2-amd64 to
> linux-image-4.17.0-1-amd64, my computer's sound card exhibits an
> audible and annoying pop or click when an audio stream is about to
> play or stop playing. The pop/click was not present with earlier
> kernels.
> 
> Turning off power saving with
> 
>  options snd_hda_intel power_save=0 power_save_controller=N
> 
> as per Redhat bug 1525104 [1] works around the problem (no pop/click).
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1525104
> 
> 
> -- Package-specific info:
> ** Version:
> Linux version 4.17.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 
> 7.3.0 (Debian 7.3.0-26)) #1 SMP Debian 4.17.8-1 (2018-07-20)
> 
> ** Command line:
> BOOT_IMAGE=/boot/vmlinuz-4.17.0-1-amd64 
> root=UUID=546f4738-0d40-4e33-b17a-29b58fe436dd ro
> 
> ** Not tainted

Bug#883181: linux-image-4.9.0-4-amd64: Default stretch kernel raises cgroup strack traces under high load

[Romain Perier]

Hi,


The last linux kernel in stretch being 4.9.110, could you re-test with this
kernel please ?

Thanks,
Regards,
Romain

On Thu, Nov 30, 2017 at 11:54:00AM +, Tom Stocker wrote:
> Package: src:linux
> Version: 4.9.51-1
> Severity: serious
> Justification: Policy 2.2.1
> 
> 
> 
> -- Package-specific info:
> ** Version:
> Linux version 4.9.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 
> 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.51-1 (2017-09-28)
> 
> ** Command line:
> BOOT_IMAGE=/boot/vmlinuz-4.9.0-4-amd64 
> root=/dev/mapper/de--bln--vm--017--vg-root ro quiet
> 
> ** Not tainted
> 
> ** Kernel log:
> [1.533757] EXT4-fs (dm-1): mounted filesystem with ordered data mode. 
> Opts: (null)
> [1.847797] ip_tables: (C) 2000-2006 Netfilter Core Team
> [1.912833] systemd[1]: systemd 232 running in system mode. (+PAM +AUDIT 
> +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS 
> +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
> [1.912859] systemd[1]: Detected virtualization vmware.
> [1.912863] systemd[1]: Detected architecture x86-64.
> [1.914546] systemd[1]: Set hostname to .
> [2.058639] random: crng init done
> [2.131752] systemd[1]: Set up automount Arbitrary Executable File Formats 
> File System Automount Point.
> [2.131812] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
> [2.131843] systemd[1]: Listening on Syslog Socket.
> [2.131885] systemd[1]: Started Forward Password Requests to Wall 
> Directory Watch.
> [2.131920] systemd[1]: Listening on udev Control Socket.
> [2.131955] systemd[1]: Started Dispatch Password Requests to Console 
> Directory Watch.
> [2.363268] EXT4-fs (dm-1): re-mounted. Opts: errors=remount-ro
> [2.516531] systemd-journald[833]: Received request to flush runtime 
> journal from PID 1
> [2.819683] input: Power Button as 
> /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
> [2.819691] ACPI: Power Button [PWRF]
> [2.819819] ACPI: AC Adapter [ACAD] (on-line)
> [2.875315] input: PC Speaker as /devices/platform/pcspkr/input/input5
> [2.881700] vmw_vmci :00:07.7: Found VMCI PCI device at 0x11080, irq 16
> [2.881767] vmw_vmci :00:07.7: Using capabilities 0xc
> [2.882410] Guest personality initialized and is active
> [2.882410] VMCI host device registered (name=vmci, major=10, minor=58)
> [2.882410] Initialized host personality
> [2.930410] [drm] Initialized
> [2.941291] sd 0:0:0:0: Attached scsi generic sg0 type 0
> [2.941374] sd 0:0:1:0: Attached scsi generic sg1 type 0
> [2.941446] sd 0:0:2:0: Attached scsi generic sg2 type 0
> [2.941516] sd 0:0:3:0: Attached scsi generic sg3 type 0
> [2.941562] sr 2:0:0:0: Attached scsi generic sg4 type 5
> [3.012775] [drm] DMA map mode: Using physical TTM page addresses.
> [3.012868] [drm] Capabilities:
> [3.012873] [drm]   Rect copy.
> [3.012874] [drm]   Cursor.
> [3.012875] [drm]   Cursor bypass.
> [3.012876] [drm]   Cursor bypass 2.
> [3.012877] [drm]   8bit emulation.
> [3.012878] [drm]   Alpha cursor.
> [3.012879] [drm]   Extended Fifo.
> [3.012880] [drm]   Multimon.
> [3.012881] [drm]   Pitchlock.
> [3.012882] [drm]   Irq mask.
> [3.012883] [drm]   Display Topology.
> [3.012884] [drm]   GMR.
> [3.012885] [drm]   Traces.
> [3.012886] [drm]   GMR2.
> [3.012887] [drm]   Screen Object 2.
> [3.012888] [drm]   Command Buffers.
> [3.012889] [drm]   Command Buffers 2.
> [3.012890] [drm]   Guest Backed Resources.
> [3.012891] [drm]   DX Features.
> [3.012893] [drm] Max GMR ids is 64
> [3.012894] [drm] Max number of GMR pages is 65536
> [3.012895] [drm] Max dedicated hypervisor surface memory is 0 kiB
> [3.012896] [drm] Maximum display memory size is 4096 kiB
> [3.012898] [drm] VRAM at 0xe800 size is 4096 kiB
> [3.012899] [drm] MMIO at 0xfe00 size is 256 kiB
> [3.012901] [drm] global init.
> [3.013022] [TTM] Zone  kernel: Available graphics memory: 60855752 kiB
> [3.013023] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
> [3.013024] [TTM] Initializing pool allocator
> [3.013029] [TTM] Initializing DMA pool allocator
> [3.013122] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [3.013127] [drm] No driver support for vblank timestamp query.
> [3.013382] [drm] Screen Target Display device initialized
> [3.013441] [drm] width 640
> [3.013453] [drm] height 480
> [3.013465] [drm] bpp 32
> [3.014570] [drm] Fifo max 0x0004 min 0x1000 cap 0x077f
> [3.015450] [drm] Using command buffers with DMA pool.
> [3.015460] [drm] DX: no.
> [3.015695] fbcon: svgadrmfb (fb0) is primary device
> [3.017598] Console: switching to colour frame buffer device 100x37
> [3.096662] ppdev: user-space parallel port driver
> [3.112337] [drm] Initialized vmwgfx 2.12.0 

Bug#887102: Please add quirk US_FL_BROKEN_FUA JMS567-based USB3 UAS enclosure (152d:0578) to stretch debian kernels

[Romain Perier]

On Sat, Jan 13, 2018 at 09:29:27PM +0100, Laurent GUERBY wrote:
> Package: linux
> Version: 4.9.65-3+deb9u
> Severity: wishlist
> 
> Hi,
> 
> The quirk  US_FL_BROKEN_FUA JMS567-based USB3 UAS enclosure
> (152d:0578) has been added by this patch :
> 
> https://patchwork.kernel.org/patch/10120851/
> 
> It has been included by upstream kernel 4.9.71 and 4.14.8 but isn't
> available on released debian kernel stretch and stretch-backports.
> 
> We have a debian stretch machine with this USB3 enclosure and we get
> this kind of error which should be fixed by the quirk:
> 
> https://unix.stackexchange.com/questions/237204/filesystem-is-reporting
> -a-write-error-on-a-specific-sector-even-after-the-partit
> 
> Thanks in advance for your help,
> 
> Sincerely,
> 
> Laurent

Hi,

The last linux kernel in stretch being 4.9.110, could you re-test with this
kernel please ? Does it solve your problem ?

Thanks,
Romain

Re: Need of debian OS with kernel list

[Romain Perier]

Hello,

You can have a look at this site
https://packages.debian.org/fr/stretch/linux-image-amd64, supposing
you want to install a kernel image for amd64.

Stretch is the current stable release with kernel 4.9.110.
Buster is the next stable release (testing)
Sid is the development release (unstable).

In your case, I think you need to focus on Stretch as you probably
want something stable.
You can download an iso image for installing stretch here
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/

I hope it helps,

Regards,
Romain

2018-07-18 9:27 GMT+02:00 cmurugan :
> Hello Sir,
>
> I'm System administrator. I'm asked to install kernel 4.9 in debian OS. But
> I'm not sure which debian OS have 4.9 kernel. So could you please share me
> "debian OS with kernel list " at the time debian OS release.
>
> Thanks,
> Murugan Chandrasekar
>

Upload latest firmware-nonfree into archives

[Romain Perier]

Hello,

Once merge request
https://salsa.debian.org/kernel-team/firmware-nonfree/merge_requests/4
is merged, I think it would be a good thing to upload firmware-nonfree
into archives.

It fixes ~8 bugs and several CVE .

Feel free to ping me, If I can provide any help,

Romain

Re: bugs.debian.org is randomly failing for src:linux

[Romain Perier]

Hello,

2018-07-03 21:20 GMT+02:00 Don Armstrong :
>
> Yeah, I'm aware of the issue, and unfortunately, the solution is quite
> complicated and involves larger changes to the way bugs are served by
> the BTS.

Yeah, I suspected that you were already aware of the issue :) .

>
> However, these changes *are* in progress, and eventually they should be
> fixed.
>
> I've fixed a few of the lower hanging fruit, but src:linux keeps
> breaking as new bugs are filed and the archive itself gets larger. I'll
> try to fix a few more as I get a chance.

Ah, good to know !

>
> While you're waiting for me to do that,
> https://bugs-devel.debian.org/cgi-bin/pkgreport.cgi?src=linux works, and
> I will try to keep it working. I haven't advertised this widely because
> I will likely break it from time to time (and the interface will
> definitely change).

Thanks your this link and for your reply. It seems to work better
indeed. Even, if
I get some troubles with it, it cannot be worse than the others links,
So it will be okay don't worry ;) .
If on my side I can provide any help (regarding src:linux bugs), feel
free to ping me.

Regards,
Romain

bugs.debian.org is randomly failing for src:linux

[Romain Perier]

Hello,

I am a Debian contributor. Currently, we have a ton of linux kernel
bugs assigned to src:linux.
Most of the time http://bugs.debian.org/src:linux is failing with an
error "500 Internal Server Error".

After discussing about the issue on IRC, it seems to be caused by a
too important number of bugs on our side. Several hacks were
suggested, I have tried to use bugs-master or bugs-buxtehude instead,
these worked for a time, but it's still randomly failing.


Would you have a solution or an idea of the problem ?

Thanks for your time,
Have a nice day,
Romain

Bug#898267: [firmware-misc-nonfree] Missing firmware i915/kbl_dmc_ver1_04.bin

[Romain Perier]

Hello,

could you provide us the kernel logs ? By running dmesg
or journalctl -b.

Thanks

On Wed, May 09, 2018 at 03:55:18PM +0300, Alexander Kernozhitsky wrote:
> Package: firmware-misc-nonfree
> Version: 20170823-1
> Severity: minor
> 
> Linux kernel shows me the warning at boot time. It looks like "missing 
> firmware i915/kbl_dmc_ver1_04.bin", but the package contains i915/
> kbl_dmc_ver1_01.bin. A newer kernel requires 1.04 version. Please update the 
> firmware.
> 
> --- System information. ---
> Architecture: 
> Kernel:   Linux 4.16.0-1-amd64
> 
> Debian Release: buster/sid
>   990 testing ftp.by.debian.org 
>   500 unstableftp.by.debian.org 
> 
> --- Package information. ---
> Package's Depends field is empty.
> 
> Package's Recommends field is empty.
> 
> Suggests (Version) | Installed
> ==-+-===
> initramfs-tools| 0.130
> -- 
> -
> Alexander Kernozhitsky

Re: Processed: reopening 897204, found 897204 in 4.15.17-1, tagging 897204

[Romain Perier]

Hi,


2018-05-04 9:04 GMT+02:00 Salvatore Bonaccorso <car...@debian.org>:
> Hi Romain,
>
> On Fri, May 04, 2018 at 08:44:32AM +0200, Romain Perier wrote:
>> Hello,
>>
>> Whoops, I did something wrong apparently, sorry.
>> So I only fixed the issue in sid (4.16), I have to wait that the
>> package is in buster before closing this bug, I guess, right ?
>
> My point was to reopen the bug, the closer is marked correctly in the
> debian/changelog file and it is actually not yet fixed, only in the
> packaging repository commited. Once 4.16.5-2 or maybe an iteration
> with an 4.16.7 import on top, will enter the archive, the BTS will
> correctly handle the closing of the bug (and with correct version, say
> we have then 4.16.7-1 at the time including your change, then the bug
> will bie closed with that version on upload and archive entering
> time).

Ah, I see. I did not know that BTS closes bugs automatically (I need
to continue to read documentation about it).
It makes sense, yes.

>
> Hope this explains my reopening, marking yet as unfixed, tagging as
> pending.

It does, yes :)

Thanks,
Romain

Re: Processed: reopening 897204, found 897204 in 4.15.17-1, tagging 897204

[Romain Perier]

Hello,

Whoops, I did something wrong apparently, sorry.
So I only fixed the issue in sid (4.16), I have to wait that the
package is in buster before closing this bug, I guess, right ?

Romain

2018-05-03 22:18 GMT+02:00 Debian Bug Tracking System :
> Processing commands for cont...@bugs.debian.org:
>
>> reopen 897204
> Bug #897204 {Done: romain.per...@gmail.com} [src:linux] 
> linux-image-4.15.0-3-armmp: Please enable CONFIG_DRM_DW_HDMI_AHB_AUDIO=m and 
> CONFIG_DRM_DW_HDMI_CEC=m
> 'reopen' may be inappropriate when a bug has been closed with a version;
> all fixed versions will be cleared, and you may need to re-add them.
> Bug reopened
> No longer marked as fixed in versions linux/4.16.5-2.
>> found 897204 4.15.17-1
> Bug #897204 [src:linux] linux-image-4.15.0-3-armmp: Please enable 
> CONFIG_DRM_DW_HDMI_AHB_AUDIO=m and CONFIG_DRM_DW_HDMI_CEC=m
> Ignoring request to alter found versions of bug #897204 to the same values 
> previously set
>> tags 897204 + pending
> Bug #897204 [src:linux] linux-image-4.15.0-3-armmp: Please enable 
> CONFIG_DRM_DW_HDMI_AHB_AUDIO=m and CONFIG_DRM_DW_HDMI_CEC=m
> Added tag(s) pending.
>> thanks
> Stopping processing here.
>
> Please contact me if you need assistance.
> --
> 897204: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897204
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#897590: linux-image-4.9.0-6-armmp: Missing CONFIG_MFD_TPS65217 may cause hardware damage

[Romain Perier]

Hello,

I have proposed a merge request for this at
https://salsa.debian.org/kernel-team/linux/merge_requests/12

Thanks,
Regards,
Romain

On Thu, May 03, 2018 at 10:03:14AM +, PA Nilsson wrote:
> Package: src:linux
> Version: 4.9.82-1+deb9u3
> Severity: grave 
> 
> Dear Maintainer,
> 
> When shutting down BeagleBoneBlack, running Debian 9.3, it was
> discovered that the system still draws excessive power and puts the
> system out of spec with possible hardware damage as a result.
> 
> This is due to the PMIC not shutting down correctly, as described by the
> referenced posts:
> http://bugs.elinux.org/issues/143
> https://groups.google.com/forum/#%21msg/beagleboard/7sxPePT7wkM/V1Ft-xxh0agJ
> 
> This in turn is due to the driver for the PMIC is not avaialble since
> CONFIG_MFD_TPS65217 is missing.
> 
> Setting CONFIG_MFD_TPS65217 will enable the correct shutdown procedure.
> 
> 
> 
> -- Package-specific info:
> ** Version:
> Linux version 4.9.0-6-armmp (debian-kernel@lists.debian.org) (gcc version 
> 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02)
> 
> ** Command line:
> console=ttyO0,115200n8 root=/dev/mmcblk1p2 rw rootfstype=ext4 rootwait
> 
> ** Not tainted
> 
> ** Kernel log:
> Unable to read kernel log; any relevant messages should be attached
> 
> ** Model information
> Hardware  : Generic AM33XX (Flattened Device Tree)
> Revision  : 
> Device Tree model: TI AM335x BeagleBone Black
> 
> ** Loaded modules:
> dm_crypt
> dm_mod
> xts
> gf128mul
> algif_skcipher
> af_alg
> sd_mod
> sg
> uas
> usb_storage
> scsi_mod
> fuse
> snd_soc_simple_card
> snd_soc_simple_card_utils
> omap_aes
> omap_sham
> crypto_engine
> omap_rng
> rng_core
> tilcdc
> snd_soc_davinci_mcasp
> snd_soc_omap
> ledtrig_heartbeat
> omap_hwspinlock
> ledtrig_timer
> tda998x
> hwspinlock_core
> snd_soc_core
> snd_pcm_dmaengine
> snd_pcm
> drm_kms_helper
> snd_timer
> snd
> soundcore
> at24
> cppi41
> omap_wdt
> drm
> leds_gpio
> cpufreq_dt
> nvmem_core
> nf_conntrack_ipv4
> nf_defrag_ipv4
> xt_tcpudp
> xt_conntrack
> nf_conntrack
> iptable_filter
> ip_tables
> x_tables
> autofs4
> ext4
> crc16
> jbd2
> crc32c_generic
> fscrypto
> ecb
> mbcache
> smsc
> musb_dsps
> musb_hdrc
> udc_core
> davinci_mdio
> usbcore
> phy_am335x
> phy_generic
> usb_common
> phy_am335x_control
> ti_cpsw
> cpsw_ale
> cpsw_common
> davinci_cpdma
> omap_hsmmc
> musb_am335x
> 
> ** PCI devices:
> not available
> 
> ** USB devices:
> not available
> 
> 
> -- System Information:
> Debian Release: 9.4
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: armhf (armv7l)
> 
> Kernel: Linux 4.9.0-6-armmp (SMP w/1 CPU core)
> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
> (charmap=ANSI_X3.4-1968)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages linux-image-4.9.0-6-armmp depends on:
> ii  initramfs-tools [linux-initramfs-tool]  0.130
> ii  kmod23-2
> ii  linux-base  4.5
> 
> Versions of packages linux-image-4.9.0-6-armmp recommends:
> pn  firmware-linux-free  
> pn  irqbalance   
> 
> Versions of packages linux-image-4.9.0-6-armmp suggests:
> pn  debian-kernel-handbook  
> pn  linux-doc-4.9   
> 
> Versions of packages linux-image-4.9.0-6-armmp is related to:
> pn  firmware-amd-graphics 
> pn  firmware-atheros  
> pn  firmware-bnx2 
> pn  firmware-bnx2x
> pn  firmware-brcm80211
> pn  firmware-cavium   
> pn  firmware-intel-sound  
> pn  firmware-intelwimax   
> pn  firmware-ipw2x00  
> pn  firmware-ivtv 
> pn  firmware-iwlwifi  
> pn  firmware-libertas 
> pn  firmware-linux-nonfree
> pn  firmware-misc-nonfree 
> pn  firmware-myricom  
> pn  firmware-netxen   
> pn  firmware-qlogic   
> pn  firmware-realtek  
> pn  firmware-samsung  
> pn  firmware-siano
> pn  firmware-ti-connectivity  
> pn  xen-hypervisor
> 
> -- no debconf information

Bug#897204: linux-image-4.15.0-3-armmp: Please enable CONFIG_DRM_DW_HDMI_AHB_AUDIO=m and CONFIG_DRM_DW_HDMI_CEC=m

[Romain Perier]

Hello,

This has been fixed in
https://salsa.debian.org/kernel-team/linux/commit/ff277a8c4c916aa022acd9a4201519cc995a1040.
It will be part of linux-image-4.16.5-2-armmp.

Regards,
Romain

On Mon, Apr 30, 2018 at 12:24:52AM +, Korbinian Rosenegger wrote:
> Package: src:linux
> Version: 4.15.17-1+local
> Severity: wishlist
> 
> Dear Maintainer,
> 
> please enable these two options for supporting audio and CEC over HDMI on the 
> SolidRun Cubox-i
> 
> CONFIG_DRM_DW_HDMI_AHB_AUDIO=m
> CONFIG_DRM_DW_HDMI_CEC=m
> 
> 
> At the moment I'm using a self compiled kernel package.
> 
> 
> Thank you :)
> 
> 
> Korbi
> 
> 
> 
> 
> -- Package-specific info:
> ** Version:
> Linux version 4.15.0-3-armmp (debian-kernel@lists.debian.org) (gcc version 
> 7.3.0 (Debian 7.3.0-15)) #1 SMP Debian 4.15.17-1+local (2018-04-25)
> 
> ** Command line:
> root=/dev/mmcblk1p1 ro quiet cma=256M
> 
> ** Tainted: O (4096)
>  * Out-of-tree module has been loaded.
> 
> ** Kernel log:
> Unable to read kernel log; any relevant messages should be attached
> 
> ** Model information
> Hardware  : Freescale i.MX6 Quad/DualLite (Device Tree)
> Revision  : 
> Device Tree model: SolidRun Cubox-i Dual/Quad
> 
> ** Loaded modules:
> joydev
> hid_generic
> usbhid
> brcmfmac
> brcmutil
> dw_hdmi_cec
> cfg80211
> hid
> dw_hdmi_ahb_audio
> cec
> rfkill
> ahci_imx
> libahci_platform
> libahci
> snd_soc_imx_spdif
> snd_soc_fsl_spdif
> imx_pcm_dma
> libata
> snd_soc_core
> snd_pcm_dmaengine
> ir_lirc_codec
> lirc_dev
> snd_pcm
> scsi_mod
> snd_timer
> imx2_wdt
> snd
> soundcore
> gpio_ir_recv
> dw_hdmi_imx(O)
> rc_core
> pwm_imx
> leds_pwm
> imxdrm(O)
> dw_hdmi(O)
> imx_ipu_v3
> imx6q_cpufreq
> etnaviv
> tda998x
> drm_kms_helper
> drm
> ip_tables
> x_tables
> autofs4
> ext4
> crc16
> mbcache
> jbd2
> crc32c_generic
> fscrypto
> ecb
> ci_hdrc_imx
> ci_hdrc
> ehci_hcd
> sdhci_esdhc_imx
> usbcore
> sdhci_pltfm
> i2c_imx
> udc_core
> sdhci
> usb_common
> usbmisc_imx
> phy_mxs_usb
> anatop_regulator
> evdev
> 
> ** PCI devices:
> 
> ** USB devices:
> Bus 002 Device 002: ID 062a:0102 Creative Labs Wireless Keyboard/Mouse Combo 
> [MK1152WC]
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
> Architecture: armhf (armv7l)
> 
> Kernel: Linux 4.15.0-3-armmp (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages linux-image-4.15.0-3-armmp depends on:
> ii  initramfs-tools [linux-initramfs-tool]  0.130
> ii  kmod25-1
> ii  linux-base  4.5
> 
> Versions of packages linux-image-4.15.0-3-armmp recommends:
> pn  apparmor 
> ii  firmware-linux-free  3.4
> ii  irqbalance   1.3.0-0.1
> 
> Versions of packages linux-image-4.15.0-3-armmp suggests:
> pn  debian-kernel-handbook  
> pn  linux-doc-4.15  
> 
> Versions of packages linux-image-4.15.0-3-armmp is related to:
> ii  firmware-amd-graphics 20170823-1
> pn  firmware-atheros  
> pn  firmware-bnx2 
> pn  firmware-bnx2x
> ii  firmware-brcm8021120170823-1
> pn  firmware-cavium   
> pn  firmware-intel-sound  
> pn  firmware-intelwimax   
> pn  firmware-ipw2x00  
> pn  firmware-ivtv 
> pn  firmware-iwlwifi  
> pn  firmware-libertas 
> ii  firmware-linux-nonfree20170823-1
> ii  firmware-misc-nonfree 20170823-1
> pn  firmware-myricom  
> pn  firmware-netxen   
> pn  firmware-qlogic   
> pn  firmware-realtek  
> pn  firmware-samsung  
> pn  firmware-siano
> pn  firmware-ti-connectivity  
> pn  xen-hypervisor
> 
> -- no debconf information

Re: Debian kernel contributions

[Romain Perier]

2018-04-27 14:08 GMT+02:00 Moritz Muehlenhoff :
> Du schriebst in gmane.linux.debian.devel.kernel:
>> Hello,
>>
>> My name is Romain, I am an upstream linux contributor and I would like
>> to contribute on downstream projects like Debian. In my free time, I
>> love hacking (and beer too! but that's another business :p) . I would
>> want to focus on kernel development and perhaps a bit of kernel
>> packaging too.
>>
>> I have discussed with Vincent Bernat on IRC, he redirected me to this
>> ML. I am also on IRC (with the nick "rpr"), I am only connected to
>> #debian-kernel for now.
>>
>> I would glad to help, what would you recommend ?
>
> We have a huge backlog of open, old bug reports. One good way to
> get familiar with Debian maintenance is to go through old bugs,
> ping the reporters if those are still current (or even reproducible)
> and close useless reports.
>
> Eventually you'll find some bugs which are still unfixed in current
> kernels, so they could be forwarded to the attention of the relevant
> subsystem maintainers.
>
> You might also run into bugs fixed upstream which are not fixed in
> our stable release. If the patches fixing these bugs are abiding
> the stable kernel guidelines, consider forwarding them to stable@.
>
> If you notice any bugs suggesting changes to the kernel configs
> or if you see anything worth changing in our packaging, consider
> create a pull request on salsa.debian.org.
>
> Cheers,
> Moritz


Hello,

Okay, I will get familiar with Debian by browsing BTS and help to do
some triaging.
If I find interesting patches attached to a bug, or interesting
upstream patch, security patch or change to do in the package,
I will propose a merge request on Salsa. I will also ping the
reporters, according to the status of the bug.

Thanks for your feedback,
Regards,
Romain

Re: Debian kernel contributions

[Romain Perier]

Hello,

Thanks for your reply. Yeah, I have started to read this documentation
and the one about the "developer corner", already (not finished yet).
I have also started to look into existing bugs on
http://bugs.debian.org/src:linux, I have replied to my first bug (I
have realized that the form was wrong later, sorry for that)

I have started to look into https://wiki.debian.org/DebianKernel and
https://salsa.debian.org/kernel-team.

You mean an alioth group on https://alioth.debian.org ? Ok, I will
take a look thanks.

For now, I want to focus on kernel related stuffs :)

Do you have current topics where I could help ?

Thanks in advance,
Regards,
Romain

2018-04-26 10:08 GMT+02:00 Ozgur Kara <o...@zgur.org>:
>
>
> 25.04.2018, 00:21, "Romain Perier" <romain.per...@gmail.com>:
>> Hello,
>
> Hello Romain,
>
> you are welcome to the Debian country,  are you reading help debian? this 
> could be the first step:
>
> https://www.debian.org/intro/help
>
> I think you should check out the fixed security issue and debugging bugs and 
> be a member of a Alioth group.
>
> https://bugs.debian.org/
>
> Regards
>
> Ozgur
>
>> My name is Romain, I am an upstream linux contributor and I would like
>> to contribute on downstream projects like Debian. In my free time, I
>> love hacking (and beer too! but that's another business :p) . I would
>> want to focus on kernel development and perhaps a bit of kernel
>> packaging too.
>>
>> I have discussed with Vincent Bernat on IRC, he redirected me to this
>> ML. I am also on IRC (with the nick "rpr"), I am only connected to
>> #debian-kernel for now.
>>
>> I would glad to help, what would you recommend ?
>>
>> Thanks,
>> Romain

Bug#883294:

[Romain Perier]

Hello,

Could you :

- Retry with linux-image 4.15, that is the current kernel in buster/sid
- Instead of not using IO-APIC completly, could you try to boot with
kernel parameter "no_timer_check" ?

Does it help ?

Thanks,
Romain

Debian kernel contributions

[Romain Perier]

Hello,

My name is Romain, I am an upstream linux contributor and I would like
to contribute on downstream projects like Debian. In my free time, I
love hacking (and beer too! but that's another business :p) . I would
want to focus on kernel development and perhaps a bit of kernel
packaging too.


I have discussed with Vincent Bernat on IRC, he redirected me to this
ML. I am also on IRC (with the nick "rpr"), I am only connected to
#debian-kernel for now.

I would glad to help, what would you recommend ?

Thanks,
Romain