Bug#1061521: + XPS 13 9343

[Hans de Goede]

Hi Antoine,

On 2/3/24 17:16, Antoine wrote:
> On 1/20/24 21:26, Hans de Goede wrote:
>> Can you try adding "i8042.dumbkbd=1" to your kernel commandline?
>>
>> The next question is if the keyboard will still actually
>> work after suspend/resume with "i8042.dumbkbd=1". If it
>> stays in the list, but no longer works
> 
> Hi, thanks a lot for taking into account our hardware,
> just a supplementary feedback:
> 
> In my case (Dell XPS 13 9343/i5-5200U):
> - Dell Inc. XPS 13 9343/0TM99H, BIOS A19 12/24/2018
> - Linux version 6.6.13-1 (2024-01-20)
> 
> commandline with `i8042.dumbkbd=1` fixes the issue,
> with capslock functional but without led
> + as a side note, hibernate doesn't trigger any issue
> 
> (before getting informed of and testing `i8042.dumbkbd=1`)
> I had attached logs before/after suspend against 6.6.11 and 6.6.13 :
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061521#30
> 
> I remain at your disposal for any further infos/testing

The issue of the kbd on some Dell XPS models no longer
working after a suspend/resume cycle should be fixed by
these 2 patches which are on their way to Linus' tree:

https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=for-linus=683cd8259a9b883a51973511f860976db2550a6e
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=for-linus=9cf6e24c9fbf17e52de9fff07f12be7565ea6d61

Regards,

Hans

Bug#1036968: included in 6.6.9-1

[Hans-Christoph Steiner]

For the record, the module was included starting in 6.6.9-1:

$ grep -i CS35L41 /boot/config-6.6.9-amd64
CONFIG_SND_HDA_SCODEC_CS35L41=m
CONFIG_SND_HDA_SCODEC_CS35L41_I2C=m
CONFIG_SND_HDA_SCODEC_CS35L41_SPI=m
CONFIG_SND_SOC_CS35L41_LIB=m
CONFIG_SND_SOC_CS35L41=m
CONFIG_SND_SOC_CS35L41_SPI=m
CONFIG_SND_SOC_CS35L41_I2C=m

Bug#1036968: fixed

[Hans-Christoph Steiner]

Control: fixed 1036968 6.6.9-1
Control: fixed 1036968 6.6.11-1

With 6.6.11-1, the headphone jack insert detection is now working when running 
on bookworm.

Re: debian kernel pickup startegy vs linux LTS kernels

[Hans van Kranenburg]

Hi Eric,

I think I can help answering this one. It's a good question.

On 8/5/23 10:43, Eric Valette wrote:
> Hi Debian kernel maintainers,
> 
> I have a question regarding the way kernel versions are selected for the 
> stable tree. [...]
> [...]
> 
> So I have reverted to 6.1.x release for many machines and put the 
> package on hold.
> 
> apt-cache policy linux-image-amd64
> linux-image-amd64:
>Installé : 6.1.38-2
>Candidat : 6.4.4-2
>   Table de version :
>   6.4.4-2 500
>  500 http://ftp.fr.debian.org/debian unstable/main amd64 Packages
>   *** 6.1.38-2 500
>  500 http://security.debian.org/debian-security 
> bookworm-security/main amd64 Packages
>  100 /var/lib/dpkg/status
> 
> Two days ago, I was a bit surprised to see that only 6.1.38-2 was pushed 
> to correct zenbleed while at least 6.1.41 was available for a week or so 
> and we are now at 6.1.43.
> 
> So my questions are:
> 
>   - Why did you not pick up the last LTS version?

The 6.1.38-2 package version is a security update. It has two extra
included patches compared to the previous 6.1.38-1.

https://tracker.debian.org/news/1449038/accepted-linux-6138-2-source-into-stable-security/

When preparing a security update, first an attempt is made to provide a
new package containing the needed fixes, and at the same time having the
least possible amount of other changes included. In this case, it seems
this was possible, by just picking two new upstream changes, still on
top of the source version 6.1.38.

>   - On what occasion do you pick up a new LTS kernel for the
> stable branch? Is there any formal rule?

For regular Debian stable point releases, which tend to happen about
every two months, there usually will be a package update that follows
the stable upstream branch. At that point, the upstream source will be
updated to whatever is current upstream (LTS) stable version, and the
separately added security patches can be dropped again.

The security updates happen 'in between' the normal point releases, and
by trying to keep them as small as possible, we also might for example
accommodate users who treat installing a security update differently
than a stable point release.

Extra...1!

After a security update is published, it also automatically gets queued
for stable-proposed-updates (for the next official point release). At
https://tracker.debian.org/pkg/linux this is visible at 2023-07-31,
where it happens a day later:

https://tracker.debian.org/news/1449227/accepted-linux-6138-2-source-into-proposed-updates/

So, even if for some reason there would not be a separate update for the
point release, the earlier security update will then be the version that
gets included.

Extra...2!

In some exceptional situations, it might be desirable to already provide
a new package with a new upstream (LTS/stable) kernel version, for
reasons that do not warrant doing a security update. For example, there
might be some non-trivial regression bugs that hit a bunch of users with
specific use cases / hardware. If downgrading to the previous package
version as workaround is also not an option because of some serious
other problem, the kernel team might decide to do some extra work
already to help those users get out of the uncomfortable situation right
now. (These should be exceptional ;])

In that case, the kernel team can already do similar work as would
otherwise be done later (closer to the Debian stable point release
date), and for example already upload a package with new upstream source
version. In that case, it also gets uploaded to stable-proposed-update,
and users who really want or need it, can install it from there.

It's officially signed (the package repository) and at least the users
do not need to build it themselves etc.

> No criticism just curious : I can always pick up the Debian kernel, the 
> Debian config, slightly modify it for the kernel signature and sign the 
> produced kernel and modules. Just that given the handful of modules I do 
> not need, this is time consuming and I find myself out of normal Debian 
> path.

Thanks, have fun!
Hans

Bug#1036968: Ubuntu 22.04 includes it

[Hans-Christoph Steiner]

The sound works with Ubuntu 22.04.  This laptop family (Dell XPS) is listed as 
supported by Ubuntu on their site.  It is the same hardware as the Dell XPS 13 Plus:

https://ubuntu.com/certified/202112-29802

The Ubuntu/jammy 22.04 kernel includes this same list of modules as listed in 
kernel.org issue:


https://packages.ubuntu.com/jammy/amd64/linux-buildinfo-5.15.0-78-generic/download

$ grep -i CS35L41 
linux-buildinfo-5.15.0-78-generic_5.15.0-78.85_amd64/usr/lib/linux/5.15.0-78-generic/config 


CONFIG_SND_HDA_SCODEC_CS35L41=m
CONFIG_SND_HDA_SCODEC_CS35L41_I2C=m
CONFIG_SND_HDA_SCODEC_CS35L41_SPI=m
CONFIG_SND_SOC_CS35L41_LIB=m
CONFIG_SND_SOC_CS35L41=m
CONFIG_SND_SOC_CS35L41_SPI=m
CONFIG_SND_SOC_CS35L41_I2C=m

This machine is setup with Secure Boot, and not setup to sign its own kernels. 
So testing it in Debian would not be easy for me until its shipped in a signed 
kernel.

Bug#1036968: linux: Enable CONFIG_SND_SOC_CS35L41_I2C for Intel Alder Lake sound

[Hans-Christoph Steiner]

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

Dear Maintainer,

I installed Debian on a Dell XPS 17 9720:
https://wiki.debian.org/InstallingDebianOn/Dell/XPS%2017%209720

The audio output works, but there are a number of problems:

* Headphone plug detection does not work at all.
* No audio input is detected.
* The audio crashes after a couple of days.

This bug goes through some of the development efforts to fix this:
https://bugzilla.kernel.org/show_bug.cgi?id=216194

One thing they said there is that all CS35L41 modules need to be
enabled.  This is the recommended set:

CONFIG_SND_HDA_SCODEC_CS35L41=m
CONFIG_SND_HDA_SCODEC_CS35L41_I2C=m
CONFIG_SND_HDA_SCODEC_CS35L41_SPI=m
CONFIG_SND_SOC_CS35L41_LIB=m
CONFIG_SND_SOC_CS35L41=m
CONFIG_SND_SOC_CS35L41_SPI=m
CONFIG_SND_SOC_CS35L41_I2C=m

There is one module still not enabled in the Debian kernels (6.1.0-8,
6.3.2-1~exp1, and 6.3.4-1~exp1):

$ grep CS35L41 /boot/config-6.3.0-0-amd64
CONFIG_SND_HDA_SCODEC_CS35L41=m
CONFIG_SND_HDA_SCODEC_CS35L41_I2C=m
CONFIG_SND_HDA_SCODEC_CS35L41_SPI=m
CONFIG_SND_SOC_CS35L41_LIB=m
CONFIG_SND_SOC_CS35L41=m
CONFIG_SND_SOC_CS35L41_SPI=m
# CONFIG_SND_SOC_CS35L41_I2C is not set

Could this module be enabled?


-- Package-specific info:
** Version:
Linux version 6.3.0-0-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC 
Debian 6.3.2-1~exp1 (2023-05-15)


** Command line:
BOOT_IMAGE=/vmlinuz-6.3.0-0-amd64 root=/dev/mapper/monolith--vg-root ro quiet

** Tainted: W (512)
 * kernel issued warning

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

** Model information
sys_vendor: Dell Inc.
product_name: XPS 17 9720
product_version:
chassis_vendor: Dell Inc.
chassis_version:
bios_vendor: Dell Inc.
bios_version: 1.14.0
board_vendor: Dell Inc.
board_name: 0TW02W
board_version: A00

** Loaded modules:
tls
tun
mmc_block
r8153_ecm
r8152
ctr
ccm
rfcomm
cmac
algif_hash
algif_skcipher
af_alg
wireguard
libchacha20poly1305
chacha_x86_64
poly1305_x86_64
curve25519_x86_64
libcurve25519_generic
libchacha
ip6_udp_tunnel
udp_tunnel
snd_seq_dummy
snd_hrtimer
snd_seq
snd_seq_device
qrtr
overlay
bnep
binfmt_misc
nls_ascii
nls_cp437
vfat
fat
snd_ctl_led
snd_soc_sof_sdw
snd_soc_intel_hda_dsp_common
snd_sof_probes
snd_soc_intel_sof_maxim_common
snd_soc_rt711_sdca
snd_soc_rt715_sdca
regmap_sdw_mbq
snd_soc_rt1316_sdw
snd_hda_codec_hdmi
regmap_sdw
snd_soc_dmic
snd_sof_pci_intel_tgl
snd_sof_intel_hda_common
soundwire_intel
soundwire_generic_allocation
soundwire_cadence
snd_sof_intel_hda
snd_sof_pci
snd_sof_xtensa_dsp
snd_sof
snd_sof_utils
x86_pkg_temp_thermal
snd_soc_hdac_hda
intel_powerclamp
snd_hda_ext_core
coretemp
snd_soc_acpi_intel_match
iwlmvm
snd_soc_acpi
btusb
kvm_intel
btrtl
snd_soc_core
btbcm
btintel
btmtk
mac80211
snd_compress
kvm
soundwire_bus
bluetooth
snd_hda_intel
snd_intel_dspcfg
snd_intel_sdw_acpi
snd_hda_codec
uvcvideo
libarc4
snd_hda_core
videobuf2_vmalloc
irqbypass
uvc
dell_laptop
dell_wmi
iwlwifi
snd_hwdep
jitterentropy_rng
videobuf2_memops
rapl
dell_smbios
ledtrig_audio
mei_hdcp
snd_pcm
mei_pxp
drbg
hid_sensor_als
ucsi_acpi
intel_rapl_msr
videobuf2_v4l2
processor_thermal_device_pci
dcdbas
intel_cstate
ansi_cprng
dell_wmi_sysman
hid_sensor_trigger
processor_thermal_device
cfg80211
iTCO_wdt
ecdh_generic
intel_uncore
videodev
dell_wmi_ddv
dell_wmi_descriptor
firmware_attributes_class
wmi_bmof
pcspkr
typec_ucsi
snd_timer
hid_sensor_iio_common
processor_thermal_rfim
mei_me
intel_pmc_bxt
industrialio_triggered_buffer
processor_thermal_mbox
videobuf2_common
roles
snd
iTCO_vendor_support
kfifo_buf
processor_thermal_rapl
mc
industrialio
mei
watchdog
ecc
soundcore
rfkill
igen6_edac
typec
intel_rapl_common
int3403_thermal
int340x_thermal_zone
int3400_thermal
intel_hid
acpi_thermal_rel
sparse_keymap
acpi_tad
intel_pmc_core
acpi_pad
cdc_mbim
joydev
cdc_wdm
ac
hid_multitouch
evdev
serio_raw
nfsd
auth_rpcgss
nfs_acl
lockd
grace
sunrpc
fuse
msr
loop
configfs
efi_pstore
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
btrfs
blake2b_generic
dm_crypt
dm_mod
efivarfs
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
cdc_ncm
cdc_ether
usbnet
mii
raid6_pq
libcrc32c
crc32c_generic
raid1
raid0
multipath
linear
md_mod
usbhid
hid_sensor_custom
hid_sensor_hub
intel_ishtp_hid
i915
drm_buddy
i2c_algo_bit
crc32_pclmul
drm_display_helper
crc32c_intel
nvme
cec
nvme_core
ghash_clmulni_intel
rc_core
sha512_ssse3
ttm
t10_pi
hid_generic
xhci_pci
sha512_generic
crc64_rocksoft_generic
drm_kms_helper
crc64_rocksoft
xhci_hcd
rtsx_pci_sdmmc
crc_t10dif
mmc_core
crct10dif_generic
i2c_hid_acpi
usbcore
intel_lpss_pci
crct10dif_pclmul
aesni_intel
video
i2c_i801
intel_ish_ipc
i2c_hid
intel_lpss
crc64
drm
psmouse
thunderbolt
crypto_simd
rtsx_pci
i2c_smbus
intel_ishtp
idma64
usb_common
crct10dif_common
cryptd
hid
battery
wmi
button

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:4621] (rev 02)
  

Bug#1001805: linux-image-5.10.0-9-amd64: Permanent blinking of wireless led

[Hans-J. Ullrich]

Package: linux-image-5.10.0-9-amd64
Version: 5.10.70-1
Severity: normal

Dear Maintainer,


with the latest kernel version (change from *-8-amd64 to *-9-amd64 and higher), 
I discovered an annoying issue.
This issue shows, that the wireless led is permanently blinking, but it should 
only blink, when real traffic is 
received. 

Examination showed, that the permanent blinking is caused by the router (it is 
a Fritz!Box), which is permanently
sending brodcast traffic. However, the indication of broadcast traffic with the 
led was suppressed in kernels with version -8-amd64 and lower, and only "real" 
traffic was indicated by the led.

Behaving this way, the led indication is very useful, as normal traffic will 
let the led blink during traffic I know I had initiated (like calling a 
website). Permanently blinking showed, something fishy is going on and I should 
examine it: Is a download/update running? Is there a large mail coming? Does 
someone have access to my system? Is there a bruteforce attack ongoing? 

So, this function is really important for me, and I would like to have it back. 
At the moment I am staying with kernel *-8-amd64. Please note, I saw this on 
kali linux, too.

I believe, this issue is in the atheros module (I am using an AR542x Wireless 
card), and the module is ath5.ko.

If this is really an issue in this module, please take a look at the ath9.ko 
module, maybe the same issue appears there, too.

It would be very nice, if you could take a look at this. Please feel free, to 
ask for more information. 

Network dumps or whatever can be delivered, if needed.

Thank you very much for reading this and any help.

Best regards

Hans
 
 
-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CRAP, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-5.10.0-9-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.140
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-5.10.0-9-amd64 recommends:
ii  apparmor 2.13.6-10
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.10.0-9-amd64 suggests:
pn  debian-kernel-handbook  
ii  extlinux3:6.04~git20190206.bf6db5b4+dfsg1-3+b1
ii  grub-pc 2.04-20
pn  linux-doc-5.10  

Bug#1001409: Add privacy screen modules to the initrd

[Hans de Goede]

Package: initramfs-tools

Starting with kernel 5.17 the kernel supports the builtin privacy screens built 
into the LCD panel of some new laptop models.

This means that the drm drivers will now return -EPROBE_DEFER from their 
probe() method on models with a builtin privacy screen when the privacy screen 
provider driver has not been loaded yet.

To avoid any regressions Debian should modify its initrd generation tool to 
include privacy screen provider drivers in the initrd (at least on systems with 
a privacy screen), before 5.17 kernels start showing up in the Debian repos.

If this change is not made, then users using a graphical bootsplash (plymouth) 
will get an extra boot-delay of up to 8 seconds (DeviceTimeout in 
plymouthd.defaults) before plymouth will show and when using disk-encryption 
where the LUKS password is requested from the initrd, the system may fallback 
to text-mode after these 8 seconds.

I've written a patch with the necessary changes for dracut, which might be 
useful as an example for how to deal with this, see: 
https://github.com/dracutdevs/dracut/pull/1666

ATM the only kms driver using privacy screens is the i915 driver and the only 
provider is the thinkpad_acpi driver. But both are likely to change (and change 
soon!), so the detection really should be made dynamic as has been done in the 
dracut patch.

Note I've also filed a bug for this for Ubuntu in launchpad:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1954320

Bug#998173: linux-image-5.10.0-9-amd64: with kernel version 5.10.0-9-amd64 LED is permanently blinking

[Hans-J. Ullrich]

Package: linux-image-5.10.0-9-amd64
Severity: normal

Dear Maintainer,

with the upgrade from kernel version 5.10.0-8-amd64 to version 0-9-amd64 I 
notice a very annoying issue with my wireless card.

Problem is, the LED is permanently blinking, not (as it was with the former 
kernel) when there is real trffic.

The kernel module which is responsible for that, is ath5k.ko (This is an 
Atheros card)
Normally the wireless LED only blinks, when there is real traffic aimed to my 
IP. 
However, with 0-9- the LED is permanently blinking. 

I could verify, that it is no traffic created by the notebook itself (used 
tcpdump) and killed all network processes (daemons/apps whatever) running on 
the system.

But even when there were no processes running except the one needed for the 
connection with the router, the LED kept on blinking.

Further investigation showed, that the blinking appeared due to the broadcast 
packages sent by the router. The wireless card thinks, this is normal traffic 
and the LED blinks.

This is bad for me, as the LED was in the past often a good sign, when 
soemthing fishy is going on. If the LED is only blinking from time to time, 
everything is ok, but when it was blinking som,ething special is going on 
(i.e. an update is running or freshclam is updating, but also some brute force 
attacks could also be discovered.) 

It would be nice, if you could examine, what has changed at the new kernel, and 
I would be happy, when I 
could get the old behaviour back.

At the moment I reverted back to kernel 5.10.0-8-0*, which is running perfectly.

Thank you very much for all the help!

Best regards

Hans


-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#988333: [Pkg-xen-devel] linux-image-5.10.0-6-amd64: VGA Intel IGD Passthrough to Debian Xen HVM DomUs not working, but Windows Xen HVMs do work

[Hans van Kranenburg]

Hi!

On 10/19/21 5:44 AM, Chuck Zmudzinski wrote:
> On 5/10/2021 1:33 PM, Chuck Zmudzinski wrote:
>> [...] with buster and bullseye running as the Dom0, I can only get the 
>> VGA/Passthrough feature to work with Windows Xen HVMs. I would expect both 
>> Windows and Linux HVMs to work comparably well.

You don't mention the used Xen version (Debian package version) for
buster and bullseye anywhere, so I'll assume it's the latest
4.14.3-1(~deb11u1) one.

> [...]
> 
> The biggest problems were that the Dom0 reported problems
> with IRQ 16 being disabled after starting the bullseye HVM DomU,
> and only xl destroy could be used to stop the corrupted process.

Well, at least we have an error somewhere already. That's a starting point.

Can you share the domU config file?

And, other configs you need to have in place to exclude the devices from
being seen as normal devices directly in dom0? (I haven't used
passthrough myself yet, but I read that this is needed.)

Can you share more verbose logging done by xl create when using xl -vvv
create ?

But, AFAIK what you want to do should be possible yes.

> The bullseye HVM DomU still fails to boot on an up-to-date
> bullseye Xen Dom0 configured to pass through the same PCI/IGD
> devices. The bullseye HVM DomU with IGD passthrough has so
> far only been verified to work on an old, slightly modified
> jessie Xen Dom0.
> 
> More Details: These latest tests are with linux version 5.10.70-1
> for bullseye stable. For the jessie Dom0, which worked with the
> unmodified bullseye HVM DomU, I had to add a few patches to
> the old jessie Xen packages so the unmodified bullseye Xen HVM

Ok, yes, clear, that makes the domU kernel not the primary suspect.

> These tests demonstrate that a fix for this bug is possible in src:xen
> rather than in src:linux, but the patches needed to fix this bug in
> Xen 4.14, which is the version of Xen on bullseye, are not yet
> identified.

It might also be possible (just a wild guess) that for Xen 4.14, the
options in the domU config file need to be different than for Xen 4.4.

> I will continue to investigate this issue and try to bisect the problem
> as it recurs in Dom0 for some version of Xen > 4.4 and <= 4.14. It
> will obviously take some time since there are so many differences
> between Xen 4.4 and 4.14.

If you can make progress on that, and find an actual commit that changes
the behavior, then we're probably at 95% towards finding a cause and
solution. :) That'd be great.

A possible time-saver that I can recommend is to send a post to the
upstream xen-users list [0] about this already. Like "Hi all, I'm
starting a HVM Linux domU with Linux 5.10.70 on a Xen 4.14.3 system with
also 5.10.70 dom0 kernel, with this and this domU config file. It fails
to start, this is the xl -vvv create output, and this error (the irq
stuff) appears in the dom0 kernel log.". Try to keep it simple and not
too long initially, without the surrounding stories, to increase chance
of it being fully read.

> If I find a fix in src:xen for Xen >=4.14 Dom0 on bullseye or sid, I will
> reassign #988333 to src:xen myself. Until then, I will leave it to the
> discretion of the Debian Kernel Team to decide whether or not to
> reassign it to src:xen now.

Yes, that makes sense indeed, I'll do it in a minute. Even while we
don't know if it has to do with the Xen or dom0 kernel code, it's more
likely that in either case, we'll end up asking the upstream Xen people
about it.

Have fun,
Hans

[0] https://lists.xenproject.org/mailman/listinfo/xen-users

Bug#991967: Simply ACPI powerdown/reset issue?

[Hans van Kranenburg]

th Fixes: 1c4aa69ca1e1, but I
agree with Diederik that we should keep them all together.

I do not know if this is also the thing Chuck tested in the end, but I'm
a bit lost in the walls of text that were produced in these two bugs.

https://salsa.debian.org/xen-team/debian-xen/-/merge_requests/14

These fixes were actually posted before 4.14.0+88-g1d1d1f5391-2
happened. It's unfortunate that we did not notice it, since the above
could have been part of the package that was in the archive when Debian
11 released. Or if anyone owning the specific type of hardware had ran
into it during testing during the freeze, we could also have found them
in time. But yeah, that happens.

Diederik, I think we should omit the 5th one, since it's a cosmetics
commit, which also starts touching (older) code unrelated to this issue.

What I plan to do is include these as regression fixes in the next
package update. The issue is only affecting a subset of hardware types.
There's a workaround (pull the plug), the fixes are known. There is no
security risk, there is no data corruption or unexpected crashes during
normal operation.

Hans

Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709

[Hans van Kranenburg]

Hi spi, Salvatore,

On 8/5/21 1:58 PM, s...@gmxpro.de wrote:
> 
> In preparation for the bug report for upstream I did some more
> investigation.
> 
> The kernel panic also occurs without bonding interfaces but needs much
> more time to happen. With a bonding interface it happens within some
> seconds. Without bonding interfaces it needs like a minute with the
> network discovery being re-launched for 2 or 3 times. The kernel panic
> is still the same about the bnx2 driver.
> 
> In the constellation without a bonding interface the kernel panic only
> occurs if
> - opnsense as a domU is running (this domU bounds all bridged interfaces
> as default gateway for all networks)

Just FWIW, I'm seeing this bug-mail-thread now, and it rings a bell.

I spent some time in the past to debug crashing BCM5719 (4x1G) nics in
HP DL360 G8/9 series servers. In this case, the firmware inside the nic
crashed, so the symptoms were different. This happened only when having
a Xen domU active as router, which was routing incoming traffic packets
(from outside the box) back to the outside again.

02:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit
Ethernet PCIe (rev 01)
02:00.1 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit
Ethernet PCIe (rev 01)
02:00.2 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit
Ethernet PCIe (rev 01)
02:00.3 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit
Ethernet PCIe (rev 01)

Also, 2x 1G were bonded, I use openvswitch with LACP for that.

The symptoms are obviously different, mine looked like this:

tg3 :02:00.2 eth1: transmit timed out, resetting
tg3 :02:00.2 eth1: 0x: 0x165714e4, 0x00100546, 0x0201,
0x00800010
tg3 :02:00.2 eth1: 0x0010: 0x92b3000c, 0x, 0x92b4000c,
0x
tg3 :02:00.2 eth1: 0x0020: 0x92b5000c, 0x, 0x,
0x22be103c

