Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#38800 - [linux] 3.12: desktop feezes with nfs write and activated swap space

Attached to Project: Arch Linux
Opened by Michael (hede) - Wednesday, 05 February 2014, 15:16 GMT
Last edited by Doug Newgard (Scimmia) - Saturday, 14 October 2017, 14:23 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

If I copy a big file via nfs to some server, my Desktop is freezing every other second. Mouse lags, etc.

Wired thing: If I disable swap space, everything turns to normal.

Additional info:
IBM Thinkcentre A60
NVidia NForce 410 / MCP51 / Geforce 6050
Broadcom Corporation NetXtreme BCM5788
1 GB Ram, Sata Disk
Linux 3.12.9-1-ARCH i686
Nouveau GPU driver

Steps to reproduce:

prerequisite: some Network Server exporting an NFS share with async option set (here it's a dm600 Dreambox)

At the arch desktop client:
# mount 192.168.2.49:/media/hdd -o nfsvers=3,async,rsize=8192,wsize=8192 /mnt/tmp2
# cp /home/user/somebigfile /mnt/tmp2/

result: desktop is freezing, mouse lags, ...

# swapoff -a

result: everything turns to normal, file copy is progressing.

# swapon -a

result: desktop is freezing, mouse lags, slow copy progress, ...
This task depends upon

Closed by  Doug Newgard (Scimmia)
Saturday, 14 October 2017, 14:23 GMT
Reason for closing:  No response
Comment by Michael (hede) - Wednesday, 05 February 2014, 15:26 GMT
PS: I tried different parameters with mount.nfs: other w/rsizes results in more or less network speed. With "sync" everything is fine, but it's really slow. "intr" doesn't change a thing.

If swapspace is activated and the desktop is laggy, I can kill the copy command ([ctrl]-[c] in the xterm), then immediatly everything is fine (no lags) even while the buffers are still flushing (command prompt not appearing) and network traffic is still on-going!
Comment by Michael (hede) - Wednesday, 05 February 2014, 15:28 GMT
PPS: Even with activated swapspace, the swap does not get used. The "free" command shows the following while lagging:

total used free shared buffers cached
Mem: 996480 944308 52172 26684 1444 217712
-/+ buffers/cache: 725152 271328
Swap: 974844 0 974844

... so it's not swap activity which is causing the lags.
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 07 February 2014, 01:24 GMT
  • Field changed: Summary (desktop feezes with nfs write and activated swap space → [linux] 3.12: desktop feezes with nfs write and activated swap space)
  • Field changed: Status (Unconfirmed → Waiting on Response)
  • Field changed: Category (Packages: Extra → Upstream Bugs)
  • Task assigned to Thomas B├Ąchler (brain0), Tobias Powalowski (tpowa)
upstream report? status with 3.13?
Comment by Michael (hede) - Saturday, 08 February 2014, 10:13 GMT
I haven't done any upstream report. I don't even know if it's related to linux (the kernel) or something else. Maybe there's some hardware issue? Interrupts? The lags are havier if there are more apps/programs running, even if there's no Disk activity (except the copy process itself) and the CPU is pretty much idle (<10% load).

Lags starting 30-60 seconds after I start "cp" to the nfs share. If it's lagging and I do a "swapoff -a", then it needs 10-20 seconds to settle down, then the lags mitigate/soften. (remember: that's the case even if swap space is nearly unused, in my last Test there was 356kB swap space usage at the time when I did the "swapoff -a")

btw: the nfs server here is some dreambox set top box, which limits the network traffic to 1-3 MB/s, so at the pc side (arch) there shouldn't be anything that busy ...

The problem still exist with:
Linux pcname 3.13.2-1-ARCH #1 SMP PREEMPT Thu Feb 6 23:34:40 CET 2014 i686 GNU/Linux

Interrupt table:
$ cat /proc/interrupts
CPU0 CPU1
0: 52 0 XT-PIC-XT-PIC timer
6: 0 3 IO-APIC-edge floppy
7: 1 0 IO-APIC-edge
8: 0 1 IO-APIC-edge rtc0
9: 0 0 IO-APIC-fasteoi acpi
11: 1185 1034539 IO-APIC-fasteoi enp3s8
14: 10 1962 IO-APIC-edge pata_amd
15: 0 0 IO-APIC-edge pata_amd
19: 2 986 IO-APIC-fasteoi snd_hda_intel
20: 0 0 IO-APIC-fasteoi sata_nv
21: 179 32062 IO-APIC-fasteoi sata_nv
22: 0 4 IO-APIC-fasteoi ehci_hcd:usb1
23: 183 31840 IO-APIC-fasteoi ohci_hcd:usb2
41: 1 804 PCI-MSI-edge nouveau
NMI: 9 11 Non-maskable interrupts
LOC: 149844 139431 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 9 11 Performance monitoring interrupts
IWI: 8484 7320 IRQ work interrupts
RTR: 0 0 APIC ICR read retries
RES: 216842 170744 Rescheduling interrupts
CAL: 83 2178 Function call interrupts
TLB: 1641 3014 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 7 7 Machine check polls
ERR: 1
MIS: 0

Btw, I remember I've seen some error message regarding linux detecting some mainboard bug where some timer is not connected to the apic here. I cannot find it in dmesg now. Will check that later.
   dmesg.txt (47.5 KiB)
Comment by Michael (hede) - Saturday, 08 February 2014, 10:24 GMT
The apic timer issue is in the dmesg:
[ 0.026666] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
But this seems not to be the issue because:
[ 0.033333] ...trying to set up timer as ExtINT IRQ...
[ 0.067041] ..... works.
And timer interrupts are comming in:
0: 52 0 XT-PIC-XT-PIC timer
Comment by Tobias Powalowski (tpowa) - Wednesday, 13 August 2014, 07:02 GMT
Status on 3.16?
Comment by Michael (hede) - Wednesday, 13 August 2014, 17:41 GMT
Linux pcname 3.16.0-2-ARCH #1 SMP PREEMPT Mon Aug 4 19:04:45 CEST 2014 x86_64 GNU/Linux

It's still reproducible.

The PC has 4GB Ram now. Behaviour is different. GUI is clean, but surfing with firefox, opening some tabs, it stalls every now and then.

Using mem=1G (kernel cmdline) and opening some applications I can reproduce the old behaviour in lagging/stuttering GUI incl. Mouse movement.

But this seems only affecting X. Opening xterm and press and holding a key results in lagging/stuttering char input. Switching to a VT (i.e. [ctrl]-[alt]-[F2]) and press and holding a key results in clean/consistent/regular input.

Additional info: Besides 3 more GB RAM the PC has a Radeon HD 5770 now, using the included open source radeon driver.
Comment by mattia (nTia89) - Sunday, 01 October 2017, 15:35 GMT
is this issue still valid?

Loading...