Bug#884094: Impact on NFS shared

[Ben Hutchings]

On Sat, 2017-12-16 at 00:28 +0100, Louis Chanouha wrote:
> I'm not Linux kernel neither Debian boot friendly, my apologies if
> I'm missing anything. 
> This error occurred after a reboot on an fresh install of Debian
> STRETCH (not upgraded from Jessie), consecutive after an apt upgrade
> command (with kernel update). 
> This installation is very standard (but with LVM layer), no
> modifications regarding boot configuration were done (debian
> installer did the job). 
> 
> Tell me if you need something from me, I would me glad to help.

Try these commands:

uname -v
dpkg -l linux-image-4.9.0-4-amd64
debsums -c linux-image-4.9.0-4-amd64

Ben.

-- 
Ben Hutchings
Teamwork is essential - it allows you to blame someone else.



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

Bug#859639: More info

[Samuel Smith]

Apparently switching to use the intel driver (instead of modeset) did 
not fix anything, just made it worse.


What seems to cause the issue is using Firefox + having a second 
instance of Firefox open (using a "Dev" profile, I use this for web 
development work) + having a private browsing instance open on the Dev 
profile.


With the modesetting driver one of two things would happen. Either one 
of the Firefox instances would stop responding, but not due to 100% cpu 
lock up, it was as if the firefox instance would just stop responding to 
mouse or keyboard inputs for minutes at a time. Normally a 'Ctrl+q' 
would fix that (basically quit and restart). I don't actually remember 
having this problem up until a couple of weeks ago.


In the other case, I'd minimize firefox to the task bar, do something 
else, and then maximize it back. But upon the maximize, the screen on my 
external monitor would turn black for a second and then come back on 
(laptop is in a docking station with the lid closed and LCD screen off), 
if I move my mouse or click, the screen would again turn black for a 
second and then come back. Only way to stop this cycle is to either 
minimize the firefox instance or 'Ctrl+q' it. Now this particular issue 
happens about once a month (sometimes every other month) and had done 
that for a few months now (but less than a year). The problem is that 
since the last kernel update, it seems to happen everyday. Been that way 
for the last 2 weeks or so. But also I updated Firefox from 57 to 57.0.1 
about 2 weeks ago as well... so not sure. But either way, a web browser 
should not cause a monitor to go blank.


Onto today, about 24 hours after using the intel driver (the current one 
in the repos) I got a complete screen freeze. The mouse cursor started 
to move very slowly and then stopped. Nothing would respond after that. 
There was no hard drive activity either (so nothing ate up all the ram 
and started swapping to disk). Keyboard was not responsive either. Not 
even pushing capslock would light the capslock led on the keyboard. 
Tried ctrl+alt+backspace but got nothing. Tried various sysrq commands 
but no response so had to force the whole laptop off by holding down the 
power button.


Upon boot up, I removed the intel driver and went back to the 
modesetting driver. On my two Firefox instances, I had forced GPU 
offloading via the 'layers.acceleration.force-enabled' option. Normally 
it is disabled on Linux machines. I went ahead and left it forced on for 
my main instance (so no change), but on my Dev instance, I set it back 
to default (off). Perhaps running two instances of Firefox with GPU 
acceleration is too much, but still should not crash a system...



Not sure what info I should provide, but here's an lspci of my vga:

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core 
Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 
[VGA controller])
Subsystem: Lenovo 2nd Generation Core Processor Family 
Integrated Graphics Controller

Flags: bus master, fast devsel, latency 0, IRQ 29
Memory at f000 (64-bit, non-prefetchable) [size=4M]
Memory at e000 (64-bit, prefetchable) [size=256M]
I/O ports at 4000 [size=64]
[virtual] Expansion ROM at 000c [disabled] [size=128K]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: i915
Kernel modules: i915

Debating on grabbing the latest kernel from backports.. but really don't 
want to have to mess with that. Thinking something is wrong in the i915 
driver.



Regards,

Re: Re: Iproute2 for Debian testing and backports

[Luca Boccassi]

