Re: Rust for Linux and host-only libraries

[Fabian Grünbichler]

On April 19, 2024 8:44:12 PM GMT+02:00, Miguel Ojeda 
 wrote:
>On Fri, Apr 19, 2024 at 8:13 PM Fabian Grünbichler
> wrote:
>>
>> Yes, all crates packaged by the Rust team (and most packaged for consumption 
>> by other packages/as build-deps by people outside of the team) ship their 
>> (patched for distro use) sources in a subdir there. The patches (except for 
>> wholesale exclusions of bundled C code and similar things, which is done via 
>> orig tarball repacking) are also shipped there, so the delta is easily 
>> reviewable. The whole directory structure can be used as (partial) drop-in 
>> for crates.io by configuring cargo accordingly (in Debian packaging this is 
>> done by a cargo wrapper shipped in /usr/share/cargo/bin/cargo, but that one 
>> is probably not suitable as-is for kernel stuff - it or rather its output 
>> might serve as an example for the needed cargo config runes though ;))
>
>Thanks for the quick reply!
>
>I see -- in principle, we only need the sources, i.e. we would not
>compile the crates using Cargo. Are the patches applied to the sources
>already, or are they applied by that cargo wrapper you mention at
>build time? (Well, assuming users should use the patched versions).

No, the patches are already applied in the source files shipped by 
librust-xxx-dev, if there are any. The cargo wrapper takes care of other 
things, like instructing cargo to use the packaged sources and setting 
rustflags and similar options. You should be able to use the same sources with 
manual rustc invocations without cargo or our wrapper just fine :) 

There's a bit of peculiarity around the versioning - the librust-.. packages 
provide all the semver prefixes of their version as well, so you can express "I 
want crate X in a semver compatible version of at least 2.3" via a versioned 
dependency (by depending on librust-x-2-dev with a version of at least 2.3), 
but also the more restricted variants (e.g., X in some 2.3.n version, or a 
specific 2.3.4 version, by depending on librust-2.3-dev resp. 
librust-2.3.4-dev). Normally, the actual package providing all of those is 
librust-X-dev, except when we need to package more than one version of X, then 
there might be a librust-X-dev in version A (providing all the semver prefixes 
of A), and another package librust-X-B-dev, where B is the shortest 
semver-breaking prefix of a semver incompatible version older than A (providing 
all semver prefixes of that version). A might be 2.3.4 and B 1 (with B's full 
version being 1.2.0, for example). Most of that won't be relevant for you - 
except that you want to depend on e.g. librust-syn-1-dev if you want syn 1.x, 
even if the actual "real" package is called librust-syn-dev, as the latter 
might also contain syn 0.x or 2.x in other distros/releases. Hope this was not 
too confusing ;)

Re: Rust for Linux and host-only libraries

[Fabian Grünbichler]

On April 19, 2024 7:09:15 PM GMT+02:00, Miguel Ojeda 
 wrote:
>Hi Ximin, Sylvestre, Fabian, all,
>
>In Rust for Linux, we are considering using host-only/userspace Rust
>libraries (e.g. `syn`), and we were asked to check whether it would be
>possible to just pick them from the distribution (since, in principle,
>they don't require kernel-specific changes).
>
>What is the policy in Debian for those? I was told about
>`debcargo-conf` by Zixing Liu, and indeed I can see e.g. `syn` there
>in `librust-syn-dev`, which places the sources at
>`/usr/share/cargo/registry/`, which is great for what we need. Is that
>correct? This would be useful for kernel developers that do not trust
>third-party repositories (not even Rust's/crates.io/the upstream
>repository).

Yes, all crates packaged by the Rust team (and most packaged for consumption by 
other packages/as build-deps by people outside of the team) ship their (patched 
for distro use) sources in a subdir there. The patches (except for wholesale 
exclusions of bundled C code and similar things, which is done via orig tarball 
repacking) are also shipped there, so the delta is easily reviewable. The whole 
directory structure can be used as (partial) drop-in for crates.io by 
configuring cargo accordingly (in Debian packaging this is done by a cargo 
wrapper shipped in /usr/share/cargo/bin/cargo, but that one is probably not 
suitable as-is for kernel stuff - it or rather its output might serve as an 
example for the needed cargo config runes though ;))

>By the way, is there a way to query where the sources are (i.e. that
>path) in a "standard" way (e.g. like `pkg-config`)? Or, at least, can
>we assume it should be stable? (e.g. for automated detection and/or
>instructions we may want to provide).

Not really - other than that directory being in the format the cargo expects 
for registry replacement, which is the same structure as `cargo vendor` 
creates. There is no index or .pc equivalent - the Cargo.toml file inside each 
crate has all the info and more in a standardized fashion after all :)

I don't except this to change anytime soon (basically - only if stable dynamic 
linking becomes feasible and we stop shipping the sources in binary packages 
altogether ;) or if cargo itself completely revamps how it supports vendoring). 
If we know people/projects outside of Debian packaging are using this, adding a 
comment in the tooling that currently decides those paths (and their 
contents/structure) so that we know we should discuss or at least give a heads 
up about any planned fundamental changes should be easy to do :)

Don't hesitate to reach out if you have further questions or go ahead with 
using the packaged crate sources! 

While there is considerable overlap w.r.t. subscribers, there is a second 
Debian rust list for discussions (debian-r...@lists.debian.org) - this one here 
gets all the automated notifications for all team maintained packages, so is 
rather high volume and things can get overlooked sometimes.

Bug#1035569: installation-reports: failed to detect Realtek RTL8852BE WiFi 6 802.11ax PCIe adapter

[fabian]

Hi guys,

Am 05.05.2023 18:09, schrieb Diederik de Haas:

Too recent for Bookworm as it appears that it was added in 6.2,
while Bookworm has 6.1.


today I tried again with a TP-Link TL-WN725N Nano USB dongle which 
contains the Realtek RTL8188EU chip set. Same result, the adapter is not 
recognized and I am presented with a list of kernel modules of which 
none works. But in this case, I am pretty sure that the RTL8188EU chip 
*should* be supported by a recent kernel.


Any hints, or should I file a separate installation report?

Cheers,

 - Fabian

Bug#1003210: Linux kernel module loading failing with "failed to validate module" error

[Fabian Grünbichler]

On Thu, Jan 06, 2022 at 10:18:23AM +, Ben Dooks wrote:
> Package: linux-image-5.15.0-2-amd64
> Version: 5.15.5-2
> 
> Dmesg output when mmc card is inserted:
> 
> 
> [137854.880467] mmc0: cannot verify signal voltage switch
> [137855.004774] mmc0: new ultra high speed SDR104 SDHC card at address 
> [137855.009414] BPF: type_id=6 bits_offset=416
> [137855.009418] BPF:
> [137855.009419] BPF:Invalid name
> [137855.009420] BPF:
> [137855.009422] failed to validate module [mmc_block] BTF: -22
> 
> # cat /etc/debian_version
> bookworm/sid

see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998716 for more
info.

the workaround: ensure the booted kernel and the on-disk kernel modules
are from the same build: either reboot (possibly needs to regenerate
initrd first) or downgrade the on-disk kernel to the booted version.

TL;DRL: Debian either needs to start bumping ABI for every upload, or
hard-disable generating split BTF info for kernel modules

Bug#998716: linux-image-5.14.0-2-amd64: The package size has grown a lot compared to 5.8/5.10 releases

[Fabian Grünbichler]

