Re: Bug#903122: debian-installer-9-netboot-amd64: Please add char/virtio_console module (paravirtualized serial) to netinst

2018-07-09 Thread Ben Hutchings 
On Tue, 2018-07-10 at 02:32 +0200, Cyril Brulebois wrote:
> Control: reassign -1 src:linux
> Control: tag -1 patch
> 
> Ben Hutchings  (2018-07-09):
> > I would say virtio-modules.  All the virtio class drivers depend on
> > virtio and virtio_ring, which means that adding them to any other
> > package would require that package to depend on virtio-modules.
> > 
> > (The Xen-specific drivers don't have this issue only because xenbus
> > unfortunately has to be built-in.)
> 
> Alright, I've implemented this in the attached patches, one for sid, and
> one for stretch. I didn't run any test builds, but I've verified that
> contrary to some other virtio* modules, virtio_console is built
> everywhere (CONFIG_VIRTIO_CONSOLE=m in debian/config/config), so should
> be added without '?'.

For the kernel-wedge config, it generally doesn't matter whether a
driver might be built-in.  The "copy-modules" sub-command checks in the
"modules.builtin" file before looking for a real module file.  It's
only a problem if all the modules listed for a package are built-in,
because an empty package is treated as an error (maybe that should just
be a warning?).

Ben.

> Thanks for considering.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.



signature.asc
Description: This is a digitally signed message part

Bug#903437: firmware-atheros: Ath10k/QCA9377 doesn't work

2018-07-09 Thread susu 
Package: firmware-atheros
Version: 20170823-1
Severity: important

#
[3.885977] ath10k_pci :07:00.0: firmware: failed to load ath10k/pre-
cal-pci-:07:00.0.bin (-2)
[3.885978] ath10k_pci :07:00.0: Direct firmware load for ath10k/pre-
cal-pci-:07:00.0.bin failed with error -2
[3.885983] ath10k_pci :07:00.0: firmware: failed to load ath10k/cal-
pci-:07:00.0.bin (-2)
[3.885984] ath10k_pci :07:00.0: Direct firmware load for ath10k/cal-
pci-:07:00.0.bin failed with error -2
[3.886149] ath10k_pci :07:00.0: firmware: failed to load
ath10k/QCA9377/hw1.0/firmware-6.bin (-2)
[3.886149] ath10k_pci :07:00.0: Direct firmware load for
ath10k/QCA9377/hw1.0/firmware-6.bin failed with error -2
[3.887389] ath10k_pci :07:00.0: firmware: direct-loading firmware
ath10k/QCA9377/hw1.0/firmware-5.bin
[3.887392] ath10k_pci :07:00.0: qca9377 hw1.1 target 0x05020001 chip_id
0x003821ff sub 17aa:0901
[3.887393] ath10k_pci :07:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs
0 testmode 0
[3.887665] ath10k_pci :07:00.0: firmware ver WLAN.TF.1.0-00267-1 api 5
features ignore-otp crc32 79cea2c7




-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

firmware-atheros depends on no packages.

firmware-atheros recommends no packages.

Versions of packages firmware-atheros suggests:
ii  initramfs-tools  0.130

-- no debconf information

Processed: Re: Bug#903122: debian-installer-9-netboot-amd64: Please add char/virtio_console module (paravirtualized serial) to netinst

2018-07-09 Thread Debian Bug Tracking System 
Processing control commands:

> reassign -1 src:linux
Bug #903122 [debian-installer-9-netboot-amd64] 
debian-installer-9-netboot-amd64: Please add char/virtio_console module 
(paravirtualized serial) to netinst
Bug reassigned from package 'debian-installer-9-netboot-amd64' to 'src:linux'.
Ignoring request to alter found versions of bug #903122 to the same values 
previously set
Ignoring request to alter fixed versions of bug #903122 to the same values 
previously set
> tag -1 patch
Bug #903122 [src:linux] debian-installer-9-netboot-amd64: Please add 
char/virtio_console module (paravirtualized serial) to netinst
Added tag(s) patch.

-- 
903122: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903122
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: Bug#903122: debian-installer-9-netboot-amd64: Please add char/virtio_console module (paravirtualized serial) to netinst

2018-07-09 Thread Cyril Brulebois 
Control: reassign -1 src:linux
Control: tag -1 patch