On Thu, 14 Dec 2017, Alexander Wirt wrote:
> On Wed, 13 Dec 2017, Stephen Hemminger wrote:
> 
> > Iproute2 gains new features every release to keep up with the
upstream kernel.
> > 
> > How do I request that iproute for Debian testing (buster) and
backports (stretch-backports)
> > be kept in sync?  
> > kernel  iproute
> > sid 4.144.9
> > buster  4.134.9
> > stretch-backports   4.134.9
> > stretch 4.9 4.9
> > 
> > Do you need resources to be applied to Debian maintenance for this?
> Yes, we need more manpower. 
> 
> Alex

Hello Alex,

In case you'd like some help in maintaining iproute2, I'll happily
volunteer. I could give you a hand keeping up with new releases. We
rely heavily on iproute2 at $work so it's a win-win.

And I worked with Stephen in the past, so if he breaks something
upstream I know where to find him :-P

Kind regards,
Luca Boccassi

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

Bug#884094: Impact on NFS shared

[Louis Chanouha]

I'm not Linux kernel neither Debian boot friendly, my apologies if I'm missing 
anything. 
This error occurred after a reboot on an fresh install of Debian STRETCH (not 
upgraded from Jessie), consecutive after an apt upgrade command (with kernel 
update). 
This installation is very standard (but with LVM layer), no modifications 
regarding boot configuration were done (debian installer did the job). 

Tell me if you need something from me, I would me glad to help. 

Regards, 
Louis 
> 
> From: Ben Hutchings 
> Sent: Fri Dec 15 19:05:30 CET 2017
> To: Louis Chanouha , <884...@bugs.debian.org>
> Subject: Re: Bug#884094: Impact on NFS shared
> 
> 
> On Fri, 2017-12-15 at 17:08 +0100, Louis Chanouha wrote:
> > Thie 4.9.0-4 update broke my NFS mounted sahred, with the following line 
> > in syslog:
> > 
> > dns_resolver: Unknown symbol register_key_type_2 (err 0)
> > 
> > Rollback to kernel 4.9.0-3-amd64 solves the issues, but i think this bug 
> > should be considered as critical.
> 
> This means you are running the old kernel with new modules.  Either you
> have not rebooted or your boot loader is misconfigured.
> 
> Ben
> 
> -- 
> Ben Hutchings
> Teamwork is essential - it allows you to blame someone else.
> 

Bug#883938: RFT: Candidate fix for boot failure of Debian 8.10 on various x86 systems

[Dr. Nagy Elemér Kár oly]

Dear Ben,

Thank you, the fix works for me, both Sun Fires (X2200M2 and X4200M2) boot with 
3.16.51-3~a.test (2017-12-11).

Best wishes:
Elemér

Re: Possibilities for a special Azure or cloud Linux package

[Bastian Blank]

Hi

I forgot to add the cloud team early to this mail.

On Sat, Nov 18, 2017 at 01:48:53AM +, Ben Hutchings wrote:
> On Fri, 2017-11-17 at 16:07 +0100, Bastian Blank wrote:
> > Hi kernel team
> > 
> > We at credativ are responsible for maintaining the Azure cloud images.
> > We got asked by Microsoft to explore the possibilities of introducing a
> > specialised Linux image for this plattform into Debian.  The main
> > enhancements we look at would be:
> > - faster boot of the instance,
> > - smaller memory footprint of the running kernel, and
> > - new features.
> 
> However, if it is possible to create a single flavour that provides
> those sorts of enhancements for multiple cloud platforms, I think that
> would be worthwhile.

I have some initial findings for a kernel using a derived config.  I
reduced the boot time by 5 seconds (from 30 to 25).  The installed size
was reduced from 190 to 50MB.

Microsoft published a patch set against 4.13 and 4.14
https://github.com/Microsoft/azure-linux-kernel
they would like to add.

Now the question is if other cloud providers would like to follow such a
path by using and careing for a specialised linux image for this
platforms?

Bastian

-- 
Landru! Guide us!
-- A Beta 3-oid, "The Return of the Archons", stardate 3157.4

Bug#884482: linux-image-4.13.0-1-amd64: KVM module doesn't load: ERROR: could not insert 'kvm_intel': Input/output error

[Diane Trout]

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

Dear Maintainer,

After booting into 4.13.13 my kvm based virutual hosts wouldn't load
any longer.

root:~# kvm
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: failed to initialize KVM: No such file or directory

trying to load the kvm driver produces:

root:~# modprobe kvm_intel
modprobe: ERROR: could not insert 'kvm_intel': Input/output error