On Tue, Nov 30, 2021 at 08:18:56PM +0100, Ben Hutchings wrote:
> On Tue, 2021-11-30 at 11:01 +0100, Fabian Grünbichler wrote:
> [...]
> > possibly interesting in that context (I asked/posted the link in 
> > #debian-kernel a few days ago as well) - these BTF sections now actually 
> > reference the BTF info in the kernel image itself (as part of the 
> > deduplication of shared information), which makes the latter part of the 
> > ABI, and AFAICT this is not (yet?) tracked in Debian..
> > 
> > https://lore.kernel.org/all/1637926692.uyvrkty41j.astr...@nora.none/
> > 
> > an otherwise ABI compatible kernel upgrade thus has the potential to 
> > break module loading altogether, and I'd recommend disabling the split 
> > BTF feature for the time being unless you plan on bumping ABI for every 
> > kernel update anyway.
> 
> Yes, that is interesting/concerning.
> 
> If we continue to not bump the ABI number on every update, then I
> think:
> 
> 1. In-tree modules should not be loadable between an upgrade and a
> reboot.  (This can happen already for specific modules, due to symbol
> version changes that we think don't affect out-of-tree modules.) 
> Alternatively, they could still be loadable but then their BTF info
> should be completely discarded.
> 
> 2. Out-of-tree modules should be built without BTF deduplication, or
> without BTF info.
> 
> The main reason for not bumping the ABI number every time is to avoid
> forcing an unnecessary rebuild of out-of-tree modules.  We could try
> switching to something like RHEL's "weak-update" mechanism where ABI-
> compatible out-of-tree modules are automatically linked into a new
> version's modules directory without rebuilding them.  In that case we
> would still need to implement item (2) above.

FWIW, I ran into this issue for real on a Sid system:

booted kernel: Linux host 5.15.0-2-amd64 #1 SMP Debian 5.15.5-1 (2021-11-26) 
x86_64 GNU/Linux
installed kernel: ii  linux-image-5.15.0-2-amd64 5.15.5-2 amd64
Linux 5.15 for 64-bit PCs (signed)

attempting to (auto-)load any module not already loaded before the
upgrade:

Dec 26 17:18:48 host mtp-probe[319902]: checking bus 4, device 3: 
"/sys/devices/pci:00/:00:01.2/:02:00.0/:03:08.0/:05:00.3/usb4/4-4"
Dec 26 17:18:48 host mtp-probe[319902]: bus: 4, device: 3 was not an MTP device
Dec 26 17:18:49 host kernel: scsi 3:0:0:0: Direct-Access  
Multi-Reader  -0 1.00 PQ: 0 ANSI: 6
Dec 26 17:18:49 host kernel: scsi 3:0:0:1: Direct-Access  
Multi-Reader  -1 1.00 PQ: 0 ANSI: 6
Dec 26 17:18:49 host kernel: scsi 3:0:0:2: Direct-Access  
Multi-Reader  -2 1.00 PQ: 0 ANSI: 6
Dec 26 17:18:49 host kernel: scsi 3:0:0:3: Direct-Access  
Multi-Reader  -3 1.00 PQ: 0 ANSI: 6
Dec 26 17:18:49 host kernel: scsi 3:0:0:0: Attached scsi generic sg0 type 0
Dec 26 17:18:49 host kernel: scsi 3:0:0:1: Attached scsi generic sg1 type 0
Dec 26 17:18:49 host kernel: scsi 3:0:0:2: Attached scsi generic sg2 type 0
Dec 26 17:18:49 host kernel: scsi 3:0:0:3: Attached scsi generic sg3 type 0
Dec 26 17:18:49 host kernel: BPF:[86226] ENUM T_CONDITION_MET
Dec 26 17:18:49 host kernel: BPF:size=4 vlen=11
Dec 26 17:18:49 host kernel: BPF:
Dec 26 17:18:49 host kernel: BPF:Invalid name
Dec 26 17:18:49 host kernel: BPF:
Dec 26 17:18:49 host kernel: failed to validate module [sd_mod] BTF: -22

module loading fails until booted and on-disk kernel images match again
- either by downgrading the latter (to 5.15.5-1 in this case), or by
rebooting.

note that just disabling the relevant KConfig doesn't work in my
experience, since it will be automatically enabled again by the presence
of a split-BTF capable pahole version in the build environment. patching
the default value to 'n' does work though[0].

0: 
https://git.proxmox.com/?p=pve-kernel.git;a=commitdiff;h=bc1d1913898940cabcea142f75a2a4759790a503

Bug#934736: initramfs-tools: MODULES=dep fails when rootfs is zfs

[Fabian Ebner]

Package: initramfs-tools
Version: 0.140
Followup-For: Bug #934736

Dear Maintainer,

this issue is still present in version 0.140 of the package. I quickly
tested the patch from Aron Xu, which still seems to work.


-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 18M Dec  3 10:19 /boot/initrd.img-5.13.19-1-pve
-- /proc/cmdline
initrd=\EFI\proxmox\5.13.19-1-pve\initrd.img-5.13.19-1-pve 
root=ZFS=rpool/ROOT/pve-1 boot=zfs crashkernel=384M-:256M

-- /proc/filesystems
ext3
ext2
ext4
squashfs
vfat
fuseblk
btrfs

-- lsmod
Module  Size  Used by
ebtable_filter 16384  0
ebtables   36864  1 ebtable_filter
ip_set 53248  0
ip6table_raw   16384  0
iptable_raw16384  0
ip6table_filter16384  0
ip6_tables 32768  2 ip6table_filter,ip6table_raw
iptable_filter 16384  0
bpfilter   16384  0
softdog16384  2
bonding   176128  0
tls98304  1 bonding
nfnetlink_log  20480  1
nfnetlink  20480  3 ip_set,nfnetlink_log
intel_rapl_msr 20480  0
intel_rapl_common  24576  1 intel_rapl_msr
kvm_amd   122880  0
ccp94208  1 kvm_amd
kvm   868352  1 kvm_amd
irqbypass  16384  1 kvm
crct10dif_pclmul   16384  1
ghash_clmulni_intel16384  0
bochs_drm  16384  0
drm_vram_helper24576  1 bochs_drm
drm_ttm_helper 16384  1 drm_vram_helper
ttm69632  2 drm_vram_helper,drm_ttm_helper
drm_kms_helper258048  4 drm_vram_helper,bochs_drm
aesni_intel   376832  0
crypto_simd16384  1 aesni_intel
cec53248  1 drm_kms_helper
rc_core57344  1 cec
cryptd 24576  2 crypto_simd,ghash_clmulni_intel
fb_sys_fops16384  1 drm_kms_helper
syscopyarea16384  1 drm_kms_helper
sysfillrect16384  1 drm_kms_helper
pcspkr 16384  0
sysimgblt  16384  1 drm_kms_helper
joydev 28672  0
input_leds 16384  0
mac_hid16384  0
serio_raw  20480  0
efi_pstore 16384  0
qemu_fw_cfg20480  0
vhost_net  32768  0
vhost  53248  1 vhost_net
vhost_iotlb16384  1 vhost
tap24576  1 vhost_net
ib_iser40960  0
rdma_cm   118784  1 ib_iser
iw_cm  49152  1 rdma_cm
ib_cm 122880  1 rdma_cm
ib_core   360448  4 rdma_cm,iw_cm,ib_iser,ib_cm
iscsi_tcp  24576  0
libiscsi_tcp   32768  1 iscsi_tcp
libiscsi   65536  3 libiscsi_tcp,iscsi_tcp,ib_iser
scsi_transport_iscsi   131072  5 libiscsi_tcp,iscsi_tcp,ib_iser,libiscsi
drm   561152  6 
drm_kms_helper,drm_vram_helper,bochs_drm,drm_ttm_helper,ttm
sunrpc561152  1
ip_tables  32768  2 iptable_filter,iptable_raw
x_tables   49152  7 
ebtables,ip6table_filter,ip6table_raw,iptable_filter,ip6_tables,iptable_raw,ip_tables
autofs445056  2
zfs  3551232  10
zunicode  331776  1 zfs
zzstd 528384  1 zfs
zlua  151552  1 zfs
zavl   16384  1 zfs
icp   299008  1 zfs
zcommon98304  2 zfs,icp
znvpair   102400  2 zfs,zcommon
spl   106496  6 zfs,icp,zzstd,znvpair,zcommon,zavl
btrfs1400832  0
blake2b_generic20480  0
xor24576  1 btrfs
zstd_compress 176128  1 btrfs
hid_generic16384  0
usbhid 57344  0
hid   135168  2 usbhid,hid_generic
raid6_pq  114688  1 btrfs
libcrc32c  16384  1 btrfs
crc32_pclmul   16384  0
psmouse   159744  0
virtio_net 57344  0
net_failover   20480  1 virtio_net
failover   16384  1 net_failover
virtio_scsi24576  1
i2c_piix4  28672  0
uhci_hcd   53248  0
ehci_hcd   90112  0
pata_acpi  16384  0
floppy 86016  0

-- /etc/initramfs-tools/modules

-- /etc/initramfs-tools/initramfs.conf
MODULES=dep
BUSYBOX=auto
KEYMAP=n
COMPRESS=gzip
DEVICE=
NFSROOT=auto
RUNSIZE=10%
FSTYPE=auto

-- /etc/initramfs-tools/update-initramfs.conf
update_initramfs=yes
backup_initramfs=no

-- /proc/mdstat
Personalities : 
unused devices: 

-- /sys/block
loop0
loop1
loop2
loop3
loop4
loop5
loop6
loop7
sda
sr0

-- mkinitramfs hooks
/etc/initramfs-tools/hooks/:

/usr/share/initramfs-tools/hooks:
btrfs
dmsetup
fsck
fuse
iscsi
kdump-tools
keymap
klibc-utils
kmod
lvm2
resume
thermal
thin-provisioning-tools
udev
xfs
zdev
zfs
zfsunlock
zz-busybox


-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT

Bug#998716: linux-image-5.14.0-2-amd64: The package size has grown a lot compared to 5.8/5.10 releases

[Fabian Grünbichler]

On November 30, 2021 12:57 am, Ben Hutchings wrote:
> On Sun, 07 Nov 2021 03:52:13 +0200 Bohdan Horbeshko
>  wrote:
>> Package: linux-image-5.14.0-2-amd64
>> Severity: minor
>> 
>> Dear Maintainer,
>> 
>> the Installed-Size of the package has occasionally grown up to 375 MB,
>> which is about 30% larger than several minor releases before. A kindful
>> anonymous person has collected some more information here:
>> https://www.linux.org.ru/forum/general/16628666?cid=16628797 , and found
>> out that virtually every module has been grown in size. So this is
>> likely related to compilation options, rather than to some added modules
>> as I suspected before.
>> 
>> Please investigate the actual reason and report if this can/would be
>> fixed in further packages, thanks.
> [...]
> 
> The linked thread mentioned floppy.ko as an exmaple. Comparing the
> versions I have installed here:
> 
> ~$ ls -l /lib/modules/*/kernel/drivers/block/floppy.ko
> -rw-r--r-- 1 root root 182555 Aug  3 07:50 
> /lib/modules/5.10.0-8-amd64/kernel/drivers/block/floppy.ko
> -rw-r--r-- 1 root root 196947 Nov 26 06:33 
> /lib/modules/5.15.0-2-amd64/kernel/drivers/block/floppy.ko
> 
> there's about a 14 KiB increase from 5.10 to 5.15.
> 
> The code and static data sizes are roughly the same, actually slightly
> smaller:
> 
> ~$ size /lib/modules/*/kernel/drivers/block/floppy.ko
>text  data bss dec hex filename
>   64213  4893   14660   83766   14736 
> /lib/modules/5.10.0-8-amd64/kernel/drivers/block/floppy.ko
>   63619  4836   16516   84971   14beb 
> /lib/modules/5.15.0-2-amd64/kernel/drivers/block/floppy.ko
> 
> The bss can be ignored as it doesn't take up disk space.
> 
> Listing the sections with "objdump -h", I see a new section in 5.15:
> 
> Idx Name  Size  VMA   LMA   File off  Algn
> [...]
>  26 .BTF  2b58      00010c40  2**0
>   CONTENTS, READONLY
> 
> That's a size of about 11 KiB, so most of the increase.
> 
> After that I compared *all* the modules installed by these versions:
> 
> ~$ du --bytes --summ /lib/modules/5.10.0-8-amd64/kernel
> 294650546 /lib/modules/5.10.0-8-amd64/kernel
> ~$ du --bytes --summ /lib/modules/5.15.0-2-amd64/kernel
> 371262312 /lib/modules/5.15.0-2-amd64/kernel
> 
> About a 73 MiB increase.
> 
> I calculated the total size of .BTF sections:
> 
> $ find /lib/modules/5.15.0-2-amd64/ -name '*.ko' | xargs objdump -h -j .BTF | 
> awk 'BEGIN { total = 0 } $2 == ".BTF" { total = total + strtonum("0x" $3) } 
> END { print total }'
> objdump: Warning: Separate debug info file 
> /usr/lib/modules/5.15.0-2-amd64/kernel/sound/usb/usx2y/snd-usb-us122l.ko 
> found, but CRC does not match - ignoring
> objdump: Warning: Separate debug info file 
> /usr/lib/modules/5.15.0-2-amd64/kernel/drivers/leds/leds-gpio.ko found, but 
> CRC does not match - ignoring
> objdump: Warning: Separate debug info file 
> /usr/lib/modules/5.15.0-2-amd64/kernel/fs/nls/nls_cp862.ko found, but CRC 
> does not match - ignoring
> 61693267
> 
> About 59 MiB, so again most of the increase.
> 
> It appears that BTF in modules was enabled in Linux 5.11 by
> 

possibly interesting in that context (I asked/posted the link in 
#debian-kernel a few days ago as well) - these BTF sections now actually 
reference the BTF info in the kernel image itself (as part of the 
deduplication of shared information), which makes the latter part of the 
ABI, and AFAICT this is not (yet?) tracked in Debian..

https://lore.kernel.org/all/1637926692.uyvrkty41j.astr...@nora.none/

an otherwise ABI compatible kernel upgrade thus has the potential to 
break module loading altogether, and I'd recommend disabling the split 
BTF feature for the time being unless you plan on bumping ABI for every 
kernel update anyway.

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

[Fabian Pietsch]

Hi,


* Fabian Pietsch (Wed, 03 Apr 2019 12:30:01 +0200):
> As suggested, I tested more compact cmdline.txt, though:
> 
> | root=/dev/mmcblk0p2
> 
> | console=tty0 root=/dev/mmcblk0p2
> 
> | console=tty0 root=/dev/mmcblk0p2 cma=128M
> 
> With the first two, cma defaulted to 64M and already the lightdm login
> screen stops updating after a few seconds to minutes. With the 3rd,
> the bug initially didn't happen so I used X a bit, then logged out and
> let the system fall idle; the bug then seems to have happened
> 9868 seconds after boot (according to dmesg --follow).

Another round (system mostly idle except for manually renaming enx[...]
to eth0 after boot and restarting wicd, which came with lxde meta-package
to manage the networking, to get a correct system time via NTP)  ->
3960 seconds after boot (in dmesg). That seems to suggest to me that
the cmdline.txt built by raspi3-firmware was not the issue, here.
Still don't know whether it's possible or sensible to disable the
"weird" initial cmdline passed by the firmware, though.

In any case, the tile binning error ...

| kernel: vc4_v3d 3fc0.v3d: Failed to allocate memory for tile binning: 
-12. You may need to enable CMA or give it more memory.

... together with a preceding, e.g., ...

| kernel: [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
| kernel: [drm]V3D:  23468kb BOs (10)
| kernel: [drm] V3D shader:144kb BOs (35)
| kernel: [drm]   dumb:   8148kb BOs (4)

... is usually surrounded (in journal) by nothing but many:

| kernel: alloc_contig_range: [36400, 37500) PFNs busy

What I'm trying to say is that there seems to be no log-noticeable
concurrent activity going on.  Watching the CMA use via /proc/meminfo
suggests that it's much more than half free, most of the time.
The tile binning error seems to be entirely random, at this point.


Looking at the source[1], vc4_allocate_bin_bo() seems to use a strategy
of successively allocating memory until it randomly finds a block that
fits certain requirements. Maybe randomly sometimes there is no such
block available, leading to it failing with -ENOMEM. It's not clear
to me, though, when and why the function is called, seemingly randomly
on an idle system. It reads to me as an initialization, not something
that is randomly repeated. (?)

[1] 
https://sources.debian.org/src/linux/4.19.28-2/drivers/gpu/drm/vc4/vc4_v3d.c/#L244


Again, it would be nice if the resulting device error state could
somehow be reset / the function retried with more/different CMA free
at a later point during the same boot. Perhaps that's already possible
(maybe even in a general way?) but I don't know how.

(Trying to unbind the driver (vc4_v3d) via sysfs led to a kernel oops
(IIRC paging fault?), and an attempt to bind it again was rejected
without any noticeable action.)


Regards, Fabian

-- 
Fabian "canvon" Pietsch - https://www.canvon.de/

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

[Fabian Pietsch]

Hi,

* Romain Perier (Wed, 27 Mar 2019 21:33:19 +0100):
> Return-Path: 
> Message-ID: <20190327203319.ga15...@debby.home>
> From: Romain Perier 
> Subject: Re: Bug#925334: vc4: CMA fills up and screen not updated anymore
>  on raspi3
> To: Fabian Pietsch , 925...@bugs.debian.org
> User-Agent: Mutt/1.10.1 (2018-07-13)
> 
> On Wed, Mar 27, 2019 at 03:29:21PM +0100, Fabian Pietsch wrote:

[...]

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

[...]

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

[...]

> 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) ?

Didn't find anything useful to that regard in linux-doc Documentation/
and by googling. Could you please tell me how?

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

The initial part until the two spaces seems to be auto-generated by the
firmware at boot, so I guess I can't change or suppress it; if it should
be possible, again, please tell me how.

My kernel cmdline as passed *to* the firmware is:

| fabian@rpi3:~$ cat /boot/firmware/cmdline.txt
| console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw elevator=deadline 
fsck.repair=yes net.ifnames=0 cma=128M rootwait

This is just auto-generated by the raspi3-firmware package to which
you (Romain Perier) seem to be contributing.

As suggested, I tested more compact cmdline.txt, though:

| root=/dev/mmcblk0p2

| console=tty0 root=/dev/mmcblk0p2

| console=tty0 root=/dev/mmcblk0p2 cma=128M

With the first two, cma defaulted to 64M and already the lightdm login
screen stops updating after a few seconds to minutes. With the 3rd,
the bug initially didn't happen so I used X a bit, then logged out and
let the system fall idle; the bug then seems to have happened
9868 seconds after boot (according to dmesg --follow).

Regards, Fabian

-- 
Fabian "canvon" Pietsch - https://www.canvon.de/

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

[Fabian Pietsch]

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

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

[Fabian Pietsch]

Package: src:linux
Version: 4.19.16-1
Severity: important
Tags: upstream

Dear Maintainer,

(please also see the additional information in the footnotes below.)

When using the vc4 video driver with Xorg on the Raspberry Pi 3 [raspi3],
it seems to sooner or later fill up the CMA, leading to, e.g., this:

[  739.307920] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[  739.314932] [drm]V3D:  23468kb BOs (10)
[  739.321333] [drm] V3D shader:144kb BOs (35)
[  739.327734] [drm]   dumb:   8148kb BOs (4)

When additionally the following happens, the screen stops updating
until reboot [stops_updating]:

[  739.334049] vc4_v3d 3fc0.v3d: Failed to allocate memory for tile 
binning: -12. You may need to enable CMA or give it more memory.

This happens with cma=64M, cma=128M and cma=256M, though 128M seems to
be the recommended size for vc4 use, according to comments in
package raspi3-firmware's /etc/default/raspi3-firmware.

ii  raspi3-firmware 1.20190215-1 arm64Raspberry Pi 2 and 3 GPU firmware 
and bootloaders

With cma=128M, the error happens on a freshly booted, idle system
running lightdm, after perhaps 10m-30m, or can be provoked by
running a [screensaver].

A work-around is to force Xorg to use driver fbdev, which seems to work
even after the tile binning error which otherwise would have required
a reboot.


I also get a lot of, e.g.:

[  739.135918] alloc_contig_range: [37400, 38400) PFNs busy

I don't know if this is related or a different problem.


Please somehow make it possible (or even automatic) for the screen
update to continue without the need for a reboot. Fixes to CMA handling
so that the tile binning error doesn't even happen anymore would be
even better!

Regards, Fabian

(Please also see the footnotes below.)


[raspi3]
This machine was set up based on a Raspberry Pi 3 Debian buster preview
image, from https://wiki.debian.org/RaspberryPi3 ; it says
unofficial/unsupported, there, I hope this bug report still is ok
as, as far as I understand, the unmodified Debian buster arm64 kernel
seems to be used[1].

[1] Pulled in via apt from official mirror in sources.list:
https://github.com/Debian/raspi3-image-spec/blob/master/raspi3.yaml#L72


[stops_updating] "Stops updating the screen" here means that the
Xorg tty graphical contents don't change anymore, except for the
mouse cursor. The mouse cursor can still be moved around, and even
changes form on, e.g., window borders, and I can resize the terminal
window up one line, and the cursor change on mouseover reflects
the change; just nothing changes to the non-mousecursor visual picture.

Also, tasking into console works fine, and tasking back into the Xorg
tty restores the previous visual picture, and tasking back into the
console again is also still possible. So no real "freeze" or hard crash,
here, except that, after the tile binning error in dmesg, the Xorg
tty graphical contents don't change (except for mouse cursor).


[screensaver] The error can be provoked by running the following
for some time:

  /usr/lib/xscreensaver/tessellimage -root -fill-screen

This leads to a slightly different pattern of dmesg messages, though.
The thing in common is that the screen stops updating, there, too,
when the tile binning error quoted above happens.

When provoked in this way, "grep ^CmaFree: /proc/meminfo" in a loop
said 25564 kB directly before a tile binning error message, 7160 kB
directly after, with values between 8000-1 kB after, with
recovery to 81740 kB after exiting tessellimage. But the screen update
stays stopped.


Additional dmesg output:

[0.00] Booting Linux on physical CPU 0x00 [0x410fd034]
[0.00] Linux version 4.19.0-2-arm64 (debian-kernel@lists.debian.org) 
(gcc version 8.2.0 (Debian 8.2.0-14)) #1 SMP Debian 4.19.16-1 (2019-01-17)
[0.00] Machine model: Raspberry Pi 3 Model B Rev 1.2
[...]
[0.00] cma: Reserved 128 MiB at 0x3340
[...]
[0.00] Memory: 780176K/970752K available (8700K kernel code, 1600K 
rwdata, 2788K rodata, 4864K init, 530K bss, 59504K reserved, 131072K 
cma-reserved)
[...]
[0.000193] Console: colour dummy device 80x25
[0.000682] console [tty0] enabled
[...]
[0.141070] simple-framebuffer 3e887000.framebuffer: framebuffer at 
0x3e887000, 0x373800 bytes, mapped to 0x(ptrval)
[0.141106] simple-framebuffer 3e887000.framebuffer: format=r5g6b5, 
mode=1824x984x16, linelength=3648
[0.162242] Console: switching to colour frame buffer device 228x61
[0.182688] simple-framebuffer 3e887000.framebuffer: fb0: simplefb 
registered!
[...]
[4.768075] raspberrypi-firmware soc:firmware: Attached to firmware from 
2019-02-12 19:42
[...]
[   11.863850] vc4_hdmi 3f902000.hdmi: ASoC: Failed to create component debugfs 
directory
[   11.921037] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-&g

Re: Debian Kernel info

[Fabian Grünbichler]

On Wed, Sep 05, 2018 at 05:34:15PM +0200, Martin Steigerwald wrote:
> Fabian Grünbichler - 05.09.18, 17:19:
> > On Wed, Sep 05, 2018 at 02:33:33PM +0200, Martin Steigerwald wrote:
> > > Tomas Bortoli - 05.09.18, 08:48:
> > > > is there a place where I find the config used to compile Linux for
> > > > the latest Debian ?
> > > > 
> > > > 
> > > > The alternative idea I had is to `apt source linux-image-version`
> > > > but
> > > > that requires to download the whole package.
> > > 
> > > Probably via
> > > 
> > > https://sources.debian.org/src/linux/4.17.17-1/debian/config/amd64/
> > > 
> > > or something like that?
> > 
> > linux-image-$(uname -r) ships /boot/config-$(uname -r), which AFAIK is
> > the actual config used to compile that kernel image.
> 
> Sure, I know that. And yes, it appears the source package puts the 
> config together from various sources. But that was the closest 
> approximation I came up with so far.
> 
> I am not sure whether there is something similar than sources.debian.org 
> for binary packages. I thought there was, but currently I have no idea 
> where that might be.

Not that I know of - but it's just a {wget,curl} followed by dpkg
--fsys-tarfile | tar [...] of the binary package away, since both the
package and path are known ;)

Re: Debian Kernel info

[Fabian Grünbichler]

On Wed, Sep 05, 2018 at 02:33:33PM +0200, Martin Steigerwald wrote:
> Hi Tomas.
> 
> Tomas Bortoli - 05.09.18, 08:48:
> > is there a place where I find the config used to compile Linux for the
> > latest Debian ?
> > 
> > 
> > The alternative idea I had is to `apt source linux-image-version` but
> > that requires to download the whole package.
> 
> Probably via
> 
> https://sources.debian.org/src/linux/4.17.17-1/debian/config/amd64/
> 
> or something like that?

linux-image-$(uname -r) ships /boot/config-$(uname -r), which AFAIK is
the actual config used to compile that kernel image.

Bug#902661: linux-image-4.16.0-2-amd64: kernel BUG at /build/linux-uwVqDp/linux-4.16.16/mm/usercopy.c:100!

[Fabian]

Package: src:linux
Version: 4.16.16-2
Severity: important

Dear Maintainer,

starting X via 'startx' causes every screen to stay black, no more
interaction with mouse or keyboards is possible. So I connected via ssh
and tried to execute 'systemctl reboot'. Only the ssh connection was
closed but the system stayed running without any interaction.
After a reboot I looked again via ssh what dmesg prints out.
It said "usercopy: Kernel memory exposure attempt detected from SLUB
object 'nvidia_stack_cache' (offset: 11440, size 3)!", followed by the
message mentioned in the subject.
Therefore the system is not usable with X in this configuration.

nvidia-driver is in version 390.67-1

-- Package-specific info:
** Version:
Linux version 4.16.0-2-amd64 (debian-kernel@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-23)) #1 SMP Debian 4.16.16-2 (2018-06-22)

** Command line:
BOOT_IMAGE=/vmlinuz-4.16.0-2-amd64 root=/dev/mapper/loki-root ro 
cgroup_enable=memory swapaccount=1 quiet

** Tainted: PDO (4225)
 * Proprietary module has been loaded.
 * Kernel has oopsed before.
 * Out-of-tree module has been loaded.

** Kernel log:
[  116.932901]  ? _nv028088rm+0x55/0x90 [nvidia]
[  116.933048]  ? _nv013695rm+0xee/0x100 [nvidia]
[  116.933195]  ? _nv015343rm+0x154/0x270 [nvidia]
[  116.933350]  ? _nv008317rm+0x134/0x1a0 [nvidia]
[  116.933505]  ? _nv008296rm+0x29c/0x2b0 [nvidia]
[  116.933661]  ? _nv001072rm+0xe/0x20 [nvidia]
[  116.933818]  ? _nv007324rm+0xd8/0x100 [nvidia]
[  116.933962]  ? _nv001171rm+0x627/0x830 [nvidia]
[  116.934106]  ? rm_ioctl+0x73/0x100 [nvidia]
[  116.934240]  ? nvidia_ioctl+0xb0/0x730 [nvidia]
[  116.934370]  ? nvidia_ioctl+0x57c/0x730 [nvidia]
[  116.934371]  ? kmem_cache_free+0x19c/0x1d0
[  116.934501]  ? nvidia_frontend_unlocked_ioctl+0x3e/0x50 [nvidia]
[  116.934502]  ? do_vfs_ioctl+0xa4/0x630
[  116.934504]  ? __fput+0x164/0x1e0
[  116.934505]  ? SyS_ioctl+0x74/0x80
[  116.934507]  ? do_syscall_64+0x6c/0x130
[  116.934508]  ? entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[  116.934509] Code: 2e 00 00 44 8d 42 01 88 50 01 48 8b 05 4a 2e 00 00 8a 48 
02 48 8b 05 40 2e 00 00 41 0b c8 88 48 02 48 8b 05 33 2e 00 00 8a 48 02 <41> 84 
c8 74 0e 66 41 03 d0 b8 ff ff 00 00 66 3b d0 72 e3 f3 c3 
[  126.968483] INFO: NMI handler (nmi_cpu_backtrace_handler) took too long to 
run: 2.416 msecs
[  126.970325] general protection fault:  [#2] SMP NOPTI
[  126.970328] Modules linked in: ctr ccm ipt_MASQUERADE nf_nat_masquerade_ipv4 
nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype xt_conntrack nf_nat 
nf_conntrack br_netfilter bridge stp llc overlay aufs(O) ebtable_filter 
ebtables devlink ip6table_filter ip6_tables iptable_filter pci_stub vboxpci(O) 
vboxnetadp(O) vboxnetflt(O) vboxdrv(O) tun arc4 snd_hda_codec_hdmi nls_ascii 
rt2800usb nls_cp437 rt2x00usb vfat rt2800lib fat rt2x00lib eeepc_wmi asus_wmi 
sparse_keymap mac80211 snd_hda_codec_realtek video mxm_wmi wmi_bmof efi_pstore 
snd_hda_codec_generic cfg80211 edac_mce_amd kvm_amd ccp crc_ccitt rng_core 
evdev rfkill snd_hda_intel joydev kvm snd_hda_codec irqbypass serio_raw efivars 
fam15h_power sg snd_hda_core snd_hwdep snd_pcm snd_timer
[  126.970372]  snd wmi soundcore button shpchp sp5100_tco k10temp 
nvidia_drm(PO) drm_kms_helper drm nvidia_modeset(PO) nvidia(PO) ipmi_devintf 
ipmi_msghandler it87 hwmon_vid loop parport_pc ppdev lp parport efivarfs 
ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 fscrypto ecb algif_skcipher 
af_alg uas usb_storage dm_crypt dm_mod sr_mod cdrom raid10 raid456 
async_raid6_recov async_memcpy async_pq async_xor async_tx xor hid_holtek_mouse 
hid_generic usbhid hid sd_mod raid6_pq libcrc32c crc32c_generic raid1 raid0 
multipath linear md_mod ohci_pci crct10dif_pclmul crc32_pclmul crc32c_intel 
ghash_clmulni_intel pcbc ahci aesni_intel aes_x86_64 libahci crypto_simd 
glue_helper xhci_pci cryptd ohci_hcd ehci_pci libata xhci_hcd ehci_hcd 
i2c_piix4 usbcore e1000e usb_common scsi_mod
[  126.970449] CPU: 7 PID: 2270 Comm: Xorg Tainted: P  DO 
4.16.0-2-amd64 #1 Debian 4.16.16-2
[  126.970450] Hardware name: To be filled by O.E.M. To be filled by 
O.E.M./Crosshair V Formula, BIOS 1703 10/17/2012
[  126.970854] RIP: 0010:_nv007222rm+0x25/0x90 [nvidia]
[  126.970856] RSP: 0018:a199c4017d20 EFLAGS: 00010006
[  126.970858] RAX: 48e28944ff36 RBX: c14f82b8 RCX: a199c4017db0
[  126.970859] RDX: c089a515 RSI: 08de RDI: c14f82b8
[  126.970860] RBP: 8caf4d202ff8 R08:  R09: a199c4017dac
[  126.970861] R10:  R11: ff00 R12: 08de
[  126.970862] R13: 8caf4d855000 R14: 8caf87ec0f00 R15: 8caf85ef7000
[  126.970864] FS:  7f827a97f6c0() GS:8caf9edc() 
knlGS:
[  126.970866] CS:  0010 DS:  ES:  CR0: 80050033
[  126.970867] CR2: 7f4a27c12900 CR3: 0003af20a000 CR4: 000406e0
[

Bug#880655: SMB mount/umount between 2 docker containers causes kernel Oops

[Fabian Holler]

On Sun, Nov 05, 2017 at 12:01:11AM +, Ben Hutchings wrote:
> Control: reassign -1 src:linux 4.9.51-1
> 
> On Fri, 2017-11-03 at 12:08 +0100, Fabian Holler wrote:
> > Package: linux-image-4.9.0-4-amd64
> > Version: 4.9.51-1
> > 
> > Running Samba in one docker container and mounting/umounting a SMB share of 
> > it
> > in a second docker container causes a kernel Oops.
> > The machine did not crash with linux-image-4.9.0-4-amd64=4.9.51-1.
> 
> That's the same version you're reporting as failing.  Which version is
> working?

Yes, the Oops happens with linux-image-4.9.0-4-amd64=4.9.51-1.
I meant the Oops happened with that kernel but after the Oops the machine
continued to run.

I tried it again again and the machine crashed on the 2. try.

Bug#880655: SMB mount/umount between 2 docker containers causes kernel Oops

[Fabian Holler]

Package: linux-image-4.9.0-4-amd64
Version: 4.9.51-1

Running Samba in one docker container and mounting/umounting a SMB share of it
in a second docker container causes a kernel Oops.
The machine did not crash with linux-image-4.9.0-4-amd64=4.9.51-1.

The bug can be reproduced by https://github.com/fho/docker-samba-loop.

I was also able to reproduce a kernel Oops with the docker-samba-loop scripts
in multiple Ubuntu kernels (incl. machine crashes).
The trace looks different on linux-image-4.9.0-4-amd64. It might be a
different issue.
Ubuntu bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1729637
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407 might be related,
it's about the "unregister_netdevice: waiting for lo to become free."
messages.

The kernel log is attached.
[ 1085.345239] unregister_netdevice: waiting for lo to become free. Usage count 
= 1
[ 1095.425242] unregister_netdevice: waiting for lo to become free. Usage count 
= 1
[ 1105.505246] unregister_netdevice: waiting for lo to become free. Usage count 
= 1
[ 1115.585269] unregister_netdevice: waiting for lo to become free. Usage count 
= 1
[ 1124.835985] docker0: port 2(veth966a0a1) entered disabled state
[ 1124.846673] device veth966a0a1 left promiscuous mode
[ 1124.852945] docker0: port 2(veth966a0a1) entered disabled state
[ 1124.893454] BUG: unable to handle kernel paging request at fee0
[ 1124.900946] IP: [] sk_filter_uncharge+0x5/0x40
[ 1124.907177] PGD 12995b067 
[ 1124.909816] PUD 0 
[ 1124.913539] Oops:  [#1] SMP
[ 1124.916816] Modules linked in: nls_utf8 cifs sha256_ssse3 cmac md4 
des_generic arc4 dns_resolver fscache xt_nat xt_tcpudp veth ipt_MASQUERADE 
nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo 
iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype 
iptable_filter xt_conntrack nf_nat nf_conntrack br_netfilter bridge stp llc 
overlay sb_edac edac_core crct10dif_pclmul crc32_pclmul ppdev 
ghash_clmulni_intel intel_rapl_perf sg evdev parport_pc pvpanic parport 
serio_raw button ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_generic 
fscrypto ecb mbcache sd_mod crc32c_intel virtio_scsi scsi_mod virtio_net 
aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd psmouse 
virtio_pci virtio_ring virtio i2c_piix4
[ 1124.991747] CPU: 0 PID: 10546 Comm: dockerd Not tainted 4.9.0-4-amd64 #1 
Debian 4.9.51-1
[ 1124.44] Hardware name: Google Google Compute Engine/Google Compute 
Engine, BIOS Google 01/01/2011
[ 1125.009273] task: 899b769f2040 task.stack: a8ed0101
[ 1125.015302] RIP: 0010:[]  [] 
sk_filter_uncharge+0x5/0x40
[ 1125.023967] RSP: 0018:a8ed01013de8  EFLAGS: 00010202
[ 1125.029386] RAX:  RBX: 899c67741aa8 RCX: 0006
[ 1125.036631] RDX:  RSI: fec8 RDI: 899c67741800
[ 1125.043941] RBP: 899c67741800 R08:  R09: 
[ 1125.051181] R10: 899c676b6810 R11: 899b769f2040 R12: 899c677418a8
[ 1125.058436] R13: 0001 R14: 899c67741880 R15: 899c6a80d400
[ 1125.065679] FS:  7fe5aa0c1700() GS:899c6fc0() 
knlGS:
[ 1125.073880] CS:  0010 DS:  ES:  CR0: 80050033
[ 1125.079740] CR2: fee0 CR3: 000126d0e000 CR4: 000406f0
[ 1125.086980] DR0:  DR1:  DR2: 
[ 1125.094232] DR3:  DR6: fffe0ff0 DR7: 0400
[ 1125.101472] Stack:
[ 1125.103589]  8eae9555 899c67741800 a8ed01013e60 
899c677418a8
[ 1125.111545]  8eba849a 899c6a80d740 899c677418a8 
899c66ece6e0
[ 1125.119778]  899beaaaee40 6cd836548a884acd 899c4c955040 
899c4c955070
[ 1125.127787] Call Trace:
[ 1125.130353]  [] ? __sk_destruct+0x35/0x190
[ 1125.136126]  [] ? unix_release_sock+0x1ea/0x2d0
[ 1125.142329]  [] ? unix_release+0x19/0x30
[ 1125.147933]  [] ? sock_release+0x1a/0x70
[ 1125.153523]  [] ? sock_close+0xe/0x20
[ 1125.158868]  [] ? __fput+0xd5/0x220
[ 1125.164030]  [] ? task_work_run+0x79/0xa0
[ 1125.169719]  [] ? exit_to_usermode_loop+0xa4/0xb0
[ 1125.176095]  [] ? syscall_return_slowpath+0x54/0x60
[ 1125.182650]  [] ? system_call_fast_compare_end+0x99/0x9b
[ 1125.189633] Code: ea ff ff ff c3 4c 89 e7 e8 49 d2 c3 ff 48 c7 c0 f4 ff ff 
ff e9 49 ff ff ff 48 c7 c0 f4 ff ff ff e9 3d ff ff ff 90 66 66 66 66 90 <48> 8b 
46 18 8b 40 04 48 8d 04 c5 28 00 00 00 3e 29 87 24 01 00 
[ 1125.216264] RIP  [] sk_filter_uncharge+0x5/0x40
[ 1125.222598]  RSP 
[ 1125.226200] CR2: fee0
[ 1125.230140] ---[ end trace 25825482a4e502a0 ]---

Bug#872765: [Solved] Problem solved in 4.14.0-rc3-amd64

[Ricardo Fabian Peliquero]

Dear Maintainer,

Just to let you know that the problem is solved in 4.13.4-1. According to 
changelog:

   * ALSA: Enable SND_OSSEMUL, a new dependency of SND_{MIXER,PCM}_OSS

Thank you _very_ much!

Ricardo

Bug#872765: linux-image-4.13.0-trunk-amd64: further information

[Ricardo Fabian Peliquero]

Dear Maintainer,

I attach more information. I have updated to linux-image-4.13.0-trunk-amd64 
4.13.1-1, but the problem remains.

Note that aumix-common depends on oss-compat package. Also, according to kernel 
changelog (https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.13.1) there 
were changes into the sound modules.

Please, let me know any other information you might need.

Kindest regards,

Ricardo
; uname -a
Linux hp425 4.12.0-1-amd64 #1 SMP Debian 4.12.6-1 (2017-08-12) x86_64 GNU/Linux

; lspci | grep Audio
00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia 
(Intel HDA) (rev 40)
01:05.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] RS880 HDMI Audio 
[Radeon HD 4200 Series]

; cat /proc/devices
Character devices:
  1 mem
  4 /dev/vc/0
  4 tty
  4 ttyS
  5 /dev/tty
  5 /dev/console
  5 /dev/ptmx
  7 vcs
 10 misc
 13 input
 14 sound/mixer
 14 sound/dsp
 14 sound/audio
 14 sound/mixer1
 21 sg
 29 fb
 81 video4linux
116 alsa
128 ptm
136 pts
152 aoechr
180 usb
189 usb_device
226 drm
247 media
248 kfd
249 bsg
250 watchdog
251 rtc
252 dax
253 tpm
254 gpiochip

Block devices:
259 blkext
  8 sd
 11 sr
 65 sd
 66 sd
 67 sd
 68 sd
 69 sd
 70 sd
 71 sd
128 sd
129 sd
130 sd
131 sd
132 sd
133 sd
134 sd
135 sd
152 aoe
179 mmc

; ls -l /dev/dsp
crw-rw 1 root audio 14, 3 sep 14 08:57 /dev/dsp

; su -c dmesg
[0.00] Linux version 4.12.0-1-amd64 (debian-kernel@lists.debian.org) 
(gcc version 6.4.0 20170805 (Debian 6.4.0-3) ) #1 SMP Debian 4.12.6-1 
(2017-08-12)
[0.00] Command line: auto BOOT_IMAGE=LinuxViejo ro 
root=UUID=d83c21d8-53d3-46e2-8772-82e9dd92546c edd=off
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000ef000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xafce] usable
[0.00] BIOS-e820: [mem 0xafcf-0xafdcefff] reserved
[0.00] BIOS-e820: [mem 0xafdcf000-0xafecefff] ACPI NVS
[0.00] BIOS-e820: [mem 0xafecf000-0xafefefff] ACPI data
[0.00] BIOS-e820: [mem 0xafeff000-0xafef] usable
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xffe0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00013fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.6 present.
[0.00] DMI: Hewlett-Packard HP 425/1475, BIOS 68DVA Ver. F.03 08/13/2010
[0.00] tsc: Fast TSC calibration using PIT
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] AGP: No AGP bridge found
[0.00] e820: last_pfn = 0x14 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-D uncachable
[0.00]   E-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base  mask 8000 write-back
[0.00]   1 base 8000 mask E000 write-back
[0.00]   2 base A000 mask F000 write-back
[0.00]   3 base 0001 mask C000 write-back
[0.00]   4 base FFE0 mask FFE0 write-protect
[0.00]   5 base FFF4 mask  write-protect
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] TOM2: 00014000 aka 5120M
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
[0.00] e820: last_pfn = 0xaff00 max_arch_pfn = 0x4
[0.00] Base memory trampoline at [9cf680099000] 99000 size 24576
[0.00] Using GB pages for direct mapping
[0.00] BRK [0x54b54000, 0x54b54fff] PGTABLE
[0.00] BRK [0x54b55000, 0x54b55fff] PGTABLE
[0.00] BRK [0x54b56000, 0x54b56fff] PGTABLE
[0.00] BRK [0x54b57000, 0x54b57fff] PGTABLE
[0.00] BRK [0x54b58000, 0x54b58fff] PGTABLE
[0.00] RAMDISK: [mem 0x7ff3b000-0x7fff]
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000F2AA0 14 (v00 HPQOEM)
[0.00] ACPI: RSDT 0xAFEFE038 38 (v01 HPQOEM SLIC-MPC 
0003  0113)
[0.00] ACPI: FACP 0xAFEFD000 74 (v01 HPQOEM 307E 
0003 HP   0001)
[0.00] ACPI BIO

