Bug#1069598: cifs-utils: When mounting a samba-share by a client with kernel 6.1.0-20-amd64, some subdirectories and files within the mounted share are missing

[Bernhard Übelacker]

Hello,
this seems to be the same issue as here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069102
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069092

And the fix seems to be prepared here:
https://salsa.debian.org/kernel-team/linux/-/commit/37a0ac93027302ffbfae41ddc844312e88e72eef

Kind regards,
Bernhard

Bug#1032642: iproute2: ip tunnel change ip6gre to gre crashes with stack smash

[Bernhard Übelacker]

Dear Maintainer,
I tried to find out where exactly the stack smashing takes place.
And found the ioctl SIOCCHGTUNNEL did write more than the 52 bytes
allocated in variable old_p, by that overwriting the stack canary.

Kind regards,
Bernhard


(gdb)
0x5557589f  62  {
1: x/i $pc
=> 0x5557589f :  mov%fs:0x28,%rax
(gdb)
0x555758a8  62  {
1: x/i $pc
=> 0x555758a8 :  mov%rax,0x68(%rsp)
(gdb) print/x $rax
$1 = 0xbf9b77d893accd00
(gdb) print/x $rsp + 0x68
$2 = 0x7fffea28


(gdb)
0x77e575f5  120 in ../sysdeps/unix/syscall-template.S
1: x/i $pc
=> 0x77e575f5 :syscall
2: /x *(uint64_t*)0x7fffea28 = 0xbf9b77d893accd00
(gdb) bt
#0  0x77e575f5 in ioctl () at ../sysdeps/unix/syscall-template.S:120
#1  0x55578230 in tnl_get_ioctl (basedev=0x7fffee8f "gre1", 
p=) at tunnel.c:77
#2  0x55576243 in parse_args (argc=9, argv=0x7fffec50, cmd=35315, 
p=0x7fffea70) at iptunnel.c:181
#3  0x555762fb in do_add (cmd=35315, argc=, argv=) at iptunnel.c:260
#4  0x5556258b in do_cmd (argv0=0x7fffee81 "tunnel", argc=11, 
argv=0x7fffec40) at ip.c:133
#5  0x55561fc2 in main (argc=12, argv=0x7fffec38) at ip.c:344
(gdb) stepi
0x77e575f7  120 in ../sysdeps/unix/syscall-template.S
1: x/i $pc
=> 0x77e575f7 :cmp$0xf001,%rax
2: /x *(uint64_t*)0x7fffea28 = 0x200

(gdb) print _p
$7 = (struct ip_tunnel_parm *) 0x7fffe9f0
(gdb) print sizeof(old_p)
$8 = 52
(gdb) print/x 0x7fffe9f0 + 52
$9 = 0x7fffea24

