Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64

2023-02-19 Thread Diederik de Haas
On Monday, 20 February 2023 01:07:29 CET Samuel Thibault wrote:
> Diederik de Haas, le lun. 20 févr. 2023 00:38:28 +0100, a ecrit:
> > On Monday, 20 February 2023 00:27:57 CET Samuel Thibault wrote:
> > > Diederik de Haas, le lun. 20 févr. 2023 00:14:19 +0100, a ecrit:
> > > > On Tuesday, 14 February 2023 18:10:11 CET Samuel Thibault wrote:
> > > > > Some people on debian-accessibility wanted to install debian in
> > > > > arm64 under the utm wrapped qemu on Macos. The current installation
> > > > > images however do not include sound drivers and speakup.
> > > > 
> > > > Currently working on a MR to achieve that, but ...
> > > > 
> > > > > ... indeed, it seems these modules are getting built only for
> > > > > amd64, 686, mips, sh4.
> > > > 
> > > > ... this architecture list seems rather random? Why not also add it to
> > > > f.e. armhf, which itself is also a rather random
> > > > not-previously-enabled-arch?
> > > 
> > > I don't see why we shouldn't indeed. If some drivers didn't make sense
> > > on these archs they would rather be disabled by the arch configuration
> > > anyway. Speakup itself is portable and should be working on any arch,
> > > provided it has a virtual console.
> > > 
> > > The only historical reason I can see is that it was enabled only for
> > > architectures which have a gtk installer image (for which we consider
> > > that size doesn't matter).
> > 
> > On https://www.debian.org/devel/debian-installer/ I checked the links
> > under "other images (netboot, USB stick, etc.)" for the presence of a
> > "netboot/gtk/" folder and that turned out to be arm64 and armhf, so I'll
> > only add those.
> > 
> > If other arches should be added too, that can be done later.
> 
> I'm just thinking that probably people won't actually do it. That's what
> happened for arm64: see commit ea37896526075fb9d0f453ec537536149ea97d16
> which copied over the gtk configuration, but left speakup/sound
> commented, most probably just because the package was not available, and
> only now, 4 years later, we notice the missing feature.

As mentioned in my other reply, I submitted a MR for the kernel side here:
https://salsa.debian.org/kernel-team/linux/-/merge_requests/661

But it looks like something needs to be done on the d-i side as well.
But I'm not willing to do that. I'm not familiar with d-i's code/inner working 
and when comparing arm64.cfg with armhf.cfg in netboot/gtk folder I saw 
differences and I don't know why that is.

Diederik

signature.asc
Description: This is a digitally signed message part.


Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64

2023-02-19 Thread Samuel Thibault
Diederik de Haas, le lun. 20 févr. 2023 00:38:28 +0100, a ecrit:
> On Monday, 20 February 2023 00:27:57 CET Samuel Thibault wrote:
> > Diederik de Haas, le lun. 20 févr. 2023 00:14:19 +0100, a ecrit:
> > > On Tuesday, 14 February 2023 18:10:11 CET Samuel Thibault wrote:
> > > > Some people on debian-accessibility wanted to install debian in arm64
> > > > under the utm wrapped qemu on Macos. The current installation images
> > > > however do not include sound drivers and speakup.
> > > 
> > > Currently working on a MR to achieve that, but ...
> > > 
> > > > ... indeed, it seems these modules are getting built only for
> > > > amd64, 686, mips, sh4.
> > > 
> > > ... this architecture list seems rather random? Why not also add it to
> > > f.e.
> > > armhf, which itself is also a rather random not-previously-enabled-arch?
> > 
> > I don't see why we shouldn't indeed. If some drivers didn't make sense
> > on these archs they would rather be disabled by the arch configuration
> > anyway. Speakup itself is portable and should be working on any arch,
> > provided it has a virtual console.
> > 
> > The only historical reason I can see is that it was enabled only for
> > architectures which have a gtk installer image (for which we consider
> > that size doesn't matter).
> 
> On https://www.debian.org/devel/debian-installer/ I checked the links under
> "other images (netboot, USB stick, etc.)" for the presence of a 
> "netboot/gtk/" 
> folder and that turned out to be arm64 and armhf, so I'll only add those.
> 
> If other arches should be added too, that can be done later.

I'm just thinking that probably people won't actually do it. That's what
happened for arm64: see commit ea37896526075fb9d0f453ec537536149ea97d16
which copied over the gtk configuration, but left speakup/sound
commented, most probably just because the package was not available, and
only now, 4 years later, we notice the missing feature.

Samuel



Processed: Re: Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64

2023-02-19 Thread Debian Bug Tracking System
Processing control commands:

> tag -1 -moreinfo
Bug #1031289 [src:linux] linux: Missing sound drivers (and speakup) in d-i on 
arm64
Removed tag(s) moreinfo.

-- 
1031289: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031289
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64

2023-02-19 Thread Diederik de Haas
Control: tag -1 -moreinfo

On Monday, 20 February 2023 00:38:28 CET Diederik de Haas wrote:
> On Monday, 20 February 2023 00:27:57 CET Samuel Thibault wrote:
> > Diederik de Haas, le lun. 20 févr. 2023 00:14:19 +0100, a ecrit:
> > > On Tuesday, 14 February 2023 18:10:11 CET Samuel Thibault wrote:
> > > > Some people on debian-accessibility wanted to install debian in arm64
> > > > under the utm wrapped qemu on Macos. The current installation images
> > > > however do not include sound drivers and speakup.
> > > 
> > > Currently working on a MR to achieve that, but ...
> > > 
> > > > ... indeed, it seems these modules are getting built only for
> > > > amd64, 686, mips, sh4.
> > > 
> > > ... this architecture list seems rather random?
> 
> On https://www.debian.org/devel/debian-installer/ I checked the links under
> "other images (netboot, USB stick, etc.)" for the presence of a
> "netboot/gtk/" folder and that turned out to be arm64 and armhf, so I'll
> only add those.
> 
> If other arches should be added too, that can be done later.

https://salsa.debian.org/kernel-team/linux/-/merge_requests/661

signature.asc
Description: This is a digitally signed message part.


Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64

2023-02-19 Thread Diederik de Haas
On Monday, 20 February 2023 00:27:57 CET Samuel Thibault wrote:
> Diederik de Haas, le lun. 20 févr. 2023 00:14:19 +0100, a ecrit:
> > On Tuesday, 14 February 2023 18:10:11 CET Samuel Thibault wrote:
> > > Some people on debian-accessibility wanted to install debian in arm64
> > > under the utm wrapped qemu on Macos. The current installation images
> > > however do not include sound drivers and speakup.
> > 
> > Currently working on a MR to achieve that, but ...
> > 
> > > ... indeed, it seems these modules are getting built only for
> > > amd64, 686, mips, sh4.
> > 
> > ... this architecture list seems rather random? Why not also add it to
> > f.e.
> > armhf, which itself is also a rather random not-previously-enabled-arch?
> 
> I don't see why we shouldn't indeed. If some drivers didn't make sense
> on these archs they would rather be disabled by the arch configuration
> anyway. Speakup itself is portable and should be working on any arch,
> provided it has a virtual console.
> 
> The only historical reason I can see is that it was enabled only for
> architectures which have a gtk installer image (for which we consider
> that size doesn't matter).

On https://www.debian.org/devel/debian-installer/ I checked the links under
"other images (netboot, USB stick, etc.)" for the presence of a "netboot/gtk/" 
folder and that turned out to be arm64 and armhf, so I'll only add those.

If other arches should be added too, that can be done later.

Cheers,
  Diederik

signature.asc
Description: This is a digitally signed message part.


Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64

2023-02-19 Thread Samuel Thibault
Diederik de Haas, le lun. 20 févr. 2023 00:14:19 +0100, a ecrit:
> On Tuesday, 14 February 2023 18:10:11 CET Samuel Thibault wrote:
> > Some people on debian-accessibility wanted to install debian in arm64
> > under the utm wrapped qemu on Macos. The current installation images
> > however do not include sound drivers and speakup.
> 
> Currently working on a MR to achieve that, but ...
> 
> > ... indeed, it seems these modules are getting built only for
> > amd64, 686, mips, sh4.
> 
> ... this architecture list seems rather random? Why not also add it to f.e. 
> armhf, which itself is also a rather random not-previously-enabled-arch? 

I don't see why we shouldn't indeed. If some drivers didn't make sense
on these archs they would rather be disabled by the arch configuration
anyway. Speakup itself is portable and should be working on any arch,
provided it has a virtual console.

The only historical reason I can see is that it was enabled only for
architectures which have a gtk installer image (for which we consider
that size doesn't matter).

Samuel



Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64

2023-02-19 Thread Diederik de Haas
Control: tag -1 +moreinfo

On Tuesday, 14 February 2023 18:10:11 CET Samuel Thibault wrote:
> Some people on debian-accessibility wanted to install debian in arm64
> under the utm wrapped qemu on Macos. The current installation images
> however do not include sound drivers and speakup.

Currently working on a MR to achieve that, but ...

> ... indeed, it seems these modules are getting built only for
> amd64, 686, mips, sh4.

... this architecture list seems rather random? Why not also add it to f.e. 
armhf, which itself is also a rather random not-previously-enabled-arch? 

(Explicitly) CC-ing debian-boot as there may be other factors I'm not aware of 
and/or other considerations to be taken into account.

signature.asc
Description: This is a digitally signed message part.


Processed: Re: Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64

2023-02-19 Thread Debian Bug Tracking System
Processing control commands:

> tag -1 +moreinfo
Bug #1031289 [src:linux] linux: Missing sound drivers (and speakup) in d-i on 
arm64
Added tag(s) moreinfo.

-- 
1031289: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031289
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64

2023-02-19 Thread Samuel Thibault
Hello,

Samuel Thibault, le mar. 14 févr. 2023 22:02:34 +0100, a ecrit:
> Samuel Thibault, le mar. 14 févr. 2023 18:10:11 +0100, a ecrit:
> > E: Unable to locate package sound-modules-6.1.0-4-arm64-di
> > E: Unable to locate package speakup-modules-6.1.0-4-arm64-di
> > 
> > and indeed, it seems these modules are getting built only for amd64,
> > 686, mips, sh4.
> > 
> > Could we consider adding them on arm64 in the linux package?
> 
> Which boils down to:
> 
> cp debian/installer/modules/{i386,arm64}/speakup-modules
> cp debian/installer/modules/{i386,arm64}/sound-modules
> rm -f debian/control.md5sum
> ./debian/rules debian/control

Do you think this could be uploaded in time for bookworm?

Thanks,
Samuel



Bug#1019700: Info received (Fwd: Bug#1019700: mmc0: Timeout waiting for hardware cmd interrupt.)

2023-02-19 Thread Cyril Brulebois
Cyril Brulebois  (2023-02-19):
> FWIW bisecting this issue with a CM4 (and eMMC, no external storage) has
> been on my todo list for a long while… but results seem consistent with
> my (now) vague recollection: regression in the late 5.1X versions.

Sorry, that was with external storage, swapping the SD card again and
again, always starting with a fresh one to get consistent results. So
the sd_poll_once trick mentioned by Bjorn would be totally out of scope
here.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Bug#1019700: Info received (Fwd: Bug#1019700: mmc0: Timeout waiting for hardware cmd interrupt.)

2023-02-19 Thread Cyril Brulebois
Hi,

Hank Barta  (2022-09-22):
> I've gone through "git bisect" on the repo and results are at
> https://paste.debian.net/1254605/
> 
> Each candidate was tested with 6 reboots (including 3 that involved power
> cycling.)
> 
> There were four stages that did not build and at which I executed 'git
> bisect skip' to get a buildable candidate. They are listed in the paste
> linked above.
> 
> I have notes on the build errors if that would be useful.

FWIW bisecting this issue with a CM4 (and eMMC, no external storage) has
been on my todo list for a long while… but results seem consistent with
my (now) vague recollection: regression in the late 5.1X versions.

I was initially chasing down the PCIe regression and was also
encountering a black screen regression, so everything is a bit fuzzy,
sorry… A quick search returns these though:
  
https://lore.kernel.org/linux-arm-kernel/20220529011526.4lzuvkv5zclwn...@mraw.org/
  
https://lore.kernel.org/linux-arm-kernel/20220602191757.pqictbfarmvlf...@mraw.org/


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Bug#1031623: Memory leak on bullseye-backports kernel

2023-02-19 Thread bgme

Package: linux-image-amd64
Version: 6.0.12-1~bpo11+1

Dear Maintainer,

The bullseye-backports kernel seems to have memory leaks.

![Memory Basic 
1](https://img.bgme.bid/media_attachments/files/109/765/807/240/058/094/original/4797799a06a1f6a0.png)
![Memory Detai 
1](https://img.bgme.bid/media_attachments/files/109/765/733/452/620/356/original/ac80f53c417e8987.png)
![Memory Slab 
1](https://img.bgme.bid/media_attachments/files/109/765/600/897/375/029/original/fc19cd690d31b7c3.png) 



The memory usage graph during the worst memory leak.  But unfortunately, 
it was restarted directly at that time, and no log was kept.


![Memory Basic 
2](https://img.bgme.bid/media_attachments/files/109/891/489/647/006/108/original/56e5e856c9ce8105.png)
![Memory Detail 
2](https://img.bgme.bid/media_attachments/files/109/891/492/977/702/947/original/d8916e5ae7ae2347.png)
![Memory Slab 
2](https://img.bgme.bid/media_attachments/files/109/891/494/523/668/852/original/ca1f479a7c4e4483.png)


The memory usage graph recently.

-

Some informations:

# lsb_release -a
Distributor ID: Debian
Description:    Debian GNU/Linux 11 (bullseye)
Release:    11
Codename:   bullseye

# uname -a
Linux git 6.0.0-0.deb11.6-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0.12-1~bpo11+1 
(2022-12-19) x86_64 GNU/Linux

# free -h
   totalusedfree  shared  buff/cache   available
Mem:15Gi   6.6Gi   567Mi   1.0Gi   8.1Gi   7.3Gi
Swap:  8.0Gi   3.7Gi   4.3Gi

# smem -tw
Area   Used  Cache   Noncache
firmware/hardware 0  0  0
kernel image  0  0  0
kernel dynamic memory  1104746474994163548048
userspace memory465713613719723285164
free memory  298680 298680  0
--
   1600328091700686833212

# cat /proc/meminfo
MemTotal:   16003280 kB
MemFree:  292884 kB
MemAvailable:7623832 kB
Buffers:  20 kB
Cached:  8357004 kB
SwapCached:  1219960 kB
Active:  6195512 kB
Inactive:5855924 kB
Active(anon):2455580 kB
Inactive(anon):  2337516 kB
Active(file):3739932 kB
Inactive(file):  3518408 kB
Unevictable:   0 kB
Mlocked:   0 kB
SwapTotal:   8387580 kB
SwapFree:4534508 kB
Zswap:   1665924 kB
Zswapped:3608680 kB
Dirty:  6028 kB
Writeback:76 kB
AnonPages:   3414016 kB
Mapped:  1386444 kB
Shmem:   1098512 kB
KReclaimable: 408784 kB
Slab:1475632 kB
SReclaimable: 408784 kB
SUnreclaim:  1066848 kB
KernelStack:   20368 kB
PageTables:   385704 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit:16389220 kB
Committed_AS:   14574028 kB
VmallocTotal:   34359738367 kB
VmallocUsed:   62348 kB
VmallocChunk:  0 kB
Percpu: 5824 kB
HardwareCorrupted: 0 kB
AnonHugePages:208896 kB
ShmemHugePages:0 kB
ShmemPmdMapped:0 kB
FileHugePages: 0 kB
FilePmdMapped: 0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
Hugetlb:   0 kB
DirectMap4k:  182128 kB
DirectMap2M: 5715968 kB
DirectMap1G:10485760 kB

# slabtop -o
 Active / Total Objects (% used): 13245486 / 13988330 (94.7%)
 Active / Total Slabs (% used)  : 271375 / 271375 (100.0%)
 Active / Total Caches (% used) : 121 / 158 (76.6%)
 Active / Total Size (% used)   : 1274666.34K / 1441579.73K (88.4%)
 Minimum / Average / Maximum Object : 0.01K / 0.10K / 8.00K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
10730176 10696353  99%0.06K 167659   64670636K vmap_area
1151584 907533  78%0.14K  41128   28164512K btrfs_extent_map
452312 344597  76%0.57K  16154   28258464K radix_tree_node
261504  87883  33%0.03K   2043  128  8172K lsm_inode_cache
214500 210884  98%0.20K  10725   20 42900K vm_area_struct
158559 152049  95%0.08K   3109   51 12436K Acpi-State
145984 144333  98%0.06K   2281   64  9124K anon_vma_chain
134736  90425  67%0.19K   6416   21 25664K dentry
 82104  53847  65%1.17K   3280   27104960K btrfs_inode
 75348  68093  90%0.19K   3588   21 14352K kmalloc-192
 56901  56884  99%0.10K   1459   39  5836K anon_vma
 50660  49975  98%0.02K298  170  1192K lsm_file_cache
 50528  49997  98%0.25K   1579   32 12632K filp
 43329  37528  86%0.10K      39  K btrfs_free_space
 38336  38174  99%0.12K   1198   32  4792K kernfs_node_cache
 36416  24580  67%0.25K   1138   32  9104K