Bug#872765: linux-image-4.13.0-rc7-amd64: further information

[Ricardo Fabian Peliquero]

Dear maintainer,

Please find attached further information regarding this bug:
strace, ltrace and ls output.

The problem is still present in 4.13.0-rc7-amd64.

Should you need any other test, please let me know.

Kindest regards,

Ricardo
# Non working mixer

; uname -a
Linux hp425 4.13.0-rc7-amd64 #1 SMP Debian 4.13~rc7-1~exp1 (2017-08-30) x86_64 
GNU/Linux

; LANG=en ls -l /dev/mixer
ls: cannot access '/dev/mixer': No such file or directory

; ls -l /dev/snd/
total 0
drwxr-xr-x 2 root root   80 ago 31 16:55 by-path
crw-rw 1 root audio 116,  5 ago 31 16:55 controlC0
crw-rw 1 root audio 116,  2 ago 31 16:55 controlC1
crw-rw 1 root audio 116,  8 ago 31 16:55 hwC0D0
crw-rw 1 root audio 116,  4 ago 31 16:55 hwC1D0
crw-rw 1 root audio 116,  7 ago 31 16:55 pcmC0D0c
crw-rw 1 root audio 116,  6 ago 31 16:55 pcmC0D0p
crw-rw 1 root audio 116,  3 ago 31 16:55 pcmC1D3p
crw-rw 1 root audio 116,  1 ago 31 16:55 seq
crw-rw 1 root audio 116, 33 ago 31 16:55 timer