tg3 :02:00.2 eth1: 0x7000: 0x0808, 0x, 0x,
0x4cd8
tg3 :02:00.2 eth1: 0x7010: 0xdbbd2b97, 0x010080f3, 0x00d70081,
0x03008200
tg3 :02:00.2 eth1: 0x7020: 0x, 0x, 0x0406,
0x10004000
tg3 :02:00.2 eth1: 0x7030: 0x0002, 0x4cdc, 0x001f,
0x
tg3 :02:00.2 eth1: 0: Host status block
[0001:0070:(:0563:):(:0094)]
tg3 :02:00.2 eth1: 0: NAPI info
[0070:0070:(016a:0094:01ff)::(068c:::)]
tg3 :02:00.2 eth1: 1: Host status block
[0001:0083:(::):(015b:)]
tg3 :02:00.2 eth1: 1: NAPI info
[0051:0051:(::01ff):0124:(0124:0124::)]
tg3 :02:00.2 eth1: 2: Host status block
[0001:00d8:(0e96::):(:)]
tg3 :02:00.2 eth1: 2: NAPI info
[00a4:00a4:(::01ff):0e5b:(065b:065b::)]
tg3 :02:00.2 eth1: 3: Host status block
[0001:0013:(::):(:)]
tg3 :02:00.2 eth1: 3: NAPI info
[00f8:00f8:(::01ff):072f:(072f:072f::)]
tg3 :02:00.2 eth1: 4: Host status block
[0001:009c:(::0736):(:)]
tg3 :02:00.2 eth1: 4: NAPI info
[007c:007c:(::01ff):0716:(0716:0716::)]
tg3 :02:00.2: tg3_stop_block timed out, ofs=1400 enable_bit=2
tg3 :02:00.2: tg3_stop_block timed out, ofs=c00 enable_bit=2
tg3 :02:00.2 eth1: Link is down
tg3 :02:00.2 eth1: Link is up at 1000 Mbps, full duplex
tg3 :02:00.2 eth1: Flow control is off for TX and off for RX
tg3 :02:00.2 eth1: EEE is disabled

> - sysctl parameter net.bridge.bridge-nf-call-ip6tables is set to 0.
> 
> If both conditions are not met no kernel panic oaccurs.

What I found out in the end is that using `ethtool -K $iface tso off` is
a workaround to not make it trigger some obscure bug inside the nic that
makes it crash.

So, I think my actual suggestion would be, even while it does not look
like the same thing, but it's still Broadcom stuff which can have
*cough* weird issues... if you can reliably reproduce the problem, then
can you try setting tso off on the physical interfaces in dom0 and try
again? In Dutch we say "nooit geschoten altijd mis".

> Other IPv6 related sysctl parameters are set on dom0 like
> net.ipv6.conf.all.disable_ipv6 = 1
> net.ipv6.conf.default.disable_ipv6 = 1
> net.ipv6.conf.lo.disable_ipv6 = 1
> 
> 
> The layer2-iptables settings are
> net.bridge.bridge-nf-call-ip6tables = 0 ***
> 
> 
> net.bridge.bridge-nf-call-iptables = 1
> 
> 
> net.bridge.bridge-nf-call-arptables = 0
> 
> 
> 
> 
> As said, if I don't set the one marked with *** to 0 there is no kernel
> panic.
> 
> I wonder if this still is a kernel issue but still wouldn't expect a
> kernel panic to happen.
> 
> Cheers,
> spi
> 

Have fun,
Hans

Bug#988300: [SOLVED] linux-kbuild-5.10: can not build nvidia-kernel-340xx-dkms

[Hans]

Dear maintainers,

tested a lot and I dicovered, there is a problem with the nvidia-package 
version 340.108-3-*.

This package (and even the original version from NVidia) does NOT build.

However, on your repo I found version 340.108-10-*bpo*, which I manually 
downloaded and installed. This version is running well and I suggest, to 
release it as soon as possible.

As I found a solution for me, I think, you can safely close this bugreport.

Thank you very much for reading this and all the work.

Best regards

Hans  

Bug#988300: linux-kbuild-5.10: can not build nvidia-kernel-340xx-dkms

[Hans-J. Ullrich]

Package: linux-kbuild-5.10
Version: 5.10.28-1
Severity: important

Dear Maintainer,

I am not quite sure, but I believe, there is a problem with either 
linux-kbuild-5.10 or the nvidia-kernel-340xx-dkms.

The problem is, that the build of the kernel module stops and the make.log says 
the following:

--- snip ---

make[3]: Verzeichnis „/usr/src/linux-headers-5.10.0-6-amd64“ wird betreten
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (
\
echo >&2;   \
echo >&2 "  ERROR: Kernel configuration is invalid.";   \
echo >&2 " include/generated/autoconf.h or include/config/auto.conf are 
missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix 
it.";  \
echo >&2 ;  \
/bin/false)
make -f /usr/src/linux-headers-5.10.0-6-common/scripts/Makefile.build obj=.. \
single-build= \
need-builtin=1 need-modorder=1
/usr/src/linux-headers-5.10.0-6-common/scripts/Makefile.build:44: 
/usr/src/linux-headers-5.10.0-6-common/../Makefile: Datei oder Verzeichnis 
nicht gefunden
make[4]: *** Keine Regel, um 
„/usr/src/linux-headers-5.10.0-6-common/../Makefile“ zu erstellen.  Schluss.
make[3]: *** [/usr/src/linux-headers-5.10.0-6-common/Makefile:1822: ..] Fehler 2
make[3]: Verzeichnis „/usr/src/linux-headers-5.10.0-6-amd64“ wird verlassen
make[2]: *** [Makefile:185: __sub-make] Fehler 2
make[2]: Verzeichnis „/usr/src/linux-headers-5.10.0-6-common“ wird verlassen
make[1]: *** [Makefile:205: nvidia.ko] Fehler 2
make[1]: Verzeichnis „/var/lib/dkms/nvidia-legacy-340xx/340.108/build“ wird 
verlassen
make: *** [Makefile:221: ../Module.symvers] Fehler 2
make: Verzeichnis „/var/lib/dkms/nvidia-legacy-340xx/340.108/build/uvm“ wird 
verlassen
  
1124,1  
--- snap 

This issue happened, when I deinstalled and reinstalled all the nvidia-packages.

Please note: It was possible before to build the nvidia-module for a 
5.10-version, but this was a prior version before 5.10.0-6-amd64 (maybe 
5.10.0-4-amd64 or similar).

On kernel version 4.19.0-16-amd64 the module can be build, but this is another 
linux-kbuild-version!

Thus and because of the make.log I believe, linux-kbuild-5.10 might be buggy.

Thank you for reading this and any help.

Best regards

Hans
 

 





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

Kernel: Linux 4.19.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CRAP, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-kbuild-5.10 depends on:
ii  libc6  2.31-11
ii  libelf10.183-1
ii  libssl1.1  1.1.1k-1

linux-kbuild-5.10 recommends no packages.

linux-kbuild-5.10 suggests no packages.

-- debconf-show failed

Bug#987030: linux-image-5.10.0-6-amd64 - Fans speed maximum - CPU load < 1%

[Hans van Kranenburg]

Oh,

On 4/16/21 11:44 AM, Hans van Kranenburg wrote:
> [...]
> 
> I have the same issue here, it started at the moment I moved from the
> 4.19 kernel to 5.9, and now 5.10. For totally non-obvious reasons fans
> start blowing like crazy regularly for a few seconds. When observing
> system load, it's just hovering around 0.2 - 0.4, no peaks observed.
> 
> [...]

So, while the fan misbehavior started around the time of the kernel
upgrade, the reason turned out to be a lot more simple.

For me, it was a dust problem. After thorough cleaning, the problem is
gone. :D

Hans

Bug#987030: linux-image-5.10.0-6-amd64 - Fans speed maximum - CPU load < 1%

[Hans van Kranenburg]

Hi,

On 4/15/21 10:51 PM, klak wrote:
> Package:  linux-image-5.10.0-6-amd64
> Version:  5.10.28-1
> 
> Hello Maintainer,
> 
> every few minutes the fans turn to maximum for a few seconds. The CPU
> load is less than 1 %, but the fans are turning maximum. The problen
> starts with version 5.9. I didn't see anything conspicuous in the
> syslog. The machine is a KVM host and the problem also occurs when it
> is idle.

I have the same issue here, it started at the moment I moved from the
4.19 kernel to 5.9, and now 5.10. For totally non-obvious reasons fans
start blowing like crazy regularly for a few seconds. When observing
system load, it's just hovering around 0.2 - 0.4, no peaks observed.

This is an Intel NUC with just a Buster system used as mostly inactive
desktop.

FWIW, attached are output of lshw and lspci -v.

> Board + CPU :
> =
> DMI: Intel Corporation S5520HC/S5520HC, BIOS
> S5500.86B.01.00.0064.050520141428 05/05/2014
> 
> smpboot: CPU0: Intel(R) Xeon(R) CPU   L5640  @ 2.27GHz (family:
> 0x6, model: 0x2c, stepping: 0x2)
> 
> Performance Events: PEBS fmt1+, Westmere events, 16-deep LBR, Intel PMU
> driver.
> DMAR: Intel(R) Virtualization Technology for Directed I/O

Hans
dorothy
description: Mini PC
product: NUC8i5BEH (BOXNUC8i5BEH)
vendor: Intel(R) Client Systems
version: J72747-305
serial: G6BE94400JDL
width: 64 bits
capabilities: smbios-3.2.1 dmi-3.2.1 smp vsyscall32
configuration: boot=normal chassis=mini family=Intel NUC sku=BOXNUC8i5BEH 
uuid=889D1A9F-A26C-DC8C-5D1C-1C697A09E4C6
  *-core
   description: Motherboard
   product: NUC8BEB
   vendor: Intel Corporation
   physical id: 0
   version: J72692-307
   serial: GEBE94TU
   slot: Default string
 *-firmware
  description: BIOS
  vendor: Intel Corp.
  physical id: 0
  version: BECFL357.86A.0072.2019.0524.1801
  date: 05/24/2019
  size: 64KiB
  capacity: 16MiB
  capabilities: pci upgrade shadowing cdboot bootselect socketedrom edd 
int13floppy1200 int13floppy720 int13floppy2880 int5printscreen int14serial 
int17printer acpi usb biosbootspecification uefi
 *-memory
  description: System Memory
  physical id: 3b
  slot: System board or motherboard
  size: 32GiB
*-bank:0
 description: SODIMM DDR4 Synchronous 2400 MHz (0.4 ns)
 product: CT16G4SFD824A.M16FE
 vendor: 859B
 physical id: 0
 serial: E3029A84
 slot: SODIMM1
 size: 16GiB
 width: 64 bits
 clock: 2400MHz (0.4ns)
*-bank:1
 description: SODIMM DDR4 Synchronous 2400 MHz (0.4 ns)
 product: CT16G4SFD824A.M16FE
 vendor: 859B
 physical id: 1
 serial: E302B39D
 slot: SODIMM2
 size: 16GiB
 width: 64 bits
 clock: 2400MHz (0.4ns)
 *-cache:0
  description: L1 cache
  physical id: 45
  slot: L1 Cache
  size: 256KiB
  capacity: 256KiB
  capabilities: synchronous internal write-back unified
  configuration: level=1
 *-cache:1
  description: L2 cache
  physical id: 46
  slot: L2 Cache
  size: 1MiB
  capacity: 1MiB
  capabilities: synchronous internal write-back unified
  configuration: level=2
 *-cache:2
  description: L3 cache
  physical id: 47
  slot: L3 Cache
  size: 6MiB
  capacity: 6MiB
  capabilities: synchronous internal write-back unified
  configuration: level=3
 *-cpu
  description: CPU
  product: Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz
  vendor: Intel Corp.
  physical id: 48
  bus info: cpu@0
  version: Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz
  serial: To Be Filled By O.E.M.
  slot: U3E1
  size: 3139MHz
  capacity: 3800MHz
  width: 64 bits
  clock: 100MHz
  capabilities: lm fpu fpu_exception wp vme de pse tsc msr pae mce cx8 
apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht 
tm pbe syscall nx pdpe1gb rdtscp x86-64 constant_tsc art arch_perfmon pebs bts 
rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 
monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 
x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 
3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp 
tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep 
bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec 
xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp 
md_clear fl

Bug#977262: linux-image-5.9.0-4-amd64: nvidia-kernel cannot be built any more

[Hans-J. Ullrich]

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

Dear Maintainer,

when upgrading from linux-image-5.9.0-3-amd64 to *-5.9.0-4-amd64 and its 
headers, it is not 
possible to build the required kernel module for the nividia-packages. This 
includes latest legacy versions "340xx" as well as "390xx". 

So it is not possible, to use hardware acceleration with graphic cards which 
need these packages.

I believe, the problem is kernel related, as the nvidia-packages were not 
updated and they still build fine on linux-image-5.9.0-3-amd64 (the version, I 
am running at the moment).

It would be nice, if you could take a lokk at that, as I believe, there are 
lots of hardware like notebooks, where you can not exchange the graphics card 
easily, if not at all.

Thank you very much for any help!

Best regards

Hans



-- Package-specific info:
** Version:
Linux version 5.9.0-3-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 
10.2.0-17) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 
5.9.9-1 (2020-11-19)

** Command line:
BOOT_IMAGE=/vmlinuz-5.9.0-3-amd64 
root=UUID=ad01422d-da21-4b7f-ad9e-ce6c459ca494 ro quiet

** Tainted: POE (12289)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

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

** Model information
sys_vendor: Acer
product_name: Aspire 7520G
product_version: V1.32
chassis_vendor: Acer
chassis_version: N/A
bios_vendor: Acer
bios_version: V1.33
board_vendor: Acer
board_name: Fuquene
board_version: N/A

** Loaded modules:
xfrm_user
xfrm_algo
l2tp_ppp
l2tp_netlink
l2tp_core
ip6_udp_tunnel
udp_tunnel
pppox
ppp_generic
slhc
cmac
ctr
ccm
nf_tables
nfnetlink
cpufreq_conservative
uinput
binfmt_misc
uvcvideo
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_common
videodev
mc
ath5k
snd_hda_codec_hdmi
ath
mac80211
snd_hda_codec_realtek
snd_hda_codec_generic
ledtrig_audio
edac_mce_amd
kvm_amd
snd_hda_intel
ccp
snd_intel_dspcfg
snd_hda_codec
rng_core
snd_hda_core
kvm
joydev
cfg80211
irqbypass
snd_hwdep
snd_pcm_oss
snd_mixer_oss
serio_raw
r852
pcspkr
sm_common
snd_pcm
libarc4
wmi_bmof
nand
k8temp
ir_rc6_decoder
snd_timer
nand_ecc
bch
nandcore
snd
sg
rc_rc6_mce
mtd
r592
memstick
soundcore
ene_ir
evdev
rc_core
ac
button
analog
gameport
isofs
acer_wmi
sparse_keymap
rfkill
vboxvideo
drm_vram_helper
drm_ttm_helper
ttm
drm_kms_helper
cec
nvidia(POE)
usbnet
mii
cpufreq_userspace
cpufreq_ondemand
cpufreq_powersave
powernow_k8
parport_pc
ppdev
lp
parport
loop
drm
fuse
sunrpc
configfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
ecb
aes_generic
libaes
crypto_simd
cryptd
glue_helper
lrw
gf128mul
algif_skcipher
af_alg
dm_crypt
dm_mod
hid_generic
usbhid
hid
sd_mod
t10_pi
crc_t10dif
crct10dif_generic
crct10dif_common
sr_mod
cdrom
ata_generic
ahci
pata_amd
libahci
ohci_pci
libata
ohci_hcd
psmouse
ehci_pci
ehci_hcd
firewire_ohci
sdhci_pci
usbcore
cqhci
scsi_mod
sdhci
firewire_core
mmc_core
crc_itu_t
forcedeth
usb_common
i2c_nforce2
battery
wmi
video

** PCI devices:
00:00.0 RAM memory [0500]: NVIDIA Corporation MCP67 Memory Controller 
[10de:0547] (rev a2)
Subsystem: Acer Incorporated [ALI] MCP67 Memory Controller [1025:0126]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:01.0 ISA bridge [0601]: NVIDIA Corporation MCP67 ISA Bridge [10de:0548] (rev 
a2)
Subsystem: Acer Incorporated [ALI] MCP67 ISA Bridge [1025:0126]
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 
Kernel driver in use: nForce2_smbus
Kernel modules: i2c_nforce2

00:01.2 RAM memory [0500]: NVIDIA Corporation MCP67 Memory Controller 
[10de:0541] (rev a2)
Subsystem: NVIDIA Corporation MCP67 Memory Controller [10de:cb84]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- 
Kernel driver in use: ohci-pci
Kernel modules: ohci_pci

00:02.1 USB controller [0c03]: NVIDIA Corporation MCP67 EHCI USB 2.0 Controller 
[10de:055f] (rev a2) (prog-if 20 [EHCI])
Subsystem: Acer Incorporated [ALI] MCP67 EHCI USB 2.0 Controller 
[1025:0126]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci

00:04.0 USB controller [0c03]: NVIDIA Corporation MCP67 OHCI USB 1.1 Controller 
[10de:055e] (rev a2) (

Bug#971951: linux-image-5.8.0-2-amd64: Touchpad module is deinitialized when running plasma5

[Hans-J. Ullrich]

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

Dear Maintainer,

I discovered an issue since the last update with the touchpad of my notebook. 
It is a Synaptic touchpad and as I believe, the 
touchpad driver is a kernel module, send this issue to the kernel. If I am 
wrong, please correct me.

The issue appeares, when the notebook get into high processing, for example, 
when I am running firefox with lots of modules.

Then suddenly the (external) mouse behaves wrong. "Wrong" means, by hovering 
over the scroll bar, it scrolls automatically down, or by clicking in a window 
with several tab buttons, it jumps to the most right tab.

My checks discovered, that it is NOT the mouse itself, when this happens, but 
it is the touchpad. To prove this I did the following when the bug appeared:

1. Disconnected the external mouse = bug still existent
2. Opened systemsettings in plasma, then in the hardwaremenu chose "touchpad 
settings"
3. By hovering the mousepointer over the testfield, I could see the touchpad 
moving without any action by me = bug still existent
4. To delete the touchpad driver, I set "delete touchpad driver when external 
mouse exists" and put in the external mouse again = touchpad no more working, 
mouse working correctly
5. Disconnected external mouse, touchpad again active = bug NO MORE existent, 
everything ok


The issue is also gone, when restarting plasma5.

So, I think, there might be a problem with dbus or the touchpad driver itself.

However, I yet found no way, to reproduce this bug, it appears often, but 
randomly. And it appears not only in plasma5, also when running a game like 
doom3 or some other shooter. These are not started from plasma5, these are 
started from LXDE.

I got you all information, I think them important, but feel free to ask for 
more.

Thank you very much for reading this and your help.

Best regards

Hans



 



-- Package-specific info:
** Version:
Linux version 5.8.0-2-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 
10.2.0-9) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 5.8.10-1 
(2020-09-19)

** Command line:
BOOT_IMAGE=/vmlinuz-5.8.0-2-amd64 
root=UUID=ad01422d-da21-4b7f-ad9e-ce6c459ca494 ro quiet

** Tainted: POE (12289)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

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

** Model information
sys_vendor: Acer
product_name: Aspire 7520G
product_version: V1.32
chassis_vendor: Acer
chassis_version: N/A
bios_vendor: Acer
bios_version: V1.33
board_vendor: Acer
board_name: Fuquene
board_version: N/A

** Loaded modules:
vboxnetadp(OE)
l2tp_ppp
l2tp_netlink
l2tp_core
ip6_udp_tunnel
udp_tunnel
vboxnetflt(OE)
pppox
ppp_generic
slhc
xfrm_user
xfrm_algo
ctr
ccm
nf_tables
nfnetlink
cpufreq_conservative
uinput
binfmt_misc
uvcvideo
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_common
videodev
mc
ath5k
ath
mac80211
snd_hda_codec_hdmi
snd_hda_codec_realtek
cfg80211
snd_hda_codec_generic
ledtrig_audio
edac_mce_amd
kvm_amd
snd_hda_intel
snd_intel_dspcfg
ccp
rng_core
snd_hda_codec
snd_hda_core
kvm
snd_hwdep
snd_pcm_oss
snd_mixer_oss
r852
snd_pcm
sm_common
joydev
irqbypass
nand
snd_timer
pcspkr
wmi_bmof
snd
nand_ecc
serio_raw
libarc4
bch
k8temp
ir_rc6_decoder
sg
nandcore
r592
mtd
soundcore
memstick
rc_rc6_mce
ene_ir
rc_core
ac
evdev
button
analog
gameport
isofs
cdrom
acer_wmi
sparse_keymap
rfkill
vboxvideo(OE)
ttm
drm_kms_helper
cec
vboxdrv(OE)
nvidia(POE)
usbnet
mii
cpufreq_userspace
cpufreq_powersave
powernow_k8
parport_pc
ppdev
lp
parport
drm
loop
sunrpc
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
ecb
aes_generic
libaes
crypto_simd
cryptd
glue_helper
lrw
gf128mul
algif_skcipher
af_alg
dm_crypt
dm_mod
sd_mod
t10_pi
crc_t10dif
crct10dif_generic
crct10dif_common
hid_generic
usbhid
hid
ahci
libahci
ata_generic
pata_amd
libata
ohci_pci
psmouse
ohci_hcd
scsi_mod
sdhci_pci
cqhci
sdhci
ehci_pci
ehci_hcd
firewire_ohci
mmc_core
forcedeth
firewire_core
crc_itu_t
usbcore
usb_common
i2c_nforce2
battery
wmi
video

** PCI devices:
00:00.0 RAM memory [0500]: NVIDIA Corporation MCP67 Memory Controller 
[10de:0547] (rev a2)
Subsystem: Acer Incorporated [ALI] MCP67 Memory Controller [1025:0126]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:01.0 ISA bridge [0601]: NVIDIA Corporation MCP67 ISA Bridge [10de:0548] (rev 
a2)
Subsystem: Acer Incorporated [ALI] MCP67 ISA Bridge [1025:0126]
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 
Kernel driver in use: nForce2_smbus
Kernel modules: 

Bug#964494: File system corruption with ext3 + kernel-4.19.0-9-amd64

[Hans van Kranenburg]

Hi,

On Wed, 15 Jul 2020 20:52:40 -0700 Sarah Newman  wrote:
> On 7/7/20 8:13 PM, Ben Hutchings wrote:
> > Control: reassign -1 src:linux
> > Control: tag -1 moreinfo
> > 
> > On Tue, 2020-07-07 at 17:30 -0700, Sarah Newman wrote:
> >> Package: linux-signed-amd64
> >> Version: 4.19.0-9-amd64
> >>
> >> We've had two separate reports now of debian buster users running
> >> 4.19.0-9-amd64 who experienced serious file system corruption.
> > 
> > Which version?  (I.e. what does "uname -v" or
> > "dpkg -s linux-image-4.19.0-9-amd64" say?)
> > 
> >> - Both were using ext3
> >> - Both are running Xen HVM, but I do not have reason to believe this to be 
> >> related
> 
> [...]

I have servers which run 4.19.118-2 as dom0 kernel and a Xen 4.11.4-1
rebuild for Buster.

One example is a smallish 6-server cluster that got a reboot cycle 48
days ago.

It contains a few heavily loaded domUs with 4.19.118 or 4.19.131 based
kernels.

No problems or disk corruption or anything is seen yet. dom0 filesystem
is ext4, domUs use a mix of ext4 and btrfs (over iscsi). So, no ext3
anywhere.

We haven't got bug reports against Debian Xen packages in the BTS about
this.

I have not yet tried to make an ext3 fs on a block device in a test domU
and then have it do things with the fs and reboot it now and then. If
wanted, I can do that and see if there's any problem after a week or
two. Just to add chaos to help correlating.

FWIW,
Hans

Bug#960117: linux-image-5.6.0-1-686: linux-image-5.6.0-1-686-pae starts weird sound at boot on battery (Update)

[Hans]

Dear developers,

there is a little thing, I want to correct: The described behaviour also 
appears on my Acer Notebook, which is same way partitioned, but is running 64-
bit (amd64). Same kernel-version, same behaviour. So it might be a problem in 
the sources.

Thank you for your help.

Best gegards

Hans

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

Bug#960117: linux-image-5.6.0-1-686: linux-image-5.6.0-1-686-pae starts weird sound at boot on battery

[Hans-J. Ullrich]

Package: src:linux
Version: 5.6.7-1
Severity: important
File: linux-image-5.6.0-1-686

Dear Maintainer,

I am running in an issue when booting the latest kernel 5.6.0-1-pae. This 
appears only on 32-bit-version, every computer with 
64-bit is running fine.