(gdb) list iptunnel.c:181
178 if (cmd == SIOCCHGTUNNEL && count == 0) {
179 struct ip_tunnel_parm old_p = {};
180
181 if (tnl_get_ioctl(*argv, _p))
182 return -1;

Bug#1028309: linux-image-6.0.0-6-amd64: Regression in Kernel 6.0: System partially freezes with "nvme controller is down"

[Bernhard Übelacker]

On Thu, 12 Jan 2023 18:31:37 + =?UTF-8?Q?Julian_Gro=c3=9f?= 
 wrote:
My computer just froze on Kernel version 5.19.11-1. Though nothing got 
logged.
Now I don't know if this is the same issue and newer kernels just behave 
better in terms of logging, or if this is a different issue..


I guess I will add a second screen to my computer, open journalctl on 
there, and point a camera at it to capture the issue.


Hello Julian,
Capturing with a camera might be possible.
But if you have a serial port at the target machine,
another capturing system available, and a cable connecting them,
it might be more convenient to capture the output from the serial port,
to have it in text form.


Below links show the kernel parameters at the target machine:
https://wiki.archlinux.org/title/working_with_the_serial_console#Kernel

And at the capturing machine you could start "script", that would
record all that happens to a file "typescript" in the current directory,
and inside start "screen" to the other machine like here:
https://wiki.archlinux.org/title/working_with_the_serial_console#Screen


If the machine is still kind of responsive then it might also be possible
to capture through a network connection via "netconsole", more details
in following link:
https://wiki.ubuntu.com/Kernel/Netconsole

Kind regards,
Bernhard

Bug#989010: linux-image-5.10.0-7-amd64: No display (post, grub, boot messages and desktop) after the upgrade to 5.10.38

[Bernhard Übelacker]

Hello Jim,
I am not involved in packaging, but came to this report by chance.



The attached file contains all the changes you devs have made in the kernel
configs from 5.10.28 (-6 package) to 5.10.38/.40 (-7 package). It was made with
meld.
~10 kernel parameters have changed and led to this mess, so I assume it would
be trivial for you to find the faulty one.


These parameters are not all that changed - there are around 1400 patches
added upstream to the kernel between v5.10.28 and v5.10.38.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=v5.10.38


Kind regards,
Bernhard

Bug#943398: Closing this bug (BTS maintenance for src:linux bugs)

[Bernhard Übelacker]

Hello,
just for the record.
Upstream seems to have fixed this in [1] which
is included in kernel v5.8 and later.

Kind regards,
Bernhard

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/tools/perf/ui/browsers/hists.c?id=d61cbb859b45fdb6b4997f2d51834fae41af0e94

Bug#869684: linux-image-4.9.0-3-686-pae: Thinkpad T60 hangs on resume after suspend to disk; regress since Debian 8

[Bernhard Übelacker]

Control: fixed -1 linux/5.10.28-1


Dear Maintainer,
I got that Thinkpad T60 back, and did upgrade
the installation to bullseye.

I can now confirm that the nokaslr workaround is not
needed any more, hibernate and resume is working for
me with current kernel 5.10.0-6-686-pae/5.10.28-1 in testing.

Unfortunately I did not check if buster kernel already would
have worked without the nokaslr parameter.

I hope it is ok to mark it fixed for current version.

Kind regards,
Bernhard

Bug#979340: nouveau: Suspend hangs for 5 minutes before completing

[Bernhard Übelacker]

Dear Maintainer,
just a side note:
The visible segfaults might be related to #977945.
Unknown if they have any effect on suspending.

Kind regards,
Bernhard

Bug#983934: linux-image-5.3.0-3-amd64: guest kernel fails inside qemu VM with qxl displays (BUG: unable to handle page fault)

[Bernhard Übelacker]

Dear Maintainer,
I investigated a bit further and came across this document [1].
There it is stated that in Linux usually a single qxl device with
multiple outputs [2] is used and in Windows multiple qxl devices with
a single output each [3].

Using with a Linux guest the suggested multiple outputs of a single
qxl device does not produce the kernel oops and works perfect.

This kernel issue is just visible with multiple qxl devices and a Linux guest,
therefore is kind of an unusual setup, nevertheless was not causing
this kernel oops up until 5.2 and fails afterwards.

Kind regards,
Bernhard

[1] https://www.spice-space.org/multiple-monitors.html, paragraph "Spice 
Protocol"

[2] QEmu parameter: "... -device qxl-vga,max_outputs=4,... ..."
[3] QEmu parameter: "... -device qxl-vga   -device qxl ..."



As a side note:
In my tests with multiple qxl devices and watching the Linux guest
with remote-viewer the mouse pointer was always stuck at one position.

Debugging remote-viewer/Qemu shows that if multiple qxl devices are used,
the mouse mode gets set to "server", therefore no absolute
but just relative mouse movements get sent to the VM.
My guess is that the guest qxl driver on Linux does
currently not implement that mode.
spice-0.14.3/server/reds.c:640, reds_update_mouse_mode:
SPICE_MOUSE_MODE_CLIENT / SPICE_MOUSE_MODE_SERVER

Bug#932250: random segfaults

[Bernhard Übelacker]

Hello Paul,
is it possible to install the package systemd-coredump on
the systems showing this crash?

Then after the next crash in the output of 'journalctl --no-pager'
should the segfault appear followed by a backtrace
that you could forward to this bug.

This should clarify which function calls lead to the crash.

More information on improving that information additionally
are here: https://wiki.debian.org/HowToGetABacktrace

Kind regards,
Bernhard

Bug#964181: linux-image-4.19.0-9-amd64: Unable to get battery status

[Bernhard Übelacker]

Dear Maintainer,
this bug sounds similar to this one:
https://bugs.debian.org/927163

Kind regards,
Bernhard

Bug#962372: linux-image-5.7.0-rc5-amd64: Silead module not installed

[Bernhard Übelacker]

Dear Maintainer,
bug #925424 seems to be about the same issue.

Kind regards,
Bernhard

Bug#955407: linux-image-4.19.0-8-amd64: "Uhhuh. NMI received for unknown reason" on AMD Ryzen

[Bernhard Übelacker]

Dear Maintainer,
I observed such logging, too. My system is similar to the submitters one.
Found two occourences in still available kern.log* files. (See attached file.)

One was most probably related to a "GPU fault" 25 seconds before,
running 4.19.0-8-amd64/4.19.98-1.

The other was while not being at the idling system,
running 5.4.0-0.bpo.3-amd64/5.4.13-1~bpo10+1.
No negative consequence found at that time.

Kind regards,
Bernhard
# LANG=C lscpu
...
CPU family:  23
Model:   1
Model name:  AMD Ryzen 7 1700 Eight-Core Processor
Stepping:1
...


# (zcat kern.log.4.gz kern.log.3.gz kern.log.2.gz; cat kern.log.1 kern.log) | grep -E "NMI received|Linux version" -A3

Mar  7 00:10:29 rechner kernel: [0.00] Linux version 4.19.0-8-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.98-1 (2020-01-26)
...
Mar  7 00:10:29 rechner kernel: [0.00] DMI: System manufacturer System Product Name/PRIME B350M-A, BIOS 4801 04/25/2019
...
Mar  7 00:13:49 rechner kernel: [  205.788363] amdgpu :08:00.0: GPU fault detected: 147 0x0c304401 for process SOTTR.exe pid 3426 thread SOTTR.exe:cs0 pid 3448
Mar  7 00:13:49 rechner kernel: [  205.788370] amdgpu :08:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0FF22786
Mar  7 00:13:49 rechner kernel: [  205.788373] amdgpu :08:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0E044001
Mar  7 00:13:49 rechner kernel: [  205.788378] amdgpu :08:00.0: VM fault (0x01, vmid 7, pasid 32782) at page 267528070, read from 'TC1' (0x54433100) (68)
...
Mar  7 00:13:49 rechner kernel: [  205.788463] amdgpu :08:00.0: VM fault (0x01, vmid 7, pasid 32782) at page 142747517, read from 'TC1' (0x54433100) (68)
Mar  7 00:13:59 rechner kernel: [  215.998608] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=25858, emitted seq=25860
Mar  7 00:13:59 rechner kernel: [  215.998615] [drm] GPU recovery disabled.
Mar  7 00:14:14 rechner kernel: [  230.580910] Uhhuh. NMI received for unknown reason 2d on CPU 7.
Mar  7 00:14:14 rechner kernel: [  230.580911] Do you have a strange power saving mode enabled?
Mar  7 00:14:14 rechner kernel: [  230.580914] Dazed and confused, but trying to continue
Mar  7 00:15:17 rechner kernel: [  294.139939] sysrq: SysRq : Keyboard mode set to system default
Mar  7 00:15:20 rechner kernel: [  296.891922] sysrq: SysRq : Terminate All Tasks

(attempt to test Shadow of the Tomb Raider Trial via Steam, kernel crash dump available, at least the "GPU fault" was reproducible.)

--

Mar 26 10:00:52 rechner kernel: [0.00] Linux version 5.4.0-0.bpo.3-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 5.4.13-1~bpo10+1 (2020-02-07)
...
Mar 26 10:00:52 rechner kernel: [0.00] DMI: System manufacturer System Product Name/PRIME B350M-A, BIOS 4801 04/25/2019
...
Mar 29 07:27:08 rechner kernel: [246383.312487] Uhhuh. NMI received for unknown reason 3c on CPU 6.
Mar 29 07:27:08 rechner kernel: [246383.312488] Do you have a strange power saving mode enabled?
Mar 29 07:27:08 rechner kernel: [246383.312489] Dazed and confused, but trying to continue
Mar 29 07:35:37 rechner kernel: [246892.656398] Process accounting resumed

(system was at this time idle, no negative consequences recognized, system could be shutdown later without problems.)

Bug#949631: linux-image-4.19.0-7-amd64: refcount_t: underflow; use-after-free. Followed by: list_del corruption. next->prev should be

[Bernhard Übelacker]

Dear Maintainer,
crash happened again today when stopping a qemu VM with
the quit command at the qemu prompt.

Found the "refcount_t: underflow" already once at 2020-01-07,
but there the system could continue to run more than a day.

All occourences are with:
[0.00] Linux version 4.19.0-7-amd64 (debian-kernel@lists.debian.org) 
(gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.87-1 (2019-12-03)

Kind regards,
Bernhard
[0.00] Linux version 4.19.0-7-amd64 (debian-kernel@lists.debian.org) 
(gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.87-1 (2019-12-03)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-7-amd64 
root=UUID=64e985dd-8bd3-4051-82a4-a01577abbed4 ro crashkernel=384M-:128M
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'compacted' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0fff] reserved
[0.00] BIOS-e820: [mem 0x1000-0x0008] usable
[0.00] BIOS-e820: [mem 0x0009-0x00090fff] type 20
[0.00] BIOS-e820: [mem 0x00091000-0x0009] usable
[0.00] BIOS-e820: [mem 0x000a-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x09e0] usable
[0.00] BIOS-e820: [mem 0x09e1-0x09ff] reserved
[0.00] BIOS-e820: [mem 0x0a00-0x0a1f] usable
[0.00] BIOS-e820: [mem 0x0a20-0x0a20afff] ACPI NVS
[0.00] BIOS-e820: [mem 0x0a20b000-0x0aff] usable
[0.00] BIOS-e820: [mem 0x0b00-0x0b01] reserved
[0.00] BIOS-e820: [mem 0x0b02-0xd18acfff] usable
[0.00] BIOS-e820: [mem 0xd18ad000-0xd18d9fff] ACPI data
[0.00] BIOS-e820: [mem 0xd18da000-0xda732fff] usable
[0.00] BIOS-e820: [mem 0xda733000-0xda898fff] reserved
[0.00] BIOS-e820: [mem 0xda899000-0xda8b9fff] ACPI data
[0.00] BIOS-e820: [mem 0xda8ba000-0xdacc2fff] usable
[0.00] BIOS-e820: [mem 0xdacc3000-0xdad87fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xdad88000-0xdbaa3fff] reserved
[0.00] BIOS-e820: [mem 0xdbaa4000-0xdbb44fff] type 20
[0.00] BIOS-e820: [mem 0xdbb45000-0xddff] usable
[0.00] BIOS-e820: [mem 0xde00-0xdfff] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfd10-0xfd1f] reserved
[0.00] BIOS-e820: [mem 0xfea0-0xfea0] reserved
[0.00] BIOS-e820: [mem 0xfeb8-0xfec01fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
[0.00] BIOS-e820: [mem 0xfec3-0xfec30fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved
[0.00] BIOS-e820: [mem 0xfed4-0xfed44fff] reserved
[0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved
[0.00] BIOS-e820: [mem 0xfedc2000-0xfedc] reserved
[0.00] BIOS-e820: [mem 0xfedd4000-0xfedd5fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfeef] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00041f37] usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.60 by American Megatrends
[0.00] efi:  ACPI 2.0=0xd18ad000  ACPI=0xd18ad000  SMBIOS=0xdba12000  
SMBIOS 3.0=0xdba11000  ESRT=0xd8841a98  MEMATTR=0xd80dc018 
[0.00] secureboot: Secure boot could not be determined (mode 0)
[0.00] SMBIOS 3.1.1 present.
[0.00] DMI: System manufacturer System Product Name/PRIME B350M-A, BIOS 
4801 04/25/2019
[0.00] tsc: Fast TSC calibration failed
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] last_pfn = 0x41f380 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-B write-through
[0.00]   C-D uncachable
[0.00]   E-F write-protect
[0.00] MTRR variable 

Bug#943398: linux-perf-5.2: perf report segmentation fault

[Bernhard Übelacker]

Control: forwarded -1 https://marc.info/?l=linux-kernel=157973791626377=2
Control: tags -1 + upstream


Hello Salvatore,
thanks for the link.
I tried to get in contact with upstream.

Kind regards,
Bernhard

https://www.spinics.net/lists/kernel/msg3384013.html
https://marc.info/?l=linux-kernel=157973791626377=2

Bug#943398: linux-perf-5.2: perf report segmentation fault

[Bernhard Übelacker]

Hello Salvatore,

> Can you report the issue directly upstream?
Will do, but I am not sure exactly to where.

I found the MAINTAINERS file and I guess if there
is no "B:" line it has to be reported to the "L:" list ?

Kind regards,
Bernhard

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS#n12936

Bug#943398: linux-perf-5.2: perf report segmentation fault

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce using linux-perf-5.2 and it is
also visible in linux-perf-5.4 5.4.8-1,
by just pressing enter.

The crash happens because in line 3172
function hist_browser__selected_entry returns
browser->he_selection, which is at this time a
null pointer.
This null pointer gets dereferenced to
access the res_samples member.

Upstream seems to have fixed other occourences [1]
of browser->he_selection being null, but this is
already contained in 5.4 while a crash still happens.

Kind regards,
Bernhard



Program received signal SIGSEGV, Segmentation fault.
(rr) bt
#0  perf_evsel__hists_browse (evsel=0x55e794ebcb40, 
nr_events=nr_events@entry=1, helpline=helpline@entry=0x55e794f7c040 "Tip: 
System-wide collection from all CPUs: perf record -a", 
left_exits=left_exits@entry=false, hbt=hbt@entry=0x0, min_pcnt=, 
env=env@entry=0x55e794eb54f0, warn_lost_event=true, 
annotation_opts=0x7ffcc3063dc8) at ui/browsers/hists.c:3170
#1  0x55e79385cce9 in perf_evlist__tui_browse_hists 
(evlist=evlist@entry=0x55e794ebc0c0, help=help@entry=0x55e794f7c040 "Tip: 
System-wide collection from all CPUs: perf record -a", hbt=hbt@entry=0x0, 
min_pcnt=, env=env@entry=0x55e794eb54f0, 
warn_lost_event=warn_lost_event@entry=true, 
annotation_opts=annotation_opts@entry=0x7ffcc3063dc8) at 
ui/browsers/hists.c:3422
#2  0x55e7936f1ece in report__browse_hists (rep=0x7ffcc3063c30) at 
builtin-report.c:585
#3  __cmd_report (rep=0x7ffcc3063c30) at builtin-report.c:930
#4  cmd_report (argc=, argv=) at 
builtin-report.c:1475
#5  0x55e79375b823 in run_builtin (p=0x55e793a9ef90 , argc=2, 
argv=0x7ffcc30661f0) at perf.c:312
#6  0x55e7936d6a2c in handle_internal_command (argv=, 
argc=) at perf.c:364
#7  run_argv (argcp=, argv=) at perf.c:408
#8  main (argc=2, argv=0x7ffcc30661f0) at perf.c:538