; ls -l /dev/snd/by-path/
total 0
lrwxrwxrwx 1 root root 12 ago 31 16:55 pci-:00:14.2 -> ../controlC0
lrwxrwxrwx 1 root root 12 ago 31 16:55 pci-:01:05.1 -> ../controlC1

; LANG=en ltrace aumix -v 90
setlocale(LC_ALL, "")   = nil
bindtextdomain("aumix", "/usr/share/locale")= "/usr/share/locale"
textdomain("aumix") = "aumix"
access("/dev/mixer", 0) = -1
getopt(3, 0x7fffee92f958, "hILqSd:f:C:v:b:t:s:w:P:p:l:m:c:x"...) = 118
strchr("vbtswplmcxWrio123", 'v')= "vbtswplmcxWrio123"
open("/dev/sound/mixer", 2, 00) = -1
dcgettext(0, 0x55f64df0c4c4, 5, -104)   = 0x55f64df0c4c4
perror("aumix:  error opening mixer"aumix:  error opening mixer: No such file 
or directory
)   = 
fputc('\n', 0x7f63f0d6d520
) = 10
exit(1 
+++ exited (status 1) +++

; LANG=en strace aumix -v 90
execve("/usr/bin/aumix", ["aumix", "-v", "90"], [/* 17 vars */]) = 0
brk(NULL)   = 0x560d4c68c000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f134f875000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=77980, ...}) = 0
mmap(NULL, 77980, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f134f861000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libgpm.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\35\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=23056, ...}) = 0
mmap(NULL, 2119264, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f134f44f000
mprotect(0x7f134f454000, 2093056, PROT_NONE) = 0
mmap(0x7f134f653000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0x7f134f653000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libncursesw.so.5", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240{\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=194496, ...}) = 0
mmap(NULL, 2290168, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f134f21f000
mprotect(0x7f134f24e000, 2093056, PROT_NONE) = 0
mmap(0x7f134f44d000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2e000) = 0x7f134f44d000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3
read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\316\0\0\0\0\0\0"..., 832) = 
832
fstat(3, {st_mode=S_IFREG|0644, st_size=170784, ...}) = 0
mmap(NULL, 2267936, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f134eff5000
mprotect(0x7f134f01b000, 2093056, PROT_NONE) = 0
mmap(0x7f134f21a000, 20480, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x25000) = 0x7f134f21a000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\4\2\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1681176, ...}) = 0
mmap(NULL, 3787104, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f134ec58000
mprotect(0x7f134edeb000, 2097152, PROT_NONE) = 0
mmap(0x7f134efeb000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x193000) = 0x7f134efeb000
mmap(0x7f134eff1000, 14688, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS

Bug#872765: linux-image-4.13.0-rc5-amd64: cannot open audio mixer

[Ricardo Fabian Peliquero]

Package: src:linux
Version: 4.13~rc5-1~exp1
Severity: normal

Dear Maintainer,

After upgrading from linux-image-4.12.0-1-amd64 to linux-image-4.13.0-rc5-amd64,
aumix will not work.

The following error appears while booting:

  Linux hp425 4.13.0-rc5-amd64 #1 SMP Debian 4.13~rc5-1~exp1 (2017-08-14) 
x86_64 GNU/Linux

  [FAIL] Restoring mixer settings...[] failed. ... failed!

  ...

  login: [   22.327889] random: crng init done


And this error appears after running aumix (either as normal user or as root):

 aumix:  error opening mixer: No such file or directory

It is not possible to hear audio with this scenario.


I've installed alsa-utils, and alsamixer will do the job, but won't hear any 
audio after
switching back to aumix.


Downgrading to linux-image-4.12.0-1-amd64 will also solve the problem. That is, 
this
message will show while booting:

  [ ok ] Restoring mixer settings... mixer mixer1[] done..

and aumix will work as expected as normal user.


You will find dmesg's output below, but bear in mind that mixer settings 
restoring is
disabled (echo 'SAVEMIXER=no' > /etc/default/aumix).

Kindest regards,

Ricardo



-- Package-specific info:
** Version:
Linux version 4.13.0-rc5-amd64 (debian-kernel@lists.debian.org) (gcc version 
6.4.0 20170805 (Debian 6.4.0-3)) #1 SMP Debian 4.13~rc5-1~exp1 (2017-08-14)

** Command line:
auto BOOT_IMAGE=Linux ro root=UUID=d83c21d8-53d3-46e2-8772-82e9dd92546c edd=off

** Tainted: W (512)
 * Taint on warning.

** Kernel log:

[0.00] random: get_random_bytes called from start_kernel+0x3d/0x456 
with crng_init=0
[0.00] Linux version 4.13.0-rc5-amd64 (debian-kernel@lists.debian.org) 
(gcc version 6.4.0 20170805 (Debian 6.4.0-3)) #1 SMP Debian 4.13~rc5-1~exp1 
(2017-08-14)
[0.00] Command line: auto BOOT_IMAGE=Linux ro 
root=UUID=d83c21d8-53d3-46e2-8772-82e9dd92546c edd=off
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000ef000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xafce] usable
[0.00] BIOS-e820: [mem 0xafcf-0xafdcefff] reserved
[0.00] BIOS-e820: [mem 0xafdcf000-0xafecefff] ACPI NVS
[0.00] BIOS-e820: [mem 0xafecf000-0xafefefff] ACPI data
[0.00] BIOS-e820: [mem 0xafeff000-0xafef] usable
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xffe0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00013fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] random: fast init done
[0.00] SMBIOS 2.6 present.
[0.00] DMI: Hewlett-Packard HP 425/1475, BIOS 68DVA Ver. F.03 08/13/2010
[0.00] tsc: Fast TSC calibration using PIT
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] AGP: No AGP bridge found
[0.00] e820: last_pfn = 0x14 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-D uncachable
[0.00]   E-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base  mask 8000 write-back
[0.00]   1 base 8000 mask E000 write-back
[0.00]   2 base A000 mask F000 write-back
[0.00]   3 base 0001 mask C000 write-back
[0.00]   4 base FFE0 mask FFE0 write-protect
[0.00]   5 base FFF4 mask  write-protect
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] TOM2: 00014000 aka 5120M
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
[0.00] e820: last_pfn = 0xaff00 max_arch_pfn = 0x4
[0.00] Base memory trampoline at [94a500099000] 99000 size 24576
[0.00] Using GB pages for direct mapping
[0.00] BRK [0x12c357000, 0x12c357fff] PGTABLE
[0.00] BRK [0x12c358000, 0x12c358fff] PGTABLE
[0.00] BRK [0x12c359000, 0x12c359fff] PGTABLE
[0.00] BRK [0x12c35a000, 0x12c35afff] PGTABLE
[0.00] BRK [0x12c35b000, 0x12c35bfff] PGTABLE
[0.00] BRK [0x12c35c000, 0x12c35cfff] PGTABLE
[0.00] BRK [0x12c35d000, 0x12c35dfff] PGTABLE
[0

Bug#843128: partially solved

[Ricardo Fabian Peliquero]

On Fri, Dec 09, 2016 at 01:03:44PM +, Ben Hutchings wrote:
> On Fri, 2016-12-09 at 01:18 -0300, Ricardo Fabian Peliquero wrote:
> >  from: linux-image-4.8.0-1-amd64-unsigned:amd64 (4.8.5-1)
> >    to: linux-image-4.9.0-rc8-amd64-unsigned:amd64 (4.9~rc8-1~exp1)
> > and installing mingetty(8)
> > the system is booting well (e.g. without kernel panic).
> > 
> > But the following errors appeared for ttys using these lines in 
> > /etc/inittab:
> > 
> > 2:23:respawn:/sbin/fgetty tty2
> > # Produces error. Output:
> >  [   14.741345] fgetty[1309] vsyscall attempted with vsyscall=none 
> > ip:ff600400 cs:33 sp:7ffcb7dbade0 ax:ff[   14.753469] fgetty[1309]: 
> > segfault at ff600400 ip ff600400 sp 7ffcb7dbade0 error 
> > 15
> > ...
> >  INIT: Id "2" respawning too fast: disabled for 5 minutes
> > 
> > 3:23:respawn:/sbin/ngetty 3
> > # Produces error. Output:
> >  [   14.670134] ngetty-helper[1311] vsyscall attempted with vsyscall=none 
> > ip:ff600400 cs:33 sp:7ffca011e1a[   14.684298] ngetty-helper[1311]: 
> > segfault at ff600400 ip ff600400 sp 7ffca011e1a0 error 
> > 15
> 
> fgetty uses dietlibc, and the stable version of dietlibc still uses the
> vsyscall feature which is now disabled by default.  You can make it
> work again by adding 'vsyscall=emulate' to the kernel command line.
> 
> I'll have to reconsider whether to revert the configuration change now
> that I know dietlibc is a problem.

Your suggestion worked here.

I will be using vsyscall emulation option appended to lilo.conf until better 
resolution.

Thank you!

Ricardo

Bug#843128: partially solved

[Ricardo Fabian Peliquero]

Dear Maintainer,

After upgrading

 from: linux-image-4.8.0-1-amd64-unsigned:amd64 (4.8.5-1)
   to: linux-image-4.9.0-rc8-amd64-unsigned:amd64 (4.9~rc8-1~exp1)

and installing mingetty(8)

the system is booting well (e.g. without kernel panic).

But the following errors appeared for ttys using these lines in /etc/inittab:

2:23:respawn:/sbin/fgetty tty2
# Produces error. Output:
 [   14.741345] fgetty[1309] vsyscall attempted with vsyscall=none 
ip:ff600400 cs:33 sp:7ffcb7dbade0 ax:ff[   14.753469] fgetty[1309]: 
segfault at ff600400 ip ff600400 sp 7ffcb7dbade0 error 15
 [   14.761442] fgetty[1314] vsyscall attempted with vsyscall=none 
ip:ff600400 cs:33 sp:7ffc57494eb0 ax:ff[   14.774655] fgetty[1314]: 
segfault at ff600400 ip ff600400 sp 7ffc57494eb0 error 15
 [   14.783045] fgetty[1315] vsyscall attempted with vsyscall=none 
ip:ff600400 cs:33 sp:7fff4cd23c40 ax:ff[   14.797132] fgetty[1315]: 
segfault at ff600400 ip ff600400 sp 7fff4cd23c40 error 15
 [   14.805678] fgetty[1316] vsyscall attempted with vsyscall=none 
ip:ff600400 cs:33 sp:7ffebc275580 ax:ff[   14.820255] fgetty[1316]: 
segfault at ff600400 ip ff600400 sp 7ffebc275580 error 15
 [   14.829085] fgetty[1317] vsyscall attempted with vsyscall=none 
ip:ff600400 cs:33 sp:7ffdf2ba87d0 ax:ff[   14.846203] fgetty[1317]: 
segfault at ff600400 ip ff600400 sp 7ffdf2ba87d0 error 15
 [   14.855785] fgetty[1318] vsyscall attempted with vsyscall=none 
ip:ff600400 cs:33 sp:7fff05d8bca0 ax:ff[   14.873951] fgetty[1318]: 
segfault at ff600400 ip ff600400 sp 7fff05d8bca0 error 15
 [   14.883984] fgetty[1319] vsyscall attempted with vsyscall=none 
ip:ff600400 cs:33 sp:7ffdb25fe940 ax:ff[   14.903582] fgetty[1319]: 
segfault at ff600400 ip ff600400 sp 7ffdb25fe940 error 15
 [   14.914209] fgetty[1320] vsyscall attempted with vsyscall=none 
ip:ff600400 cs:33 sp:7ffe39d6bda0 ax:ff[   14.934960] fgetty[1320]: 
segfault at ff600400 ip ff600400 sp 7ffe39d6bda0 error 15
 [   14.946825] fgetty[1321] vsyscall attempted with vsyscall=none 
ip:ff600400 cs:33 sp:7fff000656c0 ax:ff[   14.968608] fgetty[1321]: 
segfault at ff600400 ip ff600400 sp 7fff000656c0 error 15
 [   14.981397] fgetty[1322] vsyscall attempted with vsyscall=none 
ip:ff600400 cs:33 sp:7fffa6d94100 ax:ff[   15.004560] fgetty[1322]: 
segfault at ff600400 ip ff600400 sp 7fffa6d94100 error 15
 INIT: Id "2" respawning too fast: disabled for 5 minutes

3:23:respawn:/sbin/ngetty 3
# Produces error. Output:
 [   14.670134] ngetty-helper[1311] vsyscall attempted with vsyscall=none 
ip:ff600400 cs:33 sp:7ffca011e1a[   14.684298] ngetty-helper[1311]: 
segfault at ff600400 ip ff600400 sp 7ffca011e1a0 error 15


Please let me know if you consider these errors should be reported to fgetty 
and ngetty maintainers.

Kind regards,

Ricardo

Bug#839881: firmware-linux recommends both amd64-microcode and intel-microcode

[Ricardo Fabian Peliquero]

Package: firmware-linux
Version: 20160824-1
Severity: minor

Dear Maintainer,

firmware-linux recommends both amd64-microcode AND intel-microcode packages. 
Please consider if recommending amd64-microcode OR intel-microcode would be 
enough.

Kind regards,

Ricardo


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

Kernel: Linux 4.7.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages firmware-linux depends on:
ii  firmware-linux-free 3.4
ii  firmware-linux-nonfree  20160824-1

Versions of packages firmware-linux recommends:
ii  amd64-microcode  3.20160316.1
pn  intel-microcode  

firmware-linux suggests no packages.

-- no debconf information

Bug#801084: bluez-firmware: Please include firmware for Broadcom Corp. BCM20702 Bluetooth 4.0

[Fabian Greffrath]

Package: bluez-firmware
Version: 1.2-3
Severity: important

Hi there,

I have spent yesterday evening with trying to get my Bluetooth
working. After several attempts (e.g. adding my uid to the "lp" group,
because I got "DBusFailedError: No such file or directory" errors from
blueman) I found the following in my 'dmesg' output:

bluetooth hci0: Direct firmware load for brcm/BCM20702A0-0a5c-21e6.hcd
failed with error -2

Apparently, this file is missing for a proper operation of the
Bluetooth dongle on my system. However, it is not available in any
firmware package in Debian. Thus, I am asking you to add it to the
bluez-firmware package which I find most appropriate for this.

Having searched the web for this file name, I found the following site
with instructions on how to download and install it:

http://plugable.com/2014/06/23/plugable-usb-bluetooth-adapter-solving-hfphsp-profile-issues-on-linux

Once I followed the instructions on this site, I could connect all my
Bluetooth devices to my laptop.

Some additional information:

I am using a Lenovo ThinkPad T430.

# dmidecode -s bios-version; dmidecode -s bios-release-date
G1ETA6WW (2.66 )
08/19/2014

$ lsusb | grep Blue
Bus 003 Device 007: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0
[ThinkPad]

$ uname -a
Linux kff50 4.2.0-1-amd64 #1 SMP Debian 4.2.1-2 (2015-09-27) x86_64
GNU/Linux

Please tell me if you think a different package (e.g.
firmware-linux-nonfree, CC:ed) is better suited to hold this firmware,
I will then re-assign this bug there.

Thanks!

 - Fabian

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

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#722270: Acknowledgement (linux-image-3.10-2-amd64: Will only reboot if ehci_pci and ehci_hcd modules are unloaded)

[Fabian Greffrath]

Am Montag, den 09.09.2013, 17:36 +0200 schrieb Fabian Greffrath:
> my system will only reboot, e.g. from the gnome-shell menu, if I have
> forcefully unloaded the ehci_pci and ehci_hcd modules via rmmod 
> before. Else, it simply changes to a VT and prints a line like "The
> system is going to reboot NOW" but nothing happens.

Interestingly, suspend only works if the e1000e module is unloaded
before. Should I file a wishlist bug against pm-utils to include this in
some quirk?

- Fabian


-- 
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/1383817324.13330.10.ca...@kff50.ghi.rwth-aachen.de

Bug#722270: linux-image-3.10-2-amd64: Will only reboot if ehci_pci and ehci_hcd modules are unloaded

[Fabian Greffrath]

Package: src:linux
Version: 3.10.7-1
Severity: normal

Hi,

my system will only reboot, e.g. from the gnome-shell menu, if I have
forcefully unloaded the ehci_pci and ehci_hcd modules via rmmod before. Else,
it simply changes to a VT and prints a line like "The system is going to reboot
NOW" but nothing happens.

 - Fabian



-- Package-specific info:
** Version:
Linux version 3.10-2-amd64 (debian-kernel@lists.debian.org) (gcc version 4.7.3 
(Debian 4.7.3-6) ) #1 SMP Debian 3.10.7-1 (2013-08-17)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.10-2-amd64 
root=UUID=9589f0ee-81d5-4860-b95b-1164a796a1c9 ro init=/bin/systemd quiet

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
[   12.941024] USB Video Class driver (1.1.1)
[   13.061988] usbcore: registered new interface driver btusb
[   13.064561] nouveau  [   VBIOS][:01:00.0] ... appears to be valid
[   13.064565] nouveau  [   VBIOS][:01:00.0] using image from ACPI
[   13.064745] nouveau  [   VBIOS][:01:00.0] BIT signature found
[   13.064749] nouveau  [   VBIOS][:01:00.0] version 70.08.b7.02.02
[   13.065027] nouveau  [ DEVINIT][:01:00.0] adaptor not initialised
[   13.065030] nouveau  [   VBIOS][:01:00.0] running init tables
[   13.172016] nouveau  [ PFB][:01:00.0] RAM type: DDR3
[   13.172019] nouveau  [ PFB][:01:00.0] RAM size: 1024 MiB
[   13.172030] nouveau  [ PFB][:01:00.0]ZCOMP: 0 tags
[   13.195957] nouveau  [  PTHERM][:01:00.0] FAN control: none / external
[   13.195965] nouveau  [  PTHERM][:01:00.0] fan management: disabled
[   13.195969] nouveau  [  PTHERM][:01:00.0] internal sensor: yes
[   13.199673] vga_switcheroo: enabled
[   13.199836] [TTM] Zone  kernel: Available graphics memory: 3936720 kiB
[   13.199838] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[   13.199839] [TTM] Initializing pool allocator
[   13.199842] [TTM] Initializing DMA pool allocator
[   13.199856] mtrr: no more MTRRs available
[   13.199859] nouveau  [ DRM] VRAM: 1024 MiB
[   13.199860] nouveau  [ DRM] GART: 512 MiB
[   13.199864] nouveau  [ DRM] TMDS table version 2.0
[   13.199865] nouveau  [ DRM] DCB version 4.0
[   13.199868] nouveau  [ DRM] DCB outp 00: 01800323 00010034
[   13.199870] nouveau  [ DRM] DCB outp 01: 02811300 
[   13.199871] nouveau  [ DRM] DCB outp 02: 028223a6 0f220010
[   13.199873] nouveau  [ DRM] DCB outp 03: 02822362 00020010
[   13.199874] nouveau  [ DRM] DCB outp 04: 048333b6 0f220010
[   13.199876] nouveau  [ DRM] DCB outp 05: 04833372 00020010
[   13.199877] nouveau  [ DRM] DCB outp 06: 088443c6 0f220010
[   13.199879] nouveau  [ DRM] DCB outp 07: 08844382 00020010
[   13.199880] nouveau  [ DRM] DCB conn 00: 0040
[   13.199882] nouveau  [ DRM] DCB conn 01: 0100
[   13.199883] nouveau  [ DRM] DCB conn 02: 00110246
[   13.199885] nouveau  [ DRM] DCB conn 03: 00220346
[   13.199886] nouveau  [ DRM] DCB conn 04: 01400446
[   13.200682] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[   13.200683] [drm] No driver support for vblank timestamp query.
[   13.200686] nouveau  [ DRM] ACPI backlight interface available, not 
registering our own
[   13.200700] nouveau W[ DRM] voltage table 0x50 unknown
[   13.200857] nouveau  [ DRM] 2 available performance level(s)
[   13.200860] nouveau  [ DRM] 1: core 270MHz shader 540MHz memory 405MHz
[   13.200863] nouveau  [ DRM] 3: core 475MHz shader 950MHz memory 900MHz 
voltage 10mV
[   13.200865] nouveau  [ DRM] c: core 270MHz shader 540MHz memory 405MHz
[   13.205481] nouveau  [ DRM] MM: using COPY0 for buffer copies
[   13.297335] psmouse serio2: alps: Unknown ALPS touchpad: E7=10 00 64, EC=10 
00 64
[   13.406431] nouveau :01:00.0: No connectors reported connected with modes
[   13.406435] [drm] Cannot find any crtc or sizes - going 1024x768
[   13.436728] nouveau  [ DRM] allocated 1024x768 fb: 0x6, bo 
880231ba8800
[   13.436862] nouveau :01:00.0: fb1: nouveaufb frame buffer device
[   13.436866] [drm] Initialized nouveau 1.1.1 20120801 for :01:00.0 on 
minor 1
[   13.465791] RPC: Registered named UNIX socket transport module.
[   13.465794] RPC: Registered udp transport module.
[   13.465795] RPC: Registered tcp transport module.
[   13.465796] RPC: Registered tcp NFSv4.1 backchannel transport module.
[   13.502892] FS-Cache: Loaded
[   13.515774] Key type dns_resolver registered
[   13.541646] FS-Cache: Netfs 'nfs' registered for caching
[   13.783953] Installing knfsd (copyright (C) 1996 o...@monad.swb.de).
[   14.574163] psmouse serio2: trackpoint: IBM TrackPoint firmware: 0x0e, 
buttons: 3/3
[   14.768921] input: TPPS/2 IBM TrackPoint as 
/devices/platform/i8042/serio1/serio2/input/input15
[   15.671622] input: ACPI Virtual Keyboard Device as 
/devices/virtual/input/input16
[   15.924591] lp: driver loaded but no devices found
[   15

Bug#702880: Acknowledgement (linux-image-3.8-trunk-amd64: Suspend locks when the laptop lid is closed)

[Fabian Greffrath]

I should add to that bug report that suspending and waking up works
perfectly fine if I manually invoke "sudo sudo pm-suspend
--quirk-s3-bios --quirk-s3-mode". The phrase "text mode" in PM-ACTION(8)
gave the final hint. However, I have no idea how the Gnome menu knew how
to invoke it with the right quirks, whereas the kernel had no idea when
I just closed the Lid...

 - Fabian


> when I am logged in into a Gnome session and close the lid of my
> laptop, the
> suspend process somehow hangs. It looks like it switched to VC1,
> because I can
> see some part of the boot log, but the computer is still on but
> unresponsive
> and the fan turns on high speed. However, when I suspend the system
> via the
> personal menu in the right corner of gnome-shell (hit Alt and click on
> "Switch
> off"), the system suspends and wakes up perfectly. I have to admit I
> am not
> perfectly sure where to file this bug, but since I am sure the kernel
> is
> involved, I am filing it here. ;)


-- 
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/1366194281.8788.6.camel@debian

Bug#702880: linux-image-3.8-trunk-amd64: Suspend locks when the laptop lid is closed

[Fabian Greffrath]

Package: src:linux
Version: 3.8.2-1~experimental.1
Severity: normal

Hi Debian Kernel team,

when I am logged in into a Gnome session and close the lid of my laptop, the
suspend process somehow hangs. It looks like it switched to VC1, because I can
see some part of the boot log, but the computer is still on but unresponsive
and the fan turns on high speed. However, when I suspend the system via the
personal menu in the right corner of gnome-shell (hit Alt and click on "Switch
off"), the system suspends and wakes up perfectly. I have to admit I am not
perfectly sure where to file this bug, but since I am sure the kernel is
involved, I am filing it here. ;)

Cheers,
 - Fabian



-- Package-specific info:
** Version:
Linux version 3.8-trunk-amd64 (debian-kernel@lists.debian.org) (gcc version 
4.7.2 (Debian 4.7.2-5) ) #1 SMP Debian 3.8.2-1~experimental.1

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.8-trunk-amd64 
root=UUID=fcfe4b79-8543-4b30-a687-7c018a18437c ro quiet

** Not tainted

** Kernel log:
[30405.688221] [drm] ib test on ring 3 succeeded in 1 usecs
[30405.852045] usb 1-6: reset high-speed USB device number 2 using ehci-pci
[30405.956077] ata5: SATA link down (SStatus 0 SControl 300)
[30405.956147] ata6: SATA link down (SStatus 0 SControl 300)
[30406.128057] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[30406.156045] ata2.00: configured for UDMA/100
[30406.192058] firewire_core :09:01.0: rediscovered device fw0
[30406.244054] usb 7-1: reset low-speed USB device number 2 using uhci_hcd
[30407.160190] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at 
byte 1
[30407.976042] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[30407.992823] ata1.00: configured for UDMA/133
[30407.992981] sd 0:0:0:0: [sda] Starting disk
[30407.999800] PM: resume of devices complete after 2363.356 msecs
[30408.000171] PM: Finishing wakeup.
[30408.000172] Restarting tasks ... done.
[30408.017097] video LNXVIDEO:00: Restoring backlight state
[30408.915005] iwlwifi :04:00.0: L1 Enabled; Disabling L0S
[30408.918029] iwlwifi :04:00.0: Radio type=0x0-0x2-0x0
[30409.070771] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[30409.081003] tg3 :08:00.0: irq 50 for MSI/MSI-X
[30409.190162] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[30415.512078] wlan0: authenticate with 00:c0:02:e6:ae:a2
[30415.512826] wlan0: capabilities/regulatory prevented using AP HT/VHT 
configuration, downgraded
[30415.513473] wlan0: send auth to 00:c0:02:e6:ae:a2 (try 1/3)
[30415.515771] wlan0: authenticated
[30415.516058] iwlwifi :04:00.0 wlan0: disabling HT/VHT due to WEP/TKIP use
[30415.516064] iwlwifi :04:00.0 wlan0: disabling HT as WMM/QoS is not 
supported by the AP
[30415.516069] iwlwifi :04:00.0 wlan0: disabling VHT as WMM/QoS is not 
supported by the AP
[30415.520054] wlan0: associate with 00:c0:02:e6:ae:a2 (try 1/3)
[30415.521924] wlan0: RX AssocResp from 00:c0:02:e6:ae:a2 (capab=0x411 status=0 
aid=2)
[30415.527616] wlan0: associated
[30415.527665] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[30417.547629] traps: nautilus-shell-[26035] general protection ip:42d00b 
sp:7fff6949f730 error:0 in nautilus-shell-search-provider[40+78000]
[30418.075566] traps: nautilus-shell-[26050] general protection ip:42d00b 
sp:7fff102c43e0 error:0 in nautilus-shell-search-provider[40+78000]
[32614.284397] wlan0: deauthenticating from 00:c0:02:e6:ae:a2 by local choice 
(reason=3)
[32614.296456] cfg80211: Calling CRDA to update world regulatory domain
[32614.321471] cfg80211: World regulatory domain updated:
[32614.321477] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp)
[32614.321480] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 
2000 mBm)
[32614.321483] cfg80211:   (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 
2000 mBm)
[32614.321485] cfg80211:   (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 
2000 mBm)
[32614.321488] cfg80211:   (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 
2000 mBm)
[32614.321491] cfg80211:   (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 
2000 mBm)
[32617.634810] wlan0: authenticate with a2:21:b7:95:bb:10
[32617.635388] wlan0: capabilities/regulatory prevented using AP HT/VHT 
configuration, downgraded
[32617.636303] wlan0: send auth to a2:21:b7:95:bb:10 (try 1/3)
[32617.638091] wlan0: authenticated
[32617.638371] iwlwifi :04:00.0 wlan0: disabling HT/VHT due to WEP/TKIP use
[32617.641421] wlan0: associate with a2:21:b7:95:bb:10 (try 1/3)
[32617.643969] wlan0: RX AssocResp from a2:21:b7:95:bb:10 (capab=0x411 status=0 
aid=3)
[32617.646912] wlan0: associated
[32649.912050] iwlwifi :04:00.0: fail to flush all tx fifo queues
[32651.920081] iwlwifi :04:00.0: fail to flush all tx fifo queues
[32653.928080] iwlwifi :04:00.0: fail to flush all tx fifo queues
[32655.936078] iwlwifi :04:00.0: fail to flush all tx fifo queues
[32657.952078] iwlwifi :04:00.0: fail to flush a