Environment:
I am running am EEEPC with a SSD harddrive, which is seperated in several 
partitions (/boot, /home (luks enc.), /var (luks enc.)
, /usr (luks enc.). The batteries are fully charged and in best shape.

Issue:
When booting on battery, first /usr wants to be decrypted, what is running 
well. Then, as soon it wants to be /var decrypted, ththere is a loud noise from 
the speakers (hardly to describe, such a "taktaktaktaktaktak..." with about 
5Hz.

Ignoring this, the syetem is booting, but the sound stays. I tested with the 
prior kernel-version 5.5.0-2-686-pae, which works without any isues.

I also had to say, that I had an issue with this kernel to the partition of 
/var, which killed my filesystem (glad, could restore it by using the 
superblock) and I believe this crash was due to the same bug in kernel-version 
5.6.0-1-686 so I set this report to "important" as it might kill something.

As a workaround, I am running now kernel 5.5.0-2-686-pae, but it would be nice, 
if you could fix this issue in kernel 5.6.0-1-686-pae (or higher).

Thank you very much for the grrat work!

Best regards and stay healthy!

Hans

 
*** End of the template - remove these template lines ***


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GSE Express Memory 
Controller Hub [8086:27ac] (rev 03)
Subsystem: ASUSTeK Computer Inc. Mobile 945GSE Express Memory 
Controller Hub [1043:8340]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GSE 
Express Integrated Graphics Controller [8086:27ae] (rev 03) (prog-if 00 [VGA 
controller])
Subsystem: ASUSTeK Computer Inc. Mobile 945GSE Express Integrated 
Graphics Controller [1043:8340]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 
943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03)
Subsystem: ASUSTeK Computer Inc. Mobile 945GM/GMS/GME, 943/940GML 
Express Integrated Graphics Controller [1043:8340]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:1b.0 Audio device [0403]: Intel Corporation NM10/ICH7 Family High Definition 
Audio Controller [8086:27d8] (rev 02)
Subsystem: ASUSTeK Computer Inc. NM10/ICH7 Family High Definition Audio 
Controller [1043:8398]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 
1 [8086:27d0] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:1c.1 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 
2 [8086:27d2] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:1c.3 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 
4 [8086:27d6] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR+ TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:1d.0 USB controller [0c03]: Intel Corporation NM10/ICH7 Family

Bug#908438: cubietruck wifi reversion

[Hans de Goede]

On 18-12-2019 22:46, Salvatore Bonaccorso wrote:

Can you report this to upstream directly? (Please keep the Debian bug
into the loop).


I have submitted the patch upstream at the same time I added a comment
to the Debian bug. Upstream did not accept the patch back then because
the were hoping a real fix would show up soon.

If people are still hitting this issue, it might be a good idea if
someone re-tests and if the patch still helps re-submits it upstream.

Bug#944612: [Pkg-xen-devel] system still crashes with bullseye and kernel v5.3

[Hans van Kranenburg]

Hi Alexander,

On 12/18/19 9:24 PM, Alexander Dahl wrote:
> 
> meanwhile I'm running bullseye with kernel v5.3, but the problem
> persists and my Xen system is annoyingly unstable due to this bug. I
> attach some more logs from the last days and add the debian xen devel
> list in Cc. Maybe someone over there has an idea how to fix this. After
> all the log shows plenty of hints it could have something to do with Xen.

I think the xen parts you see in the stack trace listings are usual
calls that show that a domU is asking dom0 via the hypervisor to do some
disk read/writes or send data over the network (the 'upcall').

https://wiki.xen.org/wiki/Event_Channel_Internals

So, after getting that request, the dom0 Linux kernel tries to execute
it, which is e.g. the enqueue function to throw a network packet at the
physical network interface.

The first error we see is the "transmit queue 0 timed out". This looks
like the Linux kernel is looking at the network port hardware, and
expects it to accept the packet, deal with it and put it on the wire.

When this does not happen, and the network port hardware seems frozen
and timeouts, it's forcibly reset (I don't know if the thing is
resetting itself because it crashed, or if the Linux kernel does
something to reset it). "Reset adapter unexpectedly" gives me the
feeling that the firmware inside the network card crashed and something
inside there also reset it.

> Anyone care to help debug this? I have no idea where to start. Can
> kernel or xen generate coredumps one could analyze? Or is the log output
> the only thing?
> 
> (If you look at the logs, the strange thing is the system does not crash
> and reboot immediately, but later after lots of errors with storage, but
> comes back fine after reboot.)

The ata errors (disk fails to process a command) happen after all of the
above happens. Usually disk errors that look like this point at broken
disk hardware or bugs in the firmware in the disk. However, if it
consistently happens 6 to 7 seconds after the network card disaster, it
might be a symptom of the former.

The first thing I would recommend is disabling transmit segmentation
offloading to the network card in dom0 (ethtool enp1s0 tso off) and see
if it prevents the network card from choking on some kind of input. If
not, play with more settings like transmit checksum offloading (tx off).

If this does not help, we can start asking some Xen developers if they
have an idea how we can help with debugging and what we should do. (I
help maintaining the Xen packages in Debian, my knowledge about
internals of it is mostly limited to all the been-there-done-thats
during the years of using it as a user.)

I expect the problem to be related to Linux and the hardware, and not
specifically Xen. Knowing if the same happens when just booting Linux
without Xen is valuable debugging info. However, I realize that it's
likely a bit complicated to, in that case, try triggering the problem by
generate the same workload that's now coming from the domUs.

Curious to hear what happens,
Thanks,
Hans van Kranenburg

Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen

[Hans van Kranenburg]

On 3/12/19 8:19 PM, Juergen Gross wrote:
> On 12/03/2019 17:41, Hans van Kranenburg wrote:
>> On 3/12/19 5:04 PM, Juergen Gross wrote:
>>> On 11/03/2019 20:50, Hans van Kranenburg wrote:
>>>> On 3/11/19 7:34 AM, Juergen Gross wrote:
>>>>>
>>>>> I'm not sure. Patch 3 of this series is basically already there (see
>>>>> commit c6d4381220a0087ce19dbf6984d92c451bd6b364). So maybe all we need
>>>>> is patch 4, which should really be easy to do?
>>>>>
>>>>> Hans, could you give it a try? You'd need to use a 4.20 kernel at least.
>>>>> I can do the official patch posting in case you confirm it working.
>>>>
>>>> Ehm ok, well... This is interesting.
>>>>
>>>> I just built a 4.20.13 (without the patch), and I did it from the Debian
>>>> kernel team repo, because then I just get all latest config options like
>>>> I would get them in Debian.
>>>>
>>>> I rebooted the HP Z820 with it (with Xen 4.11) and I don't see any
>>>> errors similar to the ones I pasted earlier.
>>>>
>>>> I haven't been running any domU on it yet (just installed it), but this
>>>> is not what I expected.
>>>
>>> Well, commit c6d4381220a0087ce19dbf6984d92c451bd6b364 is part of a
>>> rather large series making the dma interface cleaner and using it more
>>> correctly where appropriate. Maybe your use case is covered by this
>>> series already.
>>
>> It seems so. That's good, of course, but it also means that I cannot be
>> of any use here any more to test the additional proposed change. ;]
> 
> I don't think the change is needed any longer.
> 
> Christoph's series was meant to fix stuff like that and it did that very
> well.

Clear.

Then for 4.19 in Debian the workaround is documented in here.

And if someone from the kernel team is reading along... Please mark as
solved when >= 4.20 is uploaded to Debian unstable?

Hans

Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen

[Hans van Kranenburg]

On 3/12/19 5:04 PM, Juergen Gross wrote:
> On 11/03/2019 20:50, Hans van Kranenburg wrote:
>> On 3/11/19 7:34 AM, Juergen Gross wrote:
>>>
>>> I'm not sure. Patch 3 of this series is basically already there (see
>>> commit c6d4381220a0087ce19dbf6984d92c451bd6b364). So maybe all we need
>>> is patch 4, which should really be easy to do?
>>>
>>> Hans, could you give it a try? You'd need to use a 4.20 kernel at least.
>>> I can do the official patch posting in case you confirm it working.
>>
>> Ehm ok, well... This is interesting.
>>
>> I just built a 4.20.13 (without the patch), and I did it from the Debian
>> kernel team repo, because then I just get all latest config options like
>> I would get them in Debian.
>>
>> I rebooted the HP Z820 with it (with Xen 4.11) and I don't see any
>> errors similar to the ones I pasted earlier.
>>
>> I haven't been running any domU on it yet (just installed it), but this
>> is not what I expected.
> 
> Well, commit c6d4381220a0087ce19dbf6984d92c451bd6b364 is part of a
> rather large series making the dma interface cleaner and using it more
> correctly where appropriate. Maybe your use case is covered by this
> series already.

It seems so. That's good, of course, but it also means that I cannot be
of any use here any more to test the additional proposed change. ;]

Except, for trying it to see if it won't introduce more regressions and
explosions, if you want me to.

Hans

Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen

[Hans van Kranenburg]

On 3/11/19 7:34 AM, Juergen Gross wrote:
> 
> I'm not sure. Patch 3 of this series is basically already there (see
> commit c6d4381220a0087ce19dbf6984d92c451bd6b364). So maybe all we need
> is patch 4, which should really be easy to do?
> 
> Hans, could you give it a try? You'd need to use a 4.20 kernel at least.
> I can do the official patch posting in case you confirm it working.

Ehm ok, well... This is interesting.

I just built a 4.20.13 (without the patch), and I did it from the Debian
kernel team repo, because then I just get all latest config options like
I would get them in Debian.

I rebooted the HP Z820 with it (with Xen 4.11) and I don't see any
errors similar to the ones I pasted earlier.

I haven't been running any domU on it yet (just installed it), but this
is not what I expected.

xen_extra  : .2-pre
xen_version: 4.11.2-pre
xen_commandline: placeholder dom0_mem=2G,max:2G
dom0_max_vcpus=1-4 com2=115200,8n1 console=com2,vga noreboot=true
xpti=dom0=false,domu=true smt=off clocksource=tsc tsc=stable:socket

Hans

Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen

[Hans van Kranenburg]

On 3/10/19 11:03 PM, Andrew Cooper wrote:
> On 10/03/2019 21:35, Hans van Kranenburg wrote:
>>
>> [...]
>>
>> Using dom0_mem=2GiB,max:4GiB instead of dom0_mem=2GiB,max:2GiB (which I
>> started with) makes the errors go away, so workaround confirmed.

It's actually dom0_mem=2G,max:4G, I typed something before which was not
identical to what I started that machine with.

>> [...]
>> I think I'm fine with this workaround.
> 
> I think
> https://lists.xen.org/archives/html/xen-devel/2014-12/msg00699.html is
> the last attempt David made to upstream the fixes.
> 
> Linux is still broken, and these fixes are still necessary.

FMI, is this max:4G DTRT for me now in the meantime, or am I still
facing more hidden problems while using this workaround?

> Boris/Juergen: Any chance you could look into these patches?  I have no
> idea what they they're in against master, but its also liable its now
> more complicated with the host max mfn calculations which have gone in
> more recently.

Thanks,
Hans

Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen

[Hans van Kranenburg]

found -1 4.19.20-1
thanks

Hi,

Reviving a thing from Jan 2017 here. I don't have this thread in my
mailbox, so no inline quotes.

I just installed some HP z820 workstation and rebooted it into Xen
4.11.1+26-g87f51bf366-3 with linux 4.19.20-1 as dom0 kernel.

During boot I'm greeted by a long list of...

[   14.518793] mpt3sas :02:00.0: swiotlb buffer is full (sz: 65536
bytes)
[   14.518899] mpt3sas :02:00.0: swiotlb buffer is full
[   14.518956] mpt3sas :02:00.0: swiotlb buffer is full (sz: 65536
bytes)
[   14.518988] sd 6:0:3:0: pci_map_sg failed: request for 786432 bytes!
[   14.519081] mpt3sas :02:00.0: swiotlb buffer is full
[   14.519309] sd 6:0:1:0: pci_map_sg failed: request for 1310720 bytes!
[   14.524611] mpt3sas :02:00.0: swiotlb buffer is full (sz: 65536
bytes)
[   14.527309] mpt3sas :02:00.0: swiotlb buffer is full
[   14.527405] sd 6:0:3:0: pci_map_sg failed: request for 786432 bytes!
[...]

...and some hangs here and there. This indeed did not happen when
booting just Linux, without Xen.

Some searching brought me to this Debian bug. So, thanks for writing
down all kinds of research here already. Even if it's not fixed upstream
yet, this helps a lot. :-)

Using dom0_mem=2GiB,max:4GiB instead of dom0_mem=2GiB,max:2GiB (which I
started with) makes the errors go away, so workaround confirmed.

I can try any of the linked patches, but I see that in message 54,
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850425#54
Andrew says: "IIRC, they were essentially rejected,". Next message, Ian
asks "Do you have a reference ?", but I don't see any fup on that.

I think I'm fine with this workaround.

If someone will ever work on the upstream patches, then this is just to
let know that I might be able to help testing. However, I only have one
of this type of box and it's gonna be installed as server at some
non-profit organization without OOB access, replacing even older donated
hardware, so, it will be kinda limited... :)

Hans

Bug#914951: 4.19.5 fails to boot as Xen dom0

[Hans van Kranenburg]

On 11/30/18 10:46 PM, Hans van Kranenburg wrote:
> On 11/29/18 2:38 AM, Hans van Kranenburg wrote:
>> On 11/29/18 1:20 AM, Hans van Kranenburg wrote:
>>> Package: src:linux
>>> Version: 4.19.5-1~exp1
>>> Severity: normal
>>>
>>> Hi,
>>>
>>> Latest 4.19 upload fails to boot as Xen dom0.
>>
>> Copy at
>> https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03313.html
>>
>> [...]
> 
> A fix has been written and tested:
> 
> https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03570.html
> 
> I tested it on top of 4.19.5-1~exp1.
> 
> I expect the first of those two patches (the actual fix) to show up in a
> later 4.19.

Since next upload seems to be targeted at unstable, we should have this
fix already:

https://salsa.debian.org/kernel-team/linux/merge_requests/82

Hans

Bug#914951: 4.19.5 fails to boot as Xen dom0

[Hans van Kranenburg]

On 11/29/18 2:38 AM, Hans van Kranenburg wrote:
> On 11/29/18 1:20 AM, Hans van Kranenburg wrote:
>> Package: src:linux
>> Version: 4.19.5-1~exp1
>> Severity: normal
>>
>> Hi,
>>
>> Latest 4.19 upload fails to boot as Xen dom0.
> 
> Copy at
> https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03313.html
> 
> [...]

A fix has been written and tested:

https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03570.html

I tested it on top of 4.19.5-1~exp1.

I expect the first of those two patches (the actual fix) to show up in a
later 4.19.

Hans

Bug#914951: 4.19.5 fails to boot as Xen dom0

[Hans van Kranenburg]

On 11/29/18 1:20 AM, Hans van Kranenburg wrote:
> Package: src:linux
> Version: 4.19.5-1~exp1
> Severity: normal
> 
> Hi,
> 
> Latest 4.19 upload fails to boot as Xen dom0.

Copy at
https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03313.html

But at least if someone else would also report or search for it, we have
this one to point to. :)

> Attached are two serial console output logs. One is starting with Xen
> 4.11 (from debian unstable) as dom0, and the other one without Xen.
> 
> [2.085543] BUG: unable to handle kernel paging request at
> 888d9fffc000
> [2.085610] PGD 200c067 P4D 200c067 PUD 0
> [2.085674] Oops:  [#1] SMP NOPTI
> [2.085736] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
> 4.19.0-trunk-amd64 #1 Debian 4.19.5-1~exp1+pvh1

Ehm, paste fail for this snippet, this is from my 4.19.5-1~exp1+pvh1
with extra Xen (domU) PVH patches. However, the full attached log is
from 4.19.5-1~exp1 which fails in exactly the same way.

> [2.085823] Hardware name: HP ProLiant DL360 G7, BIOS P68 05/21/2018
> [2.085895] RIP: e030:ptdump_walk_pgd_level_core+0x1fd/0x490
> [...]
> 
> The pti=off setting on the PV dom0 kernel is left behind from the time
> when 4.9 failed to boot as Xen dom0 because of the bug handling that.

-- 
Hans van Kranenburg

Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1

[Hans van Kranenburg]

Hi,

On 11/24/18 2:19 AM, Cesare Leonardi wrote:
> 
> On Sat, 24 Nov 2018 01:08:56 +0100 Hans van Kranenburg
>  wrote:
>> You didn't share any part of your logging. Can you share a part of dmesg
>> logging that shows Oops in it?
> 
> Here it is, attached to this message.
> Previously I didn't attached it because to me it looks substantially the
> same as the one I attached in the opening message of this bug (#913119).

Thanks. Your logging indeed also only shows the 'task [...] blocked for
more than 120 seconds', and no actual OOPS messages.

>> If a task hangs while doing disk IO, it might cause messages like these
>> in dmesg:
>>
>> INFO: task kthxbye:1157 blocked for more than 120 seconds.
>>    Not tainted blah #1 Debian someversion
>> [...]
>> 
>>
>> These are 'just' informational messages. The process will still wait
>> until it can continue.
>>
>> A kernel Oops is something really different. It usually means that some
>> data structures or code to be executed are corrupt and there's a real
>> problem going on, it's not just stalled and waiting.
> 
> Thank you very much for this explanation: I didn't know this difference
> and indeed I realized that I didn't know what a oops really is.

I'm unfortunately not the person who can fix this issue. Anyway, it's
good to confirm there is no actual real oops in your log. :)

Hans

Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1

[Hans van Kranenburg]

Hi,

On 11/24/18 12:42 AM, Cesare Leonardi wrote:
> Bug still present with the new 4.18.0-3-amd64 (4.18.20-1).
> 
> This morning I've tryed to boot this new kernel version, removing the
> workaround given by the following kernel parameters:
> scsi_mod.use_blk_mq=0 dm_mod.use_blk_mq=0
> 
> The system showed disk hangs in less than 5 hours, and, as in previous
> 4.17 and 4.18, normal disk activities was restored after some minutes,
> without apparent data loss. I experienced two hangs before rebooting,
> but one of them didn't produce an oops in dmesg. It was not the first
> time I saw an hang without oops: maybe those that can recover in less
> than 120 seconds, doesn't produce oopses in dmesg?

You didn't share any part of your logging. Can you share a part of dmesg
logging that shows Oops in it?

If a task hangs while doing disk IO, it might cause messages like these
in dmesg:

INFO: task kthxbye:1157 blocked for more than 120 seconds.
   Not tainted blah #1 Debian someversion
[...]


These are 'just' informational messages. The process will still wait
until it can continue.

A kernel Oops is something really different. It usually means that some
data structures or code to be executed are corrupt and there's a real
problem going on, it's not just stalled and waiting.

> And just to be clear, it doesn't seem a bug related to LVM but more
> precisely to various types (all?) of LVM RAID. In fact my notebook disk
> uses LVM linear volumes and never showed those hangs and oopses.

Have fun,
Hans

Bug#910074: linux-image-4.9.0-8-amd64: BTRFS data loss - kernel BUG at .../linux-4.9.110/fs/btrfs/ctree.c:3178

[Hans van Kranenburg]

Hi,

On 10/02/2018 10:08 PM, Nicholas D Steeves wrote:
> Hi Michael,
> 
> On Tue, Oct 02, 2018 at 11:37:45AM +0100, Michael Firth wrote:
>>
>> After this, there was a file that was errored on the filesystem (as
>> reported by 'btrfs check'), and it seems BTRFS doesn't have any tools to
>> resolve the error. Deleting the file at the reported inode has cleared
>> the error from 'btrfs check', but I am not 100% sure that will have
>> fixed all the corruption.
>>
> 
> As far as I know, if 'btrfs check' is clean then you're in the clear
> for any known issues involving the fs structure.  Of course, a 'btrfs
> scrub' is necessary to check for data and metadata corruption...  BTW,
> if you're using an ssd, make sure you're mounting with -o nossd,
> because as far as I know linux-4.9.x still hasn't been patched.
> P.S. that requires a full rebalance to take effect.  Make up-to-date
> backups before running that rebalance...
> 
>> This issue looks very like the bug described at:
>>
>> https://www.spinics.net/lists/linux-btrfs/msg60984.html
>>
>> And in bug report #708509 for a much older kernel (from 2013)
>>
>> According to the BTRFS mailing list post above, there are patches
>> submitted to fix this issue (or one with the same symptoms).
>> Is there any way to easily determine if these patches are in the Debian
>> version of the V4.9.110 kernel?
> 
> The last time I checked I couldn't find any btrfs-specific ones in
> Debian; I used apt-get source and expected to find a quilt series.
> 
>> If not, what is the route to get these patches incorporated? Do I need
>> to talk to the BTRFS people about getting the patches in to the stock
>> V4.9 kernel, or is this something that the Debian team would apply
>> directly?
> 
> The first of the two patches from that 29 Nov 2016 linux-btrfs email
> appears to be queued for linux-4.9.119:
>   https://lore.kernel.org/patchwork/patch/972419/
> 
> I wasn't able to find status of the second one wrt linux-4.9.x.
> 
>> Kernel bug report output included below, in case it is useful.
>>
>> BTRFS may not be a filesystem that everyone uses, but I feel if it is in
>> the Debian kernel then bugs that can cause data loss should be fixed if
>> a patch already exists.
> 
> In principle I agree; although I think it would be safer to coordinate
> with Greg Kroah-Harman about getting them applied upstream before
> importing them into Debian, since (afaik)

> we don't have any btrfs
> specialists working on our kernel...people who would know if importing
> one of these patches will introduce unintended side-effects or a
> rabbit hole of patches.

This is not a debian specific issue. The upstream btrfs team does not
have enough work capacity to do this, and mainly focuses on going
forward instead of looking back. And I don't think there's really
someone who would know the things mentioned above except for the authors
of the patches themselves (who tag them for stable if it's data
corruption and if they know it will work (tm)), or the btrfs maintainer
who knows which ones to put together in which order to prepare the next
kernel release.

>  Maybe it would be safer to look at the delta
> between btrfs in 4.9.x and 4.14.x and ask for backported fixes from
> 4.14.x to 4.9.x? (eg: more than six months of testing in 4.14.x, like
> the -o ssd bug that is still present in 4.9.x)

For the -o ssd issue, in hindsight, it was a mistake to not get that
into 4.9 earlier.

Every user who wants to try out btrfs on his/her computer with Stretch
and uses it as the root filesystem on a disk which is not too large is
still affected by this sub-optimal behaviour.

So I guess that's a TODO for me, to still get it done now. It's 951e7966
and 583b723151 with a few small changes to make it apply. At least it
has had enough testing, and the amount of users with out-of-space
filesystems has decreased notably in the last year in #btrfs IRC. :)

Hans



signature.asc
Description: OpenPGP digital signature

Bug#908438: cubietruck wifi reversion

[Hans de Goede]

Hi all,

I've hit this problem myself this weekend on both a
Cubietruck and on a "LeMaker Banana Pro.

For me the problem was intermittent on both devices, once
it happened it seems to require a power-cycle to fix.

Once things work one can safely reboot without hitting
the issue.

I'm attaching a patch which fixes this problem for me,
it is more of a workaround but it does not have much of
a downside. Using an OOB IRQ instead of the sdio-IRQ
mechanism is mostly important to allow the MMC controller
to go into runtime-suspend which is not really an issue
on these boards since they are (usually) not battery
powered.

Regards,

Hans

>From 34de386e5a1113360c967ba9f76901282e46a415 Mon Sep 17 00:00:00 2001
From: Hans de Goede 
Date: Sun, 30 Sep 2018 16:58:52 +0200
Subject: [PATCH resend] ARM: dts: sun7i: Disable OOB IRQ for brcm wifi on
 Cubietruck and Banana Pro

While doing some brcmfmac driver work I needed to test this also on some
devicetree based boards. So I fired up the good old Cubietruck and when
that would not work a Banana Pro.

With an unmodified 4.17 kernel both boards intermittently would come up
with non working wifi with the following errors:

 brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
 brcmfmac: brcmf_bus_started: failed: -110
 brcmfmac: brcmf_attach: dongle is not responding: err=-110
 brcmfmac: brcmf_sdio_firmware_callback: brcmf_attach failed

They would come up this way more often then with actual working wifi,
once this problem happens it seems to require a power-cycle to fix.
Once things work one can safely reboot without hitting the issue.

I've found that disabling OOB interrupts fixes this. This really is more
of a workaround then a proper fix, but it makes the wifi reliable again
and it does not have much of a downside.

Using an OOB IRQ instead of the sdio-IRQ mechanism is mostly important to
allow the MMC controller to go into runtime-suspend which is not really an
issue on these boards since they are (usually) not battery powered.

I've looked at recent brcmfmac and mmc-core changes which may explain this
and I've not found anything. So the most likely culprit is the A20 external
interrupt handling e.g. perhaps it is set to edge instead of level? Either
way I do not have time to further investigate this.

BugLink: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908438
Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun7i-a20-bananapro.dts  | 16 +---
 arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 16 +---
 2 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/sun7i-a20-bananapro.dts b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
index 0898eb6162f5..0e1ddd998b20 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
@@ -174,9 +174,19 @@
 	brcmf: wifi@1 {
 		reg = <1>;
 		compatible = "brcm,bcm4329-fmac";
-		interrupt-parent = <>;
-		interrupts = <7 15 IRQ_TYPE_LEVEL_LOW>;
-		interrupt-names = "host-wake";
+		/*
+		 * OOB interrupt support is broken ATM, often the first irq
+		 * does not get seen resulting in the drv probe failing with:
+		 *
+		 * brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
+		 * brcmfmac: brcmf_bus_started: failed: -110
+		 * brcmfmac: brcmf_attach: dongle is not responding: err=-110
+		 * brcmfmac: brcmf_sdio_firmware_callback: brcmf_attach failed
+		 *
+		 * interrupt-parent = <>;
+		 * interrupts = <7 15 IRQ_TYPE_LEVEL_LOW>;
+		 * interrupt-names = "host-wake";
+		 */
 	};
 };
 
diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index 5649161de1d7..a837516db6f9 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -222,9 +222,19 @@
 	brcmf: wifi@1 {
 		reg = <1>;
 		compatible = "brcm,bcm4329-fmac";
-		interrupt-parent = <>;
-		interrupts = <7 10 IRQ_TYPE_LEVEL_LOW>; /* PH10 / EINT10 */
-		interrupt-names = "host-wake";
+		/*
+		 * OOB interrupt support is broken ATM, often the first irq
+		 * does not get seen resulting in the drv probe failing with:
+		 *
+		 * brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
+		 * brcmfmac: brcmf_bus_started: failed: -110
+		 * brcmfmac: brcmf_attach: dongle is not responding: err=-110
+		 * brcmfmac: brcmf_sdio_firmware_callback: brcmf_attach failed
+		 *
+		 * interrupt-parent = <>;
+		 * interrupts = <7 10 IRQ_TYPE_LEVEL_LOW>; /* PH10 / EINT10 */
+		 * interrupt-names = "host-wake";
+		 */
 	};
 };
 
-- 
2.19.0