https://sources.debian.org/src/linux/5.4.8-1/tools/perf/ui/browsers/hists.c/#L2217
2217 static struct hist_entry *hist_browser__selected_entry(struct 
hist_browser *browser)
2218 {
2219return browser->he_selection;
2220 }

https://sources.debian.org/src/linux/5.4.8-1/tools/perf/ui/browsers/hists.c/#L3170
3170nr_options += add_res_sample_opt(browser, 
[nr_options],
3171 [nr_options],
3172 
hist_browser__selected_entry(browser)->res_samples,
3173 evsel, A_NORMAL);


[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/tools/perf/ui/browsers/hists.c?id=ceb75476db1617a88cc29b09839acacb69aa076e

# Bullseye/testing amd64 qemu VM 2020-01-13


apt update
apt dist-upgrade


apt install systemd-coredump mc colorized-logs gdb rr linux-perf-5.4 
linux-perf-5.4-dbgsym


perf record ls
perf report perf.data
# Press enter


###



# 5.2.17-1+b1


wget 
https://snapshot.debian.org/archive/debian/20191006T205801Z/pool/main/l/linux/linux-perf-5.2_5.2.17-1%2Bb1_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20191006T205801Z/pool/main/l/linux/linux-image-5.2.0-3-amd64-unsigned_5.2.17-1%2Bb1_amd64.deb
wget 
https://snapshot.debian.org/archive/debian-debug/20191006T210740Z/pool/main/l/linux/linux-perf-5.2-dbgsym_5.2.17-1%2Bb1_amd64.deb

dpkg -i linux-image-5.2.0-3-amd64-unsigned_5.2.17-1+b1_amd64.deb 
linux-perf-5.2_5.2.17-1+b1_amd64.deb

reboot


root@debian:~# uname -a
Linux debian 5.2.0-3-amd64 #1 SMP Debian 5.2.17-1 (2019-10-06) x86_64 GNU/Linux

root@debian:~# perf record ls
...
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0,009 MB perf.data (2 samples) ]

