Bug#1055694: initramfs-tools: After updating coreutils cp: not replacing in console when running update-initramfs

[Sven Joachim]

On 2023-11-11 01:32 +0100, Thorsten Glaser wrote:

> On Fri, 10 Nov 2023, Sven Joachim wrote:
>
>>|   'cp -n' and 'mv -n' now exit with nonzero status if they skip their
>>|   action because the destination exists, and likewise for 'cp -i',
>
> Ouch! Nonzero? That’s harsh, and bad as it’s impossible to distinguish
> between error and declining to copy/move.
>
> There is a good example in diff(1) for how to handle this better:
> use distinct errorlevels for each case.
>
> Michael, could you perhaps throw that upstream?

There is already an upstream bug report for this, see
https://debbugs.gnu.org/62572.

Cheers,
   Sven

Bug#1055694: initramfs-tools: After updating coreutils cp: not replacing in console when running update-initramfs

[Sven Joachim]

Control: reassign -1 klibc-utils
Control: affects -1 initramfs-tools

On 2023-11-10 19:17 +1100, Konomi wrote:

> Package: initramfs-tools
> Version: 0.142
> Severity: normal
> X-Debbugs-Cc: konomikit...@gmail.com
>
> Dear Maintainer,
>
> After updating coreutils from 9.1-1 to 9.4-1+b1 the following lines appear 
> when
> running update-initramfs -u:
>
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/cat'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/cpio'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/dd'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/dmesg'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/false'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/gunzip'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/kill'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/ln'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/ls'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/mkdir'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/mkfifo'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/mknod'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/mount'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/mv'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/nuke'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/readlink'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/resume'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/sh'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/sleep'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/sync'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/true'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/umount'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/uname'

FWIW, this has been triggered by the following changes in coreutils:

,
| * Noteworthy changes in release 9.3 (2023-04-18) [stable]
|
| ** Changes in behavior
|
|   'cp -n' and 'mv -n' now issue an error diagnostic if skipping a file,
|   to correspond with -n inducing a nonzero exit status as of coreutils 9.2.
|
| * Noteworthy changes in release 9.2 (2023-03-20) [stable]
|
| ** Changes in behavior
|
|   'cp -n' and 'mv -n' now exit with nonzero status if they skip their
|   action because the destination exists, and likewise for 'cp -i',
|   'ln -i', and 'mv -i' when the user declines.  (POSIX specifies this
|   for 'cp -i' and 'mv -i'.)
`

I looked for 'cp -n' in the initramfs-tools source and could not find
it.  It turns out that the actual culprit is the file
/usr/share/initramfs-tools/hooks/klibc-utils which uses the -n option,
apparently with good reason, namely not to overwrite files from busybox.

> The lines seem to be a cosmetic issue only, but I cannot be entirely sure.

There do not seem to be any ill effects beside the warnings.

Cheers,
   Sven

Bug#1051577: iproute2: obsolete conffiles

[Sven Joachim]

Control: found -1 6.5.0-2

On 2023-09-10 00:55 +0200, gregor herrmann wrote:

> Package: iproute2
> Version: 6.5.0-1
> Severity: normal
>
> After upgrading to 6.5.0-1 adequate shows:
>
> adequate found packaging bugs
> -
>
> iproute2: obsolete-conffile /etc/iproute2/rt_tables.d/README
> iproute2: obsolete-conffile /etc/iproute2/rt_protos.d/README
> iproute2: obsolete-conffile /etc/iproute2/rt_protos
> iproute2: obsolete-conffile /etc/iproute2/rt_dsfield
> iproute2: obsolete-conffile /etc/iproute2/nl_protos
> iproute2: obsolete-conffile /etc/iproute2/ematch_map
> iproute2: obsolete-conffile /etc/iproute2/bpf_pinning

There are a few more leftovers still present in 6.5.0-2:

,
| $ adequate iproute2
| iproute2: obsolete-conffile /etc/iproute2/group
| iproute2: obsolete-conffile /etc/iproute2/rt_realms
| iproute2: obsolete-conffile /etc/iproute2/rt_scopes
| iproute2: obsolete-conffile /etc/iproute2/rt_tables
`