Bug#903767: 4.9.110-1 Xen PV boot workaround

[Hans van Kranenburg]

On 07/17/2018 12:39 AM, Benoît Tonnerre wrote:
> Hi,
> 
> I tested this workaround : I confirm that it works on Xen host, but not
> on Xen guest.
> If you try to start a vm with latest kernel i.e. theses parameters in
> cfg file :
> 
> #
> #  Kernel + memory size
> #
> kernel  = '/boot/vmlinuz-4.9.0-7-amd64'
> extra   = 'elevator=noop'
> ramdisk = '/boot/initrd.img-4.9.0-7-amd64'
> 
> The VM crash in loop with kernel error :
> 
> [...]
> 
> Did I miss something ?

Yes, the pti=off needs to go in your extra line:

  extra = 'elevator=noop pti=off'

Hans

Bug#903821: 4.9.110-1 Xen PV boot workaround

[Hans van Kranenburg]

Reportedly, adding pti=off to the kernel boot parameters will work
around the issue for now.

Turning off pti in the guest kernel is done in any case for PV. The
issue between 4.9.107 and 4.9.111 affects the detection and turning off
of pti, that's why forcing it off helps.

In 4.9.112 it's fixed in commit 1adc34adc3447c34926994b87db5d929f5ab45b5
"x86/cpu: Re-apply forced caps every time CPU caps are re-read"

Hans

Bug#903821: [Pkg-xen-devel] Bug#903821: xen-hypervisor-4.8-amd64: Kernel Panic after upgrading to stretch 9.5 (linux-image-4.9.0-7-amd64)

[Hans van Kranenburg]

Hi,

On 07/15/2018 12:16 PM, Benoît Tonnerre wrote:
> [...]
> 
> After updating 3 Xen servers from stretch (9.4) to stretch (9.5), I
> notice a kernel panic on these 3 servers.

Thanks for the report.

This is probably all related:

This went into 4.9.102:
https://www.spinics.net/lists/kernel/msg2808364.html

This into 4.9.107:
https://www.spinics.net/lists/stable/msg242657.html

And this went into 4.9.112:
https://www.spinics.net/lists/stable/msg246729.html

Apparently kernels from 4.9.107 to 4.9.111 don't boot correctly.

Hans

Bug#899044: Oops: 0000 [#1] SMP in skb_release_data, openvswitch related

[Hans van Kranenburg]

To: netdev, dev@openvswitch
Cc: Eric Dumazet (author of ff04a771ad), debian bug

Hi,

As follow-up to my bug report at Debian [0], I'm trying to do bug triage
and find out more. I'm not the expert here, but anything could help, and
it's an opportunity to learn things.

I'm observing the attached errors ('general protection fault:  [#1]
SMP' and 'BUG: unable to handle kernel paging request') on machines that
are Xen dom0 and running a 4.9.88 Debian Stretch kernel as dom0 kernel.
The errors have been happening a few times in the last few weeks. It
started after upgrading them from Jessie and 3.16 kernel to Stretch with
4.9 kernel.

The traces printed look very much alike every time.

If I look up the listed address, I get:

-$ addr2line -e /usr/lib/debug/boot/vmlinux-4.9.0-6-amd64 -i -a
814f5c7d
0x814f5c7d
./debian/build/build_amd64_none_amd64/./include/linux/compiler.h:243
(discriminator 3)
./debian/build/build_amd64_none_amd64/./include/linux/page-flags.h:143
(discriminator 3)
./debian/build/build_amd64_none_amd64/./include/linux/mm.h:779
(discriminator 3)
./debian/build/build_amd64_none_amd64/./include/linux/skbuff.h:2592
(discriminator 3)
./debian/build/build_amd64_none_amd64/./net/core/skbuff.c:594
(discriminator 3)

 583 static void skb_release_data(struct sk_buff *skb)
 584 {
 585 struct skb_shared_info *shinfo = skb_shinfo(skb);
 586 int i;
 587
 588 if (skb->cloned &&
 589 atomic_sub_return(skb->nohdr ? (1 << SKB_DATAREF_SHIFT)
+ 1 : 1,
 590   >dataref))
 591 return;
 592
 593 for (i = 0; i < shinfo->nr_frags; i++)
 594   ->__skb_frag_unref(>frags[i]);<--
 595
 596 /*
 597  * If skb buf is from userspace, we need to notify the caller
 598  * the lower device DMA has done;
 599  */
 600 if (shinfo->tx_flags & SKBTX_DEV_ZEROCOPY) {
 601 struct ubuf_info *uarg;
 602
 603 uarg = shinfo->destructor_arg;
 604 if (uarg->callback)
 605 uarg->callback(uarg, true);
 606 }
 607
 608 if (shinfo->frag_list)
 609 kfree_skb_list(shinfo->frag_list);
 610
 611 skb_free_head(skb);
 612 }

The most recent (well, from 2014) biggest change in this area is...

commit ff04a771ad25fc9ba91690e73465b4d34b6bf8b3
Author: Eric Dumazet <eduma...@google.com>
Date:   Tue Sep 23 18:39:30 2014 -0700

net : optimize skb_release_data()

...which is not present in the 3.16.y kernel that Debian Jessie still
uses, and which does not hit this problem (however, also using older
openvswitch userspace components).

Other changes in this area mention zero copy IO, which sounds like
something openvswitch could be using.

-- background: openvswitch usage --

For networking between domUs and the outside world, we use openvswitch.

After such an error happens:
* The amount of "flows" in the kernel quickly raises to the limit,
1, as seen in output of ovs-dpctl show.
* Network traffic that should flow through the openvswitch bridge starts
disappearing in a seemingly random way (probably because it can't handle
new traffic flows).
* The memory usage of the userspace ovs-vswitchd starts growing quickly.
* Many of the ovs commands, like to add or remove an interface or bridge
hang.

After a restart of the openvswitch-switch service, and fixing up a bunch
of configuration of connected interfaces, functionality is restored.

While most of the symptoms seem related to userspace openvswitch
processes, the cause of it all seems to be in the kernel, while the
userspace ovs-vswitchd process is receiving a network packet?

-- reproducer --

I don't have a reliable reproducer yet, except for waiting days or weeks
until it randomly happens somewhere. There's no sign of unusual amounts
of traffic / load etc when it happens.

An idea I can come up with is builing a semi-random udp packet generator
to start stressing the code path from kernel to ovs-vswitchd.

If I succeed reproducing, I can start trying other kernels or changes.

Please advice what else I could do to help resolving this issue.

Thanks,
Regards,

Hans van Kranenburg

[0] https://bugs.debian.org/899044
May  4 08:23:03 altair kernel: [83978.662075] BUG: unable to handle kernel 
paging request at 0003001f
May  4 08:23:03 altair kernel: [83978.665887] IP: [] 
skb_release_data+0x8d/0x110
May  4 08:23:03 altair kernel: [83978.669837] PGD 0 
May  4 08:23:03 altair kernel: [83978.669882] 
May  4 08:23:03 altair kernel: [83978.673589] Oops:  [#1] SMP
May  4 08:23:03 altair kernel: [83978.677281] Modules linked in: cls_u32 
sch_ingress act_mirred sch_fq_codel ifb xt_mark sch_htb xt_physdev br_netfilter 
bridge stp llc xen_netback xen_blkback algif_skcipher af_alg dm_service_time 
binfmt_misc xen_gntdev xen_evtchn openvswitch nf_nat_ip

Bug#899044: Oops: 0000 [#1] SMP in skb_release_data, openvswitch related

[Hans van Kranenburg]

Package: src:linux
Version: 4.9.88-1

Hi,

I'm observing the attached errors on machines that are Xen dom0 and
running the latest Debian Stretch 4.9 kernel as dom0 kernel. The errors
have been happening a few times in the last few weeks. It started after
upgrading them from Jessie and 3.16 kernel to Stretch with 4.9 kernel.

For networking between domUs and the outside world, we use openvswitch.

After such an error happens:
* The amount of "flows" in the kernel quickly raises to the limit,
1, as seen in output of ovs-dpctl show.
* Network traffic that should flow through the openvswitch bridge starts
disappearing in a seemingly random way.
* The memory usage of the userspace ovs-vswitchd starts growing quickly.
* Many of the ovs commands, like to add or remove an interface or bridge
hang.

After a restart of the openvswitch-switch service, and fixing up a bunch
of configuration of connected interfaces, functionality is restored.

While most of the symptoms seem related to userspace openvswitch
processes, the cause of it all seems to be in the kernel, while the
userspace ovs-vswitchd process is receiving a network packet?

Sadly I do not know how to reproduce this, except for just waiting until
it happens again.

Please advice what else I could use to help resolving this issue.

Thanks,
Regards,
-- 
Hans van Kranenburg
May  4 08:23:03 altair kernel: [83978.662075] BUG: unable to handle kernel 
paging request at 0003001f
May  4 08:23:03 altair kernel: [83978.665887] IP: [] 
skb_release_data+0x8d/0x110
May  4 08:23:03 altair kernel: [83978.669837] PGD 0 
May  4 08:23:03 altair kernel: [83978.669882] 
May  4 08:23:03 altair kernel: [83978.673589] Oops:  [#1] SMP
May  4 08:23:03 altair kernel: [83978.677281] Modules linked in: cls_u32 
sch_ingress act_mirred sch_fq_codel ifb xt_mark sch_htb xt_physdev br_netfilter 
bridge stp llc xen_netback xen_blkback algif_skcipher af_alg dm_service_time 
binfmt_misc xen_gntdev xen_evtchn openvswitch nf_nat_ipv6 libcrc32c xenfs 
xen_privcmd ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 
ip6table_filter ip6table_mangle ip6table_raw ip6_tables ipt_REJECT 
nf_reject_ipv4 xt_tcpudp xt_owner xt_multiport xt_conntrack iptable_filter 
iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack 
iptable_mangle iptable_raw dm_crypt intel_powerclamp crct10dif_pclmul 
crc32_pclmul iTCO_wdt iTCO_vendor_support ghash_clmulni_intel pcspkr serio_raw 
joydev evdev amdkfd radeon ttm drm_kms_helper drm i2c_algo_bit lpc_ich mfd_core 
i7core_edac hpilo
May  4 08:23:03 altair kernel: [83978.701936]  sg ipmi_si hpwdt edac_core 
ipmi_msghandler acpi_power_meter button shpchp dm_multipath dm_mod scsi_dh_rdac 
scsi_dh_emc scsi_dh_alua ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp 
libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 ext4 
crc16 jbd2 fscrypto ecb mbcache btrfs crc32c_generic xor raid6_pq mlx4_en ptp 
pps_core hid_generic usbhid hid sd_mod crc32c_intel aesni_intel aes_x86_64 
glue_helper lrw gf128mul ablk_helper cryptd psmouse ehci_pci uhci_hcd ehci_hcd 
usbcore usb_common hpsa scsi_transport_sas bnx2 mlx4_core devlink scsi_mod 
thermal
May  4 08:23:03 altair kernel: [83978.724406] CPU: 1 PID: 1486 Comm: 
revalidator7 Not tainted 4.9.0-6-amd64 #1 Debian 4.9.88-1
May  4 08:23:03 altair kernel: [83978.729139] Hardware name: HP ProLiant DL360 
G7, BIOS P68 08/16/2015
May  4 08:23:03 altair kernel: [83978.733958] task: 880119e1ee80 
task.stack: c90042764000
May  4 08:23:03 altair kernel: [83978.738724] RIP: e030:[]  
[] skb_release_data+0x8d/0x110
May  4 08:23:03 altair kernel: [83978.743560] RSP: e02b:c90042767c78  
EFLAGS: 00010206
May  4 08:23:03 altair kernel: [83978.748352] RAX: 0050 RBX: 
0002 RCX: 81ce0f40
May  4 08:23:03 altair kernel: [83978.753116] RDX:  RSI: 
8800cc998900 RDI: 8800cc998900
May  4 08:23:03 altair kernel: [83978.757867] RBP: 8800cc998900 R08: 
880123c0 R09: 88011f22
May  4 08:23:03 altair kernel: [83978.762598] R10: 8800cc998900 R11: 
880119e10280 R12: 0002
May  4 08:23:03 altair kernel: [83978.767321] R13: 88011f227ec0 R14: 
88011dea2800 R15: 
May  4 08:23:03 altair kernel: [83978.772000] FS:  7fc1656cc700() 
GS:88012824() knlGS:
May  4 08:23:03 altair kernel: [83978.776671] CS:  e033 DS:  ES:  CR0: 
80050033
May  4 08:23:03 altair kernel: [83978.781355] CR2: 0003001f CR3: 
0001212b1000 CR4: 2660
May  4 08:23:03 altair kernel: [83978.786135] Stack:
May  4 08:23:03 altair kernel: [83978.790841]  880120a28000 
8800cc998900 c90042767ec0 7ea4
May  4 08:23:03 altair kernel: [83978.795898]  814f6267 
880120a28000 8800cc998900 814fcc91
May  4 08:23:03 altair kernel: [83978.800806]  880120a28000 
8153f2df c9

Bug#891235: linux-headers-4.15.0-1-amd64: dkms modules, like zfs-dkms and spl-dkms do not compile against this kernel package

[Hans Freitag]

Unfortunately, I was to fast, the workaround does not work so I had to
go back on 4.14, but i am sure that you can copy the stuff together. I
tried a similar procedure a few weeks ago.

> Kernel: Linux 4.14.0-3-amd64 (SMP w/4 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)
> LSM: AppArmor: enabled
> 

Bug#891235: linux-headers-4.15.0-1-amd64: dkms modules, like zfs-dkms and spl-dkms do not compile against this kernel package

[Hans Freitag]

Package: linux-headers-4.15.0-1-amd64
Version: 4.15.4-1
Severity: important

Dear Maintainer,

I have problems updating to kernel 4.15 due to the fact that zfs-dkms and spl-
dkms won't compile automatically anymore.

Error Message is:

Building initial module for 4.15.0-1-amd64
configure: error:
*** Please make sure the kmod spl devel  package for your
*** distribution is installed then try again.  If that fails you
*** can specify the location of the spl objects with the
*** '--with-spl-obj=PATH' option.
Error! Bad return status for module build on kernel: 4.15.0-1-amd64 (x86_64)
Consult /var/lib/dkms/zfs/0.6.5.9/build/make.log for more information.


There is a manual workaround after installing linux-headers you have to execute
in /usr/src :

(cd linux-kbuild-4.15/ ; tar cvfz - . )| (cd linux-headers-4.15.0-1-amd64/ ;
tar xvfz - )

to make the objects available in linux-headers.

It means however some manual interaction, in an otherwise automatic update
procedure.

regards

Hans



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 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)
LSM: AppArmor: enabled

Bug#888465: CPU usage reporting issues

[Hans van Kranenburg]

Hi Ryan,

On 01/26/2018 12:20 AM, Ryan Thoryk wrote:
> Package: linux-image-4.9.0-5-amd64
> Version: 4.9.65-3+deb9u2
> Severity: normal
> 
> I'm having an issue with CPU usage reporting, tested on kernels 4.9.0-3
> and 4.9.0-5.  The machines are running on Amazon EC2, which could be
> related.  With the "sar" utility, after some time, the system's "steal"
> value periodically is 100%,

This means that your vcpus want to execute work but are not being
scheduled on a physical cpu core. Either the physical machine gets too
much work from all the virtual machines that are requesting cpu time, or
other things are going on, like your virtual machine getting paused
(e.g. when doing live migration there's a handover moment when it's
shortly paused and then resumed, this is also visible as a short 100%
steal spike).

> and the normal CPU user/system values,
> including idle, are always 0.  When running a cpu-intensive app and
> using the "top" utility, the user and system values are always 0, the
> "idle" field stays at 100%, and only the "wait" field increases.

Sounds a lot like this one:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871608

A patch to fix that cpu accounting breakage (picked from linux 4.15) was
included in 4.9.65-3. So only for the 4.9.0-3 (which actual version?)
you could be seeing that one happening.

> The attached file shows the "sar" output around the time the issue
> started.  This has happened on 2 separate machines (started at different
> times on each), and a reboot appears to (temporarily) fix the issue. 
> I'm wondering if anyone else has this issue, and if it could be
> something to do with the hypervisor.

Because of the mentioned steal time fix that was included in a version
in between the 2 versions you mention, my first suggestion would be to
see if the symptoms on the old and new kernel are exactly the same, or
if they are only similar but different.

Hans

Bug#887676: Stretch kernel 4.9.0-5-amd64 breaks Xen PVH support

[Hans van Kranenburg]

Control: forcemerge 886591 -1

Hi,

On 01/19/2018 01:30 AM, Michael J. Redd wrote:
> Package: linux-image-amd64
> Version: 4.9+80+deb9u
> 
> [...]
> 
> Latest Stretch kernel (4.9.0-5-amd64), released per DSA-4082-1, breaks
> Xen PVH domU support.

If you are using Xen 4.8, then it's the obsolete PVH v1.

Sorry to be the one that has to make your day miserable, but PVH was not
supposed to be used by end users and not supported in any way before Xen
4.10 and Linux kernel 4.11 in the guest.

That means, there is no solution for this and there will not be.

https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00540.html

Hans

Re: Xen security update [was: Re: [Pkg-xen-devel] Xen packaging in Debian - Progress update]

[Hans van Kranenburg]

On 01/10/2018 08:54 AM, Wolodja Wentland wrote:
> Hans van Kranenburg <h...@knorrie.org> writes:
> 
>> == Security update for Stretch ==
>>
>> On IRC I got some questions about the already earlier released XSA
>> patches, which still aren't in Stretch.
> 
> It would be a lovely if a security upload that includes patches for the
> following XSAs could be prepared, given that many people will reboot
> their hypervisors these days:
> 
> - https://xenbits.xen.org/xsa/advisory-248.html
> - https://xenbits.xen.org/xsa/advisory-249.html
> - https://xenbits.xen.org/xsa/advisory-250.html
> - https://xenbits.xen.org/xsa/advisory-251.html
> 
> These are all single patches that apply cleanly to 4.8 (with some fuzz)
> and will have been deployed in locally built packages by many.

Yes, that's what that whole section was about. See the links in my
previous message.

Got reply from security team: "Thanks, I'll get back to you end of week."

Hans

Re: Xen packaging in Debian - Progress update

[Hans van Kranenburg]

Hi,

On 12/22/2017 02:01 AM, Hans van Kranenburg wrote:
> To: Debian xen and kernel team list, Ian Jackson

I'm replying to my own email, since there has not been a reply on the
lists to it yet.

For Ian Jackson: There's a question for you below (section "Moving
packaging repository"), can you please answer that.

== What's happening? (skip this section if you're busy) ==

Three weeks ago, when I started working on this, I didn't remotely know
what would happen on Jan 3, but I like the rollercoaster ride.

In the past days:
* ...I've been working to get the packaging moved on from 4.9 to Xen 4.10.
* ...I could help the kernel team a bit with handling xen-related
regression bugs that were reported on the updated linux packages.
* ...replied to a few other open Xen bugs.
* Moritz from the security team mailed me like "Hey! Did you get any
response on that email? What's gonna happen to xen?" and I told him what
was going on and that I'd like to help wherever I can.
* ...the #debian-xen IRC channel on OFTC has become active again, others
have been joining and offering more help, and we're discussing all kind
of things, about packaging, but also about upgrade tactics for any size
Xen cluster we're managing ourselves.

== Security update for Stretch ==

On IRC I got some questions about the already earlier released XSA
patches, which still aren't in Stretch.

Question for security team: If you want to have it, I've prepared an
update for in the mean time. [0] [1] [2]. I'm not a Maintainer yet, but
at least I have some GPG signatures of Debian Developers now. ;]

== Xen 4.10 ==

We're still all looking at upstream to find out what they're going to do
in the next days.

My gut feeling is that a not-neglectible part of users is looking into
upgrading to Xen 4.10 and Linux 4.14 in the domU. It would be really
great if Debian could have Xen 4.10 in testing and stretch-backports.

So, in the meantime I'm trying to get a proper Xen 4.10 package in order
for unstable. The build doesn't work completely yet, but if there's a
dpkg-shlibdeps expert around, maybe you can help. More info on IRC.

In general, If someone with more intimate knowledge of Xen can help
review the changes, always welcome, as well as beta-testers for new
packages.

== Moving packaging repository ==

It makes sense to get the cleaned up packaging code moved to a new
Debian Xen team owned repo at the new Debian Gitlab hosting.

Ian: Can you please ACK that it's ok if we go on with this and take
ownership to get it set up? Thanks.

== Thanks for your time ==

Regards,
Hans van Kranenburg

[0]
https://github.com/knorrie/debian-xen/commit/d3922c423010894d5badfc5381a7312b90715cbf

[1]
https://github.com/knorrie/debian-xen/releases/tag/debian%2F4.8.2%2Bxsa245-0%2Bdeb9u2

[2] https://syrinx.knorrie.org/~knorrie/xen/stretch-security/



signature.asc
Description: OpenPGP digital signature

Bug#886491: Bug#886591: 4.9.0-5 (after kaiser patch) breaks xen pvh

[Hans van Kranenburg]

tags 886491 + wontfix
tags 886591 + wontfix
thanks

On 01/07/2018 11:28 PM, Hans van Kranenburg wrote:
> 
> Thanks for your report. This does not render the complete package
> unusable for any user.

The answer from upstream Xen to this is:

https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00540.html

So, breakage is expected and it's not going to be fixed.

Hans van Kranenburg

Bug#886591: 4.9.0-5 (after kaiser patch) breaks xen pvh

[Hans van Kranenburg]

# ok, let's try again...
severity 886591 important
reassign 886591 src:linux 4.9.65-3+deb9u2
merge 886591 886491
thanks

Thanks for your report. This does not render the complete package
unusable for any user.

Hans

Bug#886491: linux-image-4.9.0-5-amd64: Does not boot as Xen guest in HVM mode

[Hans van Kranenburg]

On 01/07/2018 06:42 PM, Michael Stone wrote:
> retitle 886491 linux-image-4.9.0-5-amd64: Does not boot as Xen guest in
> PVH mode
> thanks
> 
> HVM and PVH are two different modes. The fix suggested in this bug
> report (commenting out pvh=1 in the conf file) points to the problem
> being the latter. I can confirm that PVH guests fail to boot using
> 4.9.0-5 and a conf file that boots fine with -3.

I don't understand this line:

>> It is running but only in pv mode, not in hvm mode
>> (commenting out pvh=1 in the guest config file).

Yes, pv, pvh and hvm are all different things, but I don't understand
what reporter is actually doing. What scenario does commenting something
out cause?

And as far as I know using PVH is not supported with a Xen before 4.10?

Hans

Bug#886491: linux-image-4.9.0-5-amd64: Does not boot as Xen guest in HVM mode

[Hans van Kranenburg]

troller: Intel Corporation 8 Series HECI #0 (rev 04)
> Subsystem: Intel Corporation 8 Series HECI
> Flags: bus master, fast devsel, latency 0, IRQ 75
> Memory at f7c3e000 (64-bit, non-prefetchable) [size=32]
> Capabilities: [50] Power Management version 3
> Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Kernel driver in use: mei_me
> Kernel modules: mei_me
> 
> 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I218-V 
> (rev 04)
> Subsystem: Intel Corporation Ethernet Connection I218-V
> Flags: bus master, fast devsel, latency 0, IRQ 72
> Memory at f7c0 (32-bit, non-prefetchable) [size=128K]
> Memory at f7c3c000 (32-bit, non-prefetchable) [size=4K]
> I/O ports at f080 [size=32]
> Capabilities: [c8] Power Management version 2
> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Capabilities: [e0] PCI Advanced Features
> Kernel driver in use: e1000e
> Kernel modules: e1000e
> 
> 00:1b.0 Audio device: Intel Corporation 8 Series HD Audio Controller (rev 04)
> Subsystem: Intel Corporation 8 Series HD Audio Controller
> Flags: bus master, fast devsel, latency 0, IRQ 76
> Memory at f7c3 (64-bit, non-prefetchable) [size=16K]
> Capabilities: [50] Power Management version 3
> Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
> Capabilities: [100] Virtual Channel
> Kernel driver in use: snd_hda_intel
> Kernel modules: snd_hda_intel
> 
> 00:1d.0 USB controller: Intel Corporation 8 Series USB EHCI #1 (rev 04) 
> (prog-if 20 [EHCI])
> Subsystem: Intel Corporation 8 Series USB EHCI
> Flags: medium devsel, IRQ 23
> Memory at f7c3b000 (32-bit, non-prefetchable) [size=1K]
> Capabilities: [50] Power Management version 3
> Capabilities: [58] Debug port: BAR=1 offset=00a0
> Capabilities: [98] PCI Advanced Features
> Kernel driver in use: ehci-pci
> Kernel modules: ehci_pci
> 
> 00:1f.0 ISA bridge: Intel Corporation 8 Series LPC Controller (rev 04)
> Subsystem: Intel Corporation 8 Series LPC Controller
> Flags: bus master, medium devsel, latency 0
> Capabilities: [e0] Vendor Specific Information: Len=0c 
> Kernel driver in use: lpc_ich
> Kernel modules: lpc_ich
> 
> 00:1f.2 SATA controller: Intel Corporation 8 Series SATA Controller 1 [AHCI 
> mode] (rev 04) (prog-if 01 [AHCI 1.0])
> Subsystem: Intel Corporation 8 Series SATA Controller 1 [AHCI mode]
> Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 74
> I/O ports at f0d0 [size=8]
> I/O ports at f0c0 [size=4]
> I/O ports at f0b0 [size=8]
> I/O ports at f0a0 [size=4]
> I/O ports at f060 [size=32]
> Memory at f7c3a000 (32-bit, non-prefetchable) [size=2K]
> Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
> Capabilities: [70] Power Management version 3
> Capabilities: [a8] SATA HBA v1.0
> Kernel driver in use: ahci
> Kernel modules: ahci
> 
> 00:1f.3 SMBus: Intel Corporation 8 Series SMBus Controller (rev 04)
> Subsystem: Intel Corporation 8 Series SMBus Controller
> Flags: medium devsel, IRQ 18
> Memory at f7c39000 (64-bit, non-prefetchable) [size=256]
> I/O ports at f040 [size=32]
> Kernel driver in use: i801_smbus
> Kernel modules: i2c_i801
> 
>>
>> Since the domU is running linux-image-4.9.0-5-amd64 that can only mean it's
>> the kernel update just done, which is version 4.9.65-3+deb9u2
> It is running but only in pv mode, not in hvm mode
> (commenting out pvh=1 in the guest config file).
> 
>> When reporting kernel versions, note that the package name and the actual
>> version can be different. So please always include the real package version,
>> like 4.9.65-3 or whatever in case of linux-image-4.9.0-4-amd64.
>>
>> Anything you could do yourself to narrow down the issue would help.
>>
> What happens is that pygrub succeeds in processing menu.lst at domU.
> It seems not to load the kernel however (but if I do boot in pv mode it does).
> I get somehow the impression that the xen drivers for hvm are not loaded.
> But I cannot check that.
> If there is some logging I can turn on, I am happy to do so.