root@debian:~# perf report perf.data
perf: Speicherzugriffsfehler
 backtrace 
perf_5.2(+0x322d14)[0x5631251b2d14]
/lib/x86_64-linux-gnu/libc.so.6(+0x3a0ff)[0x7f88ec6ee0ff]
perf_5.2(+0x32021e)[0x5631251b021e]
perf_5.2(+0x3211c8)[0x5631251b11c8]
perf_5.2(+0x1bb4f5)[0x56312504b4f5]
perf_5.2(+0x222072)[0x5631250b2072]
perf_5.2(+0x1a0a13)[0x563125030a13]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f88ec6dabba]
perf_5.2(+0x1a0c69)[0x563125030c69]



root@debian:~# gdb -q --args perf_5.2 report perf.data
Reading symbols from perf_5.2...
(No debugging symbols found in perf_5.2)
(gdb) set width 0
(gdb) set pagination off
(gdb) run
...
rogram received signal SIGSEGV, Segmentation fault.
   0x5587421e in ?? ()
(gdb) bt
#0  0x5587421e in ?? ()
#1  0x558751c9 in ?? ()
#2  0x5570f4f6 in ?? ()
#3  0x55776073 in ?? ()
#4  0x556f4a14 in ?? ()
#5  0x7758abbb in __libc_start_main (main=0x556f43b0, argc=3, 
argv=0x7fffecf8, init=, fini=, 
rtld_fini=, stack_end=0x7fffece8) at ../csu/libc-start.c:308
#6  0x556f4c6a in ?? ()
(gdb) generate-core /root/core-perf_5.2
warning: target file /proc/800/cmdline contained unexpected null characters
Saved corefile /root/core-perf_5.2

root@debian:~# dpkg -i 

Bug#932550: qemu-system-x86: WinXP no longer boots with --enable-kvm, stops at \Windows\System32\Drivers\Mup.sys

[Bernhard Übelacker]

fixed 932550 4.19.67-1

Bug#934979: debian 10 main after turning on computer resuming from hibernation displays

[Bernhard Übelacker]

Hello,
maybe the following report is related:

https://bugs.debian.org/928736

Kind regards,
Bernhard

Bug#934304: linux-image-5.2.0-2-amd64: powertop aborts on version 5.2

[Bernhard Übelacker]

Dear Maintainer,
this issue seems to start since patch:

features/all/lockdown/0031-tracefs-Restrict-tracefs-when-the-kernel-is-locked-d.patch

Therefore a vanialla build does not show this issue.

With either of the following changes on top of all
debian patches, the exception does not happen.

But the first does also prevent opening the file
when not locked down.

The second allows to open the file, but cannot say
if the intended effect of the patch for lockdowned
kernels is still given.

Kind regards,
Bernhard



diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
index 338c791c9a0e..f446977bf9c8 100644
--- a/fs/tracefs/inode.c
+++ b/fs/tracefs/inode.c
@@ -41,6 +41,8 @@ static int default_open_file(struct inode *inode, struct file 
*filp)
return -EPERM;
 
real_fops = dentry->d_fsdata;
+   if (!real_fops->open)
+   return -EINVAL;
return real_fops->open(inode, filp);
 }
 



diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
index 338c791c9a0e..d37c959291ab 100644
--- a/fs/tracefs/inode.c
+++ b/fs/tracefs/inode.c
@@ -438,7 +438,7 @@ struct dentry *tracefs_create_file(const char *name, 
umode_t mode,
 
dentry->d_fsdata = (void *)fops;
memcpy(proxy_fops, fops, sizeof(*proxy_fops));
-   proxy_fops->open = default_open_file;
+   proxy_fops->open = fops->open ? default_open_file : NULL;
inode->i_mode = mode;
inode->i_fop = proxy_fops;
inode->i_private = data;

Bug#934304: linux-image-5.2.0-2-amd64: powertop aborts on version 5.2

[Bernhard Übelacker]

Control: found -1 linux/5.2.6-1


Dear Maintainer,
the bugreport https://bugs.debian.org/934292
seems about the same issue.

The issue can be reproduced by just accessing the file below.


root@debian:~# strace -f powertop
execve("/usr/sbin/powertop", ["powertop"], 0x7fff5df92d08 /* 11 vars */) = 0
brk(NULL)   = 0x56055fbf3000
...
openat(AT_FDCWD, "/sys/kernel/debug/tracing/events/power/cpu_idle/id", 
O_RDONLY) = ?
+++ killed by SIGKILL +++
Getötet

root@debian:~# cat /sys/kernel/debug/tracing/events/power/cpu_idle/id
Getötet


Issue can not be seen in 5.0.2-1~exp1, appeared in 5.2.6-1.

Kind regards,
Bernhard

Bug#932250: linux-image-amd64: random segfaults without taking something down

[Bernhard Übelacker]

Hello,
the information might not yet be enough for
the maintainers to help.

Maybe you could install the package systemd-coredump.
In the output of 'journalctl --no-pager' should then
the segfaults appear too, followed by a backtrace
that you could forward to this bug.

Kind regards,
Bernhard

Bug#927163: linux-image-4.19.0-4-amd64: Missing modules for AXP288 power fuel gauge driver

[Bernhard Übelacker]

Hello Marcus Lundblad,
I don't know if it is related - I own a Baytrail
device that contains also these axp devices.
Back in late 2017 I got some help from Hans de Goede,
who worked that time in that area.
There my battery information was also missing with
the stock debian kernel.

He suggested to build a kernel with the config from a
"v4.14-footrail" branch from following repo first.
 https://github.com/jwrdegoede/linux-sunxi/

I could reduce the differences to following:

#Note on x86 this provides an ACPI OpRegion, so this must be 'y'
#(builtin) and not a module, as the OpRegion must be available as
#soon as possible. For the same reason the I2C bus driver options
#I2C_DESIGNWARE_PLATFORM and I2C_DESIGNWARE_BAYTRAIL must be 'y' too.
#I2C_DESIGNWARE_PLATFORM=y
#I2C_DESIGNWARE_BAYTRAIL=y
#MFD_AXP20X_I2C=y

Could this be relevant for Cherrytrail too?

Kind regards,
Bernhard

Bug#921114: amdgpu: The CS has been cancelled because the context is lost.

[Bernhard Übelacker]

Hello Jean-Dominique Frattini,
I am not involved in packaging any of these packages,
but I noted that you opened the last three days nearly
the same issue against three different packages?
What are you trying to achive that way?
And you noted versions contained in current Buster,
but you claim it is Stretch?
You write it is a regression - do you know the package
versions or the date when it was working like expected?
Also giving an example application that triggers that
error message could maybe make the bug report more
attractive to get some one having the matching hardware
looking at it.

Kind regards,
Bernhard

Bug#920607: Debian Buster installer on qnap ts-21x / Fujitsu Q700 : /dev/mtdblock* missing

[Bernhard Übelacker]

Hello Everyone,
I also tried to install current testing to a qnap ts-119P II.

On Tue, 29 Jan 2019 21:43:50 +0100 =?UTF-8?Q?Uwe_Kleine-K=c3=b6nig?= 
 wrote:
> On 1/27/19 12:13 PM, Lukas Straub wrote:
> > Package: linux
> > Version: 4.19.12-1
> > 
> > Hello Everyone,
> > I tried the latest Buster Installer on my Fujitsu Q700 (rebranded
> > qnap ts-21x) and Everything works except that /dev/mtdblock* devices
> > are missing so flashing the kernel and initrd fails.
> 
> I see the spi-orion-Driver is not loaded. Does /dev/mtd* appear if you do
> 
>   modprobe spi-orion
>   modprobe m25p80

Unfortunately I found just the m25p80.ko right after boot,
the spi-orion.ko is missing.
Should that be downloaded by the installer later or
already included in the initrd?

By following commands one should be able to get the
missing spi-orion.ko for the debian installer from 20190118:

cd $(mktemp -d)
wget 
http://deb.debian.org/debian/pool/main/l/linux/linux-image-4.19.0-1-marvell_4.19.12-1_armel.deb
udpkg --unpack linux-image-4.19.0-1-marvell_4.19.12-1_armel.deb
depmod -a

modprobe spi-orion
modprobe m25p80

And after that dmesg got following additional lines:

...
[ 1112.557570] m25p80 spi0.0: m25p128 (16384 Kbytes)
[ 1112.56] 6 fixed-partitions partitions found on MTD device spi0.0
[ 1112.567783] Creating 6 MTD partitions on "spi0.0":
[ 1112.567793] 0x-0x0008 : "U-Boot"
[ 1112.568533] 0x0020-0x0040 : "Kernel"
[ 1112.569407] 0x0040-0x00d0 : "RootFS1"
[ 1112.569653] 0x00d0-0x0100 : "RootFS2"
[ 1112.569877] 0x0008-0x000c : "U-Boot Config"
[ 1112.570090] 0x000c-0x0020 : "NAS Config"

After that I could successfully finish a buster installation,
and boot the installed system.

If there is something more to test I have the serial console
connected and it is not yet in "production".

Kind regards,
Bernhard

Bug#919290: SMB2_close_free: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000

[Bernhard Übelacker]

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

Dear Maintainer,

I received following crash while having a cifs filesystem mounted
from a qemu VM running on the same host.
Unfortunately forgot to unmount and shut down the VM.
Then after some minutes system froze and restarted.

If it may be important, the mount commmand was:
mount -t cifs -o 
user=Benutzer1,pass=test,port=4445,uid=1000,gid=1000,vers=3.0,noserverino 
//127.0.254.55/C share
That port is a forward on the qemu command line:
...hostfwd=tcp:127.0.254.55:4445-:445...


kdump-tools are installed and collected a core.


Upstream has following bug that looks quite similar [1], and
[2] on the mailing list.
Last year I experienced a crash also related to SMB2 that
may be related that I just reported upstream [3].

Upstream linux-4.20.y contains patch [4] that seems related.


Kind regards,
Bernhard


[1] https://bugzilla.kernel.org/show_bug.cgi?id=202223
[2] https://lkml.org/lkml/2018/10/23/702
[3] https://bugzilla.kernel.org/show_bug.cgi?id=200907
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/cifs/smb2pdu.c?id=32a1fb36f6e50183871c2c1fcf5493c633e84732


# ls -lisah /var/crash/201901141532/*
2904688  80K -rw-r--r-- 1 root root  78K Jan 14 15:32 
/var/crash/201901141532/dmesg.201901141532
2904805 158M -rw-r--r-- 1 root root 158M Jan 14 15:32 
/var/crash/201901141532/dump.201901141532




[37873.194365] CIFS VFS: Server 127.0.254.55 has not responded in 120 seconds. 
Reconnecting...
[37947.794384] BUG: unable to handle kernel NULL pointer dereference at 

[37947.794393] PGD 0 P4D 0 
[37947.794401] Oops:  [#1] SMP NOPTI
[37947.794407] CPU: 11 PID: 13315 Comm: file.so Kdump: loaded Tainted: G
   OE 4.19.0-1-amd64 #1 Debian 4.19.12-1
[37947.794411] Hardware name: System manufacturer System Product Name/PRIME 
B350M-A, BIOS 4014 05/11/2018
[37947.794466] RIP: 0010:SMB2_close_free+0x8/0x10 [cifs]



$ crash /usr/lib/debug/lib/modules/4.19.0-1-amd64/vmlinux 
/var/crash/201901141532/dump.201901141532

crash> bt
PID: 13315  TASK: 967938300ec0  CPU: 11  COMMAND: "file.so"
 #0 [accec32cb8e0] machine_kexec at 88e558f7
 #1 [accec32cb938] __crash_kexec at 88f1e19d
 #2 [accec32cba00] crash_kexec at 88f1f35d
 #3 [accec32cba18] oops_end at 88e29afd
 #4 [accec32cba38] no_context at 88e640ae
 #5 [accec32cba90] __do_page_fault at 88e64772
 #6 [accec32cbb00] page_fault at 8960108e
[exception RIP: SMB2_close_free+8]
RIP: c0f5bb48  RSP: accec32cbbb8  RFLAGS: 00010246
RAX:   RBX: 967798d61000  RCX: 
RDX: 0007  RSI: 0246  RDI: accec32cbd68
RBP: accec32cbdf0   R8: 000a   R9: 
R10: 0045  R11: 228354df9900  R12: accec32cbc50
R13: 96782d1f4000  R14: 967798d62800  R15: 
ORIG_RAX:   CS: 0010  SS: 0018
 #7 [accec32cbbb8] smb2_queryfs at c0f4e1b8 [cifs]
 #8 [accec32cbe00] cifs_statfs at c0f126fd [cifs]
 #9 [accec32cbe38] statfs_by_dentry at 890907e7
#10 [accec32cbe50] vfs_statfs at 89090a56
#11 [accec32cbe68] user_statfs at 89090b54
#12 [accec32cbea8] __do_sys_statfs at 89090bc0
#13 [accec32cbf38] do_syscall_64 at 88e040d3
#14 [accec32cbf50] entry_SYSCALL_64_after_hwframe at 89600088
RIP: 7f58114bd217  RSP: 7fffeabfea08  RFLAGS: 0246
RAX: ffda  RBX: 55981f7305b8  RCX: 7f58114bd217
RDX:   RSI: 7fffeabfea10  RDI: 55981f7305b8
RBP: 7fffeabfea10   R8: 7f581158ec40   R9: 55981f730630
R10: 0007  R11: 0246  R12: 7fffeabfead0
R13: 7fffeabfeac8  R14: 55981f77de88  R15: 55981f7316f0
ORIG_RAX: 0089  CS: 0033  SS: 002b

crash> dis SMB2_close_free
0xc0f5bb40 :   nopl   0x0(%rax,%rax,1) [FTRACE NOP]
0xc0f5bb45 : mov(%rdi),%rax
0xc0f5bb48 : mov(%rax),%rdi
0xc0f5bb4b :jmpq   0xc0f3f870 




-- Package-specific info:
** Version:
Linux version 4.19.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 
8.2.0 (Debian 8.2.0-13)) #1 SMP Debian 4.19.12-1 (2018-12-22)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-1-amd64 
root=UUID=64e985dd-8bd3-4051-82a4-a01577abbed4 ro crashkernel=384M-:128M

** Tainted: OE (12288)
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: System manufacturer
product_name: System Product Name
product_version: System Version
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends Inc.
bios_version: 4014
board_vendor: ASUSTeK COMPUTER 

Bug#911392: linux-image-686-pae: Kernel panic after upgrading to 4.18 (Bug #911392)

[Bernhard Übelacker]

Control: fixed 911392 linux/4.19.12-1

Dear Maintainer,
did an update on that testsystem and the error
does not show up with at least 4.19.12-1.

Kind regards,
Bernhard

Bug#909805: linux-image-686-pae: Kernel panic after upgrading to 4.18

[Bernhard Übelacker]

Hello,
might this just another cases of similar bugs 908924/908382/911392?

Is this still an issue with current version 4.19.12-1 ?

Kind regards,
Bernhard



signature.asc
Description: OpenPGP digital signature

Bug#911392: linux-image-686-pae: Kernel panic after upgrading to 4.18 (Bug #911392)

[Bernhard Übelacker]

Hello,
missed following bug while listing maybe related ones:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911320

Kind regards,
Bernhard

Bug#869684: linux-image-4.9.0-3-686-pae: Thinkpad T60 hangs on resume after suspend to disk; regress since Debian 8

[Bernhard Übelacker]

Hello,
I installed a Thinkpad T60 last year around 16.19.2016 with Debian Testing.
With the kernel contained at that time suspend to disk was working well.
(linux-image-4.6.0-1-686-pae  4.6.4-1, [1])

Just recently I got this system back and upgraded it to current Stretch.
(linux-image-4.9.0-3-686-pae  4.9.30-2+deb9u3)
There I can confirm resume is not working anymore.

As my first attempt to add some information to this bug report never
arrived (with reportbug) I decided to try with a vanilla kernel:
The git head from yesterday has the same issue (4.13.0-rc4+)

And then tried some git bisect.
Finally I came to this commit:

$ git bisect bad
65fe935dd2387a4faf15314c73f5e6d31ef0217e is the first bad commit
commit 65fe935dd2387a4faf15314c73f5e6d31ef0217e
Author: Kees Cook 
Date:   Mon Jun 13 15:10:02 2016 -0700

x86/KASLR, x86/power: Remove x86 hibernation restrictions

With the following fix:

70595b479ce1 ("x86/power/64: Fix crash whan the hibernation code 
passes control to the image kernel")

... there is no longer a problem with hibernation resuming a
KASLR-booted kernel image, so remove the restriction.

...

:04 04 62ec80a77951d45d01880a17fc64e9ee9d2e974c 
a43a4a4e1d1625a67d5403328d52a0103253a747 M  Documentation
:04 04 81718df2254545796eda792b975f9ab32d2a62bd 
b75ddf9403921b170727f685370ecc70d0ff6907 M  arch
:04 04 85ea5ad6e9b8fea1691552d14c998b04f8364136 
3462d929255d999a68f1a37e7e7ba9a66b099a39 M  kernel


I tried adding "nokaslr" to my default kernel parameters and
indeed I could successfully resume with a vanilla 4.13.0-rc4+ and
the default Stretch 4.9.30-2+deb9u3 kernels.


Adding this to /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet nokaslr"
and executing
update-grub
should make it permanent.


Probably this can be confirmed by Sergio B.?


Kind regards,
Bernhard




[1] 
http://snapshot.debian.org/package/linux/4.6.4-1/#linux-image-4.6.0-1-686-pae_4.6.4-1

Bug#783082: linux-image-3.16.0-4-586: video players/browsers crash with 'illegal instruction' on i586

[Bernhard Übelacker]

Hello hikaru,
just saw your report and tried if I could reproduce your issue.

But probably you want to reproduce these steps on your hardware to verify
that this is really the issue on real hardware.


These steps I tried to reproduce:
- install a qemu virtual machine with current jessie with some desktop
  environment and following packages: gdb vlc-dbg libav-dbg
- shut down the VM and restarted with forcing it to i586 with these
  parameters: qemu-system-i386 -cpu pentium ...
- started vlc without starting a video
- started in a terminal gdb: gdb --pid 984
- issue the command cont
- play in vlc a video
- at some point I came to the following exception
- the command bt shows you the call stack which led to the exception
- (to end the crashed vlc issue commands kill and quit)


Stack without having debug symbols installed:
Program received signal SIGILL, Illegal instruction.
[Switching to Thread 0xb17ffb40 (LWP 545)]
0xaf282c93 in ?? () from /usr/lib/i386-linux-gnu/libavcodec.so.56
(gdb) bt
#0  0xaf282c93 in ?? () from /usr/lib/i386-linux-gnu/libavcodec.so.56
#1  0xaf2b9680 in ?? () from /usr/lib/i386-linux-gnu/libavcodec.so.56
#2  0xaf2bd816 in ?? () from /usr/lib/i386-linux-gnu/libavcodec.so.56
#3  0xaf274c86 in ?? () from /usr/lib/i386-linux-gnu/libavcodec.so.56
#4  0xaf4e9c9c in avcodec_decode_video2 () from 
/usr/lib/i386-linux-gnu/libavcodec.so.56
#5  0xb1582801 in ?? () from /usr/lib/vlc/plugins/codec/libavcodec_plugin.so
#6  0xb743928e in ?? () from /usr/lib/libvlccore.so.8
#7  0xb743ae57 in ?? () from /usr/lib/libvlccore.so.8
#8  0xb76a0d97 in start_thread (arg=0xb17ffb40) at pthread_create.c:309
#9  0xb75f7dfe in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129
(gdb)

With debug symbols installed:
Program received signal SIGILL, Illegal instruction.
[Switching to Thread 0xb227fb40 (LWP 1002)]
0xafcd9c93 in mid_pred (c=0, b=0, a=0) at 
/build/libav-H9AQHK/libav-11.3/libavcodec/x86/mathops.h:77
77  /build/libav-H9AQHK/libav-11.3/libavcodec/x86/mathops.h: Datei oder 
Verzeichnis nicht gefunden.
(gdb) bt
#0  0xafcd9c93 in mid_pred (c=0, b=0, a=0) at 
/build/libav-H9AQHK/libav-11.3/libavcodec/x86/mathops.h:77
#1  pred_motion (my=synthetic pointer, mx=synthetic pointer, ref=0, 
list=0, part_width=4, n=0, h=0xb233e4c0) at 
/build/libav-H9AQHK/libav-11.3/libavcodec/h264_mvpred.h:140
#2  ff_h264_decode_mb_cavlc (h=0xb233e4c0) at 
/build/libav-H9AQHK/libav-11.3/libavcodec/h264_cavlc.c:959
#3  0xafd10680 in decode_slice (avctx=0xb2338ea0, arg=0xb227f050) at 
/build/libav-H9AQHK/libav-11.3/libavcodec/h264_slice.c:2275
#4  0xafd14816 in ff_h264_execute_decode_slices (h=0xb233e4c0, 
context_count=1) at /build/libav-H9AQHK/libav-11.3/libavcodec/h264_slice.c:2369
#5  0xafccbc86 in decode_nal_units (parse_extradata=0, buf_size=74, 
buf=0xb2302500 , h=0xb233e4c0) at 
/build/libav-H9AQHK/libav-11.3/libavcodec/h264.c:1662
#6  h264_decode_frame (avctx=0xb2338ea0, data=0xb2303040, 
got_frame=0xb227f1a8, avpkt=0xb227f1d4) at 
/build/libav-H9AQHK/libav-11.3/libavcodec/h264.c:1782
#7  0xaff40c9c in avcodec_decode_video2 (avctx=0xb2338ea0, 
picture=0xb2303040, got_picture_ptr=0xb227f1a8, avpkt=0xb227f1d4) at 
/build/libav-H9AQHK/libav-11.3/libavcodec/utils.c:1600
#8  0xb2003801 in DecodeVideo (p_dec=0xb2335180, pp_block=0xb227f1a8) at 
codec/avcodec/video.c:631
#9  0xb74d428e in DecoderDecodeVideo (p_dec=0xb2335180, p_block=0xb2302490) 
at input/decoder.c:1385
#10 0xb74d5e57 in DecoderProcessVideo (b_flush=optimized out, 
p_block=0xb2302490, p_dec=optimized out) at input/decoder.c:1631
#11 DecoderProcess (p_block=optimized out, p_dec=optimized out) at 
input/decoder.c:1810
#12 DecoderThread (p_data=0xb2335180) at input/decoder.c:909
#13 0xb773bd97 in start_thread (arg=0xb227fb40) at pthread_create.c:309
#14 0xb7692dfe in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129
(gdb)

