Bug#1053643: curl: ldap queries to IPv6 addresses broken after 7.88.1-10+deb12u3 update (Debian 12.2)
Package: curl Version: 7.88.1-10+deb12u3 Severity: normal Tags: ipv6 X-Debbugs-Cc: t...@security.debian.org We use curl as a health check in our keepalived setup. We basically run the following curl command: curl 'ldap://[2a02:2c40:0:a412::389:389]' This works fine in 7.88.1-10+deb12u1, but breaks after upgrading to 7.88.1-10+deb12u3 (version in Debian 12.2). Output with the working version: $ curl -v 'ldap://[2a02:2c40:0:a412::389:389]' * Trying [2a02:2c40:0:a412::389:389]:389... * Connected to 2a02:2c40:0:a412::389:389 (2a02:2c40:0:a412::389:389) * port 389 (#0) * LDAP local: LDAP Vendor = OpenLDAP ; LDAP Version = 20513 * LDAP local: ldap://[2a02:2c40:0:a412::389:389]/ * LDAP local: trying to establish cleartext connection DN: objectClass: top objectClass: OpenLDAProotDSE * Closing connection 0 Output with broken version: $ curl -v 'ldap://[2a02:2c40:0:a412::389:389]' * Trying [2a02:2c40:0:a412::389:389]:389... * Connected to 2a02:2c40:0:a412::389:389 (2a02:2c40:0:a412::389:389) port 389 (#0) * LDAP local: Cannot connect to ldap://2a02:2c40:0:a412::389:389:389, Bad parameter to an ldap routine * Closing connection 0 Looking at the changelog, I assume this issue was introduced in 7.88.1-10+deb12u2 It works for IPv6 if we specify a hostname, but not if we specify an IPv6 address: Regards, Rik -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-12-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages curl depends on: ii libc6 2.36-9+deb12u3 ii libcurl4 7.88.1-10+deb12u3 ii zlib1g1:1.2.13.dfsg-1 curl recommends no packages. curl suggests no packages. -- no debconf information
Bug#1042893: pcs: resource move fails
Source: pcs
Version: 0.11.5-1
Severity: important
Tags: upstream patch
Hi,
I've set up a pacemaker cluster using pcs on Debian 12. When trying to
move a resource from one node to the next, this fails with a python
error:
Traceback (most recent call last):
File "/usr/sbin/pcs", line 33, in
sys.exit(load_entry_point('pcs==0.11.5', 'console_scripts', 'pcs')())
^^^
File "/usr/lib/python3/dist-packages/pcs/app.py", line 273, in main
routing.create_router(cmd_map, [])(
File "/usr/lib/python3/dist-packages/pcs/cli/common/routing.py", line 33, in
_router
return cmd_map[sub_cmd](lib, argv_next, modifiers)
^^^
File "/usr/lib/python3/dist-packages/pcs/cli/common/routing.py", line 33, in
_router
return cmd_map[sub_cmd](lib, argv_next, modifiers)
^^^
File "/usr/lib/python3/dist-packages/pcs/resource.py", line 854, in
resource_move
lib.resource.move_autoclean(
File "/usr/lib/python3/dist-packages/pcs/cli/common/lib_wrapper.py", line 95,
in decorated_run
return run_with_middleware(run, cli_env, *args, **kwargs)
^^
File "/usr/lib/python3/dist-packages/pcs/cli/common/middleware.py", line 14,
in run
return next_in_line(env, *args, **kwargs)
^^
File "/usr/lib/python3/dist-packages/pcs/cli/common/middleware.py", line 42,
in apply
result_of_next = next_in_line(env, *args, **kwargs)
^^
File "/usr/lib/python3/dist-packages/pcs/cli/common/middleware.py", line 80,
in apply
result_of_next = next_in_line(env, *args, **kwargs)
^^
File "/usr/lib/python3/dist-packages/pcs/cli/common/lib_wrapper.py", line 86,
in run
lib_call_result = run_library_command(lib_env, *args, **kwargs)
^
File "/usr/lib/python3/dist-packages/pcs/lib/commands/resource.py", line
1823, in move_autoclean
_, move_transitions, after_move_simulated_cib = simulate_cib(
^
File "/usr/lib/python3/dist-packages/pcs/lib/pacemaker/live.py", line 426, in
simulate_cib
plaintext_result, transitions_xml, new_cib_xml = simulate_cib_xml(
^
File "/usr/lib/python3/dist-packages/pcs/lib/pacemaker/live.py", line 387, in
simulate_cib_xml
with tools.get_tmp_file() as new_cib_file, tools.get_tmp_file() as
transitions_file:
File "/usr/lib/python3.11/contextlib.py", line 289, in helper
return _GeneratorContextManager(func, args, kwds)
^^
File "/usr/lib/python3.11/contextlib.py", line 105, in __init__
self.gen = func(*args, **kwds)
^^^
TypeError: get_tmp_file() missing 1 required positional argument: 'data'
This seems to be a known regression:
https://github.com/ClusterLabs/pcs/issues/696
A patch is available upstream:
https://github.com/ClusterLabs/pcs/commit/2ab9e9c4fd1f26e5320c7585a83ba5d1857d4042
The patch looks very small and clean. Please apply the patch to the Debian 12
version.
Regards,
Rik
-- System Information:
Debian Release: 12.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-10-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1040313: iputils-ping: incorrect results (responses from different addresses should not be accounted as received)
Package: iputils-ping Version: 3:20221126-1 Severity: normal Hi, After upgrading our monitoring host from bullseye to bookworm, our check_ping plugin suddenly reports that hosts that have been down for months are up again for a few minutes. I've looked into this and it seems we are running so many ping checks, that the randomly selected id from a ping to host A sometimes matches to the id of the ping to host B. Since all icmp responses are forwarded to both ping processes on the system. I've looked at the code between the ping command from bullseye and bookworm and it seems that the code from bookworm accounts for these wrong packets: it shows the response but marks it as "DIFFERENT ADDRESS!". This is correct, but these packets are then accounted for in the number of responses received and this makes it seem that a host is up when it isn't: root@iridium:~# ping 10.89.22.23 -v ping: sock4.fd: 3 (socktype: SOCK_RAW), sock6.fd: 4 (socktype: SOCK_RAW), hints.ai_family: AF_UNSPEC ai->ai_family: AF_INET, ai->ai_canonname: '10.89.22.23' PING 10.89.22.23 (10.89.22.23) 56(84) bytes of data. 64 bytes from 10.89.22.179: icmp_seq=1 ident=47195 ttl=252 time=1.04 ms (DIFFERENT ADDRESS!) 64 bytes from 10.89.22.179: icmp_seq=2 ident=47195 ttl=252 time=5.79 ms (DIFFERENT ADDRESS!) 64 bytes from 10.89.22.179: icmp_seq=3 ident=47195 ttl=252 time=69.8 ms (DIFFERENT ADDRESS!) 64 bytes from 10.89.22.179: icmp_seq=4 ident=47195 ttl=252 time=0.988 ms (DIFFERENT ADDRESS!) 64 bytes from 10.89.22.179: icmp_seq=5 ident=47195 ttl=252 time=0.975 ms (DIFFERENT ADDRESS!) ^C --- 10.89.22.23 ping statistics --- 1022 packets transmitted, 5 received, 99.5108% packet loss, time 1045246ms rtt min/avg/max/mdev = 0.975/15.720/69.808/27.107 ms, pipe 994 Since 10.89.22.23 (the one we are pinging) is down, there are no responses from this system. But because the ident (47195 in the example above) matches a different ping to 10.89.22.179, the responses are also parsed by this ping. It correctly shows that the response came from a different address, but still adds the 5 packets as 5 valid received packets, which makes the packet loss 99.5% instead of 100%. Those invalid packets should not count as valid responses as they are not from the correct host. I've compared the source code of ping between the bullseye and bookworm version, and the bullseye version discarded the packets if this occured. This change results in hosts that are actually down being reported as up in our monitoring system. Regards, Rik -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages iputils-ping depends on: ii libc62.36-9 ii libcap2 1:2.66-4 ii libcap2-bin 1:2.66-4 ii libidn2-02.3.3-1+b1 iputils-ping recommends no packages. iputils-ping suggests no packages. -- no debconf information
Bug#1037555: autofs: automount -m triggers segfaults
Package: autofs Version: 5.1.8-2 Severity: minor Dear Maintainer, When running "automount -m" to debug the maps used by autofs, I noticed that this triggers segfaults as can be seen in 'dmesg': [Wed Jun 14 08:05:38 2023] automount[9026]: segfault at 8 ip 7f5d6f3d4d19 sp 7ffd202ac5d8 error 4 in libc.so.6[7f5d6f2a5000+155000] likely on CPU 1 (core 0, socket 1) [Wed Jun 14 08:05:38 2023] Code: fe 7f 5c 17 e1 c5 f8 77 c3 0f 1f 84 00 00 00 00 00 89 f8 48 89 fa c5 f9 ef c0 25 ff 0f 00 00 3d e0 0f 00 00 0f 87 37 01 00 00 fd 74 0f c5 fd d7 c1 85 c0 74 5b f3 0f bc c0 c5 f8 77 c3 0f 1f [Wed Jun 14 08:05:38 2023] automount[9028]: segfault at 8 ip 7f5d6f3d4d19 sp 7ffd202ac5d8 error 4 in libc.so.6[7f5d6f2a5000+155000] likely on CPU 1 (core 0, socket 1) [Wed Jun 14 08:05:38 2023] Code: fe 7f 5c 17 e1 c5 f8 77 c3 0f 1f 84 00 00 00 00 00 89 f8 48 89 fa c5 f9 ef c0 25 ff 0f 00 00 3d e0 0f 00 00 0f 87 37 01 00 00 fd 74 0f c5 fd d7 c1 85 c0 74 5b f3 0f bc c0 c5 f8 77 c3 0f 1f [Wed Jun 14 08:05:38 2023] automount[9030]: segfault at 8 ip 7f5d6f3d4d19 sp 7ffd202ac5d8 error 4 in libc.so.6[7f5d6f2a5000+155000] likely on CPU 1 (core 0, socket 1) [Wed Jun 14 08:05:38 2023] Code: fe 7f 5c 17 e1 c5 f8 77 c3 0f 1f 84 00 00 00 00 00 89 f8 48 89 fa c5 f9 ef c0 25 ff 0f 00 00 3d e0 0f 00 00 0f 87 37 01 00 00 fd 74 0f c5 fd d7 c1 85 c0 74 5b f3 0f bc c0 c5 f8 77 c3 0f 1f [Wed Jun 14 08:05:38 2023] automount[9032]: segfault at 8 ip 7f5d6f3d4d19 sp 7ffd202ac5d8 error 4 in libc.so.6[7f5d6f2a5000+155000] likely on CPU 0 (core 0, socket 0) [Wed Jun 14 08:05:38 2023] Code: fe 7f 5c 17 e1 c5 f8 77 c3 0f 1f 84 00 00 00 00 00 89 f8 48 89 fa c5 f9 ef c0 25 ff 0f 00 00 3d e0 0f 00 00 0f 87 37 01 00 00 fd 74 0f c5 fd d7 c1 85 c0 74 5b f3 0f bc c0 c5 f8 77 c3 0f 1f [Wed Jun 14 08:05:38 2023] automount[9034]: segfault at 8 ip 7f5d6f3d4d19 sp 7ffd202ac5d8 error 4 in libc.so.6[7f5d6f2a5000+155000] likely on CPU 1 (core 0, socket 1) [Wed Jun 14 08:05:38 2023] Code: fe 7f 5c 17 e1 c5 f8 77 c3 0f 1f 84 00 00 00 00 00 89 f8 48 89 fa c5 f9 ef c0 25 ff 0f 00 00 3d e0 0f 00 00 0f 87 37 01 00 00 fd 74 0f c5 fd d7 c1 85 c0 74 5b f3 0f bc c0 c5 f8 77 c3 0f 1f The application seems to be working fine otherwise. nsswitch.conf has the following line for automount: automount: files sss Regards, Rik -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages autofs depends on: ii init-system-helpers 1.65.2 ii libc62.36-9 ii libnsl2 1.3.0-2 ii libtirpc31.3.3+ds-1 ii libxml2 2.9.14+dfsg-1.2 ii ucf 3.0043+nmu1 Versions of packages autofs recommends: ii e2fsprogs 1.47.0-2 ii kmod30+20221128-1 ii nfs-common 1:2.6.2-4 autofs suggests no packages. -- no debconf information
Bug#946941: (another) memory leak still present
Hi, I've updated our print server to cups 2.2.10-6+deb10u2 yesterday. Everything seems fine at first, but overnight it has started to leak memory again. It's definitely not so bad as before, but it seems there's still another memory leak in cups somewhere. When I look at the smaps file in /proc for the cupsd process, I see that most of the memory is in [heap]. 559a8605a000-559aeba66000 rw-p 00:00 0 [heap] Size: 1665072 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Rss: 906848 kB Pss: 906848 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 906848 kB Referenced: 583936 kB Anonymous: 906848 kB LazyFree: 0 kB AnonHugePages: 321536 kB ShmemPmdMapped: 0 kB Shared_Hugetlb: 0 kB Private_Hugetlb: 0 kB Swap: 758060 kB SwapPss: 758060 kB Locked: 0 kB VmFlags: rd wr mr mw me ac sd Any ideas on how to further debug this are very welcome. Regards, Rik -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 <>
Bug#946941: memory leak fixes in 2.2.11 and 2.2.12
Hi, It seems the newer upstream releases 2.2.11 and 2.2.12 fix memory issues: https://github.com/apple/cups/releases/tag/v2.2.11 https://github.com/apple/cups/releases/tag/v2.2.12 Would it be possible to backport those fixes to the Debian package? Regards, Rik -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 <>
Bug#946941: cups: Memory leak in cupsd
Package: cups Version: 2.2.10-6+deb10u1 Severity: important Hi, After upgrading our print server from Debian 9 to 10, we frequently get notified by our monitoring system that the server is running out of memory. It seems there's a memory leak in cupsd. The memory usage starts at about 3.8% and can grow to 98% of system memory. When I monitor the memory usage of the cupsd process with top, and then run the following command in a terminal on the print server, I can see the memory usage grow with each invocation: lpstat -W completed -u The memory usage is increased and never decreased again. The memory usage also increases with other commands (although not as much), such as 'lpstat -a'. I assume client systems trigger the same issue when they query printer status. Just last night the memory usage went from about 100MB to 3GB in 23 minutes (cups was restarted by logrotate). A similar issue is described in the comments of https://askubuntu.com/questions/1160624/cupsd-service-high-memory-usage Regards, Rik -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cups depends on: ii cups-client2.2.10-6+deb10u1 ii cups-common2.2.10-6+deb10u1 ii cups-core-drivers 2.2.10-6+deb10u1 ii cups-daemon2.2.10-6+deb10u1 ii cups-filters 1.21.6-5 ii cups-ppdc 2.2.10-6+deb10u1 ii cups-server-common 2.2.10-6+deb10u1 ii debconf [debconf-2.0] 1.5.71 ii ghostscript9.27~dfsg-2+deb10u3 ii libavahi-client3 0.7-4+b1 ii libavahi-common3 0.7-4+b1 ii libc6 2.28-10 ii libcups2 2.2.10-6+deb10u1 ii libcupsimage2 2.2.10-6+deb10u1 ii libgcc11:8.3.0-6 ii libstdc++6 8.3.0-6 ii libusb-1.0-0 2:1.0.22-2 ii poppler-utils 0.71.0-5 ii procps 2:3.3.15-2 Versions of packages cups recommends: pn avahi-daemon ii colord 1.4.3-4 ii cups-filters [ghostscript-cups] 1.21.6-5 pn printer-driver-gutenprint Versions of packages cups suggests: ii cups-bsd 2.2.10-6+deb10u1 pn cups-pdf pn foomatic-db-compressed-ppds | foomatic-db ii hplip 3.18.12+dfsg0-2 ii printer-driver-hpcups 3.18.12+dfsg0-2 ii smbclient 2:4.9.5+dfsg-5+deb10u1 ii udev 241-7~deb10u2 -- Configuration Files: /etc/default/cups changed [not included] -- debconf information: cupsys/backend: lpd, socket, usb, snmp, dnssd cupsys/raw-print: true
Bug#863896: dnsmasq: systemd appends junk to the dnsmasq commandline
Package: dnsmasq Version: 2.76-5 Followup-For: Bug #863896 This issue seems to be caused by the recent upgrade of the dns-root-data package. The root.ds file in this new package contains two records where the previous version (2015052300+h+1) only had one record. The old version was also formatted with spaces, where the new one uses tabs. Downgrading dns-root-data to the previous version lets dnsmasq start again. This should be fixed in the dnsmasq init script where it parses /usr/share/dns/root.ds Regards, Rik -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dnsmasq depends on: ii dnsmasq-base 2.76-5+b1 ii init-system-helpers 1.48 ii netbase 5.4 dnsmasq recommends no packages. Versions of packages dnsmasq suggests: pn resolvconf -- Configuration Files: /etc/default/dnsmasq changed [not included] /etc/dnsmasq.conf changed [not included] -- no debconf information
Bug#856467: davical: Fails to create principals for LDAP users with modifyTimestamp configured since 1.1.5
Package: davical
Version: 1.1.5-1
Severity: important
Dear Maintainer,
When the configuration contains an LDAP mapping for the modified field
to modifyTimestamp,
davical fails to create a new user as there's an error in the code that
does the mapping.
The outcome is that the user is not created and can not login. Users
that were already
in the database of davical can login.
Version 1.1.3 from stable does not have this issue.
Relevant bits of our configuration:
'mapping_field' => array("username" => "uid",
"modified" => "modifyTimestamp",
"fullname" => "cn",
"user_no" => "uidNumber",
"email" => "mail"
), //used to create the user based on his
ldap properties
'format_updated' => array('Y' => array(0,4),'m' => array(4,2),'d'=>
array(6,2),'H' => array(8,2),'M'=>array(10,2),'S' => array(12,2)),
I've reported this upstream as issue 108.
https://gitlab.com/davical-project/davical/issues/108
I have cloned the repository here and it contains a fix for this issue:
https://gitlab.esat.kuleuven.be/Rik.Theys/davical
Regards,
Rik
-- System Information:
Debian Release: 8.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages davical depends on:
ii libawl-php 0.57-1~bpo8+1
ii libdbd-pg-perl 3.4.2-1
ii libyaml-perl 1.13-1
ii perl 5.20.2-3+deb8u6
ii php5 5.6.30+dfsg-0+deb8u1
ii php5-cli 5.6.30+dfsg-0+deb8u1
ii php5-pgsql 5.6.30+dfsg-0+deb8u1
ii postgresql-client-9.4 [postgresql-client] 9.4.10-0+deb8u1
Versions of packages davical recommends:
ii php5-curl 5.6.30+dfsg-0+deb8u1
ii postgresql 9.4+165+deb8u2
Versions of packages davical suggests:
ii php5-ldap 5.6.30+dfsg-0+deb8u1
-- Configuration Files:
/etc/davical/config.php changed [not included]
-- no debconf information
Bug#837770: obnam: list-errors produces python traceback
Package: obnam
Version: 1.19.1-1
Severity: minor
Hi,
Running 'obnam list-errors' produces a list of error messages and then crashes
with the following python traceback:
`EncryptionError` (`RD88CFX`)
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/cliapp/app.py", line 189, in _run
self.process_args(args)
File "/usr/lib/python2.7/dist-packages/obnamlib/app.py", line 208, in
process_args
cliapp.Application.process_args(self, args)
File "/usr/lib/python2.7/dist-packages/cliapp/app.py", line 589, in
process_args
method(args[1:])
File
"/usr/lib/python2.7/dist-packages/obnamlib/plugins/list_errors_plugin.py", line
40, in list_errors
f.write(': {}\n'.format(self.indent(error.msg).lstrip()))
File
"/usr/lib/python2.7/dist-packages/obnamlib/plugins/list_errors_plugin.py", line
44, in indent
s = ''.join(s.rstrip() + '\n' for s in s.splitlines())
AttributeError: 'NoneType' object has no attribute 'splitlines'
Regards,
Rik
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages obnam depends on:
ii libc6 2.23-5
ii python2.7.11-2
ii python-cliapp 1.20160724-1
ii python-fuse 2:0.2.1-14
ii python-larch 1.20151025-1
ii python-paramiko 2.0.0-1
ii python-tracing0.9-1
ii python-ttystatus 0.32-1
ii python-yaml 3.12-1
obnam recommends no packages.
obnam suggests no packages.
-- no debconf information
Bug#819302: Fixed in 4.1.18 release
Hi, Looking at the samba changelog this bug should be fixed in the 4.1.18 release. Would it be possible to backport this fix into the jessie package? Regards, Rik -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 <>
Bug#819302: samba: Some printers no longer work after upgrade from Wheezy - GUID issues
Package: samba Version: 2:4.1.17+dfsg-2+deb8u2 Severity: important Tags: patch Hi, After upgrading our print server from Wheezy to Jessie, windows clients can no longer connect to some of our printers. These printers have drivers available on the print server. The following error is logged for each printer that has this issue. [2016/03/26 10:06:23.845600, 0] ../source3/printing/nt_printing_ads.c:116(nt_printer_guid_get) Failed to get GUID for printer ev-ricoh-c2003 [2016/03/26 10:06:23.846099, 0] ../source3/rpc_server/spoolss/srv_spoolss_nt.c:4858(_spoolss_GetPrinter) _spoolss_GetPrinter: failed to construct printer info level 7 - WERR_BADFILE This issue is described in the following samba bug report and this bug report has a patch attached that should fix this bug. https://bugzilla.samba.org/show_bug.cgi?id=11018 The bug report also contains a workaround to fix this manually. Please consider applying the upstream patch to the debian package. Regards, Rik -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages samba depends on: ii adduser 3.113+nmu3 ii dpkg 1.17.26 ii libasn1-8-heimdal1.6~rc2+dfsg-9 ii libbsd0 0.7.0-2 ii libc62.19-18+deb8u3 ii libcomerr2 1.42.12-1.1 ii libhdb9-heimdal [heimdal-hdb-api-8] 1.6~rc2+dfsg-9 ii libkdc2-heimdal 1.6~rc2+dfsg-9 ii libkrb5-26-heimdal 1.6~rc2+dfsg-9 ii libldb1 2:1.1.17-2+deb8u1 ii libpam-modules 1.1.8-3.1+deb8u1 ii libpam-runtime 1.1.8-3.1+deb8u1 ii libpopt0 1.16-10 ii libpython2.7 2.7.9-2 ii libroken18-heimdal 1.6~rc2+dfsg-9 ii libtalloc2 2.1.1-2 ii libtdb1 1.3.1-1 ii libtevent0 0.9.21-1 ii lsb-base 4.1+Debian13+nmu1 ii multiarch-support2.19-18+deb8u3 ii procps 2:3.3.9-9 ii python 2.7.9-1 ii python-dnspython 1.12.0-1 ii python-ntdb 1.0-5 ii python-samba 2:4.1.17+dfsg-2+deb8u2 pn python2.7:any ii samba-common 2:4.1.17+dfsg-2+deb8u2 ii samba-common-bin 2:4.1.17+dfsg-2+deb8u2 ii samba-dsdb-modules 2:4.1.17+dfsg-2+deb8u2 ii samba-libs 2:4.1.17+dfsg-2+deb8u2 ii tdb-tools1.3.1-1 ii update-inetd 4.43 Versions of packages samba recommends: pn attr ii logrotate 3.8.7-1+b1 pn samba-vfs-modules Versions of packages samba suggests: ii bind9 1:9.9.5.dfsg-9+deb8u6 ii bind9utils 1:9.9.5.dfsg-9+deb8u6 pn ctdb pn ldb-tools ii ntp1:4.2.6.p5+dfsg-7+deb8u1 pn smbldap-tools ii winbind2:4.1.17+dfsg-2+deb8u2 -- debconf information: * samba/generate_smbpasswd: false samba-common/title: * samba/run_mode: daemons
Bug#811419: debian-installer: Provide option to disable local interaction with the installer if SSH access is enabled
Hi, On 01/18/2016 11:46 PM, Martin Michlmayr wrote: > * Rik Theys <rik.th...@esat.kuleuven.be> [2016-01-18 20:15]: >> When a preseed file is used to enable SSH access to the installer, the >> local user can still interfere with the installation process by using >> the local console. >> >> It would be nice to have an option to disable local interaction with >> the installer, so only remote access is allowed. > > Out of interest, what's the use case for this? We have Linux workstations in offices of users who don't have root permission on the (installed) system. When we upgrade the system we would like to prevent the user from interacting with the installer. We preseed all installation settings except the root password and partitioning. We can use the SSH access to the installer to remotely finish the installation, but the user can also set the password on the system as the installer also asks the questions locally. We would like to prevent this. It would be nice to have like a 'network-console/remote-only' option to only allow remote interaction with the installer. The local display could then show a message that the admin is doing the installation remotely and to not touch the system. On RHEL/Fedora we can use the vnc option so the installer is only available over VNC. I'm aware that this is not perfect and that the end-user can always gain access to the system as (s)he has physical access, but (s)he would have to abort the installation which is immediately noticed by the admin doing the remote install. Regards, Rik -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 <>
Bug#811419: debian-installer: Provide option to disable local interaction with the installer if SSH access is enabled
Package: debian-installer Severity: wishlist Hi, When a preseed file is used to enable SSH access to the installer, the local user can still interfere with the installation process by using the local console. It would be nice to have an option to disable local interaction with the installer, so only remote access is allowed. This would provide the same possibilities as is possible with the 'vnc noshell' option on RHEL/Fedora installers. In our case we don't preseed the root password and partitioning so these are the only questions still asked by the installer. Those questions are asked both on the console and via SSH. Regards, Rik -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#778891: [Pkg-puppet-devel] Bug#778891: puppet: systemd unit file does not load environment from /etc/default/puppet - breaks upgrades
Hi, On 02/23/2015 11:56 AM, Stig Sandbeck Mathisen wrote: I'm not going to add it back, but unless I'm missing something in the scenario I've outlined above, I don't agree there are no security implications here. There is a bug, which should be fixed. I've upgraded it to serious again, so it is release critical. Thanks. Can you also remove the 'wontfix' tag? There are security implications, but as it needs administrative privileges to your DNS server or physical access to your network to exploit. (Or, you need to place your laptop running puppet on a hostile network, which is more likely.) In our environment we have systems managed centrally and systems managed by research groups but they share the same dns domain. I don't think they would appreciate it if their systems suddenly started to contact our puppet server :-). Regards, Rik -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758870: Supposedly going to be fixed in kernel v3.18
Hi, I've had a similar issue with Fedora's 3.17 kernel and indeed it was fixed after an upgrade to 3.18. If Jessie has the same bug, I agree it should best be fixed prior to its release. As a workaround on the 3.17 kernel I started the RPC idmapd service. This service is normally no longer required on clients (as they use the keyring thing now), but it worked around this bug for me. It may be a workaround on Jessie also. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778891: [Pkg-puppet-devel] Bug#778891: puppet: systemd unit file does not load environment from /etc/default/puppet - breaks upgrades
Hi, On Sat, 21 Feb 2015, Stig Sandbeck Mathisen wrote: Rik Theys rik.th...@esat.kuleuven.be writes: During an upgrade from wheezy to jessie, puppet was upgraded to 3.7.2 and systemd became the default init system. When jessie is released, an upgrade should keep the current init system. I was under the impression that upgrades from Wheezy to Jessie would switch the init system to systemd by default, unless a pin was configured prior to the upgrade (as instructed in the draft release notes)? Or do you mean upgrades from Jessie to Jessie+1 (Stretch?)? In our environment, our puppet master is not called puppet and we override this setting using the DAEMON_OPTS variable in /etc/default/puppet: DAEMON_OPTS=--server our-puppet-master.ourdomain.tld The wheezy (and jessie) init script supports this, but the systemd unit file for puppet does not read this environment file and defaults back to the puppet DNS name for puppet masters. The fix for this is simple and a patch for the systemd unit file is attached: the unit file should have an EnvironmentFile statement to load the environment from /etc/default/puppet (if it exists). The /etc/default/puppet file is not shipped with the puppet packaging, but is checked for in the sysv init script as a means to override the configuration. I installed the puppet package on a different Wheezy system to verify and it gets installed. 'dpkg -L puppet' also lists the file. For systemd, please use override your systemd unit with one of: * A fragment in /etc/systemd/system/puppet.service.d/something.conf This is how I've done if for now. Please consider setting server under the [main] section in /etc/puppet/puppet.conf. This will work no matter which init is used. This is probably indeed the best solution. I've flagged this as security as an upgrade from wheezy to jessie could open a system to a puppet server controlled by someone else. In case the puppet client did not yet have signed certificate it could be signed by the puppet puppet master, which could then execute arbitrary actions on the system. The puppet agent starts disabled with puppet agent --disable, and has to be manually enabled with puppet agent --enable. Even disabled, the puppet agent will connect to the master, send its CSR, and ask for a signed certificate periodically. You've lost me. Where in the init script is puppet started with --disable? Imagine I have a wheezy system with puppet installed and I've never updated /etc/default/puppet to change the START variable to have it started, my system would never have contacted any puppet master and would not have any certs. (we can argue that is doesn't make sense to have it installed if you're not using it, but there would be no security impact if you did as it wouldn't start by default). When I then upgrade this wheezy system to jessie, my system will suddenly start puppet (as the init script/systemd unit no longer checks the START condition) and will send a certificate request to a puppet host on my network, which might not be under my control. If the admin of this rogue puppet master signs it and configures a manifest for my system, my system will happily apply it. Am I missing something? If this is correct, my opinion is that this has security implications. Looking at the puppet postinst snippet of the jessie package I don't see any logic to only enable puppet when it was already enabled (by checking the START variable) before? If it is manually enabled, and still connects to a master someone has successfully installed on your network after having changed your domain to add the puppet name to point to that puppet master, I would suggest this is not primarily a security fault in the puppet agent packaging. If you need to configure /etc/default/puppet with command line options for a puppet master, install puppet agent, have it not to connect to the master, upgrade it from wheezy to jessie, then change init systems, and _then_ start the puppet agent, the window of opportunity for such an attacker is rather small. If the puppet agent has a puppet certificate, the puppet agent will abort with a SSL error when connecting to the new master, since the CA will differ. I know but if the wheezy installation had the puppet package installed but never had the START variable adjusted, it would not have any certificates to verify. If your puppet master is not called puppet in your enterprise it would not make a difference as the client would not be able to resolve it. But once it connects to a network that does have a 'puppet' machine, it would send its CSR to that node. This scenario is not very likely; I have removed the security tag. I'm not going to add it back, but unless I'm missing something in the scenario I've outlined above, I don't agree there are no security implications here. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas
Bug#778891: puppet: systemd unit file does not load environment from /etc/default/puppet - breaks upgrades
Package: puppet Version: 3.7.2-2 Severity: grave Tags: patch security Justification: user security hole Hi, During an upgrade from wheezy to jessie, puppet was upgraded to 3.7.2 and systemd became the default init system. In our environment, our puppet master is not called puppet and we override this setting using the DAEMON_OPTS variable in /etc/default/puppet: DAEMON_OPTS=--server our-puppet-master.ourdomain.tld The wheezy (and jessie) init script supports this, but the systemd unit file for puppet does not read this environment file and defaults back to the puppet DNS name for puppet masters. The fix for this is simple and a patch for the systemd unit file is attached: the unit file should have an EnvironmentFile statement to load the environment from /etc/default/puppet (if it exists). The patch only brings back support for the DAEMON_OPTS option, and not for the variable to prevent startup. I've flagged this as security as an upgrade from wheezy to jessie could open a system to a puppet server controlled by someone else. In case the puppet client did not yet have signed certificate it could be signed by the puppet puppet master, which could then execute arbitrary actions on the system. I did not check if the postinst script only enables the systemd unit when the START variable in /etc/default/puppet is set to yes. If it doesn't, the puppet service will be started on upgrades to jessie (and systemd), even if it was disabled before. It would also introduce the problem above by contacting the wrong puppet master. Regards, Rik -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages puppet depends on: ii init-system-helpers 1.22 ii puppet-common 3.7.2-2 ii ruby1:2.1.0.4 ii ruby2.1 [ruby-interpreter] 2.1.5-1 puppet recommends no packages. Versions of packages puppet suggests: pn etckeeper none pn puppet-el none pn vim-puppet none -- Configuration Files: /etc/default/puppet e3a89dd703e6b796ef7889ba75af2df7 [Errno 2] No such file or directory: u'/etc/default/puppet e3a89dd703e6b796ef7889ba75af2df7' /etc/logrotate.d/puppet 037c34a239a8895833388ccfce278adc [Errno 2] No such file or directory: u'/etc/logrotate.d/puppet 037c34a239a8895833388ccfce278adc' -- no debconf information --- puppet.service.orig 2015-02-21 12:05:48.26000 +0100 +++ puppet.service 2015-02-21 12:06:07.37600 +0100 @@ -4,7 +4,8 @@ [Service] Type=forking PIDFile=/run/puppet/agent.pid -ExecStart=/usr/bin/puppet agent +EnvironmentFile=-/etc/default/puppet +ExecStart=/usr/bin/puppet agent $DAEMON_OPTS [Install] WantedBy=multi-user.target
Bug#778249: linux-tools-3.16: Please include the x86_energy_perf_policy and turbostat tool on x86
Package: linux-tools-3.16 Version: 3.16-3 Severity: wishlist Hi, Would it be possible to include the x86_energy_perf_policy and turbostat tool on x86 builds of linux-tools? It allows you to set the x86 performance policy of the CPU, and a tool to monitor the CPU states of recent intel processors. Regards, Rik -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-tools-3.16 depends on: ii libaudit1 1:2.4-1+b1 ii libc6 2.19-13 ii libdw10.159-4 ii libelf1 0.159-4 ii libnuma1 2.0.10-1 ii libperl5.20 5.20.1-5 ii libpython2.7 2.7.8-11 ii libslang2 2.3.0-2 ii libunwind81.1-3.2 ii perl 5.20.1-5 pn python:anynone Versions of packages linux-tools-3.16 recommends: ii linux-base 3.5 Versions of packages linux-tools-3.16 suggests: pn linux-doc-3.16 none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778251: linux-image-3.16.0-4-amd64: x86_energy_perf_policy of cpu0 switches to performance after suspend to ram
Package: src:linux Version: 3.16.7-ckt4-3 Severity: normal Hi, I was playing with the x86_energy_perf_policy tool to change the energy performance policy of the CPU. When the system boots, it indicates it has switched the CPU to the 'normal' perf_policy (from 'performance'). [0.011281] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8) When checked with the x86_energy_perf_policy tools, this looks OK: rik@earth:~/bin$ sudo ./x86_energy_perf_policy -v -r CPUID.06H.ECX: 0x9 cpu0: 0x0006 cpu1: 0x0006 cpu2: 0x0006 cpu3: 0x0006 6 seems to indicate 'normal' on my CPU. To check the values, I configured the CPU to enter 'normal': rik@earth:~/bin$ sudo ./x86_energy_perf_policy -v normal CPUID.06H.ECX: 0x9 cpu0 msr0x1b0 0x0006 - 0x0006 cpu1 msr0x1b0 0x0006 - 0x0006 cpu2 msr0x1b0 0x0006 - 0x0006 cpu3 msr0x1b0 0x0006 - 0x0006 For 'performance', the tool sets the msr to 0 at the end: rik@earth:~/bin$ sudo ./x86_energy_perf_policy -v performance CPUID.06H.ECX: 0x9 cpu0 msr0x1b0 0x0006 - 0x cpu1 msr0x1b0 0x0006 - 0x cpu2 msr0x1b0 0x0006 - 0x cpu3 msr0x1b0 0x0006 - 0x Now, when the system boots, all cpu's are correctly set to 'normal'. But when I suspend to RAM and wake the system again, cpu0's perf_policy is set to performance again. The other cpu's remain at the normal policy: rik@earth:~/bin$ sudo ./x86_energy_perf_policy -v -r CPUID.06H.ECX: 0x9 cpu0: 0x cpu1: 0x0006 cpu2: 0x0006 cpu3: 0x0006 It seems the perf_policy is not restored on resume for cpu0. My system has the following cpu: rik@earth:~/bin$ lscpu Architecture: x86_64 CPU op-mode(s):32-bit, 64-bit Byte Order:Little Endian CPU(s):4 On-line CPU(s) list: 0-3 Thread(s) per core:2 Core(s) per socket:2 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family:6 Model: 58 Model name:Intel(R) Core(TM) i5-3360M CPU @ 2.80GHz Stepping: 9 CPU MHz: 3433.390 CPU max MHz: 3500. CPU min MHz: 1200. BogoMIPS: 5581.57 Virtualization:VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 3072K NUMA node0 CPU(s): 0-3 Regards, Rik -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-ker...@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=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/vg_earth-root ro elevator=deadline quiet systemd.show_status=1 splash ** Not tainted ** Kernel log: [ 401.220242] pci :00:1f.3: using default PCI settings [ 401.220384] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [ 401.220402] ivb_uncore :00:00.0: no hotplug settings from platform [ 401.220407] ivb_uncore :00:00.0: using default PCI settings [ 401.220422] i915 :00:02.0: no hotplug settings from platform [ 401.220427] i915 :00:02.0: using default PCI settings [ 401.220442] xhci_hcd :00:14.0: no hotplug settings from platform [ 401.220447] xhci_hcd :00:14.0: using default PCI settings [ 401.220467] mei_me :00:16.0: no hotplug settings from platform [ 401.220472] mei_me :00:16.0: using default PCI settings [ 401.220489] e1000e :00:19.0: no hotplug settings from platform [ 401.220494] e1000e :00:19.0: using default PCI settings [ 401.220513] ehci-pci :00:1a.0: no hotplug settings from platform [ 401.220518] ehci-pci :00:1a.0: using default PCI settings [ 401.220537] snd_hda_intel :00:1b.0: no hotplug settings from platform [ 401.220548] pcieport :00:1c.0: no hotplug settings from platform [ 401.220559] pcieport :00:1c.1: no hotplug settings from platform [ 401.220600] pcieport :00:1c.2: no hotplug settings from platform [ 401.220610] pcieport :00:1c.3: no hotplug settings from platform [ 401.220620] pcieport :00:1c.5: no hotplug settings from platform [ 401.220668] ehci-pci :00:1d.0: no hotplug settings from platform [ 401.220673] ehci-pci :00:1d.0: using default PCI settings [ 401.220693] lpc_ich :00:1f.0: no hotplug settings from platform [ 401.220698] lpc_ich :00:1f.0: using default PCI settings [ 401.220717] ahci :00:1f.2: no hotplug settings from platform [ 401.220723] ahci :00:1f.2: using default PCI settings [ 401.220740] pci :00:1f.3: no hotplug settings from platform [ 401.220745] pci :00:1f.3: using default PCI settings [ 401.220790] i915 :00:02.0: BAR 6: [???
Bug#777165: Update affected kernels
found 777165 3.18.5-1~exp1 forwarded 777165 https://bugzilla.kernel.org/show_bug.cgi?id=92871 stop This bug is also present in the 3.18 kernel from experimental. I've also tested this on 3.19-rc7 and it also has this bug. I filed an upstream bug at https://bugzilla.kernel.org/show_bug.cgi?id=92871 Regards, Rik
Bug#777165: linux-image-3.16.0-4-amd64: WARNING and guest crash when using nested virtualisation
Hi, On Fri, Feb 6, 2015 at 6:57 AM, Jérôme Deuchnord debian-li...@deuchnord.tk wrote: I have the same problem, and wrote a bug, but nobody answered me: https://lists.debian.org/20150131113439.1239.79224.reportbug@JeromeTanghe-Debian The screen on the photo doesn't say the same thing, but sometimes my PC writes these messages too... I looked at the stack trace in your screenshot. This does not look like the same issue I'm experiencing. Your stack trace doesn't mention kvm-intel. Regards, Rik
Bug#777165: Looks similar to RHEL bug
Hi, This bug looks like a similar bug in the RHEL bugzilla: https://bugzilla.redhat.com/show_bug.cgi?format=multipleid=1086058 Regards, Rik
Bug#777165: linux-image-3.16.0-4-amd64: WARNING and guest crash when using nested virtualisation
Package: src:linux Version: 3.16.7-ckt4-3 Severity: normal Hi, I enabled nested virtualisation on the kvm_intel module and created a virtual machine (using virt-manager). The VM had the host cpu flags copied so it also had the vmx cpu flag. Inside this VM I configured another virtual machine (also using virt-manager). As soon as the new VM (inside the first VM) is launched, the following WARNING is reported on the host kernel and the first VM reboots. [ 187.013217] [ cut here ] [ 187.013242] WARNING: CPU: 1 PID: 2394 at /build/linux-y7bjb0/linux-3.16.7-ckt4/arch/x86/kvm/vmx.c:8699 nested_vmx_vmexit+0x7f3/0x820 [kvm_intel]() [ 187.013245] Modules linked in: vhost_net vhost macvtap macvlan tun xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat ipt_REJECT bridge stp llc bnep bluetooth 6lowpan_iphc binfmt_misc cpufreq_userspace cpufreq_powersave cpufreq_conservative cpufreq_stats nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter ip_tables x_tables snd_hda_codec_hdmi cx88_blackbird cx2341x cx22702 iTCO_wdt iTCO_vendor_support cx88_dvb cx88_vp3054_i2c videobuf_dvb arc4 dvb_core wm8775 tuner_simple tuner_types tda9887 tda8290 coretemp tuner snd_hda_codec_via snd_hda_codec_generic rt61pci rt2x00pci rt2x00mmio rt2x00lib snd_hda_intel joydev evdev cx8802 snd_hda_controller snd_hda_codec eeprom_93cx6 snd_hwdep mac80211 [ 187.013297] cx8800 cx88_alsa snd_pcm cfg80211 cx88xx kvm_intel kvm snd_timer psmouse serio_raw nouveau btcx_risc tveeprom mxm_wmi wmi video videobuf_dma_sg videobuf_core rc_core rfkill i7core_edac ttm drm_kms_helper v4l2_common drm videodev snd edac_core i2c_i801 soundcore media i2c_algo_bit i2c_core shpchp lpc_ich mfd_core asus_atk0110 button acpi_cpufreq processor thermal_sys loop firewire_sbp2 fuse parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 btrfs xor raid6_pq dm_mod raid1 raid0 md_mod sg sd_mod crc_t10dif crct10dif_generic sr_mod cdrom crct10dif_common hid_generic usbhid hid usb_storage crc32c_intel ahci libahci libata firewire_ohci xhci_hcd scsi_mod ehci_pci r8169 ehci_hcd firewire_core crc_itu_t mii usbcore usb_common [ 187.013374] CPU: 1 PID: 2394 Comm: qemu-system-x86 Not tainted 3.16.0-4-amd64 #1 Debian 3.16.7-ckt4-3 [ 187.013376] Hardware name: System manufacturer System Product Name/P7P55D-E, BIOS 150412/14/2010 [ 187.013379] 0009 815096a7 810676f7 [ 187.013383] 8800a498f000 0014 [ 187.013387] a083dec3 a0734daf [ 187.013391] Call Trace: [ 187.013399] [815096a7] ? dump_stack+0x41/0x51 [ 187.013406] [810676f7] ? warn_slowpath_common+0x77/0x90 [ 187.013416] [a083dec3] ? nested_vmx_vmexit+0x7f3/0x820 [kvm_intel] [ 187.013435] [a0734daf] ? kvm_mmu_load+0x26f/0x400 [kvm] [ 187.013452] [a0727d25] ? kvm_arch_vcpu_ioctl_run+0xde5/0x1110 [kvm] [ 187.013458] [810d1a3f] ? futex_wake+0x6f/0x120 [ 187.013471] [a0712a51] ? kvm_vcpu_ioctl+0x2f1/0x590 [kvm] [ 187.013477] [811eb978] ? eventfd_ctx_read+0x58/0x1e0 [ 187.013482] [81096ad0] ? wake_up_state+0x10/0x10 [ 187.013487] [811b9dcf] ? do_vfs_ioctl+0x2cf/0x4b0 [ 187.013491] [811ebb37] ? eventfd_read+0x37/0x60 [ 187.013506] [a071bfcc] ? kvm_on_user_return+0x4c/0x80 [kvm] [ 187.013510] [811ba031] ? SyS_ioctl+0x81/0xa0 [ 187.013515] [8150fa2a] ? int_signal+0x12/0x17 [ 187.013520] [8150f76d] ? system_call_fast_compare_end+0x10/0x15 [ 187.013523] ---[ end trace ae3922755979b8ad ]--- When I retry to create the VM inside the first VM, the first VM keeps on crashing but the WARNING is not repeated on the host kernel. But I assume this is by design. Regards, Rik -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-ker...@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=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/vg_saturn-root ro init=/bin/systemd audit=1 quiet systemd.show_status=1 ** Tainted: W (512) * Taint on warning. ** Kernel log: [ 12.610352] [TTM] Initializing DMA pool allocator [ 12.610362] nouveau [ DRM] VRAM: 512 MiB [ 12.610366] nouveau [ DRM] GART: 1048576 MiB [ 12.610369] nouveau [ DRM] TMDS table version 2.0 [ 12.610371] nouveau [ DRM] DCB version 4.0 [ 12.610372] nouveau [ DRM] DCB outp 00: 02000300 [ 12.610374] nouveau [ DRM] DCB outp 01: 01000302 00020030 [ 12.610375] nouveau [ DRM] DCB outp 02: 01011310 [ 12.610377] nouveau [ DRM] DCB outp 03: 02032362 00020010 [ 12.610378] nouveau [ DRM] DCB conn 00: 1030 [ 12.610379] nouveau [ DRM] DCB conn 01:
Bug#771718: general: Screen blanks and does not come back up unless system is suspended
Package: general Severity: normal Hi, I was thus far unable to pinpoint which component causes this behaviour as I can not find anything in my logs (and/or journal). I have therefore assigned it to general. Feel free to change to a more appropriate package. I'm using KDE on Jessie with gdm3 as the login manager. The system has systemd installed. When the system is idle for few minutes (but before the limit set in the KDE screensaver settings), the screen will blank and will not come back on keypress or mouse movements. I have to close the lid of the laptop to let the system suspend. After resume I will get the unlock window of the screensaver and can continue working. I can login using SSH when this happens but couldn't find anything in the logs that could explain this. Any ideas on how to further debug this issue is appreciated. Are there any other reports about similar behaviour? Regards, Rik -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754855: linux-image-3.14-1-amd64: backport PowerEdge VRTX driver from 3.15 to 3.14 kernel
Package: src:linux Version: 3.14.12-1 Severity: wishlist Hi, If the 3.14 kernel will be the kernel for Jessie, please consider backporting support for the Dell PowerEdge VRTX storage. Support for this was first introduced with the 3.15 kernel in the following commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=229fe47cd046ef2d01c13298293cda9693811417 This driver allows Linux on the VRTX blades to access the shared storage in the enclosure. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731270: libmount1: remount sometimes fails on boot with systemd (fixed upstream)
Package: libmount1 Version: 2.20.1-5.5 Severity: normal Dear Maintainer, I use systemd as init. Sometimes during boot-up systemd spawns the emergency shell because it failed to mount my /home (which is on LVM on MD raid). According to the log file this is because the file system was already mounted or busy. This seems to happen whenever systemd runs an fsck on the file system first. Dec 03 19:54:32 saturn systemd[1]: Starting File System Check on /dev/mapper/vg_saturn-home... Dec 03 19:54:32 saturn lvm2[1661]: Setting up LVM Volume Groups...done. Dec 03 19:54:32 saturn systemd[1]: Started lvm2.service. Dec 03 19:54:32 saturn systemd[1]: Started File System Check on /dev/mapper/vg_stripe-stripe. Dec 03 19:54:32 saturn systemd[1]: Mounting /srv/scratch... Dec 03 19:54:32 saturn systemd[1]: Found device /dev/mapper/vg_saturn-swap. Dec 03 19:54:32 saturn systemd[1]: Activating swap /dev/mapper/vg_saturn-swap... Dec 03 19:54:32 saturn systemd-fsck[1773]: /dev/mapper/vg_saturn-home: clean, 62243/37486592 files, 132761085/1499 Dec 03 19:54:32 saturn systemd[1]: Mounted /srv/scratch. Dec 03 19:54:32 saturn kernel: EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null) Dec 03 19:54:32 saturn systemd[1]: Activated swap /dev/mapper/vg_saturn-swap. Dec 03 19:54:32 saturn systemd[1]: Starting Swap. Dec 03 19:54:32 saturn systemd[1]: Reached target Swap. Dec 03 19:54:32 saturn kernel: Adding 8388604k swap on /dev/mapper/vg_saturn-swap. Priority:-1 extents:1 across:8 Dec 03 19:54:32 saturn systemd-udevd[1796]: failed to execute '/lib/udev/socket:@/org/freedesktop/hal/udev_event' Dec 03 19:54:32 saturn systemd[1]: Started File System Check on /dev/mapper/vg_saturn-home. Dec 03 19:54:32 saturn systemd[1]: Mounting /home... Dec 03 19:54:32 saturn mount[1805]: mount: /dev/mapper/vg_saturn-home already mounted or /home busy Dec 03 19:54:32 saturn systemd[1]: home.mount mount process exited, code=exited status=32 Dec 03 19:54:32 saturn systemd[1]: Failed to mount /home. Dec 03 19:54:32 saturn systemd[1]: Dependency failed for Local File Systems. Dec 03 19:54:32 saturn systemd[1]: Triggering OnFailure= dependencies of local-fs.target. Dec 03 19:54:32 saturn systemd-udevd[1807]: failed to execute '/lib/udev/socket:@/org/freedesktop/hal/udev_event' Dec 03 19:54:32 saturn systemd[1]: Unit home.mount entered failed state. This looks very similar to the following Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=873983 In Fedora this was fixed by upgrading to util-linux 2.21.2. Since Debian still has version 2.20 I believe this bug could be fixed by upgrading to a newer upstream version. Please consider upgrading to a newer util-linux version. Regards, Rik -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libmount1 depends on: ii libblkid1 2.20.1-5.5 ii libc6 2.17-97 ii libselinux12.2.1-1 ii libsepol1 2.2-1 ii multiarch-support 2.17-97 libmount1 recommends no packages. libmount1 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729805: systemd: fails to show startup messages with systemd.show_status=1
Hi, I've created a bug report in the freedesktop.org bug tracker: https://bugs.freedesktop.org/show_bug.cgi?id=72282 Regards, Rik On Thu, Nov 28, 2013 at 10:54 AM, Rik Theys rik.th...@gmail.com wrote: Hi, Thanks for investigating this! Please forward the bug upstream. Regards, Rik On Wed, Nov 27, 2013 at 9:41 PM, Michael Stapelberg stapelb...@debian.org wrote: control: tags -1 + upstream Hi Rik, Rik Theys rik.th...@gmail.com writes: The complete command line is: $ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.11-2-amd64 root=/dev/mapper/vg_earth-root ro elevator=deadline init=/bin/systemd systemd.show_status=1 acpi_backlight=vendor acpi_osi=Linux quiet On Fedora: $ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.11.8-200.fc19.x86_64 root=/dev/mapper/vg_lucifer-root ro rd.lvm.lv=vg_lucifer/swap rd.dm=0 rd.luks=0 rd.md.uuid=e10bb37b:c4d7dd2e:a7e5d7a5:bf92e861 LANG=en_US.UTF-8 rd.lvm.lv=vg_lucifer/root rd.md.uuid=ab201cc0:2553b487:1596c82a:81dfa07f quiet systemd.show_status=1 plymouth.enable=0 The difference here is that in your Debian command line, you have quiet _after_ the systemd.show_status=1, in the Fedora command line, you have quiet _before_ the systemd.show_status=1. If you look at the code, as soon as systemd encounters the quiet option, it will set arg_show_status = false: http://cgit.freedesktop.org/systemd/systemd/tree/src/core/main.c?id=8cf030b349cbcb0901d880c9165d785dfc9cd569#n413 So, this is actually an upstream bug. Can you please report it upstream, ideally with a patch fixing the issue, or do you need us to forward it? -- Best regards, Michael -- Rik -- Rik
Bug#729805: systemd: fails to show startup messages with systemd.show_status=1
Hi, Thanks for investigating this! Please forward the bug upstream. Regards, Rik On Wed, Nov 27, 2013 at 9:41 PM, Michael Stapelberg stapelb...@debian.orgwrote: control: tags -1 + upstream Hi Rik, Rik Theys rik.th...@gmail.com writes: The complete command line is: $ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.11-2-amd64 root=/dev/mapper/vg_earth-root ro elevator=deadline init=/bin/systemd systemd.show_status=1 acpi_backlight=vendor acpi_osi=Linux quiet On Fedora: $ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.11.8-200.fc19.x86_64 root=/dev/mapper/vg_lucifer-root ro rd.lvm.lv=vg_lucifer/swap rd.dm=0 rd.luks=0 rd.md.uuid=e10bb37b:c4d7dd2e:a7e5d7a5:bf92e861 LANG=en_US.UTF-8 rd.lvm.lv=vg_lucifer/root rd.md.uuid=ab201cc0:2553b487:1596c82a:81dfa07f quiet systemd.show_status=1 plymouth.enable=0 The difference here is that in your Debian command line, you have quiet _after_ the systemd.show_status=1, in the Fedora command line, you have quiet _before_ the systemd.show_status=1. If you look at the code, as soon as systemd encounters the quiet option, it will set arg_show_status = false: http://cgit.freedesktop.org/systemd/systemd/tree/src/core/main.c?id=8cf030b349cbcb0901d880c9165d785dfc9cd569#n413 So, this is actually an upstream bug. Can you please report it upstream, ideally with a patch fixing the issue, or do you need us to forward it? -- Best regards, Michael -- Rik
Bug#729805: systemd: fails to show startup messages with systemd.show_status=1
reopen 729805 thanks Hi Michael, On Sun, Nov 17, 2013 at 8:43 PM, Michael Biebl bi...@debian.org wrote: Am 17.11.2013 16:34, schrieb Rik Theys: To show the systemd startup messages (OK Starting/started/...), I added systemd.show_status=1 to /etc/default/grub and updated the grub config. No messages (except for the systemd-fsck messages) are shown during startup. After startup, /proc/cmdline shows that systemd.show_status=1 was set, together with quiet. The systemd.show_status=1 should be necessary when quiet is also specified but does not seem to have any effect. quiet implies systemd.show_status=0 (read the systemd man page) and you passed systemd.show_status=1, so those two options conflict. On my fedora system here the man page says that adding quiet merely changes the default value of systemd.show_status. If it is explicitly set, the value should be honoured. systemd.show_status= Takes a boolean argument. If true shows terse service status updates on the console during bootup. Defaults to true, unless quiet is passed as kernel command line option in which case it defaults to false. Adding quiet _and_ systemd.show_status=1 works as expected on my Fedora 19, but not on Debian. On Fedora it shows the sytemd messages but not the kernel messages (due to the quiet). On Debian it shows nothing (except for the systemd-fsck ones). Regards, Rik
Bug#729805: systemd: fails to show startup messages with systemd.show_status=1
Hi, The complete command line is: $ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.11-2-amd64 root=/dev/mapper/vg_earth-root ro elevator=deadline init=/bin/systemd systemd.show_status=1 acpi_backlight=vendor acpi_osi=Linux quiet On Fedora: $ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.11.8-200.fc19.x86_64 root=/dev/mapper/vg_lucifer-root ro rd.lvm.lv=vg_lucifer/swap rd.dm=0 rd.luks=0 rd.md.uuid=e10bb37b:c4d7dd2e:a7e5d7a5:bf92e861 LANG=en_US.UTF-8 rd.lvm.lv=vg_lucifer/root rd.md.uuid=ab201cc0:2553b487:1596c82a:81dfa07f quiet systemd.show_status=1 plymouth.enable=0 Regards, Rik On Mon, Nov 18, 2013 at 5:29 PM, Michael Biebl bi...@debian.org wrote: Please paste the complete kernel command line: cat /proc/cmdline -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- Rik
Bug#728909: linux-image-3.11-1-amd64: kernel WARNING in tcp_input.c:2711 tcp_fastretrans_alert
Package: src:linux Version: 3.11.6-2 Severity: normal Hi, I received the following WARNING in my kernel messages: [ 846.633954] WARNING: CPU: 0 PID: 553 at /build/linux-iRt5Ta/linux-3.11.6/net/ipv4/tcp_input.c:2711 tcp_fastretrans_alert+0xb72/0xba0() [ 846.633955] Modules linked in: ebtable_nat ebtables dell_wmi sparse_keymap joydev ppdev binfmt_misc lp ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipt_REJECT xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter ip_tables x_tables iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal arc4 snd_hda_codec_hdmi snd_hda_codec_idt iwldvm dell_laptop mac80211 dcdbas snd_hda_intel coretemp snd_hda_codec microcode psmouse snd_hwdep serio_raw snd_pcm uvcvideo snd_page_alloc snd_seq videobuf2_vmalloc videobuf2_memops snd_seq_device videobuf2_core snd_timer videodev media snd i2c_i801 btusb bluetooth iwlwifi cfg80211 soundcore rfkill mei_me mei lpc_ich mfd_core wmi parport_pc parport mperf evdev ac battery processor kvm_intel kvm loop fuse autofs4 ext4 crc16 mbcache jbd2 dm_crypt dm_mod sg sr_mod sd_mod cdrom crc_t10dif crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 ablk_helper cryptd lrw gf128mul glue_helper ahci libahci libata scsi_mod e1000e ptp pps_core ehci_pci sdhci_pci xhci_hcd sdhci ehci_hcd i915 mmc_core video i2c_algo_bit drm_kms_helper drm usbcore usb_common i2c_core thermal thermal_sys button [ 846.634009] CPU: 0 PID: 553 Comm: irq/47-iwlwifi Not tainted 3.11-1-amd64 #1 Debian 3.11.6-2 [ 846.634010] Hardware name: Dell Inc. Latitude E6530/0JC5MT, BIOS A09 12/13/2012 [ 846.634011] 0009 81474882 81058442 [ 846.634013] 8801ee68f040 4320 0001 0003 [ 846.634015] 813db5b2 ee68f040 8801ee68f040 [ 846.634017] Call Trace: [ 846.634021] [81474882] ? dump_stack+0x41/0x51 [ 846.634024] [81058442] ? warn_slowpath_common+0x72/0x90 [ 846.634027] [813db5b2] ? tcp_fastretrans_alert+0xb72/0xba0 [ 846.634030] [813dc052] ? tcp_ack+0x9b2/0xf40 [ 846.634033] [a0711eec] ? ip6t_do_table+0x30c/0x6b5 [ip6_tables] [ 846.634036] [813dca71] ? tcp_rcv_established+0x161/0x840 [ 846.634039] [8144aea1] ? tcp_v6_do_rcv+0x2d1/0x610 [ 846.634041] [a0720322] ? ipv6_confirm+0xd2/0x130 [nf_conntrack_ipv6] [ 846.634043] [8144b7a5] ? tcp_v6_rcv+0x5c5/0x730 [ 846.634045] [81425dd0] ? ip6_rcv_finish+0x80/0x80 [ 846.634048] [813beb7e] ? nf_hook_slow+0x6e/0x130 [ 846.634050] [81425dd0] ? ip6_rcv_finish+0x80/0x80 [ 846.634052] [81425e90] ? ip6_input_finish+0xc0/0x400 [ 846.634056] [813930a7] ? __netif_receive_skb_core+0x5e7/0x820 [ 846.634058] [81393354] ? netif_receive_skb+0x24/0x80 [ 846.634062] [81065169] ? mod_timer+0x109/0x220 [ 846.634068] [a066ac5a] ? ieee80211_deliver_skb.isra.27+0x8a/0x200 [mac80211] [ 846.634074] [a066c069] ? ieee80211_rx_handlers+0xc29/0x2180 [mac80211] [ 846.634079] [a066da0c] ? ieee80211_prepare_and_rx_handle+0x44c/0xa60 [mac80211] [ 846.634084] [a066e311] ? ieee80211_rx+0x2f1/0x820 [mac80211] [ 846.634086] [81384919] ? __kmalloc_reserve.isra.26+0x29/0x80 [ 846.634090] [a06c73ab] ? iwlagn_rx_reply_rx+0x38b/0x500 [iwldvm] [ 846.634095] [a050bf1a] ? iwl_pcie_irq_handler+0x5fa/0xa60 [iwlwifi] [ 846.634098] [8101157b] ? __switch_to+0x11b/0x490 [ 846.634100] [810d3970] ? irq_finalize_oneshot.part.29+0xd0/0xd0 [ 846.634102] [810d3986] ? irq_thread_fn+0x16/0x40 [ 846.634103] [810d3c73] ? irq_thread+0x113/0x140 [ 846.634105] [810d39f0] ? irq_forced_thread_fn+0x40/0x40 [ 846.634106] [810d3b60] ? irq_thread_check_affinity+0xb0/0xb0 [ 846.634109] [81077f8f] ? kthread+0xaf/0xc0 [ 846.634111] [81077ee0] ? kthread_create_on_node+0x110/0x110 [ 846.634114] [81481b7c] ? ret_from_fork+0x7c/0xb0 [ 846.634116] [81077ee0] ? kthread_create_on_node+0x110/0x110 [ 846.634117] ---[ end trace a9e11ac92b0fb24d ]--- At first glance, I don't notice any side effects on my system. I'm using IPv6 with privacy extensions enabled. Don't know how reproducable this is. Regards, Rik -- Package-specific info: ** Version: Linux version 3.11-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.1 (Debian 4.8.1-10) ) #1 SMP Debian 3.11.6-2 (2013-11-01) ** Command line: BOOT_IMAGE=/vmlinuz-3.11-1-amd64 root=/dev/mapper/vg_earth-root ro elevator=deadline init=/bin/systemd systemd.show_status=true acpi_backlight=vendor acpi_osi=Linux quiet ** Tainted: W (512) * Taint on warning. ** Kernel log: [ 10.107392] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci:00/:00:1b.0/sound/card0/input8 [ 10.107460] input: HDA Intel PCH HDMI/DP,pcm=7 as
Bug#725906: linux-image-3.10-3-amd64: latency when increasing or decreasing brightness
Hi, I've experienced similar behaviour since the 3.9 kernels on my Dell Latitude 6530 Adding the following kernel parameter to the grub boot line has dramatically reduced the latency for me: acpi_backlight=vendor It might also make a difference for you. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#723098: linux-image-3.10-2-amd64: Setting screen backlight bightness extremely sluggish
Hi Marc, I'm experiencing similar behaviour on my Dell Latitude E6530: updating the brightness blocks (mouse) input and is very slow. Adding 'acpi_backlight=vendor' to the kernel parameters has helped a lot on my system to make the brightness updates less slow. It's still slower than it used to be, but has improved since I've added this parameter. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698780: BUG in nfs_mark_delegation_referenced after network outages
Hi, We seem to be hitting the same bug regarding NFS after a network interruption. We have one user here who can frequently trigger this bug by hibernating his system over lunch. The bug would trigger after resuming (not immediately, sometimes an hour later). I've installed the 3.7 kernel from experimental on his system and the bug was no longer triggered, so it's probably fixed upstream. Unfortunately the user is not very responsive in helping me track down which upstream kernel version introduced the fix, and I've been unable to reproduce the problem myself. Do you have a way of (reliably) triggering this bug? Regards, Rik -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699412: intel-microcode: Microcode for Xeon E5540 missing after upgrade from squeeze to wheezy
Package: intel-microcode Version: 1.20120606.v2.2 Severity: important Hi, After upgrading one of our servers from Squeeze to Wheezy, we noticed the cpu microcode was no longer being upgraded. The kernel messages indicated the needed microcode file was not found: 57360.773761] platform microcode: firmware: agent aborted loading intel-ucode/06-1a-05 (not found?) [57360.800626] microcode: CPU1 sig=0x106a5, pf=0x1, revision=0x11 [57360.822985] platform microcode: firmware: agent aborted loading intel-ucode/06-1a-05 (not found?) [57360.849827] microcode: CPU2 sig=0x106a5, pf=0x1, revision=0x11 [57360.871786] platform microcode: firmware: agent aborted loading intel-ucode/06-1a-05 (not found?) [57360.898530] microcode: CPU3 sig=0x106a5, pf=0x1, revision=0x11 [57360.920616] platform microcode: firmware: agent aborted loading intel-ucode/06-1a-05 (not found?) [57360.947446] microcode: CPU4 sig=0x106a5, pf=0x1, revision=0x11 [57360.969779] platform microcode: firmware: agent aborted loading intel-ucode/06-1a-05 (not found?) [57360.996561] microcode: CPU5 sig=0x106a5, pf=0x1, revision=0x11 [57361.018533] platform microcode: firmware: agent aborted loading intel-ucode/06-1a-05 (not found?) [57361.045313] microcode: CPU6 sig=0x106a5, pf=0x1, revision=0x11 [57361.067445] platform microcode: firmware: agent aborted loading intel-ucode/06-1a-05 (not found?) [57361.094153] microcode: CPU7 sig=0x106a5, pf=0x1, revision=0x11 [57361.116573] platform microcode: firmware: agent aborted loading intel-ucode/06-1a-05 (not found?) [57361.143551] microcode: CPU8 sig=0x106a5, pf=0x1, revision=0x11 [57361.165602] platform microcode: firmware: agent aborted loading intel-ucode/06-1a-05 (not found?) [57361.192287] microcode: CPU9 sig=0x106a5, pf=0x1, revision=0x11 [57361.214418] platform microcode: firmware: agent aborted loading intel-ucode/06-1a-05 (not found?) [57361.241367] microcode: CPU10 sig=0x106a5, pf=0x1, revision=0x11 [57361.264347] platform microcode: firmware: agent aborted loading intel-ucode/06-1a-05 (not found?) [57361.291217] microcode: CPU11 sig=0x106a5, pf=0x1, revision=0x11 [57361.313523] platform microcode: firmware: agent aborted loading intel-ucode/06-1a-05 (not found?) [57361.340494] microcode: CPU12 sig=0x106a5, pf=0x1, revision=0x11 [57361.362679] platform microcode: firmware: agent aborted loading intel-ucode/06-1a-05 (not found?) [57361.389517] microcode: CPU13 sig=0x106a5, pf=0x1, revision=0x11 [57361.417568] platform microcode: firmware: agent aborted loading intel-ucode/06-1a-05 (not found?) [57361.444542] microcode: CPU14 sig=0x106a5, pf=0x1, revision=0x11 [57361.467111] platform microcode: firmware: agent aborted loading intel-ucode/06-1a-05 (not found?) [57361.494137] microcode: CPU15 sig=0x106a5, pf=0x1, revision=0x11 [57361.516492] platform microcode: firmware: agent aborted loading intel-ucode/06-1a-05 (not found?) The newer versions of the intel-microcode.dat file used to generate these firmware files no longer seem to include the microcode update for the following CPU: vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Xeon(R) CPU E5540 @ 2.53GHz stepping: 5 I've downloaded the intel-microcode 0.20100826-1_amd64 version from the squeeze repo and this file still includes the microcode update for this cpu: it updates it from 0x11 to 0x15. Is there a way to merge the older and recent intel-microcode.dat files, so microcode updates are not lost? If I manually add the 06-1a-05 file from the older microcode.dat file to /lib/firmware/intel-ucode, will it get removed by updates from the intel-microcode package and/or iucode_tool? Regards, Rik -- System Information: Debian Release: 7.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash intel-microcode depends on no packages. Versions of packages intel-microcode recommends: ii iucode-tool 0.8.3-1 intel-microcode suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698780: BUG in nfs_mark_delegation_referenced also triggered without hibernation
Hi, We had another system triggering this same BUG which did not come out of resume/hibernate, so the hibernation/suspend does not seem relevant. Although the issue seems to be a lot easier to hit when using hibernate/suspend. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698780: linux-image-3.2.0-0.bpo.4-amd64: BUG in nfs_mark_delegation_referenced after resume from hibernate
Package: src:linux Version: 3.2.35-2~bpo60+1 Severity: normal Hi, When our NFSv4 client is resumed from hibernate, it logs the following message: NFS: nfs4_reclaim_open_state: Lock reclaim failed! After a while (15 min up to 2 hours) the following BUG is triggered: Jan 22 09:13:47 bax kernel: [31774.290971] BUG: unable to handle kernel paging request at ffb8 Jan 22 09:13:47 bax kernel: [31774.291024] IP: [a0491292] nfs_mark_delegation_referenced+0x6/0x6 [nfs] Jan 22 09:13:47 bax kernel: [31774.291083] PGD 1607067 PUD 1608067 PMD 0 Jan 22 09:13:47 bax kernel: [31774.291116] Oops: [#1] SMP Jan 22 09:13:47 bax kernel: [31774.291142] CPU 3 Jan 22 09:13:47 bax kernel: [31774.291155] Modules linked in: nls_utf8 nls_cp437 vfat fat ip6_tables rfcomm bridge stp bnep bluetooth rfkill autofs4 tun parport_pc cpufreq_powersave cpufreq_stats ppdev lp parport cpufreq_conservative cpufreq_userspace uinput binfmt_misc kvm_intel kvm fuse nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc ipt_REJECT xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables loop snd_hda_codec_hdmi snd_hda_codec_realtek i915 snd_hda_intel snd_hda_codec snd_hwdep drm_kms_helper snd_pcm_oss snd_mixer_oss snd_pcm drm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq coretemp i2c_i801 i2c_algo_bit i2c_core crc32c_intel ghash_clmulni_intel snd_timer snd_seq_device aesni_intel snd cryptd soundcore aes_x86_64 snd_page_alloc usbhid hid tpm_tis tpm tpm_bios psmouse acpi_cpufreq evdev mperf serio_raw pcspkr ses dcdbas video aes_generic processor button enclosure ext4 mbcache jbd2 crc16 dm_mod sg sr_mod sd_mod cdr om crc_t10dif usb_storage ahci lib Jan 22 09:13:47 bax kernel: ahci libata scsi_mod ehci_hcd e1000e xhci_hcd usbcore thermal usb_common thermal_sys [last unloaded: scsi_wait_scan] Jan 22 09:13:47 bax kernel: [31774.291930] Jan 22 09:13:47 bax kernel: [31774.291942] Pid: 7211, comm: gnome-www-brows Not tainted 3.2.0-0.bpo.4-amd64 #1 Debian 3.2.35-2~bpo60+1 Dell Inc. OptiPlex 7010/0KRC95 Jan 22 09:13:47 bax kernel: [31774.292014] RIP: 0010:[a0491292] [a0491292] nfs_mark_delegation_referenced+0x6/0x6 [nfs] Jan 22 09:13:47 bax kernel: [31774.292079] RSP: 0018:880252c55d00 EFLAGS: 00010246 Jan 22 09:13:47 bax kernel: [31774.292109] RAX: d8ca RBX: d8ca RCX: 880252c55d58 Jan 22 09:13:47 bax kernel: [31774.292149] RDX: 880252c55d58 RSI: 0001 RDI: Jan 22 09:13:47 bax kernel: [31774.292188] RBP: 880252c55d58 R08: 880252c54000 R09: a049b930 Jan 22 09:13:47 bax kernel: [31774.292227] R10: 880409eda000 R11: 88040b625000 R12: 880409eda000 Jan 22 09:13:47 bax kernel: [31774.292267] R13: 88040a2b8400 R14: R15: Jan 22 09:13:47 bax kernel: [31774.292307] FS: 7feb72f3f980() GS:88041e2c() knlGS: Jan 22 09:13:47 bax kernel: [31774.292351] CS: 0010 DS: ES: CR0: 80050033 Jan 22 09:13:47 bax kernel: [31774.292383] CR2: ffb8 CR3: 00023920 CR4: 001406e0 Jan 22 09:13:47 bax kernel: [31774.292422] DR0: DR1: DR2: Jan 22 09:13:47 bax kernel: [31774.292462] DR3: DR6: 0ff0 DR7: 0400 Jan 22 09:13:47 bax kernel: [31774.292501] Process gnome-www-brows (pid: 7211, threadinfo 880252c54000, task 8803ead37550) Jan 22 09:13:47 bax kernel: [31774.292550] Stack: Jan 22 09:13:47 bax kernel: [31774.292563] a047f6e0 88031ac16800 8803309d0300 8803f1049560 Jan 22 09:13:47 bax kernel: [31774.292613] 8803f1049f40 880409eda000 880252c55d58 88031ac16800 Jan 22 09:13:47 bax kernel: [31774.292664] a04868b0 880252c55dc8 d8ca Jan 22 09:13:47 bax kernel: [31774.292713] Call Trace: Jan 22 09:13:47 bax kernel: [31774.292740] [a047f6e0] ? nfs4_handle_exception+0x149/0x2bb [nfs] Jan 22 09:13:47 bax kernel: [31774.292788] [a04868b0] ? nfs4_open_delegation_recall+0x157/0x171 [nfs] Jan 22 09:13:47 bax kernel: [31774.292838] [a0491974] ? __nfs_inode_return_delegation+0xb4/0x1ac [nfs] Jan 22 09:13:47 bax kernel: [31774.292889] [a0478856] ? nfs_wb_all+0x39/0x3e [nfs] Jan 22 09:13:47 bax kernel: [31774.292930] [a047815b] ? nfs_sillyrename+0xa1/0x272 [nfs] Jan 22 09:13:47 bax kernel: [31774.292969] [8110fe61] ? vfs_unlink+0x69/0xc8 Jan 22 09:13:47 bax kernel: [31774.293001] [81112418] ? do_unlinkat+0xca/0x154 Jan 22 09:13:47 bax kernel: [31774.293036] [81104faa] ? do_sys_open+0xd6/0xe8 Jan 22 09:13:47 bax kernel: [31774.293069] [8136d652] ? system_call_fastpath+0x16/0x1b Jan 22 09:13:47 bax kernel: [31774.293104] Code: 5d 41 5c 41 5d 48 c7 c6 d0 cd 49 a0 48 c7 c7 d6 24 4a a0 31 c0 e9 14 51 ed e0 59 5b 5d 41 5c 41 5d c3 90 90
Bug#697681: fixed in bind9 1:9.9.2.dfsg.P1-2
Hi, Would it possible to add a second part of this fix? Without it, the log is still spammed with the following errors: Jan 16 14:44:19 sulphur named[3202]: RSA_verify failed Jan 16 14:44:20 sulphur named[3202]: error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:291: Jan 16 14:44:20 sulphur named[3202]: RSA_verify failed Jan 16 14:44:20 sulphur named[3202]: error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:291: Jan 16 14:44:20 sulphur named[3202]: RSA_verify failed Jan 16 14:44:20 sulphur named[3202]: error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:291: Jan 16 14:44:20 sulphur named[3202]: RSA_verify failed Patch was mentioned in the same thread [1] and when I apply the patch to the package it works OK. See patch in attach. Did you ask for the more recent package to be unblocked for testing? Are you planning to and/or would you mind if I ask for it to be unblocked once the additional patch is applied? Regards, Rik [1] http://www.mail-archive.com/bind-users@lists.isc.org/msg14759.html On 01/10/2013 01:36 AM, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the bind9 package: #697681: bind9: DNSSEC validating resolver spams log file after upgrade to 9.8.4 It has been closed by LaMont Jones lam...@debian.org. -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors diff -ur bind9-9.8.4.dfsg.P1.orig/lib/dns/opensslrsa_link.c bind9-9.8.4.dfsg.P1/lib/dns/opensslrsa_link.c --- bind9-9.8.4.dfsg.P1.orig/lib/dns/opensslrsa_link.c 2012-10-26 06:52:55.0 +0200 +++ bind9-9.8.4.dfsg.P1/lib/dns/opensslrsa_link.c 2013-01-08 14:26:58.996397527 +0100 @@ -633,8 +633,7 @@ #endif #endif if (status != 1) - return (dst__openssl_toresult2(RSA_verify, - DST_R_VERIFYFAILURE)); + return (dst__openssl_toresult(DST_R_VERIFYFAILURE)); return (ISC_R_SUCCESS); }
Bug#697681: fixed in bind9 1:9.9.2.dfsg.P1-2
Hi, Sorry, disregards this message. I missed your upload to unstable. Thanks for fixing this! Regards, Rik On 01/10/2013 08:48 AM, Rik Theys wrote: Hi, Thanks for fixing this. Would it be possible to also fix this bug in a 9.8.4 upload directed for Wheezy? Maybe using testing-proposed-updates? A patch for this against version 1:9.8.4.dfsg.P1-2 is attached. Regards, Rik On 01/10/2013 01:36 AM, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the bind9 package: #697681: bind9: DNSSEC validating resolver spams log file after upgrade to 9.8.4 It has been closed by LaMont Jones lam...@debian.org. -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697681: fixed in bind9 1:9.9.2.dfsg.P1-2
Hi, Thanks for fixing this. Would it be possible to also fix this bug in a 9.8.4 upload directed for Wheezy? Maybe using testing-proposed-updates? A patch for this against version 1:9.8.4.dfsg.P1-2 is attached. Regards, Rik On 01/10/2013 01:36 AM, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the bind9 package: #697681: bind9: DNSSEC validating resolver spams log file after upgrade to 9.8.4 It has been closed by LaMont Jones lam...@debian.org. -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors diff -ur bind9-9.8.4.dfsg.P1.orig/lib/dns/dnssec.c bind9-9.8.4.dfsg.P1/lib/dns/dnssec.c --- bind9-9.8.4.dfsg.P1.orig/lib/dns/dnssec.c 2012-10-26 06:52:55.0 +0200 +++ bind9-9.8.4.dfsg.P1/lib/dns/dnssec.c 2013-01-08 14:29:19.980398778 +0100 @@ -552,7 +552,7 @@ char namebuf[DNS_NAME_FORMATSIZE]; dns_name_format(sig.signer, namebuf, sizeof(namebuf)); isc_log_write(dns_lctx, DNS_LOGCATEGORY_GENERAL, - DNS_LOGMODULE_DNSSEC, ISC_LOG_INFO, + DNS_LOGMODULE_DNSSEC, ISC_LOG_DEBUG(1), sucessfully validated after lower casing signer '%s', namebuf); inc_stat(dns_dnssecstats_downcase); diff -ur bind9-9.8.4.dfsg.P1.orig/lib/dns/opensslrsa_link.c bind9-9.8.4.dfsg.P1/lib/dns/opensslrsa_link.c --- bind9-9.8.4.dfsg.P1.orig/lib/dns/opensslrsa_link.c 2012-10-26 06:52:55.0 +0200 +++ bind9-9.8.4.dfsg.P1/lib/dns/opensslrsa_link.c 2013-01-08 14:26:58.996397527 +0100 @@ -633,8 +633,7 @@ #endif #endif if (status != 1) - return (dst__openssl_toresult2(RSA_verify, - DST_R_VERIFYFAILURE)); + return (dst__openssl_toresult(DST_R_VERIFYFAILURE)); return (ISC_R_SUCCESS); }
Bug#697681: bind9: DNSSEC validating resolver spams log file after upgrade to 9.8.4
Package: bind9 Version: 1:9.8.4.dfsg.P1-1 Severity: important Hi, After upgrading bind to 9.8.4 (now in testing) on our DNSSEC validating resolvers, our log files are being spammed with the following messages: Jan 8 12:06:06 sulphur named[26473]: RSA_verify failed Jan 8 12:06:06 sulphur named[26473]: error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:291: Jan 8 12:06:06 sulphur named[26473]: sucessfully validated after lower casing signer 'BIZ' Jan 8 12:06:06 sulphur named[26473]: RSA_verify failed Jan 8 12:06:06 sulphur named[26473]: error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:291: Jan 8 12:06:06 sulphur named[26473]: sucessfully validated after lower casing signer 'BIZ' Jan 8 12:07:41 sulphur named[26473]: RSA_verify failed Jan 8 12:07:41 sulphur named[26473]: error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:291: Jan 8 12:07:41 sulphur named[26473]: sucessfully validated after lower casing signer 'US' Jan 8 12:07:41 sulphur named[26473]: RSA_verify failed Jan 8 12:07:41 sulphur named[26473]: error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:291: Jan 8 12:07:41 sulphur named[26473]: sucessfully validated after lower casing signer 'US' This appears to be a known issue with the 9.8.4 update as discussed in the following thread: http://www.mail-archive.com/bind-users@lists.isc.org/msg14759.html Please apply the changes discussed in this thread to the Debian bind9 packages. Hopefully this fix will make it into Wheezy as it's filling up our logs and disks. Regards, Rik -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages bind9 depends on: ii adduser3.113+nmu3 ii bind9utils 1:9.8.4.dfsg.P1-1 ii debconf [debconf-2.0] 1.5.49 ii libbind9-801:9.8.4.dfsg.P1-1 ii libc6 2.13-37 ii libcap21:2.22-1.2 ii libdns88 1:9.8.4.dfsg.P1-1 ii libgssapi-krb5-2 1.10.1+dfsg-3 ii libisc84 1:9.8.4.dfsg.P1-1 ii libisccc80 1:9.8.4.dfsg.P1-1 ii libisccfg821:9.8.4.dfsg.P1-1 ii liblwres80 1:9.8.4.dfsg.P1-1 ii libssl1.0.01.0.1c-4 ii libxml22.8.0+dfsg1-7 ii lsb-base 4.1+Debian8 ii net-tools 1.60-24.2 ii netbase5.0 bind9 recommends no packages. Versions of packages bind9 suggests: pn bind9-doc none ii dnsutils1:9.8.4.dfsg.P1-1 pn resolvconf none pn ufw none -- Configuration Files: /etc/bind/named.conf.local changed [not included] -- debconf information: bind9/different-configuration-file: bind9/run-resolvconf: false bind9/start-as-user: bind -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631799: [squeeze] Kernel logs name_count maxed, losing inode data messages
Hi, On 12/07/2012 09:48 AM, Rik Theys wrote: Hi, On 12/06/2012 02:51 PM, Ben Hutchings wrote: On Thu, 2012-12-06 at 13:58 +0100, Rik Theys wrote: On 12/06/2012 01:29 PM, Ben Hutchings wrote: It is not too difficult to fix up the conflicts. But this is a fairly big change, so I think this bug should now be 'wontfix' for wheezy. Sorry we didn't get it fixed earlier. Sorry to hear that. Would a patch that simply increases the static number of entries in the names array be an acceptable workaround? It would decrease the change of hitting this bug. Perhaps; do you have any idea what the limit should be? What would you consider the upper limit to which we could increase the number? Just so I know at which limit I can stop building test kernels. Since you're asking me to make a somewhat arbitrary decision, I'll arbitrarily decide on double the current limit, i.e. 40. I've booted a kernel which has the AUDIT_NAMES set to 30. It's been running for about 12 hours now without any messages (with the Debian 3.2.32 kernel it already logged the first message after 57s uptime). The system is running the patches kernel for 5 days now without a single error message. Is it possible to include this change in an upcoming 3.2 kernel upload? Regards, Rik For now, it seems 30 is enough for my use case. If you're willing to bump it up to 40, I would go for that. -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631799: [squeeze] Kernel logs name_count maxed, losing inode data messages
Hi, On 12/06/2012 02:51 PM, Ben Hutchings wrote: On Thu, 2012-12-06 at 13:58 +0100, Rik Theys wrote: On 12/06/2012 01:29 PM, Ben Hutchings wrote: It is not too difficult to fix up the conflicts. But this is a fairly big change, so I think this bug should now be 'wontfix' for wheezy. Sorry we didn't get it fixed earlier. Sorry to hear that. Would a patch that simply increases the static number of entries in the names array be an acceptable workaround? It would decrease the change of hitting this bug. Perhaps; do you have any idea what the limit should be? Not really. I'm currently building a test kernel with the limit set to 25 (instead of 20). I'll see if I can boot that kernel one of these days to see if 25 is enough. The 25 might be enough for my situation, but other users could of course need an even bigger number... We do need to consider that this costs 76 bytes per name per task for which auditing is enabled, and there are normally hundreds or thousands of tasks running, so extra names aren't cheap. What would you consider the upper limit to which we could increase the number? Just so I know at which limit I can stop building test kernels. Since you're asking me to make a somewhat arbitrary decision, I'll arbitrarily decide on double the current limit, i.e. 40. I've booted a kernel which has the AUDIT_NAMES set to 30. It's been running for about 12 hours now without any messages (with the Debian 3.2.32 kernel it already logged the first message after 57s uptime). For now, it seems 30 is enough for my use case. If you're willing to bump it up to 40, I would go for that. Thank you for considering. Regards, Rik -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631799: [squeeze] Kernel logs name_count maxed, losing inode data messages
Hi, On 12/01/2012 11:10 PM, Ben Hutchings wrote: On Fri, 2012-11-30 at 11:10 +0100, Rik Theys wrote: [...] I cherry picked commits 5ef30ee53b187786e64bdc1f8109e39d17f2ce58 and 5195d8e217a78697152d64fc09a16e063a022465 and tried to compile the result, but it failed with the following error: kernel/auditsc.c:2189: error: conflicting types for ‘__audit_mq_open’ include/linux/audit.h:477: note: previous declaration of ‘__audit_mq_open’ was here kernel/auditsc.c:2289: error: conflicting types for ‘__audit_ipc_set_perm’ include/linux/audit.h:471: note: previous declaration of ‘__audit_ipc_set_perm’ was here Any idea on how to determine which intermediate patches are also needed? Or should I just try to modify commit 5195d8e217a78697152d64fc09a16e063a022465 to make it apply? It is not too difficult to fix up the conflicts. But this is a fairly big change, so I think this bug should now be 'wontfix' for wheezy. Sorry we didn't get it fixed earlier. Sorry to hear that. Would a patch that simply increases the static number of entries in the names array be an acceptable workaround? It would decrease the change of hitting this bug. Regards, Rik -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631799: [squeeze] Kernel logs name_count maxed, losing inode data messages
On 12/06/2012 01:29 PM, Ben Hutchings wrote: It is not too difficult to fix up the conflicts. But this is a fairly big change, so I think this bug should now be 'wontfix' for wheezy. Sorry we didn't get it fixed earlier. Sorry to hear that. Would a patch that simply increases the static number of entries in the names array be an acceptable workaround? It would decrease the change of hitting this bug. Perhaps; do you have any idea what the limit should be? Not really. I'm currently building a test kernel with the limit set to 25 (instead of 20). I'll see if I can boot that kernel one of these days to see if 25 is enough. The 25 might be enough for my situation, but other users could of course need an even bigger number... We do need to consider that this costs 76 bytes per name per task for which auditing is enabled, and there are normally hundreds or thousands of tasks running, so extra names aren't cheap. What would you consider the upper limit to which we could increase the number? Just so I know at which limit I can stop building test kernels. Regards, Rik -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631799: [squeeze] Kernel logs name_count maxed, losing inode data messages
Hi, On 11/30/2012 08:18 AM, Rik Theys wrote: On 11/29/2012 01:10 PM, Rik Theys wrote: On 11/25/2012 01:12 AM, Jonathan Nieder wrote: On some of our servers, we periodically see name_count maxed, losing inode data messages in the kernel log. As you mentioned, this is said to be fixed by commit 5195d8e217a7 Author: Eric Paris epa...@redhat.com Date: Tue Jan 3 14:23:05 2012 -0500 audit: dynamically allocate audit_names when not enough space is in the names array which is part of 3.3. Am I correct in understanding that the wheezy kernel is affected, too? I have not yet tried to apply the fix, so I can't comment on that. I can install the 3.2 backports kernel on this system to see if Wheezy is also affected, but I assume it is if the fix is in 3.3. I've booted the 3.2.32 bpo kernel and it is indeed affected. I'll see if I can find time to build a test kernel with the patch applied. I tried to apply this commit to 3.2.34 (and 3.2.32) but it failed to apply. Looking at the git log between 3.2.34 and 3.3 I assumed it also needed commit 5ef30ee53b187786e64bdc1f8109e39d17f2ce58. I cherry picked commits 5ef30ee53b187786e64bdc1f8109e39d17f2ce58 and 5195d8e217a78697152d64fc09a16e063a022465 and tried to compile the result, but it failed with the following error: kernel/auditsc.c:2189: error: conflicting types for ‘__audit_mq_open’ include/linux/audit.h:477: note: previous declaration of ‘__audit_mq_open’ was here kernel/auditsc.c:2289: error: conflicting types for ‘__audit_ipc_set_perm’ include/linux/audit.h:471: note: previous declaration of ‘__audit_ipc_set_perm’ was here Any idea on how to determine which intermediate patches are also needed? Or should I just try to modify commit 5195d8e217a78697152d64fc09a16e063a022465 to make it apply? Regards, Rik -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631799: [squeeze] Kernel logs name_count maxed, losing inode data messages
On 11/25/2012 01:12 AM, Jonathan Nieder wrote: On some of our servers, we periodically see name_count maxed, losing inode data messages in the kernel log. As you mentioned, this is said to be fixed by commit 5195d8e217a7 Author: Eric Paris epa...@redhat.com Date: Tue Jan 3 14:23:05 2012 -0500 audit: dynamically allocate audit_names when not enough space is in the names array which is part of 3.3. Am I correct in understanding that the wheezy kernel is affected, too? What is the impact of this bug --- does it flood logs in some situations, for example, or does it lose important information? Is the fix harmless or does it have potential downsides? On this particular server, I get 3 messages every approx. 6 minutes. [5262360.801855] name_count maxed, losing inode data: dev=00:07, inode=8 [5262360.801861] name_count maxed, losing inode data: dev=00:07, inode=334434366 [5262360.803580] name_count maxed, losing inode data: dev=00:3c, inode=21757958 The inode=8 and inode=21757958 are always the same. The second message is always different. I don't think it loses important information in my case as I don't audit a lot of items. My audit log is 99% LOGIN audits. I have not yet tried to apply the fix, so I can't comment on that. I can install the 3.2 backports kernel on this system to see if Wheezy is also affected, but I assume it is if the fix is in 3.3. It could be a while before I can confirm this as this is a production system and I did not plan on rebooting the system before the end of January. I'll see if I can squeeze in a reboot somewhere. Regards, Rik -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631799: [squeeze] Kernel logs name_count maxed, losing inode data messages
On 11/29/2012 01:10 PM, Rik Theys wrote: On 11/25/2012 01:12 AM, Jonathan Nieder wrote: On some of our servers, we periodically see name_count maxed, losing inode data messages in the kernel log. As you mentioned, this is said to be fixed by commit 5195d8e217a7 Author: Eric Paris epa...@redhat.com Date: Tue Jan 3 14:23:05 2012 -0500 audit: dynamically allocate audit_names when not enough space is in the names array which is part of 3.3. Am I correct in understanding that the wheezy kernel is affected, too? I have not yet tried to apply the fix, so I can't comment on that. I can install the 3.2 backports kernel on this system to see if Wheezy is also affected, but I assume it is if the fix is in 3.3. I've booted the 3.2.32 bpo kernel and it is indeed affected. I'll see if I can find time to build a test kernel with the patch applied. Rik -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691151: mount: Bind mounts not shown as such in mount output
Package: mount Version: 2.20.1-5.2 Severity: normal Hi, When bind mounts are configured in /etc/fstab, they don't show up as bind mounts in the output of 'mount'. From my /etc/fstab: /dev/mapper/vg_sulphur-root / ext4errors=remount-ro 0 1 /dev/mapper/vg_sulphur-bind /srv/bind ext4 errors=remount-ro,nosuid,relatime 0 2 # proc inside bind chroot /proc /srv/bind/proc nonebind0 0 # bind needs /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines in its chroot /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines /srv/bind/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines none bind 0 0 Output from 'mount | grep bind' (bind matches /srv/bind in this case): /dev/mapper/vg_sulphur-bind on /srv/bind type ext4 (rw,nosuid,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered) proc on /srv/bind/proc type proc (rw,nosuid,nodev,noexec,relatime) /dev/mapper/vg_sulphur-root on /srv/bind/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines type ext4 (rw,relatime,errors=remount-ro,user_xattr,barrier=$ The bind mounts show up with the file system type (ext4) and device (/dev/mapper/vg_sulphur-root) of the device from which they are bind mounted. The output of mount should show: /proc on /srv/bind/proc none (rw,bind) As it did on squeeze. This is probably caused by the /etc/mtab - /proc/mounts symlink now. This new behaviour makes it impossible to see which file systems were bind mounted. Regards, Rik -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mount depends on: ii libblkid12.20.1-5.2 ii libc62.13-35 ii libmount12.20.1-5.2 ii libselinux1 2.1.9-5 ii libsepol12.1.4-3 mount recommends no packages. Versions of packages mount suggests: pn nfs-common none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679750: Lenovo G360: ALPS Touchpad Recognized as PS/2 Generic Mouse(with newly dmesg information)
Hi Seth, On Tue, Jul 10, 2012 at 6:57 AM, Seth Forshee seth.fors...@canonical.com wrote: On Tue, Jul 10, 2012 at 12:16:27PM +0800, littlebat wrote: 3, If you are interest in this and have time and it is helpful, I can provide a root password for this laptop to you and run ssh service for you all the time. Then you can operate this laptop via ssh connection in this way. You can do anything on this machine even format the disk :-) I'm afraid it's just not practical to do this remotely. Being able to physically interact with the touchpad is pretty crucial. How long do you think you will need to reverse engineer the protocol if you would have the hardware? Depending on how long you think you might need, and how much it would cost me to ship my laptop to you (where are you located?), would it help if I simply ship my laptop to you? I can't do that right now, but might be able to do that in a few months. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617453: restarting doesn't always work on Dell Latitude E6400
Hi, On Fri, Jul 6, 2012 at 12:19 AM, Vincent Lefevre vinc...@vinc17.net wrote: On 2012-07-04 20:55:56 +0200, Rik Theys wrote: Vincent Lefevre wrote: When I want to restart (reboot) my Dell Latitude E6400 laptop, the machine sometimes remain on without restarting. The last message on the console is: Restarting system. Can you try adding the following parameter to your kernel boot line? Add it to the GRUB_CMDLINE_LINUX parameter in /etc/default/grub and run update-grub. reboot=pci I don't have a /etc/default/grub on this machine. It seems to be available with grub-pc, but here I have grub-legacy. Perhaps I should use defoptions=quiet reboot=pci You could add it to the kopt= line in /boot/grub/menu.lst and then run 'update-grub'. Please confirm if adding this boot parameter works for you. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679750: Lenovo G360: ALPS Touchpad Recognized as PS/2 Generic Mouse
Hi, I believe this is the same bug as launchpad bug 606238: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606238 The bug discusses various Dell laptops with ALPS touchpad that don't work. They now work in the ubuntu 12.04 kernel (and I believe upstream as well), but some (such as the one found in an Inspiron 15R N5110) still don't work because they use yet another protocol version. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617453: restarting doesn't always work on Dell Latitude E6400
Hi, Vincent Lefevre wrote: When I want to restart (reboot) my Dell Latitude E6400 laptop, the machine sometimes remain on without restarting. The last message on the console is: Restarting system. Can you try adding the following parameter to your kernel boot line? Add it to the GRUB_CMDLINE_LINUX parameter in /etc/default/grub and run update-grub. reboot=pci We need(ed) to add this parameter to some of our recent Dell desktops to make them reboot. Let us know if this helps, so it can be made the default for this laptop type. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592959: Dovecot in backports
On 06/29/2012 10:31 PM, micah anderson wrote: After getting the go ahead from the maintainers, I uploaded dovecot-antispam and dovecot2 to BPO yesterday. Because dovecot-antispam is already in BPO, it was accepted right away, the dovecot2 packages are waiting in NEW. The dovecot-antispam package has strict version dependence. This means that it only works with the version of dovecot that it was built against. I built it on my amd64 machine against the 2.1.17 version that is pending in BPO's NEW right now. However, what ended up happening is that the BPO autobuilders picked it up and built it against stable dovecot1. So right now the dovecot-antispam package in BPO is somewhat useless, it doesn't work with dovecot1 or dovecot2 (unless you are on an amd64 machine, in that case it works for dovecot2). The question is, do we go ahead with letting dovecot2 into BPO, and then do binNMUs on dovecot-antispam to make it work with dovecot2? Is it not possible to put the dovecot-antispam back and create a dovecot2-antispam package that works with the new dovecot2 package? Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645998: freeradius crashes due to segmentation fault
Hi, I've created a new 2.1.12 package based on the Debian 2.1.10 package so you can check if the new upstream release fixes this bug. The packaging simply keeps the default 2.1.10 config files, so if it works the packaging will need additional cleanup! You can find the packages for x86_64 here: http://homes.esat.kuleuven.be/~rtheys/freeradius/2.1.12-squeeze They were built on a squeeze box. If you need it for i386, you can download the following files to a directory: freeradius_2.1.12+dfsg.orig.tar.gz freeradius_2.1.12+dfsg-1.dsc freeradius_2.1.12+dfsg-1.diff.gz and run the following commands: apt-get install build-essential apt-get build-dep freeradius dpkg-source -x freeradius_2.1.12+dfsg-1.dsc cd freeradius-2.1.12+dfsg dpkg-buildpackage Even if it fixes the bug, I doubt it will end up in the next stable release as it's almost frozen. But it would be nice to document if it fixes your bug. Regards, Rik On 15/06/2012 10:04, José Antonio Antelo wrote: We followed your instructions to build the package for i386 platform and it worked well. After that, it was installed on a production enviroment to test it. The conclusion was that after few hours working it crashed again (*). If you need more information reply to atic.sistemas.r...@usc.es. Regards, (*) Jun 14 11:03:55 vm075144 kernel: [2557096.780937] freeradius[26639]: segfault at c ip b73a0328 sp bffe3820 error 4 in rlm_eap-2.1.10.so[b739c000+6000] Jun 14 15:12:24 vm075144 kernel: [2572005.811051] freeradius[31179]: segfault at c ip b735e328 sp bfdf4d10 error 4 in rlm_eap-2.1.10.so[b735a000+6000] Jun 14 15:21:49 vm075144 kernel: [2572570.522135] freeradius[8368]: segfault at c ip b7311328 sp bfe97bd0 error 4 in rlm_eap-2.1.10.so[b730d000+6000] El 05/06/12 10:20, Rik Theys escribió: Hi, I manually created a patch for this commit (see attach). I also applied the patch to the latest Debian package. You can find a build for amd64 at http://homes.esat.kuleuven.be/~rtheys/freeradius. I have not tested the resulting package, but the patch applied cleanly and there were no build errors. To reproduce the packaging: apt-get install build-essential apt-get build-dep freeradius apt-get source freeradius cd freeradius-2.1.10+dfsg copy the attached patch to the debian/patches directory echo fix-freeing-eap_handler.diff debian/patches/series add an entry to debian/changelog dpkg-buildpackage I believe the same instructions should work for the squeeze version of freeradius. If you have time, please test the updated package/patch to see if it resolves the issue you are seeing, and update the bug report with your info. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675621: system freeze after safely unmounting usb drive
Hi, On 06/07/2012 11:22 PM, Ben Hutchings wrote: On Tue, Jun 05, 2012 at 09:05:42AM +0200, Rik Theys wrote: I have seen similar crashes with the 6.0.x kernel on some of our systems. Unfortunately the systems are in a remote location and I was unable to capture any crash screens. [...] This sounds somewhat the bug fixed by: commit 8354a9e00afb022f6b508bd7d6bd74daebb8b751 or possibly: commit 5e4c1dbf52bc1ff33782266332a62151d5b5f0be But we've had those since linux-2.6 version 2.6.32-36 (Debian release 6.0.3). So unless Sebastien has somehow failed to upgrade then this must be something different. I've checked the dpkg.log file on one of the systems on which I'm certain I switched to a 3.1 kernel because of this bug, and the last 2.6.32 kernel on it before I switched is 2.6.32-39. The 3.1.5 kernel I installed at that time did not have the bug. We're really going to need a kernel log in order to make any progress on this. I'll try to reproduce this on a test system, but I leave on holiday in a few hours so it could take a while. Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675621: system freeze after safely unmounting usb drive
reassign 675621 linux-2.6 thanks Hi, I have seen similar crashes with the 6.0.x kernel on some of our systems. Unfortunately the systems are in a remote location and I was unable to capture any crash screens. I installed the 3.2 kernel from squeeze-backports on those systems and that fixed the bug. Can you try installing the linux kernel from squeeze-backports and confirm if this fixes the issue for you? See [1] for instructions on how to enable the backports repository. Please also attach the system log (/var/log/syslog) as it might contain more information about the crash. If you switch to a non-graphical console before unplugging the memory stick, does it show any messages? Press ctrl-alt-f1 to go to a non-graphical console and then unplug the usb stick. If a crash message appears, try taking a photograph of it and attach it to this bug report. Regards, Rik [1]http://backports-master.debian.org/Instructions/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645998: freeradius crashes due to segmentation fault
Hi,
I manually created a patch for this commit (see attach). I also applied
the patch to the latest Debian package. You can find a build for amd64
at http://homes.esat.kuleuven.be/~rtheys/freeradius.
I have not tested the resulting package, but the patch applied cleanly
and there were no build errors.
To reproduce the packaging:
apt-get install build-essential
apt-get build-dep freeradius
apt-get source freeradius
cd freeradius-2.1.10+dfsg
copy the attached patch to the debian/patches directory
echo fix-freeing-eap_handler.diff debian/patches/series
add an entry to debian/changelog
dpkg-buildpackage
I believe the same instructions should work for the squeeze version of
freeradius.
If you have time, please test the updated package/patch to see if it
resolves the issue you are seeing, and update the bug report with your info.
Regards,
Rik
diff -ur freeradius-2.1.10+dfsg.orig/src/modules/rlm_eap/eap.h freeradius-2.1.10+dfsg/src/modules/rlm_eap/eap.h
--- freeradius-2.1.10+dfsg.orig/src/modules/rlm_eap/eap.h 2010-09-28 13:03:56.0 +0200
+++ freeradius-2.1.10+dfsg/src/modules/rlm_eap/eap.h 2012-06-05 09:39:58.978878670 +0200
@@ -107,6 +107,7 @@
void *opaque;
void (*free_opaque)(void *opaque);
+ void *inst_holder;
int status;
diff -ur freeradius-2.1.10+dfsg.orig/src/modules/rlm_eap/mem.c freeradius-2.1.10+dfsg/src/modules/rlm_eap/mem.c
--- freeradius-2.1.10+dfsg.orig/src/modules/rlm_eap/mem.c 2010-09-28 13:03:56.0 +0200
+++ freeradius-2.1.10+dfsg/src/modules/rlm_eap/mem.c 2012-06-05 09:41:28.288350283 +0200
@@ -128,6 +128,14 @@
return handler;
}
+void eap_opaque_free(EAP_HANDLER *handler)
+{
+ if (!handler)
+ return;
+
+ eap_handler_free(handler-inst_holder, handler);
+}
+
void eap_handler_free(rlm_eap_t *inst, EAP_HANDLER *handler)
{
if (!handler)
diff -ur freeradius-2.1.10+dfsg.orig/src/modules/rlm_eap/rlm_eap.c freeradius-2.1.10+dfsg/src/modules/rlm_eap/rlm_eap.c
--- freeradius-2.1.10+dfsg.orig/src/modules/rlm_eap/rlm_eap.c 2010-09-28 13:03:56.0 +0200
+++ freeradius-2.1.10+dfsg/src/modules/rlm_eap/rlm_eap.c 2012-06-05 09:42:21.056350259 +0200
@@ -342,7 +342,7 @@
rcode = request_data_add(request,
inst, REQUEST_DATA_EAP_HANDLER,
handler,
- (void *) eap_handler_free);
+ (void *) eap_opaque_free);
rad_assert(rcode == 0);
return RLM_MODULE_HANDLED;
@@ -367,7 +367,7 @@
rcode = request_data_add(request,
inst, REQUEST_DATA_EAP_HANDLER,
handler,
- (void *) eap_handler_free);
+ (void *) eap_opaque_free);
rad_assert(rcode == 0);
/*
diff -ur freeradius-2.1.10+dfsg.orig/src/modules/rlm_eap/rlm_eap.h freeradius-2.1.10+dfsg/src/modules/rlm_eap/rlm_eap.h
--- freeradius-2.1.10+dfsg.orig/src/modules/rlm_eap/rlm_eap.h 2010-09-28 13:03:56.0 +0200
+++ freeradius-2.1.10+dfsg/src/modules/rlm_eap/rlm_eap.h 2012-06-05 09:43:14.768350275 +0200
@@ -105,6 +105,7 @@
EAP_HANDLER *eap_handler_alloc(rlm_eap_t *inst);
void eap_packet_free(EAP_PACKET **eap_packet);
void eap_ds_free(EAP_DS **eap_ds);
+void eap_opaque_free(EAP_HANDLER *handler);
void eap_handler_free(rlm_eap_t *inst, EAP_HANDLER *handler);
int eaplist_add(rlm_eap_t *inst, EAP_HANDLER *handler);
diff -ur freeradius-2.1.10+dfsg.orig/src/modules/rlm_eap/types/rlm_eap_peap/peap.c freeradius-2.1.10+dfsg/src/modules/rlm_eap/types/rlm_eap_peap/peap.c
--- freeradius-2.1.10+dfsg.orig/src/modules/rlm_eap/types/rlm_eap_peap/peap.c 2010-09-28 13:03:56.0 +0200
+++ freeradius-2.1.10+dfsg/src/modules/rlm_eap/types/rlm_eap_peap/peap.c 2012-06-05 09:45:32.340350411 +0200
@@ -1075,8 +1075,8 @@
request-proxy = fake-packet;
memset(request-proxy-src_ipaddr, 0,
sizeof(request-proxy-src_ipaddr));
- memset(request-proxy-src_ipaddr, 0,
- sizeof(request-proxy-src_ipaddr));
+ memset(request-proxy-dst_ipaddr, 0,
+ sizeof(request-proxy-dst_ipaddr));
request-proxy-src_port = 0;
request-proxy-dst_port = 0;
fake-packet = NULL;
Bug#657078: Patches to reduce footprint of nfs idmapper
Hi, With the freeze in a few weeks, I'm wondering if you would still consider applying the following patches to the Wheezy kernel: NFSv4: Further reduce the footprint of the idmapper commit 685f50f9188ac1e8244d0340a9d6ea36b6136cec NFSv4: Reduce the footprint of the idmapper commit d073e9b541e1ac3f52d72c3a153855d9a9ee3278 They are in the upstream kernel 3.4 kernel, were also backported by Fedora into their 3.2 kernel, and will be part of RHEL 6.3. A comment from Jeff Layton in the bug report seems to indicate the patches are relatively independent. The patches don't meet the requirements for a stable update, but please consider applying these patches to the Debian kernel. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664859: LVM segfaults on 3.3-rc6
Hi, On 05/12/2012 11:32 PM, Ben Hutchings wrote: On Sat, 2012-05-12 at 16:25 -0500, Jonathan Nieder wrote: Ben Hutchings wrote: Which shows that the segfault is always at the same code address: [ 56.663596] lvm[540]: segfault at ff600400 ip ff600400 sp 7fff25461ec8 error 5 [ 76.174282] exe[541]: segfault at ff600400 ip ff600400 sp 7fffa69b3388 error 5 [ 78.307062] exe[542]: segfault at ff600400 ip ff600400 sp 7fff33270d08 error 5 [ 87.775183] exe[543]: segfault at ff600400 ip ff600400 sp 7b125068 error 5 [ 97.937356] exe[545]: segfault at ff600400 ip ff600400 sp 7fffb53be498 error 5 [ 108.789157] lvm[547]: segfault at ff600400 ip ff600400 sp 7fff0e012348 error 5 This address is not accessible in user-mode, and probably isn't used by the kernel either. Nice lead. Looks like http://thread.gmane.org/gmane.linux.kernel/1248253/focus=1254330 Agreed. Rik, which version of the kernel is the hypervisor from? The hypervisor is CentOS 6.2 with kernel version 2.6.32-220.7.1.el6.x86_64 and qemu-kvm-0.12.1.2-2.209.el6_2.4.x86_64. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664859: LVM segfaults on 3.3-rc6
Hi, On 05/14/2012 10:52 AM, Ben Hutchings wrote: On Mon, 2012-05-14 at 08:48 +0200, Rik Theys wrote: Hi, On 05/12/2012 11:32 PM, Ben Hutchings wrote: On Sat, 2012-05-12 at 16:25 -0500, Jonathan Nieder wrote: Ben Hutchings wrote: Which shows that the segfault is always at the same code address: [ 56.663596] lvm[540]: segfault at ff600400 ip ff600400 sp 7fff25461ec8 error 5 [ 76.174282] exe[541]: segfault at ff600400 ip ff600400 sp 7fffa69b3388 error 5 [ 78.307062] exe[542]: segfault at ff600400 ip ff600400 sp 7fff33270d08 error 5 [ 87.775183] exe[543]: segfault at ff600400 ip ff600400 sp 7b125068 error 5 [ 97.937356] exe[545]: segfault at ff600400 ip ff600400 sp 7fffb53be498 error 5 [ 108.789157] lvm[547]: segfault at ff600400 ip ff600400 sp 7fff0e012348 error 5 This address is not accessible in user-mode, and probably isn't used by the kernel either. Nice lead. Looks like http://thread.gmane.org/gmane.linux.kernel/1248253/focus=1254330 Agreed. Rik, which version of the kernel is the hypervisor from? The hypervisor is CentOS 6.2 with kernel version 2.6.32-220.7.1.el6.x86_64 and qemu-kvm-0.12.1.2-2.209.el6_2.4.x86_64. OK, so it doesn't look we have a bug to fix. Based on that email thread I think you can work around this with 'vsyscall=native' on the guest's kernel command line. The down-side of this is that it makes it easier to exploit some types of bug for privilege escalation. Thanks, that does indeed fix the issue. It will do for now as it's just a test box. I'm sure Red Hat will fix this in one of their future updates. If I find some time, I'll check if a current Wheezy hypervisor also has this problem. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659111: Regarding NFSv4: Save the owner/group name string when doing open
Hi, On 05/10/2012 02:56 PM, Rik Theys wrote: So, the Save owner/group name string is the most efficient way of ensuring that the open works as expected, and it should be a fairly self-contained patch. There is an alternative solution, which is much shorter (and therefore appropriate for stable kernels). That is to add a line of the form snip/ I will build a kernel with this change applied and see if it fixes the issue. Jonathan was wondering if a similar line is needed in nfs4_open_reclaim? I built a kernel with the one-line patch applied and it fixes the issue. I applied the patch on the 3.2.16 kernel currently in sid. I'm now building a 2.6.32 package to test it on squeeze, but I assume it will. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659111: Regarding NFSv4: Save the owner/group name string when doing open
Hi, On 05/10/2012 05:08 PM, Jonathan Nieder wrote: I looked at the 2.6.32-44 kernel source to see if the simple fix Trond suggested can be applied there as well, but I fail to find the context where the extra line could be needed. Here's a patch to try against 2.6.32.y. Hope that helps, Jonathan fs/nfs/nfs4proc.c |1 + 1 file changed, 1 insertion(+) diff --git i/fs/nfs/nfs4proc.c w/fs/nfs/nfs4proc.c index 3c759df78f36..21c7190691d8 100644 --- i/fs/nfs/nfs4proc.c +++ w/fs/nfs/nfs4proc.c @@ -1586,6 +1586,7 @@ static int _nfs4_do_open(struct inode *dir, struct path *path, fmode_t fmode, in goto err_opendata_put; if (server-caps NFS_CAP_POSIX_LOCK) set_bit(NFS_STATE_POSIX_LOCKS,state-flags); + nfs_revalidate_inode(server, state-inode); nfs4_opendata_put(opendata); nfs4_put_state_owner(sp); *res = state; I've applied this patch to the Debian 2.6.32-44 kernel and it works there as well. Please consider applying this patch in a future kernel update. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659111: Regarding NFSv4: Save the owner/group name string when doing open
Hi,
On 05/09/2012 04:34 PM, Myklebust, Trond wrote:
Can you please comment on wether additional fixes and/or
dependencies are needed to backport the patch below to the Debian
3.2 kernel?
So, the Save owner/group name string is the most efficient way of
ensuring that the open works as expected, and it should be a fairly
self-contained patch.
There is an alternative solution, which is much shorter (and therefore
appropriate for stable kernels). That is to add a line of the form
nfs_revalidate_inode(server, state-inode);
in _nfs4_do_open() immediately after the if (opendata-o_arg.open_flags
O_EXCL) {} condition. That will cause the NFSv4 client to send an
extra GETATTR if the inode is incomplete.
I will build a kernel with this change applied and see if it fixes the
issue. Jonathan was wondering if a similar line is needed in
nfs4_open_reclaim?
To me, it would make more sense to apply the upstream patch (to the
Debian kernel) as it has been tested in the more recent kernels and is
self-contained. But I will leave that decision up to the Debian maintainers.
I looked at the 2.6.32-44 kernel source to see if the simple fix Trond
suggested can be applied there as well, but I fail to find the context
where the extra line could be needed. So I'm not sure if it applies to
the 2.6.32 kernel. Would it nice if it did as it would have a bigger
chance of being applied there as well then.
Note that I've been running the patches Jonathan provided in the bug
report[1] on a squeeze box for 47 days now without any issues and the
issue is fixed by those as well:
v2.6.33-rc1~54^2~7 rpc: add a new priority in RPC task, 2009-12-14
v2.6.33-rc1~54^2~5 nfs: make recovery state manager operations
privileged, 2009-12-14
v3.3-rc1~116^2~1 NFSv4: Save the owner/group name string when doing
open, 2012-01-07
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659111
Regards,
Rik
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659111: Regarding NFSv4: Save the owner/group name string when doing open
Hi Trond, Can you please comment on wether additional fixes and/or dependencies are needed to backport the patch below to the Debian 3.2 kernel? The Debian kernel maintainers would prefer some feedback before applying the fix to their 3.2 kernel. Regards, Rik On 04/25/2012 03:14 AM, Ben Hutchings wrote: On Tue, 2012-04-24 at 22:04 +0200, Rik Theys wrote: Hi, I'm experiencing the bug described in the Debian[1] and Red Hat[2] bug tracker. This bug seems to have been fixed in the 3.3 kernel with your commit 6926afd1925a54a13684ebe05987868890665e2b: From: Trond Myklebusttrond.mykleb...@netapp.com Date: Sat, 7 Jan 2012 13:22:46 -0500 Subject: NFSv4: Save the owner/group name string when doing open commit 6926afd1925a54a13684ebe05987868890665e2b upstream. ...so that we can do the uid/gid mapping outside the asynchronous RPC context. This fixes a bug in the current NFSv4 atomic open code where the client isn't able to determine what the true uid/gid fields of the file are, (because the asynchronous nature of the OPEN call denies it the ability to do an upcall) and so fills them with default values, marking the inode as needing revalidation. Unfortunately, in some cases, the VFS will do some additional sanity checks on the file, and may override the server's decision to allow the open because it sees the wrong owner/group fields. Signed-off-by: Trond Myklebusttrond.mykleb...@netapp.com Signed-off-by: Jonathan Niederjrnie...@gmail.com It seems Red Hat will apply the patch in their RHEL 6.3 kernel. I would also like to see this patch included in the upcoming Debian 7.0 kernel, which is based on kernel 3.2. I would like to propose this patch for a stable kernel update (3.2.x and/or 3.0.x). Trond, do you agree that this patch (alone) can/should be part of a stable update? The Debian maintainers would prefer to see the patch be part of a stable update to consider it. Note that this is not a *requirement* for the Debian kernel package. But we do prefer to get backported bug fixes reviewed and tested through the stable process, and shared with other distributions in this way. Now that I've finally had a look at this patch - and I'm sorry it's taken this long, but I do have a *lot* of different bugs and patches to look at: - With my 3.2-stable maintainer hat on, I'm going to follow Greg's judgement and say this isn't suitable. - With my Debian kernel team hat on, I think this is probably OK, but I'd like to see Trond comment on whether he's aware of any dependencies or further fixes likely to be needed. Ben. -- Rik Theys Senior System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 B-3001 LEUVEN - HEVERLEE Tel.: +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659111: Regarding NFSv4: Save the owner/group name string when doing open
Hi, On Tue, 8 May 2012, Jonathan Nieder wrote: Hi Trond, Can you please comment on wether additional fixes and/or dependencies are needed to backport the patch below to the Debian 3.2 kernel? The Debian kernel maintainers would prefer some feedback before applying the fix to their 3.2 kernel. No, the maintainers are just busy. I think everything's in order already. I asked Ben on IRC and he's still waiting on feedback from Trond first: [21:04] rik_ bwh: regarding bug 659111, Jonathan commented that everything is in order. Did I miss a reply from Trond? Will the patch be applied to a future kernel update? [21:08] bwh I don't see any reply from Trond [21:09] bwh and I really do want to see that Trond, would you mind commenting on this patch? Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670505: linux-image-3.2.0-0.bpo.2-amd64: 3.2.{14, 15} regression: NFS delegation problems
Package: linux-2.6 Version: 3.2.15-1~bpo60+1 Severity: important Hi, It seems stable update 3.2.14 or 3.2.15 introduced a regression regarding NFS4 delegations. It seems to be the same issue as reported here[1] against the 3.3 kernel. It was also intruduced there between 3.3.0 and 3.3.1. [1] https://bugzilla.redhat.com/show_bug.cgi?id=811138 The following BUG is triggered when logging into gnome, but seems to be easily reproduceable by using flock (see Fedora bug report). Apr 25 14:06:02 bach gdm-simple-greeter[2320]: WARNING: Failed to send buffer Apr 25 14:06:05 bach kernel: [ 78.797185] BUG: unable to handle kernel paging request at ffb8 Apr 25 14:06:05 bach kernel: [ 78.797233] IP: [a048f016] nfs_mark_delegation_referenced+0x6/0x6 [nfs] Apr 25 14:06:05 bach kernel: [ 78.797289] PGD 1607067 PUD 1608067 PMD 0 Apr 25 14:06:05 bach kernel: [ 78.797319] Oops: [#1] SMP Apr 25 14:06:05 bach kernel: [ 78.797344] CPU 3 Apr 25 14:06:05 bach kernel: [ 78.797357] Modules linked in: autofs4 acpi_cpufreq mperf cpufreq_stats cpufreq_userspace cpufreq_powersave cpufreq_conservative ip6_tables ppdev lp bridge stp bnep rfcomm bluetooth rfkill tun binfmt_misc uinput kvm_intel kvm fuse nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc ipt_REJECT xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables ext3 jbd loop snd_hda_codec_analog ses enclosure snd_hda_intel snd_hda_codec snd_hwdep i915 snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device joydev snd drm_kms_helper usbhid usb_storage hid evdev dell_wmi soundcore parport_pc i2c_i801 drm i2c_algo_bit i2c_core processor uas button video snd_page_alloc pcspkr sparse_keymap parport tpm_tis tpm tpm_bios wmi dcdbas psmouse serio_raw thermal_sys ext4 mbcache jbd2 crc16 dm_mod sg sr_mod sd_mod cdrom crc_t10dif uhci_hcd ahci libahci ata_generic ehci_hcd lib ata e1000e usbcore scsi_mod usb_com Apr 25 14:06:05 bach kernel: mon [last unloaded: scsi_wait_scan] Apr 25 14:06:05 bach kernel: [ 78.798038] Apr 25 14:06:05 bach kernel: [ 78.798050] Pid: 3095, comm: gnome-keyring-d Not tainted 3.2.0-0.bpo.2-amd64 #1 Dell Inc. OptiPlex 760 /0M858N Apr 25 14:06:05 bach kernel: [ 78.798114] RIP: 0010:[a048f016] [a048f016] nfs_mark_delegation_referenced+0x6/0x6 [nfs] Apr 25 14:06:05 bach kernel: [ 78.798177] RSP: 0018:88021eca9e40 EFLAGS: 00010246 Apr 25 14:06:05 bach kernel: [ 78.798206] RAX: 88021eca5000 RBX: d8ca RCX: d8ca Apr 25 14:06:05 bach kernel: [ 78.798244] RDX: 88021eca9eb8 RSI: 0001 RDI: Apr 25 14:06:05 bach kernel: [ 78.798281] RBP: 88021eca9eb8 R08: d8ca R09: a0499a60 Apr 25 14:06:05 bach kernel: [ 78.798318] R10: R11: 88022e7c8b00 R12: 88022ddfb000 Apr 25 14:06:05 bach kernel: [ 78.798356] R13: 88022da7fc00 R14: 88022e7c8b00 R15: Apr 25 14:06:05 bach kernel: [ 78.798394] FS: 7f09050907a0() GS:880237cc() knlGS: Apr 25 14:06:05 bach kernel: [ 78.798436] CS: 0010 DS: ES: CR0: 80050033 Apr 25 14:06:05 bach kernel: [ 78.798467] CR2: ffb8 CR3: 00021eda7000 CR4: 000406e0 Apr 25 14:06:05 bach kernel: [ 78.798504] DR0: DR1: DR2: Apr 25 14:06:05 bach kernel: [ 78.798541] DR3: DR6: 0ff0 DR7: 0400 Apr 25 14:06:05 bach kernel: [ 78.798579] Process gnome-keyring-d (pid: 3095, threadinfo 88021eca8000, task 88021ec841c0) Apr 25 14:06:05 bach kernel: [ 78.798625] Stack: Apr 25 14:06:05 bach kernel: [ 78.798637] a047d657 88022e7c8b00 88022da93600 88022e7c8b00 Apr 25 14:06:05 bach kernel: [ 78.798685] 00fa 0006 0002 88022e7c8b40 Apr 25 14:06:05 bach kernel: [ 78.798732] a04813f2 88022ddfb048 88021eca9eb8 Apr 25 14:06:05 bach kernel: [ 78.798779] Call Trace: Apr 25 14:06:05 bach kernel: [ 78.798804] [a047d657] ? nfs4_handle_exception+0x149/0x2b8 [nfs] Apr 25 14:06:05 bach kernel: [ 78.798851] [a04813f2] ? nfs4_proc_lock+0x2d9/0x348 [nfs] Apr 25 14:06:05 bach kernel: [ 78.798892] [a046a48f] ? do_setlk+0x59/0xcc [nfs] Apr 25 14:06:05 bach kernel: [ 78.798926] [8113c83b] ? sys_flock+0x10c/0x137 Apr 25 14:06:05 bach kernel: [ 78.798958] [81369812] ? system_call_fastpath+0x16/0x1b Apr 25 14:06:05 bach kernel: [ 78.798991] Code: 5d 41 5c 41 5d 48 c7 c6 d0 ad 49 a0 48 c7 c7 19 07 4a a0 31 c0 e9 33 35 ed e0 59 5b 5d 41 5c 41 5d c3 90 90 90 f0 80 4f 48 04 c3 48 8b 47 b8 48 85 c0 74 17 8b 50 30 83 e6 03 21 f2 39 f2 75 0b Apr 25 14:06:05 bach kernel: [ 78.799224] RIP [a048f016]
Bug#670505: [3.2.12 - 3.2.14 regression] BUG: unable to handle kernel paging request in nfs_mark_delegation_referenced
Hi Jonathan, On Thu, 26 Apr 2012, Jonathan Nieder wrote: Rik Theys wrote: It seems stable update 3.2.14 or 3.2.15 introduced a regression regarding NFS4 delegations. It seems to be the same issue as reported here[1] against the 3.3 kernel. It was also intruduced there between 3.3.0 and 3.3.1. [...] BUG: unable to handle kernel paging request at ffb8 IP: [a048f016] nfs_mark_delegation_referenced+0x6/0x6 [nfs] In [1], Jeff Layton says it looks like a regression introduced by 3114ea7a24d3 NFSv4: Return the delegation if the server returns NFS4ERR_OPENMODE and suggests a fix. Does this patch help? -- 8 -- From: Trond Myklebust trond.mykleb...@netapp.com Date: Tue, 27 Mar 2012 18:31:25 -0400 Subject: NFSv4: Minor cleanups for nfs4_handle_exception and nfs4_async_handle_error commit 14977489ffdb80d4caf5a184ba41b23b02fbacd9 upstream. If I read [1] correctly this patch was pushed in a Fedora update, and results in the following message being spewed at syslog by the thousands (filling the disk): NFS: nfs4_reclaim_open_state: Lock reclaim failed! I will try applying the patch to the Debian kernel next week, but I assume it will have the same result. If so, I believe it would be better to revert the bad commit for now, and apply a complete fix later when it becomes available. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657078: patches to reduce the footprint of the nfs4 idmapper
Hi, On 04/24/2012 10:45 PM, Jonathan Nieder wrote: Could you describe the problem in more detail? Under what circumstances does the idmapper provoke allocation failures, and how effectively do the patches avoid trouble? We have two big NFSv4 file servers that also automount from each other to provide homedirs over samba. These machines are accessed by a few hundred NFSv4 clients. On these (RHEL6) servers we see this issue come up sometimes twice a day, sometimes twice a week (since 6.2). The are reports that Debian is affected by this bug as well, for example http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636306 I've tried to reproduce this issue in the past but failed, so it's very hard to determine if the patches help a lot. But from what I've been able to find the patches dramatically reduce the memory needed (now order 4). I don't know if you can see the following Red Hat bug report? https://bugzilla.redhat.com/show_bug.cgi?id=730045 An upstream thread that starts talking about the memory issue can be found here: http://www.spinics.net/lists/linux-nfs/msg27350.html An initial patch brought this down from order 4 to order 2. A bit further down the thread they mention: Much, much better! Nice work. Built on a different machine this time with a different compiler, so sizes are a little different. Not certain why, but they're fairly close -- maybe differences in padding or something: Without either patch: (gdb) p sizeof(struct idmap) $1 = 39168 With just the first patch: (gdb) p sizeof(struct idmap) $1 = 8448 With both patches: (gdb) p sizeof(struct idmap) $1 = 272 Since the thread is also about the new nfs ID mapper, it could be that this large reduction is only (partialy) achieved if the new id mapper is in use. But since they applied it in Fedora 16, which also still has the old id mapper, I assume it's good. NFSv4: Further reduce the footprint of the idmapper commit 685f50f9188ac1e8244d0340a9d6ea36b6136cec NFSv4: Reduce the footprint of the idmapper commit d073e9b541e1ac3f52d72c3a153855d9a9ee3278 Whether or not these get applied in the stable tree (which would be nice if it can be justified), I think we definitely want them in Debian, so cloning the bug to track that. I agree! (but I'm biased). Regards, Rik -- Rik Theys Senior System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 B-3001 LEUVEN - HEVERLEE Tel.: +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657078: patches to reduce the footprint of the nfs4 idmapper
Hi, On 04/24/2012 11:16 PM, Jeff Layton wrote: On Tue, 24 Apr 2012 13:35:13 -0700 Greg KHgre...@linuxfoundation.org wrote: On Tue, Apr 24, 2012 at 10:22:50PM +0200, Rik Theys wrote: Hi, I'm experiencing the following Red Hat bug[1] on RHEL and also on Debian. I've noticed Fedora has started to ship an update with two patches that reduce the footprint of the nfs4 id mapper which should prevent this (or seriously limit the chance). NFSv4: Further reduce the footprint of the idmapper commit 685f50f9188ac1e8244d0340a9d6ea36b6136cec NFSv4: Reduce the footprint of the idmapper commit d073e9b541e1ac3f52d72c3a153855d9a9ee3278 I believe Red Hat will have those patches in an upcoming RHEL 6.x release. I'm looking for feedback on if it would be possible to include these patches in a stable 3.2 update (and/or 3.0.x) so they will become part of the upcoming Debian 7.0 kernel (which is based on 3.2). Have these patches made it into the 3.3 and/or 3.4-rc kernels? Both of these are in the 3.4-rc1 kernel release. As for stable kernels, I don't see how they fit the rules outlined in Documentation/stable_kernel_rules.txt, do you? There have been reports on linux-nfs of problems allocating this memory in the past. I suspect most of those occurred when people attempt to do an NFS mount after memory is already heavily fragmented. This allocation was fricking huge before those patches... That said, I'm not sure that really qualifies as stable-kernel fodder... After rereading the stable_kernel_rules.txt I agree that this might be too big for a stable update. I would still like to see these patches in the Debian 3.2 kernel (bug report in cc). Do you consider these patches something distributions could/should cherry pick for their kernels? I see from the RHEL 6.3 beta kernel (2.6.32-262.el6) changelog that it includes these fixes? Maybe you and/or Trond could comment on whether you are aware of any dependencies or further fixes likely to be needed? Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659111: Regarding NFSv4: Save the owner/group name string when doing open
Hi, On 04/25/2012 03:14 AM, Ben Hutchings wrote: On Tue, 2012-04-24 at 22:04 +0200, Rik Theys wrote: Hi, I'm experiencing the bug described in the Debian[1] and Red Hat[2] bug tracker. This bug seems to have been fixed in the 3.3 kernel with your commit 6926afd1925a54a13684ebe05987868890665e2b: From: Trond Myklebusttrond.mykleb...@netapp.com Date: Sat, 7 Jan 2012 13:22:46 -0500 Subject: NFSv4: Save the owner/group name string when doing open commit 6926afd1925a54a13684ebe05987868890665e2b upstream. ...so that we can do the uid/gid mapping outside the asynchronous RPC context. This fixes a bug in the current NFSv4 atomic open code where the client isn't able to determine what the true uid/gid fields of the file are, (because the asynchronous nature of the OPEN call denies it the ability to do an upcall) and so fills them with default values, marking the inode as needing revalidation. Unfortunately, in some cases, the VFS will do some additional sanity checks on the file, and may override the server's decision to allow the open because it sees the wrong owner/group fields. Signed-off-by: Trond Myklebusttrond.mykleb...@netapp.com Signed-off-by: Jonathan Niederjrnie...@gmail.com It seems Red Hat will apply the patch in their RHEL 6.3 kernel. I would also like to see this patch included in the upcoming Debian 7.0 kernel, which is based on kernel 3.2. I would like to propose this patch for a stable kernel update (3.2.x and/or 3.0.x). Trond, do you agree that this patch (alone) can/should be part of a stable update? The Debian maintainers would prefer to see the patch be part of a stable update to consider it. Note that this is not a *requirement* for the Debian kernel package. But we do prefer to get backported bug fixes reviewed and tested through the stable process, and shared with other distributions in this way. Now that I've finally had a look at this patch - and I'm sorry it's taken this long, but I do have a *lot* of different bugs and patches to look at: No problem, thanks for your time. - With my 3.2-stable maintainer hat on, I'm going to follow Greg's judgement and say this isn't suitable. OK - With my Debian kernel team hat on, I think this is probably OK, but I'd like to see Trond comment on whether he's aware of any dependencies or further fixes likely to be needed. Thank you for considering this patch. Hopefully Trond can comment on this and provide you with any information about possible additional fixes. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659111: Regarding NFSv4: Save the owner/group name string when doing open
Hi, I'm experiencing the bug described in the Debian[1] and Red Hat[2] bug tracker. This bug seems to have been fixed in the 3.3 kernel with your commit 6926afd1925a54a13684ebe05987868890665e2b: From: Trond Myklebust trond.mykleb...@netapp.com Date: Sat, 7 Jan 2012 13:22:46 -0500 Subject: NFSv4: Save the owner/group name string when doing open commit 6926afd1925a54a13684ebe05987868890665e2b upstream. ...so that we can do the uid/gid mapping outside the asynchronous RPC context. This fixes a bug in the current NFSv4 atomic open code where the client isn't able to determine what the true uid/gid fields of the file are, (because the asynchronous nature of the OPEN call denies it the ability to do an upcall) and so fills them with default values, marking the inode as needing revalidation. Unfortunately, in some cases, the VFS will do some additional sanity checks on the file, and may override the server's decision to allow the open because it sees the wrong owner/group fields. Signed-off-by: Trond Myklebust trond.mykleb...@netapp.com Signed-off-by: Jonathan Nieder jrnie...@gmail.com It seems Red Hat will apply the patch in their RHEL 6.3 kernel. I would also like to see this patch included in the upcoming Debian 7.0 kernel, which is based on kernel 3.2. I would like to propose this patch for a stable kernel update (3.2.x and/or 3.0.x). Trond, do you agree that this patch (alone) can/should be part of a stable update? The Debian maintainers would prefer to see the patch be part of a stable update to consider it. Regards, Rik [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659111 [2] https://bugzilla.redhat.com/show_bug.cgi?format=multipleid=789298 -- Rik Theys Senior System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 B-3001 LEUVEN - HEVERLEE Tel.: +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657078: patches to reduce the footprint of the nfs4 idmapper
Hi, I'm experiencing the following Red Hat bug[1] on RHEL and also on Debian. I've noticed Fedora has started to ship an update with two patches that reduce the footprint of the nfs4 id mapper which should prevent this (or seriously limit the chance). NFSv4: Further reduce the footprint of the idmapper commit 685f50f9188ac1e8244d0340a9d6ea36b6136cec NFSv4: Reduce the footprint of the idmapper commit d073e9b541e1ac3f52d72c3a153855d9a9ee3278 I believe Red Hat will have those patches in an upcoming RHEL 6.x release. I'm looking for feedback on if it would be possible to include these patches in a stable 3.2 update (and/or 3.0.x) so they will become part of the upcoming Debian 7.0 kernel (which is based on 3.2). Have these patches made it into the 3.3 and/or 3.4-rc kernels? Regards, Rik -- Rik Theys Senior System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 B-3001 LEUVEN - HEVERLEE Tel.: +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669213: bind9: new upstream release: 9.9
Package: bind9 Severity: wishlist Hi, Please consider packaging the new upstream 9.9 release for sid/wheezy. It has some new features that make rolling out DNSSEC easier (such as inline signing). Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659111: [2.6.31 - 2.6.32 regression] Files on NFS4 become unwritable,, but OK after explicit stat
Hi, On 03/21/2012 06:39 PM, Jonathan Nieder wrote: Rik Theys wrote: Can this commit be backported to the 3.2 kernel in sid? It applies and I have tested it in the past against the 3.2.4 kernel. Just for the record: we are talking about v3.3-rc1~116^2~1 NFSv4: Save the owner/group name string when doing open, 2012-01-07 It looks safe to me, too. It is too large to follow the rules of Greg's 3.2.y-stable kernel to the letter, but I think we should apply it. It seems the patch still has not made it into the sid kernel. Any reason this patch hasn't been cherry picked yet? For 2.6.32.y-longterm, I would be happier with a more minimal patch. Where can one find more information about the rpciod hang described in the commit message to 80e52aced138b (NFSv4: Don't do idmapper upcalls for asynchronous RPC calls, 2009-08-09)? Maybe there is some alternative fix to that. I would also be very much interested to hear how well the following series against 2.6.32.y does: v2.6.33-rc1~54^2~7 rpc: add a new priority in RPC task, 2009-12-14 v2.6.33-rc1~54^2~5 nfs: make recovery state manager operations privileged, 2009-12-14 v3.3-rc1~116^2~1 NFSv4: Save the owner/group name string when doing open, 2012-01-07 I've been running a patched squeeze kernel with those patches applied for about two weeks now and it fixes the bug. I have not seen any regressions in other nfs functionality using these patches. It would be great to have this fixed in squeeze if not considered too intrusive. But I would definitely like to see these patches land in the sid/wheezy kernel, so Wheezy will not have this bug. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664859: LVM segfaults on 3.3-rc6
Hi Jonathan, On 03/22/2012 04:16 PM, Jonathan Nieder wrote: It seems it's not only lvm that segfaults, but also ls etc in the initramfs. Thanks. Are symptoms tied to the version of initramfs-tools or one of its dependencies, or to the kernel version? E.g., if you install another kernel or use update-initramfs -k foo -u to update an existing one, does the newly built initramfs produce segfaults, too? I updated the initramfses for all kernels on the system (2.6.32, 3.2, 3.3). The new 3.3 image still has the segfaults, the others boot OK. I ran a diff between the update-initramfs -v output from a working and non-working kernel but I can't spot a difference. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664859: LVM segfaults on 3.3-rc6
Hi, On 03/21/2012 05:27 PM, Jonathan Nieder wrote: When booting with the quiet option off, I see that the lvm command in the initrd segfaults. Can you get a backtrace, for example by saving a core file to some other (virtual) disk and analyzing it afterward with gdb? See http://wiki.debian.org/InitramfsDebug for some hints. I captured the boot via the serial console and provided the debug command line parameter to get into the initramfs prompt. It seems it's not only lvm that segfaults, but also ls etc in the initramfs. In attach the log of my session. Would unpacking the initramfs on a sid box with the 3.3 kernel and chrooting into it be able to provide any additional info? I believe the initramfs uses another C library than glibc, or is that no longer the case? Regards, Rik Loading Linux 3.3.0-rc6-amd64 ... Loading initial ramdisk ... [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.3.0-rc6-amd64 (Debian 3.3~rc6-1~experimental.1) (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-1) ) #1 SMP Mon Mar 5 20:53:11 UTC 2012 [0.00] Command line: BOOT_IMAGE=/vmlinuz-3.3.0-rc6-amd64 root=/dev/mapper/vg_squeeze-root ro ipv6.disable=1 console=tty0 console=ttyS0,38400n8 debug [0.00] Disabled fast string operations [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009dc00 (usable) [0.00] BIOS-e820: 0009dc00 - 000a (reserved) [0.00] BIOS-e820: 000f - 0010 (reserved) [0.00] BIOS-e820: 0010 - dfffd000 (usable) [0.00] BIOS-e820: dfffd000 - e000 (reserved) [0.00] BIOS-e820: fffbc000 - 0001 (reserved) [0.00] BIOS-e820: 0001 - 00042000 (usable) [0.00] NX (Execute Disable) protection: active [0.00] DMI 2.4 present. [0.00] DMI: Red Hat KVM, BIOS 0.5.1 01/01/2007 [0.00] e820 update range: - 0001 (usable) == (reserved) [0.00] e820 remove range: 000a - 0010 (usable) [0.00] No AGP bridge found [0.00] last_pfn = 0x42 max_arch_pfn = 0x4 [0.00] MTRR default type: write-back [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 00E000 mask 3FE000 uncachable [0.00] 1 disabled [0.00] 2 disabled [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] x86 PAT enabled: cpu 0, old 0x70106, new 0x7010600070106 [0.00] last_pfn = 0xdfffd max_arch_pfn = 0x4 [0.00] found SMP MP-table at [880fd9d0] fd9d0 [0.00] initial memory mapped : 0 - 2000 [0.00] Base memory trampoline at [88098000] 98000 size 20480 [0.00] init_memory_mapping: -dfffd000 [0.00] 00 - 00dfe0 page 2M [0.00] 00dfe0 - 00dfffd000 page 4k [0.00] kernel direct mapping tables up to dfffd000 @ 1fffa000-2000 [0.00] init_memory_mapping: 0001-00042000 [0.00] 01 - 042000 page 2M [0.00] kernel direct mapping tables up to 42000 @ dffeb000-dfffd000 [0.00] RAMDISK: 375a3000 - 37ff [0.00] ACPI: RSDP 000fd980 00014 (v00 BOCHS ) [0.00] ACPI: RSDT dfffd290 00030 (v01 BOCHS BXPCRSDT 0001 BXPC 0001) [0.00] ACPI: FACP dce0 00074 (v01 BOCHS BXPCFACP 0001 BXPC 0001) [0.00] ACPI: DSDT dfffd730 02544 (v01 BXPC BXDSDT 0001 INTL 20090123) [0.00] ACPI: FACS dc80 00040 [0.00] ACPI: SSDT dfffd3e0 00345 (v01 BOCHS BXPCSSDT 0001 BXPC 0001) [0.00] ACPI: APIC dfffd2c0 000B0 (v01 BOCHS BXPCAPIC 0001 BXPC 0001) [0.00] ACPI: Local APIC address 0xfee0 [0.00] No NUMA configuration found [0.00] Faking a node at -00042000 [0.00] Initmem setup node 0 -00042000 [0.00] NODE_DATA [00041fffb000 - 00041fff] [0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00 [0.00] kvm-clock: cpu 0, msr 0:1698381, boot clock [0.00] [ea00-ea000e7f] PMD - [88040f60-88041d7f] on node 0 [0.00] Zone PFN ranges: [0.00] DMA 0x0010 - 0x1000 [0.00] DMA320x1000 - 0x0010 [0.00] Normal 0x0010 - 0x0042 [0.00] Movable zone start PFN for each node [
Bug#664859: LVM segfaults on 3.3-rc6
Hi, On 03/22/2012 01:12 PM, Rik Theys wrote: Would unpacking the initramfs on a sid box with the 3.3 kernel and chrooting into it be able to provide any additional info? I believe the initramfs uses another C library than glibc, or is that no longer the case? I did this, but when I chroot into the unpacked initrd and run /bin/sh (busybox) it works :-/. Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664859: linux-image-3.3.0-rc6-amd64: LVM segfaults on 3.3 kernel
Package: linux-2.6 Version: 3.3~rc6-1~experimental.1 Severity: important Hi, I installed the 3.3.0-rc6-amd64 kernel from experimental on a squeeze VM. The system fails to boot this kernel as it can no longer find the root file system. When booting with the quiet option off, I see that the lvm command in the initrd segfaults. Are there any changes in the new kernel that require a more recent LVM? Regards, Rik -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: Red Hat product_name: KVM product_version: RHEL 6.2.0 PC chassis_vendor: Red Hat chassis_version: bios_vendor: Seabios bios_version: 0.5.1 ** Network interface configuration: auto lo iface lo inet loopback up /sbin/iptables-restore /etc/network/firewall auto eth0 iface eth0 inet dhcp ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC [Natoma] [8086:1237] (rev 02) Subsystem: Red Hat, Inc Qemu virtual machine [1af4:1100] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- 00:01.0 ISA bridge [0601]: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] [8086:7000] Subsystem: Red Hat, Inc Qemu virtual machine [1af4:1100] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 00:01.1 IDE interface [0101]: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] [8086:7010] (prog-if 80 [Master]) Subsystem: Red Hat, Inc Qemu virtual machine [1af4:1100] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Region 0: [virtual] Memory at 01f0 (32-bit, non-prefetchable) [size=8] Region 1: [virtual] Memory at 03f0 (type 3, non-prefetchable) [size=1] Region 2: [virtual] Memory at 0170 (32-bit, non-prefetchable) [size=8] Region 3: [virtual] Memory at 0370 (type 3, non-prefetchable) [size=1] Region 4: I/O ports at c000 [size=16] Kernel driver in use: ata_piix 00:01.2 USB Controller [0c03]: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] [8086:7020] (rev 01) (prog-if 00 [UHCI]) Subsystem: Red Hat, Inc Qemu virtual machine [1af4:1100] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin D routed to IRQ 11 Region 4: I/O ports at c020 [size=32] Kernel driver in use: uhci_hcd 00:01.3 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI [8086:7113] (rev 03) Subsystem: Red Hat, Inc Qemu virtual machine [1af4:1100] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 9 Kernel driver in use: piix4_smbus 00:02.0 VGA compatible controller [0300]: Red Hat, Inc. Device [1b36:0100] (rev 03) (prog-if 00 [VGA controller]) Subsystem: Red Hat, Inc Device [1af4:1100] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 10 Region 0: Memory at f000 (32-bit, non-prefetchable) [size=64M] Region 1: Memory at e000 (32-bit, non-prefetchable) [size=64M] Region 2: Memory at f400 (32-bit, non-prefetchable) [size=8K] Region 3: I/O ports at c040 [size=32] Expansion ROM at f401 [disabled] [size=64K] 00:03.0 Ethernet controller [0200]: Red Hat, Inc Virtio network device [1af4:1000] Subsystem: Red Hat, Inc Device [1af4:0001] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 10 Region 0: I/O ports at c060 [size=32] Region 1: Memory at f402 (32-bit, non-prefetchable) [size=4K] Expansion ROM at f403 [disabled] [size=64K] Capabilities: access denied Kernel driver in use: virtio-pci 00:04.0 Communication controller [0780]: Red Hat, Inc Virtio console [1af4:1003] Subsystem: Red Hat,
Bug#659111: [2.6.31 - 2.6.32 regression] Files on NFS4 become unwritable,, but OK after explicit stat
fixed-upstream 659111 fixed 659111 linux-2.6/3.3~rc6-1~experimental.1 quit Hi, The commit that fixes this bug is now part of the upstream 3.3 kernel. I verified it on the 3.3-rc6 kernel from experimental. Can this commit be backported to the 3.2 kernel in sid? It applies and I have tested it in the past against the 3.2.4 kernel. I agree that fixing it in squeeze might be a stretch, but it would be nice to have it in Wheezy. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636306: Patches available in Fedora kernel
Hi,
The Fedora 16 kernel 3.2.10-3.fc16 has patches that should reduce the
memory requirements of the old id mapper. The relevant changelog entry is:
* Wed Mar 14 2012 Steve Dickson ste...@redhat.com
- Reduce the foot print of the NFSv4 idmapping coda (bz 593035)
I have attached the patches they have applied.
The following bug report shows that also RHEL6 is affected by this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=730045
I assume the patches they applied to their future 6.3 kernel are the
same as the Fedora patches and they confirm they fix the issue.
If switching to the new ID mapper code (bug 657078) is not considered
for the Wheezy kernel, please consider applying these patches to the 3.2
kernel in sid/testing.
Regards,
Rik
diff -up linux-3.2.noarch/fs/nfs/idmap.c.orig linux-3.2.noarch/fs/nfs/idmap.c
--- linux-3.2.noarch/fs/nfs/idmap.c.orig 2012-02-07 07:12:52.585471833 -0500
+++ linux-3.2.noarch/fs/nfs/idmap.c 2012-03-14 13:08:37.462928792 -0400
@@ -360,7 +360,7 @@ struct idmap_hashent {
unsigned long ih_expires;
__u32 ih_id;
size_t ih_namelen;
- char ih_name[IDMAP_NAMESZ];
+ const char *ih_name;
};
struct idmap_hashtable {
@@ -424,11 +424,16 @@ void
nfs_idmap_delete(struct nfs_client *clp)
{
struct idmap *idmap = clp-cl_idmap;
+ int i;
if (!idmap)
return;
rpc_unlink(idmap-idmap_dentry);
clp-cl_idmap = NULL;
+ for (i = 0; i ARRAY_SIZE(idmap-idmap_user_hash.h_entries); i++)
+ kfree(idmap-idmap_user_hash.h_entries[i].ih_name);
+ for (i = 0; i ARRAY_SIZE(idmap-idmap_group_hash.h_entries); i++)
+ kfree(idmap-idmap_group_hash.h_entries[i].ih_name);
kfree(idmap);
}
@@ -491,9 +496,14 @@ static void
idmap_update_entry(struct idmap_hashent *he, const char *name,
size_t namelen, __u32 id)
{
+ char *str = kmalloc(namelen + 1, GFP_KERNEL);
+ if (str == NULL)
+ return;
+ kfree(he-ih_name);
he-ih_id = id;
- memcpy(he-ih_name, name, namelen);
- he-ih_name[namelen] = '\0';
+ memcpy(str, name, namelen);
+ str[namelen] = '\0';
+ he-ih_name = str;
he-ih_namelen = namelen;
he-ih_expires = jiffies + nfs_idmap_cache_timeout;
}
diff -up linux-3.2.noarch/fs/nfs/idmap.c.orig linux-3.2.noarch/fs/nfs/idmap.c
--- linux-3.2.noarch/fs/nfs/idmap.c.orig 2012-03-14 13:08:37.462928792 -0400
+++ linux-3.2.noarch/fs/nfs/idmap.c 2012-03-14 13:10:17.076030982 -0400
@@ -365,7 +365,7 @@ struct idmap_hashent {
struct idmap_hashtable {
__u8 h_type;
- struct idmap_hashent h_entries[IDMAP_HASH_SZ];
+ struct idmap_hashent *h_entries;
};
struct idmap {
@@ -420,20 +420,39 @@ nfs_idmap_new(struct nfs_client *clp)
return 0;
}
+static void
+idmap_alloc_hashtable(struct idmap_hashtable *h)
+{
+ if (h-h_entries != NULL)
+ return;
+ h-h_entries = kcalloc(IDMAP_HASH_SZ,
+ sizeof(*h-h_entries),
+ GFP_KERNEL);
+}
+
+static void
+idmap_free_hashtable(struct idmap_hashtable *h)
+{
+ int i;
+
+ if (h-h_entries == NULL)
+ return;
+ for (i = 0; i IDMAP_HASH_SZ; i++)
+ kfree(h-h_entries[i].ih_name);
+ kfree(h-h_entries);
+}
+
void
nfs_idmap_delete(struct nfs_client *clp)
{
struct idmap *idmap = clp-cl_idmap;
- int i;
if (!idmap)
return;
rpc_unlink(idmap-idmap_dentry);
clp-cl_idmap = NULL;
- for (i = 0; i ARRAY_SIZE(idmap-idmap_user_hash.h_entries); i++)
- kfree(idmap-idmap_user_hash.h_entries[i].ih_name);
- for (i = 0; i ARRAY_SIZE(idmap-idmap_group_hash.h_entries); i++)
- kfree(idmap-idmap_group_hash.h_entries[i].ih_name);
+ idmap_free_hashtable(idmap-idmap_user_hash);
+ idmap_free_hashtable(idmap-idmap_group_hash);
kfree(idmap);
}
@@ -443,6 +462,8 @@ nfs_idmap_delete(struct nfs_client *clp)
static inline struct idmap_hashent *
idmap_name_hash(struct idmap_hashtable* h, const char *name, size_t len)
{
+ if (h-h_entries == NULL)
+ return NULL;
return h-h_entries[fnvhash32(name, len) % IDMAP_HASH_SZ];
}
@@ -451,6 +472,8 @@ idmap_lookup_name(struct idmap_hashtable
{
struct idmap_hashent *he = idmap_name_hash(h, name, len);
+ if (he == NULL)
+ return NULL;
if (he-ih_namelen != len || memcmp(he-ih_name, name, len) != 0)
return NULL;
if (time_after(jiffies, he-ih_expires))
@@ -461,6 +484,8 @@ idmap_lookup_name(struct idmap_hashtable
static inline struct idmap_hashent *
idmap_id_hash(struct idmap_hashtable* h, __u32 id)
{
+ if (h-h_entries == NULL)
+ return NULL;
return h-h_entries[fnvhash32(id, sizeof(id)) % IDMAP_HASH_SZ];
}
@@ -468,6 +493,9 @@ static struct idmap_hashent *
idmap_lookup_id(struct idmap_hashtable *h, __u32 id)
{
struct idmap_hashent *he = idmap_id_hash(h, id);
+
+ if (he == NULL)
+ return NULL;
if (he-ih_id != id || he-ih_namelen == 0)
return NULL;
if (time_after(jiffies, he-ih_expires))
@@ -483,12 +511,14 @@ idmap_lookup_id(struct idmap_hashtable *
static inline struct idmap_hashent *
idmap_alloc_name(struct idmap_hashtable *h, char *name, size_t len)
{
+ idmap_alloc_hashtable(h);
return idmap_name_hash(h, name, len);
}
static inline struct idmap_hashent *
Bug#659111: [2.6.31 - 2.6.32 regression] Files on NFS4 become unwritable,, but OK after explicit stat
Hi, On Wed, 21 Mar 2012, Jonathan Nieder wrote: Rik Theys wrote: Can this commit be backported to the 3.2 kernel in sid? It applies and I have tested it in the past against the 3.2.4 kernel. I would also be very much interested to hear how well the following series against 2.6.32.y does: v2.6.33-rc1~54^2~7 rpc: add a new priority in RPC task, 2009-12-14 v2.6.33-rc1~54^2~5 nfs: make recovery state manager operations privileged, 2009-12-14 v3.3-rc1~116^2~1 NFSv4: Save the owner/group name string when doing open, 2012-01-07 I believe I compiled a kernel with those patches before and I believe they indeed fixed the bug. I didn't stress test other NFS functionality on that kernel to see if anything else broke. I believe a squeeze kernel security update is pending and I hope it will release before Friday noon. If that is the case I can push this update during my maintenance window this weekend. I will apply the patches on top of that security update and run in on one of my client machines. Or can I pull the squeeze-security tree from a public repo? Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664859: LVM segfaults on 3.3-rc6
Ben, On Wed, 21 Mar 2012, Ben Hutchings wrote: It's probably also worth testing 3.3 when it shows up (currently in NEW but likely to be available within 24 hours). I compiled 3.3 from kernel.org and it has the same problem. I'll try to configure a netconsole and/or serial console tomorrow. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659111: [2.6.31 - 2.6.32.y regression] Files on NFS4 become unwritable, but OK after explicit stat
Hi, On 02/09/2012 08:43 PM, Jonathan Nieder wrote: Would it be possible to backport the fix to the 2.6.32 kernel? Or is that too intrusive for a stable update? Here's a blind backport. Only compile-tested. I would be very surprised if it does not break anything, especially because I lazily pulled in patches instead of actually carefully backporting the code to the older kernel, so it is more invasive than necessary. But maybe it can serve as a starting point. I compiled the 2.6.32 kernel from squeeze with these patches on a sid box and it seems to fix the bug. I haven't fully testing any other NFS functionality now. How do you determine which other patches are required to backport a specific patch (in general)? Is there some magic git command for that? Regards, Rik -- Rik Theys Senior System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 B-3001 LEUVEN - HEVERLEE Tel.: +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659111: [2.6.31 - 2.6.32.y regression] Files on NFS4 become unwritable, but OK after explicit stat
Hi, Thanks Jonathan for looking into this bug, and the many other bugs filed against the Debian kernels. I did a git bisect between 2.6.31 and 2.6.32 and the first bad commit is... 80e52aced138bb41b045a8595a87510f27d8d8c5 is first bad commit commit 80e52aced138bb41b045a8595a87510f27d8d8c5 Author: Trond Myklebust trond.mykleb...@netapp.com Date: Sun Aug 9 15:06:19 2009 -0400 NFSv4: Don't do idmapper upcalls for asynchronous RPC calls We don't want to cause rpciod to hang... Signed-off-by: Trond Myklebust trond.mykleb...@netapp.com Wel duh. I could have guessed that if I had read through the changelog :-/. Anyway, I'm glad the git bisect thing worked. On 02/08/2012 07:31 PM, Jonathan Nieder wrote: Please try v3.3-rc1 or newer from upstream, or try the following patch against stable/linux-3.2.y. Instructions for building a custom kernel can be found at [1] or the corresponding file in the debian-kernel-handbook package. [1] http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-kernel-org-package Which 3.2.y kernel did you test? I will upgrade the lenny test system to sid and try building a kernel with this patch. Regards, Rik -- Rik Theys Senior System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 B-3001 LEUVEN - HEVERLEE Tel.: +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657078: linux-image-3.2.0-1-amd64: Support for new NFS id mapper
Hi Ben, On Tue, Jan 24, 2012 at 3:54 PM, Ben Hutchings b...@decadent.org.uk wrote: On Tue, 2012-01-24 at 08:01 +0100, Rik Theys wrote: The allocation failure has already been reported as #636306. I proposed a fix for that in http://bugs.debian.org/636306#35. The patch in #636306 has not been tested so far? I can not apply the patch on our production system, but I can try to see if I can reproduce the bug on a test machine. Has the patch been sent upstream? I think I may have given it a minimal test, but until someone else gives it a more serious test I won't send it upstream. The following Red Hat bug is about the same issue and a comment was added that Trond has proposed patches to resolve this. I have not yet compared the patches against yours (maybe they are the same). https://bugzilla.redhat.com/show_bug.cgi?id=730045 I haven't found the time to try and determine a procedure to reliably reproduce this problem to see if your and/or Trond's patches resolve this. On our production system I've also increased vm.min_free_kbytes to 512MB, which I believed would reduce the number of times we're seeing these allocation failures. But it doesn't seem to help all that much. The system has 72GB ram so I could increase it to 1GB or something. Would that make sense? I'm not sure that's going to make a difference - keeping lots of memory available does not guarantee that there will be any large physically contiguous blocks as the idmapper is demanding. You are right, it doesn't make a difference. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659111: [2.6.31 - 2.6.32.y regression] Files on NFS4 become unwritable, but OK after explicit stat
Hi, On 02/09/2012 10:09 AM, Rik Theys wrote: On 02/08/2012 07:31 PM, Jonathan Nieder wrote: Please try v3.3-rc1 or newer from upstream, or try the following patch against stable/linux-3.2.y. Instructions for building a custom kernel can be found at [1] or the corresponding file in the debian-kernel-handbook package. Which 3.2.y kernel did you test? I tested 3.2.4-1 from unstable. I will upgrade the lenny test system to sid and try building a kernel with this patch. I did apt-get install linux-source-3.2 (which downloaded 3.2.4-1 package) tar -xjf /usr/src/linux-source-3.2.tar.bz2 cd linux-source-3.2/ apt-get build-dep linux-image-`uname -r` (3.2.0-1-amd64) patch -p1 ../kernel-vim.patch cp /boot/config-3.2.0-1-amd64 .config make oldconfig make localmodconfig make -j4 deb-pkg and installed the resulting kernel. Thus far I have not been able to trigger the bug on this kernel. I will test some more, but I believe the patch you suggested indeed fixes this bug! Thanks! Regards, Rik -- Rik Theys Senior System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 B-3001 LEUVEN - HEVERLEE Tel.: +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659111: [2.6.31 - 2.6.32.y regression] Files on NFS4 become unwritable, but OK after explicit stat
Hi, On 02/09/2012 12:04 PM, Rik Theys wrote: On 02/08/2012 07:31 PM, Jonathan Nieder wrote: Please try v3.3-rc1 or newer from upstream, or try the following patch against stable/linux-3.2.y. Instructions for building a custom kernel can be found at [1] or the corresponding file in the debian-kernel-handbook package. The patch is commit 6926afd1925a54a13684ebe05987868890665e2b upstream. Would it be possible to backport the fix to the 2.6.32 kernel? Or is that too intrusive for a stable update? Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659111: linux-image-2.6.32-5-amd64: Files on NFS4 become unwritable, but OK after explicit stat
Package: linux-2.6 Version: 2.6.32-41 Severity: normal Hi, Our home directories here are mounted over NFS4. When I log in to machine A and run vim :q and then log into machine B and do: vim :q I get E137: Viminfo file is not writable: /users/system/rtheys/.viminfo Every invocation of 'vim and :q' will trigger this. Explicitely doing a stat of the file fixes this. Doing the vim :q thing on machine A while it has been triggered on B works: A never shows this message, while B continues to show it until the file is stat'ed. The file server is a RHEL 6.2 machine. I can trigger this bug on RHEL 6 clients, Debian 6 clients, Debian 6 with the 3.2 backport, but NOT on CentOS 5 clients. I no longer have Lenny machines so I can't verify it there. This seems to have been discussed here: http://comments.gmane.org/gmane.linux.nfs/37230 According to that thread, vim tries to do a stat on the ~/.viminfo file and receives incorrect st_uid/st_gid information? If it gets the wrong information I assume this is a kernel bug. Why is the information incorrect? The easiest way to reproduce this is with vim, but I've seen similar strange behaviour when modifying my ~/.ssh/authorized_keys file and then trying to ssh to other machines. They say they are ignoring the file because the permissions are not OK. This looks like the same bug to me, but is harder to reproduce here. Regards, Rik -- Package-specific info: ** Version: Linux version 2.6.32-5-amd64 (Debian 2.6.32-41) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Jan 16 16:22:28 UTC 2012 ** Command line: BOOT_IMAGE=/vmlinuz-2.6.32-5-amd64 root=/dev/mapper/vg00-root ro ipv6.disable=1 ** Not tainted ** Kernel log: [244111.447272] name_count maxed, losing inode data: dev=00:07, inode=8 [244111.447278] name_count maxed, losing inode data: dev=00:07, inode=20898841 [244111.466208] name_count maxed, losing inode data: dev=00:3b, inode=21757958 [257106.934243] IPMI message handler: BMC returned incorrect response, expected netfn 2d cmd 0, got netfn 2d cmd 35 [411592.612032] name_count maxed, losing inode data: dev=00:13, inode=724 [411592.612590] name_count maxed, losing inode data: dev=00:07, inode=8 [411592.612596] name_count maxed, losing inode data: dev=00:07, inode=36185654 [411592.612983] name_count maxed, losing inode data: dev=00:3d, inode=2 [430225.420674] snmpd invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0 [430225.420709] snmpd cpuset=/ mems_allowed=0 [430225.420735] Pid: 1967, comm: snmpd Not tainted 2.6.32-5-amd64 #1 [430225.420763] Call Trace: [430225.420792] [810b6418] ? oom_kill_process+0x7f/0x23f [430225.420821] [810b693c] ? __out_of_memory+0x12a/0x141 [430225.420849] [810b6a93] ? out_of_memory+0x140/0x172 [430225.420878] [810ba7f8] ? __alloc_pages_nodemask+0x4ec/0x5fc [430225.420910] [812fb9ea] ? io_schedule+0x93/0xb7 [430225.420939] [810bbd5d] ? __do_page_cache_readahead+0x9b/0x1b4 [430225.420970] [81065058] ? wake_bit_function+0x0/0x23 [430225.421005] [810bbe92] ? ra_submit+0x1c/0x20 [430225.421034] [810b4b65] ? filemap_fault+0x17d/0x2f6 [430225.421065] [810caada] ? __do_fault+0x54/0x3c3 [430225.421093] [810cce2e] ? handle_mm_fault+0x3b8/0x80f [430225.421123] [8106c59b] ? ktime_get_ts+0x68/0xb2 [430225.421151] [812ff166] ? do_page_fault+0x2e0/0x2fc [430225.421180] [812fd005] ? page_fault+0x25/0x30 [430225.421207] Mem-Info: [430225.421227] Node 0 DMA per-cpu: [430225.421252] CPU0: hi:0, btch: 1 usd: 0 [430225.421277] CPU1: hi:0, btch: 1 usd: 0 [430225.421303] CPU2: hi:0, btch: 1 usd: 0 [430225.421328] CPU3: hi:0, btch: 1 usd: 0 [430225.421353] Node 0 DMA32 per-cpu: [430225.421378] CPU0: hi: 186, btch: 31 usd: 0 [430225.421404] CPU1: hi: 186, btch: 31 usd: 0 [430225.421429] CPU2: hi: 186, btch: 31 usd: 0 [430225.421455] CPU3: hi: 186, btch: 31 usd: 0 [430225.421480] Node 0 Normal per-cpu: [430225.421504] CPU0: hi: 186, btch: 31 usd: 4 [430225.421530] CPU1: hi: 186, btch: 31 usd: 31 [430225.421556] CPU2: hi: 186, btch: 31 usd: 28 [430225.421581] CPU3: hi: 186, btch: 31 usd: 0 [430225.421610] active_anon:4620751 inactive_anon:456620 isolated_anon:0 [430225.421611] active_file:1426 inactive_file:1586 isolated_file:64 [430225.421612] unevictable:8 dirty:1493 writeback:202 unstable:0 [430225.421613] free:25435 slab_reclaimable:4029 slab_unreclaimable:4788 [430225.421614] mapped:1158 shmem:132 pagetables:15171 bounce:0 [430225.421745] Node 0 DMA free:15816kB min:12kB low:12kB high:16kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15288kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:16kB kernel_stack:0kB pagetables:0kB unstable:0kB
Bug#659111: List unaffected versions
notfound 659111 linux-2.6/2.6.26-27 notfound 659111 linux-2.6/2.6.29-5 notfound 659111 linux-2.6/2.6.31-2 found 659111 linux-2.6/2.6.32-8~bpo50+1 thanks Hi, It seems Lenny is not affected by this bug. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656899: Fwd: Bug#656899: mdadm: sending ioctl 1261 to a partition warnings in kernel log with kernel 3.2
[forgot to cc the bug report] -- Forwarded message -- Hi, On Mon, Jan 23, 2012 at 1:24 PM, Michael Tokarev m...@tls.msk.ru wrote: On 22.01.2012 22:42, Rik Theys wrote: The updates installed linux kernel 3.2, which I assume is triggering this. Recently there was a security issue with ioctls sent to partitions being forwarded to the whole disk. I assume the 3.2 kernel has a fix for this and this is causing the messages. This is correct, the message is recent addition in block/scsi_ioctl.c. 1261 appears to be BLKFLSBUF, -- I'm not sure why it is not allowed for a partition anymore, and why it gets routed to scsi_ioctl.c. Kernel: Linux 3.2.0-1-amd64 (SMP w/4 CPU cores) Which kernel package version is that, exactly? This is Linux version 3.2.0-1-amd64 (Debian 3.2.1-1) (b...@decadent.org.uk) (gcc version 4.6.2 (Debian 4.6.2-11) ) #1 SMP Thu Jan 19 09:46:46 UTC 2012 which is based on the upstream 3.2.1 kernel. Regards, Rik -- Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657078: linux-image-3.2.0-1-amd64: Support for new NFS id mapper
Package: linux-2.6 Version: 3.2.1-1 Severity: wishlist Hi, Please consider enabling the new NFS ID mapper functionality in the kernel: CONFIG_NFS_USE_NEW_IDMAPPER This will also need support in nfs-utils. Enabling this feature should prevent page allocation failure errors we frequently get on our file servers, as mentioned on https://bugzilla.redhat.com/show_bug.cgi?id=593035 Fedora also appears to be enabling this feature, and if things work out even RHEL 6.3+ might switch to this. Regards, Rik -- Package-specific info: ** Version: Linux version 3.2.0-1-amd64 (Debian 3.2.1-1) (b...@decadent.org.uk) (gcc version 4.6.2 (Debian 4.6.2-11) ) #1 SMP Thu Jan 19 09:46:46 UTC 2012 ** Command line: BOOT_IMAGE=/vmlinuz-3.2.0-1-amd64 root=/dev/mapper/vg_neptune-root ro quiet splash ** Not tainted ** Kernel log: [ 693.991811] pcieport :00:1c.3: restoring config space at offset 0x7 (was 0xf0, writing 0x20f0) [ 693.991819] pcieport :00:1c.3: restoring config space at offset 0x3 (was 0x81, writing 0x810010) [ 693.991825] pcieport :00:1c.3: restoring config space at offset 0x1 (was 0x10, writing 0x100407) [ 693.991868] pcieport :00:1c.4: restoring config space at offset 0xf (was 0x100, writing 0x10010b) [ 693.991880] pcieport :00:1c.4: restoring config space at offset 0x7 (was 0xf0, writing 0x20f0) [ 693.991889] pcieport :00:1c.4: restoring config space at offset 0x3 (was 0x81, writing 0x810010) [ 693.991895] pcieport :00:1c.4: restoring config space at offset 0x1 (was 0x16, writing 0x100407) [ 693.991938] pcieport :00:1c.7: restoring config space at offset 0xf (was 0x400, writing 0x10040a) [ 693.991955] pcieport :00:1c.7: restoring config space at offset 0x3 (was 0x81, writing 0x810010) [ 693.991961] pcieport :00:1c.7: restoring config space at offset 0x1 (was 0x10, writing 0x100407) [ 693.992002] ehci_hcd :00:1d.0: restoring config space at offset 0xf (was 0x100, writing 0x105) [ 693.992018] ehci_hcd :00:1d.0: restoring config space at offset 0x4 (was 0x0, writing 0xf7f07000) [ 693.992025] ehci_hcd :00:1d.0: restoring config space at offset 0x1 (was 0x290, writing 0x292) [ 693.994564] ehci_hcd :00:1d.0: wake-up capability disabled by ACPI [ 693.994570] ehci_hcd :00:1d.0: PME# disabled [ 693.994632] ahci :00:1f.2: restoring config space at offset 0x1 (was 0x2b7, writing 0x2b00407) [ 693.994707] r8169 :05:00.0: restoring config space at offset 0xf (was 0x1ff, writing 0x105) [ 693.994724] r8169 :05:00.0: restoring config space at offset 0x8 (was 0xc, writing 0xf11c) [ 693.994732] r8169 :05:00.0: restoring config space at offset 0x6 (was 0xc, writing 0xf110400c) [ 693.994740] r8169 :05:00.0: restoring config space at offset 0x4 (was 0x1, writing 0xe001) [ 693.994747] r8169 :05:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x10) [ 693.994755] r8169 :05:00.0: restoring config space at offset 0x1 (was 0x10, writing 0x100407) [ 693.994944] iwlwifi :09:00.0: restoring config space at offset 0xf (was 0x100, writing 0x10a) [ 693.994983] iwlwifi :09:00.0: restoring config space at offset 0x4 (was 0x4, writing 0xf7e4) [ 693.994992] iwlwifi :09:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x10) [ 693.995004] iwlwifi :09:00.0: restoring config space at offset 0x1 (was 0x10, writing 0x16) [ 693.995108] xhci_hcd :0b:00.0: restoring config space at offset 0xf (was 0x100, writing 0x10b) [ 693.995132] xhci_hcd :0b:00.0: restoring config space at offset 0x4 (was 0xf794, writing 0xf7d4) [ 693.995138] xhci_hcd :0b:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x10) [ 693.995146] xhci_hcd :0b:00.0: restoring config space at offset 0x1 (was 0x16, writing 0x100402) [ 693.995186] pcieport :00:1c.4: wake-up capability disabled by ACPI [ 693.995192] xhci_hcd :0b:00.0: PME# disabled [ 693.995240] PM: early resume of devices complete after 6.756 msecs [ 693.995337] i915 :00:02.0: setting latency timer to 64 [ 693.995359] ehci_hcd :00:1a.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 693.995371] ehci_hcd :00:1a.0: setting latency timer to 64 [ 693.995474] ehci_hcd :00:1d.0: PCI INT A - GSI 23 (level, low) - IRQ 23 [ 693.995482] ehci_hcd :00:1d.0: setting latency timer to 64 [ 693.995550] snd_hda_intel :00:1b.0: PCI INT A - GSI 22 (level, low) - IRQ 22 [ 693.99] xhci_hcd :0b:00.0: setting latency timer to 64 [ 693.995558] snd_hda_intel :00:1b.0: setting latency timer to 64 [ 693.997229] usb usb2: root hub lost power or was reset [ 693.997231] usb usb3: root hub lost power or was reset [ 693.997271] snd_hda_intel :00:1b.0: irq 54 for MSI/MSI-X [ 693.997341] ahci :00:1f.2: setting latency timer to 64 [ 693.997353] r8169 :05:00.0: wake-up capability disabled by ACPI [
Bug#657078: linux-image-3.2.0-1-amd64: Support for new NFS id mapper
Hi Ben, On Mon, Jan 23, 2012 at 11:28 PM, Ben Hutchings b...@decadent.org.uk wrote: On Mon, Jan 23, 2012 at 10:43:18PM +0100, Rik Theys wrote: Please consider enabling the new NFS ID mapper functionality in the kernel: CONFIG_NFS_USE_NEW_IDMAPPER Enabling this feature should prevent page allocation failure errors we frequently get on our file servers, as mentioned on https://bugzilla.redhat.com/show_bug.cgi?id=593035 The allocation failure has already been reported as #636306. I proposed a fix for that in http://bugs.debian.org/636306#35. I agree enabling the new feature for squeeze is not an option, but can it be considered for wheezy/sid? I assume the new feature is the Way Forward? The patch in #636306 has not been tested so far? I can not apply the patch on our production system, but I can try to see if I can reproduce the bug on a test machine. Has the patch been sent upstream? On our production system I've also increased vm.min_free_kbytes to 512MB, which I believed would reduce the number of times we're seeing these allocation failures. But it doesn't seem to help all that much. The system has 72GB ram so I could increase it to 1GB or something. Would that make sense? Regards, Rik -- Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656899: mdadm: sending ioctl 1261 to a partition warnings in kernel log with kernel 3.2
Package: mdadm Version: 3.2.3-2 Severity: normal Dear Maintainer, After upgrading my system to the latest sid packages I'm seeing the following errors in the kernel log: [4.334881] mdadm: sending ioctl 800c0910 to a partition! [4.334886] mdadm: sending ioctl 800c0910 to a partition! [4.334899] mdadm: sending ioctl 1261 to a partition! [4.334903] mdadm: sending ioctl 1261 to a partition! [4.335072] mdadm: sending ioctl 1261 to a partition! [4.335076] mdadm: sending ioctl 1261 to a partition! [4.356749] mdadm: sending ioctl 1261 to a partition! [4.356753] mdadm: sending ioctl 1261 to a partition! [4.371002] mdadm: sending ioctl 1261 to a partition! [4.371007] mdadm: sending ioctl 1261 to a partition! [ 362.584197] scsi_verify_blk_ioctl: 184 callbacks suppressed [ 362.584202] mdadm: sending ioctl 1261 to a partition! [ 362.584206] mdadm: sending ioctl 1261 to a partition! [ 363.761256] mdadm: sending ioctl 1261 to a partition! [ 363.761261] mdadm: sending ioctl 1261 to a partition! [ 363.840027] mdadm: sending ioctl 1261 to a partition! [ 363.840030] mdadm: sending ioctl 1261 to a partition! [ 363.911620] mdadm: sending ioctl 1261 to a partition! [ 363.911623] mdadm: sending ioctl 1261 to a partition! [ 363.989988] mdadm: sending ioctl 1261 to a partition! [ 363.989994] mdadm: sending ioctl 1261 to a partition! [ 368.892432] scsi_verify_blk_ioctl: 12 callbacks suppressed [ 368.892438] mdadm: sending ioctl 1261 to a partition! [ 368.892442] mdadm: sending ioctl 1261 to a partition! The upgrade included updates for mdadm and the linux kernel. The updates installed linux kernel 3.2, which I assume is triggering this. Recently there was a security issue with ioctls sent to partitions being forwarded to the whole disk. I assume the 3.2 kernel has a fix for this and this is causing the messages. So far the systems seems to work correctly. Regards, Rik -- Package-specific info: --- mdadm.conf DEVICE partitions CREATE owner=root group=disk mode=0660 auto=yes HOMEHOST system MAILADDR root ARRAY /dev/md0 UUID=b6ddc988:92dcc593:bfe78010:bc810f04 ARRAY /dev/md1 UUID=c614722b:a51ac2d5:bfe78010:bc810f04 ARRAY /dev/md2 UUID=f2991683:1ef2c973:852484a6:e390a598 --- /etc/default/mdadm INITRDSTART='all' AUTOSTART=true AUTOCHECK=true START_DAEMON=true DAEMON_OPTIONS=--syslog VERBOSE=false --- /proc/mdstat: Personalities : [raid0] [raid1] md2 : active raid0 sda4[0] sdb4[1] 275273600 blocks 64k chunks md1 : active raid1 sda3[0] sdb3[1] 629145536 blocks [2/2] [UU] md0 : active raid1 sda2[0] sdb2[1] 255936 blocks [2/2] [UU] unused devices: none --- /proc/partitions: major minor #blocks name 80 976762584 sda 81 209715200 sda1 82 256000 sda2 83 629145600 sda3 84 137636887 sda4 8 16 976762584 sdb 8 17 209715200 sdb1 8 18 256000 sdb2 8 19 629145600 sdb3 8 20 137636887 sdb4 1101048575 sr0 90 255936 md0 91 629145536 md1 92 275273600 md2 2530 20971520 dm-0 2531 275271680 dm-1 2532 599781376 dm-2 25338388608 dm-3 --- LVM physical volumes: PV VGFmt Attr PSize PFree /dev/md1 vg_saturn lvm2 a-- 600.00g0 /dev/md2 vg_stripe lvm2 a-- 262.52g0 --- mount output sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,relatime,size=4090688k,nr_inodes=1022672,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=819540k,mode=755) /dev/mapper/vg_saturn-root on / type ext4 (rw,relatime,errors=remount-ro,user_xattr,acl,barrier=1,data=ordered) tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,relatime,size=1639080k) /dev/md0 on /boot type ext4 (rw,relatime,user_xattr,acl,barrier=1,data=ordered) /dev/mapper/vg_saturn-home on /home type ext4 (rw,nosuid,nodev,relatime,user_xattr,barrier=1,data=ordered) /dev/sdb1 on /srv/backup type ext4 (rw,nosuid,nodev,relatime,user_xattr,acl,barrier=1,data=ordered) /dev/mapper/vg_stripe-stripe on /srv/scratch type ext4 (rw,nosuid,nodev,relatime,user_xattr,acl,barrier=1,data=ordered) rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime) fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) cgroup on /cgroups/cpu type cgroup (rw,relatime,cpu) cgroup on /cgroups/cpuacct type cgroup (rw,relatime,cpuacct) cgroup on /cgroups/devices type cgroup (rw,relatime,devices) --- initrd.img-3.2.0-1-amd64: 70418 blocks f4fbd9099399ab08ba9b9f6c71d77595 ./scripts/local-top/mdadm 95066bfacf17ac5347fc8b261f0cb8af ./etc/mdadm/mdadm.conf 5575ff907213f7fbd5090c1f2a31145e ./lib/modules/3.2.0-1-amd64/kernel/drivers/md/raid456.ko e858246bf89b55600dafca3f0d1ddb0e
Bug#655109: linux-2.6: BUG in videobuf-core triggered by mplayer on HVR-1300
Hi, On Sun, Jan 8, 2012 at 7:36 PM, Ben Hutchings b...@decadent.org.uk wrote: Jan 8 17:12:52 saturn kernel: [ 1623.655341] [ cut here ] Jan 8 17:12:52 saturn kernel: [ 1623.655363] kernel BUG at /home/blank/debian/kernel/release/linux-2.6/linux-2.6-3.1.6/debian/build/source_amd64_none/drivers/media/video/videobuf-core.c:300! The 'BUG' indicates that the video capture queue hasn't been initialised properly or has been corrupted. However, after looking at the driver for a while I just can't see how that can happen. I've experienced this bug with previous kernel versions as well but didn't report it before. Do you remember which was the first version where this bug appeared? I bought the card when squeeze was still testing (but frozen). I never got the card to work 100% and ran into different issues and kernel messages since 2.6.32. I'm not 100% sure the videobug-core bug was present in that kernel but I believe it was. It could have been an issue before 2.6.32 but I never tried an older kernel. Regards, Rik
Bug#655109: linux-2.6: BUG in videobuf-core triggered by mplayer on HVR-1300
[Reformatted as plain-text so it will get accepted by the vger.kernel.org list] On Mon, Jan 9, 2012 at 1:14 PM, Rik Theys rik.th...@gmail.com wrote: Hi, On Sun, Jan 8, 2012 at 7:36 PM, Ben Hutchings b...@decadent.org.uk wrote: Jan 8 17:12:52 saturn kernel: [ 1623.655341] [ cut here ] Jan 8 17:12:52 saturn kernel: [ 1623.655363] kernel BUG at /home/blank/debian/kernel/release/linux-2.6/linux-2.6-3.1.6/debian/build/source_amd64_none/drivers/media/video/videobuf-core.c:300! The 'BUG' indicates that the video capture queue hasn't been initialised properly or has been corrupted. However, after looking at the driver for a while I just can't see how that can happen. I've experienced this bug with previous kernel versions as well but didn't report it before. Do you remember which was the first version where this bug appeared? I bought the card when squeeze was still testing (but frozen). I never got the card to work 100% and ran into different issues and kernel messages since 2.6.32. I'm not 100% sure the videobug-core bug was present in that kernel but I believe it was. It could have been an issue before 2.6.32 but I never tried an older kernel. Regards, Rik -- Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653381: linux-image-2.6.32-5-amd64: page allocation failures with virtio-net driver
Package: linux-2.6 Version: 2.6.32-39 Severity: normal Hi, We have a virtual machine now running as a KVM virtual machine. Before, this virtual machine was running as a Xen domU. The VM has been given the same amount of memory and number of cpu's as it had with Xen. We configured the virtio-net driver for the network card on KVM. After a few days, we got the following errors: [144129.759313] swapper: page allocation failure. order:0, mode:0x20 [144129.763497] Pid: 0, comm: swapper Not tainted 2.6.32-5-amd64 #1 [144129.766429] Call Trace: [144129.767395] IRQ [810ba7b3] ? __alloc_pages_nodemask+0x59b/0x5fc [144129.771028] [812488f9] ? __alloc_skb+0x69/0x15a [144129.772814] [a00f3e48] ? try_fill_recv+0x8b/0x18b [virtio_net] [144129.774783] [a00f48b1] ? virtnet_poll+0x543/0x5ca [virtio_net] [144129.776712] [8124fcee] ? net_rx_action+0xae/0x1c9 [144129.778402] [81053d2b] ? __do_softirq+0xdd/0x1a6 [144129.780103] [a00f3153] ? skb_recv_done+0x28/0x34 [virtio_net] [144129.782025] [81011cac] ? call_softirq+0x1c/0x30 [144129.783263] [8101322b] ? do_softirq+0x3f/0x7c [144129.784341] [81053b9b] ? irq_exit+0x36/0x76 [144129.785379] [81012922] ? do_IRQ+0xa0/0xb6 [144129.786384] [810114d3] ? ret_from_intr+0x0/0x11 [144129.787463] EOI [8102c584] ? native_safe_halt+0x2/0x3 [144129.788718] [81017201] ? default_idle+0x34/0x51 [144129.789835] [8100fe97] ? cpu_idle+0xa2/0xda [144129.791406] [814f3140] ? early_idt_handler+0x0/0x71 [144129.793105] [814f3cdd] ? start_kernel+0x3dc/0x3e8 [144129.794156] [814f33b7] ? x86_64_start_kernel+0xf9/0x106 [144129.795274] Mem-Info: [144129.795859] Node 0 DMA per-cpu: [144129.796602] CPU0: hi:0, btch: 1 usd: 0 [144129.797524] CPU1: hi:0, btch: 1 usd: 0 [144129.799074] Node 0 DMA32 per-cpu: [144129.800408] CPU0: hi: 186, btch: 31 usd: 179 [144129.801861] CPU1: hi: 186, btch: 31 usd: 0 [144129.803042] active_anon:64487 inactive_anon:23386 isolated_anon:0 [144129.803043] active_file:153783 inactive_file:234184 isolated_file:0 [144129.803044] unevictable:24 dirty:15979 writeback:0 unstable:0 [144129.803045] free:2680 slab_reclaimable:26874 slab_unreclaimable:2397 [144129.803046] mapped:11137 shmem:6661 pagetables:1456 bounce:0 [144129.809548] Node 0 DMA free:8016kB min:40kB low:48kB high:60kB active_anon:0kB inactive_anon:0kB active_file:7424kB inactive_file:416kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15352kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:24kB slab_unreclaimable:20kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no [144129.820469] lowmem_reserve[]: 0 2004 2004 2004 [144129.82] Node 0 DMA32 free:6920kB min:5704kB low:7128kB high:8556kB active_anon:257952kB inactive_anon:93540kB active_file:613916kB inactive_file:926392kB unevictable:96kB isolated(anon):0kB isolated(file):0kB present:2052308kB mlocked:96kB dirty:63844kB writeback:44kB mapped:44548kB shmem:26644kB slab_reclaimable:107064kB slab_unreclaimable:9640kB kernel_stack:1424kB pagetables:5824kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no [144129.835406] lowmem_reserve[]: 0 0 0 0 [144129.836427] Node 0 DMA: 2*4kB 3*8kB 2*16kB 1*32kB 2*64kB 3*128kB 3*256kB 3*512kB 3*1024kB 1*2048kB 0*4096kB = 8032kB [144129.839727] Node 0 DMA32: 142*4kB 132*8kB 29*16kB 19*32kB 8*64kB 7*128kB 3*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 6920kB [144129.844512] 394354 total pagecache pages [144129.845858] 398 pages in swap cache [144129.847195] Swap cache stats: add 3826, delete 3428, find 139/193 [144129.849851] Free swap = 3890228kB [144129.851570] Total swap = 3903480kB [144129.863549] 524285 pages RAM [144129.865144] 8937 pages reserved [144129.866586] 93937 pages shared [144129.868061] 431928 pages non-shared [144131.098419] swapper: page allocation failure. order:0, mode:0x20 [144131.102702] Pid: 0, comm: swapper Not tainted 2.6.32-5-amd64 #1 [144131.104570] Call Trace: [144131.105813] IRQ [810ba7b3] ? __alloc_pages_nodemask+0x59b/0x5fc [144131.108489] [812488f9] ? __alloc_skb+0x69/0x15a [144131.111075] [a00f3e48] ? try_fill_recv+0x8b/0x18b [virtio_net] [144131.113546] [a00f48b1] ? virtnet_poll+0x543/0x5ca [virtio_net] [144131.115731] [8124fcee] ? net_rx_action+0xae/0x1c9 [144131.117603] [81053d2b] ? __do_softirq+0xdd/0x1a6 [144131.119628] [a00f3153] ? skb_recv_done+0x28/0x34 [virtio_net] [144131.122428] [81011cac] ? call_softirq+0x1c/0x30 [144131.124904] [8101322b] ? do_softirq+0x3f/0x7c [144131.126660] [81053b9b] ? irq_exit+0x36/0x76 [144131.128446] [81012922] ? do_IRQ+0xa0/0xb6 [144131.130898] [810114d3] ? ret_from_intr+0x0/0x11 [144131.132971] EOI
Bug#568557: keyboard and mouse lockup, system is still running (asus_atk0110?)
Hi Jonathan, On Fri, 2 Dec 2011, Jonathan Nieder wrote: Thanks, Rik! It would also be useful to know the newest kernel you've experienced this problem on, so we can rule out it having silently gone away (though I don't think that's likely). cteg, Rik, what kernel are you using these days? I'm now running unstable and the latest kernel from unstable on that machine. I've never had this issue after switching to a USB keyboard and mouse. When I find the time, I'll try a PS/2 keyboard (if I can still find one) on the system again and see if it still locks up. Now I've made a quick web search, and learned a little more. If the kernel you currently use is affected, could you try the following and report back? http://thread.gmane.org/gmane.linux.drivers.sensors/24194/focus=26426 And were you able to try the DSDT changes Luca suggested? (If your BIOS is different from Javier's, I can help out with this.) Haven't tried this. If I still experience lockups I can give this a try. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636864: Placing a symlink in the sendsigs.omit.d directory fixes this
Hi,
This can be fixed (worked around) by letting the start/stop script
create/remove a symlink to the pid file in /lib/init/rw/sendsigs.omit.d
(for squeeze) that points to the PID file.
Sendsigs will no longer send TERM and KILL signals to the daemon then.
For testing the sendsigs.omit.d is probably under /run somewhere now.
Patch for squeeze in in attach. For testing and unstable, the
sendsigs.omit.d is now in /run: /run/sendsigs.omit.d
Regards,
Rik
--- openvpn.orig 2011-11-17 13:04:48.889161154 +0100
+++ openvpn 2011-11-17 13:06:40.197161202 +0100
@@ -63,10 +63,13 @@
--exec $DAEMON -- $OPTARGS --writepid /var/run/openvpn.$NAME.pid \
$DAEMONARG $STATUSARG --cd $CONFIG_DIR \
--config $CONFIG_DIR/$NAME.conf || STATUS=1
+
+ln -s /var/run/openvpn.$NAME.pid /lib/init/rw/sendsigs.omit.d/openvpn.$NAME.pid
}
stop_vpn () {
kill `cat $PIDFILE` || true
rm -f $PIDFILE
+ rm -f /lib/init/rw/sendsigs.omit.d/openvpn.$NAME.pid
rm -f /var/run/openvpn.$NAME.status 2 /dev/null
}