Ok, thanks for the additional information. I included the debian bug
email address again and did not remove any of your reply, so it's visible.

Sadly, I have no ready to go answer now, but at least this adds more
info to get forward.

Hans

Bug#886491: linux-image-4.9.0-5-amd64: Does not boot as Xen guest in HVM mode

[Hans van Kranenburg]

Hi jgfrm,

On 01/06/2018 06:41 PM, jgfrm wrote:
> Package: linux-image-4.9.0-5-amd64
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> Upgrade of linux-image-4.9.0-3-amd64 to linux-image-4.9.0-5-amd64
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Disable hvm guest boot in hypervisor
> 
>* What was the outcome of this action?
> Guest boots in pv mode
>* What outcome did you expect instead?
> Use hvm mode in guest config file, such that guest boots in hvm mode
> 
> *** End of the template - remove these template lines ***
> 
> 
> -- System Information:
> Debian Release: 8.10
>   APT prefers oldstable
>   APT policy: (500, 'oldstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 

The first step here is to collect more information. Things that are or
are not working with Xen setups can be difficult to track down, since it
can be related to any combination of anything like hardware, hypervisor,
dom0, domU etc...

>From your description I guess that changing domU from
linux-image-4.9.0-3-amd64 to linux-image-4.9.0-5-amd64 while all other
things remain the same caused the issue. Is that right?



I see you're using Debian Release: 8.10, which might imply Xen 4.4 and
the jessie kernel for the dom0.

As seen from the dom0, can you please reply with `uname -a`, `xen info`
and `lspci -v` output.

Since the domU is running linux-image-4.9.0-5-amd64 that can only mean
it's the kernel update just done, which is version 4.9.65-3+deb9u2

When reporting kernel versions, note that the package name and the
actual version can be different. So please always include the real
package version, like 4.9.65-3 or whatever in case of
linux-image-4.9.0-4-amd64.

Anything you could do yourself to narrow down the issue would help.

With enough information, someone else might be able to reproduce the
same situation and confirm the issue.

Hans van Kranenburg

Xen packaging in Debian

[Hans van Kranenburg]

To: Debian xen and kernel team list, Ian Jackson
Cc: Stefan Bader, maintainer of xen packages in Ubuntu

Hi all,

Short version: Hi! I'd like to help with the Xen packaging in Debian.

Long version:

Q: Who are you? How are you related to Debian an the Xen project?
A: Hi, I'm Hans van Kranenburg, nickname Knorrie, I live in the
Netherlands. I'm a Debian user since 2002, and have been using Debian
and Xen at work (Mendix) since 2006, which has grown from a handful
dom0s with 4GiB memory each to a bunch of clusters with let's say
somewhere between 10TiB and 20TiB of physical memory in the dom0s
together, running a production environment for customer application hosting.

My general interests are filesystems and networking and I like
programming in Python. At work, we've been maintaining our own debian
repository for many years, with our own packages, changed Debian
packages and custom backports, which caused me to pick up some Debian
packaging skills along the way.

Q: And why the sudden interest?
A: Some problems we ran into in the last year+ caused me to have a
better look at the Xen releases and the packages in Debian.

The situation I ran into is best described as: "Wait... I'm running a
Xen version from Debian Stable (at the time of realizing that's Jessie)
that was released before the type of hardware I have here was invented
and manufactured, it's out of support and out of security support
upstream and I'm surprised weird things are going on?" Maybe we should
reverse this a bit and see if we can keep up to date with Xen stable
releases that know about certain quirks of the hardware.

The sad part is that I quickly discovered the xen packages aren't really
actively maintained in Debian. Luckily we got a newer version in Stretch
just before the freeze and currently Ian Jackson is keeping everything
on life support (thanks!!). Current packaging is not tracked in version
control (well, not on a level of granularity that I would deem
acceptable) and the contents are being changed based on unpacking the
previous upload and changing old generated files in place, disregarding
the way how the package was set up in the past (which is quite similar
to how the linux kernel packaging for Debian works).

Q: So, let's sit in a corner and cry?
A: No, we can do better. A few days ago I started reaching out to see if
I could find members of the Xen team and ended up talking to Ian Jackson
in #debian-kernel. He encouraged me to take a further look and was
immediately available to help and answer any questions I would have.

What I did in the last few days is basically clean up the packaging to
get it back to a state where it's usable again. So, move the packaging
back to git, import the latest release and then fix enough things to be
able to at least produce new security updates for Stretch and get a
newer package into unstable.

I uploaded the work it to github [0] for now. It can be moved anywhere
else later. I tend to write things in commit messages, so please have a
look.

Besides preparing a new version for stretch-security as an example, I
moved the packaging forward to Xen 4.9, by taking the relevant changes
done by Stefan Bader in Ubuntu (thanks!!) and merge them back into the
packaging.

I (smoke)tested the resulting packages in my test environment at work.
To be able to properly test I put them in a repository at [1].

Note that I'm not a Debian Maintainer (yet). I do have packages in
Debian with my work on btrfs, the uploads are sponsored by Adam
Borowski. [2]

I guess that it'd be good to finally take the step to apply for Debian
Maintainer status when starting to work on low level security sensitive
packages like this. Luckily, we have a Debian keysigning party in the
next days in The Netherlands, so I have a quick opportinity to get
things in order. :]

I have already identified quite a few topics I'd like to discuss next,
but, let's take it one step at a time, I typed enough already here. :)

Regards,
Hans van Kranenburg

[0] https://github.com/knorrie/debian-xen/
[1] https://packages.knorrie.org/xen/debian/pool/main/x/xen/
[2] https://qa.debian.org/developer.php?login=hans%40knorrie.org

Bug#871608: linux-image-4.9.0-3-amd64: Linux kernel should handle decreasing cpu steal clock counter gracefully

[Hans van Kranenburg]

On 11/16/2017 02:19 PM, Hans van Kranenburg wrote:
> 
> Latest work on this:
> 
> https://patchwork.kernel.org/patch/10035835/
> 
> "Applied to for-linus-4.15."

Ok, I just built a 4.9.65 kernel with this patch on top and the config
from debian (config-4.9.0-4-amd64). It applies without complaints:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5e25f5db6abb96ca8ee2aaedcb863daa6dfcc07a

With the 4.9.51-1 from Stretch I can reliably reproduce the broken CPU
counters after doing live migration with Xen once or maybe twice.

The 4.9.65 + steal time patch survived throwing it around >20 times now,
and there's no sign of any weird behaviour any more.

Counters in /proc/stat keep showing values that still make sense,
instead of suddenly jumping to values like 1174983480817 or 1753913027832...

How do we proceed from here?

-- 
Hans van Kranenburg

Bug#871608: linux-image-4.9.0-3-amd64: Linux kernel should handle decreasing cpu steal clock counter gracefully

[Hans van Kranenburg]

Hi,

I ran into the same issue with 4.9.51-1 in the guest. My dom0 in this
case is still Jessie with its xen 4.4 version. Users (rightfully) worry
about what's suddenly wrong with their virtual machine, since the steal
values mess up the cpu graphs.

I see that all the discussions linked above have gone silent quickly
without a solution.

A post to the Xen mailing list on Aug 31th did not get any answer yet:
https://lists.xen.org/archives/html/xen-users/2017-08/msg00092.html

I see that the issue got fixed by replacing the code with a new
implementation of the same functionality. I guess this is a scenario
that sometimes happens, not having a ready to go fix available for the
previous LTS kernel.

So, what would be the best step forward here? Should we poke the Xen
people a bit more to find out how to approach this, or get an opinion on
the best and smallest patch to go with?

I'm not an expert in the cpu time accounting area, but I can help
testing etc...

Thanks,

--
Hans van Kranenburg

Bug#878403: linux-image-4.13.0-1-686-pae (and prior version!) crashes at boot

[Hans]

Dear maintainers,

got the kernel now running. 

Solution: 

In /etc/default/grub I had to comment the following lines:

GRUB_GFXMODE=1024x600
GRUB_GFXPAYLOAD_LINUX=keep

I believe, the latest kernel-module is not capable to run the resolution of 
1024x600 (which is the native resolution of my netbook).

With the former kernels (version 4.12 and earlier), this worked fine. As I do 
not know, if this is a bug or a feature, I let it to you to decide, what it 
is.

For me, this bugreport can be safely closed. However, if it is really a bug, 
just leave it open. I am happy with both ones. 

Thanks for reading this and best regards

Hans

Bug#878403: linux-image-4.13.0-1-686-pae (and prior version!) crashes at boot

[Hans]

Dear maintainers,

this bug seem to appear only in the kernel of debian. I built a kali live 
system (with same kernel version) and this is working fine. 

I admit, that the kali maintainers sometimes patch their kernels, but on the 
other hand, IMO you should know, that this might be a debian specific problem.

Thank you for reading this.

Best regards

Hans

Bug#878403: linux-image-4.13.0-1-686-pae (and prior version!) crashes at boot

[Hans-J. Ullrich]

]  ? 
intel_fbdev_initial_config+0x13/0x30 [i915]
Oct  2 08:42:04 localhost kernel: [   22.276836]  ? 
async_run_entry_fn+0x30/0x150
Oct  2 08:42:04 localhost kernel: [   22.276843]  ? process_one_work+0x135/0x2f0
Oct  2 08:42:04 localhost kernel: [   22.276850]  ? worker_thread+0x39/0x3a0
Oct  2 08:42:04 localhost kernel: [   22.276856]  ? kthread+0xd7/0x110
Oct  2 08:42:04 localhost kernel: [   22.276862]  ? process_one_work+0x2f0/0x2f0
Oct  2 08:42:04 localhost kernel: [   22.276867]  ? 
kthread_create_on_node+0x30/0x30
Oct  2 08:42:04 localhost kernel: [   22.276874]  ? ret_from_fork+0x19/0x24
Oct  2 08:42:04 localhost kernel: [   22.276878] Code: 88 f0 01 00 00 0f b7 52 
26 89 90 f4 01 00 00 eb d3 8d 76 00 8d bc 27 00 00 00 00 83 c4 08 5b 5e 5f 5d 
c3 90 8d b4 26 00 00 00 00 <0f> ff e9 7e fe ff ff 89 f6 8d bc 27 00 00 00 00 0f 
ff e9 18 ff
Oct  2 08:42:04 localhost kernel: [   22.276984] ---[ end trace 
b2c434140b39c81f ]---


-  end -

At the moment I have to get back to the old kernel, as the latst is not usable. 
I can not tzell, if this apears on 64-bit systems, too, mine is a 32-bit system 
(EEEPC 1005 HGO).

Thank you for any help and your work.

Best regards

Hans

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages linux-image-4.13.0-1-686-pae depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.130
ii  kmod24-1
ii  linux-base  4.5

Versions of packages linux-image-4.13.0-1-686-pae recommends:
ii  firmware-linux-free  3.4
ii  irqbalance   1.1.0-2.3

Versions of packages linux-image-4.13.0-1-686-pae suggests:
pn  debian-kernel-handbook  
ii  extlinux3:6.03+dfsg-14.1
ii  grub-pc 2.02-2
pn  linux-doc-4.13  

Versions of packages linux-image-4.13.0-1-686-pae is related to:
ii  firmware-amd-graphics 20170823-1
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
ii  firmware-linux-nonfree20170823-1
ii  firmware-misc-nonfree 20170823-1
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
ii  firmware-realtek  20170823-1
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#872917: linux-image-4.12: Missing CONFIG_VIDEO_VIM2M

[Hans Verkuil]

Package: src:linux
Version: 4.12.6-1
Severity: normal
File: linux-image-4.12

Dear Maintainer,

The virtual memory-to-memory driver is not enabled in the kernel.
It is very useful to have that enabled just like the virtual capture driver
VIVID. This makes it easy for applications to be developed/tested against a
virtual driver so no actual hardware is needed.

Regards,

Hans Verkuil
V4L2/CEC kernel co-maintainer


-- Package-specific info:
** Version:
Linux version 4.12.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 
6.4.0 20170805 (Debian 6.4.0-3) ) #1 SMP Debian 4.12.6-1 (2017-08-12)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.12.0-1-amd64 
root=UUID=6db3c566-9220-4a46-9bac-74b586336f5d ro console=tty0 
console=ttyS0,38400

** Tainted: PO (4097)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.

** Kernel log:
[ 9494.397422] vivid-000: V4L2 transmitter device registered as radio1
[43693.960430] audit: type=1702 audit(1503181198.700:2): op=linkat ppid=40970 
pid=11090 auid=1026 uid=1026 gid=1000 euid=1026 suid=1026 fsuid=1026 egid=1000 
sgid=1000 fsgid=1000 tty=pts2 ses=3 comm="ln" exe="/bin/ln" res=0
[43694.018752] audit: type=1302 audit(1503181198.700:3): item=0 
name=2F6D6E742F6E6173312F6D656469612F74762F4D2D502F4D6964736F6D6572204D7572646572732F5330382F3036202D2048696464656E204465707468732E656E672E737274
 inode=139377 dev=00:2f mode=0100444 ouid=1024 ogid=100 rdev=00:00 
nametype=NORMAL
[43694.094985] audit: type=1702 audit(1503181198.702:4): op=linkat ppid=40970 
pid=11092 auid=1026 uid=1026 gid=1000 euid=1026 suid=1026 fsuid=1026 egid=1000 
sgid=1000 fsgid=1000 tty=pts2 ses=3 comm="ln" exe="/bin/ln" res=0
[43694.153277] audit: type=1302 audit(1503181198.702:5): item=0 
name=2F6D6E742F6E6173312F6D656469612F74762F4D2D502F4D6964736F6D6572204D7572646572732F5330382F3037202D20536175636520666F722074686520476F6F73652E656E672E737274
 inode=139378 dev=00:2f mode=0100444 ouid=1024 ogid=100 rdev=00:00 
nametype=NORMAL
[43694.232624] audit: type=1702 audit(1503181198.706:6): op=linkat ppid=40970 
pid=11094 auid=1026 uid=1026 gid=1000 euid=1026 suid=1026 fsuid=1026 egid=1000 
sgid=1000 fsgid=1000 tty=pts2 ses=3 comm="ln" exe="/bin/ln" res=0
[43694.290911] audit: type=1302 audit(1503181198.706:7): item=0 
name=2F6D6E742F6E6173312F6D656469612F74762F4D2D502F4D6964736F6D6572204D7572646572732F5330382F3038202D204D6964736F6D65722052686170736F64792E656E672E737274
 inode=139379 dev=00:2f mode=0100444 ouid=1024 ogid=100 rdev=00:00 
nametype=NORMAL
[43694.369223] audit: type=1702 audit(1503181198.708:8): op=linkat ppid=40970 
pid=11096 auid=1026 uid=1026 gid=1000 euid=1026 suid=1026 fsuid=1026 egid=1000 
sgid=1000 fsgid=1000 tty=pts2 ses=3 comm="ln" exe="/bin/ln" res=0
[43694.427510] audit: type=1302 audit(1503181198.709:9): item=0 
name=2F6D6E742F6E6173312F6D656469612F74762F4D2D502F4D6964736F6D6572204D7572646572732F5330382F3031202D205468696E6773205468617420476F2042756D7020696E20746865204E696768742E656E672E737274
 inode=139380 dev=00:2f mode=0100444 ouid=1024 ogid=100 rdev=00:00 
nametype=NORMAL
[43694.513619] audit: type=1702 audit(1503181198.711:10): op=linkat ppid=40970 
pid=11098 auid=1026 uid=1026 gid=1000 euid=1026 suid=1026 fsuid=1026 egid=1000 
sgid=1000 fsgid=1000 tty=pts2 ses=3 comm="ln" exe="/bin/ln" res=0
[43694.572168] audit: type=1302 audit(1503181198.711:11): item=0 
name=2F6D6E742F6E6173312F6D656469612F74762F4D2D502F4D6964736F6D6572204D7572646572732F5330382F3032202D204465616420696E207468652057617465722E656E672E737274
 inode=139381 dev=00:2f mode=0100444 ouid=1024 ogid=100 rdev=00:00 
nametype=NORMAL
[86595.115745] device enp132s0 left promiscuous mode
[86595.130070] bridge-enp132s0: disabled promiscuous mode
[86610.356226] /dev/vmnet: open called by PID 15820 (vmx-vcpu-0)
[86610.356241] device enp132s0 entered promiscuous mode
[86610.371262] bridge-enp132s0: enabled promiscuous mode
[86610.386400] /dev/vmnet: port on hub 0 successfully opened
[161754.576422] /dev/vmnet: open called by PID 36913 (vmx-vcpu-0)
[161754.576444] /dev/vmnet: port on hub 0 successfully opened
[223374.201510] nfs: server 192.168.1.11 not responding, timed out
[223644.522111] nfs: server 192.168.1.11 not responding, timed out
[223941.465224] nfs: server 192.168.1.11 not responding, timed out
[224162.636709] nfs: server 192.168.1.11 not responding, timed out
[224469.819267] nfs: server 192.168.1.11 not responding, timed out
[224690.990620] nfs: server 192.168.1.11 not responding, timed out
[224998.173129] nfs: server 192.168.1.11 not responding, timed out
[225219.344617] nfs: server 192.168.1.11 not responding, timed out
[225526.527100] nfs: server 192.168.1.11 not responding, timed out
[225747.698581] nfs: server 192.168.1.11 not responding, timed out
[226054.881045] nfs: server 192.168.1.11 not responding, timed out
[226276.052595] nfs: server 192.168.1.11 not responding, time

Bug#872644: linux-image-4.12.0-1-686-pae: Olinux-imag-4.12.0-1-686-pae sends crash messags at boot

[Hans]

ocalhost kernel: [   22.343587]  ? process_one_work
+0x380/0x380
Aug 14 16:20:50 localhost kernel: [   22.343592]  ? kthread_create_on_node
+0x30/0x30
Aug 14 16:20:50 localhost kernel: [   22.343596]  ? ret_from_fork+0x1c/0x28
Aug 14 16:20:50 localhost kernel: [   22.343603] ---[ end trace 
e3014e12a8add248 ]---


-- snap --

You may right, it looks like the framebuffer module is involved. However, as I 
told before, it is not harmful and everything is working fine, also graphics 
looks good.

Hope it helps either.

Best 

Hans

Bug#872650: linux-image-4.12.0-1-amd64: Please enable CONFIG_MEDIA_CEC_RC

[Hans Verkuil]

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

Dear Maintainer,

In bug 868511 I requested that some CEC drivers were enabled in the kernel
(they are, and thank you very much for doing this).

Unfortunately I forgot to mention that CONFIG_MEDIA_CEC_RC should also
be enabled to integrate CEC with the remote control subsystem.

Can you enable that as well?

Thank you,

Hans Verkuil
CEC subsystem maintainer


-- Package-specific info:
** Version:
Linux version 4.12.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 
6.4.0 20170805 (Debian 6.4.0-3) ) #1 SMP Debian 4.12.6-1 (2017-08-12)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.12.0-1-amd64 
root=UUID=6db3c566-9220-4a46-9bac-74b586336f5d ro console=tty0 
console=ttyS0,38400

** Tainted: PO (4097)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.

** Kernel log:
[  200.172079] pulse8-cec serio0: Firmware build date 2015.01.27 16:14:39
[  896.983212] NET: Unregistered protocol family 40
[  897.623528] Guest personality initialized and is inactive
[  897.639759] VMCI host device registered (name=vmci, major=10, minor=57)
[  897.659568] Initialized host personality
[  897.699766] NET: Registered protocol family 40
[  900.471051] NET: Unregistered protocol family 40
[  948.751813] Guest personality initialized and is inactive
[  948.768030] VMCI host device registered (name=vmci, major=10, minor=57)
[  948.787842] Initialized host personality
[  948.822309] NET: Registered protocol family 40
[  966.560362] NET: Unregistered protocol family 40
[  966.930247] Guest personality initialized and is inactive
[  966.946508] VMCI host device registered (name=vmci, major=10, minor=57)
[  966.966337] Initialized host personality
[  967.005735] NET: Registered protocol family 40
[  975.303946] NET: Unregistered protocol family 40
[  975.653733] Guest personality initialized and is inactive
[  975.670002] VMCI host device registered (name=vmci, major=10, minor=57)
[  975.689809] Initialized host personality
[  975.728061] NET: Registered protocol family 40
[ .726315] NET: Unregistered protocol family 40
[ 1112.318799] Guest personality initialized and is inactive
[ 1112.335088] VMCI host device registered (name=vmci, major=10, minor=57)
[ 1112.354903] Initialized host personality
[ 1112.396797] NET: Registered protocol family 40
[ 1115.178131] NET: Unregistered protocol family 40
[ 1155.417492] Guest personality initialized and is inactive
[ 1155.433729] VMCI host device registered (name=vmci, major=10, minor=57)
[ 1155.453552] Initialized host personality
[ 1155.489508] NET: Registered protocol family 40
[ 1172.539782] NET: Unregistered protocol family 40
[ 1172.878231] Guest personality initialized and is inactive
[ 1172.894515] VMCI host device registered (name=vmci, major=10, minor=57)
[ 1172.914341] Initialized host personality
[ 1172.952831] NET: Registered protocol family 40
[ 1182.075389] NET: Unregistered protocol family 40
[ 1182.464403] Guest personality initialized and is inactive
[ 1182.480683] VMCI host device registered (name=vmci, major=10, minor=57)
[ 1182.500512] Initialized host personality
[ 1182.545352] NET: Registered protocol family 40
[ 1212.882112] NET: Unregistered protocol family 40
[ 1213.212129] Guest personality initialized and is inactive
[ 1213.228382] VMCI host device registered (name=vmci, major=10, minor=57)
[ 1213.248192] Initialized host personality
[ 1213.285168] NET: Registered protocol family 40
[ 1308.934160] NET: Unregistered protocol family 40
[ 1309.246158] /dev/vmmon[17854]: Module vmmon: registered with major=10 
minor=165
[ 1309.246161] /dev/vmmon[17854]: Using tsc_khz as TSC frequency: 2709937
[ 1309.246162] /dev/vmmon[17854]: Module vmmon: initialized
[ 1309.258333] Guest personality initialized and is inactive
[ 1309.274604] VMCI host device registered (name=vmci, major=10, minor=57)
[ 1309.294405] Initialized host personality
[ 1309.329458] NET: Registered protocol family 40
[ 1309.561632] /dev/vmnet: open called by PID 17969 (vmnet-bridge)
[ 1309.561637] /dev/vmnet: hub 0 does not exist, allocating memory.
[ 1309.561650] /dev/vmnet: port on hub 0 successfully opened
[ 1309.561658] bridge-enp132s0: up
[ 1309.561662] bridge-enp132s0: attached
[ 1310.594413] /dev/vmnet: open called by PID 17976 (vmnet-netifup)
[ 1310.594419] /dev/vmnet: hub 1 does not exist, allocating memory.
[ 1310.594439] /dev/vmnet: port on hub 1 successfully opened
[ 1310.670130] /dev/vmnet: open called by PID 17979 (vmnet-dhcpd)
[ 1310.670139] /dev/vmnet: port on hub 1 successfully opened
[ 1310.676410] /dev/vmnet: open called by PID 17991 (vmnet-natd)
[ 1310.676419] /dev/vmnet: hub 8 does not exist, allocating memory.
[ 1310.676445] /dev/vmnet: port on hub 8 successfully opened
[ 1310.677780] userif-3: sent link down event.
[ 1310.680277] /dev/vmnet: open called by PID 17992 (vmnet-netifup)
[ 1310.680295] /dev/vmnet: port on hub 8 successfully opened
[ 1310.690820] userif-3: sent link up

Bug#872644: linux-image-4.12.0-1-686-pae: Olinux-imag-4.12.0-1-686-pae sends crash messags at boot

[Hans-J. Ullrich]

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

Dear Maintainer,

my debian/testing system got /usr, /var and /home luks encrypted. At boot, as 
soon as I entered the passwort for the first partition to decrypt (which is 
always /usr), I get a bunch of messages, that something is crashed. However, 
this is not destructive and I can get booting on by decrypting /var and /home.

I would like to send the messages to you, but I see no way, to file these 
messages, as they are in a too early state, when a kernekl log or a boot log is 
yet not written.

If you can tell me a way, to file down the messages as soon as the kernel 
starts (maybe there is a kernel command or a grub command, which let me do 
this), then I would be happy to send you the messages. I suppose, the message 
is related to my bios. I am running an EEEPC 1005HGO with an intel N270 cpu. 
Most messqages, which are generated are intel oriented and named, and added 
with hex addresses.