Current instruction:
   (gdb) display/i $pc
   1: x/i $pc
   = 0xafc39c93 ff_h264_decode_mb_cavlc+11395:  cmovg  %edx,%edi


libavcodec/x86/mathops.h:77
There we find some inline assembly guarded by an #if HAVE_I686.


It looks like that the package libavcodec56 has exactly for
this use case 2 version of the shared object packaged:
/usr/lib/i386-linux-gnu/libavcodec.so.56.1.0
/usr/lib/i386-linux-gnu/i686/cmov/libavcodec.so.56.1.0


So I started up a local package build for libav which is still
running with following lines in:

libav-11.3/debian-shared/config.h
  #define LIBAV_CONFIGURATION --arch=i386 ... --cpu=586
  #define HAVE_I686 1


So probably this upstream commit could already be sufficient?
  [1] configure: Disable i686 for i586 and lower CPUs


Kind regards,
Bernhard


[1] 
https://git.libav.org/?p=libav.git;a=commit;h=9030c58a780a02fb8256cb75cd39275eaad786d1


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

Bug#779159: linux-image-3.16.0-4-686-pae: system hangs after login into graphic desktop

[Bernhard Übelacker]

Had no chance to attach the mentioned dmesg in text mode of reportbug.

Kind regards,
Bernhard
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.16.0-4-686-pae (debian-kernel@lists.debian.org) 
(gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03)
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable
[0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x3f4aefff] usable
[0.00] BIOS-e820: [mem 0x3f4af000-0x3f5aefff] reserved
[0.00] BIOS-e820: [mem 0x3f5af000-0x3f6aefff] ACPI NVS
[0.00] BIOS-e820: [mem 0x3f6af000-0x3f6eefff] ACPI data
[0.00] BIOS-e820: [mem 0x3f6ef000-0x3f6e] usable
[0.00] BIOS-e820: [mem 0x3f6f-0x3fff] reserved
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xffe0-0x] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.7 present.
[0.00] DMI: Acer AOD270/JE01_CT , BIOS V1.03 01/03/2012
[0.00] e820: update [mem 0x-0x0fff] usable == reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x3f6f0 max_arch_pfn = 0x100
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0FFE0 mask FFFE0 write-protect
[0.00]   1 base 0 mask FE000 write-back
[0.00]   2 base 02000 mask FE000 write-back
[0.00]   3 base 03F80 mask FFF80 uncachable
[0.00]   4 disabled
[0.00]   5 base 03F6F mask F uncachable
[0.00]   6 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] found SMP MP-table at [mem 0x000fe260-0x000fe26f] mapped at 
[c00fe260]
[0.00] initial memory mapped: [mem 0x-0x01bf]
[0.00] Base memory trampoline at [c009a000] 9a000 size 16384
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] init_memory_mapping: [mem 0x3720-0x373f]
[0.00]  [mem 0x3720-0x373f] page 2M
[0.00] init_memory_mapping: [mem 0x3400-0x371f]
[0.00]  [mem 0x3400-0x371f] page 2M
[0.00] init_memory_mapping: [mem 0x0010-0x33ff]
[0.00]  [mem 0x0010-0x001f] page 4k
[0.00]  [mem 0x0020-0x33ff] page 2M
[0.00] init_memory_mapping: [mem 0x3740-0x375fdfff]
[0.00]  [mem 0x3740-0x375fdfff] page 4k
[0.00] BRK [0x01796000, 0x01796fff] PGTABLE
[0.00] BRK [0x01797000, 0x01798fff] PGTABLE
[0.00] BRK [0x01799000, 0x01799fff] PGTABLE
[0.00] BRK [0x0179a000, 0x0179afff] PGTABLE
[0.00] RAMDISK: [mem 0x363ae000-0x371cefff]
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000FE020 24 (v02 ACRSYS)
[0.00] ACPI: XSDT 0x3F6EE120 8C (v01 ACRSYS ACRPRDCT 0001  
0113)
[0.00] ACPI: FACP 0x3F6ED000 F4 (v04 ACRSYS ACRPRDCT 0001 1025 
0004)
[0.00] ACPI: DSDT 0x3F6E1000 00780E (v02 ACRSYS ACRPRDCT  1025 
0004)
[0.00] ACPI: FACS 0x3F674000 40
[0.00] ACPI: HPET 0x3F6EC000 38 (v01 ACRSYS ACRPRDCT 0001 1025 
0004)
[0.00] ACPI: APIC 0x3F6EB000 78 (v02 ACRSYS ACRPRDCT 0001 1025 
0004)
[0.00] ACPI: MCFG 0x3F6EA000 3C (v01 ACRSYS ACRPRDCT 0001 1025 
0004)
[0.00] ACPI: WDRT 0x3F6E9000 47 (v01 ACRSYS ACRPRDCT  1025 
0004)
[0.00] ACPI: SLIC 0x3F6E 000176 (v01 ACRSYS ACRPRDCT 0001 1025 
0004)
[0.00] ACPI: BOOT 0x3F6DF000 28 (v01 ACRSYS ACRPRDCT 0001 1025 
0004)
[0.00] ACPI: MSDM 0x3F6DE000 55 (v03 ACRSYS ACRPRDCT 0001 1025 
0004)
[0.00] ACPI: FPDT 0x3F6DC000 90 (v01 ACRSYS ACRPRDCT 0001 1025 
0004)
[0.00] ACPI: SSDT 0x3F6DB000 000655 (v01 ACRSYS ACRPRDCT 3000 1025 
0004)
[0.00] ACPI: SSDT 