My problem looks similar to this RedHat bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1490803

I sanitized the networking information slightly as the specific network
location of this server isn't relevant for this issue.

Diane

-- Package-specific info:
** Version:
Linux version 4.13.0-1-amd64 (debian-kernel@lists.debian.org) (gcc
version 6.4.0 20171112 (Debian 6.4.0-10)) #1 SMP Debian 4.13.13-1
(2017-11-16)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.13.0-1-amd64 root=UUID=81e67589-4623-4681-
bf24-96391732cd99 ro quiet

** Not tainted

** Kernel log:
Running modprobe doesn't add any messages to the kernel log, and there
are no messages about kvm in the log.

"dmesg | grep -i kvm" returns nothing.

** Model information
sys_vendor: Dell Inc.
product_name: PowerEdge 2900
product_version: 
chassis_vendor: Dell Inc.
chassis_version: 
bios_vendor: Dell Inc.
bios_version: 1.3.7
board_vendor: Dell Inc.
board_name: 0YM158
board_version: A00

** Loaded modules:
nfsv3
nfs_acl
ebtable_filter
ebtables
ip6table_filter
ip6_tables
devlink
rpcsec_gss_krb5
nfsv4
dns_resolver
nfs
iptable_filter
lockd
grace
fscache
sit
tunnel4
ip_tunnel
fuse
amdkfd
radeon
coretemp
xfs
kvm
ttm
iTCO_wdt
iTCO_vendor_support
drm_kms_helper
irqbypass
drm
ipmi_si
i5000_edac
dcdbas
lpc_ich
mfd_core
sg
evdev
i2c_algo_bit
shpchp
pcspkr
serio_raw
i5k_amb
ipmi_devintf
ipmi_msghandler
button
rng_core
binfmt_misc
auth_rpcgss
sunrpc
loop
ecryptfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
fscrypto
ecb
crypto_simd
cryptd
glue_helper
aes_x86_64
hid_generic
usbhid
hid
btrfs
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
raid1
multipath
linear
raid0
md_mod
sd_mod
sr_mod
cdrom
ata_generic
ata_piix
psmouse
ehci_pci
libata
uhci_hcd
ehci_hcd
mptsas
scsi_transport_sas
mptscsih
usbcore
mptbase
usb_common
scsi_mod
bnx2

** Network interface configuration:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 131.215.xx.xx
netmask 255.255.255.0
network 131.215.xx.0
broadcast 131.215.xx.255
gateway 131.215.xx.xx
dns-nameservers 131.215.xx.xx 131.215.xx.xx
dns-search caltech.edu


** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc mq state UP
group default qlen 1000
link/ether 00:19:b9:da:e3:47 brd ff:ff:ff:ff:ff:ff
inet 131.215.xx.xx/24 brd 131.215.34.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::219:b9ff:feda:e347/64 scope link 
   valid_lft forever preferred_lft forever
3: eth1:  mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 00:19:b9:da:e3:49 brd ff:ff:ff:ff:ff:ff

*** Device statistics:
Inter-
|   Receive|  Transmit
 face |bytespackets errs drop fifo frame compressed
multicast|bytespackets errs drop fifo colls carrier compressed
 
eth1:   0   0000 0  0 0
0   0000 0   0  0
lo:   22975 389000 0  0 022
975 389000 0   0  0
 
sit0:   0   0000 0  0 0
0   0000 0   0  0
  eth0: 1142440884 4392456000 0  0408703
279879593  649479000 0   0  0
 
6to4:  1699201770000 0  0 0   17452
81818000 0   0  0

*** Protocol statistics:
Ip:
Forwarding: 2
1326412 total packets received
548374 with invalid addresses
0 forwarded
0 incoming packets discarded
778038 incoming packets delivered
536831 requests sent out
26 dropped because of missing route
Icmp:
3975 ICMP messages received
174 input ICMP message failed
ICMP input histogram:
destination unreachable: 169
timeout in transit: 9
redirects: 40
echo requests: 3754
echo replies: 3
4197 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 443
echo 