Please drop me a line, if you are interested in more. If not, I will just wait 
for the next kernel version. 

As I said, it is weired, but not destroyable.

Best regards

Hans  


 Package-specific info:
** Version:
Linux version 4.12.0-1-686-pae (debian-kernel@lists.debian.org) (gcc version 
6.4.0 20170805 (Debian 6.4.0-3) ) #1 SMP Debian 4.12.6-1 (2017-08-12)

** Command line:
BOOT_IMAGE=/vmlinuz-4.12.0-1-686-pae 
root=UUID=da2bbacb-1b05-461e-8b72-9eef666b9bf6 ro net.ifnames=0 quiet 
acpi_osi=Linux

** Tainted: W (512)
 * Taint on warning.

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

** Model information

** Loaded modules:
rfcomm
fuse
xt_multiport
iptable_filter
irda
crc_ccitt
decnet
appletalk
ax25
ipx
p8023
p8022
psnap
llc
ctr
ccm
snd_hrtimer
snd_seq_midi
snd_seq_midi_event
snd_rawmidi
snd_seq
snd_seq_device
cpufreq_conservative
cpufreq_userspace
cpufreq_powersave
bnep
binfmt_misc
iTCO_wdt
iTCO_vendor_support
option
usb_wwan
usbserial
arc4
uvcvideo
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_core
btusb
btrtl
btbcm
btintel
bluetooth
ecdh_generic
coretemp
joydev
evdev
serio_raw
snd_hda_codec_realtek
snd_hda_codec_generic
ath9k
ath9k_common
sg
snd_hda_intel
ath9k_hw
ath
i915
snd_hda_codec
snd_hda_core
snd_hwdep
snd_pcm_oss
snd_mixer_oss
lpc_ich
mfd_core
mac80211
snd_pcm
drm_kms_helper
snd_timer
snd
rng_core
soundcore
cfg80211
drm
wmi
eeepc_laptop
i2c_algo_bit
sparse_keymap
rfkill
shpchp
ac
acpi_cpufreq
button
video
battery
gspca_sn9c20x
gspca_main
v4l2_common
videodev
media
loop
atl1
mii
parport_pc
ppdev
lp
parport
ip_tables
x_tables
autofs4
ext4
crc16
jbd2
crc32c_generic
fscrypto
mbcache
ecb
lrw
gf128mul
algif_skcipher
af_alg
uas
usb_storage
hid_generic
usbhid
hid
dm_crypt
dm_mod
crypto_simd
cryptd
aes_i586
sd_mod
psmouse
ahci
libahci
libata
scsi_mod
uhci_hcd
ehci_pci
ehci_hcd
usbcore
usb_common
atl1c
thermal

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GSE Express Memory 
Controller Hub [8086:27ac] (rev 03)
Subsystem: ASUSTeK Computer Inc. Mobile 945GSE Express Memory 
Controller Hub [1043:8340]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort+ 
<MAbort+ >SERR- 

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GSE 
Express Integrated Graphics Controller [8086:27ae] (rev 03) (prog-if 00 [VGA 
controller])
Subsystem: ASUSTeK Computer Inc. Mobile 945GSE Express Integrated 
Graphics Controller [1043:8340]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 
943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03)
Subsystem: ASUSTeK Computer Inc. Mobile 945GM/GMS/GME, 943/940GML 
Express Integrated Graphics Controller [1043:8340]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:1b.0 Audio device [0403]: Intel Corporation NM10/ICH7 Family High Definition 
Audio Controller [8086:27d8] (rev 02)
Subsystem: ASUSTeK Computer Inc. NM10/ICH7 Family High Definition Audio 
Controller [1043:8398]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 
1 [8086:27d0] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemW

Bug#865866: libreoffice-writer crash on startup Debian 9 i386 arch

[Hans]

Hi folks,

here is another trick:

1. Just install linux-image-4.9.0-0-*** from backports. 

2. Then boot with it, and libreoffice will start.

3. Now reboot and start with the actual kernel i.e. 4.11-**

4. Do NOT delete ~/.config/libreoffice!!!

5. Voila, libreoffice is starting again with the latest kernel.

6. Hint: backup ~/.config/libreoffice

Happy hacking!

Best

Hans

Bug#865866: libreoffice-writer crash on startup Debian 9 i386 arch

[Hans]

Hi,

just FYI: latest version of libreoffice in debian/testing is also still 
crashing.

Thought, you should be informed.

Best

Hans

Bug#865866: libreoffice-writer crash on startup Debian 9 i386 arch

[Hans]

Hi folks, 

I think, and everyone might agree to it, that downgrading to an old kernel with 
its security 
holes and other already fixed stuff is IMO a very bad and dumb idea! 
Downgrading a 
kernel for a single app is always the most wrong policy.

You should note, that the last running libreoffice version was one version 
below the actual 
version in debian/stable. And note, too, that it ran on linux-image-4.11-XXX, 
the latest 
kernel version in debian/testing on an i386 system. 
Mine is an EEEPC 1005HGO.

So. the better solution is, for the time, libreoffice is not fixed, use an 
alternative. I suggest 
Abiword, as it is most compatible to libreoffice and can read and write most 
documents 
formats very well (better than calibre, sorry guys).

I suppose, the developer team is working hard at the moment on libreoffice, to 
get it 
fixed. We should give them the time, and hope the best.

For me, using Abiword with the latest kernel is the better solution! 

Best 

Hans

Bug#865866: libreoffice-writer crash on startup Debian 9 i386 arch

[Hans]

Hi Rene,

dated libreoffice up this morning, but no success. I deletd 
~/.config/libreoffice  
and got this error message:

*user@protheus7*:*~*$ libreoffice  
*user@protheus7*:*~*$ 

Hope, this helps.

Best

Hans

Bug#865866: libreoffice-writer crash on startup Debian 9 i386 arch

[Hans]

Hi Rene,

maybe you should know, that libreoffice-writer ran fine since my last update, 
which was 
on 20th july 2017. 

I am running debian/testing, i386. And I do almost any day an upgrade.

No kernel update! So, maybe it helps, when you see, which packages were 
updated. This is 
the list:
Install: firebird3.0-server-core:i386 (3.0.2.32703.ds4-4, automatic), 
libgltf-0.1-1:i386 
(0.1.0-2, automatic), libzmf-0.0-0:i386 (0.0.1-4, auto

After this update, libreoffice won't start any more. As someone pointed me to 
java, I 
downgraded openjdk with no success. 

Maybe this might help to look, what might have changed.

Best regards

Hans

Bug#868511: linux-image-4.11.0-1-amd64: Please enable CEC drivers

[Hans Verkuil]

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

Dear Maintainer,

Starting with kernel 4.10 the HDMI CEC framework was mainlined in the linux
kernel. It would be very nice if this and the driver for the popular PulseEight
USB CEC adapter (https://www.pulse-eight.com/p/104/usb-hdmi-cec-adapter)
can be enabled in the 4.11 kernel config:

select CONFIG_MEDIA_CEC_SUPPORT=y and CONFIG_USB_PULSE8_CEC=m.
CONFIG_VIDEO_VIVID_CEC=y is also very useful and highly recommended as this
enables CEC emulation in this virtual video driver. This allows application
developers to test their CEC implementation without having CEC hardware.

In kernel 4.12 the RainShadow driver (similar to the popular PulseEight
USB CEC adapter) should also be enabled: CONFIG_USB_RAINSHADOW_CEC=m

Regards,

Hans Verkuil
CEC Framework & pulse8-cec driver maintainer

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

Kernel: Linux 4.11.0-1-amd64 (SMP w/56 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE=C (charmap=ANSI_X3.4-1968) (ignored: 
LC_ALL set to C)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-4.11.0-1-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.130
ii  kmod24-1
ii  linux-base  4.5

Versions of packages linux-image-4.11.0-1-amd64 recommends:
ii  firmware-linux-free  3.4
ii  irqbalance   1.1.0-2.3

Versions of packages linux-image-4.11.0-1-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.02-2
pn  linux-doc-4.11  

Versions of packages linux-image-4.11.0-1-amd64 is related to:
ii  firmware-amd-graphics 20161130-3
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
ii  firmware-ivtv 20161130-3
ii  firmware-iwlwifi  20161130-3
pn  firmware-libertas 
ii  firmware-linux-nonfree20161130-3
ii  firmware-misc-nonfree 20161130-3
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
ii  firmware-realtek  20161130-3
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- debconf-show failed

Bug#843715: 3.16: xen-blkfront: fix accounting of reqs when migrating

[Hans van Kranenburg]

On 11/09/2016 12:34 AM, Hans van Kranenburg wrote:
> 
> Problem description: After using live migration with Xen, there's a
> chance a block device in a virtual machine ends up displaying 100% usage
> all the time. This also causes 1.00 to be added to the system load average.

This is actually not true. It does not (not always?) cause an extra 1.00
to the load average, and the hit rate of this bug might actually be
higher than I thought.

-- 
Hans van Kranenburg

Bug#843715: 3.16: xen-blkfront: fix accounting of reqs when migrating

[Hans van Kranenburg]

Package: linux-image-3.16.0-4-amd64
Version: 3.16.36-1+deb8u2
Severity: wishlist

Hi,

Would you please consider picking the following bugfix into the next
3.16.y kernel update (for Jessie)?

commit 3bb8c98e5612f069010ad04e5f463389e2eb6563
Author: Roger Pau Monne <roger@citrix.com>
Date:   Mon Feb 2 11:28:21 2015 +

xen-blkfront: fix accounting of reqs when migrating

Problem description: After using live migration with Xen, there's a
chance a block device in a virtual machine ends up displaying 100% usage
all the time. This also causes 1.00 to be added to the system load average.

Also see https://patchwork.kernel.org/patch/5692991/

Attached are a few examples I just collected from virtual machines in
our network that were recently live migrated and now display this
behaviour. The characteristics I see match the incorrect count on
avgqu-sz, as discussed in the patchwork link.

We do regular mass live-migrations of a couple of thousands of Xen
domUs, e.g. because of hypervisor patch/reboot cycles. After doing so,
we end up with a bunch them hitting the bug and confused customers
getting alerts about system load which are not caused by any actual problem.

I have been trying to reproduce the issue in a controlled test
environment, but haven't been able to yet, possibly because I don't know
enough about how to increase the chances to trigger it. The hit rate in
production is less than one percent, on systems with a very diverse
workload. Given the information in the fix commit and patchwork link,
I'm however quite confident that this is the exact same issue/fix.

Thanks,
-- 
Hans van Kranenburg
=
-# iostat -y -x 2
Linux 3.16.0-4-amd64 (appnode-patoka)   11/08/2016  _x86_64_(4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
   9.210.001.020.000.13   89.64

Device: rrqm/s   wrqm/s r/s w/srkB/swkB/s avgrq-sz 
avgqu-sz   await r_await w_await  svctm  %util
xvda  0.00 0.000.000.00 0.00 0.00 0.00 
3.000.000.000.00   0.00 100.00
xvdb  0.00 0.000.000.00 0.00 0.00 0.00 
0.000.000.000.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
   5.920.000.760.000.13   93.20

Device: rrqm/s   wrqm/s r/s w/srkB/swkB/s avgrq-sz 
avgqu-sz   await r_await w_await  svctm  %util
xvda  0.00 2.000.001.00 0.0012.0024.00 
3.000.000.000.00 1000.00 100.00
xvdb  0.00 0.000.000.50 0.0018.0072.00 
0.000.000.000.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
   9.300.001.780.000.25   88.66

Device: rrqm/s   wrqm/s r/s w/srkB/swkB/s avgrq-sz 
avgqu-sz   await r_await w_await  svctm  %util
xvda  0.00 0.000.000.00 0.00 0.00 0.00 
3.000.000.000.00   0.00 100.00
xvdb  0.00 1.500.001.00 0.0010.0020.00 
0.000.000.000.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
  11.570.000.880.000.25   87.30

Device: rrqm/s   wrqm/s r/s w/srkB/swkB/s avgrq-sz 
avgqu-sz   await r_await w_await  svctm  %util
xvda  0.00 6.500.503.00 4.0040.0025.14 
3.011.718.000.67 285.71 100.00
xvdb  0.00 0.000.000.00 0.00 0.00 0.00 
0.000.000.000.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
  17.340.002.200.000.26   80.21

Device: rrqm/s   wrqm/s r/s w/srkB/swkB/s avgrq-sz 
avgqu-sz   await r_await w_await  svctm  %util
xvda  0.00 0.000.000.00 0.00 0.00 0.00 
3.000.000.000.00   0.00 100.00
xvdb  0.00 0.000.000.00 0.00 0.00 0.00 
0.000.000.000.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
  14.920.001.640.000.38   83.06

Device: rrqm/s   wrqm/s r/s w/srkB/swkB/s avgrq-sz 
avgqu-sz   await r_await w_await  svctm  %util
xvda  0.00 0.000.000.00 0.00 0.00 0.00 
3.000.000.000.00   0.00 100.00
xvdb  0.00 0.500.001.00 0.00 6.0012.00 
0.000.000.000.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
  14.920.002.460.000.26   82.36

Device: rrqm/s   wrqm/s r/s w/srkB/swkB/s avgrq-sz 
avgqu-sz   await r_await w_await  svctm  %uti

Bug#829309: linux-image-3.16.0-4-amd64: Crashes and lockups in kernel 4.x

[Hans-Joachim Baader]

Package: src:linux
Version: 3.16.7-ckt25-2+deb8u2
Severity: normal

Dear Maintainer,

with bpo kernels 4.2 to 4.6, I recently had several crashes. In two
cases I got a kernel bug (log included below). In two other cases
the system locked up completely. It might be related to my old Radeon
card (HD 2400 pro). With kernel 4.6 I had both cases: a lockup
without kernel log and a crash with log. I'm now back to kernel 3.16
which is absolutely stable.


-- Package-specific info:
** Kernel log:
Jul  1 12:14:19 kilauea kernel: [47825.861691] BUG: unable to handle kernel 
paging request at c045f900
Jul  1 12:14:19 kilauea kernel: [47825.861791] IP: [] 
ttm_bo_man_put_node+0x23/0x50 [ttm]
Jul  1 12:14:19 kilauea kernel: [47825.861885] PGD 1a09067 PUD 1a0b067 PMD 
2256d1067 PTE 8000ca6db161
Jul  1 12:14:19 kilauea kernel: [47825.861969] Oops: 0003 [#1] SMP 
Jul  1 12:14:19 kilauea kernel: [47825.862012] Modules linked in: xfs(E) 
libcrc32c(E) rpcsec_gss_krb5(E) auth_rpcgss(E) nfsv4(E) dns_resolver(E) nfs(E) 
lockd(E) grace(E) sunrpc(E) fscache(E) bridge(E) stp(E) llc(E) binfmt_misc(E) 
btrfs(E) xor(E) raid6_pq(E) it87(E) hwmon_vid(E) snd_hda_codec_hdmi(E) 
firewire_sbp2(E) joydev(E) evdev(E) snd_usb_audio(E) snd_usbmidi_lib(E) 
snd_rawmidi(E) snd_seq_device(E) snd_hda_codec_realtek(E) 
snd_hda_codec_generic(E) amdkfd(E) kvm_amd(E) kvm(E) snd_hda_intel(E) 
irqbypass(E) snd_hda_codec(E) snd_hda_core(E) serio_raw(E) pcspkr(E) radeon(E) 
amd64_edac_mod(E) edac_mce_amd(E) snd_hwdep(E) k10temp(E) snd_pcm_oss(E) 
snd_mixer_oss(E) edac_core(E) snd_pcm(E) snd_timer(E) snd(E) sp5100_tco(E) 
ttm(E) i2c_piix4(E) soundcore(E) r8169(E) sg(E) mii(E) drm_kms_helper(E) wmi(E) 
drm(E) i2c_algo_bit(E) fjes(E) shpchp(E) 8250_fintek(E) acpi_cpufreq(E) 
tpm_tis(E) fuse(E) tpm(E) button(E) processor(E) md_mod(E) parport_pc(E) 
ppdev(E) lp(E) parport(E) loop(E) dm_crypt(E)
  ext4(E) ecb(E) lrw(E) gf128mul(E) glue_helper(E) ablk_helper(E) cryptd(E) 
aes_x86_64(E) crc16(E) jbd2(E) crc32c_generic(E) mbcache(E) hid_generic(E) 
usbhid(E) hid(E) sr_mod(E) cdrom(E) sd_mod(E) ata_generic(E) ohci_pci(E) 
ahci(E) pata_atiixp(E) libahci(E) firewire_ohci(E) firewire_core(E) 
crc_itu_t(E) ohci_hcd(E) ehci_pci(E) ehci_hcd(E) libata(E) usbcore(E) 
scsi_mod(E) usb_common(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E) 
autofs4(E)
Jul  1 12:14:19 kilauea kernel: [47825.863638] CPU: 2 PID: 1723 Comm: Xorg 
Tainted: GE   4.6.0-0.bpo.1-amd64 #1 Debian 4.6.1-1~bpo8+1
Jul  1 12:14:19 kilauea kernel: [47825.863749] Hardware name: Gigabyte 
Technology Co., Ltd. GA-MA770-UD3/GA-MA770-UD3, BIOS FKb 07/08/2010
Jul  1 12:14:19 kilauea kernel: [47825.863854] task: 88021c886cc0 ti: 
8802229f4000 task.ti: 8802229f4000
Jul  1 12:14:19 kilauea kernel: [47825.863937] RIP: 0010:[]  
[] ttm_bo_man_put_node+0x23/0x50 [ttm]
Jul  1 12:14:19 kilauea kernel: [47825.864051] RSP: 0018:8802229f7c80  
EFLAGS: 00010202
Jul  1 12:14:19 kilauea kernel: [47825.864111] RAX: c045f900 RBX: 
8800ca409c68 RCX: 0080
Jul  1 12:14:19 kilauea kernel: [47825.864190] RDX: 880222184740 RSI: 
8800ca409ca4 RDI: 8802221847ec
Jul  1 12:14:19 kilauea kernel: [47825.864269] RBP: 880222c66840 R08: 
ea000892e620 R09: 8801c2f5c840
Jul  1 12:14:19 kilauea kernel: [47825.864348] R10: fff2 R11: 
8802229f7dc0 R12: 8800cfbb6000
Jul  1 12:14:19 kilauea kernel: [47825.864427] R13: 88022558e980 R14: 
880222184740 R15: 8800ca409c68
Jul  1 12:14:19 kilauea kernel: [47825.864507] FS:  7f0091f3a980() 
GS:88022fc8() knlGS:
Jul  1 12:14:19 kilauea kernel: [47825.864597] CS:  0010 DS:  ES:  CR0: 
80050033
Jul  1 12:14:19 kilauea kernel: [47825.864661] CR2: c045f900 CR3: 
cb043000 CR4: 06e0
Jul  1 12:14:19 kilauea kernel: [47825.864740] Stack:
Jul  1 12:14:19 kilauea kernel: [47825.864764]  8800ca409c68 
0002 c0455660 8800ca409c98
Jul  1 12:14:19 kilauea kernel: [47825.864856]  c04563d8 
8802229f7d00 8800cfbb6060 8800cfbb6000
Jul  1 12:14:19 kilauea kernel: [47825.864946]  8802236f1d40 
8802236f1c38 0009 c0551135
Jul  1 12:14:19 kilauea kernel: [47825.865036] Call Trace:
Jul  1 12:14:19 kilauea kernel: [47825.865074]  [] ? 
ttm_bo_cleanup_memtype_use+0x70/0x80 [ttm]
Jul  1 12:14:19 kilauea kernel: [47825.865161]  [] ? 
ttm_bo_release+0x1c8/0x220 [ttm]
Jul  1 12:14:19 kilauea kernel: [47825.865289]  [] ? 
radeon_bo_unref+0x35/0x60 [radeon]
Jul  1 12:14:19 kilauea kernel: [47825.865395]  [] ? 
radeon_gem_object_free+0x53/0x70 [radeon]
Jul  1 12:14:19 kilauea kernel: [47825.865511]  [] ? 
drm_gem_object_handle_unreference_unlocked+0x8a/0x100 [drm]
Jul  1 12:14:19 kilauea kernel: [47825.865626]  [] ? 
drm_gem_object_release_handle+0x51/0x90 [drm]
Jul  1 12:14:19 kilauea kernel: [47825.865727]  [] ? 
drm_gem_handle_delete+0x6b/0xa0 [drm]
Jul  1 

Bug#810120: linux-image-3.16.0-4-amd64: i915 drm, dualscreen, FIFO underrun, kernel call trace

[Hans Meiser]

I recently installed a backported linux image:
> linux-image-4.3.0-0.bpo.1-686-pae

with this the crashes do no occure

Only things which occure are those FIFO underruns:
> [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B 
> FIFO underrun
they don't seem fatal.

Regards.

Bug#810120: linux-image-3.16.0-4-amd64: i915 drm, dualscreen, FIFO underrun, kernel call trace

[Hans Meiser]

Some more details:

* the distorted X11 screen on output LVDS1 seems only to happen with
simple window-managers like fvwm2 and jwm, but not with a
desktop-environment xfce.

This is bad because I have not found a replacement for fvwm2, which is
as configurable like fvwm2. I use fvwm2 constantly.

* Also this Problem occures, when using VGA1 instead of DP1. :(

Regards.


2016-01-06 16:40 GMT+01:00, x201-user :
> Package: src:linux
> Version: 3.16.7-ckt20-1+deb8u2
> Severity: important
>
> Dear Maintainer,
>
> ** What led up to the situation?
> Installing a plain debian jessie on a Laptop Lenovo X201,
> connecting a external screen and
> boot the system.
>
>
> ** How to reproduce on running system:
> 1.) enable second screen
> xrandr --output LVDS1 --auto --primary --output DP1 --auto --above LVDS1
> 2.) Switch screens via dpms to off
> xset dpms force off
> 3.) move mouse to awake screens and look into dmesg to see kernel call
> trace
>  ...

Bug#800792: [Update] Re: Bug#800792: linux-image-4.2.0-1-amd64 hangs during boot at network

[Hans]

Hi Geert,

after some updates this bug did not appear on my 64-bit notebook again, but it 
still appears on my EEEPC, which has the same package versions as my 64-bit 
notebook, except that all packages are 32-bit.

I added a new file of dmesg output fropm my EEEPC. I hope it helps.

Please feel free to ask for any more information.

And: Thanks for your help!

Best 

Hans

P.S. Sorry, sent this mail twice, as I forgot to add the file. 


[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.2.0-1-686-pae (debian-kernel@lists.debian.org) 
(gcc version 4.9.3 (Debian 4.9.3-4) ) #1 SMP Debian 4.2.1-2 (2015-09-27)
[0.00] Disabled fast string operations
[0.00] x86/fpu: Legacy x87 FPU detected.
[0.00] x86/fpu: Using 'lazy' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e2000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x7f79] usable
[0.00] BIOS-e820: [mem 0x7f7a-0x7f7adfff] ACPI data
[0.00] BIOS-e820: [mem 0x7f7ae000-0x7f7e] ACPI NVS
[0.00] BIOS-e820: [mem 0x7f7f-0x7f7f] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xfff8-0x] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.5 present.
[0.00] DMI: ASUSTeK Computer INC. \x931005HAG\x94/1005HAG, BIOS 0401
03/02/2010
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x7f7a0 max_arch_pfn = 0x100
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-D uncachable
[0.00]   E-E write-through
[0.00]   F-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask 08000 write-back
[0.00]   1 base 07F80 mask 0FF80 uncachable
[0.00]   2 disabled
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
[0.00] found SMP MP-table at [mem 0x000ff780-0x000ff78f] mapped at 
[c00ff780]
[0.00] initial memory mapped: [mem 0x-0x01df]
[0.00] Base memory trampoline at [c009b000] 9b000 size 16384
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] init_memory_mapping: [mem 0x3760-0x377f]
[0.00]  [mem 0x3760-0x377f] page 2M
[0.00] init_memory_mapping: [mem 0x2000-0x375f]
[0.00]  [mem 0x2000-0x375f] page 2M
[0.00] init_memory_mapping: [mem 0x0010-0x1fff]
[0.00]  [mem 0x0010-0x001f] page 4k
[0.00]  [mem 0x0020-0x1fff] page 2M
[0.00] init_memory_mapping: [mem 0x3780-0x379fdfff]
[0.00]  [mem 0x3780-0x379fdfff] page 4k
[0.00] BRK [0x01848000, 0x01848fff] PGTABLE
[0.00] BRK [0x01849000, 0x0184afff] PGTABLE
[0.00] BRK [0x0184b000, 0x0184bfff] PGTABLE
[0.00] BRK [0x0184c000, 0x0184cfff] PGTABLE
[0.00] RAMDISK: [mem 0x33fc2000-0x35fd8fff]
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000FB9E0 14 (v00 ACPIAM)
[0.00] ACPI: RSDT 0x7F7A 40 (v01 _ASUS_ Notebook 
03001002 MSFT 0097)
[0.00] ACPI: FACP 0x7F7A0200 84 (v02 A_M_I_ OEMFACP  
03001002 MSFT 0097)
[0.00] ACPI: DSDT 0x7F7A0430 008072 (v01 A1397  A1397000 
 INTL 20051117)
[0.00] ACPI: FACS 0x7F7AE000 40
[0.00] ACPI: APIC 0x7F7A0390 5C (v01 A_M_I_ OEMAPIC  
03001002 MSFT 0097)
[0.00] ACPI: MCFG 0x7F7A03F0 3C (v01 A_M_I_ OEMMCFG  
03001002 MSFT 0097)
[0.00] ACPI: OEMB 0x7F7AE040 61 (v01 A_M_I_ AMI_OEM  
03001002 MSFT 0097)
[0.00] ACPI: HPET 0x7F7A84B0 38 (v01 A_M_I_ OEMHPET  
03001002 MSFT 0097)
[0.00] ACPI: SSDT 0x7F7AEB40 0004F0 (v01 PmRef  CpuPm
3000 INTL 20051117)
[0.00] ACPI: SLIC 0x7F7A84F0 000176 (v01 _ASUS_ Notebook 
03001002 MSFT 0097)
[0.00] ACPI: Local APIC address 0xfee0
[0.00] 1149MB HIGHMEM available.
[0.00] 88

Bug#800792: linux-image-4.2.0-1-amd64 hangs during boot at network

[Hans]

Hi Geert,

after some updates this bug did not appear on my 64-bit notebook again, but it 
still appears on my EEEPC, which has the same package versions as my 64-bit 
notebook, except that all packages are 32-bit.

I added a new file of dmesg output fropm my EEEPC. I hope it helps.

Please feel free to ask for any more information.

And: Thanks for your help!

Best 

Hans

Bug#800792: linux-image-4.2.0-1-amd64 hangs during boot at network

[Hans]

Hi Geert,

maybe you should also know, that I am NOT using network manager.
Additionally I am using fixed ip-addresses, so that I am online without the 
need of wicd or network-manager.

Although I have configured eth0, it is not connected to the cable, as I am 
using wireless connection.

I send you my /etc/network/interfaces, so you can see it.

Hope this helps.

Best regards

Hansauto lo wlan0 eth0 
iface lo inet loopback
address 127.0.0.1
netmask 255.0.0.0


 at home ##

iface eth0 inet static
address 192.168.178.17
netmask 255.255.255.0
broadcast 192.168.178.255
gateway 192.168.178.1

iface wlan0 inet static 
address 192.168.1.107
netmask 255.255.255.0
broadcast 192.168.1.255
gateway 192.168.1.1
wpa-scan-ap 1
wpa-key-mgt WPA-PSK
wpa-ssid my_personal_ssid
wpa-psk topsecret_password
dns-nameservers 208.67.222.222 208.67.220.220

# iface wlan0 inet static 
#   address 192.168.1.107
#   netmask 255.255.255.0
#   broadcast 192.168.1.255
#   gateway 192.168.1.2
#   wireless_mode managed
#   wireless_essid stargazer 
#   wireless_key 3A1B3C3EF9
#   wireless_keymode open
#   dns-nameservers 208.67.222.222 208.67.220.220

 Accesspoint #

# iface eth1 inet static
#   wireless_mode Master
#   wireless_essid any
#   wireless_keymode open
#   wireless_channel 3
#   address 192.168.5.1
#   netmask 255.255.255.0
#   broadcast 192.168.5.255
#   gateway 192.168.5.1


 Experimental 

# iface wlan1 inet static
#   address 10.5.5.1
#   netmask 255.255.255.0
#   network 10.5.0.0
#   broadcast 10.5.5.255
#   gateway 192.168.1.1

# iface wlan1 inet dhcp
#   wireless_mode ad-hoc
#   wireless_keymode open
#   wireless_key off
#   wireless_ap 10.2.46.1 


 on the road ##

# iface wlan0 inet dhcp
#   wireless_mode managed
#   wireless_essid tmobile
#   wireless_key off
#   wireless_ap auto
#   wireless_keymode open

# iface wlan0 inet static
#   address 192.168.1.30
#   netmask 255.255.255.0
#   broadcast 192.168.1.255
#   gateway 192.168.1.2
#   wireless_mode managed
#   wireless_essid any
#   wireless_key off
#   wireless_ap auto
#   wireless_keymode open


 mit WPA  ##

# iface wlan0 inet dhcp
# pre-up /sbin/wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf



# Work network configuration

# iface eth0 inet static
#   address 192.168.1.110
#   netmask 255.255.255.0
#   broadcast 192.168.1.255
#   gateway 192.168.1.1

# mapping hotplug
# script grep
# map usb0
#   iface usb0 inet static
#   address 192.168.129.201
#   network 192.168.129.0
#   netmask 255.255.255.0
#   broadcast 192.168.129.255
#   pointopoint 192.168.129.201

Bug#800792: linux-image-4.2.0-1-amd64 hangs during boot at network

[Hans]

Hi Geert,

thank you for your patience. Sorry, i had to fix some other unrelated things.
> sent the output of
> 
>cat /proc/cmdline
> 

Here it is:

 snip --
BOOT_IMAGE=/vmlinuz-4.2.0-1-amd64 root=UUID=changed_by_me_to_be_secret  ro 
quiet

 snap ---


> to this bugreport
> 
> 
I also attached the output of dmesg in the file kernelringbuffer.txt as advised 
to this mail.

> Groeten
> Geert Stappers
> -- 
> Leven en laten leven
> 
> 

Greeteings

Hans

[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.2.0-1-amd64 (debian-kernel@lists.debian.org) 
(gcc version 4.9.3 (Debian 4.9.3-4) ) #1 SMP Debian 4.2.1-2 (2015-09-27)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.2.0-1-amd64 
root=UUID=ad01422d-da21-4b7f-ad9e-ce6c459ca494 ro quiet
[0.00] tseg: 00bff8
[0.00] x86/fpu: Legacy x87 FPU detected.
[0.00] x86/fpu: Using 'lazy' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009dfff] usable
[0.00] BIOS-e820: [mem 0x0009e000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000ce000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xbff4] usable
[0.00] BIOS-e820: [mem 0xbff5-0xbff64fff] ACPI data
[0.00] BIOS-e820: [mem 0xbff65000-0xbff65fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbff66000-0xbfff] reserved
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xfff8-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00013fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Acer Aspire 7520G/Fuquene, BIOS V1.32 
03/06/2008
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] AGP: No AGP bridge found
[0.00] e820: last_pfn = 0x14 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-CEFFF write-protect
[0.00]   CF000-E3FFF uncachable
[0.00]   E4000-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 00 mask FF8000 write-back
[0.00]   1 base 008000 mask FFC000 write-back
[0.00]   2 disabled
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] TOM2: 00014000 aka 5120M
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
[0.00] e820: update [mem 0xc000-0x] usable ==> reserved
[0.00] e820: last_pfn = 0xbff50 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [mem 0x000f7c90-0x000f7c9f] mapped at 
[880f7c90]
[0.00] Base memory trampoline at [88098000] 98000 size 24576
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] BRK [0x01d2c000, 0x01d2cfff] PGTABLE
[0.00] BRK [0x01d2d000, 0x01d2dfff] PGTABLE
[0.00] BRK [0x01d2e000, 0x01d2efff] PGTABLE
[0.00] init_memory_mapping: [mem 0x13fe0-0x13fff]
[0.00]  [mem 0x13fe0-0x13fff] page 2M
[0.00] BRK [0x01d2f000, 0x01d2] PGTABLE
[0.00] init_memory_mapping: [mem 0x12000-0x13fdf]
[0.00]  [mem 0x12000-0x13fdf] page 2M
[0.00] init_memory_mapping: [mem 0x0010-0xbff4]
[0.00]  [mem 0x0010-0x001f] page 4k
[0.00]  [mem 0x0020-0xbfdf] page 2M
[0.00]  [mem 0xbfe0-0xbff4] page 4k
[0.00] init_memory_mapping: [mem 0x1-0x11fff]
[0.00]  [mem 0x1-0x11fff] page 2M
[0.00] RAMDISK: [mem 0x3426a000-0x3612cfff]
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000F7CA0 24 (v02 ACRSYS)
[0.00] ACPI: XSDT 0xBFF5E30F 5C (v01 ACRSYS ACRPRDCT 
0604  LTP )
[0.00] ACPI: SLIC 0xBFF64A8C 000176 (v01 ACRSYS ACRPRDCT 
0604 LOHR )
[0.00] ACPI: FACP 0xBFF64C02 F4 (v03 NVIDIA MCP67-M  
0604 PTL_ 000F4240)
[0.00] ACPI: DSD