Bug#779159: linux-image-3.16.0-4-686-pae: system hangs after login into graphic desktop

[Bernhard Übelacker]

Package: src:linux
Version: 3.16.7-ckt4-3
Severity: normal

Dear Maintainer,

I upgraded a Wheezy installation to Testing/Jessie. All in all it was without 
big surprises.
Except that most of the time after some time (e.g. 15 seconds) after the login 
via kdm into
the kde desktop the system hangs.
Staying at the login screen did not trigger these hangs.

I connected via ssh and inspected the dmesg output before logging in to kde.
When later the hang happened there was before always such an entry:
[   12.423002] [ cut here ]
[   12.423023] WARNING: CPU: 0 PID: 38 at 
/build/linux-AmBmwr/linux-3.16.7-ckt4/include/linux/kref.h:47 
kobject_get+0x35/0x40()
[   12.423027] Modules linked in: acpi_cpufreq(+) processor loop fuse 
parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 sg sd_mod 
crc_t10dif crct10dif_generic crct10dif_common rtsx_pci_sdmmc mmc_core ahci 
libahci rtsx_pci libata uhci_hcd ehci_pci mfd_core ehci_hcd scsi_mod usbcore 
usb_common r8169 mii thermal thermal_sys
[   12.423085] CPU: 0 PID: 38 Comm: kworker/0:1 Not tainted 3.16.0-4-686-pae #1 
Debian 3.16.7-ckt4-3
[   12.423090] Hardware name: Acer AOD270/JE01_CT , BIOS V1.03 01/03/2012
[   12.423098] Workqueue: kacpi_notify acpi_os_execute_deferred
[   12.423103]  c154e9ac f57e1cf0 c1475f58  c1056ae4 c154eae4  
0026
[   12.423114]  c154e9ac 002f c12511d5 c12511d5 0009 f4c4e974 0202 