Processed: reassign 884426 to src:linux

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 884426 src:linux 4.9.65-3
Bug #884426 [firmware-iwlwifi] Wifi speeds of Debian 9 (Stretch) are 2-3 times 
slower than Debian 8 (Jessie)
Bug reassigned from package 'firmware-iwlwifi' to 'src:linux'.
No longer marked as found in versions firmware-nonfree/20161130-3.
Ignoring request to alter fixed versions of bug #884426 to the same values 
previously set
Bug #884426 [src:linux] Wifi speeds of Debian 9 (Stretch) are 2-3 times slower 
than Debian 8 (Jessie)
Marked as found in versions linux/4.9.65-3.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
884426: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884426
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#884094: Impact on NFS shared

[Ben Hutchings]

On Fri, 2017-12-15 at 17:08 +0100, Louis Chanouha wrote:
> Thie 4.9.0-4 update broke my NFS mounted sahred, with the following line 
> in syslog:
> 
> dns_resolver: Unknown symbol register_key_type_2 (err 0)
> 
> Rollback to kernel 4.9.0-3-amd64 solves the issues, but i think this bug 
> should be considered as critical.

This means you are running the old kernel with new modules.  Either you
have not rebooted or your boot loader is misconfigured.

Ben

-- 
Ben Hutchings
Teamwork is essential - it allows you to blame someone else.



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

Bug#884094: Impact on NFS shared

[Louis Chanouha]

Thie 4.9.0-4 update broke my NFS mounted sahred, with the following line 
in syslog:


dns_resolver: Unknown symbol register_key_type_2 (err 0)

Rollback to kernel 4.9.0-3-amd64 solves the issues, but i think this bug 
should be considered as critical.



Louis



--

*Logo UFTMiPLouis Chanouha | **Systèmes & Réseaux | Administrateur du SCOUT*
/Service Numérique de l'Université de Toulouse/
*Université Fédérale Toulouse Midi-Pyrénées*
15 rue des Lois - BP 61321 - 31013 Toulouse Cedex 6
Tél. : +33(0)5 61 10 80 45  / poste int. : 18045

louis.chano...@univ-toulouse.fr
Facebook 
 | 
Twitter  | www.univ-toulouse.fr 

Bug#855632: Bug#883217: linux: open on NFSv4 exported file on nfs server: "Resource temporarily unavailable" under reproducible conditions when client has granted read delegation on file

[Salvatore Bonaccorso]

Hi Stephen,

On Thu, Dec 14, 2017 at 05:51:12PM -0700, Stephen Dowdy wrote:
> 
> 
> On 12/14/2017 12:51 PM, Salvatore Bonaccorso wrote:
> > Hi Stephen,
> > 
> > On Mon, Dec 04, 2017 at 09:24:55PM +0100, Salvatore Bonaccorso wrote:
> >> Hi
> >>
> >> On Thu, Nov 30, 2017 at 03:35:40PM -0700, Stephen Dowdy wrote:
> >>> On 11/30/2017 01:39 PM, Salvatore Bonaccorso wrote:
>  Is this worth trying to be fixed for the jessie kernel?
> >>>
> >>> Salvatore,
> >>>
> >>> I believe this is likely the reason for my bug report:
> >>>
> >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855632
> >>>
> >>> as that system has thrown EAGAIN errors since i installed it in April, 
> >>> 2015.
> >>> It's a 10 NIC NFS server for the department, and often throws the error 
> >>> when i update files that are likely being read/open by client systems.
> >>> (it doesn't have a huge resource consumption load ever and i get that 
> >>> failure)
> >>>
> >>> So, i vote yeah ;)
> >>
> >> Okay.
> > 
> > Did you got a chance to test this as well for your case of #855632?
> > 
> > Regards,
> > Salvatore
> > 
> Salvatore,
> 
> 
> Sorry i didn't respond.  things have been way crazy.  Unfortunately, i 
> probably won't be able to test because:
>- problem is not reproducible easily sometimes
>- this machine services several hundred systems w/o any upcoming scheduled 
> downtime.
> 
> I haven't noticed the problem on any other machines we have, though, so don't 
> have any other candidates for testing.

Many thanks for the reply now, is much appreciated to see were we
stand. Yes I can perfectly understand the reasoning. the change is now
pending for 3.16.51-4 (or any later interation via a point release of
jessie), so if it happens to you to not have updated to stretch yet
and see your issue resolved as well we can close the second bug.

Regards,
Salvatore