Bug#800792: linux-image-4.2.0-1-amd64 hangs during boot at network

[Hans]

Package: linux-image-4.2.0-1-amd64
Version: 4.2.1-2
Severity: important

Dear maintainer-team,

there is a very annoying problem, I discovered with all kernels since version 
4.X.

When the system boots up and the network shall be activated, the system hangs 
for
a long time (about 2 minutes). Then the systemd-counter shows up and after the 
waiting time (about the mentioned 2 minutes), the system continous booting.

On my slower EEEPC netbook, this waiting time is longer.

I rechecked everything, and I can proove, that the latest 3.X kernel from 
debian does not show this behaviour. This behaviour appears since all kernels 
with version 4.0 and higher.

Really, this is a really annoying bug, especially, when you have often to boot 
the system (in my case, because I walk from customer to customer with my 
netbook).

I suppose, something has changed in the network device module between 3.16 and 
4.X.

It would be nice, if you could take a look at it. maybe this is easy to be 
fixed.

Thank you very much for reading this and all your help.

Best regards

Hans-J. Ullrich

Bug#800792: linux-image-4.2.0-1-amd64 hangs during boot at network

[Hans]

Am Samstag, 3. Oktober 2015, 19:02:53 schrieb Geert Stappers:

Hi Geert, 

I will see, if I can help.
> 
> Please provide more information, example given:
> 
>  * Log messages
Sorry, I believe, there are no usable logfiles available as it happens at 
boot.

>  * Hardware being used
The problem appears on all my systems. I have a notebook with nvidia 
network card (MCP51), a desktop with a rtl-8169 and a EEEPC 1005HA 
netbook on which I write this mail:

01:00.0 Ethernet controller: Qualcomm Atheros AR8132 Fast Ethernet 
(rev c0) 





>  * Which kernel modules being used
I am using standard kernel modules. For wlan on the notebook it is 
ath5k.ko, on the netbook it uses ath9k.ko.

>  * What you mean by boot. Is a cold boot or a resume after suspend?
The term "at boot" means a cold boot, when the device was powered off 
and starts first. Besides I want to mention, that resuming from suspend, 
the wlan device does not work again. I forgot this to mention, but maybe 
this is another bug. This behaviour also appears since kernel 4.0 and 
higher. With 3.16 this also worked fine.

>  * kernel boot parameters
> 

See my /etc/default/grub:
# If you change this file, run 'update-grub' afterwards to update 


Best 

Hans

> 
> Groeten
> Geert Stappers

Bug#793185: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard

[Hans de Goede]

Hi,

On 01-08-15 14:50, Ian Campbell wrote:

On Sat, 2015-08-01 at 10:51 +0100, Ian Campbell wrote:

http://git.kernel.org/linus/07949bf9c63c9a80027fe8452d5fe8b9ba9b3c23

I'll see about backporting that to the 4.1 kernel in Debian until we
move to 4.2.


It turns out that this patch while necessary is not sufficient and I
also needed the following for full cpufreq autoloading on Cubietruck
with Debian's modular kernel config.


Makes sense, and the patch looks good. Can you please submit this upstream
to the regulator subsys maintainers?

I know that Mark is in the Cc, but this thread does not really look
like an official patch submission, I believe that a separate
patch submission using the standard procedure for those would be
good.

Thanks  Regards,

Hans





Cheers,
Ian.

8---
 From 38880ed1b26e8778268c1da41ab2bb52c6797947 Mon Sep 17 00:00:00 2001
From: Ian Campbell i...@hellion.org.uk
Date: Sat, 1 Aug 2015 13:44:06 +0100
Subject: [PATCH] regulator: axp20x: Add module alias

This allows the module to be autoloaded.

Together with 07949bf9c63c (cpufreq: dt: allow driver to boot
automatically) this is sufficient to allow a modular kernel (such
as Debian's) to enable cpufreq on a Cubietruck.

Signed-off-by: Ian Campbell i...@hellion.org.uk
Cc: Liam Girdwood lgirdw...@gmail.com
Cc: Mark Brown broo...@kernel.org
Cc: Signed-off-by: Chen-Yu Tsai w...@csie.org
Cc: Maxime Ripard maxime.rip...@free-electrons.com
---
  drivers/regulator/axp20x-regulator.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index e4331f5..2c82131 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -264,3 +264,4 @@ module_platform_driver(axp20x_regulator_driver);
  MODULE_LICENSE(GPL v2);
  MODULE_AUTHOR(Carlo Caione ca...@caione.org);
  MODULE_DESCRIPTION(Regulator Driver for AXP20X PMIC);
+MODULE_ALIAS(platform:axp20x-regulator);




--
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/55bcc1a5.4020...@redhat.com

Bug#793185: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard

[Hans de Goede]

Hi,

On 24-07-15 12:08, Thomas Kaiser wrote:

Leonardo Canducci wrote:


I've submitted a bug [0] in the Debian BTS and tried kernel 4.0 and 4.1
from unstable and experimental branches with no success



I can confirm that it's neither working with 4.0.4 and 4.1 on cubietruck
(always tried Wheezy):


http://forum.armbian.com/index.php/topic/108-no-cpufreq-support-in-cubietruck-debian-39-wheezy-405/#entry764

With the very same kernel/userland (kernel exactly identical) cpufreq stuff
works on the other A20 devices I tested with: A20-Lime2, Banana Pi, Banana
Pro, pcDuino3 Nano, Lamobo R1


The Cubietruck has the necessary bits in the dts to also enable voltage
scaling. Is the debian kernel building the axp209 mfd driver, and also
the axp20x regulator drive, and do these get loaded properly on the
cubietruck ?

Regards,

Hans


--
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/55b21435.5040...@redhat.com

Bug#793185: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard

[Hans de Goede]

Hi,

On 24-07-15 15:16, Maxime Ripard wrote:

On Fri, Jul 24, 2015 at 02:58:31PM +0200, Hans de Goede wrote:

There is slightly more to it then those 5 lines, but yes we should enable
voltage scaling on more boards. This mostly requires someone to simply
just do the work.

I've a workshop on dts this weekend at our localhacker space and the plan
is for the people attending to get some handson experience by them doing
this work (amongst other things)  :)


While I agree with you on the fact that more board needs to have the
regulators enabled, I really don't think that making some newbies
doing it without any schematics (and boards I guess?)


They will only be writing patches for boards which I have, and the patches
will be tested on the actual boards before submitting them upstream.

I will be collecting and double checking all patches before sending them
to you.

I will let you know if they blow up any boards :)  But I do not really
expect that to happen.

 is a good thing

when it comes to something that can permanently damage a board.

I'd expect that such changes would be carefully done and tested before
being submitted.


And they will be, see above.

Regards,

Hans


--
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/55b23c55.1060...@redhat.com

Bug#793185: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard

[Hans de Goede]

Hi,

On 24-07-15 14:49, Thomas Kaiser wrote:

Hi,

Timo wrote:


I think what Maxime was trying to say is, that while all of your boards
support Cpufreq, only the Cubietruck supports voltage scaling because only
Cubietruck has the power regulator nodes defined in it's dts file (just
have a look at the last lines of the Cubitruck dts file and compare that to
the dts file, let's say, for Bananapi). On the other boards, the frequency
is scaled, but the voltage always stays at 1.4V as set in U-Boot (that
means the voltages in the cpufreq operating points are not used on these
boards). At least that's what I understand after a recent email axchange
with Chen-Yu Tsai.



Ah, now I think I understand. You're talking about these lines here?


https://github.com/RobertCNelson/u-boot/blob/master/arch/arm/dts/sun7i-a20-cubietruck.dts#L244-L269

So while using CONFIG_REGULATOR_AXP20X=y will bring working cpufreq support
to the cubietruck, shouldn't adding these lines to the device trees of the
other 5 A20 devices enable CPU voltage scaling there?


There is slightly more to it then those 5 lines, but yes we should enable
voltage scaling on more boards. This mostly requires someone to simply
just do the work.

I've a workshop on dts this weekend at our localhacker space and the plan
is for the people attending to get some handson experience by them doing
this work (amongst other things)  :)

Regards,

Hans


--
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/55b23677.2080...@redhat.com

Bug#792769: linux-image-4.0.0-2-686-pae - hibernate not working correctly

[Hans]

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


Dear maintainers,

since the update from kernel 3.16 to 4.0.0, suspend to disk is not working 
correctly.

The bug shows as follows:
When hibernation is activated (either manually or by closing lid), all 
memory 
is written to swap, then the screen is switched off. 

But after this, the computer should be switched off, which does not. The 
computer is still switched on.

I can reproduce this bug by reverting back to kernel 3.16 (where 
everything is 
ok), then booting kernel 4.0.0. and the bug appears again.

It would be nice, if you could take a look at it.

At the moment I have to stay at kernel 3.16 due it is not usable for me at 
the 
moment as this one and another major bug (#792627).

Thank you for any help!

Best regards

Hans-J. Ullrich 

Thank you very much.

Bug#792627: linux-image-4.0.0-2-686-pae: linux-image-4.0 does not bind ethernet device

[Hans]

Hi all,

there is another hint, I dioscovered in my kernel logs.

-
Jul 16 21:51:55 localhost kernel: [ 1277.742162] atl1c :01:00.0: version 
1.0.1.1-NAPI
Jul 16 21:51:55 localhost kernel: [ 1277.775065] atl1c :01:00.0 enp1s0: 
renamed from eth0



However, there is NO enp1s0 in my

/etc/udev/rules.d/70-persistent-net.rules

and I saw no reason, why it should be renamed from eth0 to enp1s0.

Of course, in /etc/network/interfaces there is only eth0 and NO enp1s0.
I believe, the reason for this bug is this strange renaming behaviour, as if I 
do an ifconfig -a it shows me enp1s0 instead of eth0.

And as enp1s0 is not defined in /etc/network/interfaces, I get the delay. 

I could prove:

NO renaming and eth0 = working correctly
renaming eth0 to enp1s0 = no network, delay at boot and ifconfig -a shows 
NO eth0 but enp1s0.

Hope this helps

Best

Hans-J. Ullrich
  


-- 
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/4305688.G8pLMSlTW4@protheus7

Bug#754857: linux-image-3.2.0-4-amd64: Sporadic kernel crashes

[Hans Yntema]

Package: src:linux
Version: 3.2.60-1+deb7u1
Severity: important

Dear Maintainer,

Intel MB DH87RL, 8GN, i5
System/kernel crashes once in a while. See a tracecall at the end.
System runs 24/7. Crash occurs typically once every 1-4 weeks.
System is not stressed for long preiods of time
CPU temp is monitored, not excessive temperatures
I don't have a clue how to trigger the kernel crash.
In the past, I have used ZFSonLinux on this system, and crashes happened more 
frequent.
ZFSOnLinux is removed (not tainted anymore). As ZFSOnLinux is (?) more memory 
intensive,
I have run memtester and mamtest86+ for a few hours without success
Last thing I have done is to relax memory timings (From default to everything 
(CAS/RAS etc) a bit more relaxed)
It did not make a difference.
I have no clue what next step I can take.
I originally did built up this system in a VM, before I moved it to real 
hardware. Any complications because of this?

The trace below refer to xhci. I have disabled xhci in the past (unload 
modules). Kernel crash still happened.

See trace at end

-- Package-specific info:
** Version:
Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 
(Debian 4.6.3-14) ) #1 SMP Debian 3.2.60-1+deb7u1

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 
root=UUID=a1fd5329-a2e2-4913-a409-1fe39bde8576 ro quiet

** Not tainted

** Kernel log:
[5.908372] hub 2-0:1.0: USB hub found
[5.908395] hub 2-0:1.0: 6 ports detected
[5.930849] ACPI: resource :00:1f.3 [io  0xf040-0xf05f] conflicts with 
ACPI region SMBI [io 0xf040-0xf04f]
[5.930851] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[5.930912] snd_hda_intel :00:03.0: irq 46 for MSI/MSI-X
[5.930929] snd_hda_intel :00:03.0: setting latency timer to 64
[6.218178] usb 1-10: new high-speed USB device number 2 using xhci_hcd
[6.236545] usb 1-10: New USB device found, idVendor=090c, idProduct=1000
[6.236553] usb 1-10: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[6.236558] usb 1-10: Product: USB Flash Disk
[6.236562] usb 1-10: Manufacturer: General
[6.236566] usb 1-10: SerialNumber: 301008229825
[6.236777] usb 1-10: ep 0x81 - rounding interval to 128 microframes, ep 
desc says 255 microframes
[6.236784] usb 1-10: ep 0x2 - rounding interval to 128 microframes, ep desc 
says 255 microframes
[6.401748] usb 1-11: new high-speed USB device number 3 using xhci_hcd
[6.420368] usb 1-11: New USB device found, idVendor=2659, idProduct=1210
[6.420373] usb 1-11: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[6.420378] usb 1-11: Product: MediaTV Pro III (EU)
[6.420382] usb 1-11: Manufacturer: Sundtek
[6.420385] usb 1-11: SerialNumber: U140218172811
[6.539735] Initializing USB Mass Storage driver...
[6.539850] scsi13 : usb-storage 1-10:1.0
[6.539904] usbcore: registered new interface driver usb-storage
[6.539905] USB Mass Storage support registered.
[7.536327] scsi 13:0:0:0: Direct-Access General  USB Flash Disk   1100 
PQ: 0 ANSI: 0 CCS
[7.537473] sd 13:0:0:0: Attached scsi generic sg8 type 0
[7.538534] sd 13:0:0:0: [sdh] 3917824 512-byte logical blocks: (2.00 
GB/1.86 GiB)
[7.539206] sd 13:0:0:0: [sdh] Write Protect is off
[7.539215] sd 13:0:0:0: [sdh] Mode Sense: 43 00 00 00
[7.539881] sd 13:0:0:0: [sdh] No Caching mode page found
[7.539955] sd 13:0:0:0: [sdh] Assuming drive cache: write through
[7.544606] sd 13:0:0:0: [sdh] No Caching mode page found
[7.544680] sd 13:0:0:0: [sdh] Assuming drive cache: write through
[7.545402]  sdh: sdh1
[7.547321] sd 13:0:0:0: [sdh] No Caching mode page found
[7.547393] sd 13:0:0:0: [sdh] Assuming drive cache: write through
[7.547467] sd 13:0:0:0: [sdh] Attached SCSI removable disk
[8.959811] hda-intel: azx_get_response timeout, switching to polling mode: 
last cmd=0x000f
[9.961476] hda-intel: No response from codec, disabling MSI: last 
cmd=0x000f
[   10.963171] hda-intel: Codec #0 probe error; disabling it...
[   11.980798] hda_intel: azx_get_response timeout, switching to single_cmd 
mode: last cmd=0x000f0001
[   11.986980] snd_hda_intel :00:1b.0: irq 46 for MSI/MSI-X
[   11.987030] snd_hda_intel :00:1b.0: setting latency timer to 64
[   12.017929] input: Sundtek Ltd. Remote Control as 
/devices/virtual/input/input3
[   12.049086] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1b.0/input/input4
[   12.053572] input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1b.0/sound/card1/input5
[   14.160254] EXT4-fs (sda1): re-mounted. Opts: (null)
[   15.097338] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
[   15.363213] loop: module loaded
[   30.922047] usb 1-11: usbfs: process 868 (mediasrv) did not claim interface 
0 before use
[   33.630668] usb 1-8: new high-speed USB device number 4 using xhci_hcd
[   33.647367] usb 1-8: 

Bug#754875: linux-image-3.14-0.bpo.1-amd64: When install 3.14-bpo on wheezy, inittab is in the way, missing dracut

[Hans Schou]

Package: linux-image-3.14-0.bpo.1-amd64
Severity: normal

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?

On a wheezy system backports was added and then install 
linux-image-3.14-0.bpo.1-amd64


   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Setting up linux-image-3.14-0.bpo.1-amd64 (3.14.12-1~bpo70+1) ...
E: Directories consolefonts, consoletrans, keymaps not found.  Please inform us 
about the issue including your OS name and version.

   * What was the outcome of this action?

Package mis-match.

Install console-data should fix the problem.

   * What outcome did you expect instead?

*** End of the template - remove these lines ***


-- System Information:
Debian Release: 7.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
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/20140715124858.25273.75548.report...@vulcan.moc.net

Bug#730135: linux-image-3.2.0-4-amd64: Kernel Oops - unable to handle kernel paging request at 0000080000000028

[Hans Yntema]

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