Bug#702878: linux-image-3.8-trunk-amd64: WLAN does not connect to range extender

[Fabian Greffrath]

Package: src:linux
Version: 3.8.2-1~experimental.1
Severity: normal

Dear Kernel team,

I have a WLAN setup at home with an access point in the cellar and a range
extender (Netgear WN2000RPT) in the living room. With my laptop I can connect
to the access point in the cellar, but not to the range extender. I have
attached diff in the output of 'dmesg' before and after a failed connection
attempt to this bug report. I am not filing this bug against network-manager,
isc-dhcp-client or any other userland tools, because I know the hardware works
(I can connect when booting into Windows Vista which is still installed on a
separate partition) and the software stack itself works, too (I can connect to
the access point, not to the range extender). Thus, I believe it's a driver
issue and the driver is provided by the kernel. For the record, this issue is
present with both the 3.2 kernel in testing and the 3.8 one in experimental. If
there is any more information you need to track down this bug, I'll be happy to
provide it.

Thanks,
 - Fabian



-- Package-specific info:
** Version:
Linux version 3.8-trunk-amd64 (debian-kernel@lists.debian.org) (gcc version 
4.7.2 (Debian 4.7.2-5) ) #1 SMP Debian 3.8.2-1~experimental.1

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.8-trunk-amd64 
root=UUID=fcfe4b79-8543-4b30-a687-7c018a18437c ro quiet

