https://bugzilla.suse.com/show_bug.cgi?id=1196048
Bug ID: 1196048
Summary: audit file watches do not really work?
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: meissner(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
auditctl -e 1
auditctl -w /etc/issue
if i do
echo hallo >> /etc/issue
-> not audited
if i do
vim /etc/issue
... remove hallo line and save ...
-> audited
cat /etc/issue
-> not audited
Not sure if I am doing it right.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1194268
Bug ID: 1194268
Summary: disable btrfs asserts in default kernels
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: dmueller(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
while chasing for I/O performance issues in virtualized environments (usecase
Open Build Service package builds for example), I noticed that btrfs in our
default kernel has asserts enabled. according to the Kconfig help setting, this
setting is purely for development purposes.
I suggested to move the setting CONFIG_BTRFS_ASSERT only into the debug
flavors, however there was concerns that this affects finding memory
corruptions and other hardware related issues.
On the other side, in my brief testing it appeared disabling reduced code size
noticeably (in dual-digit percentage range) and also improved IOPS on a FIO
randrw test (on a cow file) by over 20%. I will replicate the tests to be sure.
This bug is to track how to address the issue and making asserts purely
developer only and disable them in production builds of the openSUSE
distribution.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1195297
Bug ID: 1195297
Summary: fbtft spi screens no longer functions properly.
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: aarch64
OS: openSUSE Tumbleweed
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: simonf.lees(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Connected to the raspberry pi on my Robot I have a small 3.2" display
[1] (or a clone / older version) it connects via SPI on the raspberry
pi's GPIO header. In the past i've had it working with the overlay at
[2] and the fbtft driver.
This kinda setup is pretty common in the embedded / hobbyist world, I
don't use a desktop or anything just simple status apps using the
framebuffer directly on the other hand it wouldn't be the end of the
world if I moved to Qt.
Today I finally got a chance to update and as of now I no longer have an
/dev/fb1 (/dev/fb0 is hdmi) is that expected with my current setup? I
had other issues with the update and had to grab a fresh image and re
add my overlay and raspbery pi config so there is also a chance I missed
something setting it up again. I've put some dmesg output from the older
system the new system shows nothing and below that is an fbi command I
use for testing.
Log from previously working system:
[ 59.468595] fbtft: module is from the staging directory, the quality
is unknown, you have been warned.
[ 59.714749] fb_ili9340: module is from the staging directory, the
quality is unknown, you have been warned.
[ 59.716023] fb_ili9340 spi0.0: fbtft_property_value: buswidth = 8
[ 59.716049] fb_ili9340 spi0.0: fbtft_property_value: debug = 0
[ 59.716063] fb_ili9340 spi0.0: fbtft_property_value: rotate = 270
[ 59.716079] fb_ili9340 spi0.0: fbtft_property_value: fps = 25
[ 59.716093] fb_ili9340 spi0.0: fbtft_property_value: txbuflen = 32768
[ 61.352903] graphics fb1: fb_ili9340 frame buffer, 320x240, 150 KiB
video memory, 32 KiB buffer memory, fps=25, spi0.0 at 16 MHz
Test command:
sudo fbi -T 13 -d /dev/fb1 --noverbose 1-110313112A3.jpg
1. https://www.waveshare.com/wiki/3.2inch_RPi_LCD_(B)
2. https://github.com/swkim01/waveshare-dtoverlays
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1179894
Bug ID: 1179894
Summary: warnings in OBS builds from kernel+initrd about
"Warning: running kernel does not support fscaps"
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: okurz(a)suse.com
QA Contact: qa-bugs(a)suse.de
CC: fvogt(a)suse.com, jslaby(a)suse.com, msuchanek(a)suse.com,
okurz(a)suse.com, thomas.blume(a)suse.com, tiwai(a)suse.com
Depends on: 1178401
Found By: ---
Blocker: ---
+++ This bug was initially created as a clone of Bug #1178401 +++
## Observation
https://build.opensuse.org/build/openSUSE:Factory/images/local/000product:o…
shows repeated warnings about:
```
[ 14s] Warning: running kernel does not support fscaps
[ 14s] Warning: running kernel does not support fscaps
[ 14s] Warning: running kernel does not support fscaps
[ 14s] Warning: running kernel does not support fscaps
[ 14s] Warning: running kernel does not support fscaps
[ 14s] Warning: running kernel does not support fscaps
[ 14s] Warning: running kernel does not support fscaps
[ 14s] Warning: running kernel does not support fscaps
```
## Steps to reproduce
Seemingly reproducible in any build of packages, e.g.
https://build.opensuse.org/public/build/openSUSE:Factory/standard/x86_64/00…
shows the same
## Expected result
Only errors and warnings in the log that I as package/project maintainer can
fix
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1178463
Bug ID: 1178463
Summary: Flood of "usb usb{2,6}-port1: Cannot enable." messages
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: lmb(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Created attachment 843325
--> https://bugzilla.suse.com/attachment.cgi?id=843325&action=edit
lsusb -vv
With the 5.10.0rc2 kernel from Kernel:HEAD, I'm experiencing a flood of:
...
[ 372.567942] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
[ 374.686509] usb usb6-port1: Cannot enable. Maybe the USB cable is bad?
[ 377.026495] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
[ 378.986503] usb usb6-port1: Cannot enable. Maybe the USB cable is bad?
[ 381.446415] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
[ 383.290504] usb usb6-port1: Cannot enable. Maybe the USB cable is bad?
[ 385.918496] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
[ 387.586478] usb usb6-port1: Cannot enable. Maybe the USB cable is bad?
[ 390.386475] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
[ 391.894454] usb usb6-port1: Cannot enable. Maybe the USB cable is bad?
...
The XPS 13 is connected to a Belkin Thunberbird dock. As far as I can tell,
except for these messages, all USB connected peripherals (keyboard, mouse,
webcam) are working.
Attaching lsusb -vv and dmesg output.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1193931
Bug ID: 1193931
Summary: unexpectedly, the system freezes very much
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: suse(a)rop.cx
QA Contact: qa-bugs(a)suse.de
Group: novellonly, SUSE Security Internal
Found By: ---
Blocker: ---
Created attachment 854712
--> https://bugzilla.suse.com/attachment.cgi?id=854712&action=edit
full dmesg
usually nothing works and only sometimes works very slowly for a few seconds,
but the cursor is working properly, usually without delay
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1192624
Bug ID: 1192624
Summary: ltp_nfs nfs05 (NFS stress test with make) fails
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: petr.vorel(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Tumbleweed Build 20211110 kernel 5.14.14-2-default (2b5383f) [1] (but it might
have been failing in 5.13 and older kernels) fails to run all nfs*_05 tests
which run shell script nfs05 [2] which runs nfs05_make_tree.c [3] (NFS stress
test with make).
Test output:
# nfs05 -v 4 -t tcp; echo "### TEST nfs4_05 COMPLETE >>> $?"
nfs05 1 TINFO: timeout per run is 0h 5m 0s
nfs05 1 TINFO: setup NFSv4, socket type tcp
nfs05 1 TINFO: Mounting NFS: mount -v -t nfs -o proto=tcp,vers=4
10.0.0.2:/tmp/LTP_nfs05.G8q7DLN0j0/4/tcp /tmp/LTP_nfs05.G8q7DLN0j0/4/0
nfs05 1 TINFO: start nfs05_make_tree -d 20 -f 50 -t 8
tst_test.c:1363: TINFO: Timeout per run is 0h 05m 00s
Test timed out, sending SIGTERM!
If you are running on slow machine, try exporting LTP_TIMEOUT_MUL > 1
Terminated
nfs05 1 TBROK: test terminated
nfs05 1 TINFO: Cleaning up testcase
umount.nfs4: /tmp/LTP_nfs05.G8q7DLN0j0/4/0: device is busy
Test is still running... 10
Test is still running... 9
Test is still running... 8
make[6]: *** No rule to make target '26445.6.20.c', needed by '26445.6.20'.
Stop.
make[5]: *** [makefile:9: dir] Error 2
make[4]: *** [makefile:9: dir] Error 2
make[3]: *** [makefile:9: dir] Error 2
make[2]: *** [makefile:9: dir] Error 2
make[1]: *** [makefile:9: dir] Error 2
make: *** [makefile:9: dir] Error 2
tst_cmd.c:109: TBROK: 'make' exited with a non-zero code 2 at tst_cmd.c:109
Test is still running... 7
...
make: *** [makefile:9: dir] Error 2
Test is still running... 1
rm: cannot remove
'/tmp/LTP_nfs05.G8q7DLN0j0/4/tcp/susetest.26445/dir/dir/dir/dir/dir/dir':
Directory not empty
rm: cannot remove
'/tmp/LTP_nfs05.G8q7DLN0j0/4/tcp/susetest.26446/dir/dir/dir/dir/dir/dir':
Directory not empty
rm: cannot remove
'/tmp/LTP_nfs05.G8q7DLN0j0/4/tcp/susetest.26447/dir/dir/dir/dir/dir/dir':
Directory not empty
rm: cannot remove
'/tmp/LTP_nfs05.G8q7DLN0j0/4/tcp/susetest.26448/dir/dir/dir/dir/dir/dir':
Directory not empty
rm: cannot remove
'/tmp/LTP_nfs05.G8q7DLN0j0/4/tcp/susetest.26449/dir/dir/dir/dir/dir/dir':
Directory not empty
rm: cannot remove
'/tmp/LTP_nfs05.G8q7DLN0j0/4/tcp/susetest.26450/dir/dir/dir/dir/dir/dir':
Directory not empty
rm: cannot remove
'/tmp/LTP_nfs05.G8q7DLN0j0/4/tcp/susetest.26452/dir/dir/dir/dir/dir/dir':
Directory not empty
rm: cannot remove
'/tmp/LTP_nfs05.G8q7DLN0j0/4/tcp/susetest.26451/dir/dir/dir/dir/dir/dir':
Directory not empty
make[6]: *** No rule to make target '26451.6.46.c', needed by '26451.6.46'.
Stop.
make[5]: *** [makefile:9: dir] Error 2
make[4]: *** [makefile:9: dir] Error 2
make[3]: *** [makefile:9: dir] Error 2
make[2]: *** [makefile:9: dir] Error 2
make[1]: *** [makefile:9: dir] Error 2
make: *** [makefile:9: dir] Error 2
rm: cannot remove '/tmp/LTP_nfs05.G8q7DLN0j0/4/0': Device or resource busy
rm: cannot remove '/tmp/LTP_nfs05.G8q7DLN0j0/4/0': Is a directory
There is probably no stack trace in dmesg related to this test (in attached
dmesg there is really long Call Trace related to FCNTL_LOCKTESTS reported in
#1192623).
[1] https://openqa.opensuse.org/tests/2029105
[2]
https://github.com/linux-test-project/ltp/blob/master/testcases/network/nfs…
[3]
https://github.com/linux-test-project/ltp/blob/master/testcases/network/nfs…
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1176026
Bug ID: 1176026
Summary: bond interface should not invent mac address by
default
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: ro(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
since 5.8.4 (unsure about last digit):
when setting up a bond if kernel chooses a random mac
removing and readding the slave gets back to the used behaviour:
obs-arm-1:~ # modprobe bonding
3: enP2p1s0v1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN
group default qlen 1000
link/ether 1c:1b:0d:60:ee:8b brd ff:ff:ff:ff:ff:ff
7: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 9e:29:55:da:aa:0e brd ff:ff:ff:ff:ff:ff
obs-arm-1:~ # echo +enP2p1s0v1 > /sys/class/net/bond0/bonding/slaves
7: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 9e:29:55:da:aa:0e brd ff:ff:ff:ff:ff:ff
obs-arm-1:~ # echo -enP2p1s0v1 > /sys/class/net/bond0/bonding/slaves
obs-arm-1:~ # echo +enP2p1s0v1 > /sys/class/net/bond0/bonding/slaves
7: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 1c:1b:0d:60:ee:8b brd ff:ff:ff:ff:ff:ff
--
You are receiving this mail because:
You are the assignee for the bug.