Bug#1049448: new kernel updating problem

[Gunnar Wolf]

Control: reassign 1049448 raspi-firmware
thanks

Hello Paul and slimshady,

I'm reassigning this bug to raspi-firmware, as it relates to an already known
issue; the fix has been uploaded already for several weeks in unstable+testing,
but I will now prepare an upload for stable as well.

I'll follow up with the diff and will open a corresponding bug on
release.debian.org as mentioned in [1].

Sorry for the much unintended noise. Thank you very much!

[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable


signature.asc
Description: PGP signature

Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files as it's not just used in RPi devices

[Gunnar Wolf]

Hi!

Diederik de Haas dijo [Tue, Jan 31, 2023 at 10:33:41PM +0100]:
> > Would they fit into a separate source package not associated with
> > raspi-config?
> 
> I do strongly think they do not belong in the raspi-firmware package for the 
> reason I retitled this bug and retitled my response Subject. Another reason 
> is 
> that the raspi-firmware package makes (several) assumptions, namely that they 
> are only used/usable on RPi devices and have a /boot/firmware directory 
> (where 
> a FAT partition is mounted, although that part is not checked for).
> I have previously expressed my concerns/doubts about that, but that's outside 
> the scope of this bug.
> It also looks 'weird' to install the raspi-firmware package while you only 
> care 
> about the wifi firmware and not care about RPi's at all.

Right, I agree this should be a package of its own. I didn't know
raspi-nonfree came from a "coherent" set of firmware sources provided
by a single upstream. It is a distorsion that peopleinterested in
brcmfmac firmware have to install raspi-firmware if they have
different hardware.

> > The other option is that they get included upstream in
> > linux-firmware.git by upstream?
> 
> Gunnar knows I'm not much of a fan of Raspberry Pi Foundation (RPF) and that 
> was confirmed once again by their typical reaction to this exact request. 
> 
> I'm too 'lazy' to look it up, so I'll paraphrase it:
> "It works for us (so fsck off). Can't you just use our files?"

I doubt we will find true RPF fans here 😉


signature.asc
Description: PGP signature

Bug#1021337: linux-image-5.19.0-2-amd64: Please enable building of the idxd module for the IntelData Accelerator support

[Gunnar Wolf]

Vincent Blut dijo [Thu, Oct 06, 2022 at 12:48:58PM +0200]:
> > > Specifically, the required configuration options to enable all of its
> > > features are:
> > >CONFIG_INTEL_IDXD=m
> > >CONFIG_INTEL_IDXD_SVM=y
> > 
> > Is this only applicable for the amd64 architecture or is it useful for 
> > others 
> > as well?
> 
> Since these depend on X86_64, only amd64 is concerned.

Right. And as I mentioned in the bug report,

The driver enables the Data Streaming Accelerator or DSA
capability for the 4th generation of the Intel Scalable Xeon
processor family, with code name Sapphire Rapids, and for future
Intel processors.

So, yes, it is relevant only for relatively recent x86_64 chips
produced by Intel (> 2019). For further details,

https://01.org/blogs/2019/introducing-intel-data-streaming-accelerator


signature.asc
Description: PGP signature

Bug#1021337: linux-image-5.19.0-2-amd64: Please enable building of the idxd module for the IntelData Accelerator support

[Gunnar Wolf]

Package: linux-image-5.19.0-2-amd64
Severity: normal
X-Debbugs-Cc: jair.de.jesus.gonzalez.plascen...@intel.com, 
miguel.bernal.ma...@intel.com

Hello,

I was recently approached by Intel engineers Jair de Jesús Gonzalez
Plascencia and Miguel Bernal Marín, both Cc:ed here. They asked me for
help to get the needed components for Intel Data Accelerator in
Debian.

A necessary first step towards achieving this is having the needed
module built as part of our kernels; this driver has been part of
Linux since 5.6. This report is to request you to add the module in
Debian. Quoting from their mail to me:

Specifically, the required configuration options to enable all of its
features are:

   CONFIG_INTEL_IDXD=m
   # Intel Data Accelerators support
   # found in Linux kernels: 5.6–5.19, 6.0-rc+HEAD

   CONFIG_INTEL_IDXD_SVM=y
   # Accelerator Shared Virtual Memory Support
   # found in Linux kernels: 5.11–5.19, 6.0-rc+HEAD

   Other required configuration options that are already present in the
   Debian Bullseye and Debian Bookworm kernels are:

   CONFIG_INTEL_IOMMU=y
   CONFIG_INTEL_IOMMU_SVM=y
   CONFIG_IRQ_REMAP=y
   CONFIG_PCI_ATS=y
   CONFIG_PCI_PRI=y
   CONFIG_PCI_PASID=y
   CONFIG_DMA_ENGINE=y

- What does it enable? / What is the use case?

The driver enables the Data Streaming Accelerator or DSA
capability for the 4th generation of the Intel Scalable Xeon
processor family, with code name Sapphire Rapids, and for future
Intel processors.

As stated in the DSA specification (which can be found at

https://software.intel.com/en-us/download/intel-data-streaming-accelerator-preliminary-architecture-specification):

The driver enables the Data Streaming Accelerator or DSA
capability for the 4th generation of the Intel Scalable Xeon
processor family, with code name Sapphire Rapids, and for future
Intel processors.

As stated in the DSA specification (which can be found at

https://software.intel.com/en-us/download/intel-data-streaming-accelerator-preliminary-architecture-specification
 ):

Intel DSA is a high-performance data copy and transformation
accelerator that will be integrated in future Intel® processors,
targeted for optimizing streaming data movement and transformation
operations common with applications for high-performance storage,
networking, persistent memory, and various data processing
applications.

Intel DSA replaces Intel® QuickData Technology, which is a part of
Intel® I/O Acceleration Technology.

This request comes as a requisite for the packaging of the userspace
components of this functionality (WNPP bug is to be fixed once I got a
bug number assigned for this report).

This functionality is available starting at Intel's fourth generation
of Scalable Xeon server processors, code-named Sapphire
Rapids. Currently some SPR products are planned to be launched on 2022
calendar week 42 and 2022 calendar week 45. High volume SPR processors
have a planned launch window on 2023 calendar week 6 to 9 (Feb. 6,
2023 to March 3, 2023).

Thank you very much!


   - Gunnar
 (but really, this should be signed by Miguel and Jair ;-) )

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 



signature.asc
Description: PGP signature

Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files for wifi support in Raspberry p400

[Gunnar Wolf]

Please note I'm currenlty shipping the required files in
raspi-firmware -- I believe their right place is in
firmware-brcm80211, so please just ping me (or better, raise a bug on
raspi-firmware) whent they are added to this package.

Thanks!

Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files for wifi support in Raspberry p400

[Gunnar Wolf]

Package: firmware-brcm80211
Version: 20210818-1
Severity: normal
Tags: newcomer

The Raspberry Pi p400 is very similar to the 4 family, but the Wifi
chip is a slightly different model, and is thus not recognized when
running with Debian, not even with firmware-brcm80211.

We need the addition of three files, all three of them available in
RPi-Distro's firmware-nonfree repository in Github
(https://github.com/RPi-Distro/firmware-nonfree/tree/master/brcm/):

brcmfmac43456-sdio.bin
brcmfmac43456-sdio.clm_blob
brcmfmac43456-sdio.txt

Thank you very much!

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

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

Bug#986863: linux: Serial terminal for RPi 4 and p400 corrupted during bootup

[Gunnar Wolf]

Control: Severity -1 normal

Ben Hutchings dijo [Fri, Apr 16, 2021 at 03:07:48PM +0200]:
> > During the boot process of the Raspberry Pi models 4 (4 and 8GB) and
> > p400, the console starts working correctly, but as the vc4 video gets
> > initialized, the console gets corrupted.
> [...]
> 
> This is a known problem with the RPi 3/4 hardware:
> 
> "In order to use the mini UART, you need to configure the Raspberry Pi
> to use a fixed VPU core clock frequency. This is because the mini UART
> clock is linked to the VPU core clock, so that when the core clock
> frequency changes, the UART baud rate will also change."
> 
> (from
> ).

Ugh, great... FSVO.

I can confirm both force_turbo=1 and core_freq=250 worked for keeping
the serial port functioning after vc4 is loaded, but am still unsure
which should be enabled by default for our RPi4 users (I'd set it in
the raspi-firmware package).

In any case, I'm downgrading this bug to Normal, as it has a known
workaround, but if you don't disagree, I'd still regard to it as an
existing, open bug.

Thanks!


signature.asc
Description: PGP signature

Bug#986863: linux: Serial terminal for RPi 4 and p400 corrupted during bootup

[Gunnar Wolf]

Control: notfound -1 5.9.15-1
Control: found -1 5.10.4-1

Marking two adjacent kernel versions where the breakage first appeared.

Bug#986863: linux: Serial terminal for RPi 4 and p400 corrupted during bootup

[Gunnar Wolf]

found 986863 5.10.0-6-arm64
notfound 986863 5.8.0-3-arm64
thanks

I blacklisted the vc4 module, and the console works reliably again, so
that's a way to get a working system. I will blacklist in the images I
produce, but this should not be needed for users to know!

I am also trying with a kernel from the 5.8 series, as noted in the
pseudo-headers to the BTS. The bug does not happen under kernel
5.8.0-3. I will try to more precisely pinpoint the place where it
stopped working.

Just to have as much information together -- If I boot without loading
the vc4 module, then load it via modprobe, I get the following
messages:

root@rpi4-20210226:~# modprobe vc4
[   71.824867] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi-0' 
already present!
[   71.835045] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[   71.869840] debugfs: Directory 'fef05700.hdmi' with parent 'vc4-hdmi-1' 
already present!
[   71.879230] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[   71.899628] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops [vc4])
[   71.906197] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
[   71.912815] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
[   71.920100] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
[   71.927301] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
[   71.934495] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
[   71.941850] fb0: switching to vc4drmfb from simple
[   71.947094] Console: switching to colour dummy device 80x25
[   71.974285] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
[   72.035497] Console: switching to colour frame buffer device 160x45
[   72.041942] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
root@rpi4-20210226:~# 

After which, the console becomes unoperative.

I tested this in the p400 as well, the behavior us the same.


signature.asc
Description: PGP signature

Bug#878332: linux > 4.11: Raspberry pi 2 hangs at boot with lpae kernel

[Gunnar Wolf]

Philip Rinn dijo [Thu, Sep 10, 2020 at 12:09:29PM +0200]:
> Hi Gunnar,
> 
> thanks for testing - but your message leaves me a little confused. You claim, 
> the
> bug is fixed but you say
> 
> > we have used only regular linux-image-armmp kernels (and have no
> > reason to suppose -lpae is needed).
> 
> So, my question, did you actually test with an "-lpae" kernel?

At the time of my bug report, I had not tested it yet. I checked right
now, downloading an image from raspi.debian.net, and installing the
-lpae kernel, I can confirm it boots correctly all the way to:

root@rpi2-20200910:~# uname -a
Linux rpi2-20200910 4.19.0-10-armmp-lpae #1 SMP Debian 4.19.132-1 
(2020-07-24) armv7l GNU/Linux

> While being technically correct that an "-lpae" kernel is not needed, the 
> kernel
> should still also work on an rpi2 _with_ an "-lpae" kernel.

OK, I'm happy to have understood this correctly :-)


signature.asc
Description: PGP signature

Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

[Gunnar Wolf]

fixed 820622 4.19.132-1
thanks

Hello,

I have not seen this message appear in my RPi2, using stock Debian
kernels starting at 4.19 (even a bit before that, I think). I do not
use the LPAE kernel, as I understand it does not make much sense in
the RPi2 (sold only with 1GB RAM, and not expandable), so probably
this specific kernel should be tested, but I believe the bug can be
now safely closed.


signature.asc
Description: PGP signature

Bug#941597: linux: [dtb] Raspberry Pi 3B+: does not shut down (regression against buster)

[Gunnar Wolf]

fixed 941597  5.7.17-1
thanks

I have some RPi3B+ using the arm64 Linuxkernel at version 5.7
(currently in testing), and they both shutdown and reboot reliably. I
believe this bug can now be closed.


signature.asc
Description: PGP signature

Bug#878332: linux > 4.11: Raspberry pi 2 hangs at boot with lpae kernel

[Gunnar Wolf]

fixed 878332 4.19.132-1
fixed 878332 5.7.17-1
thanks

Hello,

This bug is no longer present in kernels shipped in Debian stable /
testing / unstable. Do note, though, that the Raspberry Pi 2 is sold
with 1GB RAM only and cannot be upgraded, and thus has no use for
LPAE, we have used only regular linux-image-armmp kernels (and have no
reason to suppose -lpae is needed).


signature.asc
Description: PGP signature

Bug#917941: Installation Buster on HP 17-by Notebook

[Gunnar Wolf]

Hi,

Just adding some info to this bug, for whoever stumbles upon it - I
just got a new HP laptop (HP Pavillion X360, 14", specific model
14-cd0004la) with this same wifi chip. I was able to install and use
the (very not official, run at your own risk!) drivers available at
https://github.com/tomaspinho/rtl8821ce via DKMS. So far, so good (not
that it's been very far yet ;-) )

Other than this driver, the laptop works very well with a stock Debian
Buster 10.4.

Will submit a separate installation report, of course. Thanks!

Bug#904043: arm: Enable CONFIG_SPI_SPIDEV

[Gunnar Wolf]

Hi,

This bug is being added as several users (me included) have required
this information from the (unofficial) Raspberry Pi Debian "clean"
image.

There is a great number of devices with similar format, allowing for
GPIO communications, that would benefit from having SPIDEV enabled in
our mainline kernel. FWIW, my particular use case (for which I chose
to switch to Raspbian instead) was to flash ROM images.

Thanks for considering this bug as a harmless and easy-to-fulfill
wishlist request!


signature.asc
Description: PGP signature

Bug#694575: installation-reports: Fails to find SATA drives regardless of the FakeRAID card settings

[Gunnar Wolf]

Cyril Brulebois dijo [Tue, Dec 25, 2012 at 04:35:58PM +0100]:
> > Right, that seems to be the case — Sorry for submitting a duplicate;
> > merging. I hope this can be fixed before the release.
> 
> unless we reach a number of duplicates counted on 2 digits, I'm happy
> to have some of them. ;)
> 
> The kernel got fixed, and that one should be used for rc1 images, to
> be published soon.

Right - I have not (and cannot, as I'm 7000Km away from home) checked
if the current images fix this bug, but it is most likely it
does... So feel free to close this bug. Of course, as soon as I'm
back, I will check if it's now working.


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121225154255.gc94...@gwolf.org

Bug#567747: /etc/modprobe.d/i915-kms.conf: startx results in a black screen permanently turned off until reboot

[Gunnar Wolf]

As a temporary workaround, or in case this is of any value: Logging in
from a second computer to the affected one allows you to:

- /etc/init.d/gdm stop
- Launch X and kill it (Ctrl-C)
- /etc/init.d/gdm start

And this time it works properly. 

-- 
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100218225612.ga14...@localdomain