** Not tainted

** Kernel log:
[30405.688221] [drm] ib test on ring 3 succeeded in 1 usecs
[30405.852045] usb 1-6: reset high-speed USB device number 2 using ehci-pci
[30405.956077] ata5: SATA link down (SStatus 0 SControl 300)
[30405.956147] ata6: SATA link down (SStatus 0 SControl 300)
[30406.128057] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[30406.156045] ata2.00: configured for UDMA/100
[30406.192058] firewire_core :09:01.0: rediscovered device fw0
[30406.244054] usb 7-1: reset low-speed USB device number 2 using uhci_hcd
[30407.160190] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at 
byte 1
[30407.976042] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[30407.992823] ata1.00: configured for UDMA/133
[30407.992981] sd 0:0:0:0: [sda] Starting disk
[30407.999800] PM: resume of devices complete after 2363.356 msecs
[30408.000171] PM: Finishing wakeup.
[30408.000172] Restarting tasks ... done.
[30408.017097] video LNXVIDEO:00: Restoring backlight state
[30408.915005] iwlwifi :04:00.0: L1 Enabled; Disabling L0S
[30408.918029] iwlwifi :04:00.0: Radio type=0x0-0x2-0x0
[30409.070771] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[30409.081003] tg3 :08:00.0: irq 50 for MSI/MSI-X
[30409.190162] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[30415.512078] wlan0: authenticate with 00:c0:02:e6:ae:a2
[30415.512826] wlan0: capabilities/regulatory prevented using AP HT/VHT 
configuration, downgraded
[30415.513473] wlan0: send auth to 00:c0:02:e6:ae:a2 (try 1/3)
[30415.515771] wlan0: authenticated
[30415.516058] iwlwifi :04:00.0 wlan0: disabling HT/VHT due to WEP/TKIP use
[30415.516064] iwlwifi :04:00.0 wlan0: disabling HT as WMM/QoS is not 
supported by the AP
[30415.516069] iwlwifi :04:00.0 wlan0: disabling VHT as WMM/QoS is not 
supported by the AP
[30415.520054] wlan0: associate with 00:c0:02:e6:ae:a2 (try 1/3)
[30415.521924] wlan0: RX AssocResp from 00:c0:02:e6:ae:a2 (capab=0x411 status=0 
aid=2)
[30415.527616] wlan0: associated
[30415.527665] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[30417.547629] traps: nautilus-shell-[26035] general protection ip:42d00b 
sp:7fff6949f730 error:0 in nautilus-shell-search-provider[40+78000]
[30418.075566] traps: nautilus-shell-[26050] general protection ip:42d00b 
sp:7fff102c43e0 error:0 in nautilus-shell-search-provider[40+78000]
[32614.284397] wlan0: deauthenticating from 00:c0:02:e6:ae:a2 by local choice 
(reason=3)
[32614.296456] cfg80211: Calling CRDA to update world regulatory domain
[32614.321471] cfg80211: World regulatory domain updated:
[32614.321477] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp)
[32614.321480] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 
2000 mBm)
[32614.321483] cfg80211:   (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 
2000 mBm)
[32614.321485] cfg80211:   (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 
2000 mBm)
[32614.321488] cfg80211:   (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 
2000 mBm)
[32614.321491] cfg80211:   (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 
2000 mBm)
[32617.634810] wlan0: authenticate with a2:21:b7:95:bb:10
[32617.635388] wlan0: capabilities/regulatory prevented using AP HT/VHT 
configuration, downgraded
[32617.636303] wlan0: send auth to a2:21:b7:95:bb:10 (try 1/3)
[32617.638091] wlan0: authenticated
[32617.638371] iwlwifi :04:00.0 wlan0: disabling HT/VHT due to WEP/TKIP use
[32617.641421] wlan0: associate with a2:21:b7:95:bb:10 (try 1/3)
[32617.643969] wlan0: RX AssocResp from a2:21:b7:95:bb:10 (capab=0

Oracle’s Unbreakable Enterprise Kernel - is there more to it?

[Fabian Greffrath]

Dear kernel team and -devel,

Oracle recently announced [1] their own 2.6.32-based Unbreakable 
Enterprise Kernel for their RHEL derivative called Oracle Linux. The 
announcement promises severe performance improvements compared to the 
stock RHEL kernel.


Do you know what patches they applied to the kernel and if they (or 
parts of them) are acceptable for Debian's linux-2.6 kernel as well?


Best regards,
 - Fabian

[1] http://www.oracle.com/us/corporate/press/173453


--
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/4c99c1f7.3090...@greffrath.com

Bug#588433: closed by Ben Hutchings (Re: Bug#588433: linux-image-2.6.32-5-686: tries to run update-grub, although grub isn't installed anymore)

[Fabian Greffrath]

reopen 588433
reassign 588433 grub-pc
found 588433 1.98+20100706-1
retitle Please remove entries from /etc/kernel-img.conf when removed
thanks

Am 08.07.2010 22:15, schrieb Debian Bug Tracking System:

That file is created by the installer.  If you choose to install GRUB during
the initial installation then it sets these hook commands.  This is in no way
a bug in the kernel package.


Alright, then I am reassigning this to the grub-pc package.

Collin, even if I purged the grub packages from my system, update-grub 
is still referenced by the /etc/kernel-img.conf file, which has been 
created by the installer. This leads to failure in the kernel package 
configuration phase. Please remove these entries when the package is 
removed, because this will also delete the update-grub script.


Cheers,
Fabian



--
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/4c36d214.8050...@greffrath.com

Bug#588433: linux-image-2.6.32-5-686: tries to run update-grub, although grub isn't installed anymore

[Fabian Greffrath]

Package: linux-2.6
Version: 2.6.32-16
Severity: normal

Hi,

today the linux-image-2.6.32-5-686 (2.6.32-16) package failed for me during the
configuration phase. When the postinst script is run manually, the following
happens:

$ sudo LANG=C /var/lib/dpkg/info/linux-image-`uname -r`.postinst configure
Running depmod.
Running update-initramfs.
update-initramfs: Generating /boot/initrd.img-2.6.32-5-686
initrd.img(/boot/initrd.img-2.6.32-5-686
) points to /boot/initrd.img-2.6.32-5-686
 (/boot/initrd.img-2.6.32-5-686) -- doing nothing at /var/lib/dpkg/info/linux-
image-2.6.32-5-686.postinst line 379.
vmlinuz(/boot/vmlinuz-2.6.32-5-686
) points to /boot/vmlinuz-2.6.32-5-686
 (/boot/vmlinuz-2.6.32-5-686) -- doing nothing at /var/lib/dpkg/info/linux-
image-2.6.32-5-686.postinst line 379.
Running update-grub.
User postinst hook script [update-grub] failed to execute: No such file or
directory

So it fails to start update-grub, which is expected as I have purged all grub
packages from my system and replaced it with the extlinux bootloader instead.
However, grub-pc is still set as postinst_hook in /etc/kernel-img.conf:

$ grep grub /etc/kernel-img.conf
postinst_hook = update-grub
postrm_hook   = update-grub

Please note that I have never ever touched this file. It should not blindly
rely the existance of update-grub.

Cheers,
Fabian



-- Package-specific info:
** Version:
Linux version 2.6.32-5-686 (Debian 2.6.32-16) (b...@decadent.org.uk) (gcc 
version 4.3.5 (Debian 4.3.5-1) ) #1 SMP Tue Jul 6 14:57:57 UTC 2010

** Command line:
initrd=/boot/initrd.img-2.6.32-5-686 
root=UUID=e6445315-c5bf-4e2c-b011-3ed84748fd53 ro quiet 
BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 

** Not tainted

** Kernel log:
[1.267887] ehci_hcd :00:0b.0: irq 19, io mem 0xf0805000
[1.273371] libata version 3.00 loaded.
[1.276165] ehci_hcd :00:0b.0: USB 2.0 started, EHCI 1.00
[1.276207] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[1.276208] usb usb1: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[1.276210] usb usb1: Product: EHCI Host Controller
[1.276212] usb usb1: Manufacturer: Linux 2.6.32-5-686 ehci_hcd
[1.276213] usb usb1: SerialNumber: :00:0b.0
[1.276533] usb usb1: configuration #1 chosen from 1 choice
[1.276596] hub 1-0:1.0: USB hub found
[1.276602] hub 1-0:1.0: 8 ports detected
[1.278578] ata_piix :00:01.1: version 2.13
[1.278925] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[1.283457] scsi0 : ata_piix
[1.283803] scsi1 : ata_piix
[1.284000] ata1: PATA max UDMA/33 cmd 0x1f0 ctl 0x3f6 bmdma 0xd000 irq 14
[1.284002] ata2: PATA max UDMA/33 cmd 0x170 ctl 0x376 bmdma 0xd008 irq 15
[1.284297] ohci_hcd :00:06.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
[1.284348] ohci_hcd :00:06.0: OHCI Host Controller
[1.284366] ohci_hcd :00:06.0: new USB bus registered, assigned bus 
number 2
[1.284443] ohci_hcd :00:06.0: irq 22, io mem 0xf0804000
[1.340199] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
[1.340202] usb usb2: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[1.340203] usb usb2: Product: OHCI Host Controller
[1.340205] usb usb2: Manufacturer: Linux 2.6.32-5-686 ohci_hcd
[1.340206] usb usb2: SerialNumber: :00:06.0
[1.340284] usb usb2: configuration #1 chosen from 1 choice
[1.340302] hub 2-0:1.0: USB hub found
[1.340360] hub 2-0:1.0: 8 ports detected
[1.440679] ata2.00: ATAPI: VBOX CD-ROM, 1.0, max UDMA/133
[1.440943] ata1.00: ATA-6: VBOX HARDDISK, 1.0, max UDMA/133
[1.440945] ata1.00: 16777216 sectors, multi 128: LBA 
[1.441587] ata2.00: configured for UDMA/33
[1.441766] ata1.00: configured for UDMA/33
[1.441985] scsi 0:0:0:0: Direct-Access ATA  VBOX HARDDISK1.0  
PQ: 0 ANSI: 5
[1.442390] scsi 1:0:0:0: CD-ROMVBOX CD-ROM   1.0  
PQ: 0 ANSI: 5
[1.478171] sd 0:0:0:0: [sda] 16777216 512-byte logical blocks: (8.58 
GB/8.00 GiB)
[1.478202] sd 0:0:0:0: [sda] Write Protect is off
[1.478204] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[1.478216] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[1.478336]  sda: sda1 sda2 
[1.493719] sd 0:0:0:0: [sda] Attached SCSI disk
[1.533184] sd 0:0:0:0: Attached scsi generic sg0 type 0
[1.533486] sr 1:0:0:0: Attached scsi generic sg1 type 5
[1.765793] PM: Starting manual resume from disk
[1.765795] PM: Resume from partition 8:5
[1.765796] PM: Checking hibernation image.
[1.765982] PM: Error -22 checking image file
[1.765983] PM: Resume from disk failed.
[1.802971] kjournald starting.  Commit interval 5 seconds
[1.802979] EXT3-fs: mounted filesystem with ordered data mode.
[2.812132] udev: starting version 158
[3.528405] pci :00:04.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
[3.530095] vboxguest: maj

Bug#575681: xserver-xorg-video-radeon: shows severe artifacts since switching to KMS

[Fabian Greffrath]

Am 06.04.2010 12:16, schrieb Michel Dänzer:

My patch has landed in Dave Airlie's drm-linus tree and should make it
into 2.6.34 and hopefully also 2.6.33.y.


That's good news (finally, my graphics hardware is more than 7 years 
old). However, I would love to also see this patch included in the 
2.6.32 kernel that is going to be shipped with Debian squeeze.