Dear Maintainer,
Nov 21 21:15:58 ijntema-svr kernel: [1469250.079513] BUG: unable to handle 
kernel paging request at 0828
Nov 21 21:15:58 ijntema-svr kernel: [1469250.079569] IP: [a008fc7e] 
jbd2_journal_release_jbd_inode+0x3f/0x10a [jbd2]
Nov 21 21:15:58 ijntema-svr kernel: [1469250.079630] PGD 0
Nov 21 21:15:58 ijntema-svr kernel: [1469250.079647] Oops:  [#1] SMP
Nov 21 21:15:58 ijntema-svr kernel: [1469250.079675] CPU 0
Nov 21 21:15:58 ijntema-svr kernel: [1469250.079689] Modules linked in: 
tcp_diag inet_diag xt_recent zfs(P) zunicode(P) zavl(P) zcommon(P) znvpair(P) 
spl(O) sha256_generic cryptd aes_x86_64 aes$
Nov 21 21:15:58 ijntema-svr kernel: trfs crc32c libcrc32c zlib_deflate sg 
sd_mod crc_t10dif usb_storage ata_generic floppy uhci_hcd pata_marvell ata_piix 
ehci_hcd r8169 mii libata scsi_mod usbc$
Nov 21 21:15:58 ijntema-svr kernel: [1469250.080007]
Nov 21 21:15:58 ijntema-svr kernel: [1469250.080007] Pid: 23, comm: kswapd0 
Tainted: P   O 3.2.0-4-amd64 #1 Debian 3.2.51-1 System manufacturer 
System Product Name/P5Q-VM
Nov 21 21:15:58 ijntema-svr kernel: [1469250.080007] RIP: 
0010:[a008fc7e]  [a008fc7e] 
jbd2_journal_release_jbd_inode+0x3f/0x10a [jbd2]
Nov 21 21:15:58 ijntema-svr kernel: [1469250.080007] RSP: 0018:880224345b70 
 EFLAGS: 00010246
Nov 21 21:15:58 ijntema-svr kernel: [1469250.080007] RAX: 9a559a55 RBX: 
0800 RCX: 0025
Nov 21 21:15:58 ijntema-svr kernel: [1469250.080007] RDX: 9a55 RSI: 
0800 RDI: 8801e1ab6b9c
Nov 21 21:15:58 ijntema-svr kernel: [1469250.080007] RBP: 8801e1ab6800 R08: 
0025 R09: 880101b25468
Nov 21 21:15:58 ijntema-svr kernel: [1469250.080007] R10: ea0004a4a698 R11: 
ea0004a4a698 R12: 880224345b88
Nov 21 21:15:58 ijntema-svr kernel: [1469250.080007] R13: 8801e1ab6b9c R14: 
880224345bb0 R15: 880226dc8870
Nov 21 21:15:58 ijntema-svr kernel: [1469250.080007] FS:  
() GS:88022fc0() knlGS:
Nov 21 21:15:58 ijntema-svr kernel: [1469250.080007] CS:  0010 DS:  ES: 
 CR0: 8005003b
Nov 21 21:15:58 ijntema-svr kernel: [1469250.080007] CR2: 0828 CR3: 
01605000 CR4: 000406f0
Nov 21 21:15:58 ijntema-svr kernel: [1469250.080007] DR0:  DR1: 
 DR2: 
Nov 21 21:15:58 ijntema-svr kernel: [1469250.080007] DR3:  DR6: 
0ff0 DR7: 0400
Nov 21 21:15:58 ijntema-svr kernel: [1469250.080007] Process kswapd0 (pid: 23, 
threadinfo 880224344000, task 880226dc8870)
Nov 21 21:15:58 ijntema-svr kernel: [1469250.080007] Stack:
Nov 21 21:15:58 ijntema-svr kernel: [1469250.080007]  880224345b68 
a0268d1f 880224345dc0 811aa9c1
Nov 21 21:15:58 ijntema-svr kernel: [1469250.080007]  0282 
810958cb ea0007108470 880224345ba8


-- Package-specific info:
** Version:
Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 
(Debian 4.6.3-14) ) #1 SMP Debian 3.2.51-1

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 
root=UUID=a1fd5329-a2e2-4913-a409-1fe39bde8576 ro quiet

** Tainted: PO (4097)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.

** Kernel log:
[   56.577065] ivtv0: Reopen i2c bus for IR-blaster support
[   56.601102] cx25840 10-0044: cx25843-24 found @ 0x88 (ivtv i2c driver #0)
[   57.125708] i2c-core: driver [tuner] using legacy suspend method
[   57.125711] i2c-core: driver [tuner] using legacy resume method
[   57.140033] tuner 10-0061: Tuner -1 found with type(s) Radio TV.
[   57.161966] wm8775 10-001b: chip found @ 0x36 (ivtv i2c driver #0)
[   57.454622] tuner-simple 10-0061: creating new instance
[   57.454625] tuner-simple 10-0061: type set to 55 (TCL 2002MB)
[   57.46] ivtv0: Registered device video0 for encoder MPG (4096 kB)
[   57.461209] ivtv0: Registered device video32 for encoder YUV (2048 kB)
[   57.461248] ivtv0: Registered device vbi0 for encoder VBI (1024 kB)
[   57.461286] ivtv0: Registered device video24 for encoder PCM (320 kB)
[   57.461288] ivtv0: Initialized card: Hauppauge WinTV PVR-150
[   57.461308] ivtv: End initialization
[   58.914919] ivtv :04:00.0: firmware: agent loaded v4l-cx2341x-enc.fw 
into memory
[   58.928618] ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
[   59.128149] ivtv0: Encoder revision: 0x02060039
[   59.948235] cx25840 10-0044: firmware: agent loaded v4l-cx25840.fw into 
memory
[   63.688472] cx25840 10-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
[   66.689041] EXT4-fs (sda1): re-mounted. Opts: (null)
[   67.928195] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
[   68.305858] loop: module loaded
[   86.878681] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: 
(null)
[   89.349301] r8169 

Bug#728806: linux-image-3.2.0-4-amd64: btrfs reports checksum error, while md5sum shows same checksum on original and backup

[Hans Yntema]

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

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

I have a dedicated backup internal SATA HDD; (4TB, GPT), filled 70%. Btrfs on 
DM-Crypt; Backups are created with Dirvish, e.g., many hardlinked files.
HDD Converted (yesterday) from ext4 to btrfs. Subsequently run scrub. Scrub 
reports checksum errors: (multiple, as it is a Dirvish backup)

Nov  4 20:40:50 ijntema-svr kernel: [254525.824034] btrfs: checksum error at 
logical 522774728704 on dev /dev/dm-2, sector 1021044392, root 5, inode 
199230932, 
offset 2135773184, length 4096, links 87 (path: 
dvd/20131008-0114/tree/dvd-18+/Contact/VTS_01_1.VOB)

However, when I run md5sum on the backup HDD VTS_01_1.VOB and on the original 
HDD VTS_01_1.VOB, the checksum is the same. In other words,
backup equals original; hence how can btrfs report a checksum error?

Above checksum error appears as many times as Dirvish snapshots exists. 
However, a few syslog entries are corrupt:
Nov  4 20:40:50 ijntema-svr kernel: [254525.824034] btrfs: checksum error at 
logical 522774728704 on dev /dev/dm-2, sector 1021044392, root 5, in
offset 2135773184, length 4096, links 87 (path: 
^B���\��^E^B���(��^E^Bߙ^E^Bߙ^E^Bߙ^E^B���Xߙ^E^B���$ߙ^E^Bޙ^E^Bޙ^E^Bޙ^E^B���Tޙ^E^B���TS_01_1.VOB)

Checksum errors are reported on multiple files. It seems (samples a few) that 
these have in common that some of the log entries are corrupt.

*** End of the template - remove these lines ***


-- Package-specific info:
** Version:
Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 
(Debian 4.6.3-14) ) #1 SMP Debian 3.2.51-1

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 
root=UUID=a1fd5329-a2e2-4913-a409-1fe39bde8576 ro quiet

** Tainted: PO (4097)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.

** Kernel log:
[   46.973408] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[   46.973409] [drm] Driver supports precise vblank timestamp query.
[   46.973453] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[   47.052019] No connectors reported connected with modes
[   47.052029] [drm] Cannot find any crtc or sizes - going 1024x768
[   47.055623] fbcon: inteldrmfb (fb0) is primary device
[   47.059717] Console: switching to colour frame buffer device 128x48
[   47.062336] fb0: inteldrmfb frame buffer device
[   47.062337] drm: registered panic notifier
[   47.062356] No ACPI video bus found
[   47.062398] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0
[   50.913889] ivtv :04:00.0: firmware: agent loaded v4l-cx2341x-enc.fw 
into memory
[   50.927813] ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
[   51.124161] ivtv0: Encoder revision: 0x02060039
[   51.969453] cx25840 0-0044: firmware: agent loaded v4l-cx25840.fw into memory
[   55.756463] cx25840 0-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
[   58.659414] EXT4-fs (sdb1): re-mounted. Opts: (null)
[   60.120401] EXT4-fs (sdb1): re-mounted. Opts: errors=remount-ro
[   60.311121] loop: module loaded
[   83.998708] EXT4-fs (sdb2): mounted filesystem with ordered data mode. Opts: 
(null)
[   85.718049] r8169 :01:00.0: eth0: link down
[   85.718057] r8169 :01:00.0: eth0: link down
[   85.719048] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   86.773847] RPC: Registered named UNIX socket transport module.
[   86.773852] RPC: Registered udp transport module.
[   86.773855] RPC: Registered tcp transport module.
[   86.773859] RPC: Registered tcp NFSv4.1 backchannel transport module.
[   86.893156] FS-Cache: Loaded
[   86.973669] FS-Cache: Netfs 'nfs' registered for caching
[   87.015189] Installing knfsd (copyright (C) 1996 o...@monad.swb.de).
[   88.797250] r8169 :01:00.0: eth0: link up
[   88.798660] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[  104.043486] tun: Universal TUN/TAP device driver, 1.6
[  104.043488] tun: (C) 1999-2004 Max Krasnyansky m...@qualcomm.com
[  106.330800] lp: driver loaded but no devices found
[  106.355669] ppdev: user-space parallel port driver
[  109.474905] ip_tables: (C) 2000-2006 Netfilter Core Team
[  109.527350] ip6_tables: (C) 2000-2006 Netfilter Core Team
[  109.758316] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[  115.172189] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery 
directory
[  115.183501] NFSD: starting 90-second grace period
[  185.061947] /dev/vmmon[5572]: Module vmmon: registered with major=10 
minor=165
[  185.061952] /dev/vmmon[5572]: Module vmmon: initialized
[  185.956391] [5579]: VMCI: shared components initialized.
[  185.956432] [5579]: VMCI: host components initialized.
[  185.956597] [5579]: VMCI: Module registered (name=vmci,major=10,minor=59).
[  185.956600] [5579]: VMCI: Using host personality
[  185.956602] [5579]: VMCI: Module (name=vmci) is initialized
[  186.332610] fuse 

Bug#727266: BUG: unable to handle kernel paging request at 0000080000000028

[Hans Yntema]

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

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
Headless server. Situation occured at somepoint in time

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I had to reset system to reboot. System only responded to ping. SSH/HTTP server 
did not respond

   * What was the outcome of this action?
   * What outcome did you expect instead?

Syslog is filled with traces. I copied the first one:
Oct 23 02:21:53 server kernel: [470089.718971] BUG: unable to handle kernel 
paging request at 0828
Oct 23 02:21:53 server kernel: [470089.719050] IP: [a007bc7e] 
jbd2_journal_release_jbd_inode+0x3f/0x10a [jbd2]
Oct 23 02:21:53 server kernel: [470089.719132] PGD 0
Oct 23 02:21:53 server kernel: [470089.719154] Oops:  [#1] SMP
Oct 23 02:21:53 server kernel: [470089.719189] CPU 0
Oct 23 02:21:53 server kernel: [470089.719209] Modules linked in: 
ipt_MASQUERADE iptable_nat nf_nat tun tcp_diag inet_diag sha256_generic cryptd 
aes_x86_64 aes_generic cbc dm_crypt dm_mod vmn$
Oct 23 02:21:53 server kernel: ata_generic uhci_hcd pata_marvell ata_piix 
ehci_hcd r8169 mii libata scsi_mod usbcore usb_common [last unloaded: 
scsi_wait_scan]
Oct 23 02:21:53 server kernel: [470089.720006]
Oct 23 02:21:53 server kernel: [470089.720006] Pid: 23, comm: kswapd0 Tainted: 
G   O 3.2.0-4-amd64 #1 Debian 3.2.51-1 System manufacturer System 
Product Name/P5Q-VM
Oct 23 02:21:53 server kernel: [470089.720006] RIP: 0010:[a007bc7e]  
[a007bc7e] jbd2_journal_release_jbd_inode+0x3f/0x10a [jbd2]
Oct 23 02:21:53 server kernel: [470089.720006] RSP: 0018:8802242e9b70  
EFLAGS: 00010246
Oct 23 02:21:53 server kernel: [470089.720006] RAX: b4c0b4c0 RBX: 
0800 RCX: 0025
Oct 23 02:21:53 server kernel: [470089.720006] RDX: b4c0 RSI: 
0800 RDI: 880223708b9c
Oct 23 02:21:53 server kernel: [470089.720006] RBP: 880223708800 R08: 
0025 R09: 880101b25468
Oct 23 02:21:53 server kernel: [470089.720006] R10:  R11: 
 R12: 8802242e9b88
Oct 23 02:21:53 server kernel: [470089.720006] R13: 880223708b9c R14: 
8802242e9bb0 R15: 880226dc8870
Oct 23 02:21:53 server kernel: [470089.720006] FS:  () 
GS:88022fc0() knlGS:
Oct 23 02:21:53 server kernel: [470089.720006] CS:  0010 DS:  ES:  CR0: 
8005003b
Oct 23 02:21:53 server kernel: [470089.720006] CR2: 0828 CR3: 
0001f7be3000 CR4: 000406f0
Oct 23 02:21:53 server kernel: [470089.720006] DR0:  DR1: 
 DR2: 
Oct 23 02:21:53 server kernel: [470089.720006] DR3:  DR6: 
0ff0 DR7: 0400
Oct 23 02:21:53 server kernel: [470089.720006] Process kswapd0 (pid: 23, 
threadinfo 8802242e8000, task 880226dc8870)
Oct 23 02:21:53 server kernel: [470089.720006] Stack:
Oct 23 02:21:53 server kernel: [470089.720006]  8802242e9b68 
a010ad1f 8802242e9b78 811aa9c1
Oct 23 02:21:53 server kernel: [470089.720006]  0282 
810958cb ea00013ed4e0 88014a2fd680
Oct 23 02:21:53 server kernel: [470089.720006]  88014a2fd680 
01b251b0 880101b252a8 880101b251b0
Oct 23 02:21:53 server kernel: [470089.720006] Call Trace:
Oct 23 02:21:53 server kernel: [470089.720006]  [a010ad1f] ? 
ext4_drop_inode+0xe/0x4a [ext4]
Oct 23 02:21:53 server kernel: [470089.720006]  [811aa9c1] ? 
_atomic_dec_and_lock+0x29/0x48
Oct 23 02:21:53 server kernel: [470089.720006]  [810958cb] ? 
__call_rcu+0x21/0x12c
Oct 23 02:21:53 server kernel: [470089.720006]  [a0112098] ? 
ext4_clear_inode+0x44/0x64 [ext4]
Oct 23 02:21:53 server kernel: [470089.720006]  [8110d068] ? 
evict+0x96/0x148
Oct 23 02:21:53 server kernel: [470089.720006]  [8110d2d2] ? 
dispose_list+0x27/0x31
Oct 23 02:21:53 server kernel: [470089.720006]  [8110de13] ? 
prune_icache_sb+0x250/0x25f
Oct 23 02:21:53 server kernel: [470089.720006]  [810fcb0a] ? 
prune_super+0xd5/0x13f
Oct 23 02:21:53 server kernel: [470089.720006]  [810c218d] ? 
shrink_slab+0x18f/0x24d
Oct 23 02:21:53 server kernel: [470089.720006]  [810c4b5d] ? 
balance_pgdat+0x283/0x4b7
Oct 23 02:21:53 server kernel: [470089.720006]  [810c5064] ? 
kswapd+0x2d3/0x303
Oct 23 02:21:53 server kernel: [470089.720006]  [8105fc83] ? 
add_wait_queue+0x3c/0x3c
Oct 23 02:21:53 server kernel: [470089.720006]  [810c4d91] ? 
balance_pgdat+0x4b7/0x4b7
Oct 23 02:21:53 server kernel: [470089.720006]  [8105f631] ? 
kthread+0x76/0x7e
Oct 23 02:21:53 server kernel: [470089.720006]  [81356374] ? 
kernel_thread_helper+0x4/0x10
Oct 23 02:21:53 server kernel: [470089.720006]  

Bug#718533: linux-image-3.10-1-amd64: conf/modules typo dm-raid45 makes RAID5 arrays unbootable

[Hans Bausewein]

rootdelay=1 is enough here :-)


thanks for the hint.

Hans


-- 
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/b77447d2e3238c9db221ec40858074f8.squir...@webmail.xs4all.nl

Bug#705627: linux-image-3.2.0-4-486: wheezy installer fails to boot on Lenovo S10e

[Hans-Christoph Steiner]

Package: linux-image-3.2.0-4-486
Version: 3.2.35-2
Severity: grave
Tags: d-i patch
Justification: renders package unusable


I've just installed the debian-wheezy-DI-rc1-i386-netinst.iso installer on a
Lenovo S10e netbook with a Intel Atom N270 1.60GHz by doing this onto a USB
thumb drive:

dd if=debian-wheezy-DI-rc1-i386-netinst.iso of=/dev/sdb

It does show the splash screen, but when I select Install, it just hangs
there, and never boots. Running install intel_idle.max_cstate=0 boots, and
that's how I was able to run the install. Otherwise the install process worked
perfectly.  Apparently its an old bug, I found a discussion of the issue and
the workaround that I used here:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/634702

After the install, I tried installing the same kernel that the installer uses
(linux-image-3.2.0-4-486) and rebooting to it.  That worked fine.  It seems
that is a different version than the version the installer uses:

$ file /mnt/install.386/vmlinuz 
/mnt/install.386/vmlinuz: Linux kernel x86 boot executable bzImage, version
3.2.0-4-486 (debian-kernel@lists.debian.org) #1 Debian 3.2.35-2, RO-rootFS,
swap_dev 0x2, Normal VGA

$ file /boot/vmlinuz-3.2.0-4-486
/boot/vmlinuz-3.2.0-4-486: Linux kernel x86 boot executable bzImage, version
3.2.0-4-486 (debian-kernel@lists.debian.org) #1 Debian 3.2.41-2, RO-rootFS,
swap_dev 0x2, Normal VGA


-- System Information:
Debian Release: 7.0 DI-rc1
Architecture: i386 (i686)

Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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/20130417161821.2004.57521.report...@blinky.at.or.at

Bug#705627: nightly build still affected

[Hans-Christoph Steiner]

I just downloaded and tried this:
http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/debian-testing-i386-netinst.iso

from 2013-04-17 11:11

It is also affected.


-- 
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/516ed982.4060...@eds.org

Bug#665881: [wheezy] module ath5k is blocking wlan-card

[Hans-J. Ullrich]

Hi Jonathan and Ben.

Some special news. I tested again.

I installed linux-image-3.3.0-rc6-amd64_3.3~rc6-1~experimental.1_amd64.deb 
from snapshots.debian.org, and its headers, but the bug never appeared.

I did almos 10 - 15 rebootsx with no appearence of the bug.

Then I started 3.2 kernel and the bug appeared again. Maybe this information 
might be important for you. However, I guess I already tested this in the 
past, but this time all packagesd are up-to-date (state from today, of 
course).

Hope this helps!

Greets

Hans


-- 
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/201301101902.43088.hans.ullr...@loop.de

Bug#665881: [wheezy] module ath5k is blocking wlan-card

[Hans-J. Ullrich]

Hi jonatahan,

happy new year! 
 
  Hadn't you tested 3.3-rc6 and found it to work ok?
  
  No, I never did. Maybe I should.
 

Hmm, I could not find it in the repositories and neither in 
backports.debian.org. I remember, there is another source, where packages go, 
but I forgot, where it was.

Can you point me to, where I find a 3.3-rc6-kernel-package? I guess, I will 
find 
the headers there, too.

Cheers

Hans


-- 
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/201301011454.58798.hans.ullr...@loop.de

Bug#665881: [wheezy] module ath5k is blocking wlan-card

[Hans-J. Ullrich]

Hi Jonathan,

I already tested 3.3-rc6. Just look into the history of this bugreport.

Shall I test it new? Due to my tests in the past, it might be rather possible, 
to find out, in which kernel version and where a change was made, to inhibit 
the described behaviour.

IMO it never appeared in 3.4 and higher.

Hans


-- 
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/201301011633.16038.hans.ullr...@loop.de

Bug#665881: [wheezy] module ath5k is blocking wlan-card

[Hans-J. Ullrich]

Hi Ben, hi Jonathan!

After several tries and 5 hours of compiling, I am sad, to tell you, the 
patch, Ben sent me, is not working.

Just before you take work into a new patch, let me first try kernel-3.4, which 
might be also possible to be released into next debian stable. Ben told so.

I tested 3.1, 3.2, 3,5 and 3.6, but NOT 3.4! So maybe 3.4 might work as 
wished, then no other action has to be done - just release debian with 3.4!

However, if kernel-3.2 shall be in next release, I am willing to test it for 
you. Maybe it will be easier, if you send me a precompiled module, which I 
then will test here.

Please let me explain: I am not too lazy to compile, but my system is not good 
prepared for it. The main problem is, my /usr partition is too small. It has 
only 20G, so kernel building breaks, with no space left on device.

I built the kernel now on my older 64-bit-machine, which has only 512 MB RAM 
and is rather slow. 

It is not possible for me, to increase /usr (i.e. with gparted) without data 
loss, for it is ecrypted with luks.

This just a little bit of information, why I am not so fast with the kernel 
building. All machines I am using (my 64-bit notebook, the 64-bit desktop-pc, 
my netbook and so on) are mostly permanently needed for my work, so they 
should not be killed somehow. I am happy, when they are working as wished!

However, as I said, I am happy, when I can help, but results may be last a 
little longer as expected due to my weired environment.

Thanks for your patience and best regards

Hans



 


-- 
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/201212311917.37299.hans.ullr...@loop.de

Bug#665881: [wheezy] module ath5k is blocking wlan-card

[Hans-J. Ullrich]

Hi Jonathan!
 Gah, that's way more work than should be required. Did the module
 eventually load and just not work well, or were the instructions in my
 message or in the kernel handbook broken? (The latter would be a very
 serious bug, more serious than any particular instance of missing hardware
 support.)
 

It patched fine, it loaded fine, but the bug did not disappear.
 Hadn't you tested 3.3-rc6 and found it to work ok?
 
No, I never did. Maybe I should. 

 [...]
 
 
 It sounds like debuginfo is not disabled like it should be. Did you forget
 to run scripts/config --disable DEBUG_INFO?

Ahm I forgot. I just build the whole kernel with make-kpkg -j4 --initrd 
kernel-image 
 
 Sorry for the trouble and hope that helps.

Next time, I will try better.
 
 Sincerely,
 Jonathan

Greets

Hans


-- 
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/201212311953.59137.hans.ullr...@loop.de

Bug#665881: linux-image-3.2.0-2-amd64: module ath5k is blocking wlan-card

[Hans-J. Ullrich]

 Heh, no, sorry.
 
 Could you test whether the attached patches fix the problem in 3.2?
 Please follow the instructions at
 http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-off
 icial to rebuild the kernel package with these patches.
 
 Ben.

Hi Ben, 

so, now after hours and hours of compiling, I could not manage to get the 
patched module loaded. The system is telling something of version mismatch.

Whatever, I think, just close the bug and do no more efforts in fixing the bug, 
it is itz not worth for the following reasons:

1. This bug is now since kernel 3.1 and no one cared of it - except of me.

2. As I am the only one with this bug, it needs not to be fixed - I got a 
solution for me (just using a newer kernel)

3. The kernel 3.2.X is such old, that it will be very soon replaced by the 
newer ones - who cares, what Ubuntu does.

4. I suggest, just to add the patch into the next kernel 3.2-0-XXX version. I 
will report it. It will make things not worse than they are. I will report of 
my tests then.

So, it will be ok for me, if the bug will be closed.


Thank you very much for your help, and do not waste any time for fixing this 
bug. There are much more important bugs to fix, I think!

Best regards and a happy new year!

Hans
 


-- 
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/201212302001.45418.hans.ullr...@loop.de

Bug#665881: [wheezy] module ath5k is blocking wlan-card

[Hans-J. Ullrich]

Hi Jonathan,
 
 Could you send the command you used?  Generally you need to install
 the new Debian package you built and reboot to test, but there are
 other possibilities, too.  The above doesn't tell me enough to know
 what went wrong.

Sure! I did the following: Installed all needed packages, unpacked the source 
package and made a symlink /usr/src/linux to /usr/src/linux-source-3.2

Patched: patch -p1  /mypath/blah/0001ath5kxx.patch
So I did with all patches.

Then copied /boot/config-3.2.0-4-amd64 to /usr/src/linux/.config (so I got also 
the version, worked before in the past this way).

After that make menuconfig to check.

Building then:  make modules, because I just wanted to build only the ath5k 
module. 

At last I copied the newly build module ath5k.ko and replaced it with the new 
built one.

depmod -a finished all.

 
 You've made this same argument before.  The sad situation we're in is
 that only a small fraction of Debian users report bugs.  You're a
 representative of quiet masses of Debian users, potential Debian
 users, and other Linux users with similar hardware.  Meanwhile
 stubborn people like me want to see all easily-fixable hardware
 support bugs fixed, even if they only affect one person.
 

Well, if there are other people with the same problem, leave it open. Very ok 
for me! I just did not want to waste your time for a single person (=me), who 
cannot give much help back.

 Sorry for the burden, but it really does help.
 
 Of course if you're sick of it, that's also fine --- we can mark the
 bug as unreproducible, stop bothering you, and probably close it in a
 couple of weeks.

No, I am not sick and I will try it in the next time. But my time is limited, 
as I cannot run compilatiuon at work and in the evening the time is often too 
short, to run a compilation.

 
 Hoping that clarifies,
 Jonathan

Best regards

Hans


-- 
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/201212302147.39949.hans.ullr...@loop.de

Bug#665881: linux-image-3.2.0-2-amd64: module ath5k is blocking wlan-card

[Hans-J. Ullrich]

Dear maintainers,

I just want to let you know, that this bug is still in linux-image-3.2.0-4-
amd64, but NOT in version linux-image-3.5.XXX and also NOT in version linux-
image-3.6. from experimental.

Both kernels I have run now for the last months (3.5 for over 4 months and now 
3.6 for more than 4 weeks).

Both kernel are running super fine! No problems in any case.

Just in case for the new stable version, I suggest 3.5 or higher should be 
released.

Thanks for reading this mail.

Have a very nice christmess!


Hans 


-- 
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/201212231118.22386.hans.ullr...@loop.de