There are also the directories /etc/iproute2/rt_protos.d,
/etc/iproute2/rt_tables.d and /etc/iproute2 which are no longer shipped
in the package.  Unfortunately dpkg-maintscript-helper does not clean
those up automatically (see #584185).

Cheers,
   Sven

Bug#1041147: nfs-kernel-server: fsidd creates /fsid.sock

[Sven Joachim]

On 2023-07-15 08:23 +0200, Sven Joachim wrote:

> Package: nfs-kernel-server
> Version: 1:2.6.3-1
>
> On my system I found a top level socket /fsid.sock which is created by
> /lib/systemd/system/fsidd.service.  This is obviously not the right
> place for the socket, it should be put under /run.
>
> In the upstream git repository I have found a patch[1] which I will try
> and report back, if nobody beats me to it.
>
> 1. 
> http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=e00ab3c0616fe6d83ab0710d9e7d989c299088f7

Adding that patch to the series file worked well for me, I am attaching
it for your convenience.  However, the now unused socket /fsid.sock
remained on the system, so it should be cleaned up by the postinst
script.

From e00ab3c0616fe6d83ab0710d9e7d989c299088f7 Mon Sep 17 00:00:00 2001
From: NeilBrown 
Date: Thu, 11 May 2023 14:26:47 -0400
Subject: [PATCH] fsidd: provide better default socket name.

Having the default socket name be in the current directory is a poor
choice for a daemon that is expected to run as root.

It is also likely better to use an "abstract" socket name.  abstract
names do not exist in the filesystem namespace and are local to a
network namespace.  Using an abstract name ensures that the nfsd,
mountd, and fsidd are all in the same network namespace.

This patch:
 - uses a single #define for the default socket name, rather than 2;
 - allows the socket name to start with '@' which is interpreted to
   be a request to use the abstract name space (systemd uses the same
   convention).
 - changes the default to "@/run/fsid.sock".  I don't know of a formal
   standard for choosing names in the abstract name space, the defacto
   standard (seen in "ss -xa|grep @") is to use a name similar to what
   might be used in the filesystem.

Acked-by: Richard Weinberger 
Signed-off-by: NeilBrown 
Signed-off-by: Steve Dickson 
---
 support/reexport/fsidd.c| 10 ++
 support/reexport/reexport.c |  3 +++
 support/reexport/reexport.h |  2 +-
 3 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/support/reexport/fsidd.c b/support/reexport/fsidd.c
index 3fef1ef3..37649d06 100644
--- a/support/reexport/fsidd.c
+++ b/support/reexport/fsidd.c
@@ -18,11 +18,10 @@

 #include "conffile.h"
 #include "reexport_backend.h"
+#include "reexport.h"
 #include "xcommon.h"
 #include "xlog.h"

-#define FSID_SOCKET_NAME "fsid.sock"
-
 static struct event_base *evbase;
 static struct reexpdb_backend_plugin *dbbackend = _plug_ops;

@@ -167,11 +166,14 @@ int main(void)

 	sock_file = conf_get_str_with_def("reexport", "fsidd_socket", FSID_SOCKET_NAME);

-	unlink(sock_file);
-
 	memset(, 0, sizeof(struct sockaddr_un));
 	addr.sun_family = AF_UNIX;
 	strncpy(addr.sun_path, sock_file, sizeof(addr.sun_path) - 1);
+	if (addr.sun_path[0] == '@')
+		/* "abstract" socket namespace */
+		addr.sun_path[0] = 0;
+	else
+		unlink(sock_file);

 	srv = socket(AF_UNIX, SOCK_SEQPACKET | SOCK_NONBLOCK, 0);
 	if (srv == -1) {
diff --git a/support/reexport/reexport.c b/support/reexport/reexport.c
index eddc9bf4..d597a2f7 100644
--- a/support/reexport/reexport.c
+++ b/support/reexport/reexport.c
@@ -38,6 +38,9 @@ static bool connect_fsid_service(void)
 	memset(, 0, sizeof(struct sockaddr_un));
 	addr.sun_family = AF_UNIX;
 	strncpy(addr.sun_path, sock_file, sizeof(addr.sun_path) - 1);
+	if (addr.sun_path[0] == '@')
+		/* "abstract" socket namespace */
+		addr.sun_path[0] = 0;

 	s = socket(AF_UNIX, SOCK_SEQPACKET, 0);
 	if (s == -1) {
diff --git a/support/reexport/reexport.h b/support/reexport/reexport.h
index 3bed03a9..856c3085 100644
--- a/support/reexport/reexport.h
+++ b/support/reexport/reexport.h
@@ -13,6 +13,6 @@ int reexpdb_fsidnum_by_path(char *path, uint32_t *fsidnum, int may_create);
 int reexpdb_apply_reexport_settings(struct exportent *ep, char *flname, int flline);
 void reexpdb_uncover_subvolume(uint32_t fsidnum);

-#define FSID_SOCKET_NAME "fsid.sock"
+#define FSID_SOCKET_NAME "@/run/fsid.sock"

 #endif /* REEXPORT_H */
--
2.40.1

Bug#1041147: nfs-kernel-server: fsidd creates /fsid.sock

[Sven Joachim]

Package: nfs-kernel-server
Version: 1:2.6.3-1

On my system I found a top level socket /fsid.sock which is created by
/lib/systemd/system/fsidd.service.  This is obviously not the right
place for the socket, it should be put under /run.

In the upstream git repository I have found a patch[1] which I will try
and report back, if nobody beats me to it.

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


1. 
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=e00ab3c0616fe6d83ab0710d9e7d989c299088f7

Bug#1014319: depmod: WARNING: could not open modules.builtin.modinfo at /var/tmp/mkinitramfs_vBlw4a/lib/modules/5.18.0-2-amd64: No such file or directory

[Sven Joachim]

Control: tags -1 + patch

On 2022-07-04 10:00 +0200, Vincent Lefevre wrote:

> On 2022-07-04 15:01:13 +1000, Konomi Kitten wrote:
>> When update-initramfs runs I receive the following message:
>>
>> depmod: WARNING: could not open modules.builtin.modinfo at
>> /var/tmp/mkinitramfs_vBlw4a/lib/modules/5.18.0-2-amd64: No such file or
>> directory
>
> I also got such a warning on two of my machines. It seems to
> be triggered when upgrading kmod (which provides depmod) to
> 30+20220630-1.

Same here.  The following patch takes care of the problem.

Cheers,
Sven

From e41183925d51bd97cd0b85660b6abdaad0fd5b69 Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Mon, 4 Jul 2022 08:35:46 +0200
Subject: [PATCH] Copy modules.builtin.modinfo into initramfs

As of kmod version 30, depmod issues a warning if this file is
missing.

Closes: #1014319
---
 mkinitramfs | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mkinitramfs b/mkinitramfs
index a4d16f6..df1b940 100755
--- a/mkinitramfs
+++ b/mkinitramfs
@@ -316,10 +316,10 @@ for d in conf/conf.d etc run scripts ${MODULESDIR}; do
 	mkdir -p "${DESTDIR}/${d}"
 done

-# Copy in modules.builtin and modules.order (not generated by depmod)
+# Copy in modules.builtin, modules.builtin.modinfo and modules.order (not generated by depmod)
 # and modules.builtin.bin (generated by depmod, but too late to avoid
 # error messages as in #948257)
-for x in modules.builtin modules.builtin.bin modules.order; do
+for x in modules.builtin modules.builtin.bin modules.builtin.modinfo modules.order; do
 	if [ -f "${MODULESDIR}/${x}" ]; then
 		cp -p "${MODULESDIR}/${x}" "${DESTDIR}${MODULESDIR}/${x}"
 	fi
--
2.36.1

Bug#990662: nouveau 0000:01:00.0: firmware: failed to load nouveau/nvd9_fuc084 (-2)

[Sven Joachim]

On 2021-07-04 09:36 +0200, Mathieu Malaterre wrote:

> Package: firmware-misc-nonfree
> Version: 20210315-2~bpo10+1
>
> It would be super nice to distribute the nividia/nouveau firmware in
> firmware-misc-nonfree.

There are two classes of firmware for NVidia cards: official ones from
NVidia for newer cards which is already included in
firmware-misc-nonfree and placed under /lib/fimware/nvidia, and firmware
for older cards which is not distributable but needs to be extracted
from the non-free driver and is put under /lib/firmware/nouveau.  This
firmware can be useful for video decoding, but is not necessary for other
operations.

https://nouveau.freedesktop.org/VideoAcceleration.html

> Right now symptoms are:
> [127020.582478] nouveau :01:00.0: firmware: failed to load
> nouveau/nvd9_fuc084 (-2)
> [127020.582481] firmware_class: See https://wiki.debian.org/Firmware
> for information about missing firmware
> [127020.582482] nouveau :01:00.0: Direct firmware load for
> nouveau/nvd9_fuc084 failed with error -2
> [127020.582487] nouveau :01:00.0: firmware: failed to load
> nouveau/nvd9_fuc084d (-2)
> [127020.582488] nouveau :01:00.0: Direct firmware load for
> nouveau/nvd9_fuc084d failed with error -2
> [127020.582489] nouveau :01:00.0: msvld: unable to load firmware data
> [127020.582491] nouveau :01:00.0: msvld: init failed, -19
> [127064.484342] nouveau :01:00.0: firmware: failed to load
> nouveau/nvd9_fuc084 (-2)
> [127064.484353] nouveau :01:00.0: Direct firmware load for
> nouveau/nvd9_fuc084 failed with error -2
> [127064.484375] nouveau :01:00.0: firmware: failed to load
> nouveau/nvd9_fuc084d (-2)
> [127064.484380] nouveau :01:00.0: Direct firmware load for
> nouveau/nvd9_fuc084d failed with error -2
> [127064.484384] nouveau :01:00.0: msvld: unable to load firmware data
> [127064.484389] nouveau :01:00.0: msvld: init failed, -19
>
> Reference:
>
> https://build.opensuse.org/package/view_file/hardware/nvidia-firmware-installer/nvidia-firmware-installer.spec?expand=1
> https://raw.githubusercontent.com/envytools/firmware/master/extract_firmware.py

Since the firmware is not distributable as-is, it cannot be put into
firmware-misc-nonfree (or any other package).  What could be done is to
package an installer in contrib.  Would you like to do that?

Cheers,
   Sven

Bug#953522: reassign 953522 to firmware-realtek

[Sven Joachim]

Control: tags -1 + fixed-upstream

On 2020-03-10 18:10 +, Ben Hutchings wrote:

> reassign 953522 firmware-realtek
> thanks

For the record, the file has been added to firmware-linux.git in
September[1].  I think upgrading firmware-nonfree to 20200122 would be
rather useful.

Cheers,
   Sven


1. 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/rtl_nic/rtl8125a-3.fw?h=20200122=f667c005600bd4fe24a0a439b7a3f3eadcce753a

Bug#928672: firmware-misc-nonfree: please include GV100 signed firmware

[Sven Joachim]

On 2019-07-29 18:26 +0300, m712 wrote:

> Looks like you missed one. Installing firmware-misc-nonfree-20190717-1 
> reports one missing file:
>
> W: Possible missing firmware /lib/firmware/nvidia/gv100/acr/ucode_load.bin 
> for module nouveau
>
> Please fix it. Thanks.

I have added a merge request at
https://salsa.debian.org/kernel-team/firmware-nonfree/merge_requests/8.

Cheers,
   Sven

Bug#932854: initramfs-tools-core: Please depend on logsave

[Sven Joachim]

Control: severity -1 normal

On 2019-07-25 12:37 -0400, rharw...@club.cc.cmu.edu wrote:

> Package: initramfs-tools
> Version: 0.133
> Followup-For: Bug #932854
> Control: severity -1 critical
>
> Raising severity of this since it renders the machine unbootable.

The critical part is that e2fsprogs 1.45.3-1 did not depend on logsave
after splitting that into its own package, see #932861.

Cheers,
   Sven

Bug#932854: Missing dependency for initramfs-tools-core

[Sven Joachim]

Control: retitle -1 initramfs-tools-core: Please depend on logsave

On 2019-07-23 22:37 +, Colin Booth wrote:

> Package: initramfs-tools-core
> Version: 0.133
>
> The functions file shipped with initramfs-tools-core version 0.133 and
> earlier contains a call to logsave(8) in the _checkfs_once() function.
> The latest version of e2fsprogs (1.45.3-1) has removed logsave and it is
> now shipped in a separate package. This causes a surprise drop into an
> initramfs shell as the fsck line fails.

In order not to instantly break initramfs-tools and thus booting the
system, the new e2fsprogs package should have depended on logsave rather
than just suggesting it.  See #932861 and friends.

> Please add a Depends: logsave in the next shipping version of
> initramfs-tools-core or update the _checkfs_once function to not require
> that program.

ITSM that depending on logsave | e2fsprogs (<< 1.45.3) is sufficient, and
probably also necessary.

Cheers,
   Sven

Bug#932881: add dependency on logsave

[Sven Joachim]

Control: reassign -1 e2fsprogs 1.45.3-1
Control: forcemerge 932861 -1

On 2019-07-24 08:32 +0300, Aleksi Suhonen wrote:

> Package: initramfs-tools
> Severity: grave
> Version: 0.133
>
> After upgrading e2fsprogs to 1.45.3-1, computer fails to boot because
> rootfs fails to fsck. And fsck fails because binary for logsave is
> missing. Or in fact, fsck doesn't fail, but the init script reports it
> did, because it cannot tell the difference...
>
> This is because logsave has just been split into its own package
> "logsave." The initrd builder scripts should depend on it, except it
> seems that not all hardware platforms have the logsave package yet...

It is e2fsprogs which needs to depend on logsave for the time being in
order not to break its reverse dependencies.  As for initramfs-tools,
initramfs-tools-core should probably depend on
logsave | e2fsprogs (<< 1.45.3), that is tracked in #932854.

Cheers,
   Sven

Bug#928672: firmware-misc-nonfree: please include GV100 signed firmware

[Sven Joachim]

Package: firmware-misc-nonfree
Version: 20190502-1

For a while I have been seeing warnings from update-initramfs:

,
| # update-initramfs -u -k 4.19.0-5-amd64
| update-initramfs: Generating /boot/initrd.img-4.19.0-5-amd64
| W: Possible missing firmware /lib/firmware/nvidia/gv100/sec2/sig.bin for 
module nouveau
| W: Possible missing firmware /lib/firmware/nvidia/gv100/sec2/image.bin for 
module nouveau
| W: Possible missing firmware /lib/firmware/nvidia/gv100/sec2/desc.bin for 
module nouveau
| W: Possible missing firmware /lib/firmware/nvidia/gv100/nvdec/scrubber.bin 
for module nouveau
| W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/sw_method_init.bin 
for module nouveau
| W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/sw_bundle_init.bin 
for module nouveau
| W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/sw_nonctx.bin for 
module nouveau
| W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/sw_ctx.bin for 
module nouveau
| W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/gpccs_sig.bin for 
module nouveau
| W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/gpccs_data.bin for 
module nouveau
| W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/gpccs_inst.bin for 
module nouveau
| W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/gpccs_bl.bin for 
module nouveau
| W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/fecs_sig.bin for 
module nouveau
| W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/fecs_data.bin for 
module nouveau
| W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/fecs_inst.bin for 
module nouveau
| W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/fecs_bl.bin for 
module nouveau
| W: Possible missing firmware /lib/firmware/nvidia/gv100/acr/ucode_unload.bin 
for module nouveau
| W: Possible missing firmware /lib/firmware/nvidia/gv100/acr/ucode_load.bin 
for module nouveau
| W: Possible missing firmware /lib/firmware/nvidia/gv100/acr/unload_bl.bin for 
module nouveau
| W: Possible missing firmware /lib/firmware/nvidia/gv100/acr/bl.bin for module 
nouveau
`

The files in question have been added to linux-firmware.git last year,
commit eb6419c26e ("nvidia: add GV100 signed firmware") [1].

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.1.0-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

firmware-misc-nonfree depends on no packages.

firmware-misc-nonfree recommends no packages.

Versions of packages firmware-misc-nonfree suggests:
ii  initramfs-tools  0.133

-- no debconf information


1. 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=eb6419c26ec2872abcff15c2a6dd7030493d03bc

Bug#911510: nfs-utils: scripts using rpcinfo don't find it

[Sven Joachim]

Control: severity -1 serious
Control: reassign -1 rpcbind 1.2.5-0.1
Control: retitle -1 rpcbind: changed location of rpcinfo breaks nfs-utils

Am 21.10.2018 um 09:54 schrieb Elimar Riesebieter:

> Source: nfs-utils
> Version: 1.3.4-2.2
> Severity: grave
> Tags: patch
> Justification: renders package unusable
>
>
> bug- and initscripts using rpcinfo are looking in $PREFIX/sbin.
> Since rpcbind installs rpcinfo in $PREFIX/bin we need to adjust the
> scripts as proposed in the attached patch.

It would also be necessary to add adjust the dependency on rpcbind to
(>= 1.2.5), since earlier versions of rpcbind installed rpcinfo in
/usr/sbin.  And rpcbind would need a versioned Breaks on
nfs-{common,kernel-server}.

> Or we need to change rpcbind to install rpcinfo in $PREFIX/sbin

That's where it was before the rpcbind NMUs.  Certainly /usr/bin is a
more logical place for rpcinfo; the reason why it was put into /usr/sbin
is that libc-bin versions before 2.16 used to ship /usr/bin/rpcinfo.
See also #707589 on that topic.

Cheers,
   Sven

Bug#904065: initramfs-tools: stderr reports "rmdir: failed to remove '/var/tmp/mkinitramfs_XXXXXX/var/cache/ldconfig': No such file or directory"

[Sven Joachim]

Control: severity -1 minor
Control: tags -1 + patch

On 2018-07-19 12:04 +0800, Boyuan Yang wrote:

> Package: initramfs-tools
> Severity: important
> Version: 0.131
>
> Dear initramfs-tools maintainers,
>
> I installed initramfs-tools 0.131 from 
> http://incoming.debian.org/debian-buildd and got the following error messages:
>
> ===
> 正在安装新版本配置文件 /etc/initramfs-tools/initramfs.conf ...
> 正在设置 initramfs-tools (0.131) ...
> update-initramfs: deferring update (trigger activated)
> 正在设置 firefox-l10n-zh-cn (61.0.1-1) ...
> 正在处理用于 initramfs-tools (0.131) 的触发器 ...
> update-initramfs: Generating /boot/initrd.img-4.17.0-1-amd64
> rmdir: 删除 '/var/tmp/mkinitramfs_wEihys/var/cache/ldconfig' 失败: 没有那个文件或目录
> ===
>
> A manual invocation of update-initramfs got the following output:
>
> ===
> % LC_ALL=C sudo update-initramfs -u 
> update-initramfs: Generating /boot/initrd.img-4.17.0-1-amd64
> rmdir: failed to remove '/var/tmp/mkinitramfs_G50d00/var/cache/ldconfig': No 
> such file or directory
> % echo $?
> 0
> 
>
> I'm not sure if it is a critical error or not. However, this problem needs to 
> be solved anyway.

Failing to remove a directory because it did not exist in the first
place is not a big deal, so this error message is just cosmetic.  Below
is a patch that fixes it.

>From ca5373c7fee4e6928e50699eeb9cb40e63018957 Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Thu, 19 Jul 2018 11:22:04 +0200
Subject: [PATCH] mkinitramfs: Don't try to remove a non-existent directory

The auxiliary ldconfig cache might not exist, in my tests there was
not even a var/ subdirectory in ${DESTDIR}.
---
 mkinitramfs | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/mkinitramfs b/mkinitramfs
index 89a61a3..58a9ff7 100755
--- a/mkinitramfs
+++ b/mkinitramfs
@@ -340,8 +340,10 @@ if ! ldconfig -r "$DESTDIR" ; then
 fi
 # The auxiliary cache is not reproducible and is always invalid at boot
 # (see #845034)
-rm -f "${DESTDIR}"/var/cache/ldconfig/aux-cache
-rmdir --ignore-fail-on-non-empty "${DESTDIR}"/var/cache/ldconfig
+if [ -d "${DESTDIR}"/var/cache/ldconfig ]; then
+	rm -f "${DESTDIR}"/var/cache/ldconfig/aux-cache
+	rmdir --ignore-fail-on-non-empty "${DESTDIR}"/var/cache/ldconfig
+fi
 
 # Apply DSDT to initramfs
 if [ -e "${CONFDIR}/DSDT.aml" ]; then
-- 
2.18.0

Bug#880660: xserver-xorg-video-nouveau: Crash when kernel tries to switch to frame buffer

[Sven Joachim]

Control: tags -1 + patch fixed-upstream

On 2018-01-09 20:48 +0100, Sven Joachim wrote:

> Looking again, I think this is
> https://bugs.freedesktop.org/show_bug.cgi?id=103421 which has a patch
> that works for at least two people, attached for convenience.  If you
> dare building your own kernel, you may want to try it out.
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c
> index a2978a37b4f3..700fc754f28a 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c
> @@ -174,6 +174,7 @@ gf119_sor = {
>   .links = gf119_sor_dp_links,
>   .power = g94_sor_dp_power,
>   .pattern = gf119_sor_dp_pattern,
> + .drive = gf119_sor_dp_drive,
>   .vcpi = gf119_sor_dp_vcpi,
>   .audio = gf119_sor_dp_audio,
>   .audio_sym = gf119_sor_dp_audio_sym,

This patch is now in Linus' tree[1].

Cheers,
   Sven


1. 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1b5c7ef3d0d0610bda9b63263f7c5b7178d11015

Bug#880660: xserver-xorg-video-nouveau: Crash when kernel tries to switch to frame buffer

[Sven Joachim]

On 2017-11-03 13:46 +0100, Christoph Pohl wrote:

> after upgrading to kernel 4.13, the nouveau kernel module crashes when
> the kernel tries to switch to frame buffer during boot. Under 4.12,
> where everything was working fine, this was the relevant output of
> dmesg:
>
> Nov  3 09:15:04 ws6779 kernel: [4.615541] nouveau :01:00.0: DRM: 
> allocated 1920x1200 fb: 0x6, bo 97aed7608800
> Nov  3 09:15:04 ws6779 kernel: [4.615989] fbcon: nouveaufb (fb0) is 
> primary device
> Nov  3 09:15:04 ws6779 kernel: [4.758665] Console: switching to colour 
> frame buffer device 240x75
> Nov  3 09:15:04 ws6779 kernel: [4.862120] nouveau :01:00.0: fb0: 
> nouveaufb frame buffer device
>
> Now, under 4.13, this happens and leaves the monitor without a signal,
> making the system unuseable:
>
> Nov  3 09:14:06 ws6779 kernel: [4.647634] nouveau :01:00.0: DRM: 
> allocated 1920x1200 fb: 0x6, bo 8c79da533000
> Nov  3 09:14:06 ws6779 kernel: [4.652071] fbcon: nouveaufb (fb0) is 
> primary device
> Nov  3 09:14:06 ws6779 kernel: [4.749172] BUG: unable to handle kernel 
> NULL pointer dereference at   (null)
> Nov  3 09:14:06 ws6779 kernel: [4.749173] IP:   (null)
> Nov  3 09:14:06 ws6779 kernel: [4.749174] PGD 0 
> Nov  3 09:14:06 ws6779 kernel: [4.749174] P4D 0 
> Nov  3 09:14:06 ws6779 kernel: [4.749174] 
> Nov  3 09:14:06 ws6779 kernel: [4.749175] Oops: 0010 [#1] SMP
> Nov  3 09:14:06 ws6779 kernel: [4.749176] Modules linked in: joydev 
> hid_generic usbhid hid binfmt_misc intel_uncore(+) hp_wmi sparse_keymap 
> rfkill wmi_bmof evdev intel_rapl_perf serio_raw pcspkr sg lpc_ich(+) mfd_core 
> snd_hda_intel(+) snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd 
> soundcore mei_me(+) mei battery i915(+) shpchp(+) tpm_infineon nouveau(+) 
> mxm_wmi wmi video button ttm drm_kms_helper drm i2c_algo_bit parport_pc ppdev 
> lp sunrpc parport ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 
> crc32c_generic fscrypto ecb sr_mod cdrom sd_mod crc32c_intel ahci libahci 
> aesni_intel aes_x86_64 crypto_simd cryptd glue_helper libata xhci_pci 
> ehci_pci e1000e xhci_hcd ehci_hcd psmouse scsi_mod i2c_i801 ptp usbcore 
> pps_core usb_common fan thermal
> Nov  3 09:14:06 ws6779 kernel: [4.749204] CPU: 4 PID: 199 Comm: 
> kworker/u16:4 Not tainted 4.13.0-1-amd64 #1 Debian 4.13.4-2
> Nov  3 09:14:06 ws6779 kernel: [4.749205] Hardware name: Hewlett-Packard 
> HP EliteDesk 800 G1 TWR/18E4, BIOS L01 v02.65 07/13/2015
> Nov  3 09:14:06 ws6779 kernel: [4.749241] Workqueue: nvkm-disp 
> gf119_disp_super [nouveau]
> Nov  3 09:14:06 ws6779 kernel: [4.749241] task: 8c79d753d040 
> task.stack: b4f2821c4000
> Nov  3 09:14:06 ws6779 kernel: [4.749242] RIP: 0010:  (null)
> Nov  3 09:14:06 ws6779 kernel: [4.749242] RSP: 0018:b4f2821c7c40 
> EFLAGS: 00010206
> Nov  3 09:14:06 ws6779 kernel: [4.749243] RAX: c081fec0 RBX: 
>  RCX: 0016
> Nov  3 09:14:06 ws6779 kernel: [4.749244] RDX:  RSI: 
>  RDI: 8c79dbe9a000
> Nov  3 09:14:06 ws6779 kernel: [4.749244] RBP:  R08: 
>  R09: 
> Nov  3 09:14:06 ws6779 kernel: [4.749244] R10: 1000 R11: 
> 10624dd3 R12: 
> Nov  3 09:14:06 ws6779 kernel: [4.749245] R13: b4f2821c7d6e R14: 
> b4f2821c7d60 R15: 8c79dce92c00
> Nov  3 09:14:06 ws6779 kernel: [4.749245] FS:  () 
> GS:8c79efb0() knlGS:
> Nov  3 09:14:06 ws6779 kernel: [4.749246] CS:  0010 DS:  ES:  
> CR0: 80050033
> Nov  3 09:14:06 ws6779 kernel: [4.749247] CR2:  CR3: 
> 000214009000 CR4: 001406e0
> Nov  3 09:14:06 ws6779 kernel: [4.749247] Call Trace:
> Nov  3 09:14:06 ws6779 kernel: [4.749272]  ? 
> nvkm_dp_train_drive+0x210/0x2f0 [nouveau]
> Nov  3 09:14:06 ws6779 kernel: [4.749294]  ? nvkm_dp_acquire+0x89c/0xca0 
> [nouveau]
> Nov  3 09:14:06 ws6779 kernel: [4.749317]  ? 
> nv50_disp_super_2_2+0x69/0x430 [nouveau]
> Nov  3 09:14:06 ws6779 kernel: [4.749337]  ? gf119_disp_super+0x1a5/0x2f0 
> [nouveau]
> Nov  3 09:14:06 ws6779 kernel: [4.749340]  ? process_one_work+0x181/0x370
> Nov  3 09:14:06 ws6779 kernel: [4.749341]  ? worker_thread+0x4d/0x3a0
> Nov  3 09:14:06 ws6779 kernel: [4.749342]  ? kthread+0xfc/0x130
> Nov  3 09:14:06 ws6779 kernel: [4.749343]  ? process_one_work+0x370/0x370
> Nov  3 09:14:06 ws6779 kernel: [4.749344]  ? 
> kthread_create_on_node+0x70/0x70
> Nov  3 09:14:06 ws6779 kernel: [4.749346]  ? ret_from_fork+0x25/0x30
> Nov  3 09:14:06 ws6779 kernel: [4.749346] Code:  Bad RIP value.
> Nov  3 09:14:06 ws6779 kernel: [4.749349] RIP:   (null) RSP: 
> b4f2821c7c40
> Nov  3 09:14:06 ws6779 kernel: [4.749349] CR2: 
> Nov  3 09:14:06 

Re: Bug#880660: xserver-xorg-video-nouveau: Crash when kernel tries to switch to frame buffer

[Sven Joachim]

Control: reassign -1 src:linux
Control: found -1 4.13.4-2

On 2017-11-03 13:46 +0100, Christoph Pohl wrote:

> Package: xserver-xorg-video-nouveau
> Version: 1:1.0.15-2
> Severity: important
>
> Dear Maintainer,
>
> after upgrading to kernel 4.13, the nouveau kernel module crashes when
> the kernel tries to switch to frame buffer during boot.

This is obviously a kernel problem and has nothing to do with
xserver-xorg-video-nouveau.

> Under 4.12,
> where everything was working fine, this was the relevant output of
> dmesg:
>
> Nov  3 09:15:04 ws6779 kernel: [4.615541] nouveau :01:00.0: DRM: 
> allocated 1920x1200 fb: 0x6, bo 97aed7608800
> Nov  3 09:15:04 ws6779 kernel: [4.615989] fbcon: nouveaufb (fb0) is 
> primary device
> Nov  3 09:15:04 ws6779 kernel: [4.758665] Console: switching to colour 
> frame buffer device 240x75
> Nov  3 09:15:04 ws6779 kernel: [4.862120] nouveau :01:00.0: fb0: 
> nouveaufb frame buffer device
>
> Now, under 4.13, this happens and leaves the monitor without a signal,
> making the system unuseable:
>
> Nov  3 09:14:06 ws6779 kernel: [4.647634] nouveau :01:00.0: DRM: 
> allocated 1920x1200 fb: 0x6, bo 8c79da533000
> Nov  3 09:14:06 ws6779 kernel: [4.652071] fbcon: nouveaufb (fb0) is 
> primary device
> Nov  3 09:14:06 ws6779 kernel: [4.749172] BUG: unable to handle kernel 
> NULL pointer dereference at   (null)
> Nov  3 09:14:06 ws6779 kernel: [4.749173] IP:   (null)
> Nov  3 09:14:06 ws6779 kernel: [4.749174] PGD 0 
> Nov  3 09:14:06 ws6779 kernel: [4.749174] P4D 0 
> Nov  3 09:14:06 ws6779 kernel: [4.749174] 
> Nov  3 09:14:06 ws6779 kernel: [4.749175] Oops: 0010 [#1] SMP
> Nov  3 09:14:06 ws6779 kernel: [4.749176] Modules linked in: joydev 
> hid_generic usbhid hid binfmt_misc intel_uncore(+) hp_wmi sparse_keymap 
> rfkill wmi_bmof evdev intel_rapl_perf serio_raw pcspkr sg lpc_ich(+) mfd_core 
> snd_hda_intel(+) snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd 
> soundcore mei_me(+) mei battery i915(+) shpchp(+) tpm_infineon nouveau(+) 
> mxm_wmi wmi video button ttm drm_kms_helper drm i2c_algo_bit parport_pc ppdev 
> lp sunrpc parport ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 
> crc32c_generic fscrypto ecb sr_mod cdrom sd_mod crc32c_intel ahci libahci 
> aesni_intel aes_x86_64 crypto_simd cryptd glue_helper libata xhci_pci 
> ehci_pci e1000e xhci_hcd ehci_hcd psmouse scsi_mod i2c_i801 ptp usbcore 
> pps_core usb_common fan thermal
> Nov  3 09:14:06 ws6779 kernel: [4.749204] CPU: 4 PID: 199 Comm: 
> kworker/u16:4 Not tainted 4.13.0-1-amd64 #1 Debian 4.13.4-2
> Nov  3 09:14:06 ws6779 kernel: [4.749205] Hardware name: Hewlett-Packard 
> HP EliteDesk 800 G1 TWR/18E4, BIOS L01 v02.65 07/13/2015
> Nov  3 09:14:06 ws6779 kernel: [4.749241] Workqueue: nvkm-disp 
> gf119_disp_super [nouveau]
> Nov  3 09:14:06 ws6779 kernel: [4.749241] task: 8c79d753d040 
> task.stack: b4f2821c4000
> Nov  3 09:14:06 ws6779 kernel: [4.749242] RIP: 0010:  (null)
> Nov  3 09:14:06 ws6779 kernel: [4.749242] RSP: 0018:b4f2821c7c40 
> EFLAGS: 00010206
> Nov  3 09:14:06 ws6779 kernel: [4.749243] RAX: c081fec0 RBX: 
>  RCX: 0016
> Nov  3 09:14:06 ws6779 kernel: [4.749244] RDX:  RSI: 
>  RDI: 8c79dbe9a000
> Nov  3 09:14:06 ws6779 kernel: [4.749244] RBP:  R08: 
>  R09: 
> Nov  3 09:14:06 ws6779 kernel: [4.749244] R10: 1000 R11: 
> 10624dd3 R12: 
> Nov  3 09:14:06 ws6779 kernel: [4.749245] R13: b4f2821c7d6e R14: 
> b4f2821c7d60 R15: 8c79dce92c00
> Nov  3 09:14:06 ws6779 kernel: [4.749245] FS:  () 
> GS:8c79efb0() knlGS:
> Nov  3 09:14:06 ws6779 kernel: [4.749246] CS:  0010 DS:  ES:  
> CR0: 80050033
> Nov  3 09:14:06 ws6779 kernel: [4.749247] CR2:  CR3: 
> 000214009000 CR4: 001406e0
> Nov  3 09:14:06 ws6779 kernel: [4.749247] Call Trace:
> Nov  3 09:14:06 ws6779 kernel: [4.749272]  ? 
> nvkm_dp_train_drive+0x210/0x2f0 [nouveau]
> Nov  3 09:14:06 ws6779 kernel: [4.749294]  ? nvkm_dp_acquire+0x89c/0xca0 
> [nouveau]
> Nov  3 09:14:06 ws6779 kernel: [4.749317]  ? 
> nv50_disp_super_2_2+0x69/0x430 [nouveau]
> Nov  3 09:14:06 ws6779 kernel: [4.749337]  ? gf119_disp_super+0x1a5/0x2f0 
> [nouveau]
> Nov  3 09:14:06 ws6779 kernel: [4.749340]  ? process_one_work+0x181/0x370
> Nov  3 09:14:06 ws6779 kernel: [4.749341]  ? worker_thread+0x4d/0x3a0
> Nov  3 09:14:06 ws6779 kernel: [4.749342]  ? kthread+0xfc/0x130
> Nov  3 09:14:06 ws6779 kernel: [4.749343]  ? process_one_work+0x370/0x370
> Nov  3 09:14:06 ws6779 kernel: [4.749344]  ? 
> kthread_create_on_node+0x70/0x70
> Nov  3 09:14:06 ws6779 kernel: [4.749346]  ? ret_from_fork+0x25/0x30

Bug#836411: linux-image-4.7.0-1-amd64: hibernation fails, regression from 4.6

[Sven Joachim]

Control: tags -1 + fixed-upstream patch

On 2016-09-05 08:35 +0200, Sven Joachim wrote:

> Control: forwarded -1 
> https://lists.freedesktop.org/archives/dri-devel/2016-September/117528.html
>
> On 2016-09-02 19:48 +0200, Sven Joachim wrote:
>
>> Package: src:linux
>> Version: 4.7.2-1
>> Severity: important
>>
>> The other day I got myself a new (though not really shiny) laptop[1],
>> and while I managed to get most things working, hibernation (via
>> "systemctl hibernate") is broken in 4.7: the screen gets black, the fan
>> keeps being noisy, and there is no other sign of activity, so I had to
>> power-cycle the machine.
>>
>> With the 4.6 kernel from testing, hibernation and resume works fine.
>
> Found the culprit in the radeon driver and reported it upstream.

And at last it has been fixed in 4.14-rc3 by commit 820608548737
("drm/radeon: disable hard reset in hibernate for APUs"), although there
is the problem that the screen is blank after resume from hibernation.
But a suspend/resume cycle brings it back, I can live with that. 

Patch is attached for your convenience, it should appear in the stable
kernels soon.

Cheers,
   Sven

>From 820608548737e315c6f93e3099b4e65bde062334 Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deuc...@amd.com>
Date: Fri, 15 Sep 2017 11:55:27 -0400
Subject: [PATCH] drm/radeon: disable hard reset in hibernate for APUs

Fixes a hibernation regression on APUs.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=191571
Fixes: 274ad65c9d02bdc (drm/radeon: hard reset r600 and newer GPU when hibernating.)
Signed-off-by: Alex Deucher <alexander.deuc...@amd.com>
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c
index 997131d58c7f..ffc10cadcf34 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1663,7 +1663,7 @@ int radeon_suspend_kms(struct drm_device *dev, bool suspend,
 	radeon_agp_suspend(rdev);
 
 	pci_save_state(dev->pdev);
-	if (freeze && rdev->family >= CHIP_CEDAR) {
+	if (freeze && rdev->family >= CHIP_CEDAR && !(rdev->flags & RADEON_IS_IGP)) {
 		rdev->asic->asic_reset(rdev, true);
 		pci_restore_state(dev->pdev);
 	} else if (suspend) {
-- 
2.14.2

Bug#876215: linux-base: typo in linux-update-symlinks.1

[Sven Joachim]

Package: linux-base
Version: 4.5
Tags: patch

I wanted to get rid of the /vmlinuz and /initrd symlinks.  It took me a
while to find out that they are managed by linux-update-symlinks, and
then a trivial but crucial typo in the manpage did cost me even more
time to figure out that the parameter I needed to set is called
do_symlinks rather than no_symlinks.  Patch attached.


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

Kernel: Linux 4.13.2-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-base depends on:
ii  debconf  1.5.63

linux-base recommends no packages.

linux-base suggests no packages.


>From ca0c57a5213074261ce8e07a42533d79f8b0675d Mon Sep 17 00:00:00 2001
From: Sven Joachim <svenj...@gmx.de>
Date: Tue, 19 Sep 2017 20:36:55 +0200
Subject: [PATCH] Fix typo in linux-update-symlinks.1

---
 man/linux-update-symlinks.1 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man/linux-update-symlinks.1 b/man/linux-update-symlinks.1
index 97754db..c6ea4dc 100644
--- a/man/linux-update-symlinks.1
+++ b/man/linux-update-symlinks.1
@@ -31,7 +31,7 @@ Specifies the directory in which to maintain symlinks
 .B link_in_boot
 If set to a true value, specifies that the directory is \fI/boot\fR
 .TP
-.B no_symlinks
+.B do_symlinks
 If set to a false value, disables maintenance of symlinks
 .PD 1
 .PP
-- 
2.14.1

Bug#869084: linux-image-4.12.0-trunk-amd64: rtl8723be fails to work with old firmware

[Sven Joachim]

Control: tags -1 + patch

On 2017-07-28 13:29 +0200, Sven Joachim wrote:

> Control: forwarded -1 
> https://marc.info/?l=linux-wireless=150124050420053=2
>
> On 2017-07-20 13:54 +0200, Sven Joachim wrote:
>
>> Package: src:linux
>> Version: 4.12.2-1~exp1
>> Severity: important
>>
>> As of commit f70e4df2b384d21e36a7c30a591639592692e0ec, the rtl8723be
>> driver uses a new firmware file rtlwifi/rtl8723befw_36.bin which is not
>> packaged for Debian yet.  There is fallback code to load the old
>> firmware file rtlwifi/rtl8723befw.bin, but does not seem to work, for
>> the wifi fails to come up on my laptop. :-(
>
> AFAICS the problem is that request_firmware_nowait() does not wait for
> the firmware to show up and returns 0 even if the file is not there, so
> the code to load the fallback file will never be reached.
>
> I have reported this upstream now.

And even managed to come up with a patch that got accepted in the
wireless-drivers-next tree[1].  It does not apply to 4.12, therefore I
have attached a version which does.  Alternatively you could cherry-pick
commit f2764f61fa10 ("rtlwifi: Fix memory leak when firmware request
fails")[2] before it.

Cheers,
   Sven


1. 
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/?id=1d9b168d8ea9a0f51947d0e2f84856e77d2fe7ff

2. 
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/?id=f2764f61fa10593204b0c5e4e9a68dba02112e50

>From 6fff98234b7a25b717714a9a504d1ca805765ef1 Mon Sep 17 00:00:00 2001
From: Sven Joachim <svenj...@gmx.de>
Date: Sat, 29 Jul 2017 11:10:13 +0200
Subject: [PATCH] rtlwifi: Fix fallback firmware loading

Commit f70e4df2b384 ("rtlwifi: Add code to read new versions of
firmware") added code to load an old firmware file if the new one is
not available.  Unfortunately that code is never reached because
request_firmware_nowait() does not wait for the firmware to show up
and returns 0 even if the file is not there.

Use the existing fallback mechanism introduced by commit 62009b7f1279
("rtlwifi: rtl8192cu: Add new firmware") instead.

Fixes: f70e4df2b384 ("rtlwifi: Add code to read new versions of firmware")
Cc: sta...@vger.kernel.org
Signed-off-by: Sven Joachim <svenj...@gmx.de>
---
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c | 13 +++--
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c | 13 +++--
 2 files changed, 6 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c
index 8c0ac96b5430..c781105a8524 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c
@@ -187,16 +187,8 @@ int rtl8723be_init_sw_vars(struct ieee80211_hw *hw)
   rtlpriv->io.dev, GFP_KERNEL, hw,
   rtl_fw_cb);
 	if (err) {
-		/* Failed to get firmware. Check if old version available */
-		fw_name = "rtlwifi/rtl8723befw.bin";
-		pr_info("Using firmware %s\n", fw_name);
-		err = request_firmware_nowait(THIS_MODULE, 1, fw_name,
-	  rtlpriv->io.dev, GFP_KERNEL, hw,
-	  rtl_fw_cb);
-		if (err) {
-			pr_err("Failed to request firmware!\n");
-			return 1;
-		}
+		pr_err("Failed to request firmware!\n");
+		return 1;
 	}
 	return 0;
 }
@@ -287,6 +279,7 @@ static const struct rtl_hal_cfg rtl8723be_hal_cfg = {
 	.bar_id = 2,
 	.write_readback = true,
 	.name = "rtl8723be_pci",
+	.alt_fw_name = "rtlwifi/rtl8723befw.bin",
 	.ops = _hal_ops,
 	.mod_params = _mod_params,
 	.maps[SYS_ISO_CTRL] = REG_SYS_ISO_CTRL,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c
index abaf34cb1433..bc6dcac34924 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c
@@ -214,16 +214,8 @@ int rtl8821ae_init_sw_vars(struct ieee80211_hw *hw)
   rtlpriv->io.dev, GFP_KERNEL, hw,
   rtl_fw_cb);
 	if (err) {
-		/* Failed to get firmware. Check if old version available */
-		fw_name = "rtlwifi/rtl8821aefw.bin";
-		pr_info("Using firmware %s\n", fw_name);
-		err = request_firmware_nowait(THIS_MODULE, 1, fw_name,
-	  rtlpriv->io.dev, GFP_KERNEL, hw,
-	  rtl_fw_cb);
-		if (err) {
-			pr_err("Failed to request normal firmware!\n");
-			return 1;
-		}
+		pr_err("Failed to request normal firmware!\n");
+		return 1;
 	}
 	/*load wowlan firmware*/
 	pr_info("Using firmware %s\n", wowlan_fw_name);
@@ -325,6 +317,7 @@ static const struct rtl_hal_cfg rtl8821ae_hal_cfg = {
 	.bar_id = 2,
 	.write_readback = true,
 	.name = "rtl8821ae_pci",
+	.alt_fw_name = "rtlwifi/rtl8821aefw.bin",
 	.ops = _hal_ops,
 	.mod_params = _mod_params,
 	.maps[SYS_ISO_CTRL] = REG_SYS_ISO_CTRL,
-- 
2.13.3

Bug#869084: linux-image-4.12.0-trunk-amd64: rtl8723be fails to work with old firmware

[Sven Joachim]

Control: forwarded -1 https://marc.info/?l=linux-wireless=150124050420053=2

On 2017-07-20 13:54 +0200, Sven Joachim wrote:

> Package: src:linux
> Version: 4.12.2-1~exp1
> Severity: important
>
> As of commit f70e4df2b384d21e36a7c30a591639592692e0ec, the rtl8723be
> driver uses a new firmware file rtlwifi/rtl8723befw_36.bin which is not
> packaged for Debian yet.  There is fallback code to load the old
> firmware file rtlwifi/rtl8723befw.bin, but does not seem to work, for
> the wifi fails to come up on my laptop. :-(

AFAICS the problem is that request_firmware_nowait() does not wait for
the firmware to show up and returns 0 even if the file is not there, so
the code to load the fallback file will never be reached.

I have reported this upstream now.

Cheers,
   Sven

Bug#869084: linux-image-4.12.0-trunk-amd64: rtl8723be fails to work with old firmware

[Sven Joachim]

Package: src:linux
Version: 4.12.2-1~exp1
Severity: important

As of commit f70e4df2b384d21e36a7c30a591639592692e0ec, the rtl8723be
driver uses a new firmware file rtlwifi/rtl8723befw_36.bin which is not
packaged for Debian yet.  There is fallback code to load the old
firmware file rtlwifi/rtl8723befw.bin, but does not seem to work, for
the wifi fails to come up on my laptop. :-(


-- Package-specific info:
** Version:
Linux version 4.12.0-trunk-amd64 (debian-kernel@lists.debian.org) (gcc version 
6.4.0 20170704 (Debian 6.4.0-1) ) #1 SMP Debian 4.12.2-1~exp1 (2017-07-18)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.12.0-trunk-amd64 
root=UUID=54317940-5e45-4370-8f77-153d1b67ca31 ro quiet

** Not tainted

** Kernel log:
[  917.542154]  ? rcu_dump_cpu_stacks+0x99/0xd0
[  917.542160]  ? rcu_check_callbacks+0x78b/0x8e0
[  917.542167]  ? update_wall_time+0x486/0x750
[  917.542174]  ? tick_sched_handle.isra.15+0x50/0x50
[  917.542179]  ? update_process_times+0x28/0x50
[  917.542185]  ? tick_sched_handle.isra.15+0x20/0x50
[  917.542190]  ? tick_sched_timer+0x38/0x70
[  917.542195]  ? __hrtimer_run_queues+0xdc/0x220
[  917.542200]  ? hrtimer_interrupt+0xa6/0x1f0
[  917.542208]  ? smp_apic_timer_interrupt+0x34/0x50
[  917.542213]  ? apic_timer_interrupt+0x82/0x90
[  917.542215]  
[  917.542223]  ? delay_tsc+0x21/0x50
[  917.542236]  ? rtl8723_fw_free_to_go+0x98/0x110 [rtl8723_common]
[  917.542243]  ? rtl8723_download_fw+0xb6/0x150 [rtl8723_common]
[  917.542254]  ? rtl8723be_hw_init+0xc6c/0x1760 [rtl8723be]
[  917.542268]  ? rtl_ps_enable_nic+0x29/0x90 [rtlwifi]
[  917.542277]  ? rtl8723be_phy_set_rf_power_state+0x337/0x370 [rtl8723be]
[  917.542288]  ? rtl_ps_set_rf_state+0xb6/0x140 [rtlwifi]
[  917.542299]  ? _rtl_ps_inactive_ps+0x36/0xb0 [rtlwifi]
[  917.542309]  ? rtl_ips_nic_on+0x7b/0xb0 [rtlwifi]
[  917.542320]  ? rtl_op_config+0x1cc/0x390 [rtlwifi]
[  917.542369]  ? ieee80211_hw_config+0x85/0x350 [mac80211]
[  917.542412]  ? __ieee80211_start_scan+0x1f6/0x6a0 [mac80211]
[  917.542455]  ? ieee80211_request_scan+0x2b/0x50 [mac80211]
[  917.542507]  ? nl80211_trigger_scan+0x317/0x7a0 [cfg80211]
[  917.542515]  ? genl_family_rcv_msg+0x1e0/0x380
[  917.542521]  ? compat_poll_select_copy_remaining+0x120/0x120
[  917.542528]  ? genl_rcv_msg+0x47/0x90
[  917.542532]  ? genl_family_rcv_msg+0x380/0x380
[  917.542536]  ? netlink_rcv_skb+0xe7/0x120
[  917.542541]  ? genl_rcv+0x24/0x40
[  917.542544]  ? netlink_unicast+0x184/0x230
[  917.542549]  ? netlink_sendmsg+0x2b8/0x3a0
[  917.542557]  ? sock_sendmsg+0x30/0x40
[  917.542562]  ? ___sys_sendmsg+0x2d7/0x2f0
[  917.542568]  ? core_sys_select+0x211/0x2b0
[  917.542576]  ? SYSC_recvfrom+0xc3/0x130
[  917.542581]  ? ktime_get_ts64+0x49/0xe0
[  917.542586]  ? __sys_sendmsg+0x51/0x90
[  917.542589]  ? __sys_sendmsg+0x51/0x90
[  917.542596]  ? system_call_fast_compare_end+0xc/0x97
[  925.616165] rtl8723_common: Polling FW ready fail!! REG_MCUFWDL:0x0006 .
[  925.622859] rtl8723_common: Firmware is not ready to run!
[  953.972286] INFO: rcu_sched self-detected stall on CPU
[  953.979117]  1-...: (5249 ticks this GP) idle=e0a/141/0 
softirq=4410/4410 fqs=2625 
[  953.986070]   (t=5250 jiffies g=2057 c=2056 q=30)
[  953.992961] NMI backtrace for cpu 1
[  953.992968] CPU: 1 PID: 1980 Comm: wpa_supplicant Not tainted 
4.12.0-trunk-amd64 #1 Debian 4.12.2-1~exp1
[  953.992970] Hardware name: HP HP Notebook/81F5, BIOS F.08 04/21/2016
[  953.992973] Call Trace:
[  953.992979]  
[  953.992989]  ? dump_stack+0x5c/0x84
[  953.992995]  ? nmi_cpu_backtrace+0x89/0x90
[  953.993003]  ? irq_force_complete_move+0x140/0x140
[  953.993009]  ? nmi_trigger_cpumask_backtrace+0xf4/0x120
[  953.993016]  ? rcu_dump_cpu_stacks+0x99/0xd0
[  953.993023]  ? rcu_check_callbacks+0x78b/0x8e0
[  953.993028]  ? update_wall_time+0x486/0x750
[  953.993035]  ? tick_sched_handle.isra.15+0x50/0x50
[  953.993040]  ? update_process_times+0x28/0x50
[  953.993046]  ? tick_sched_handle.isra.15+0x20/0x50
[  953.993051]  ? tick_sched_timer+0x38/0x70
[  953.993056]  ? __hrtimer_run_queues+0xdc/0x220
[  953.993061]  ? hrtimer_interrupt+0xa6/0x1f0
[  953.993069]  ? smp_apic_timer_interrupt+0x34/0x50
[  953.993074]  ? apic_timer_interrupt+0x82/0x90
[  953.993076]  
[  953.993083]  ? delay_tsc+0x1f/0x50
[  953.993096]  ? rtl8723_fw_free_to_go+0x98/0x110 [rtl8723_common]
[  953.993103]  ? rtl8723_download_fw+0xb6/0x150 [rtl8723_common]
[  953.993114]  ? rtl8723be_hw_init+0xc6c/0x1760 [rtl8723be]
[  953.993128]  ? rtl_ps_enable_nic+0x29/0x90 [rtlwifi]
[  953.993137]  ? rtl8723be_phy_set_rf_power_state+0x337/0x370 [rtl8723be]
[  953.993148]  ? rtl_ps_set_rf_state+0xb6/0x140 [rtlwifi]
[  953.993159]  ? _rtl_ps_inactive_ps+0x36/0xb0 [rtlwifi]
[  953.993170]  ? rtl_ips_nic_on+0x7b/0xb0 [rtlwifi]
[  953.993180]  ? rtl_op_config+0x1cc/0x390 [rtlwifi]
[  953.993230]  ? ieee80211_hw_config+0x85/0x350 [mac80211]
[  953.993273]  ? __ieee80211_start_scan+0x1f6/0x6a0 [mac80211]
[  953.993315]  ? 

Bug#861151: W: initramfs-tools configuration sets RESUME=UUID=... warning even though RESUME=none

[Sven Joachim]

On 2017-04-25 12:52 +0930, Arthur Marsh wrote:

> Package: initramfs-tools
> Version: 0.129
> Severity: normal
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
>
> set RESUME=none in /etc/initramfs-tools/initramfs.conf but
> still get messages:
>
> W: initramfs-tools configuration sets 
> RESUME=UUID=604db355-002c-4f41-b31c-438fe788b26d

That may be coming from a stale file /etc/initramfs-tools/conf.d/resume,
which is the location where the RESUME variable had to be set in
versions prior to 0.129.

AFAICS mkinitramfs sources /etc/initramfs-tools/initramfs.conf before
any files in /etc/initramfs-tools/conf.d which does not look quite
right, but maybe there are reasons for that.

> W: but no matching swap device is available.
> I: The initramfs will attempt to resume from /dev/sda4
> I: (UUID=0e388c35-a730-4a86-ac45-e11486b3e992)
> I: Set the RESUME variable to override this.
>
> As far as I can tell, on boot up there is no attempt to resume from that UUID.

Did you hibernate first?

Cheers,
   Sven

Bug#861057: initramfs-tools: no longer supports RESUME=LABEL|UUID syntax

[Sven Joachim]

Package: initramfs-tools
Version: 0.129
Severity: normal

For many years I have been using "RESUME=LABEL=swap" in
/etc/initramfs-tools/conf.d/resume.  Since initramfs-tools 0.129 this
does no longer work:

,
| # update-initramfs -c -k 4.11.0-rc7-nouveau -t
| update-initramfs: Generating /boot/initrd.img-4.11.0-rc7-nouveau
| W: initramfs-tools configuration sets RESUME=LABEL=swap
| W: but no matching swap device is available.
| I: The initramfs will attempt to resume from /dev/sdb1
| I: (UUID=4dbd12ed-75ac-445e-933a-93df34314795)
| I: Set the RESUME variable to override this.
`

Contrary to what is stated in NEWS.Debian,
RESUME=UUID=4dbd12ed-75ac-445e-933a-93df34314795 in
/etc/initramfs-tools/conf.d/resume leads to the same warning.


-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root  17M Mär 21 20:39 /boot/initrd.img-3.16.0-4-amd64
-rw-r--r-- 1 root root 5,2M Apr 12 15:54 /boot/initrd.img-4.10.10-nouveau
-rw-r--r-- 1 root root 5,2M Apr 18 10:38 /boot/initrd.img-4.10.11-nouveau
-rw-r--r-- 1 root root 5,2M Apr 21 15:27 /boot/initrd.img-4.10.12-nouveau
-rw-r--r-- 1 root root 5,2M Mär  6 11:12 /boot/initrd.img-4.11.0-rc1-nouveau
-rw-r--r-- 1 root root 5,2M Mär 17 23:09 /boot/initrd.img-4.11.0-rc2-nouveau
-rw-r--r-- 1 root root 5,2M Mär 23 12:31 /boot/initrd.img-4.11.0-rc3-nouveau
-rw-r--r-- 1 root root 5,2M Mär 29 09:00 /boot/initrd.img-4.11.0-rc4-nouveau
-rw-r--r-- 1 root root 5,2M Apr  9 12:28 /boot/initrd.img-4.11.0-rc5-nouveau
-rw-r--r-- 1 root root 5,2M Apr  9 20:55 /boot/initrd.img-4.11.0-rc6-nouveau
-rw-r--r-- 1 root root 5,2M Apr 24 09:31 /boot/initrd.img-4.11.0-rc7-nouveau
-rw-r--r-- 1 root root 5,2M Apr 24 08:59 /boot/initrd.img-4.11.0-rc8-nouveau
-rw-r--r-- 1 root root 5,0M Apr 12 15:54 /boot/initrd.img-4.4.61-nouveau
-rw-r--r-- 1 root root 5,0M Apr 18 10:38 /boot/initrd.img-4.4.62-nouveau
-rw-r--r-- 1 root root 5,0M Apr 21 15:27 /boot/initrd.img-4.4.63-nouveau
-rw-r--r-- 1 root root 5,1M Apr  8 12:09 /boot/initrd.img-4.9.21-nouveau
-rw-r--r-- 1 root root 5,1M Apr 12 15:53 /boot/initrd.img-4.9.22-nouveau
-rw-r--r-- 1 root root 5,1M Apr 18 10:38 /boot/initrd.img-4.9.23-nouveau
-rw-r--r-- 1 root root 5,1M Apr 21 15:27 /boot/initrd.img-4.9.24-nouveau
-- /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.9.24-nouveau 
root=UUID=d810a348-fcd5-4a4e-b937-65e64e7ab543 ro reboot=pci 
acpi_enforce_resources=lax quiet

-- resume
RESUME=LABEL=swap
-- /proc/filesystems
ext3
ext2
ext4

-- lsmod
Module  Size  Used by
usb_storage48130  0
snd_seq_oss26179  0
snd_seq_midi_event  5252  1 snd_seq_oss
snd_seq44554  5 snd_seq_midi_event,snd_seq_oss
snd_seq_device  3048  2 snd_seq,snd_seq_oss
ctr 3840  4
ccm 8304  2
ipt_MASQUERADE  1213  1
nf_nat_masquerade_ipv4 1929  1 ipt_MASQUERADE
iptable_nat 1887  1
nf_conntrack_ipv4   7044  1
nf_defrag_ipv4  1347  1 nf_conntrack_ipv4
nf_nat_ipv4 4507  1 iptable_nat
nf_nat 13085  2 nf_nat_masquerade_ipv4,nf_nat_ipv4
nf_conntrack   60210  4 
nf_conntrack_ipv4,nf_nat_masquerade_ipv4,nf_nat_ipv4,nf_nat
arc42040  2
binfmt_misc 6790  1
coretemp5852  0
acpi_cpufreq7186  0
kvm_intel 167309  0
kvm   322212  1 kvm_intel
irqbypass   2680  1 kvm
rt2800usb  17091  0
rt2x00usb   8561  1 rt2800usb
rt2800lib  72754  1 rt2800usb
rt2x00lib  31910  3 rt2800lib,rt2800usb,rt2x00usb
mac80211  340976  3 rt2800lib,rt2x00lib,rt2x00usb
pcspkr  2035  0
cfg80211  235323  2 rt2x00lib,mac80211
snd_hda_codec_realtek55683  1
crc_ccitt   1467  1 rt2800lib
snd_hda_codec_generic52231  1 snd_hda_codec_realtek
sg 24669  0
snd_hda_intel  17521  0
snd_hda_codec  72230  3 
snd_hda_intel,snd_hda_codec_generic,snd_hda_codec_realtek
snd_hda_core   39863  4 
snd_hda_intel,snd_hda_codec,snd_hda_codec_generic,snd_hda_codec_realtek
snd_pcm_oss34609  0
snd_mixer_oss  13600  1 snd_pcm_oss
snd_pcm73145  4 
snd_pcm_oss,snd_hda_intel,snd_hda_codec,snd_hda_core
snd_timer  19103  2 snd_seq,snd_pcm
snd54329  11 
snd_pcm_oss,snd_hda_intel,snd_mixer_oss,snd_seq,snd_hda_codec,snd_timer,snd_hda_codec_generic,snd_seq_device,snd_seq_oss,snd_pcm
intel_agp  11049  0
soundcore   5027  1 snd
intel_gtt  12341  1 intel_agp
8250   13711  0
8250_base  20223  1 8250
serial_core23306  2 8250,8250_base
evdev  12394  6
processor  27001  1 acpi_cpufreq
w83627ehf  31092  0
hwmon_vid   3108  1 w83627ehf
nfsd  230805  13
auth_rpcgss40640  1 nfsd
oid_registry2435  

Re: Bug#849984: xserver-xorg-video-nouveau: Kernel 4.8.0-2 start with black screen on NVidia ION

[Sven Joachim]

Control: reassign -1 src:linux 4.8.11-1
Control: severity -1 important

On 2017-01-02 21:17 +0100, Torben Schou Jensen wrote:

> Package: xserver-xorg-video-nouveau
> Version: 1:1.0.13-1+b1
> Severity: critical
> Justification: breaks the whole system
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate
> ***
>
>* What led up to the situation?
> Computer here is setup with Debian Testing and was updated with latest
> updates.
> Booting with latest kernel, 4.8.0-2, then result in black screen.
> In end of boot kernel drop connection to monitor.
> Not even a command prompt is available, and only hard reboot is way forward.
> Same problem on kernel 4.8.0-1.

This is a kernel problem then, no way for the xserver-xorg-video-nouveau
package to do anything about it.

> But everything work fine on kernel 4.7.0-1.
>
> In SYSLOG I see the following messages on a failed 4.8.0-2 boot.
>
> nouveau :01:00.0: bus: MMIO write of 8015 FAULT at 61a804
> nouveau :01:00.0: bus: MMIO read of  FAULT at 61a804
> nouveau :01:00.0: bus: MMIO read of 0010 FAULT at 64
> nouveau :01:00.0: bus: MMIO read of 0001 FAULT at 64
> nouveau :01:00.0: bus: MMIO read of 0010 FAULT at 64
> nouveau :01:00.0: bus: MMIO write of 0014 FAULT at 64
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
> If I boot on kernel 4.7.0-1 everything work fine and I have full display
> on my my monitor (PHILIPS 273V5HSB 1920 x
> 1080).
> If I boot on kernel 4.8.0-2 with kernel parameter "nomodeset" it start
> fine, but then Debian only use VESA in X.
>
>* What was the outcome of this action?
>
> With "nomodeset" system start fine, but NVidia card is not used as expected.
> Until further I can use kernel 4.7.0-1.
>
>* What outcome did you expect instead?
>
> I expect kernel to set modes correct so nouveau driver can start correct
> on kernel 4.8.
>
> *** End of the template - remove these template lines ***
>
>
> -- Package-specific info:
> X server symlink status:
> 
> lrwxrwxrwx 1 root root 13 Feb 17  2015 /etc/X11/X -> /usr/bin/Xorg
> -rwxr-xr-x 1 root root 274 Dec 16 19:39 /usr/bin/Xorg
>
> VGA-compatible devices on PCI bus:
> --
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation ION VGA
> [10de:087d] (rev b1)
>
> /etc/X11/xorg.conf does not exist.
>
> /etc/X11/xorg.conf.d does not exist.
>
> /etc/modprobe.d contains no KMS configuration files.
>
> Kernel version (/proc/version):
> ---
> Linux version 4.8.0-2-686-pae (debian-kernel@lists.debian.org) (gcc
> version 5.4.1 20161019 (Debian 5.4.1-3) ) #1 SMP Debian 4.8.11-1
> (2016-12-02)
>
> Xorg X server log files on system:
> --
> -rw-r--r-- 1 root root 71875 Jan  2 20:39 /var/log/Xorg.0.log
>
> Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
> -
> [   508.572]
> X.Org X Server 1.19.0
> Release Date: 2016-11-15
> [   508.573] X Protocol Version 11, Revision 0
> [   508.573] Build Operating System: Linux 3.16.0-4-amd64 i686 Debian
> [   508.573] Current Operating System: Linux asrock 4.8.0-2-686-pae #1 SMP
> Debian 4.8.11-1 (2016-12-02) i686
> [   508.574] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.8.0-2-686-pae
> root=UUID=ce862291-20d7-4312-9e8b-33cef86c57dd ro acpi=force nomodeset
> [   508.574] Build Date: 16 December 2016  07:33:27PM
> [   508.574] xorg-server 2:1.19.0-3 (https://www.debian.org/support)
> [   508.575] Current version of pixman: 0.34.0
> [   508.575]  Before reporting problems, check http://wiki.x.org
>   to make sure that you have the latest version.
> [   508.575] Markers: (--) probed, (**) from config file, (==) default
> setting,
>   (++) from command line, (!!) notice, (II) informational,
>   (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> [   508.577] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Jan  2
> 20:39:49 2017
> [   508.601] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
> [   508.659] (==) No Layout section.  Using the first Screen section.
> [   508.659] (==) No screen section available. Using defaults.
> [   508.659] (**) |-->Screen "Default Screen Section" (0)
> [   508.659] (**) |   |-->Monitor ""
> [   508.675] (==) No monitor specified for screen "Default Screen Section".
>   Using a default monitor configuration.
> [   508.675] (==) Automatically adding devices
> [   508.675] (==) Automatically enabling devices
> [   508.675] (==) Automatically adding GPU devices
> [   508.675] (==) Max clients allowed: 256, resource mask: 0x1f
> [   508.718] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not
> exist.
> [   508.718]  Entry deleted from font path.
> [   508.722] (==) FontPath set to:
>   /usr/share/fonts/X11/misc,
>

Bug#848277: nfs-common: /usr/sbin/start-statd: 10: exec: 200: not found

[Sven Joachim]

Package: nfs-common
Version: 1:1.3.4-1
Severity: important

Even after fixing nfs-config.service (see #848145), I could no longer
use my NFS 3 mounts because rpc.statd failed to start:

,
| /usr/sbin/start-statd: 10: exec: 200: not found
`

That's because dash, unlike bash, does not support file descriptors
higher than 9 in redirection and treats the command as if it had been
"exec 200 > /var/run/rpc.statd.lock".

According to POSIX.1-2008[1], you cannot rely on a number higher than 9
here:

,
| The largest possible value is implementation-defined; however, all
| implementations shall support at least 0 to 9, inclusive, for use by the
| application.
`

Indeed, using 9 rather than 200 actually works.


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

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

Versions of packages nfs-common depends on:
ii  adduser  3.115
ii  init-system-helpers  1.46
ii  keyutils 1.5.9-9
ii  libc62.24-8
ii  libcap2  1:2.25-1
ii  libcomerr2   1.43.3-1
ii  libdevmapper1.02.1   2:1.02.136-1
ii  libevent-2.0-5   2.0.21-stable-2.1
ii  libgssapi-krb5-2 1.15-1
ii  libk5crypto3 1.15-1
ii  libkeyutils1 1.5.9-9
ii  libkrb5-31.15-1
ii  libmount12.29-1
ii  libnfsidmap2 0.25-5
ii  libtirpc10.2.5-1
ii  libwrap0 7.6.q-25
ii  lsb-base 9.20161125
ii  rpcbind  0.2.3-0.5
ii  ucf  3.0036

Versions of packages nfs-common recommends:
ii  python  2.7.11-2

Versions of packages nfs-common suggests:
pn  open-iscsi  
pn  watchdog

-- no debconf information


1. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html 
(§2.7)

Re: Bug#845690: gcc-6: gcc creates unbootable kernel on x86-64

[Sven Joachim]

On 2016-11-28 14:50 +0100, Matthias Klose wrote:

> please could you check again with
> https://people.debian.org/~doko/tmp/binutils_2.27.51.20161127-1.1_amd64.deb
> having the suggested fix proposed at
> https://sourceware.org/ml/binutils/2016-11/msg00348.html

Works for me, thanks. :-)

Cheers,
   Sven

Re: Bug#845690: gcc-6: gcc creates unbootable kernel on x86-64

[Sven Joachim]

On 2016-11-27 18:34 +0100, Matthias Klose wrote:

> On 27.11.2016 16:51, Sven Joachim wrote:
>> On 2016-11-27 13:39 +0100, Matthias Klose wrote:
>> 
>>> Control: tags -1 + help moreinfo
>>> Control: severity -1 important
>>>
>>> On 27.11.2016 08:38, Sven Joachim wrote:
>>>> Control: reassign -1 binutils 2.27.51.20161124-1
>>>> Control: retitle -1 binutils: creates unbootable kernel on x86-64
>>>> Control: severity -1 grave
>>>>
>>>> On 2016-11-26 15:13 +0100, Damien Wyart wrote:
>>>>
>>>>> After running further tests today, I think this is in fact *not*
>>>>> related to gcc but to the kernel itself.
>>>>>
>>>>> I tested all 6.2.1-X versions as well as gcc-5 (5.4.1-3) and all the
>>>>> kernels fail to boot (balck screen just after grub and nothing in the
>>>>> logs).
>>>>
>>>> Same here, downgrading binutils to 2.27.51.20161118-2 helped.  I'm
>>>> reassigning the bug and bumping the severity, since several people have
>>>> observed the problem.
>>>
>>> The original report talks about a 4.4 problem on , which afaik is 
>>> superseded in
>>> unstable by newever versions released after the GCC 6 release.  This is now 
>>> made
>>> a binutils RC issue for building a kernel which is not in the archive 
>>> anymore.
>>> Please could you validate that the issue exists with the linux package in
>>> unstable as well?
>> 
>> I have noticed the problem with vanilla Linux 4.8.11 from kernel.org, so
>> I suspect the Debian kernel is affected as well.  There is no console
>> output at all, the system freezes right when uncompressing the kernel.
>> 
>> It should be noted that I haven't noticed the problem on my desktop
>> (which has a 32-bit userland but a 64-bit kernel) where I have
>> CONFIG_KERNEL_GZIP=y, but on my laptop which uses the default
>> CONFIG_KERNEL_XZ=y it is reproducible.
>
> if it's really binutils, I prepared a package reverting the fix for PR 
> ld/20815.
> Would be nice if somebody could check that out:
> https://people.debian.org/~doko/tmp/binutils_2.27.51.20161124-1.1_amd64.deb

Thanks, that binutils package produces a working kernel here.

Cheers,
   Sven

Re: Bug#845690: gcc-6: gcc creates unbootable kernel on x86-64

[Sven Joachim]

On 2016-11-27 13:39 +0100, Matthias Klose wrote:

> Control: tags -1 + help moreinfo
> Control: severity -1 important
>
> On 27.11.2016 08:38, Sven Joachim wrote:
>> Control: reassign -1 binutils 2.27.51.20161124-1
>> Control: retitle -1 binutils: creates unbootable kernel on x86-64
>> Control: severity -1 grave
>> 
>> On 2016-11-26 15:13 +0100, Damien Wyart wrote:
>> 
>>> After running further tests today, I think this is in fact *not*
>>> related to gcc but to the kernel itself.
>>>
>>> I tested all 6.2.1-X versions as well as gcc-5 (5.4.1-3) and all the
>>> kernels fail to boot (balck screen just after grub and nothing in the
>>> logs).
>> 
>> Same here, downgrading binutils to 2.27.51.20161118-2 helped.  I'm
>> reassigning the bug and bumping the severity, since several people have
>> observed the problem.
>
> The original report talks about a 4.4 problem on , which afaik is superseded 
> in
> unstable by newever versions released after the GCC 6 release.  This is now 
> made
> a binutils RC issue for building a kernel which is not in the archive anymore.
> Please could you validate that the issue exists with the linux package in
> unstable as well?

I have noticed the problem with vanilla Linux 4.8.11 from kernel.org, so
I suspect the Debian kernel is affected as well.  There is no console
output at all, the system freezes right when uncompressing the kernel.

It should be noted that I haven't noticed the problem on my desktop
(which has a 32-bit userland but a 64-bit kernel) where I have
CONFIG_KERNEL_GZIP=y, but on my laptop which uses the default
CONFIG_KERNEL_XZ=y it is reproducible.

Cheers,
   Sven

Bug#841420: --enable-default-pie breaks kernel builds

[Sven Joachim]

On 2016-10-20 17:54 +0200, Bálint Réczey wrote:

> Control: reassign -1 linux 4.7.8-1
> Control: severity -1 serious
> Control: tags -1 patch
>
> Hi David,
>
> 2016-10-20 14:02 GMT+02:00 David Weinehall :
>> Package: gcc-6
>> Severity: important
>> Version: 6.2.0-7
>>
>> --enable-default-pie (first enabled in gcc-6 6.2.0-7) causes kernel
>> builds to fail.  If the kernel is configured with the stack protector
>> enabled it'll fail with a rather unhelpful error message claiming
>> that the compiler doesn't support -fstack-protector,
>> but the problem is in fact caused by:
>>
>> kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
>>
>> (The kernel is built with -mcmodel=kernel)
>>
>> I think it's fair to say that the kernel is kind of an important piece
>> of software and that it's imperative that we don't break kernel builds...
>
> The kernel is very important indeed and it did break in our build test.
> I'm sorry, somehow I missed filing bug for the linux package, just for
> user-mode-linux.
> The following patch fixes the FTBFS:
>
> --- linux-4.7.8/debian/rules.d/Makefile.inc
> +++ linux-4.7.8/debian/rules.d/Makefile.inc
> @@ -5,7 +5,8 @@
>
>  SHELL = /bin/sh -e
>
> -CC = $(CROSS_COMPILE)gcc
> +CC = $(CROSS_COMPILE)gcc -no-pie
> +LD = $(CROSS_COMPILE)ld -no-pie
>  CXX = $(CROSS_COMPILE)g++
>  CFLAGS := $(shell dpkg-buildflags --get CFLAGS) -Wall
>  CPPFLAGS := $(shell dpkg-buildflags --get CPPFLAGS) \
>
> Maybe the ld part is obsolete, I have not checked that.

That patch might work for the Debian package, but has anybody contacted
the upstream kernel developers about that?  At least the 4.8.3 vanilla
kernel fails in the same way, I haven't tested 4.9-rc1 yet.

FWIW, this issue has been discussed in Ubuntu for six months(!), see
https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1574982.

Cheers,
   Sven

Bug#823637: firmware-nonfree: please add a firmware-nvidia-graphics package

[Sven Joachim]

Control: reassign 839139 src:firmware-nonfree
Control: severity -1 important
Control: merge -1 839139
Control: tags -1 patch

On 2016-05-06 23:23 +0200, Sven Joachim wrote:

> Source: firmware-nonfree
> Version: 20160110-1
> Severity: wishlist
>
> Starting with the Maxwell GM20x generation[1], NVidia graphics cards
> require signed firmware for most operations, the Nouveau driver does not
> provide acceleration without the firmware.
>
> In February 2016, NVidia finally made the firmware available in the
> linux-firmware git repository, and with Linux 4.6 and Mesa 11.2 (both
> currently in experimental) users should be able to get acceptable
> performance out of their expensive cards without having to resort to the
> proprietary driver.

This really ought to be fixed, as these cards have become very common
and users are complaining (see #839139).  The second of the attached
patches creates a new firmware-nvidia-graphics package with the firmware
files for Maxwell and Pascal chips.  While I still don't have the
hardware to test the package, at least update-initramfs no longer warns
about missing firmware when nouveau is included in
/etc/initramfs-tools/modules.

The new package currently is slightly under 60 kilobytes, and it would
certainly also be possible to put the files into the
firmware-misc-nonfree catch-all package (the Tegra firmware is already
there).  However, more NVidia firmware is probably going to be released
in the future, so a separate package makes sense to me.

In any case, the first of the two attached patches fixes a problem in
debian/rules.real where 'ln' would fail because a target directory does
not exist.

Thanks for consideration,
Sven

>From f5e3018be836ce90e1c2977adb7555d9743d0702 Mon Sep 17 00:00:00 2001
From: Sven Joachim <svenj...@gmx.de>
Date: Fri, 14 Oct 2016 12:58:07 +0200
Subject: [PATCH 1/2] Ensure that target directory for symbolic links exists

If a directory contains only symlinks and no regular files, as in the
case of nvidia/gm204/acr/, installing the symlink would fail:

ln -s ../../gm200/acr/ucode_unload.bin debian/firmware-nvidia-graphics/lib/firmware/nvidia/gm204/acr/ucode_unload.bin
ln: failed to create symbolic link 'debian/firmware-nvidia-graphics/lib/firmware/nvidia/gm204/acr/ucode_unload.bin': No such file or directory
debian/rules.real:13: recipe for target 'install' failed
---
 debian/rules.real | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules.real b/debian/rules.real
index 1def0e3..b0490d6 100644
--- a/debian/rules.real
+++ b/debian/rules.real
@@ -22,6 +22,7 @@ install:
 	@for i in $(LINKS); do \
 	  link=debian/$(PACKAGE_NAME)/lib/firmware/"$${i%:*}"; \
 	  target="$${i#*:}"; \
+	  install -d "$${link%/*}"; \
 	  echo ln -s "$$target" "$$link"; \
 	  ln -s "$$target" "$$link"; \
 	done
-- 
2.9.3

>From 208ed145066f2394dd0e9ed38bce81971625d3ec Mon Sep 17 00:00:00 2001
From: Sven Joachim <svenj...@gmx.de>
Date: Fri, 14 Oct 2016 10:44:58 +0200
Subject: [PATCH 2/2] Add an nvidia-graphics-firmware package

---
 debian/config/defines |   1 +
 debian/config/nvidia-graphics/LICENSE | 130 ++
 debian/config/nvidia-graphics/defines |  76 
 3 files changed, 207 insertions(+)
 create mode 100644 debian/config/nvidia-graphics/LICENSE
 create mode 100644 debian/config/nvidia-graphics/defines

diff --git a/debian/config/defines b/debian/config/defines
index 713a491..15d857e 100644
--- a/debian/config/defines
+++ b/debian/config/defines
@@ -15,6 +15,7 @@ packages:
  misc-nonfree
  myricom
  netxen
+ nvidia-graphics
  qlogic
  realtek
  samsung
diff --git a/debian/config/nvidia-graphics/LICENSE b/debian/config/nvidia-graphics/LICENSE
new file mode 100644
index 000..6dfb2aa
--- /dev/null
+++ b/debian/config/nvidia-graphics/LICENSE
@@ -0,0 +1,130 @@
+Files: nvidia/*
+Copyright:
+License: License For Customer Use of NVIDIA Software
+ IMPORTANT NOTICE -- READ CAREFULLY: This License For Customer Use of
+ NVIDIA Software ("LICENSE") is the agreement which governs use of
+ the software of NVIDIA Corporation and its subsidiaries ("NVIDIA")
+ downloadable herefrom, including computer software and associated
+ printed materials ("SOFTWARE").  By downloading, installing, copying,
+ or otherwise using the SOFTWARE, you agree to be bound by the terms
+ of this LICENSE.  If you do not agree to the terms of this LICENSE,
+ do not download the SOFTWARE.
+ .
+ RECITALS
+ .
+ Use of NVIDIA's products requires three elements: the SOFTWARE, the
+ hardware, and a personal computer. The SOFTWARE is protected by copyright
+ laws and international copyright treaties, as well as other intellectual
+ property laws and treaties.  The SOFTWARE may be protected by various
+ patents, and is not sold, and instead is only licensed for use, strictly

Bug#838858: firmware-amd-graphics: missing SI/CI smc firmware files

[Sven Joachim]

Package: firmware-amd-graphics
Version: 20160824-1
Severity: normal

There are warnings from update-initramfs that some radeon firmware files
are missing:

,
| # update-initramfs -u
| update-initramfs: Generating /boot/initrd.img-4.8.0-rc7-pavil+
| W: Possible missing firmware /lib/firmware/radeon/hainan_k_smc.bin for module 
radeon
| W: Possible missing firmware /lib/firmware/radeon/oland_k_smc.bin for module 
radeon
| W: Possible missing firmware /lib/firmware/radeon/verde_k_smc.bin for module 
radeon
| W: Possible missing firmware /lib/firmware/radeon/pitcairn_k_smc.bin for 
module radeon
| W: Possible missing firmware /lib/firmware/radeon/tahiti_k_smc.bin for module 
radeon
| W: Possible missing firmware /lib/firmware/radeon/hawaii_k_smc.bin for module 
radeon
| W: Possible missing firmware /lib/firmware/radeon/bonaire_k_smc.bin for 
module radeon
`

These files have been added upstream on 2016-06-08 in commits
406964300821 and 9693ff6d749d.


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

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

firmware-amd-graphics depends on no packages.

firmware-amd-graphics recommends no packages.

Versions of packages firmware-amd-graphics suggests:
ii  initramfs-tools  0.125

-- no debconf information

Bug#836411: linux-image-4.7.0-1-amd64: hibernation fails, regression from 4.6

[Sven Joachim]

Control: forwarded -1 
https://lists.freedesktop.org/archives/dri-devel/2016-September/117528.html

On 2016-09-02 19:48 +0200, Sven Joachim wrote:

> Package: src:linux
> Version: 4.7.2-1
> Severity: important
>
> The other day I got myself a new (though not really shiny) laptop[1],
> and while I managed to get most things working, hibernation (via
> "systemctl hibernate") is broken in 4.7: the screen gets black, the fan
> keeps being noisy, and there is no other sign of activity, so I had to
> power-cycle the machine.
>
> With the 4.6 kernel from testing, hibernation and resume works fine.

Found the culprit in the radeon driver and reported it upstream.

Cheers,
   Sven

Bug#803987: firmware-realtek: Very weak signal on RTL8723BE adaptor

[Sven Joachim]

On 2015-11-03 21:48 +0100, Antonio Peiro Saez wrote:

> Package: firmware-realtek
> Version: 20151018-2
> Severity: important
>
> After a clean installation of Debian 8.2 in a disk partition of my
> laptop the Realtek wireless network adapter, and the Realtek ethernet
> controller needed the installation of the nonfree firmware.
>
>antonio@BB-8:~$ uname -a
>Linux BB-8 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u4 (2015-09-19) 
> x86_64 GNU/Linux
>antonio@BB-8:~$ lspci | grep Realtek
>02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe 
> Wireless Network Adapter
>03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
> RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 07)
>
> The installation of the firmware-realtek 0.43 package included with
> the Debian distribution wasn't a problem.
>
> The ethernet controller works fine but the Wifi adapter not. It is a
> very strange situation because de wireless network adapter only catch
> the router signal if the laptop is situated at less than 1 meter from
> the router antenna.

This is not really a problem of the firmware, but rather of the
hardware.  Commit c18d8f5095715c56bb3cd9cba64242542632054b in the Linux
kernel tree gives an explanation:

,
| $ git show c18d8f5095715c56bb3cd9cba64242542632054b
| commit c18d8f5095715c56bb3cd9cba64242542632054b
| Author: Larry Finger 
| Date:   Wed Mar 16 13:33:34 2016 -0500
| 
| rtlwifi: rtl8723be: Add antenna select module parameter
| 
| A number of new laptops have been delivered with only a single antenna.
| In principle, this is OK; however, a problem arises when the on-board
| EEPROM is programmed to use the other antenna connection. The option
| of opening the computer and moving the connector is not always possible
| as it will void the warranty in some cases. In addition, this solution
| breaks the Windows driver when the box dual boots Linux and Windows.
| 
| A fix involving a new module parameter has been developed.  This commit
| adds the new parameter and implements the changes needed for the driver.
| 
| Signed-off-by: Larry Finger 
| Cc: Stable  [V4.0+]
| Signed-off-by: Kalle Valo 
`

With this commit (which went into Linux 4.7 and was subsequently
cherry-picked for the 4.x stable kernels), the rtl8723be module got a
new parameter ant_sel which you can set to 0 (the default), 1 or 2.

Recently I got myself a laptop with a RTL8723BE wireless adapter, and
with "modprobe rtl8723be ant_sel=1" the WiFi works perfectly, without
that parameter, "iwlist scan" would not report anything.

Cheers,
   Sven

Bug#836411: linux-image-4.7.0-1-amd64: hibernation fails, regression from 4.6

[Sven Joachim]

Package: src:linux
Version: 4.7.2-1
Severity: important

The other day I got myself a new (though not really shiny) laptop[1],
and while I managed to get most things working, hibernation (via
"systemctl hibernate") is broken in 4.7: the screen gets black, the fan
keeps being noisy, and there is no other sign of activity, so I had to
power-cycle the machine.

With the 4.6 kernel from testing, hibernation and resume works fine.


1. http://support.hp.com/at-de/document/c05187171


-- Package-specific info:
** Version:
Linux version 4.7.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 5.4.1 
20160803 (Debian 5.4.1-1) ) #1 SMP Debian 4.7.2-1 (2016-08-28)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.7.0-1-amd64 
root=UUID=54317940-5e45-4370-8f77-153d1b67ca31 ro quiet

** Not tainted

** Kernel log:
[3.740814] [TTM] Zone  kernel: Available graphics memory: 1739286 kiB
[3.740820] [TTM] Initializing pool allocator
[3.740830] [TTM] Initializing DMA pool allocator
[3.740878] [drm] radeon: 512M of VRAM memory ready
[3.740881] [drm] radeon: 2048M of GTT memory ready.
[3.740913] [drm] Loading mullins Microcode
[3.741804] radeon :00:01.0: firmware: direct-loading firmware 
radeon/mullins_pfp.bin
[3.742036] radeon :00:01.0: firmware: direct-loading firmware 
radeon/mullins_me.bin
[3.742171] input: HDA Digital PCBeep as 
/devices/pci:00/:00:14.2/sound/card1/input10
[3.742524] radeon :00:01.0: firmware: direct-loading firmware 
radeon/mullins_ce.bin
[3.742813] radeon :00:01.0: firmware: direct-loading firmware 
radeon/mullins_mec.bin
[3.743081] radeon :00:01.0: firmware: direct-loading firmware 
radeon/mullins_rlc.bin
[3.743608] input: HD-Audio Generic Mic as 
/devices/pci:00/:00:14.2/sound/card1/input12
[3.743764] input: HD-Audio Generic Headphone as 
/devices/pci:00/:00:14.2/sound/card1/input13
[3.745068] radeon :00:01.0: firmware: direct-loading firmware 
radeon/mullins_sdma.bin
[3.745086] [drm] Internal thermal controller without fan control
[3.746911] [drm] radeon: dpm initialized
[3.748104] kvm: disabled by bios
[3.748625] radeon :00:01.0: firmware: direct-loading firmware 
radeon/bonaire_uvd.bin
[3.748638] [drm] Found UVD firmware Version: 1.55 Family ID: 9
[3.749146] radeon :00:01.0: firmware: direct-loading firmware 
radeon/BONAIRE_vce.bin
[3.751247] [drm] Found VCE firmware/feedback version 40.2.2 / 15!
[3.751309] [drm] GART: num cpu pages 524288, num gpu pages 524288
[3.780829] rtl8723be: Using firmware rtlwifi/rtl8723befw.bin
[3.782931] rtl8723be :02:00.0: firmware: direct-loading firmware 
rtlwifi/rtl8723befw.bin
[3.792740] [drm] PCIE GART of 2048M enabled (table at 0x0030E000).
[3.792961] radeon :00:01.0: WB enabled
[3.792982] radeon :00:01.0: fence driver on ring 0 use gpu addr 
0x2c00 and cpu addr 0x8800ba528c00
[3.792987] radeon :00:01.0: fence driver on ring 1 use gpu addr 
0x2c04 and cpu addr 0x8800ba528c04
[3.792991] radeon :00:01.0: fence driver on ring 2 use gpu addr 
0x2c08 and cpu addr 0x8800ba528c08
[3.792996] radeon :00:01.0: fence driver on ring 3 use gpu addr 
0x2c0c and cpu addr 0x8800ba528c0c
[3.793000] radeon :00:01.0: fence driver on ring 4 use gpu addr 
0x2c10 and cpu addr 0x8800ba528c10
[3.793593] radeon :00:01.0: fence driver on ring 5 use gpu addr 
0x000782b0 and cpu addr 0xc9c382b0
[3.793804] radeon :00:01.0: fence driver on ring 6 use gpu addr 
0x2c18 and cpu addr 0x8800ba528c18
[3.793809] radeon :00:01.0: fence driver on ring 7 use gpu addr 
0x2c1c and cpu addr 0x8800ba528c1c
[3.793813] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[3.793815] [drm] Driver supports precise vblank timestamp query.
[3.793872] radeon :00:01.0: radeon: using MSI.
[3.793914] [drm] radeon: irq initialized.
[3.799567] kvm: disabled by bios
[3.802553] [drm] ring test on 0 succeeded in 2 usecs
[3.802685] [drm] ring test on 1 succeeded in 2 usecs
[3.802707] [drm] ring test on 2 succeeded in 2 usecs
[3.802934] [drm] ring test on 3 succeeded in 4 usecs
[3.802944] [drm] ring test on 4 succeeded in 4 usecs
[3.805280] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[3.806547] rtlwifi: rtlwifi: wireless switch is on
[3.828840] [drm] ring test on 5 succeeded in 1 usecs
[3.828870] [drm] UVD initialized successfully.
[3.879741] ACPI: Battery Slot [BAT1] (battery present)
[3.938151] [drm] ring test on 6 succeeded in 12 usecs
[3.938163] [drm] ring test on 7 succeeded in 2 usecs
[3.938166] [drm] VCE initialized successfully.
[3.940903] [drm] ib test on ring 0 succeeded in 0 usecs
[4.358593] systemd[1]: apt-daily.timer: Adding 4h 32min 19.906642s 

Bug#823637: firmware-nonfree: please add a firmware-nvidia-graphics package

[Sven Joachim]

Source: firmware-nonfree
Version: 20160110-1
Severity: wishlist

Starting with the Maxwell GM20x generation[1], NVidia graphics cards
require signed firmware for most operations, the Nouveau driver does not
provide acceleration without the firmware.

In February 2016, NVidia finally made the firmware available in the
linux-firmware git repository, and with Linux 4.6 and Mesa 11.2 (both
currently in experimental) users should be able to get acceptable
performance out of their expensive cards without having to resort to the
proprietary driver.


1. https://nouveau.freedesktop.org/wiki/CodeNames/#NV110

Bug#808916: linux-image-4.3.0-1-amd64: non-blocking stack trace crash during startup (drm/i915) in drm_atomic_check_only+0x46f/0x540

[Sven Joachim]

On 2015-12-24 12:48 +0100, Christophe wrote:

> Package: src:linux
> Version: 4.3.3-2
> Severity: normal
> Tags: upstream
>
> Dear Maintainer,
>
> Having just updated my Debian Testing to the 4.3 kernel from 3.16, I
> have noticed the stack trace below during boot, which does not seem to
> disturb further operation.

I noticed a very similar stacktrace myself with a self-compiled 4.3
kernel, but...

> It may be worth reporting upstream, or it may be already fixed as
> there's been changes in this part?

...they went away when I upgraded to 4.4-rc5, so it might be a
good idea for you to try a 4.4.0-rc6 kernel from experimental.

Cheers,
   Sven

Bug#661193: linux-tools-3.2: perf fails to annotate code with separate debug info under some conditions

[Sven Joachim]

Control: found -1 linux-tools/4.2-2
Control: tags -1 + fixed-upstream

On 2012-02-24 23:11 +0100, Sami Liedes wrote:

> Package: linux-tools-3.2
> Version: 3.2.1-2
> Severity: normal
>
> Hi!
>
> perf report does not show source code lines (annotation) for some
> binaries with separate debug information if those build-id's have been
> cached in perf's build-id cache. This is true for at least those
> packages whose debug symbols are installed in
> /usr/lib/debug/path/binary and not in
> /usr/lib/debug/.build-id/.../$hash. For example, e2fslibs, e2fsprogs
> and I believe very many others packages are affected by this (the
> mentioned packages even after fixing their -dbg packages per #661071).

This should be fixed in Linus' tree with commit
5baecbcd9c9a2f491afe1369fc22e7363f9c94d5[1], but I haven't tested it.

Cheers,
   Sven


1. 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5baecbcd9c9a2f491afe1369fc22e7363f9c94d5

Bug#781337: xserver-xorg-video-nouveau: Screen Hangs Displaying Black and White Rectangles After Resuming from Suspend

[Sven Joachim]

On 2015-04-08 18:25 +0200, Jean-Marc wrote:

 Sat, 28 Mar 2015 08:10:09 +0100
 Sven Joachim svenj...@gmx.de écrivait :

 hi Sven,

 Control: reassign -1 src:linux
 Control: merge 781359 -1
 
 I think this is the same problem as #781359, happening on very similar
 hardware (GeForce 8600M GT).
 

 Can I do something to help ?

Report it upstream, please see http://nouveau.freedesktop.org/wiki/Bugs/
for instructions.

Cheers,
   Sven


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87lhi27ce0@turtle.gmx.de

Re: Bug#781337: xserver-xorg-video-nouveau: Screen Hangs Displaying Black and White Rectangles After Resuming from Suspend

[Sven Joachim]

Control: reassign -1 src:linux
Control: merge 781359 -1

I think this is the same problem as #781359, happening on very similar
hardware (GeForce 8600M GT).


On 2015-03-27 19:17 +0100, Jean-Marc wrote:

 Package: xserver-xorg-video-nouveau
 Version: 1:1.0.11-1
 Severity: important

 Dear Maintainer,

 I get on a regular basis problems resuming from suspend.
 (sometimes very serious needing a hard reset).

 The problem is the following:
 Instead of resuming, the system partially hangs and the screen displays black 
 and white rectangles.

 Switching to the console is not always possible.

 If I can switch to it, I get messages repetitively flooding it:
 kernel: [ 2723.298937] nouveau E[  PGRAPH][:02:00.0] PGRAPH_VSTATUS0: 
 0x00145b4d CCACHE
 kernel: [ 2723.298939] nouveau E[  PGRAPH][:02:00.0] PGRAPH_VSTATUS1: 
 0x002d
 kernel: [ 2723.298941] nouveau E[  PGRAPH][:02:00.0] PGRAPH_VSTATUS2: 
 0x0034db40 ENG2D ROP
 kernel: [ 2725.298350] nouveau E[  PGRAPH][:02:00.0] PGRAPH TLB flush 
 idle timeout fail
 kernel: [ 2725.298355] nouveau E[  PGRAPH][:02:00.0] PGRAPH_STATUS  : 
 0x011fde03 BUSY DISPATCH VFETCH CCACHE_PREGEOM STRMOUT_VATTR_POSTGEOM VCLIP 
 TRAST CLIPID ZCULL ENG2D RMASK TPC_RAST TPC_PROP ROP

 If I can switch to the console, I can blindly type some commands to reboot.

 It worked like this since I upgrade to 3.14 kernel I think.

 I also noticed other people suffer the same problem solved by upgrading to 
 experimental kernel 3.19.

 See https://bugs.freedesktop.org/show_bug.cgi?id=89186.

 Apparently, the reportbug does its job very well.
 If you need more info, feel free to get in touch.

 Jean-Marc.


 -- Package-specific info:
 X server symlink status:
 
 lrwxrwxrwx 1 root root 13 May 19  2013 /etc/X11/X - /usr/bin/Xorg
 -rwxr-xr-x 1 root root 2401376 Feb 11 01:35 /usr/bin/Xorg

 VGA-compatible devices on PCI bus:
 --
 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation G84 [GeForce 
 8600 GT] [10de:0402] (rev a1)

 /etc/X11/xorg.conf does not exist.

 /etc/X11/xorg.conf.d does not exist.

 KMS configuration files:
 
 /etc/modprobe.d/radeon-kms.conf:
   options radeon modeset=1

 Kernel version (/proc/version):
 ---
 Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 
 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt7-1 (2015-03-01)

 Xorg X server log files on system:
 --
 -rw-r--r-- 1 root root  8851 Jun 12  2014 /var/log/Xorg.3.log
 -rw-r--r-- 1 root root  8851 Jun 12  2014 /var/log/Xorg.4.log
 -rw-r--r-- 1 root root  8851 Jun 12  2014 /var/log/Xorg.5.log
 -rw-r--r-- 1 root root 36984 Mar 10 17:49 /var/log/Xorg.2.log
 -rw-r--r-- 1 root root 36787 Mar 25 11:36 /var/log/Xorg.1.log
 -rw-r--r-- 1 root root 45354 Mar 27 18:46 /var/log/Xorg.0.log

 Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
 -
 [20.533] 
 X.Org X Server 1.16.4
 Release Date: 2014-12-20
 [20.533] X Protocol Version 11, Revision 0
 [20.533] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
 [20.533] Current Operating System: Linux Cunegonde 3.16.0-4-amd64 #1 SMP 
 Debian 3.16.7-ckt7-1 (2015-03-01) x86_64
 [20.533] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 
 root=UUID=f763cefc-7dc7-47b1-b9f4-4600778e0176 ro quiet
 [20.533] Build Date: 11 February 2015  12:32:02AM
 [20.533] xorg-server 2:1.16.4-1 (http://www.debian.org/support) 
 [20.533] Current version of pixman: 0.32.6
 [20.533]  Before reporting problems, check http://wiki.x.org
   to make sure that you have the latest version.
 [20.533] Markers: (--) probed, (**) from config file, (==) default 
 setting,
   (++) from command line, (!!) notice, (II) informational,
   (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
 [20.533] (==) Log file: /var/log/Xorg.0.log, Time: Fri Mar 27 18:06:06 
 2015
 [20.664] (==) Using system config directory /usr/share/X11/xorg.conf.d
 [20.895] (==) No Layout section.  Using the first Screen section.
 [20.895] (==) No screen section available. Using defaults.
 [20.895] (**) |--Screen Default Screen Section (0)
 [20.895] (**) |   |--Monitor default monitor
 [20.908] (==) No monitor specified for screen Default Screen Section.
   Using a default monitor configuration.
 [20.908] (==) Automatically adding devices
 [20.908] (==) Automatically enabling devices
 [20.908] (==) Automatically adding GPU devices
 [21.269] (WW) The directory /usr/share/fonts/X11/cyrillic does not 
 exist.
 [21.276]  Entry deleted from font path.
 [21.430] (==) FontPath set to:
   /usr/share/fonts/X11/misc,
   /usr/share/fonts/X11/100dpi/:unscaled,
   /usr/share/fonts/X11/75dpi/:unscaled,
   /usr/share/fonts/X11/Type1,
   

Re: Bug#740953: [xserver-xorg-video-nouveau]: No devices detected. (anymore)

[Sven Joachim]

Control: reassign -1 src:linux
Control: found -1 3.13~rc6-1~exp1
Control: fixed -1 3.17~rc5-1~exp1

On 2014-10-20 23:20 +0200, Viktor Malyarchuk wrote:

 Fixed in kernel 3.16.5 (unstable) and 3.17 (experimental).

 Relevant commit is:
 https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=7babfd7f066dae02c63d9ccac886419ccfb80cfd

Thanks!  Reassigning to the kernel then, will close the bug soon.

Cheers,
   Sven


 On Wed, Mar 26, 2014 at 5:27 PM, Sven Joachim svenj...@gmx.de wrote:

 On 2014-03-26 22:57 +0100, Viktor Malyarchuk wrote:

  On Sun, Mar 23, 2014 at 3:48 AM, Sven Joachim svenj...@gmx.de wrote:
 
  When the nouveau kernel module is loaded, any conflicting framebuffer
  drivers are (supposed to be) removed.  Check your dmesg if that is the
  case for you.

  Conflicting framebuffer drivers are different. Here are relevant dmesg
  lines:
 
 
  a) CONFIG_X86_SYSFB=y (dmesg.3.13-1-amd64 and Xorg.0.log.3.13-1-amd64 in
  attachment)
  ---
  [   10.591133] fb: conflicting fb hw usage nouveaufb vs simple - removing
  generic driver
  ...
  [   10.983470] nouveau  [ DRM] allocated 2560x1440 fb: 0x8, bo
  880265d15000
  [   11.01] nouveau :01:00.0: fb0: nouveaufb frame buffer device
  ---
 
  b) # CONFIG_X86_SYSFB is not set (dmesg.3.13.7+ and Xorg.0.log.3.13.7+ in
  attachment)
  ---
  [   11.666121] fb: conflicting fb hw usage nouveaufb vs EFI VGA -
 removing
  generic driver
  ...
  [   12.040732] nouveau  [ DRM] allocated 2560x1440 fb: 0x8, bo
  880262dc8400
  [   12.040790] fbcon: nouveaufb (fb0) is primary device
  [   12.121273] nouveau :01:00.0: fb0: nouveaufb frame buffer device
  ---

 That's how it is supposed to be in both cases, so we can rule that out.
 Now why X fails in the first case but not in the second, I don't know.

 I think you're best off reporting the bug upstream, please see
 http://nouveau.freedesktop.org/wiki/Bugs/ for instructions.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87sih2z03l@turtle.gmx.de

Bug#761182: xserver-xorg-video-nouveau: NV94: screen black after resume from S3

[Sven Joachim]

On 2014-11-11 10:00 +0100, Julien Cristau wrote:

 Control: reassign -1 src:linux 3.16.5-1
 Control: fixed -1 3.17-1~exp1
 Control: tag -1 upstream fixed-upstream
 Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=83550

 On Mon, Nov 10, 2014 at 23:34:56 -0500, Dennis Linnell wrote:

 I have been suffering similar symptoms. The problem occurs in all the 3.16
 kernels through 3.16.5-1, but not in any of the 3.14 kernels, most recently
 3.14.15-2.
 
 As suggested above, I tried the latest kernel, linux-image-3.17-1-686-pae
 (3.17-1~exp1) from experimental. That fixed the problem for me.
 
 This appears to be the relevant upstream bug report:
 
 https://www.libreoffice.org/bugzilla/show_bug.cgi?id=83550
 
 See the patch. It would be nice to see this problem fixed in the jessie 3.16
 kernel.
 
 That's commit 5838ae610ff36777b8fce6f353c2417980c1a1fa upstream.

Ben Skeggs sent this and other Nouveau related fixes for 3.16 to
sta...@vger.kernel.org three weeks ago, but they did not make it into
3.16.7, nor has the Ubuntu kernel team picked them up for 3.16.7-ckt1
yet. :-(  I have now reminded them to take these patches.

Cheers,
   Sven


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87lhnhplrt@turtle.gmx.de

Bug#762939: nfs-common: /etc/init.d/nfs-common starts #!/bin/bash

[Sven Joachim]

On 2014-09-26 14:50 +0200, John Hughes wrote:

 Package: nfs-common
 Version: 1:1.2.8-9
 Severity: wishlist

 Dear Maintainer,

 /etc/init.d/nfs-common starts #!/bin/bash, but doesn't seem to contain
 any bashisms.  It'd be nice to use /bin/sh.

The same applies to /etc/init.d/nfs-kernel-server.  I have changed both
scripts to run under /bin/sh in order to get a bash-free boot.

Cheers,
   Sven


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a95fu7da@turtle.gmx.de

Bug#757835: nfs-kernel-server: after update 1.2.8-6-1.2.8-8 rpc.mountd starts crashing

[Sven Joachim]

On 2014-08-12 20:23 +0200, Ben Hutchings wrote:

 On Tue, 2014-08-12 at 09:05 -0700, Steve Langasek wrote:
 [...]
 Matthias, could you please have a look at the below test case?  We have a
 regression in the latest nfs-kernel-server build, which appears to be caused
 by a gcc-4.9 bug.
 
 Should I work around this in nfs-utils, or is a quick fix possible in
 gcc-4.9?
 
  char buf[100];
  
  void
  add_name(char *old)
  {
 char *cp = old;
  
 while (cp  *cp) {
 cp++;
 }
 __builtin_strncpy(buf, old, cp-old);
 [...]

 So far as I know (haven't checked the latest standard), pointer
 subtraction has undefined behaviour unless both operands point into (or
 one beyond) the same array.  As this is not true of null pointers, the
 compiler may infer that old can't be null, so cp can't be null, so there
 is no need to check whether it is.

This is true in C, unfortunately.  However…

 I.e. this is a bug in nfs-utils, not the compiler.

…Petr's example program crashes even when compiled with g++-4.9, and in
C++ subtracting two null pointers is valid, yielding zero.

Cheers,
   Sven


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/874mxhmtbw@turtle.gmx.de

Bug#757835: nfs-kernel-server: after update 1.2.8-6-1.2.8-8 rpc.mountd starts crashing

[Sven Joachim]

Control: severity -1 grave

On 2014-08-11 20:04 +0200, Antti Järvinen wrote:

 Package: nfs-kernel-server
 Version: 1:1.2.8-8
 Severity: normal

 Dear Maintainer,

 Here is snippet from /var/log/messages of my nfs-server:
 Aug 11 20:54:05 muikku kernel: [12322.241131] 
 NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
 Aug 11 20:54:05 muikku kernel: [12322.241875] 
 NFSD: starting 90-second grace period (net c15dd380)
 Aug 11 20:54:14 muikku kernel: [12331.154343] rpc.mountd[12851]: segfault at 
 0 ip 0804ffb6 sp bfb01150 error 4 in rpc.mountd[8048000+19000]

 naturally shares fail to get mounted on client boxes.

Same here, and since this renders nfs-kernel-server pretty much useless,
I'm bumping the severity.

Cheers,
   Sven


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87y4uunauu@turtle.gmx.de

Bug#750360: systemd-sysv: breaks NFS root systems

[Sven Joachim]

On 2014-06-03 19:49 +0200, maximilian attems wrote:

 Hello Michael!

 On Tue, Jun 03, 2014 at 06:19:23PM +0200, Michael Biebl wrote:
 
 On Tue, Jun 03, 2014 at 11:36:25AM +0200, maximilian attems wrote:
  in any case, did you test it with klibc chroot too?
  meaning disabling BUSYBOX for the initramfs.
 
 I quickly tested /usr/lib/klibc/bin/chroot, and that worked fine.
 So if the udeb versions aren't fundametally different, that should work.
 

 thank you very much, pushed out to initramfs repo:
 http://anonscm.debian.org/gitweb/?p=kernel/initramfs-tools.git

 will upload soonish.

Is this test going to work for systems with a separate /usr ?

,
| $ which test
| /usr/bin/test
`

Cheers,
   Sven


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87lhtdrhuj@turtle.gmx.de

Bug#750360: systemd-sysv: breaks NFS root systems

[Sven Joachim]

On 2014-06-03 21:30 +0200, maximilian attems wrote:

 On Tue, Jun 03, 2014 at 08:03:16PM +0200, Sven Joachim wrote:
 
 Is this test going to work for systems with a separate /usr ?
 
 ,
 | $ which test
 | /usr/bin/test
 `
 

 dash or bash or POSIX shells have builtin test too.
 so yes it should just work.

The code which which you committed does not seem to invoke /bin/sh, and
you can't run shell builtins that way:

,
| # LC_ALL=C chroot /var/cache/pbuilder/build/4383/ cd /tmp
| chroot: failed to run command 'cd': No such file or directory
`

I guess the following should work (untested):

--8---cut here---start-8---
diff --git a/scripts/nfs b/scripts/nfs
index 967e67f..3b7ade2 100644
--- a/scripts/nfs
+++ b/scripts/nfs
@@ -67,7 +67,7 @@ mountroot()
# loop until nfsmount succeeds
do_nfsmount
while [ ${retry_nr} -lt ${delay} ] \
-! chroot ${rootmnt} test -x ${init} ; do
+! chroot ${rootmnt} /bin/sh -c test -x ${init} ; do
[ $quiet != y ]  log_begin_msg Retrying nfs mount
/bin/sleep 1
do_nfsmount
--8---cut here---end---8---

Cheers,
   Sven


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a99trbxs@turtle.gmx.de

Bug#729707: reassigning

[Sven Joachim]

On 2013-12-17 11:39 +0100, Holger Levsen wrote:

 control: reassign -1 xserver-xorg-video-nouveau
 thanks

First you reassigned it to src:linux which seems to at least somewhat
reasonable to me…

 This is a wild guess. Please support cleaning up bugs against the base 
 system. 
 This is clearly no base bug... Thanks.

And it's clearly no bug in xserver-xorg-video-nouveau either.  Please
reassign it back to the kernel where it probably belongs.

TIA,
Sven


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sitrwun5@turtle.gmx.de

Bug#721115: linux-base: Depends on libuuid-perl then perlapi-5.14.2, however perlapi-5.14.2 was removed in perl (5.18.1-2)

[Sven Joachim]

On 2013-08-28 11:49 +0200, Ben Hutchings wrote:

 On Wed, 2013-08-28 at 14:28 +0800, Steven Shiau wrote:
 Package: linux-base
 Version: 3.5
 Severity: normal
 
 Dear Maintainer,
 linux-base depends on libuuid-perl then perlapi-5.14.2, however
 perlapi was removed in perl (5.18.1-2). This will cause the running
 linux-image package to be removed.

 It looks like linux-base needs to be re-uploaded (it's arch:all, so
 binNMUs won't help).

No, why should it?

 http://release.debian.org/transitions/html/perl5.18.html apparently only
 covers dependencies on 'perl' not 'perlapi-5.14.2' so it seems to be
 understating the size of this transition.

 Does this make sense?

Not to me, linux-base does not depend on perl nor perl-api-5.14.2.  All
that's needed is a rebuild of libuuid-perl against the newer perl, and
libuuid-perl is listed on the above page.

Cheers,
   Sven


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87haeaxgsq@turtle.gmx.de

Bug#707589: nfs-kernel-server: NFSv3 is broken with libc-bin 2.17

[Sven Joachim]

Package: nfs-kernel-server
Version: 1:1.2.6-3
Severity: important

I have just spent half an hour trying to find out why my NFS mounts had
stopped working.  It turns out that the init script tries to run
/usr/bin/rpcinfo:

,
|   $PREFIX/bin/rpcinfo -u localhost nfs 3 /dev/null 21 ||
|   RPCMOUNTDOPTS=$RPCMOUNTDOPTS --no-nfs-version 3
`

Alas, libc-bin as of version 2.17-1 no longer ships /usr/bin/rpcinfo,
which seems to make sense given that rpcbind provides /usr/sbin/rpcinfo.
The net effect is that --no-nfs-version 3 gets added to rpc.mountd's
options, breaking NFSv3 mounts.


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 3.8.12-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages nfs-kernel-server depends on:
ii  libblkid1   2.20.1-5.3
ii  libc6   2.17-1
ii  libtirpc1   0.2.2-5
ii  libwrap07.6.q-24
ii  lsb-base4.1+Debian9
ii  nfs-common  1:1.2.6-3
ii  ucf 3.0025+nmu3

nfs-kernel-server recommends no packages.

nfs-kernel-server suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d2t0p26v@turtle.gmx.de

Re: Bug#703291: [xserver-xorg-video-nouveau] Dual display problem: Using xrandr to setup dual displays causes X to hang

[Sven Joachim]

Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=63048
Control: reassign -1 src:linux
Control: found -1 3.2.39-1
Control: affects -1 xserver-xorg-video-nouveau

On 2013-04-03 01:06 +0200, Guy Heatley wrote:

 I have raised this issue as a bug on freedesktop.org
 The bug number is 63048

 https://bugs.freedesktop.org/show_bug.cgi?id=63048

Thanks, marking as forwarded accordingly (and reassigning to the
kernel).

Cheers,
   Sven


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871uarziq2@turtle.gmx.de

Re: Bug#703291: [xserver-xorg-video-nouveau] Dual display problem: Using xrandr to setup dual displays causes X to hang

[Sven Joachim]

On 2013-03-18 22:44 +0100, Guy Heatley wrote:

 Sven - I can confirm that your downgrading suggestion fixes this problem.

 On 18/03/13 17:03, Sven Joachim wrote:
 Kernel folks, this appears to be a regression resulting from the
 DRM 3.4 backport.

 Can you confirm that downgrading linux-image-3.2.0-4-amd64 to
 3.2.35-2 (available on snapshots.debian.org[1]) fixes the problem?

 Yes, this fixes it.

Could you please try a 3.8 kernel from experimental (requires
initramfs-tools from experimental as well)?  If the problem persists,
file a bug on https://bugs.freedesktop.org/.  Choose product xorg,
component Driver/nouveau, and let us know the bug number.

Cheers,
   Sven


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874ng7ji0y@turtle.gmx.de

Re: Bug#703291: [xserver-xorg-video-nouveau] Dual display problem: Using xrandr to setup dual displays causes X to hang

[Sven Joachim]

Kernel folks, this appears to be a regression resulting from the DRM 3.4
backport.

On 2013-03-18 02:05 +0100, Guy Heatley wrote:

 Package: xserver-xorg-video-nouveau
 Version: 1:1.0.1-5
 Severity: important

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

 Since upgrading my (Wheezy) desktop machine a couple of days ago with
 APT, my dual-display setup has stopped working.

I assume that the last upgrade was less than half a year ago?  If so,
it's almost certainly a problem with the latest kernel.

 I run an xrandr script as I login to set up my twin displays:

 # 1280x1024 59.89 Hz (CVT 1.31M4) hsync: 63.67 kHz; pclk: 109.00 MHz
 xrandr --newmode 1280x1024_60.00  109.00  1280 1368 1496 1712  1024
 1027 1034 1063 -hsync +vsync
 xrandr --addmode DVI-I-1 1280x1024_60.00
 xrandr --output VGA-1 --primary --gamma 1.2:1.2:1.05 --brightness 0.95
 --dpi 96
 xrandr --output DVI-I-1 --mode 1280x1024_60.00 --right-of VGA-1
 --gamma 0.75:0.9:0.9 --brightness 0.9 --dpi 96

 Running this script in Gnome or XFCE now causes X to immediately hang,
 and requires I log in to the machine via SSH and reboot it.

 In fluxbox or KDE the script simply doesn't work (but no hang ... well
 fluxbox hangs X when I log out)

 Concerning my secondary display (the one called DVI-I-1 in the
 script): the graphics card has never been able to poll any monitor
 attached for any EDID information (I suspect the DVI-A to SVGA adapter
 I use is not fully wired?). Anyway, I boot with the
 drm_kms_helper.poll=0 in my grub.cfg to prevent constant futile polling.
 I don't know if this has any bearing?

Remove that parameter to find out.

 Thanks for any advice.

Can you confirm that downgrading linux-image-3.2.0-4-amd64 to 3.2.35-2
(available on snapshots.debian.org[1]) fixes the problem?

Cheers,
   Sven


1. 
http://snapshot.debian.org/package/linux/3.2.35-2/#linux-image-3.2.0-4-amd64_3.2.35-2


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8738vsej3t@turtle.gmx.de

Re: Bug#698107: installation-reports: Linux nvidia graphics regression

[Sven Joachim]

Control: reassign -1 src: linux
Control: retitle -1 nouveau: hangs on GeForce GT 630

Kernel team: just another bug report from a user with a Fermi card who
found the Wheezy kernel unusable.

On 2013-01-14 08:14 +0100, Bob Proulx wrote:

 Package: installation-reports
 Severity: important

 Machine: MSI 970A-G46 with GeForce GT 630

 Installing using the latest Wheezy 7.0 Beta4 installer resulted in a
 hung system after installation.  The pre-boot install went okay.  But
 after the initial reboot the system was left with the following on the
 screen (manually transcribed):

   Loading, please wait...
   INIT: version 2.88 booting
   Using makefile-style concurrent boot in runlevel S.
   Starting hotplug events dispatcher: udevd.
   Synthesizing the initial hotplug events...done.
   Waiting for /dev to be fully populated...[   5.270835] SP5100 TCO timer: 
 mmio address 0xbafe00 already in use
   [   5.697252] [drm] nouveau :01:00.0: unknown i2c port 51
   [   5.74] [drm] nouveau :01:00.0: unknown i2c port 48
   [   5.74] [drm] nouveau :01:00.0: unknown i2c port 48
   [   5.79] [drm] nouveau :01:00.0: unknown i2c port 57
   [   5.52] [drm] nouveau :01:00.0: unknown i2c port 59

 And then it hangs.  Nothing I can do will reboot it other than power
 cycling it.

 This problem seems similar but different from
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696571 due to being
 completely different hardware and different symptoms.  But it is in
 the same area.  If it is the same then feel free to merge.  If
 different I thought it would be easier to have this in a separate
 report.

It's totally different from #696571, but it could be related to #694734.

Bob, could you please test Julien Cristau's kernel from [1] and follow
up on bug #687442?  See the logs of that bug for details.


1. 
http://people.debian.org/~jcristau/linux-image-3.2.0-4.drm-amd64_3.2.35-3~jcristau.1_amd64.deb
 


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txqiz3sb@turtle.gmx.de

Bug#698107: installation-reports: Linux nvidia graphics regression

[Sven Joachim]

On 2013-01-15 19:42 +0100, Sven Joachim wrote:

 It's totally different from #696571, but it could be related to #694734.

Sorry, I rather meant #690586/#690284, namely these symptoms:

   [   5.697252] [drm] nouveau :01:00.0: unknown i2c port 51
   [   5.74] [drm] nouveau :01:00.0: unknown i2c port 48
   [   5.74] [drm] nouveau :01:00.0: unknown i2c port 48
   [   5.79] [drm] nouveau :01:00.0: unknown i2c port 57
   [   5.52] [drm] nouveau :01:00.0: unknown i2c port 59

 And then it hangs.  Nothing I can do will reboot it other than power
 cycling it.

Cheers,
   Sven


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ip6yz36m@turtle.gmx.de

Bug#694734: adjusting severity

[Sven Joachim]

On 2012-12-05 01:12 +0100, Ben Hutchings wrote:

 Could you try Julien Cristau's kernel package that uses 3.4 DRM drivers?
 This is a possible solution for wheezy's current poor or missing support
 for some recent GPUs.

Works fine with my GeForce 8500 GT, I don't have any more recent GPU to
test.

 Quoting from #687442:
 New image is up at
 http://people.debian.org/~jcristau/linux-image-3.2.0-4.drm-amd64_3.2.34-1~jcristau.1_amd64.deb
 
 sha1sum is 1bbb6e4590e4f000739af89f3090ffc6bb9cb409.
 diff against svn at
 http://people.debian.org/~jcristau/3.2.34-1~jcristau.1.diff

Cheers,
   Sven


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zk1s1ku7@turtle.gmx.de

Re: Bug#694734: adjusting severity

[Sven Joachim]

Control: reassign -1 src:linux
Control: found -1 3.2.23-1
Control: fixed -1 3.6.4-1~experimental.1
Control: retitle -1 nouveau: black screen with GeForce GTX 560

On 2012-11-29 18:49 +0100, Sven Joachim wrote:

 On 2012-11-29 18:38 +0100, Javier Domingo wrote:

 I can't now at the moment access to the computer, but I can attach
 what I sent there, the dmesg output and the Xorg.0.log output.

 I must say that with kernel 3.2 the computer doesn't boot, or at least
 it tells me about non-recognised ports and screen gets freezed. As
 that is during kernel load (sec 8), I suppose the problem is that it
 just doesn't have card info.

 No, probably not.  But the problem has been reported in Ubuntu 12.04 as
 well, they also use the 3.2 kernel:
 https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/952574.

Reassigning to the kernel and marking the bug as fixed in 3.6.

I begin to wonder if there are _any_ Fermi cards that work with Wheezy's
kernel. :-/

Cheers,
   Sven 


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877goxd1if@turtle.gmx.de

Bug#690586: Seems to be the same as #690284

[Sven Joachim]

Control: merge 690284 -1

It seems to me that #690284 and #690586 are the same problem, so I'm
taking the liberty to merge these bugs.

Cheers,
   Sven


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r4ncffka@turtle.gmx.de

Re: Bug#690586: installation-reports: NVIDIA GF108 [Quadro 1000M] 10de:0dfa (rev a1) X fails with nouveau/linux-3.2

[Sven Joachim]

Control: severity -1 important
Control: reassign -1 src:linux
Control: found -1 3.2.23-1
Control: fixed -1 3.3-1~experimental.1

Am 20.11.2012 um 19:29 schrieb Andreas B. Mundt:

 On Tue, Nov 20, 2012 at 05:57:27PM +0100, Sven Joachim wrote:
 [...]
 Could you please try a 3.3 kernel from snapshot.debian.org¹?  There were
 various i2c related nouveau commits in that version, so maybe it would
 be sufficient to backport them.

 ¹
 http://snapshot.debian.org/archive/debian/20120322T225438Z/pool/main/l/linux-2.6/linux-image-3.3.0-trunk-amd64_3.3-1%7Eexperimental.1_amd64.deb

 This kernel works fine without any special handling, just installing
 and rebooting is sufficient.

 $ uname -a
 Linux lmz 3.3.0-trunk-amd64 #1 SMP Thu Mar 22 18:02:10 UTC 2012 x86_64
 GNU/Linux

Thank you.  I'm reassigning the bug to the Linux kernel and hopefully
mark it as fixed in 3.3 and later.

Now the question is which commits would need to be backported to the
wheezy kernel.  Some candidates:

,
| $ git log --grep=nouveau.*i2c --pretty=oneline v3.2..v3.3
| 525895ba388c949aa906f26e3ec5cb1ab041f56b drm/nouveau/gem: fix fence_sync race 
/ oops
| 5d56fe5fd794a98c4f446f8665fd06b82e93ff64 Merge branch 'drm-nouveau-next' of 
git://anongit.freedeskto
| f553b79c03f0dbd52f6f03abe8233a2bef8cbd0d drm/nouveau/i2c: handle bit-banging 
ourselves
| 9e3b6b99075a01ce47379eee74365aece14242f3 drm/nouveau/i2c: fix debug message
| 2bdb06e3cff066c546fb41152bc582a5ec73e899 drm/nouveau/i2c: tidy up bit-bang 
helpers, also fixing nv50
| 486a45c2a6c19b159602d044ab601a92cd81f524 drm/nouveau/i2c: do parsing of 
i2c-related vbios info in no
| 0f8067c7054d22f240fca376e01430eecdc112df drm/nouveau/bios: fold 
fixup_legacy_i2c
`

But that's beyond my skills :-(, so I'm passing the ball to the Debian
kernel team.

Cheers,
   Sven


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mwyc5c73@turtle.gmx.de

nouveau: severe display corruption on NV4E on machines with 2G RAM

[Sven Joachim]

Control: reassign -1 src:linux
Control: affects -1 xserver-xorg-video-nouveau
Control: retitle -1 nouveau: NV4E acceleration corruption when DMA above 31-bit 
(2 Gig barrier) 
Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=46557

For those who don't want to read the whole bug log: this bug is about
severe display corruption for those cursed with an Nvidia NV4E
(GeForce 6100/6150) graphics chip under two conditions:

- The machine has more than 2 Gigabyte RAM.
- A 64-bit kernel is used.

In this case, the machine is unusable with nouveau unless memory is
restricted to 2 Gigabyte (mem=2G) or acceleration is disabled
(nouveau.noaccel=1).  For details, see the upstream bug on
https://bugs.freedesktop.org/show_bug.cgi?id=46557.

Cheers,
   Sven


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87625k80ft@turtle.gmx.de

Bug#684240: [wheezy] lenovo t61 laptop fails to shutdown

[Sven Joachim]

On 2012-10-11 02:04 +0200, Jonathan Nieder wrote:

 Luis Mochan wrote:

 [   297.964] (II) [drm] DRM interface version 1.4
 [   297.964] (II) [drm] DRM open master succeeded.
 [   297.964] (--) NOUVEAU(0): Chipset: NVIDIA NV86

 Sven has the same chipset, I think.  It was supposed to work well at
 least in the past.

I had some problems now and then, but currently it works fine.  However,
it's a desktop card, not a laptop.

 [...]
 [   299.012] (II) NOUVEAU(0): Output LVDS-1 disconnected
 [   299.012] (II) NOUVEAU(0): Output VGA-1 disconnected
 [   299.012] (II) NOUVEAU(0): Output DVI-D-1 disconnected
 [   299.012] (WW) NOUVEAU(0): Unable to find connected outputs - setting 
 1024x768 initial framebuffer

That looks really bad.

 [3.012903] uvesafb: NVIDIA Corporation, G86 Board - NV_NB8M , Chip Rev   
 , OEM: NVIDIA, VBE v3.0

 Not sure why uvesafb is claiming the display instead of nouveaufb.  It
 also could be interesting to try blacklisting uvesafb.

I think uvesafb is only loaded if you force it to (e.g. with the
video=uvesafb kernel parameter), and it's not even included in the
initramfs by default.

The Nouveau wiki¹ claims that handover from uvesafb to nouveaufb does not
work, but maybe this information is outdated.

Cheers,
   Sven


¹ http://nouveau.freedesktop.org/wiki/KernelModeSetting


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pq42qt9d@turtle.gmx.de

Bug#689178: No support for modern nVidia cards (GT 610) - System unusable!

[Sven Joachim]

On 2012-10-01 14:30 +0200, Jonathan Nieder wrote:

 Kees de Jong wrote:

 I was able to recreate the error by reverting back to the Nouveau
 driver. It still crashes with the 3.2.0-3-amd64 kernel, but it works
 with the 3.5-trunk-amd64 kernel. Although I'm only able to use the
 'fall-back' mode of Gnome 3.

 Nice.  What happens if you boot with the parameter nouveau.noaccel=0
 appended to the kernel command line?

 I'd also be interested in full dmesg output (as an attachment) from
 booting the 3.5.y kernel and starting X with drm.debug=0xe and
 log_buf_len=16M parameters appended to the kernel command line
 (without noaccel=0).

 By the way, looks like I was confused before --- your card is an nvd9,
 not nve0.

And that's the reason for the missing acceleration, there is still no
working free microcode for NVD9. :-(  Search for case 0xd9: in
drivers/gpu/drm/nouveau/nouveau_state.c.

It is possible to extract firmware from the blob, but the procedure is
rather complicated¹.

Cheers,
   Sven


¹ http://nouveau.freedesktop.org/wiki/NVC0_Firmware


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87a9w6p5e4@turtle.gmx.de

Re: Bug#679252: bugs intended for linux being filed against src

[Sven Joachim]

On 2012-07-25 13:30 +0200, Touko Korpela wrote:

 On Wed, Jun 27, 2012 at 02:39:29PM +0100, Ben Hutchings wrote:
 On Wed, 2012-06-27 at 07:56 -0500, Jonathan Nieder wrote:
  Source: linux
  Version: 3.2.20-1
  
  Hi kernel maintainers,
  
  Gergely Nagy wrote:
  
   reassign 679226 src:linux-2.6 3.2.20-1
  
  Several bugs seem to have been filed against the nonexistent 'src'
  package recently.  I am guessing this means reportbug or some related
  tool does not know how to deal with 'src:linux' as a package name.
  Please use plain 'linux' for now.
 
 reportbug-ng is doing this.  Let's get it fixed.

 Recent bugs reported against 'src' have X-Mailer: reportbug 6.4
 Looks like reportbug is buggy too.

This seems to be a side effect of the fix for #666469, FWIW.

Cheers,
   Sven


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87394gf44j@turtle.gmx.de

Bug#679566: backport nouveau features from 3.4

[Sven Joachim]

severity 679566 serious
thanks

On 2012-06-29 21:51 +0200, Sven Joachim wrote:

 Package: linux
 Version: 3.2.21-3
 Tags: patch

 Turning this feature request into a bug report.  Note that it blocks
 #679557 which I have just filed at RC severity.

Ping?  Note that while #679557 may seem to only affect unstable, we
really need this version of xserver-xorg-video-nouveau to go into wheezy
unless somebody comes up with a fix for #666468 -- and I don't expect
that to happen anytime soon.

Hence, upgrading the severity of this bug report to the same as #679557.

Cheers,
   Sven

 On 2012-06-16 14:16 +0200, Sven Joachim wrote:

 On 2012-06-04 20:42 +0200, Julien Cristau wrote:
 
 We'll probably also need some nouveau updates to (at least) update to
 the 1.0.0 ABI,

 See commit ace77b6b1304 in xserver-xorg-video-nouveau for the reason:

 commit ace77b6b1304826f4004bde23809b55d476b0615
 Author: Ben Skeggs bske...@redhat.com
 Date:   Tue May 29 21:21:57 2012 +1000

 disable fermi accel on 0.0.16 interface
 
 Kepler accel support broke some assumption made by the older kernel
 interface, and Fermi shares the same code.  It can't work (without
 some annoying hacks anyway) with the 0.0.16 kernel anymore.

 diff --git a/src/nv_dma.c b/src/nv_dma.c
 index 3b75ca9..1757f4d 100644
 --- a/src/nv_dma.c
 +++ b/src/nv_dma.c
 @@ -36,6 +36,12 @@ NVInitDma(ScrnInfoPtr pScrn)
  int size, ret;
  void *data;
  
 +if (pNv-dev-drm_version  0x0100  pNv-dev-chipset = 0xc0) {
 +xf86DrvMsg(pScrn-scrnIndex, X_ERROR,
 +   Fermi acceleration not supported on old kernel\n);
 +return FALSE;
 +}
 +
  if (pNv-Architecture  NV_ARCH_C0) {
  data = nv04_data;
  size = sizeof(nv04_data);

 I haven't had time to look at this at all, but I think
 Maarten had a backport at
 http://people.canonical.com/~mlankhorst/drm-abi-patches.tgz

 Note that this is actually an uncompressed tar archive.

 Attached is a compressed version of it.



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878veq8gzv@turtle.gmx.de

Bug#679566: backport nouveau features from 3.4

[Sven Joachim]

Package: linux
Version: 3.2.21-3
Tags: patch

Turning this feature request into a bug report.  Note that it blocks
#679557 which I have just filed at RC severity.

On 2012-06-16 14:16 +0200, Sven Joachim wrote:

 On 2012-06-04 20:42 +0200, Julien Cristau wrote:
 
 We'll probably also need some nouveau updates to (at least) update to
 the 1.0.0 ABI,

 See commit ace77b6b1304 in xserver-xorg-video-nouveau for the reason:

 commit ace77b6b1304826f4004bde23809b55d476b0615
 Author: Ben Skeggs bske...@redhat.com
 Date:   Tue May 29 21:21:57 2012 +1000

 disable fermi accel on 0.0.16 interface
 
 Kepler accel support broke some assumption made by the older kernel
 interface, and Fermi shares the same code.  It can't work (without
 some annoying hacks anyway) with the 0.0.16 kernel anymore.

 diff --git a/src/nv_dma.c b/src/nv_dma.c
 index 3b75ca9..1757f4d 100644
 --- a/src/nv_dma.c
 +++ b/src/nv_dma.c
 @@ -36,6 +36,12 @@ NVInitDma(ScrnInfoPtr pScrn)
   int size, ret;
   void *data;
  
 + if (pNv-dev-drm_version  0x0100  pNv-dev-chipset = 0xc0) {
 + xf86DrvMsg(pScrn-scrnIndex, X_ERROR,
 +Fermi acceleration not supported on old kernel\n);
 + return FALSE;
 + }
 +
   if (pNv-Architecture  NV_ARCH_C0) {
   data = nv04_data;
   size = sizeof(nv04_data);

 I haven't had time to look at this at all, but I think
 Maarten had a backport at
 http://people.canonical.com/~mlankhorst/drm-abi-patches.tgz

 Note that this is actually an uncompressed tar archive.

Attached is a compressed version of it.

Cheers,
   Sven




drm-abi-patches.tar.gz
Description: Binary data

Re: Linux features for wheezy

[Sven Joachim]

On 2012-06-26 21:23 +0200, Sven Joachim wrote:

 On 2012-06-04 20:42 +0200, Julien Cristau wrote:

 We'll probably also need some nouveau updates to (at least) update to
 the 1.0.0 ABI, I haven't had time to look at this at all, but I think
 Maarten had a backport at
 http://people.canonical.com/~mlankhorst/drm-abi-patches.tgz but doesn't
 have the hw to test them.

 We may have a volunteer now (Michele, CC'ed), but the patchset does not
 cleanly apply to the 3.2.21 kernel:

 ,
 | $ tar xf ../drm-abi-patches.tgz -O | patch -Np1 --dry-run 
 | [...]
 `

Scrap that please, this is not the right way to apply the patches.  The
following commands should actually work (assuming you're on sid and have
the latest 3.2 kernel installed):

sudo apt-get install linux-source-3.2
tar xf /usr/src/linux-source-3.2.tar.bz2
wget http://people.canonical.com/~mlankhorst/drm-abi-patches.tgz
cd linux-source-3.2
tar xf ../drm-abi-patches.tgz
for patch in patches/*; do patch -Np1 -i $patch;done
cp /boot/config-3.2.0-3-amd64 .config
make deb-pkg

Then there should be a linux-image-3.2.21-something.deb in the parent
directory that you can install with dpkg.  Michele, could you do that?

Cheers,
   Sven


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lij7ijru@turtle.gmx.de

Re: Linux features for wheezy

[Sven Joachim]

On 2012-06-28 16:38 +0200, Sven Joachim wrote:

 Scrap that please, this is not the right way to apply the patches.  The
 following commands should actually work (assuming you're on sid and have
 the latest 3.2 kernel installed):

 sudo apt-get install linux-source-3.2
 tar xf /usr/src/linux-source-3.2.tar.bz2
 wget http://people.canonical.com/~mlankhorst/drm-abi-patches.tgz
 cd linux-source-3.2
 tar xf ../drm-abi-patches.tgz
 for patch in patches/*; do patch -Np1 -i $patch;done
 cp /boot/config-3.2.0-3-amd64 .config
 make deb-pkg

Michele replied in private mail that the patched kernel works fine with
3D acceleration.

Cheers,
   Sven


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vf7i822@turtle.gmx.de

Re: Linux features for wheezy

[Sven Joachim]

On 2012-06-04 20:42 +0200, Julien Cristau wrote:

 We'll probably also need some nouveau updates to (at least) update to
 the 1.0.0 ABI, I haven't had time to look at this at all, but I think
 Maarten had a backport at
 http://people.canonical.com/~mlankhorst/drm-abi-patches.tgz but doesn't
 have the hw to test them.

We may have a volunteer now (Michele, CC'ed), but the patchset does not
cleanly apply to the 3.2.21 kernel:

,
| $ tar xf ../drm-abi-patches.tgz -O | patch -Np1 --dry-run 
| patching file drivers/gpu/drm/nouveau/nouveau_drv.h
| patching file drivers/gpu/drm/nouveau/nvd0_display.c
| patching file drivers/gpu/drm/nouveau/nouveau_drv.h
| Hunk #1 succeeded at 292 (offset 2 lines).
| patching file drivers/gpu/drm/nouveau/nouveau_channel.c
| Hunk #1 succeeded at 425 (offset -9 lines).
| patching file drivers/gpu/drm/nouveau/nouveau_dma.h
| patching file drivers/gpu/drm/nouveau/nouveau_channel.c
| patching file drivers/gpu/drm/nouveau/nouveau_dma.c
| patching file drivers/gpu/drm/nouveau/nouveau_drv.h
| Hunk #1 succeeded at 1032 (offset 2 lines).
| patching file drivers/gpu/drm/nouveau/nouveau_state.c
| patching file drivers/gpu/drm/nouveau/nouveau_display.c
| patching file drivers/gpu/drm/nouveau/nouveau_drv.h
| Hunk #1 FAILED at 1672.
| 1 out of 1 hunk FAILED -- saving rejects to file 
drivers/gpu/drm/nouveau/nouveau_drv.h.rej
| patching file drivers/gpu/drm/nouveau/nvc0_fifo.c
| patching file drivers/gpu/drm/nouveau/nvc0_graph.c
| patching file drivers/gpu/drm/nouveau/nouveau_fence.c
| patching file drivers/gpu/drm/nouveau/nouveau_drv.h
| Hunk #1 succeeded at 1662 (offset 2 lines).
| patching file drivers/gpu/drm/nouveau/nouveau_fence.c
| patching file drivers/gpu/drm/nouveau/nv50_display.c
| patching file drivers/gpu/drm/nouveau/nouveau_bo.c
| patching file drivers/gpu/drm/nouveau/nouveau_drv.h
| patching file drivers/gpu/drm/nouveau/nouveau_gem.c
`

Maarten, could you rebase the patches?

Cheers,
   Sven


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vcidg9mp@turtle.gmx.de

Re: Linux features for wheezy

[Sven Joachim]

On 2012-06-04 20:42 +0200, Julien Cristau wrote:

 On Sat, Jun  2, 2012 at 23:47:03 +0100, Ben Hutchings wrote:

 Some hardware support; this can still be done after the freeze but the
 sooner the better:
 
 - [armhf] omapdrm driver
 - [x86] gma500 support for new chips
 - [x86] i915 improvements in Ivy Bridge support
 - radeon support for new chips
 - NVMe driver
 - tg3 support for 57766 chip
 - ipheth support for iPhone 4S
 - DRM/KMS driver for DisplayLink
 - qmi_wwan driver (#670241)
 
 We'll probably also need some nouveau updates to (at least) update to
 the 1.0.0 ABI,

See commit ace77b6b1304 in xserver-xorg-video-nouveau for the reason:

--8---cut here---start-8---
commit ace77b6b1304826f4004bde23809b55d476b0615
Author: Ben Skeggs bske...@redhat.com
Date:   Tue May 29 21:21:57 2012 +1000

disable fermi accel on 0.0.16 interface

Kepler accel support broke some assumption made by the older kernel
interface, and Fermi shares the same code.  It can't work (without
some annoying hacks anyway) with the 0.0.16 kernel anymore.

diff --git a/src/nv_dma.c b/src/nv_dma.c
index 3b75ca9..1757f4d 100644
--- a/src/nv_dma.c
+++ b/src/nv_dma.c
@@ -36,6 +36,12 @@ NVInitDma(ScrnInfoPtr pScrn)
int size, ret;
void *data;
 
+   if (pNv-dev-drm_version  0x0100  pNv-dev-chipset = 0xc0) {
+   xf86DrvMsg(pScrn-scrnIndex, X_ERROR,
+  Fermi acceleration not supported on old kernel\n);
+   return FALSE;
+   }
+
if (pNv-Architecture  NV_ARCH_C0) {
data = nv04_data;
size = sizeof(nv04_data);
--8---cut here---end---8---

 I haven't had time to look at this at all, but I think
 Maarten had a backport at
 http://people.canonical.com/~mlankhorst/drm-abi-patches.tgz

Note that this is actually an uncompressed tar archive.

I wonder what happens if, during the wheezy+1 release cycle, the Nouveau
DDX or the mesa driver starts depending on other features present in
Linux 3.4 but not in Maarten's patchset.

 but doesn't have the hw to test them.

We need someone with a Fermi card that is supported (i.e. there is
working microcode) by Linux 3.2.

Should we upload xserver-xorg-video-nouveau to unstable and wait for
complaints?  The version in sid is unusable anyway[1] :-/, so breaking
acceleration for some users might not be such a big deal.

Cheers,
   Sven


1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675161


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aa03bgep@turtle.gmx.de

Bug#580525: beep: Unknown cmd messages in syslog

[Sven Joachim]

On 2012-03-07 15:36 +0100, Jonathan Nieder wrote:

 On 2012-03-03 23:33 +0100, Sven Joachim wrote:
 On 2010-05-06 17:39 +0200, Sven Joachim wrote:

 I get a message like the following in syslog whenever I run beep:

 May 6 17:04:58 turtle kernel: ioctl32(beep:24688): Unknown cmd
 fd(3) cmd(8000451a){t:'E';sz:0} arg(08049569) on /dev/tty0

 This is probably from (in beep.c):

   if (ioctl(console_fd, EVIOCGSND(0)) != -1)
 console_type = BEEP_TYPE_EVDEV;
   else
 console_type = BEEP_TYPE_CONSOLE;

 where the missing ioctl is completely expected and not worth a
 warning.  So yes, this looks like a (cosmetic) bug.

 [...]
 The message still occurs in 3.2 kernels (including the Debian 3.2.7-1
 kernel), but Linus removed it directly after the Linux 3.2 release in
 commit 07d106d0a3 (vfs: fix up ENOIOCTLCMD error handling).

 Thanks.  That patch is not queued for 3.2.y --- should it be?

Probably not, since it hardly meets the conditions described in
Documentation/stable_kernel_rules.txt.

Cheers,
   Sven



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hay08g1x@turtle.gmx.de

Re: Bug#580525: beep: Unknown cmd messages in syslog

[Sven Joachim]

reassign 580525 linux-2.6
thanks

Reassigning another bug report of mine to the kernel.

On 2010-05-06 17:39 +0200, Sven Joachim wrote:

 Package: beep
 Version: 1.2.2-24
 Severity: normal

 I get a message like the following in syslog whenever I run beep:

 May  6 17:04:58 turtle kernel: ioctl32(beep:24688): Unknown cmd fd(3) 
 cmd(8000451a){t:'E';sz:0} arg(08049569) on /dev/tty0


 -- System Information:
 Debian Release: squeeze/sid
   APT prefers unstable
   APT policy: (500, 'unstable'), (1, 'experimental')
 Architecture: i386 (x86_64)

 Kernel: Linux 2.6.34-rc6-nouveau (SMP w/2 CPU cores)

The message still occurs in 3.2 kernels (including the Debian 3.2.7-1
kernel), but Linus removed it directly after the Linux 3.2 release in
commit 07d106d0a3 (vfs: fix up ENOIOCTLCMD error handling).

Cheers,
   Sven


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d38te2lo@turtle.gmx.de

Bug#633423: Problem with autofs 64-bit kernel/32-bit userspace compatibility

[Sven Joachim]

tags 633423 + fixed-upstream patch
thanks

On 2012-02-24 20:15 +0100, Sven Joachim wrote:

 Short summary for readers new to the bug: boot hangs with i386 systemd
 and an x86_64 kernel.  

 On 2011-10-15 21:51 +0200, Sven Joachim wrote:

 It seems that somebody who is both smarter and more pertinacious than
 myself has tried to use a 32-bit systemd under 64-bit kernel and
 experienced the hangs, see the thread starting at [1].

 Thomas Meyer proposed a patch in [2], but it was rejected, arguing that
 the incompatibility should be fixed in the kernel.  Of course the autofs
 maintainer disagrees and wants workarounds in userspace, so we're stuck
 in a deadlock. :-/

 1. 
 http://lists.freedesktop.org/archives/systemd-devel/2011-September/003338.html
 2. 
 http://lists.freedesktop.org/archives/systemd-devel/2011-September/003396.html
  

 Thankfully this problem has now been communicated to Linus himself, and
 he agreed that it should be fixed in the kernel.  See the following long
 threads on the LKML:

 http://thread.gmane.org/gmane.linux.kernel/1255125
 http://thread.gmane.org/gmane.linux.kernel/1256405

 I will keep an eye on this bug and send an update when a fix appears in
 Linus' tree that I can test.

3.3-rc5 works for me, as does 3.2.7 with the following changes
cherry-picked:

a32744d4abae (autofs: work around unhappy compat problem on x86-64)
3c761ea05a89 (Fix autofs compile without CONFIG_COMPAT)
048cd4e51d24 (compat: fix compile breakage on s390)

The latter two are necessary to fix FTBFS problems on other
architectures introduced by a32744d4abae.

Cheers,
   Sven



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wr763dtb@turtle.gmx.de

Re: Bug#633423: Problem with autofs 64-bit kernel/32-bit userspace compatibility

[Sven Joachim]

reassign 633423 linux-2.6
retitle 633423 autofs4 interface is broken between x86 and x86_64
affects 633423 systemd
thanks

Short summary for readers new to the bug: boot hangs with i386 systemd
and an x86_64 kernel.  

On 2011-10-15 21:51 +0200, Sven Joachim wrote:

 It seems that somebody who is both smarter and more pertinacious than
 myself has tried to use a 32-bit systemd under 64-bit kernel and
 experienced the hangs, see the thread starting at [1].

 Thomas Meyer proposed a patch in [2], but it was rejected, arguing that
 the incompatibility should be fixed in the kernel.  Of course the autofs
 maintainer disagrees and wants workarounds in userspace, so we're stuck
 in a deadlock. :-/

 Unhappy,
 Sven


 1. 
 http://lists.freedesktop.org/archives/systemd-devel/2011-September/003338.html
 2. 
 http://lists.freedesktop.org/archives/systemd-devel/2011-September/003396.html
  

Thankfully this problem has now been communicated to Linus himself, and
he agreed that it should be fixed in the kernel.  See the following long
threads on the LKML:

http://thread.gmane.org/gmane.linux.kernel/1255125
http://thread.gmane.org/gmane.linux.kernel/1256405

I will keep an eye on this bug and send an update when a fix appears in
Linus' tree that I can test.

Cheers,
   Sven


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87obsoxcua@turtle.gmx.de

Bug#633423: Problem with autofs 64-bit kernel/32-bit userspace compatibility

[Sven Joachim]

On 2012-02-24 20:44 +0100, Bastian Blank wrote:

 On Fri, Feb 24, 2012 at 08:15:09PM +0100, Sven Joachim wrote:
 Short summary for readers new to the bug: boot hangs with i386 systemd
 and an x86_64 kernel.  

 Care to explain why it hangs and not dies?

Here is Thomas Meyer's explanation from [1]:

,
| the size of autofs_v5_packet_union is 300 bytes on x86 and 304 bytes on 
x86_64 kernels.
| when running systemd (x86) on an x86_64 kernel this leads to a hang in 
automount_fd_event-loop_read
| as a second fd_event is trigged for the remaining 4 bytes. but the loop_read 
tries to read
| 300 bytes again.
`

Sven


1. 
http://lists.freedesktop.org/archives/systemd-devel/2011-September/003396.html



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87haygx9qc@turtle.gmx.de

Bug#640672: moving files to arch specific include breaks compilations with -m32

[Sven Joachim]

On 2011-09-13 21:04 +0200, Daniel Bayer wrote:

 Now I updated to linux-libc-dev 3.0.0-3 to test. After this /usr/include/asm
 is an empty directory which belongs to gcc-multilib:

Congratulations, you have just rediscovered bug #638418.

Cheers,
   Sven



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zki8ntdn@turtle.gmx.de

Bug#638867: linux-libc-dev: errno.h includes non-existent asm/errno.h for -m32

[Sven Joachim]

On 2011-08-22 17:07 +0200, François Revol wrote:

 Package: linux-libc-dev
 Version: 3.0.0-2
 Severity: important

 Last update seems to break compiling some Haiku build tools which currently
 require -m32. Build log below.

 cf. https://www.haiku-os.org/guides/building

 $ (cd generated-x86-gcc4/; jam -q haiku-vmware-image)
 patience...
 patience...
 patience...
 patience...
 patience...
 patience...
 patience...
 patience...
 patience...
 patience...
 found 98358 target(s)...
 updating 4654 target(s)...
 InitScript1 
 /home/revol/devel/haiku/trunk/generated-x86-gcc4/haiku.image-init-vars 
 C++ 
 /home/revol/devel/haiku/trunk/generated-x86-gcc4/objects/linux/x86/release/build/libroot/atomic.o
  
 In file included from /usr/include/bits/errno.h:25:0,
  from /usr/include/errno.h:36,
  from 
 /home/revol/devel/haiku/trunk/headers/build/os/support/Errors.h:15,
  from 
 /home/revol/devel/haiku/trunk/headers/build/BeOSBuildCompatibility.h:32,
  from 
 /home/revol/devel/haiku/trunk/src/build/libroot/atomic.cpp:1:
 /usr/include/linux/errno.h:4:23: fatal error: asm/errno.h: No such file or 
 directory
 compilation terminated.

I bet /usr/include/asm is an empty directory on your system while it's
supposed to be a symlink to x86_64-linux-gnu/asm.  See
http://bugs.debian.org/638418 for details.

Cheers,
   Sven



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fwktfnw4@turtle.gmx.de

Bug#638867: linux-libc-dev: errno.h includes non-existent asm/errno.h for -m32

[Sven Joachim]

reassign 638867 gcc-multilib
forcemerge 638418 638867
thanks

On 2011-08-22 17:55 +0200, François Revol wrote:

 Le 22/08/2011 17:48, Sven Joachim a écrit :
 On 2011-08-22 17:07 +0200, François Revol wrote:

 Package: linux-libc-dev
 Version: 3.0.0-2
 Severity: important

 Last update seems to break compiling some Haiku build tools which currently
 require -m32. Build log below.

 I bet /usr/include/asm is an empty directory on your system while it's
 supposed to be a symlink to x86_64-linux-gnu/asm.  See
 http://bugs.debian.org/638418 for details.


 Indeed it's an empty folder here.

Remove it and either create the symlink yourself or reinstall the
gcc-multilib package.

 Seems to be the same cause then, I first thought it was again a bug in
 libc6-dev-i386 until I apt-file searched, and now you tell me it's in
 gcc-multilib :P

I'm reassigning and merging it.

Cheers,
   Sven



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aab1fmw1@turtle.gmx.de

Bug#636495: initramfs-tools: installs optimized libraries into the initramfs

[Sven Joachim]

On 2011-08-03 14:16 +0200, Sven Joachim wrote:

 My initramfs contains a libc6 that is optimized for i686:

 ,
 | $ lsinitramfs /boot/initrd.img-$(uname -r) | grep libc.so.6 
   
 | lib/i386-linux-gnu/i686/cmov/libc.so.6
 `

 No big deal for me, but wheezy/sid systems with a pre-686 processor will
 likely have a totally broken initramfs if libc6-i686 gets installed
 accidentally.

 This happens because the code in copy_exec() that finds the path to the
 unoptimized library assumes that these libraries reside directly in
 {/usr,}/lib and does not handle the multiarch path case.

Attached is a patch against git master that works for me:

,
| % lsinitramfs /boot/initrd.img-$(uname -r) | grep libc.so.6
| lib/i386-linux-gnu/libc.so.6
`

Cheers,
   Sven

From 4548e964f26e7ed11ddf02c5e81bed4f43e8b5b0 Mon Sep 17 00:00:00 2001
From: Sven Joachim svenj...@gmx.de
Date: Fri, 5 Aug 2011 13:18:49 +0200
Subject: [PATCH] copy_exec: Handle optimized libraries under multiarch paths

In a multiarch world, libraries are not directly installed under
{/usr,}/lib, but one directory below.  Adjust the search accordingly.

Closes: #636495
---
 hook-functions |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hook-functions b/hook-functions
index 41db112..dda441a 100644
--- a/hook-functions
+++ b/hook-functions
@@ -130,7 +130,7 @@ copy_exec() {
# Try to use non-optimised libraries where possible.
# We assume that all HWCAP libraries will be in tls,
# sse2, vfp or neon.
-   nonoptlib=$(echo ${x} | sed -e 
's#/lib/\(tls\|i686\|sse2\|neon\|vfp\).*/\(lib.*\)#/lib/\2#')
+   nonoptlib=$(echo ${x} | sed -e 
's#/lib/\([^/]*/\)\?\(tls\|i686\|sse2\|neon\|vfp\).*/\(lib.*\)#/lib/\1\3#')
 
if [ -e ${nonoptlib} ]; then
x=${nonoptlib}
-- 
1.7.5.4

Bug#636495: initramfs-tools: installs optimized libraries into the initramfs

[Sven Joachim]

Package: initramfs-tools
Version: 0.99
Severity: important

My initramfs contains a libc6 that is optimized for i686:

,
| $ lsinitramfs /boot/initrd.img-$(uname -r) | grep libc.so.6   

| lib/i386-linux-gnu/i686/cmov/libc.so.6
`

No big deal for me, but wheezy/sid systems with a pre-686 processor will
likely have a totally broken initramfs if libc6-i686 gets installed
accidentally.

This happens because the code in copy_exec() that finds the path to the
unoptimized library assumes that these libraries reside directly in
{/usr,}/lib and does not handle the multiarch path case.


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 3.0.0-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages initramfs-tools depends on:
ii  cpio  2.11-7 GNU cpio -- a program to manage ar
ii  findutils 4.4.2-1+b1 utilities for finding files--find,
ii  klibc-utils   1.5.24-1   small utilities built with klibc f
ii  module-init-tools 3.16-1 tools for managing Linux kernel mo
ii  udev  172-1  /dev/ and hotplug management daemo

Versions of packages initramfs-tools recommends:
ii  busybox   1:1.18.5-1 Tiny utilities for small and embed

Versions of packages initramfs-tools suggests:
ii  bash-completion   1:1.3-1programmable completion for the ba

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8739hilmgi@turtle.gmx.de

Bug#636495: initramfs-tools: installs optimized libraries into the initramfs

[Sven Joachim]

severity 636495 normal
thanks

On 2011-08-03 14:16 +0200, Sven Joachim wrote:

 Package: initramfs-tools
 Version: 0.99
 Severity: important

 My initramfs contains a libc6 that is optimized for i686:

 ,
 | $ lsinitramfs /boot/initrd.img-$(uname -r) | grep libc.so.6 
   
 | lib/i386-linux-gnu/i686/cmov/libc.so.6
 `

 No big deal for me, but wheezy/sid systems with a pre-686 processor will
 likely have a totally broken initramfs if libc6-i686 gets installed
 accidentally.

Thinking about it again, this is probably not going to happen since ldd
will print the path of the unoptimized library if the optimized one does
not work on the current processor.  So there is only a problem if the
initramfs is generated on a more capable machine and then transferred.

Cheers,
   Sven




-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vcuek15d@turtle.gmx.de

Bug#633426: nfs-kernel-server: complains about missing /etc/exports.d directory

[Sven Joachim]

Package: nfs-kernel-server
Version: 1:1.2.4-1
Severity: minor

I just saw the following warning:

,
| # /etc/init.d/nfs-kernel-server start
| Exporting directories for NFS kernel daemon...exportfs: scandir 
/etc/exports.d: No such file or directory
| 
| .
| Starting NFS kernel daemon: nfsd mountd.
`

Creating the missing directory made nfs-kernel-server shut up, so maybe
it should just be shipped in the package.


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 3.0.0-rc6-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages nfs-kernel-server depends on:
ii  libblkid1  2.19.1-2  block device id library
ii  libc6  2.13-10   Embedded GNU C Library: Shared lib
ii  libcomerr2 1.42~WIP-2011-07-02-1 common error description library
ii  libgssapi-krb5-2   1.9.1+dfsg-1  MIT Kerberos runtime libraries - k
ii  libgssglue10.3-1 mechanism-switch gssapi library
ii  libk5crypto3   1.9.1+dfsg-1  MIT Kerberos runtime libraries - C
ii  libkrb5-3  1.9.1+dfsg-1  MIT Kerberos runtime libraries
ii  libnfsidmap2   0.24-1An nfs idmapping library
ii  libtirpc1  0.2.2-4   transport-independent RPC library
ii  libwrap0   7.6.q-21  Wietse Venema's TCP wrappers libra
ii  lsb-base   3.2-27Linux Standard Base 3.2 init scrip
ii  nfs-common 1:1.2.4-1 NFS support files common to client
ii  ucf3.0025+nmu2   Update Configuration File: preserv

nfs-kernel-server recommends no packages.

nfs-kernel-server suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y606leff@turtle.gmx.de

Bug#631255: 3.0-rc3: kernel BUG at fs/inode.c:1368!

[Sven Joachim]

On 2011-06-22 15:56 +0200, Ben Hutchings wrote:

 On Wed, 2011-06-22 at 08:36 +0200, Johannes Wiedersich wrote:
 Package: linux-2.6
 Version: 3.0.0~rc3-1~experimental.1
 Severity: important
 
 
 aptitude installing a package triggers a kernel oops. I have no idea,
 what part of the installation process is to blame, but could try to
 reproduce, if I would get further instructions. 
 [...]

 I assume you haven't seen a similar crash in earlier versions?

This bug is specific to 3.0.0-rc3 and has been fixed in -rc4.

 Also, what type of filesystem where you installing on
 (ext3/ext4/btrfs/xfs...)?

I have seen it on ext4, but it's not really filesystem specific AFAIK.

 /media/data/mattems/src/linux-2.6-3.0.0~rc3/debian/build/source_amd64_none/fs/inode.c:1368!

Fixed by commit 50338b889dc.

Cheers,
   Sven



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vsu3pmd@turtle.gmx.de

Bug#613078: xserver-xorg-video-nouveau: corrupted graphics on GeForce 6150SE nForce 430

[Sven Joachim]

On 2011-02-13 11:12 +0100, Jakub Wilk wrote:

 * Sven Joachim svenj...@gmx.de, 2011-02-12, 18:43:
https://bugs.freedesktop.org//show_bug.cgi?id=33887

 I rebuilt my kernel with this patch applied:
 https://bugs.freedesktop.org/attachment.cgi?id=43011
 The problem went away. :)

The mentioned patch was rather a hack, 2.6.38-rc6 has a proper patch
that supposedly fixes the problem (see comment #36 in the upstream bug).
Jakub, could you please verify this (2.6.38-rc6 is available from
experimental)?

Regards,
Sven



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ei6y3eky@turtle.gmx.de

Bug#613131: Fixed in kernel 2.6.38-rc6

[Sven Joachim]

On 2011-02-22 18:43 +0100, Chanoch (Ken) Bloom wrote:

 Per the upstream bug report, this is fixed in kernel commit
 aaa3d08c357dcfbe13ec23786c294759183a4d8d, which is
 included in 2.6.38-rc6.

2.6.38-rc6 is now available in experimental, could you please verify
whether it indeed fixes the problem?

Regards,
Sven



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vx63ehp@turtle.gmx.de

Bug#614507: xserver-common: Upgrade breaks X

[Sven Joachim]

On 2011-02-22 02:32 +0100, Nigel Horne wrote:

 dmesg gives me this information, if it helps:
 [   23.408742] [drm] nouveau :00:0d.0: === misaligned reg
 0x0060081D ===
 [   23.408777] [drm] nouveau :00:0d.0: === misaligned reg
 0x0060081D ===

That seems to be a kernel bug that is supposed to be fixed now¹.  Could
you please try out 2.6.38-rc6, available from experimental?

Cheers,
   Sven


¹ https://bugs.freedesktop.org//show_bug.cgi?id=33887#c36



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y6561yy7@turtle.gmx.de

Re: Bug#610987: X server hang (EQ overflowing), nouveau driver

[Sven Joachim]

forwarded 610987 https://bugs.freedesktop.org/show_bug.cgi?id=26980
thanks

On 2011-01-24 17:57 +0100, Eric Marsden wrote:

 The X server no longer responds to keyboard input or mouse clicks (the mouse 
 cursor still moves).
 Has occurred twice in one afternoon. Connecting to the machine over ssh, the 
 X server is using
 between 20 and 40% of the CPU and the tail of /var/log/Xorg.0.log (attached) 
 contains the following.

 ,
 | [ 5790.036] (II) NOUVEAU(0): Modeline 1920x1080x60.0 172.80 1920
 | 2040 2248 2576 1080 1081 1084 1118 -hsync +vsync (67.1 kHz)
 | [  9892.867] [mi] EQ overflowing. The server is probably stuck in an 
 infinite loop.
 | [  9892.867] 
 | Backtrace:
 | [  9892.907] 0: /usr/bin/X (xorg_backtrace+0x28) [0x4aa9c8]
 | [  9892.907] 1: /usr/bin/X (mieqEnqueue+0x1f4) [0x4a6a04]
 | [  9892.907] 2: /usr/bin/X (xf86PostMotionEventP+0xc4) [0x464c04]
 | [  9892.907] 3: /usr/lib/xorg/modules/input/evdev_drv.so 
 (0x7f2869a24000+0x52fc) [0x7f2869a292fc]
 | [  9892.907] 4: /usr/bin/X (0x40+0x76137) [0x476137]
 | [  9892.907] 5: /usr/bin/X (0x40+0x11ba93) [0x51ba93]
 | [  9892.907] 6: /lib/libpthread.so.0 (0x7f286dd66000+0xef60) 
 [0x7f286dd74f60]
 | [  9892.907] 7: /lib/libc.so.6 (ioctl+0x7) [0x7f286cb8be27]
 | [  9892.907] 8: /usr/lib/libdrm.so.2 (drmIoctl+0x28) [0x7f286af2e838]
 | [  9892.907] 9: /usr/lib/libdrm.so.2 (drmCommandWrite+0x1b) [0x7f286af2eabb]
 | [  9892.907] 10: /usr/lib/libdrm_nouveau.so.1 (0x7f286a8ef000+0x314d) 
 [0x7f286a8f214d]
 | [  9892.907] 11: /usr/lib/libdrm_nouveau.so.1 (nouveau_bo_map_range+0xf6) 
 [0x7f286a8f2346]
 | [  9892.907] 12: /usr/lib/xorg/modules/drivers/nouveau_drv.so 
 (0x7f286aaf4000+0x708e) [0x7f286aafb08e]
 | [  9892.907] 13: /usr/lib/xorg/modules/libexa.so (0x7f286a4b4000+0x6357) 
 [0x7f286a4ba357]
 | [  9892.907] 14: /usr/lib/xorg/modules/libexa.so (0x7f286a4b4000+0x8a81) 
 [0x7f286a4bca81]
 | [  9892.907] 15: /usr/lib/xorg/modules/libexa.so (0x7f286a4b4000+0x9fa5) 
 [0x7f286a4bdfa5]
 `

 Versions of related packages:

 xserver-xorg: 1:7.6~2
 xserver-xorg-video-nouveau: 1:0.0.16+git20101210+8bb8231-1
 linux-image-2.6.37-trunk-amd64: 2.6.37-1~experimental.1

 Graphics card: GeForce GT 220. 

This card suffers from random GPU lockups, see
https://bugs.freedesktop.org/show_bug.cgi?id=26980.  A workaround is to
disable acceleration, e.g. by booting with nouveau.noaccel=1.  The
Squeeze kernels do this automatically for your hardware since 2.6.32-22,
but the patch for this does not seem to have been applied to the
experimental kernels.

CC'ing kernel maintainers who may want to apply the patch in newer
kernels, since there is apparently no process on the upstream bug. :-(

Sven


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sjwiw5ce@turtle.gmx.de

Bug#590607: still present in 2.6.32-26

[Sven Joachim]

found 590607 2.6.32-26
thanks

Hi,

while (unsuccessfully) trying to reproduce #601962 in a chroot, I
noticed that the squeeze/sid version of linux-2.6 has this bug as well,
since it left /usr/lib/modules/2.6.32-5-amd64/modules.devname behind
after purging.

Sven



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k4kyfjax@turtle.gmx.de

Re: Bug#588339: sync/fsync in dpkg

[Sven Joachim]

On 2010-10-21 19:14 +0200, Jonathan Nieder wrote:

 Ken Bloom wrote:

 And what mount options are you using? If you're using
 defaults, /etc/mtab (and therefore the mount command) won't know what
 the default values are, but you can check /proc/mounts which will
 include the data= mount option.

 data=ordered.  That's the default for ext4.

Yes, and data=writeback does not make much of a difference.  However,
using the nodelalloc mount option does wonders, increasing unpacking
speed in dpkg 1.15.7 by a factor of ~8.

Sven



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bp6huz9g@turtle.gmx.de

Re: Bug#598803: xserver-xorg-video-intel: X crashes / hung gpu, now and then

[Sven Joachim]

On 2010-10-02 18:31 +0200, Steinar H. Gunderson wrote:

 On Sat, Oct 02, 2010 at 06:07:51PM +0200, Cesare Leonardi wrote:
 Hello Steinar, can you tell us what's your chipset?

 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 
 943/940GML Express Integrated Graphics Controller (rev 03)

I have the same one, and the HTML5 Youtube video you mentioned works
fine in Chromium with Kernel 2.6.36-rc6, libdrm 2.4.22 and
xserver-xorg-video-intel 2.13.0.

 It's a Dell Latitude D420, FWIW.

Mine is a an Acer Travelmate 2490.

Sven


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lj6gjzfw@turtle.gmx.de

Bug#591683: linux-2.6: /lib/modules/$(uname -r)/modules.devname not removed on purge

[Sven Joachim]

merge 590607 591683
thanks

On 2010-08-04 20:43 +0200, Josh Triplett wrote:

 Package: linux-2.6
 Severity: normal

 I recently installed the 2.6.35-rc6 packages, and purged 2.6.34 and
 2.6.35-rc5.  In doing so, I got a dpkg error message about the inability
 to remove the non-empty directory /lib/modules/$(uname -r)/ .  I
 checked, and both of these directories contain modules.devname files,
 which apparently got generated and not removed.

I beat you by eight days. ;-)

Sven



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hbjaky89@turtle.gmx.de

Bug#590607: linux-image-2.6.35-rc6-amd64: cruft file modules.devname left on the system after purging

[Sven Joachim]

Package: linux-2.6
Version: 2.6.35~rc6-1~experimental.1

Purging linux-image-2.6.35-rc6-amd64 left a stale file behind:

,
| % LANG=C sudo dpkg --purge linux-image-2.6.35-rc6-amd64 
| (Reading database ... 167640 files and directories currently installed.)
| Removing linux-image-2.6.35-rc6-amd64 ...
| Examining /etc/kernel/prerm.d.
| Examining /etc/kernel/postrm.d .
| run-parts: executing /etc/kernel/postrm.d/initramfs-tools 2.6.35-rc6-amd64 
/boot/vmlinuz-2.6.35-rc6-amd64
| The link /boot/vmlinuz is a damaged link
| Removing symbolic link vmlinuz 
| You may need to re-run your boot loader
| The link /boot/initrd.img is a damaged link
| Removing symbolic link initrd.img 
| You may need to re-run your boot loader
| Purging configuration files for linux-image-2.6.35-rc6-amd64 ...
| Examining /etc/kernel/postrm.d .
| run-parts: executing /etc/kernel/postrm.d/initramfs-tools 2.6.35-rc6-amd64 
/boot/vmlinuz-2.6.35-rc6-amd64
| rmdir: failed to remove `/lib/modules/2.6.35-rc6-amd64': Directory not empty
| dpkg: warning: while removing linux-image-2.6.35-rc6-amd64, directory 
'/lib/modules/2.6.35-rc6-amd64' not empty so not removed.
| Processing triggers for readahead-fedora ...
| % LANG=C ls -lA /lib/modules/2.6.35-rc6-amd64 
| total 2
| -rw-r--r-- 1 root root 196 Jul 27 20:59 modules.devname
`


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.35-rc6-nouveau+ (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877hkgensn@turtle.gmx.de

Bug#589996: Insane dependency on apt causes kernel to be removed on update

[Sven Joachim]

On 2010-07-23 01:34 +0200, Ben Hutchings wrote:

 On Thu, 2010-07-22 at 22:19 +0200, Goswin von Brederlow wrote:
 Package: linux-base
 Version: 2.6.32-17
 Severity: important
 
 Hi,
 
 in the linux-image packages there is now a dependency chain from
 linux-image-2.6... - linux-base - libapt-pkg-perl -
 libapt-pkg-libc6.9-6-4.8. Which is the virtual package provided by apt
 to signal the ABI of its library and binary caches. In effect the
 kernels are locked to a specific ABI version of apt. The problem is
 that the ABI changes from time to time and every time it does an
 update of apt will now remove the kernel for the duration of the
 transition. For an example try installing apt from experimental.
 
 Well, that is life you might say. That is what is called a library
 transition.
 
 But here comes the insane part. The 1637 line long perl postinst
 script of linux-base only depends on apt because of this code at the
 end:
 [...]

 What's really insane is that we don't have a nice and stable library to
 do this and instead I have to fork every time I want to compare two
 strings.

Isn't there libdpkg-perl which provides this, see Dpkg::Version(3)?
Though it might not be suitable for linux-base, because you would have
to depend on libdpkg-perl | dpkg-dev ( 1.15.6).

Sven



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k4ompm1r@turtle.gmx.de

Bug#581830: linux-image-2.6.32-5-amd64: console and X display do not work unless nouveau is blacklisted

[Sven Joachim]

On 2010-06-04 17:47 +0200, Vincent Lefevre wrote:

 severity 581830 grave
 retitle 581830 nouveau doesn't work (black screen) and cannot be blacklisted
 thanks

 On 2010-05-16 14:28:02 +0200, Vincent Lefevre wrote:
 The problem disappears after blacklisting nouveau.

 It is no longer possible to blacklist it. It gets loaded.

You should specify the nv driver in xorg.conf.

Sven



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bpbqu6zq@turtle.gmx.de

Bug#581830: linux-image-2.6.32-5-amd64: console and X display do not work unless nouveau is blacklisted

[Sven Joachim]

On 2010-06-04 18:02 +0200, Vincent Lefevre wrote:

 On 2010-06-04 17:56:09 +0200, Sven Joachim wrote:
 You should specify the nv driver in xorg.conf.

 Unfortunately this doesn't seem to be possible: X crashes when I try
 to generate a xorg.conf with Xorg -configure. See

   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580043

So write xorg.conf by hand, here is one for you:

--8---cut here---start-8---
Section Device
Identifier  n
Driver  nv
EndSection
--8---cut here---end---8---

Sven



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8739x2u6e6@turtle.gmx.de

Bug#583162: linux-image-2.6.32-5-amd64: console font corruption with nouveau

[Sven Joachim]

Package: linux-2.6
Version: 2.6.32-13
Severity: normal
Tags: patch fixed-upstream

When a non-default console font size is selected (e.g. by running
setfont Uni3-Terminus20x10), nouveau displays corrupted glyphs
rendering the terminal useless.

This has been fixed by commit c82b88d578847909797945824851a6a9a84f9c20:

drm/nouveau: Fix fbcon corruption with font width not divisible by 8

NV50 is nice and has a switch that autoaligns stuff for us. Pre-NV50,
we need to align input bitmap width manually.

Signed-off-by: Marcin Kościelnicki koria...@0x04.net
Signed-off-by: Francisco Jerez curroje...@riseup.net
Signed-off-by: Ben Skeggs bske...@redhat.com

This does not apply as is, attached is a patch that can be applied
against 2.6.33.4 (I haven't looked at the Debian kernel yet).  I
verified that the fix for nv50_fbcon.c works, but I cannot test the one
for nv04_fbcon.c due to lack of hardware.  Note that the same patch has
been applied in Ubuntu, see also
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/544739.


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.34-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages linux-image-2.6.32-5-amd64 depends on:
ii  debconf [debconf 1.5.32  Debian configuration management sy
ii  initramfs-tools  0.94.4  tools for generating an initramfs
ii  linux-base   2.6.34-1~experimental.1 Linux image base package
ii  module-init-tool 3.12~pre2-3 tools for managing Linux kernel mo

Versions of packages linux-image-2.6.32-5-amd64 recommends:
ii  firmware-linux-f 2.6.34-1~experimental.1 Binary firmware for various driver
ii  libc6-i686   2.10.2-9GNU C Library: Shared libraries [i

Versions of packages linux-image-2.6.32-5-amd64 suggests:
ii  grub-legacy [grub]0.97-61GRand Unified Bootloader (Legacy v
pn  linux-doc-2.6.32  none (no description available)

Versions of packages linux-image-2.6.32-5-amd64 is related to:
pn  firmware-bnx2 none (no description available)
pn  firmware-bnx2xnone (no description available)
pn  firmware-ipw2x00  none (no description available)
pn  firmware-ivtv none (no description available)
pn  firmware-iwlwifi  none (no description available)
pn  firmware-linuxnone (no description available)
pn  firmware-linux-nonfreenone (no description available)
pn  firmware-qlogic   none (no description available)
ii  firmware-ralink   0.24   Binary firmware for Ralink RT2561,
pn  xen-hypervisornone (no description available)

-- debconf information excluded

From a02fa11e84fb00c6489970570a3d4480f075e020 Mon Sep 17 00:00:00 2001
From: Sven Joachim svenj...@gmx.de
Date: Tue, 25 May 2010 22:24:47 +0200
Subject: [PATCH] drm/nouveau: Fix fbcon corruption with font width not divisible by 8
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

NV50 is nice and has a switch that autoaligns stuff for us. Pre-NV50,
we need to align input bitmap width manually.

Signed-off-by: Marcin Kościelnicki koria...@0x04.net
Signed-off-by: Francisco Jerez curroje...@riseup.net
Signed-off-by: Ben Skeggs bske...@redhat.com

Conflicts:

	drivers/gpu/drm/nouveau/nv04_fbcon.c
---
 drivers/gpu/drm/nouveau/nv04_fbcon.c |6 +++---
 drivers/gpu/drm/nouveau/nv50_fbcon.c |2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nv04_fbcon.c b/drivers/gpu/drm/nouveau/nv04_fbcon.c
index fd01caa..813b25c 100644
--- a/drivers/gpu/drm/nouveau/nv04_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nv04_fbcon.c
@@ -118,8 +118,8 @@ nv04_fbcon_imageblit(struct fb_info *info, const struct fb_image *image)
 		return;
 	}
 
-	width = (image-width + 31)  ~31;
-	dsize = (width * image-height)  5;
+	width = ALIGN(image-width, 8);
+	dsize = ALIGN(width * image-height, 32)  5;
 
 	if (info-fix.visual == FB_VISUAL_TRUECOLOR ||
 	info-fix.visual == FB_VISUAL_DIRECTCOLOR) {
@@ -136,8 +136,8 @@ nv04_fbcon_imageblit(struct fb_info *info, const struct fb_image *image)
 			 ((image-dx + image-width)  0x));
 	OUT_RING(chan, bg);
 	OUT_RING(chan, fg);
-	OUT_RING(chan, (image-height  16) | image-width);
 	OUT_RING(chan, (image-height  16) | width);
+	OUT_RING(chan, (image-height  16) | image-width);
 	OUT_RING(chan, (image-dy  16) | (image-dx  0x));
 
 	while (dsize) {
diff --git a/drivers/gpu/drm/nouveau/nv50_fbcon.c b/drivers/gpu/drm/nouveau/nv50_fbcon.c
index 0f57cdf..195c866 100644
--- a/drivers/gpu/drm/nouveau/nv50_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nv50_fbcon.c
@@ -233,7 +233,7 @@ nv50_fbcon_accel_init(struct fb_info

Bug#580894: linux-image-2.6.32-5-amd64 crashes at boot (due to nouveau)

[Sven Joachim]

Am 16.05.2010 um 12:08 schrieb Hans-J. Ullrich:

 Yeah! Found out, why this kernel version crashes. The reason is the new video 
 driver nouveau, which is interfering with some nvidia-garphic-cards. 

Nitpick: it interferes with the proprietary driver, not with the card.

 Workaround: If you are using the binary and accelerated driver nvidia-glx,  
 then you will not need the nouveau driver from the kernel. Either delete it , 
 or , just blacklist it. (Enter the driver in /etc/modules/blacklist.conf).

It would probably make sense if the nvidia-glx package shipped a file
blacklisting nouveau.

The interesting question is why nvidia.ko does even get loaded (that the
screen goes blank then does not really surprise me).  On my system, it
refuses to load when nouveau is in charge of the card.

Sven



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87eihcf5t4@turtle.gmx.de

Bug#580894: linux-image-2.6.32-5-amd64 crashes at boot (due to nouveau)

[Sven Joachim]

On 2010-05-16 13:41 +0200, Vincent Lefevre wrote:

 On 2010-05-16 13:24:07 +0200, Sven Joachim wrote:
 Am 16.05.2010 um 12:08 schrieb Hans-J. Ullrich:
  Yeah! Found out, why this kernel version crashes. The reason is
  the new video driver nouveau, which is interfering with some
  nvidia-garphic-cards.
 
 Nitpick: it interferes with the proprietary driver, not with the card.

 In my case, I don't have the proprietary driver installed on my
 machine affected by the problem. So, there is at least a bug that
 is *not* due to the proprietary driver.

You have already been told to file your own bugs for your own issues and
you have not sent anything meaningful (i.e. logs) so far.

Sven



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wrv4dq23@turtle.gmx.de

Bug#579262: /usr/sbin/mkinitramfs: 141: mktemp: not found

[Sven Joachim]

On 2010-04-26 16:45 +0200, Tom Parker wrote:

 On 26/04/10 15:32, maximilian attems wrote:
 coreutils is priority required, your box looks broken.
 please investigate how it came to missing mktemp.
 thanks

 There was an installed copy of coreutils, but version 6.10-6 which
 doesn't contain mktemp. The issue is partly because this is a mixed
 release box, with some stable, testing and unstable packages, but this
 is still an issue that should be dealt with (partially because it may
 cause weird upgrade issues for some users I suspect).

You probably downgraded coreutils from a version that replaced mktemp,
check /var/log/dpkg*.  This is not supported, and you have to fix it
yourself (reinstall mktemp or upgrade coreutils).

Sven



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87iq7ejma8@turtle.gmx.de

Re: Bug#558788: add nouveau in squeeze, please

[Sven Joachim]

On 2010-03-28 00:23 +0100, Adrian Glaubitz wrote:

 Hi,

 there are a few problems which will probably prevent nouveau
 from being added to Squeeze:

 First, Squeeze is certainly going to be shipped with 2.6.32
 since it is a kernel with long-term support from upstream.
 Since Debian puts a strong emphasis on stability and long-term
 stable support, it is very likely that it will be shipped with
 2.6.32. The problem now is that nouveau modesetting and drm
 support is not in 2.6.32 but it was first introduced with
 2.6.33. Thus, in order to use nouveau together with Squeeze,
 the nouveau drm and modesetting code will have to be backported
 from 2.6.33 which Ubuntu did for their due 10.04 release.

This has already been done in the latest linux-2.6 upload to sid.

 Secondly, even if the nouveau code gets backported to 2.6.32,
 there is still the problem that the nouveau xorg driver has
 received significant changes in the drm API which are incompatible
 to all drm code prior to 2.6.34.

These changes have been reverted in the latest upload of libdrm to
experimental, and libdrm-nouveau1 2.4.18-4 works fine with both vanilla
2.6.33 and Debian 2.6.32 from sid.

 Thus, the current upstream
 nouveau version cannot be used without a lot of efforts of
 backporting or people will have to stick to the current version
 of nouveau from experimental which, however, still needs the
 backporting of the drm code from 2.6.32 to 2.6.33.

Not true.  I am working on an xserver-xorg-video-nouveau package that is
based on the same upstream snapshot as the version in Ubuntu 10.04, and
while it needs some polishing (especially adding a README.Debian
explaining the requirements and how to set it up), it is already working
well for me.  Hopefully it can be uploaded to experimental in the next
couple of days.

 My suggestion therefore is to drop nouveau for Squeeze and
 rather wait until 2.6.34 is released and makes it into unstable.
 At this point, the kernel will provide all necessary drm and
 modesetting code in a hopefully mature state.

The real problem is that if we put nouveau into squeeze with 2.6.33 DRM
and make it the default driver for Nvidia GPUs, people are locked into
the Squeeze kernel.  This is why I personally would not support this¹,
but if the Debian kernel team and the X strike force are willing to deal
with the I upgraded my kernel and now X doesn't start!!! flow of bugs,
it might be possible.

The other problem is that with 2.6.33 DRM, most GPUs need firmware of an
uncertain legal state to provide any 2D acceleration.  If this cannot be
distributed by Debian, there needs to be another way for users to obtain
it easily.  I hacked together a short script that fetches and installs
it from an upstream tarball², but it might of course disappear from
there at any time.

Sven


¹ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568168#63
² http://people.freedesktop.org/~pq/nouveau-drm/


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hbo1oro9@turtle.gmx.de