Thanks for testing, Fabian.


It was an honour for me. ;)



--
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/4bbb1b41.8000...@greffrath.com

Bug#575681: xserver-xorg-video-radeon: shows severe artifacts since switching to KMS

[Fabian Greffrath]

Dear Michel,

Am Donnerstag, den 01.04.2010, 12:59 +0200 schrieb Michel Dänzer:
> > Will try to test it within the next few days.
> Great, thanks.

I tried the patch and can confirm that it works [*] and that it solves
the actual issue: No more artifacts in X for me. Thank you very much!

dmesg now shows the following line:

$ dmesg  | grep -i pipe 
[5.466112] [drm] radeon: 1 quad pipes, 1 Z pipes initialized.

[*] That is, I don't know which version of the kernel you used to create
the patch, but I had to slightly modify it a bit. The attached version
applies perfectly against version 2.6.32-10 in Debian.

Dear Kernel team, please apply this patch. Furthermore I think it should
get integrated upstream. Thank you very much again to all involved!

Cheers,
Fabian

>From ac8c8618c625039ec29870c2a9c36733695ecd56 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Michel=20D=C3=A4nzer?= 
Date: Thu, 1 Apr 2010 10:18:09 +0200
Subject: [PATCH] drm/radeon: R300 AD only has one quad pipe.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Gleaned from the Mesa code.

Signed-off-by: Michel Dänzer 
---
 drivers/gpu/drm/radeon/r300.c  |6 +++---
 drivers/gpu/drm/radeon/radeon_cp.c |   10 ++
 2 files changed, 9 insertions(+), 7 deletions(-)

--- linux-2.6-2.6.32.orig/drivers/gpu/drm/radeon/r300.c
+++ linux-2.6-2.6.32/drivers/gpu/drm/radeon/r300.c
@@ -345,12 +345,12 @@
 	uint32_t gb_tile_config, tmp;
 
 	r100_hdp_reset(rdev);
-	/* FIXME: rv380 one pipes ? */
-	if ((rdev->family == CHIP_R300) || (rdev->family == CHIP_R350)) {
+	if ((rdev->family == CHIP_R300 && rdev->pdev->device != 0x4144) ||
+	(rdev->family == CHIP_R350)) {
 		/* r300,r350 */
 		rdev->num_gb_pipes = 2;
 	} else {
-		/* rv350,rv370,rv380 */
+		/* rv350,rv370,rv380,r300 AD */
 		rdev->num_gb_pipes = 1;
 	}
 	rdev->num_z_pipes = 1;
--- linux-2.6-2.6.32.orig/drivers/gpu/drm/radeon/radeon_cp.c
+++ linux-2.6-2.6.32/drivers/gpu/drm/radeon/radeon_cp.c
@@ -417,8 +417,9 @@
 	return -EBUSY;
 }
 