Ben Hutchings  (2018-07-09):
> I would say virtio-modules.  All the virtio class drivers depend on
> virtio and virtio_ring, which means that adding them to any other
> package would require that package to depend on virtio-modules.
> 
> (The Xen-specific drivers don't have this issue only because xenbus
> unfortunately has to be built-in.)

Alright, I've implemented this in the attached patches, one for sid, and
one for stretch. I didn't run any test builds, but I've verified that
contrary to some other virtio* modules, virtio_console is built
everywhere (CONFIG_VIRTIO_CONSOLE=m in debian/config/config), so should
be added without '?'.

Thanks for considering.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
From 90196cd7fb99232c3990600634032a64693ec2ba Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Tue, 10 Jul 2018 02:22:04 +0200
Subject: [PATCH] udeb: Add virtio_console to virtio-modules (Closes: #903122).

Reported-by: Vincent Caron 
---
 debian/changelog| 3 +++
 debian/installer/modules/virtio-modules | 1 +
 2 files changed, 4 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 79197a0db..e9f8d5f11 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -291,6 +291,9 @@ linux (4.17.5-1) UNRELEASED; urgency=medium
   native tools built by kbuild
* fs: Fix up non-directory creation in SGID directories (CVE-2018-13405)
 
+  [ Cyril Brulebois ]
+  * udeb: Add virtio_console to virtio-modules (Closes: #903122).
+
  -- Sjoerd Simons   Wed, 04 Jul 2018 10:25:57 +0200
 
 linux (4.17.3-1) unstable; urgency=medium
diff --git a/debian/installer/modules/virtio-modules b/debian/installer/modules/virtio-modules
index bb8947525..48ce25101 100644
--- a/debian/installer/modules/virtio-modules
+++ b/debian/installer/modules/virtio-modules
@@ -3,6 +3,7 @@ virtio_blk
 virtio_balloon
 virtio_scsi
 virtio_input
+virtio_console
 
 # Some architectures do not have PCI bus
 virtio_pci ?
-- 
2.11.0

From 57748822568fe687969a2a05c20f8f2b5cc81cb9 Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Tue, 10 Jul 2018 02:22:04 +0200
Subject: [PATCH] udeb: Add virtio_console to virtio-modules (Closes: #903122).

Reported-by: Vincent Caron 
---
 debian/changelog| 6 ++
 debian/installer/modules/virtio-modules | 1 +
 2 files changed, 7 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index c9043dd64..9f02fe5f6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+linux (4.9.110-2) UNRELEASED; urgency=medium
+
+  * udeb: Add virtio_console to virtio-modules (Closes: #903122).
+
+ -- Cyril Brulebois   Tue, 10 Jul 2018 02:26:09 +0200
+
 linux (4.9.110-1) stretch; urgency=medium
 
   * New upstream stable update:
diff --git a/debian/installer/modules/virtio-modules b/debian/installer/modules/virtio-modules
index bb8947525..48ce25101 100644
--- a/debian/installer/modules/virtio-modules
+++ b/debian/installer/modules/virtio-modules
@@ -3,6 +3,7 @@ virtio_blk
 virtio_balloon
 virtio_scsi
 virtio_input
+virtio_console
 
 # Some architectures do not have PCI bus
 virtio_pci ?
-- 
2.11.0



signature.asc
Description: PGP signature

Re: Bug#903122: debian-installer-9-netboot-amd64: Please add char/virtio_console module (paravirtualized serial) to netinst

2018-07-09 Thread Ben Hutchings 
On Sun, 2018-07-08 at 06:37 +0200, Cyril Brulebois wrote:
[...]
> Vincent Caron  (2018-07-06):
[...]
> > If this module makes it to netinst's initrd, one would use those kvm
> > args:
> > 
> > -chardev file,path=virtiocon0.log,id=virtiocon0
> > -device virtio-serial
> > -device virtconsole,chardev=virtiocon0
> > 
> > ... and in the guest a /dev/hvc0 would appear. Anything the guest would
> > write to /dev/hv0 would en up in the host's vitriocon0.log file.
> 
> So it seems we're talking about kernel/drivers/char/virtio_console.ko
> that could be added to either the serial-modules udeb or the
> virtio-modules one. Kernel maintainers, what do you think?
>
> This might be worth backporting to stretch too. I can send patches when
> you've selected the udeb we should be adding this module to.

I would say virtio-modules.  All the virtio class drivers depend on
virtio and virtio_ring, which means that adding them to any other
package would require that package to depend on virtio-modules.

(The Xen-specific drivers don't have this issue only because xenbus
unfortunately has to be built-in.)

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein



signature.asc
Description: This is a digitally signed message part

Bug#720528: nvidia: driver fails kernel 3.10+ (GeForce 600M and 700M series)

2018-07-09 Thread Andres Cimmarusti 
> Control: tag -1 moreinfo
>
> On Sat, 23 Aug 2014 22:53:48 -0700 Ben Hutchings 
> wrote:
> > On Sat, 2014-08-23 at 20:14 -0700, Andres Cimmarusti wrote:
> > > Let me re-state: worked with debian 3.9, broke with debian 3.11 (but
> > > works with Ubuntu vanilla LTS 3.11.10.x series), worked with debian
> > > 3.12, broke again with debian 3.13 (but worked again with Ubuntu
> > > vanilla LTS 3.13.11.x series) and finally doesn't work with debian
> > > 3.14 and also not with 3.15, I have yet to try 3.16.
> > > My guess is that a configuration option I'm using (processor timer
> > > frequency 1000 Hz) when building the Ubuntu vanilla LTS kernels is
> > > doing the trick, but then again I don't know why debian 3.12 did work.
> > > Could this faster 1000 Hz vs 250 Hz (default in debian) have anything
> > > to do with this ACPI issue Nvidia reported...
>
> Is this still an issue with the latest driver (390.67) and kernels
> available in sid, buster, and stretch-backports?
>

Sorry I forgot to report back on this issue. Since Debian Jessie (kernel
3.16) and now Debian Wheezy this has been resolved

Re: dkms: Build with an alternative like compiler rather than gcc

2018-07-09 Thread Sedat Dilek 
On Mon, Jul 9, 2018 at 4:43 PM,   wrote:
>> -Original Message-
>> From: Sedat Dilek [mailto:sedat.di...@gmail.com]
>> Sent: Monday, July 9, 2018 9:41 AM
>> To: Limonciello, Mario
>> Cc: p...@hungry.com; da...@debian.org; a...@debian.org;
>> iucul...@debian.org; pkg-dkms-ma...@lists.alioth.debian.org; debian-
>> ker...@lists.debian.org
>> Subject: Re: dkms: Build with an alternative like compiler rather than gcc
>>
>> On Mon, Jul 9, 2018 at 4:37 PM,   wrote:
>> >> -Original Message-
>> >> From: Petter Reinholdtsen [mailto:p...@hungry.com]
>> >> Sent: Monday, July 9, 2018 9:32 AM
>> >> To: sedat.di...@gmail.com; David Paleino; Aron Xu; Limonciello, Mario;
>> Giuseppe
>> >> Iuculano
>> >> Cc: Dynamic Kernel Modules Support Team; debian-kernel@lists.debian.org
>> >> Subject: Re: dkms: Build with an alternative like compiler rather than gcc
>> >>
>> >>
>> >> [Sedat Dilek]
>> >> > As a workaround I have symlinked my mycompiler wrapper-script to
>> >> > /usr/bin/gcc.  That works.
>> >> >
>> >> > What is the recommended way to do this correctly?
>> >>
>> >> Perhaps you should use dpkg-divert to ensure your replaced gcc is not
>> >> lost in a future package upgrade?
>> >>
>> >> The DKMS team in Debian need active members.  I'm not one of them. :(
>> >>
>> >> --
>> >
>> > I think this is an upstream problem not at all specific to Debian's 
>> > implementation.
>> > I would recommend to bring this discussion upstream to get it fixed there.
>> >
>> > I believe DKMS unsets CC before starting build, but maybe that's wrong to 
>> > do
>> > in this instance.
>> >
>>
>> Personally, I do not think it is an upstream problem.
>> Unsetting CC before DKMS starts the build would explain the 
>> behaviour/handling.
>>
>

[ Removing wrong debian's dkms maintainer list ]

> How exactly does clang get used by kernel build?  It's by setting CC variable 
> right?
> You can try to remove this line to see if it fixes the problem (it should).
> https://github.com/dell/dkms/blob/master/dkms#L3515
>

I have an own script which uses bindeb-pkg make-target from Linus tree.

OK, that line looks like the culprit.

Anyway, I need a flexible handling when using different compilers - for me.

> The question would be where that variable should be ignored and where it 
> shouldn't.
> Which I believe is an upstream discussion not a Debian discussion.

I agree.

- sed@ -

RE: dkms: Build with an alternative like compiler rather than gcc

2018-07-09 Thread Mario.Limonciello 
> -Original Message-
> From: Petter Reinholdtsen [mailto:p...@hungry.com]
> Sent: Monday, July 9, 2018 9:32 AM
> To: sedat.di...@gmail.com; David Paleino; Aron Xu; Limonciello, Mario; 
> Giuseppe
> Iuculano
> Cc: Dynamic Kernel Modules Support Team; debian-kernel@lists.debian.org
> Subject: Re: dkms: Build with an alternative like compiler rather than gcc
> 
> 
> [Sedat Dilek]
> > As a workaround I have symlinked my mycompiler wrapper-script to
> > /usr/bin/gcc.  That works.
> >
> > What is the recommended way to do this correctly?
> 
> Perhaps you should use dpkg-divert to ensure your replaced gcc is not
> lost in a future package upgrade?
> 
> The DKMS team in Debian need active members.  I'm not one of them. :(
> 
> --

I think this is an upstream problem not at all specific to Debian's 
implementation.
I would recommend to bring this discussion upstream to get it fixed there.

I believe DKMS unsets CC before starting build, but maybe that's wrong to do
in this instance.

Thanks,

RE: dkms: Build with an alternative like compiler rather than gcc

2018-07-09 Thread Mario.Limonciello 
> -Original Message-
> From: Sedat Dilek [mailto:sedat.di...@gmail.com]
> Sent: Monday, July 9, 2018 9:41 AM
> To: Limonciello, Mario
> Cc: p...@hungry.com; da...@debian.org; a...@debian.org;
> iucul...@debian.org; pkg-dkms-ma...@lists.alioth.debian.org; debian-
> ker...@lists.debian.org
> Subject: Re: dkms: Build with an alternative like compiler rather than gcc
> 
> On Mon, Jul 9, 2018 at 4:37 PM,   wrote:
> >> -Original Message-
> >> From: Petter Reinholdtsen [mailto:p...@hungry.com]
> >> Sent: Monday, July 9, 2018 9:32 AM
> >> To: sedat.di...@gmail.com; David Paleino; Aron Xu; Limonciello, Mario;
> Giuseppe
> >> Iuculano
> >> Cc: Dynamic Kernel Modules Support Team; debian-kernel@lists.debian.org
> >> Subject: Re: dkms: Build with an alternative like compiler rather than gcc
> >>
> >>
> >> [Sedat Dilek]
> >> > As a workaround I have symlinked my mycompiler wrapper-script to
> >> > /usr/bin/gcc.  That works.
> >> >
> >> > What is the recommended way to do this correctly?
> >>
> >> Perhaps you should use dpkg-divert to ensure your replaced gcc is not
> >> lost in a future package upgrade?
> >>
> >> The DKMS team in Debian need active members.  I'm not one of them. :(
> >>
> >> --
> >
> > I think this is an upstream problem not at all specific to Debian's 
> > implementation.
> > I would recommend to bring this discussion upstream to get it fixed there.
> >
> > I believe DKMS unsets CC before starting build, but maybe that's wrong to do
> > in this instance.
> >
> 
> Personally, I do not think it is an upstream problem.
> Unsetting CC before DKMS starts the build would explain the 
> behaviour/handling.
> 

How exactly does clang get used by kernel build?  It's by setting CC variable 
right?
You can try to remove this line to see if it fixes the problem (it should).
https://github.com/dell/dkms/blob/master/dkms#L3515

The question would be where that variable should be ignored and where it 
shouldn't.
Which I believe is an upstream discussion not a Debian discussion.

Re: dkms: Build with an alternative like compiler rather than gcc

2018-07-09 Thread Sedat Dilek 
On Mon, Jul 9, 2018 at 4:37 PM,   wrote:
>> -Original Message-
>> From: Petter Reinholdtsen [mailto:p...@hungry.com]
>> Sent: Monday, July 9, 2018 9:32 AM
>> To: sedat.di...@gmail.com; David Paleino; Aron Xu; Limonciello, Mario; 
>> Giuseppe
>> Iuculano
>> Cc: Dynamic Kernel Modules Support Team; debian-kernel@lists.debian.org
>> Subject: Re: dkms: Build with an alternative like compiler rather than gcc
>>
>>
>> [Sedat Dilek]
>> > As a workaround I have symlinked my mycompiler wrapper-script to
>> > /usr/bin/gcc.  That works.
>> >
>> > What is the recommended way to do this correctly?
>>
>> Perhaps you should use dpkg-divert to ensure your replaced gcc is not
>> lost in a future package upgrade?
>>
>> The DKMS team in Debian need active members.  I'm not one of them. :(
>>
>> --
>
> I think this is an upstream problem not at all specific to Debian's 
> implementation.
> I would recommend to bring this discussion upstream to get it fixed there.
>
> I believe DKMS unsets CC before starting build, but maybe that's wrong to do
> in this instance.
>

Personally, I do not think it is an upstream problem.
Unsetting CC before DKMS starts the build would explain the behaviour/handling.

- sed@ -

Re: dkms: Build with an alternative like compiler rather than gcc

2018-07-09 Thread Sedat Dilek 
On Mon, Jul 9, 2018 at 4:31 PM, Petter Reinholdtsen  wrote:
>
> [Sedat Dilek]
>> As a workaround I have symlinked my mycompiler wrapper-script to
>> /usr/bin/gcc.  That works.
>>
>> What is the recommended way to do this correctly?
>
> Perhaps you should use dpkg-divert to ensure your replaced gcc is not
> lost in a future package upgrade?
>
> The DKMS team in Debian need active members.  I'm not one of them. :(
>

I am thinking of using mycompiler as an cc alternative, the same with
c++ and cpp.
The wrapper-script(s) let me pass compiler-options, too.
So this is very flexible.

Active members... the alioth email-adress in the dsc-file seems no longer valid.

Thanks for the response.

- sed@ -

Re: dkms: Build with an alternative like compiler rather than gcc

2018-07-09 Thread Petter Reinholdtsen 


[Sedat Dilek]
> As a workaround I have symlinked my mycompiler wrapper-script to
> /usr/bin/gcc.  That works.
>
> What is the recommended way to do this correctly?

Perhaps you should use dpkg-divert to ensure your replaced gcc is not
lost in a future package upgrade?

The DKMS team in Debian need active members.  I'm not one of them. :(

-- 
Happy hacking
Petter Reinholdtsen

dkms: Build with an alternative like compiler rather than gcc

2018-07-09 Thread Sedat Dilek 
Hi,

I am experimenting with clang to compile an upstream Linux kernel
v4.14.y (here: y=54).
For this I use bindeb-pkg make-target from Linus upstream.

After installing the generated linux-headers and linux-image amd64
packages, the dkms kernel-modules were built with gcc-7 which defaults
to gcc.
As a result acpi-call and virtualbox dkms modules do not load (see [1]).

As a workaround I have symlinked my mycompiler wrapper-script to /usr/bin/gcc.
That works.

What is the recommended way to do this correctly?
Is there an CC option for dkms.conf?
Use the update-alternatives system for configuring/installing clang as
an cc-alternative?

Thanks.

Regards,
- Sedat -

[1] https://lkml.org/lkml/2018/6/1/724
[2] 
https://stackoverflow.com/questions/7832892/how-to-change-the-default-gcc-compiler-in-ubuntu

P.S.: Some instructions and informations which might be helpful

root@iniza# LANG=C update-alternatives --display cc
cc - auto mode
  link best version is /usr/bin/gcc
  link currently points to /usr/bin/gcc
  link cc is /usr/bin/cc
/usr/bin/gcc - priority 20

root# dpkg --purge tp-smapi-dkms <--- XXX: Does not work with Lenovo
ThinkPad T470

root# dkms status -k 4.14.54-1-iniza-llvmlinux
acpi-call, 1.1.0, 4.14.54-1-iniza-llvmlinux, x86_64: installed
virtualbox, 5.2.10, 4.14.54-1-iniza-llvmlinux, x86_64: installed

root# dkms remove acpi-call -v 1.1.0 -k 4.14.54-1-iniza-llvmlinux
root# dkms remove virtualbox -v 5.2.10 -k 4.14.54-1-iniza-llvmlinux

root# cat /usr/bin/mycompiler
#!/bin/bash

ccache clang-7 "$@"

root# cd /usr/bin ; ln -sf mycompiler gcc <--- XXX: Workaround

root# LANG=C dkms install acpi-call -v 1.1.0 -k 4.14.54-1-iniza-llvmlinux
root# LANG=C dkms install virtualbox -v 5.2.10 -k 4.14.54-1-iniza-llvmlinux

root# cd /usr/bin ; ln -sf gcc-7 gcc <--- XXX: System default

Bug#903393: [initramfs-tools] update-initramfs -u warns: Unknown X keysym "dead_belowmacron"

2018-07-09 Thread kardan 
Package: initramfs-tools
Version: 0.130
Severity: normal

I experienced this when apt triggered initramfs-tools:

Trigger für initramfs-tools (0.130) werden
verarbeitet ... update-initramfs:
Generating /boot/initrd.img-4.16.0-2-686 WARNING: Unknown X keysym
"dead_belowmacron" WARNING: Unknown X keysym "dead_belowmacron"
WARNING: Unknown X keysym "dead_belowmacron"
WARNING: Unknown X keysym "dead_belowmacron"
W: APT had planned for dpkg to do more than it reported back (15 vs
19). Affected packages: udev:i386

It is reproducable running 

# update-initramfs -u||echo "Failed."
update-initramfs:
Generating /boot/initrd.img-4.16.0-2-686 WARNING: Unknown X keysym
"dead_belowmacron" WARNING: Unknown X keysym "dead_belowmacron"
WARNING: Unknown X keysym "dead_belowmacron"
WARNING: Unknown X keysym "dead_belowmacron"

The command ends without error. Let me know, if you know more info.

For reference:
https://bugs.freedesktop.org/show_bug.cgi?id=35527
https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/738314

This is buster upgraded to testing with some packages installed from
sid.

# apt policy initramfs-tools
initramfs-tools:
  Installed: 0.130
  Candidate: 0.130
  Version table:
 *** 0.130 500
500 http://ftp.de.debian.org/debian buster/main i386 Packages
100 /var/lib/dpkg/status

# apt policy xkb-data
xkb-data:
  Installed: 2.23.1-1
  Candidate: 2.23.1-1
  Version table:
 *** 2.23.1-1 500
500 http://ftp.de.debian.org/debian buster/main i386
Packages 100 /var/lib/dpkg/status

# apt policy console-setup
console-setup:
  Installed: 1.184
  Candidate: 1.184
  Version table:
 *** 1.184 500
500 http://ftp.de.debian.org/debian buster/main i386
Packages 100 /var/lib/dpkg/status

# apt policy xkeyboard-config
xkeyboard-config:
  Installed: (none)
  Candidate: (none)
  Version table:

--- System information. ---
Architecture: 
Kernel:   Linux 4.16.0-2-686

Debian Release: buster/sid
  500 testing-debug   debug.mirrors.debian.org 
  500 testing ftp.de.debian.org 

--- Package information. ---
Depends   (Version) | Installed
===-+-===
initramfs-tools-core  (= 0.130) | 0.130
linux-base  | 4.5


Package's Recommends field is empty.

Suggests (Version) | Installed
==-+-===
bash-completion| 1:2.8-1



--- Output from package bug script ---
-- initramfs sizes
-rw-r--r-- 1 root root 22M Apr 24 21:21 /boot/initrd.img-4.15.0-2-686
-rw-r--r-- 1 root root 22M Jun  9 18:44 /boot/initrd.img-4.16.0-1-686
-rw-r--r-- 1 root root 22M Jul  9 13:34 /boot/initrd.img-4.16.0-2-686
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.16.0-2-686 root=/dev/mapper/ ro quiet

-- resume
RESUME=/dev/mapper/
-- /proc/filesystems
ext3
ext2
ext4
squashfs
fuseblk

-- lsmod
Module  Size  Used by
rpcsec_gss_krb532768  0
nfsv4 454656  0
fuse   90112  1
dns_resolver   16384  1 nfsv4
nfs   192512  1 nfsv4
fscache45056  2 nfsv4,nfs
iTCO_wdt   16384  0
iTCO_vendor_support16384  1 iTCO_wdt
ipw2200   131072  0
libipw 32768  1 ipw2200
snd_intel8x0   32768  2
snd_ac97_codec 98304  1 snd_intel8x0
lib80211   16384  1 libipw
pcmcia 49152  0
radeon   1347584  6
ac97_bus   16384  1 snd_ac97_codec
cfg80211  462848  2 ipw2200,libipw
ttm65536  1 radeon
drm_kms_helper122880  1 radeon
snd_pcm81920  2 snd_ac97_codec,snd_intel8x0
yenta_socket   36864  0
pcmcia_rsrc20480  1 yenta_socket
pcmcia_core20480  3 yenta_socket,pcmcia,pcmcia_rsrc
drm   299008  9 radeon,ttm,drm_kms_helper
joydev 20480  0
evdev  20480  19
i2c_algo_bit   16384  1 radeon
fb_sys_fops16384  1 drm_kms_helper
lpc_ich24576  0
serio_raw  16384  0
syscopyarea16384  1 drm_kms_helper
pcspkr 16384  0
sysfillrect16384  1 drm_kms_helper
thinkpad_acpi  65536  0
sysimgblt  16384  1 drm_kms_helper
rng_core   16384  0
snd_timer  28672  1 snd_pcm
sg 32768  0
button 16384  0
nvram  16384  1 thinkpad_acpi
snd61440  9
snd_ac97_codec,snd_timer,thinkpad_acpi,snd_intel8x0,snd_pcm
soundcore  16384  1 snd rfkill 20480  3
thinkpad_acpi,cfg80211 shpchp 32768  0
battery20480  0
ac 16384  0
video  36864  1 thinkpad_acpi
acpi_cpufreq   20480  1
squashfs   45056  2
zstd_decompress65536  1 squashfs
xxhash 20480  1 zstd_decompress
loop

Bug#720528: nvidia: driver fails kernel 3.10+ (GeForce 600M and 700M series)

2018-07-09 Thread Andreas Beckmann 
Control: tag -1 moreinfo

On Sat, 23 Aug 2014 22:53:48 -0700 Ben Hutchings 
wrote:
> On Sat, 2014-08-23 at 20:14 -0700, Andres Cimmarusti wrote:
> > Let me re-state: worked with debian 3.9, broke with debian 3.11 (but
> > works with Ubuntu vanilla LTS 3.11.10.x series), worked with debian
> > 3.12, broke again with debian 3.13 (but worked again with Ubuntu
> > vanilla LTS 3.13.11.x series) and finally doesn't work with debian
> > 3.14 and also not with 3.15, I have yet to try 3.16.
> > My guess is that a configuration option I'm using (processor timer
> > frequency 1000 Hz) when building the Ubuntu vanilla LTS kernels is
> > doing the trick, but then again I don't know why debian 3.12 did work.
> > Could this faster 1000 Hz vs 250 Hz (default in debian) have anything
> > to do with this ACPI issue Nvidia reported...

Is this still an issue with the latest driver (390.67) and kernels
available in sid, buster, and stretch-backports?


Andreas

Processed: Re: Bug#720528: nvidia: driver fails kernel 3.10+ (GeForce 600M and 700M series)

2018-07-09 Thread Debian Bug Tracking System 
Processing control commands:

> tag -1 moreinfo
Bug #720528 [src:linux] nvidia: driver fails kernel 3.10+ (GeForce 600M and 
700M series)
Added tag(s) moreinfo.

-- 
720528: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720528
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#883294: Bug 197769 - kernel panic IO-APIC + timer (AMD CPU) from 4.13 onwards

2018-07-09 Thread Matthias Schönfeld 
Have you noticed
https://bugzilla.kernel.org/show_bug.cgi?id=197769
*Bug 197769*  -
kernel panic IO-APIC + timer (AMD CPU) from 4.13 onwards
seems very similiar to this debian-bug.

In this context:

> > > - Instead of not using IO-APIC completly, could you try to boot with

> > > kernel parameter "no_timer_check" ?

> > >

"no_timer_check" does not help me on FSC Esprimo P5615 with kernel 4.15.