[   12.423125]  f57e1d00 c1056ba2 0009  f57e1d18 c12511d5 f4c4e900 
c136e7dc
[   12.423135] Call Trace:
[   12.423146]  [c1475f58] ? dump_stack+0x3e/0x4e
[   12.423155]  [c1056ae4] ? warn_slowpath_common+0x84/0xa0
[   12.423163]  [c12511d5] ? kobject_get+0x35/0x40
[   12.423169]  [c12511d5] ? kobject_get+0x35/0x40
[   12.423177]  [c1056ba2] ? warn_slowpath_null+0x22/0x30
[   12.423184]  [c12511d5] ? kobject_get+0x35/0x40
[   12.423192]  [c136e7dc] ? cpufreq_cpu_get+0x5c/0xa0
[   12.423199]  [c136f17d] ? cpufreq_update_policy+0x1d/0x180
[   12.423207]  [c136f2e0] ? cpufreq_update_policy+0x180/0x180
[   12.423220]  [f8095381] ? cpufreq_set_cur_state.part.3+0x6e/0x75 
[processor]
[   12.423229]  [f8095476] ? processor_set_cur_state+0x8a/0xc3 [processor]
[   12.423242]  [f7e4bc96] ? thermal_cdev_update+0x96/0x120 [thermal_sys]
[   12.423254]  [f7e4e2c0] ? step_wise_throttle+0x40/0x70 [thermal_sys]
[   12.423265]  [f7e4c445] ? handle_thermal_trip+0x45/0x150 [thermal_sys]
[   12.423275]  [f7e533bc] ? thermal_get_temp+0x1d/0x3a [thermal]
[   12.423285]  [f7e4c5c9] ? thermal_zone_device_update+0x79/0xe0 
[thermal_sys]
[   12.423294]  [c12bfba3] ? acpi_device_notify+0x16/0x18
[   12.423301]  [c12ce70a] ? acpi_ev_notify_dispatch+0x35/0x49
[   12.423307]  [c12bbd6d] ? acpi_os_execute_deferred+0x11/0x1b
[   12.423315]  [c106d955] ? process_one_work+0x115/0x380
[   12.423322]  [c1062853] ? mod_timer+0x103/0x190
[   12.423329]  [c106e113] ? worker_thread+0xf3/0x470
[   12.423336]  [c108fe3f] ? __wake_up_locked+0x1f/0x30
[   12.423343]  [c106e020] ? create_and_start_worker+0x50/0x50
[   12.423350]  [c107334b] ? kthread+0x9b/0xb0
[   12.423359]  [c147ad81] ? ret_from_kernel_thread+0x21/0x30
[   12.423365]  [c10732b0] ? kthread_create_on_node+0x110/0x110
[   12.423371] ---[ end trace 863dcb3f68f118cb ]---

On some tries there was such a message missing and then the hang did not 
happen, so
I think this could be related.


I was able to collect one dmesg output right before the hang with some more
stack traces introduced by:
[  179.269865] Watchdog detected hard LOCKUP on cpu 1

[  184.271061] INFO: rcu_sched detected stalls on CPUs/tasks: { 1} (detected by 
3, t=5254 jiffies, g=6837, c=6836, q=171573)


Hangs happened also for some newer kernels (from experimantal, snapshot or 
Jessie):
  linux-image-3.19.0-trunk-686-pae_3.19-1~exp1_i386.deb
  linux-image-3.18.0-trunk-686-pae_3.18.6-1%7Eexp1_i386.deb
  linux-image-3.16.0-4-686-pae_3.16.7-ckt4-3_i386.deb

But on older kernels it seems not to happen (also from snapshot or Wheezy):
  linux-image-3.14-2-686-pae_3.14.15-2_i386.deb
  linux-image-3.10-3-686-pae_3.10.11-1_i386.deb
  linux-image-3.2.0-4-686-pae_3.2.65-1_i386.deb


Also I assume this is probably specific to this computer:
  Acer ASPIRE ONE D270-Dws


I am not confident if severity and the package I opened the ticket is right.
If there is anything I can supply I will try, but as this is not my device,
my access to it will be limited in some days and could then take some time.


Kind regards,
Bernhard



-- Package-specific info:
** Version:
Linux version 3.16.0-4-686-pae (debian-kernel@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-686-pae 
root=UUID=b9d840bf-00c6-461b-b55f-d2418ba19e0c ro ipv6.disable=1 quiet

** Not tainted

** Kernel log:
[   12.975954] ACPI: Power Button [PWRF]
[   13.112377] systemd-journald[163]: Received request to flush runtime journal 
from PID 1
[   13.147840]