-static void radeon_init_pipes(drm_radeon_private_t *dev_priv)
+static void radeon_init_pipes(struct drm_device *dev)
 {
+	drm_radeon_private_t *dev_priv = dev->dev_private;
 	uint32_t gb_tile_config, gb_pipe_sel = 0;
 
 	if ((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RV530) {
@@ -436,11 +437,12 @@
 		dev_priv->num_gb_pipes = ((gb_pipe_sel >> 12) & 0x3) + 1;
 	} else {
 		/* R3xx */
-		if (((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_R300) ||
+		if (((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_R300 &&
+		 dev->pdev->device != 0x4144) ||
 		((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_R350)) {
 			dev_priv->num_gb_pipes = 2;
 		} else {
-			/* R3Vxx */
+			/* RV3xx/R300 AD */
 			dev_priv->num_gb_pipes = 1;
 		}
 	}
@@ -736,7 +738,7 @@
 
 	/* setup the raster pipes */
 	if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_R300)
-	radeon_init_pipes(dev_priv);
+	radeon_init_pipes(dev);
 
 	/* Reset the CP ring */
 	radeon_do_cp_reset(dev_priv);

Bug#575681: xserver-xorg-video-radeon: shows severe artifacts since switching to KMS

[Fabian Greffrath]

Am 01.04.2010 12:36, schrieb Michel Dänzer:

Does that mean you tested the patch and it works?


Not yet. I was just impressed by how quickly you were able to trace 
the issue and provide a patch. Will try to test it within the next few 
days.


Regards,
Fabian




--
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/4bb47b42.8090...@greffrath.com

Bug#575681: xserver-xorg-video-radeon: shows severe artifacts since switching to KMS

[Fabian Greffrath]

tags 575681 + patch
thanks

Am 01.04.2010 10:39, schrieb Michel Dänzer:

Looking at the Mesa code confirmed my suspicion, the attached kernel
patch should fix it. Reassigning to the kernel.


Impressive, thank you very much!


I understood that and said this was unlikely: the artifacts looked to be
related to the rendering engine, and the display engine is generally
completely separate from that.


Fine, thanks for this explanation. :)

 - Fabian




--
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/4bb46cec.1060...@greffrath.com

Bug#530620: debian/copyright: s/Torwalds/Torvalds/

[Fabian Greffrath]

Package: linux-2.6
Version: 2.6.29-5
Severity: minor

Dear Kernel packagers,

the name of the initiator of the Linux kernel is "Linus Torvalds" [1], 
not "Linus Torwalds" [2] as found in the debian/copyright file.


[1] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=COPYING;h=ca442d313d86dc67e0a2e5d584b465bd382cbf5c;hb=27b1833279995e7c290a40cac4ef36ccea7e9283
[2] 
http://packages.debian.org/changelogs/pool/main/l/linux-2.6/current/copyright


--
Dipl.-Phys. Fabian Greffrath

Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
D-44780 Bochum

Telefon: +49 (0)234 / 32-26334
Fax: +49 (0)234 / 32-14227
E-Mail:  greffr...@leat.ruhr-uni-bochum.de



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#497230: [alpha] legacy and generic package descriptions

[Fabian Greffrath]

Well, I still don't entirely know what the -legacy package is for nor 
what constitutes an "Alpha Legacy Machine". Looking at the linux-2.6 
Debian changelog it appears it may be something to do with MILO.


Yes, same problem here.

Please provide a (non-exhaustive) list of model and/or system types 
that are supported by each particular package. For example, I have an 
"Alpha EV67" with system type and variation reported as "Tsunami" and 
"Monet" by /proc/cpuinfo. However, I still don't have any clue if I 
have to install the -generic or the -legacy kernel.


Thanks!

Cheers,
Fabian
--
Dipl.-Phys. Fabian Greffrath

Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
D-44780 Bochum

Telefon: +49 (0)234 / 32-26334
Fax: +49 (0)234 / 32-14227
E-Mail:  [EMAIL PROTECTED]



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Question about "time indices" during boot process with new (>= 2.6.25) kernel images

[Fabian Greffrath]

Thanks for your explanations, Daniel!

--
Dipl.-Phys. Fabian Greffrath

Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
D-44780 Bochum

Telefon: +49 (0)234 / 32-26334
Fax: +49 (0)234 / 32-14227
E-Mail:  [EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Question about "time indices" during boot process with new (>= 2.6.25) kernel images

[Fabian Greffrath]

Dear Kernel-Maintainers,

since I have upgraded my linux-image package to 2.6.25, time indices 
appear in brackets at the beginning of each kernel message line during 
the boot process. I have never encountered these indices with previous 
kernels (< 2.6.25).


Are these indices displayed intentionally? I haven't found anything in 
the changelogs. If yes, what's the advantage of displaying them? I, 
personally, consider them ugly. ;)


Is this a new upstream feature or is it a Debian-specific change?

Thank you for your answers!

Cheers,
Fabian

--
Dipl.-Phys. Fabian Greffrath

Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
D-44780 Bochum

Telefon: +49 (0)234 / 32-26334
Fax: +49 (0)234 / 32-14227
E-Mail:  [EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#432817: acknowledged by developer (closing 425851)

[Fabian Greffrath]

You have closed #425851, which has been forcibly merged with my Report 
#432817. You have closed the former, because you consider it a bug in 
VMWare, and this led to the closure of my bug as well. However, I have 
not encountered this bug in a VMWare environment but on a real Computer!



Debian Bug Tracking System schrieb:

This is an automatic notification regarding your Bug report
#432817: Harddisc changed from /dev/hda to sda from 2.6.18,
which was filed against the linux-2.6 package.

It has been marked as closed by one of the developers, namely
Bastian Blank <[EMAIL PROTECTED]>.

You should be hearing from them with a substantive response shortly,
in case you haven't already. If not, please contact them directly.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


  



--
Dipl.-Phys. Fabian Greffrath

Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
D-44780 Bochum

Telefon: +49 (0)234 / 32-26334
Fax: +49 (0)234 / 32-14227
E-Mail:  [EMAIL PROTECTED]




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#432817: Harddisc changed from /dev/hda to sda from 2.6.18

[Fabian Greffrath]

Package: linux-image-2.6.21-2-k7
Version: 2.6.21-5
Severity: normal

--- Please enter the report below this line. ---

Dear Kernel-maintainers,

Today I tried to boot the new-in-testing linux-image-2.6.21-2-k7.
Before that I always booted linux-image-2.6.18-4-k7.

Unfortunately the boot process did not succeed, instead the following error 
message appeared:

Begin: Mounting root file system... ...
Begin: Running /scripts/localo-top ...
ide0: I/O resource 0x3F6-0x3F6 not free.
ide0: ports already in use, skipping probe
ide1: I/O resource 0x376-0x376 not free.
ide1: ports already in use, skipping probe
Done.
Begin: Waiting for root file system... ...

>From this point on, the harddisc was active, but the boot process did not 
>continue.

I found out that all I had to do was changing 'hda' into 'sda' in /etc/fstab 
and on the grub command line to boot this kernel.
Strangely the device names for my harddisc partitions seem to have changed from 
/dev/hda* to /dev/sda* during the kernel transition.
I consider this strange, because my machine has no SATA harddisc or similar 
(AFAICT), but only an ordinary IDE harddisc.

This is the output of lspci:

00:00.0 Host bridge: Silicon Integrated Systems [SiS] 746 Host (rev 10)
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SG86C202
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS963 [MuTIOL 
Media IO] (rev 25)
00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus 
Controller
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] 
AC'97 Sound Controller (rev a0)
00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 
Controller (rev 0f)
00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 
Controller (rev 0f)
00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 
Controller
00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 
PCI Fast Ethernet (rev 90)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 
Gigabit Ethernet (rev 10)
01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 
5200] (rev a1)

Problems like these should either be avoided or at least get documented 
somewhere.

Thanks for your effort!

Cheers,
Fabian

--- System information. ---
Architecture: i386
Kernel:   Linux 2.6.18-4-k7

Debian Release: lenny/sid
  500 testing ftp2.de.debian.org 
  400 unstableftp2.de.debian.org 

--- Package information. ---
Depends   (Version) | Installed
===-+-===
module-init-tools   (>= 0.9.13) | 3.3-pre11-1
initramfs-tools  (>= 0.55)  | 0.88
 OR yaird(>= 0.0.12-8)  | 
 OR linux-initramfs-tool| 




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#417995: initramfs-tools: lets ordinary users read the root filesystem's raw block device

[Fabian Pietsch]

Package: initramfs-tools
Version: 0.85f
Severity: critical
Tags: security patch
Justification: root security hole

A system that was booted from an initramfs created by initramfs-tools has
the following device node in the booted system's /dev:

| brw-r--r-- 1 root root 3, 7 Apr  6 00:38 /dev/root

This allows ordinary users to read the raw root filesystem, i.e.,
its block device. Bypassing the normal filesystem access restrictions
with this becomes easy through, e.g., /sbin/debugfs from e2fsprogs,
a "Priority: required" package. After reading /etc/shadow, passwords of
other accounts on the system may be cracked. Other authentication data
often is even unencrypted, like the boot loader password from
/etc/lilo.conf, which allows a local attacker to reboot with, e.g.,
init=/bin/bash, and take full control of the system.  

The device node is created prior to mounting the root filesystem, by a
script shared between initramfs generator and generated initramfs.
klibc-utils' mknod doesn't seem to support passing permissions on the
command line, so umask or chmod would be needed. For "BUSYBOX=y" in
/etc/initramfs-tools/initramfs.conf, after applying the following patch,
running "update-initramfs -u" and rebooting, the device node's permissions
are sane:

| brw--- 1 root root 3, 7 Apr  6 00:50 /dev/root

--- /usr/share/initramfs-tools/scripts/functions.orig
+++ /usr/share/initramfs-tools/scripts/functions
@@ -231,6 +231,7 @@
;;
esac
 
mknod /dev/root b ${major} ${minor}
+   chmod go-rw /dev/root
ROOT=/dev/root
 }


-- Package-specific info:
-- /proc/cmdline
auto BOOT_IMAGE=debian ro root=307 resume=/dev/hda4

-- /proc/filesystems
cramfs
ext3

-- lsmod
Module  Size  Used by
ipv6  226016  18 
button  6672  0 
ac  5188  0 
battery 9636  0 
nfs   202828  2 
lockd  54344  2 nfs
nfs_acl 3584  1 nfs
sunrpc138812  4 nfs,lockd,nfs_acl
dm_snapshot15552  0 
dm_mirror  19152  0 
dm_mod 50232  2 dm_snapshot,dm_mirror
r128   34816  0 
drm61332  1 r128
3c509  11828  0 
snd_ens137123616  1 
tsdev   7520  0 
gameport   14632  1 snd_ens1371
snd_ac97_codec 83104  1 snd_ens1371
snd_ac97_bus2400  1 snd_ac97_codec
snd_pcm_oss38368  0 
snd_mixer_oss  15200  2 snd_pcm_oss
snd_pcm68676  3 snd_ens1371,snd_ac97_codec,snd_pcm_oss
snd_seq_dummy   3844  0 
snd_seq_oss28768  0 
snd_seq_midi8192  0 
snd_rawmidi22560  2 snd_ens1371,snd_seq_midi
floppy 53156  0 
psmouse35016  0 
parport_pc 32132  0 
parport33256  1 parport_pc
snd_seq_midi_event  7008  2 snd_seq_oss,snd_seq_midi
snd_seq45680  6 
snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event
pcspkr  3072  0 
rtc12372  0 
serio_raw   6660  0 
snd_timer  20996  2 snd_pcm,snd_seq
snd_seq_device  7820  5 
snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq
bttv  159732  0 
video_buf  23012  1 bttv
firmware_class  9600  1 bttv
ir_common  27780  1 bttv
compat_ioctl32  1472  1 bttv
i2c_algo_bit8424  1 bttv
btcx_risc   4776  1 bttv
tveeprom   13840  1 bttv
videodev   21120  1 bttv
v4l1_compat12036  1 videodev
v4l2_common20448  2 bttv,videodev
snd47012  10 
snd_ens1371,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
soundcore   9248  2 snd
i2c_piix4   8140  0 
snd_page_alloc  9640  1 snd_pcm
i2c_core   19680  4 bttv,i2c_algo_bit,tveeprom,i2c_piix4
shpchp 33024  0 
intel_agp  21148  1 
pci_hotplug28704  1 shpchp
agpgart29896  2 drm,intel_agp
evdev   9088  0 
ext3  119240  2 
jbd52456  1 ext3
mbcache 8356  1 ext3
ide_generic 1408  0 [permanent]
ide_cd 36064  0 
cdrom  32544  1 ide_cd
ide_disk   14848  4 
piix9444  0 [permanent]
sis900 21760  0 
3c59x  40360  0 
mii 5344  2 sis900,3c59x
generic 5476  0 [permanent]
uhci_hcd   21164  0 
usbcore   112644  2 uhci_hcd
ide_core  110504  5 ide_generic,ide_cd,ide_disk,piix,generic
thermal13608  0 
processor  28840  1 thermal
fan 4804  0 

-- kernel-img.conf
# Kernel Image manageme

Bug#404478: linux-image-2.6.18-3-vserver-amd64: strange error messages and sporadic md-raid failures with sata_promise

[Fabian Fagerholm]

Package: linux-image-2.6.18-3-vserver-amd64
Version: 2.6.18-7
Severity: normal

I run an AMD64 box with two WDC WD1600JS-55NCB1 SATA drives. Every now 
and than, the machine logs lines like the following in the syslog:

Dec 25 09:15:11 xyz kernel: ata2: translated ATA stat/err 0x51/04 to SCSI 
SK/ASC/ASCQ 0xb/00/00
Dec 25 09:15:11 xyz kernel: ata2: status=0x51 { DriveReady SeekComplete Error }
Dec 25 09:15:11 xyz kernel: ata2: error=0x04 { DriveStatusError }

Also, lines like the following have appeared, though not as often:

Dec 25 09:15:07 xyz kernel: ATA: abnormal status 0x80 on port 0xC201C29C

The two drives are partitioned into four partitions, each set up as 
RAID-1 mirrors using MD (softraid). There are several LVM volumes 
on top of those mirrors. Every now and then, MD kicks out a partition 
from one of the mirrors. Which one gets kicked out, seems to be random. 
This has been going on for a few days, and seems to be related to 
increased activity.

S.M.A.R.T. claims the disks are fine (the overall test result is PASSED) 
except for one attribute, which I believe is related to temperature:
190 Unknown_Attribute   0x0022   049   010   045Old_age   Always 
In_the_past 51

The failure time is either In_the_past or FAILING_NOW, depending on the 
situation.

I've tried running badblocks with read-only test on the drives, and they 
show no errors. (I can't risk a write test on this machine.) I've 
re-added the failed partition and the RAID resync went fine.

The disk that gets kicked out of the RAID array is scheduled for 
replacement, but these symptoms seem to indicate more than just a failed 
disk -- heat problems, a disk controller failure, a kernel bug, or 
something. Other machines have had failed disks with similar symptoms, 
but those had S.M.A.R.T. status FAILED and were clear-cut cases.

The disk controller chipset is a PDC20319, and the machine runs 
sata_promise. Kernel etc. info below.

Please let me know what additional details are needed!

Thanks,
-- 
Fabian Fagerholm <[EMAIL PROTECTED]>

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-vserver-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages linux-image-2.6.18-3-vserver-amd64 depends on:
ii  coreutil 5.97-5  The GNU core utilities
ii  debconf  1.5.8   Debian configuration management sy
ii  e2fsprog 1.39+1.40-WIP-2006.11.14+dfsg-1 ext2 file system utilities and lib
ii  initramf 0.85c   tools for generating an initramfs
ii  module-i 3.3-pre3-1  tools for managing Linux kernel mo

Versions of packages linux-image-2.6.18-3-vserver-amd64 recommends:
ii  util-vserver  0.30.211-6 user-space tools for Linux-VServer

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#385397: i have the same problem

[Fabian Seither]

Hi,i can confirm this bug-report. I have exactly the same problem. xen boots (some xen-messages are displayed) and when the kernel should be loaded the machine just reboots.Fabian Seither

Bug#385397: i have the same problem

[Fabian Seither]

Hi,i can confirm this bug-report. I have exactly the same problem. xen boots (some xen-messages are displayed) and when the kernel should be loaded the machine just reboots.
Fabian Seither

-- Mit freundlichen Grüßen  Fabian Seither

Bug#321772: Module ns558 needs to be loaded twice to work properly

[Fabian Greffrath]

Hi!

I am sorry to tell you that the patches did not work with the current 
kernel-source-2.6.8 (2.6.8-16)!


I tried with both gcc-3.3 and gcc-3.4 and allways got the following 
error message from make-kpkg:


 CC [M]  drivers/input/gameport/ns558.o
drivers/input/gameport/ns558.c: In function `ns558_isa_probe':
drivers/input/gameport/ns558.c:145: warning: implicit declaration of 
function `kcalloc'
drivers/input/gameport/ns558.c:145: warning: assignment makes pointer 
from integer without a cast
drivers/input/gameport/ns558.c:146: warning: implicit declaration of 
function `gameport_allocate_port'
drivers/input/gameport/ns558.c:146: warning: assignment makes pointer 
from integer without a cast
drivers/input/gameport/ns558.c:151: warning: implicit declaration of 
function `gameport_free_port'
drivers/input/gameport/ns558.c:161: warning: implicit declaration of 
function `gameport_set_name'
drivers/input/gameport/ns558.c:162: warning: implicit declaration of 
function `gameport_set_phys'

drivers/input/gameport/ns558.c: In function `ns558_pnp_probe':
drivers/input/gameport/ns558.c:218: warning: assignment makes pointer 
from integer without a cast
drivers/input/gameport/ns558.c:219: warning: assignment makes pointer 
from integer without a cast
drivers/input/gameport/ns558.c:234: error: request for member `parent' 
in something not a structure or union

make[3]: *** [drivers/input/gameport/ns558.o] Error 1
make[2]: *** [drivers/input/gameport] Error 2
make[1]: *** [drivers] Error 2
make[1]: Leaving directory `/usr/src/kernel-source-2.6.8'
make: *** [stamp-build] Error 2

I do not know if it is my fault, but I did not get it compiled at all 
after applying the patches.
By the way, I had to apply the patches in the order ns558-pnp.diff 
first, ns558-load.diff second,

else `patch` would tell me

patching file ns558.c
Hunk #1 FAILED at 258.
1 out of 1 hunk FAILED -- saving rejects to file ns558.c.rej

I would appreciate if you could build a kernel-image for me, so I could 
test it on my PC at home.

I was not able to make one myself... *shame* :(

Thank you in advance! ;)

Nice greetings,
Fabian




I strongly suspect that this patch fixes this problem
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f6397cecadc52779902bdd8f8cd3ea5af3a19ad1

That patch also depends on this patch, which 
seems to fix some more insmod/rmmod nastiness

http://www.kernel.org/git/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=blobdiff;h=7c5c6318eeb9ffad3b1798fca4e1a13b8239689e;hp=f31ce0bad57942b7a66f01540b3816ed2ced8762;hb=913a66fbd55ce7ed0191d267306d6fa3181d98b1;f=drivers/input/gameport/ns558.c

I've attached thes second patches as ns558-load.diff and
the first patch as  ns558-pnp.diff. (They need to be
applied in that order). If I make images are you in a position
to test them. Alternatively, you could try 
linux-image-2.6.12-1-k7 image from unstable.


 




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#321772: Module ns558 needs to be loaded twice to work properly

[Fabian Greffrath]

Package: kernel-image-2.6.8-2-k7
Version: 2.6.8-16

I am filing this bug against this specific kernel version, although I do 
not know, if other kernel versions are affected, too!


My system consists of an ASUS A7N8X (Targa Edition, Rev 1.04, Bios 1028) 
running a nForce2 chipset.

There is a Gravis Gamepad Pro (Rev 4) connected to the board's gameport.

I have the modules "joydev" and "grip" loaded, "analog" is not loaded.


This is what I have to do to get the gameport working:

# modprobe -v ns558
insmod /lib/modules/2.6.8-2-k7/kernel/drivers/input/gameport/ns558.ko

#dmesg
(...)
input: Gravis GamePad Pro on isa0201/gameport0
gameport: NS558 ISA at 0x201 speed 685 kHz
pnp: Device 00:11 disabled.
ns558: probe of 00:11 failed with error -16

-> this is quite strange, because the gameport chipset (ns558) ist the 
isapnp version!


# ls /dev/input/js*
ls: /dev/input/js*: No such file or directory

# modprobe -vr ns558
rmmod /lib/modules/2.6.8-2-k7/kernel/drivers/input/gameport/ns558.ko

# modprobe -v ns558
insmod /lib/modules/2.6.8-2-k7/kernel/drivers/input/gameport/ns558.ko

#dmesg
(...)
pnp: Device 00:11 activated.
input: Gravis GamePad Pro on pnp00:11/gameport0
gameport: NS558 PnP at pnp00:11 io 0x201 speed 685 kHz

# ls /dev/input/js*
/dev/input/js0


So I have to insmod, rmmod and insmod again the module "ns558" in order 
to get it working properly!


BTW: He seems to have just the same problem: 
http://lists.debian.org/debian-user/2005/02/msg03092.html




Nice Greetings,
Fabian




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#272519: kernel-image-2.6.8-1-686: Confirming report

[Fabian Fagerholm]

Tried with acpi=off and noapic, neither helped. Downgrading to 2.6.7
works.

-- 
Fabian Fagerholm <[EMAIL PROTECTED]>

Bug#272519: kernel-image-2.6.8-1-686: Confirming report

[Fabian Fagerholm]

Package: kernel-image-2.6.8-1-686
Version: 2.6.8-3
Followup-For: Bug #272519

I have an Inspiron 8000, and I'm seeing similar behaviour. Mostly the hang
seems to happen immediately after the partition check.

If I can make it work, I'll post the details here. Otherwise, consider this
a confirmation of the problem.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.0-test9
Locale: LANG=C, LC_CTYPE=C

Versions of packages kernel-image-2.6.8-1-686 depends on:
ii  coreutils [fileutils] 5.2.1-2The GNU core utilities
ii  fileutils 5.2.1-2The GNU file management utilities 
ii  initrd-tools  0.1.74 tools to create initrd image for p
ii  module-init-tools 3.1-pre5-7 tools for managing Linux kernel mo

-- no debconf information