amdgpu, 5.11.0, suicide when input of monitor is switched
er nfs lockd grace nfs_ssc fscache scsi_transport_iscsi ipt_REJECT nf_reject_ipv4 xt_multiport nft_compat nft_counter nf_tables nfnetlink rfkill overlay binfmt_misc x86_pkg_temp_thermal kvm_intel kvm irqbypass crct10dif_pclmul ghash_clmulni_intel aesni_intel crypto_simd cryptd glue_helper pcspkr serio_raw iTCO_wdt ee1004 iTCO_vendor_support uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common snd_usb_audio snd_usbmidi_lib videodev sg snd_rawmidi mc mei_me mei intel_pch_thermal acpi_pad evdev joydev ext4 crc16 mbcache jbd2 nvidia_drm(POE) nvidia_modeset(POE) loop nvidia(POE) drivetemp i2c_dev parport_pc parport configfs sunrpc ip_tables x_tables autofs4 raid10 raid456 async_raid6_recov [ 283.611643] async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear md_mod wacom hid_generic usbhid hid uas usb_storage amdgpu gpu_sched i2c_algo_bit drm_ttm_helper ttm crc32_pclmul psmouse mxm_wmi xhci_pci nvme drm_kms_helper xhci_hcd nvme_core cec i2c_designware_platform drm i2c_designware_core usbcore [ 283.611655] CPU: 6 PID: 214 Comm: kworker/6:3 Tainted: PW OE 5.11.0 #125 [ 283.611656] Hardware name: MSI MS-7A16/Z170A MPOWER GAMING TITANIUM(MS-7A16), BIOS 1.10 07/22/2016 [ 283.611657] Workqueue: events dm_irq_work_func [amdgpu] [ 283.611715] RIP: 0010:amdgpu_dm_atomic_commit_tail+0x21ca/0x2250 [amdgpu] [ 283.611772] Code: ff ff 37 00 00 00 c7 85 ac fd ff ff 20 00 00 00 e8 3b 50 12 00 e9 4c fb ff ff 0f 0b e9 9b f9 ff ff 0f 0b e9 eb f9 ff ff 0f 0b <0f> 0b e9 01 fa ff ff 48 89 c8 44 8b 85 bc fd ff ff bf 04 00 00 00 [ 283.611774] RSP: 0018:a93340a3fab8 EFLAGS: 00010086 [ 283.611775] RAX: 0001 RBX: 0001 RCX: 942594ed9118 [ 283.611776] RDX: 0001 RSI: 0297 RDI: 942596120188 [ 283.611777] RBP: a93340a3fdb0 R08: 0005 R09: [ 283.611778] R10: a93340a3fa18 R11: 0002 R12: 0297 [ 283.611779] R13: 9426652bc400 R14: 942594ed9000 R15: 94258abdcd80 [ 283.611779] FS: () GS:9434bed8() knlGS: [ 283.611781] CS: 0010 DS: ES: CR0: 80050033 [ 283.611782] CR2: 7f1c940f0030 CR3: 000accc0a002 CR4: 003706e0 [ 283.611783] DR0: DR1: DR2: [ 283.611784] DR3: DR6: fffe0ff0 DR7: 0400 [ 283.611784] Call Trace: [ 283.611788] commit_tail+0x94/0x130 [drm_kms_helper] [ 283.611793] drm_atomic_helper_commit+0x113/0x140 [drm_kms_helper] [ 283.611798] dm_restore_drm_connector_state+0xef/0x170 [amdgpu] [ 283.611856] handle_hpd_irq+0xea/0x120 [amdgpu] [ 283.611913] dm_irq_work_func+0x49/0x60 [amdgpu] [ 283.611969] process_one_work+0x1ec/0x380 [ 283.611971] worker_thread+0x53/0x3d0 [ 283.611973] ? process_one_work+0x380/0x380 [ 283.611975] kthread+0x11b/0x140 [ 283.611976] ? __kthread_bind_mask+0x60/0x60 [ 283.611978] ret_from_fork+0x22/0x30 [ 283.611980] ---[ end trace 4c7cf81f00d90177 ]--- I was running a KDE/Plasma session (5.21) on top of Debian/unstable. The xsession-error log only shows kscreen.kded: Config does not have at least one screen enabled, WILL NOT save this config, this is not what user wants. and XOrg log didn't say anything. I tried switching to the console and back, but the screen didn't come back. Thanks for any suggestion Norbert -- PREINING Norbert https://www.preining.info Fujitsu Research Labs + IFMGA Guide + TU Wien + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
kernel hard lockups wit 5.9-rc{2,3}
Dear all, (please Cc) I am seeing hard lockups with 5.9-rc2 and -rc3, while 5.8.N (1,2,3,4,5) work without any problems. THe lockups are hard to debug, since not even Sysrq works anymore. The screen freezes completely, no reaction. Ports are also dead, ssh into the machine is not possible. Hangs are repeatable, but not triggerable (at least I didn't find a way). Last time I left the screen locked and went shopping to find it locked up coming back. In total I got about 10 lock ups. This is an Intel CPU with AMD 5700xt GPU, running Debian/unstable. My feeling is somehow GPU related, but that might be a wide grasp. Any suggestions how to debug this? The kernel logs after reboot are empty. Best Norbert -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
IWL AC 8260, suspect GRP implementation, broken connectivity
Dear all, (please cc) linux 5.3.N (currently .7), but also older kernels Debian/sid Thinkpad X260 iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208 iwlwifi :04:00.0: loaded firmware version 36.8fd77bb3.0 op_mode iwlmvm In one particular location I see completely broken connection: dns does not work (resolve does not work), ping, ssh breaks down, http breaks down, it really sounds like a really weak connection. The problem is that: - the *same* laptop booted into Windows works at high speed connections - other computers (2 Mac) around here work without problems - mobile also connects without any problem There are no RX/TX errors whatsoever. I tried reducing MTU, to no effect. The only warning I see is TCP: wlp4s0: Driver has suspect GRO implementation, TCP performance may be compromised. wlp4s0: flags=4163 mtu 1400 inet 172.17.1.166 netmask 255.255.0.0 broadcast 172.17.255.255 inet6 fe80::fddc:f32e:f9cb:fded prefixlen 64 scopeid 0x20 ether e4:a7:a0:66:6d:f4 txqueuelen 1000 (Ethernet) RX packets 11164 bytes 7459009 (7.1 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 13204 bytes 3062515 (2.9 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 I am a bit at loss how to debug this, or better, whether it is possible to get back normal connectivity? Thanks a lot for any pointer Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: IWL AC 8260, kernel 5.3.*, many kernel WARNING
Dear Kalle, On Fri, 27 Sep 2019, Kalle Valo wrote: > I'm guessing this should fix it: > https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git/commit/?id=fddbfeece9c7882cc47754c7da460fe427e3e85b Yes, I can confirm that with this patch added on top of 5.3.1 I don't see the warnings anymore. Thanks a lot Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
IWL AC 8260, kernel 5.3.*, many kernel WARNING
l: CS: 0010 DS: ES: CR0: 80050033 Sep 27 09:08:35 burischnitzel kernel: CR2: 34b8490c9000 CR3: 00035980a004 CR4: 003606f0 Sep 27 09:08:35 burischnitzel kernel: Call Trace: Sep 27 09:08:35 burischnitzel kernel: iwl_mvm_async_handlers_wk+0xaa/0x140 [iwlmvm] Sep 27 09:08:35 burischnitzel kernel: process_one_work+0x1cf/0x370 Sep 27 09:08:35 burischnitzel kernel: worker_thread+0x4a/0x3c0 Sep 27 09:08:35 burischnitzel kernel: ? process_one_work+0x370/0x370 Sep 27 09:08:35 burischnitzel kernel: kthread+0x118/0x130 Sep 27 09:08:35 burischnitzel kernel: ? kthread_create_worker_on_cpu+0x70/0x70 Sep 27 09:08:35 burischnitzel kernel: ret_from_fork+0x35/0x40 Sep 27 09:08:35 burischnitzel kernel: ---[ end trace 544d5d5df075debd ]--- This repeats a few times (2-4) and then it settles down. WIFI works without any problems, though. Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: 4.13 breaks suspend to ram wakeup
Hi Ming, > So could you share us how often it is triggered? and what is your underlying > disk behind dm-crypt? It is triggered *every* time I suspend. Underlying disk is scsi 1:0:0:0: Direct-Access ATA WDC WD10JPVX-08J 1A07 PQ: 0 ANSI: 5 I checked the values in /sys/block/dm-?/dm/use_blk_mq and they are all set to 0. > BTW, you can debug and collect some dmesg log during system suspend/resume > without serial console: I will try that tonight, now I am at work. > Please get the patches backported to v4.13 in the following tree: Thanks Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. +JAIST +TeX Live +Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: 4.13 breaks suspend to ram wakeup
Hi Ming, > So could you share us how often it is triggered? and what is your underlying > disk behind dm-crypt? It is triggered *every* time I suspend. Underlying disk is scsi 1:0:0:0: Direct-Access ATA WDC WD10JPVX-08J 1A07 PQ: 0 ANSI: 5 I checked the values in /sys/block/dm-?/dm/use_blk_mq and they are all set to 0. > BTW, you can debug and collect some dmesg log during system suspend/resume > without serial console: I will try that tonight, now I am at work. > Please get the patches backported to v4.13 in the following tree: Thanks Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. +JAIST +TeX Live +Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: 4.13 breaks suspend to ram wakeup
Dear all, thanks for the quick feedback. On Wed, 20 Sep 2017, Ming Lei wrote: > Looks your issue is very similar with Oleksandr's report: Indeed, I am using dm-crypt (full disk encryption) and CONFIG_DEFAULT_IOSCHED="cfq" Any suggestion what should be selected instead? > And Oleksandr tested the following patchset can fix his issue: >https://marc.info/?l=linux-block=150579298505484=2 Do you have a patch against 4.13? I tried applying the following patches from git format-patch ebb2c2437d8008d467969 0001-blk-mq-only-run-hw-queues-for-blk-mq.patch 0002-block-tracking-request-allocation-with-q_usage_count.patch 0003-blk-mq-rename-blk_mq_-freeze-unfreeze-_queue.patch 0004-blk-mq-rename-blk_mq_freeze_queue_wait-as-blk_freeze.patch 0005-block-rename-.mq_freeze_wq-and-.mq_freeze_depth.patch 0006-block-pass-flags-to-blk_queue_enter.patch 0007-block-introduce-preempt-version-of-blk_-freeze-unfre.patch 0008-block-allow-to-allocate-req-with-RQF_PREEMPT-when-qu.patch 0009-SCSI-transport_spi-resume-a-quiesced-device.patch 0010-SCSI-preempt-freeze-block-queue-when-SCSI-device-is-.patch to current 4.13, but without success. (I don't want to play with .14-pre kernels by now.) Thanks a lot and all the best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. +JAIST +TeX Live +Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: 4.13 breaks suspend to ram wakeup
Dear all, thanks for the quick feedback. On Wed, 20 Sep 2017, Ming Lei wrote: > Looks your issue is very similar with Oleksandr's report: Indeed, I am using dm-crypt (full disk encryption) and CONFIG_DEFAULT_IOSCHED="cfq" Any suggestion what should be selected instead? > And Oleksandr tested the following patchset can fix his issue: >https://marc.info/?l=linux-block=150579298505484=2 Do you have a patch against 4.13? I tried applying the following patches from git format-patch ebb2c2437d8008d467969 0001-blk-mq-only-run-hw-queues-for-blk-mq.patch 0002-block-tracking-request-allocation-with-q_usage_count.patch 0003-blk-mq-rename-blk_mq_-freeze-unfreeze-_queue.patch 0004-blk-mq-rename-blk_mq_freeze_queue_wait-as-blk_freeze.patch 0005-block-rename-.mq_freeze_wq-and-.mq_freeze_depth.patch 0006-block-pass-flags-to-blk_queue_enter.patch 0007-block-introduce-preempt-version-of-blk_-freeze-unfre.patch 0008-block-allow-to-allocate-req-with-RQF_PREEMPT-when-qu.patch 0009-SCSI-transport_spi-resume-a-quiesced-device.patch 0010-SCSI-preempt-freeze-block-queue-when-SCSI-device-is-.patch to current 4.13, but without success. (I don't want to play with .14-pre kernels by now.) Thanks a lot and all the best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. +JAIST +TeX Live +Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
4.13 breaks suspend to ram wakeup
Hi, (please Cc) I recently upgraded my Lenovo X260 from 4.12 to 4.13 and with the very same software (Debian/sid) 4.13 does not properly wake up from suspend to ram. It wakes up, shows X very quickly, but it seems that the hard disk is sleeping and not reacting. I can move the mouse, but the unlock screen is not shown. Switching to the console I can enter the user name, but then I am waiting for the prompt indefinitely. Callng Sysrq-s to sync the disks never returns that the sync completed. Waiting long enough it completely freezes and only Sysrq-b helps. I have tried to capture any output, but due to the circumstances described, nothing can be saved to persist. I am happy to provide details if someone explains me how to grab them (sorry, no serial console!), or test patches/suggestions with the kernel. Thanks Norbert please Cc. -- PREINING Norbert http://www.preining.info Accelia Inc. +JAIST +TeX Live +Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
4.13 breaks suspend to ram wakeup
Hi, (please Cc) I recently upgraded my Lenovo X260 from 4.12 to 4.13 and with the very same software (Debian/sid) 4.13 does not properly wake up from suspend to ram. It wakes up, shows X very quickly, but it seems that the hard disk is sleeping and not reacting. I can move the mouse, but the unlock screen is not shown. Switching to the console I can enter the user name, but then I am waiting for the prompt indefinitely. Callng Sysrq-s to sync the disks never returns that the sync completed. Waiting long enough it completely freezes and only Sysrq-b helps. I have tried to capture any output, but due to the circumstances described, nothing can be saved to persist. I am happy to provide details if someone explains me how to grab them (sorry, no serial console!), or test patches/suggestions with the kernel. Thanks Norbert please Cc. -- PREINING Norbert http://www.preining.info Accelia Inc. +JAIST +TeX Live +Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: Lenovo Dock + Thinkpad X260 -> no HDMI audio output
Hi Sebastian, > Lenovo Dock Ultra contains a DP-MST Hub to provide all those > HDMI/DVI/DP ports. Audio over DP-MST is currently not supported > by the i915 driver, but there are patches (developed since ~2014): > > https://lists.freedesktop.org/archives/intel-gfx/2016-November/111353.html Thanks a lot. I have tried out the patch including possible fixes for the monitor disconnect issues mentioned in the freedesktop bug, but it does not fix the problem of the disappearing external monitor. Well, that means no audio-out for now, unfortunately. I will have to live without that. Thanks Norbert -- PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info GPG: 0x860CDC13fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: Lenovo Dock + Thinkpad X260 -> no HDMI audio output
Hi Sebastian, > Lenovo Dock Ultra contains a DP-MST Hub to provide all those > HDMI/DVI/DP ports. Audio over DP-MST is currently not supported > by the i915 driver, but there are patches (developed since ~2014): > > https://lists.freedesktop.org/archives/intel-gfx/2016-November/111353.html Thanks a lot. I have tried out the patch including possible fixes for the monitor disconnect issues mentioned in the freedesktop bug, but it does not fix the problem of the disappearing external monitor. Well, that means no audio-out for now, unfortunately. I will have to live without that. Thanks Norbert -- PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info GPG: 0x860CDC13fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Lenovo Dock + Thinkpad X260 -> no HDMI audio output
Dear all, (please cc) I am trying to get HDMI audio output via a Lenovo Dock Ultra in combination with a Lenovo Thinkpad X260. When plugging the HDMI device (screen) directly into the laptop, audio output can be selected in pavucontrol / Configuration, but when the laptop is connected via the dock all the HDMI devices appear as unplugged. I have googled a bit and found a similar case for T430: http://permalink.gmane.org/gmane.linux.alsa.user/36896 and checking the source code of snd_hda_intel it seems that options snd-hda-intel model=lenovo-dock should help, but indeed it didn't. I am running Debian/sid, on today's git kernel (4.9.0-rc5+). I attach the output of alsa-info. Please let me know whether I can try some more tweaks. Thanks a lot Norbert -- PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info GPG: 0x860CDC13fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 upload=true=true= !! !!ALSA Information Script v 0.4.64 !! !!Script ran on: Wed Nov 16 02:30:55 UTC 2016 !!Linux Distribution !!-- Debian GNU/Linux stretch/sid \n \l PRETTY_NAME="Debian GNU/Linux stretch/sid" NAME="Debian GNU/Linux" ID=debian HOME_URL="https://www.debian.org/; SUPPORT_URL="https://www.debian.org/support; BUG_REPORT_URL="https://bugs.debian.org/; !!DMI Information !!--- Manufacturer: LENOVO Product Name: 20F5CTO1WW Product Version: ThinkPad X260 Firmware Version: R02ET48W (1.21 ) !!Kernel Information !!-- Kernel release:4.9.0-rc5+ Operating System: GNU/Linux Architecture: x86_64 Processor: unknown SMP Enabled: Yes !!ALSA Version !! Driver version: k4.9.0-rc5+ Library version:1.1.2 Utilities version: 1.1.2 !!Loaded ALSA modules !!--- snd_hda_intel !!Sound Servers on this system !! Pulseaudio: Installed - Yes (/usr/bin/pulseaudio) Running - Yes Jack: Installed - Yes (/usr/bin/jackd) Running - No !!Soundcards recognised by ALSA !!- 0 [PCH]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xf124 irq 128 !!PCI Soundcards installed in the system !!-- 00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21) !!Advanced information - PCI Vendor/Device/Subsystem ID's !!--- 00:1f.3 0403: 8086:9d70 (rev 21) Subsystem: 17aa:504a !!Modprobe options (Sound related) !! snd_pcsp: index=-2 snd_usb_audio: index=-2 snd_atiixp_modem: index=-2 snd_intel8x0m: index=-2 snd_via82xx_modem: index=-2 snd_hda_intel: model=lenovo-dock !!Loaded sound module options !!--- !!Module: snd_hda_intel align_buffer_size : -1 bdl_pos_adj : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 beep_mode : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y enable_msi : -1 id : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) index : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 jackpoll_ms : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 model : lenovo-dock,(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) patch : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) position_fix : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 power_save : 0 power_save_controller : N probe_mask : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 probe_only : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 single_cmd : N snoop : -1 !!HDA-Intel Codec information !!--- --startcollapse-- Codec: Realtek ALC293 Address: 0 AFG Function Id: 0x1 (unsol 1) Vendor Id: 0x10ec0293 Subsystem Id: 0x17aa504b Revision Id: 0x13 No Modem Function Group found Default PCM: rates [0x5f0]: 32000 44100 48000 88200 96000 192000 bits [0xe]: 16 2
Lenovo Dock + Thinkpad X260 -> no HDMI audio output
Dear all, (please cc) I am trying to get HDMI audio output via a Lenovo Dock Ultra in combination with a Lenovo Thinkpad X260. When plugging the HDMI device (screen) directly into the laptop, audio output can be selected in pavucontrol / Configuration, but when the laptop is connected via the dock all the HDMI devices appear as unplugged. I have googled a bit and found a similar case for T430: http://permalink.gmane.org/gmane.linux.alsa.user/36896 and checking the source code of snd_hda_intel it seems that options snd-hda-intel model=lenovo-dock should help, but indeed it didn't. I am running Debian/sid, on today's git kernel (4.9.0-rc5+). I attach the output of alsa-info. Please let me know whether I can try some more tweaks. Thanks a lot Norbert -- PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info GPG: 0x860CDC13fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 upload=true=true= !! !!ALSA Information Script v 0.4.64 !! !!Script ran on: Wed Nov 16 02:30:55 UTC 2016 !!Linux Distribution !!-- Debian GNU/Linux stretch/sid \n \l PRETTY_NAME="Debian GNU/Linux stretch/sid" NAME="Debian GNU/Linux" ID=debian HOME_URL="https://www.debian.org/; SUPPORT_URL="https://www.debian.org/support; BUG_REPORT_URL="https://bugs.debian.org/; !!DMI Information !!--- Manufacturer: LENOVO Product Name: 20F5CTO1WW Product Version: ThinkPad X260 Firmware Version: R02ET48W (1.21 ) !!Kernel Information !!-- Kernel release:4.9.0-rc5+ Operating System: GNU/Linux Architecture: x86_64 Processor: unknown SMP Enabled: Yes !!ALSA Version !! Driver version: k4.9.0-rc5+ Library version:1.1.2 Utilities version: 1.1.2 !!Loaded ALSA modules !!--- snd_hda_intel !!Sound Servers on this system !! Pulseaudio: Installed - Yes (/usr/bin/pulseaudio) Running - Yes Jack: Installed - Yes (/usr/bin/jackd) Running - No !!Soundcards recognised by ALSA !!- 0 [PCH]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xf124 irq 128 !!PCI Soundcards installed in the system !!-- 00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21) !!Advanced information - PCI Vendor/Device/Subsystem ID's !!--- 00:1f.3 0403: 8086:9d70 (rev 21) Subsystem: 17aa:504a !!Modprobe options (Sound related) !! snd_pcsp: index=-2 snd_usb_audio: index=-2 snd_atiixp_modem: index=-2 snd_intel8x0m: index=-2 snd_via82xx_modem: index=-2 snd_hda_intel: model=lenovo-dock !!Loaded sound module options !!--- !!Module: snd_hda_intel align_buffer_size : -1 bdl_pos_adj : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 beep_mode : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y enable_msi : -1 id : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) index : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 jackpoll_ms : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 model : lenovo-dock,(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) patch : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) position_fix : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 power_save : 0 power_save_controller : N probe_mask : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 probe_only : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 single_cmd : N snoop : -1 !!HDA-Intel Codec information !!--- --startcollapse-- Codec: Realtek ALC293 Address: 0 AFG Function Id: 0x1 (unsol 1) Vendor Id: 0x10ec0293 Subsystem Id: 0x17aa504b Revision Id: 0x13 No Modem Function Group found Default PCM: rates [0x5f0]: 32000 44100 48000 88200 96000 192000 bits [0xe]: 16 2
Re: redraw issues on i915 since 4.9-rc
> It won't apply directly, but you could try testing that commit and its > parent to see if my hunch was correct. Unfortunately parent commit was also ok. I am trying to bisect, but somehow git tells me something about "...merge commit..." - will see how it goes. Norbert -- PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info GPG: 0x860CDC13fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: redraw issues on i915 since 4.9-rc
> It won't apply directly, but you could try testing that commit and its > parent to see if my hunch was correct. Unfortunately parent commit was also ok. I am trying to bisect, but somehow git tells me something about "...merge commit..." - will see how it goes. Norbert -- PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info GPG: 0x860CDC13fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: redraw issues on i915 since 4.9-rc
Hi Chris, > https://cgit.freedesktop.org/drm-intel/ I pulled from there and rebuild my kernel. Rebooting and everything is fine. Looks much better!!! > https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next-queued=d2a84a76a3b970fa32e6eda3d85e7782f831379e Do you want me to test this patch only on top of master? (If it applies!!!) All the best Norbert -- PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info GPG: 0x860CDC13fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: redraw issues on i915 since 4.9-rc
Hi Chris, > https://cgit.freedesktop.org/drm-intel/ I pulled from there and rebuild my kernel. Rebooting and everything is fine. Looks much better!!! > https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next-queued=d2a84a76a3b970fa32e6eda3d85e7782f831379e Do you want me to test this patch only on top of master? (If it applies!!!) All the best Norbert -- PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info GPG: 0x860CDC13fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
btrfs BUGs
Dear all, (please Cc) since 4.6.0-rc I see regular BUG in btrfs_destroy_inode: Variant 1: [47093.775175] [ cut here ] [47093.775187] WARNING: CPU: 3 PID: 19909 at fs/btrfs/inode.c:9261 btrfs_destroy_inode+0xad/0x224 [47093.775189] Modules linked in: hmac drbg ansi_cprng ctr ccm uas usbhid acpi_call(O) vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) binfmt_misc x86_pkg_temp_thermal intel_powerclamp kvm irqbypass crc32c_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd iwlmvm mac80211 iwlwifi cfg80211 acpi_als kfifo_buf industrialio sony_laptop ipv6 autofs4 [47093.775226] CPU: 3 PID: 19909 Comm: aptitude Tainted: GW O 4.6.0-rc2 #161 [47093.775229] Hardware name: Sony Corporation SVP1322A1J/VAIO, BIOS R2092V7 04/24/2015 [47093.775231] 8800209afd10 8129d414 [47093.775236] 8800209afd50 8104233d 242d209afcc8 [47093.775241] 88003b7605c0 88003b760640 8802153f2000 818367a0 [47093.775245] Call Trace: [47093.775251] [] dump_stack+0x4d/0x63 [47093.775257] [] __warn+0xb8/0xd3 [47093.775261] [] warn_slowpath_null+0x18/0x1a [47093.775265] [] btrfs_destroy_inode+0xad/0x224 [47093.775270] [] destroy_inode+0x38/0x50 [47093.775273] [] evict+0x166/0x16d [47093.775277] [] iput+0x160/0x169 [47093.775280] [] __dentry_kill+0xee/0x157 [47093.775284] [] dput+0x1aa/0x1cf [47093.775288] [] SYSC_renameat2+0x304/0x3c9 [47093.775293] [] SyS_rename+0x19/0x1b [47093.775299] [] entry_SYSCALL_64_fastpath+0x17/0x93 [47093.775302] ---[ end trace f6f5069f352abf67 ]--- Variant 2: [47103.281321] [ cut here ] [47103.281329] WARNING: CPU: 2 PID: 19909 at fs/btrfs/inode.c:9261 btrfs_destroy_inode+0xad/0x224 [47103.281330] Modules linked in: hmac drbg ansi_cprng ctr ccm uas usbhid acpi_call(O) vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) binfmt_misc x86_pkg_temp_thermal intel_powerclamp kvm irqbypass crc32c_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd iwlmvm mac80211 iwlwifi cfg80211 acpi_als kfifo_buf industrialio sony_laptop ipv6 autofs4 [47103.281349] CPU: 2 PID: 19909 Comm: aptitude Tainted: GW O 4.6.0-rc2 #161 [47103.281350] Hardware name: Sony Corporation SVP1322A1J/VAIO, BIOS R2092V7 04/24/2015 [47103.281352] 8800209afdc8 8129d414 [47103.281354] 8800209afe08 8104233d 242d209afd80 [47103.281356] 8800262e0db0 8800262e0e30 8802153f2000 818367a0 [47103.281358] Call Trace: [47103.281362] [] dump_stack+0x4d/0x63 [47103.281365] [] __warn+0xb8/0xd3 [47103.281366] [] warn_slowpath_null+0x18/0x1a [47103.281368] [] btrfs_destroy_inode+0xad/0x224 [47103.281371] [] destroy_inode+0x38/0x50 [47103.281372] [] evict+0x166/0x16d [47103.281374] [] iput+0x160/0x169 [47103.281377] [] do_unlinkat+0x116/0x1a6 [47103.281379] [] SyS_unlink+0x11/0x13 [47103.281382] [] entry_SYSCALL_64_fastpath+0x17/0x93 [47103.281384] ---[ end trace f6f5069f352abf68 ]--- Variant 3 [47201.848251] [ cut here ] [47201.848258] WARNING: CPU: 1 PID: 19909 at fs/btrfs/inode.c:9261 btrfs_destroy_inode+0xad/0x224 [47201.848259] Modules linked in: hmac drbg ansi_cprng ctr ccm uas usbhid acpi_call(O) vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) binfmt_misc x86_pkg_temp_thermal intel_powerclamp kvm irqbypass crc32c_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd iwlmvm mac80211 iwlwifi cfg80211 acpi_als kfifo_buf industrialio sony_laptop ipv6 autofs4 [47201.848277] CPU: 1 PID: 19909 Comm: aptitude Tainted: GW O 4.6.0-rc2 #161 [47201.848278] Hardware name: Sony Corporation SVP1322A1J/VAIO, BIOS R2092V7 04/24/2015 [47201.848279] 8800209afd28 8129d414 [47201.848281] 8800209afd68 8104233d 242d209afce0 [47201.848283] 880132c631c8 880132c63248 8802153f2000 818367a0 [47201.848284] Call Trace: [47201.848288] [] dump_stack+0x4d/0x63 [47201.848291] [] __warn+0xb8/0xd3 [47201.848292] [] warn_slowpath_null+0x18/0x1a [47201.848294] [] btrfs_destroy_inode+0xad/0x224 [47201.848296] [] destroy_inode+0x38/0x50 [47201.848298] [] evict+0x166/0x16d [47201.848299] [] iput+0x160/0x169 [47201.848301] [] __dentry_kill+0xee/0x157 [47201.848302] [] dput+0x1aa/0x1cf [47201.848304] [] __fput+0x15f/0x173 [47201.848306] [] fput+0x9/0xb [47201.848307] [] task_work_run+0x62/0x78 [47201.848309] [] prepare_exit_to_usermode+0x81/0x9f [47201.848310] [] syscall_return_slowpath+0x6e/0x73 [47201.848313] [] entry_SYSCALL_64_fastpath+0x91/0x93 [47201.848315] ---[ end trace f6f5069f352abf69 ]--- This is home-compiled kernel 4.6.0-rc2 on Debian/sid All the best (please Cc) Norbert PREINING
btrfs BUGs
Dear all, (please Cc) since 4.6.0-rc I see regular BUG in btrfs_destroy_inode: Variant 1: [47093.775175] [ cut here ] [47093.775187] WARNING: CPU: 3 PID: 19909 at fs/btrfs/inode.c:9261 btrfs_destroy_inode+0xad/0x224 [47093.775189] Modules linked in: hmac drbg ansi_cprng ctr ccm uas usbhid acpi_call(O) vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) binfmt_misc x86_pkg_temp_thermal intel_powerclamp kvm irqbypass crc32c_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd iwlmvm mac80211 iwlwifi cfg80211 acpi_als kfifo_buf industrialio sony_laptop ipv6 autofs4 [47093.775226] CPU: 3 PID: 19909 Comm: aptitude Tainted: GW O 4.6.0-rc2 #161 [47093.775229] Hardware name: Sony Corporation SVP1322A1J/VAIO, BIOS R2092V7 04/24/2015 [47093.775231] 8800209afd10 8129d414 [47093.775236] 8800209afd50 8104233d 242d209afcc8 [47093.775241] 88003b7605c0 88003b760640 8802153f2000 818367a0 [47093.775245] Call Trace: [47093.775251] [] dump_stack+0x4d/0x63 [47093.775257] [] __warn+0xb8/0xd3 [47093.775261] [] warn_slowpath_null+0x18/0x1a [47093.775265] [] btrfs_destroy_inode+0xad/0x224 [47093.775270] [] destroy_inode+0x38/0x50 [47093.775273] [] evict+0x166/0x16d [47093.775277] [] iput+0x160/0x169 [47093.775280] [] __dentry_kill+0xee/0x157 [47093.775284] [] dput+0x1aa/0x1cf [47093.775288] [] SYSC_renameat2+0x304/0x3c9 [47093.775293] [] SyS_rename+0x19/0x1b [47093.775299] [] entry_SYSCALL_64_fastpath+0x17/0x93 [47093.775302] ---[ end trace f6f5069f352abf67 ]--- Variant 2: [47103.281321] [ cut here ] [47103.281329] WARNING: CPU: 2 PID: 19909 at fs/btrfs/inode.c:9261 btrfs_destroy_inode+0xad/0x224 [47103.281330] Modules linked in: hmac drbg ansi_cprng ctr ccm uas usbhid acpi_call(O) vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) binfmt_misc x86_pkg_temp_thermal intel_powerclamp kvm irqbypass crc32c_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd iwlmvm mac80211 iwlwifi cfg80211 acpi_als kfifo_buf industrialio sony_laptop ipv6 autofs4 [47103.281349] CPU: 2 PID: 19909 Comm: aptitude Tainted: GW O 4.6.0-rc2 #161 [47103.281350] Hardware name: Sony Corporation SVP1322A1J/VAIO, BIOS R2092V7 04/24/2015 [47103.281352] 8800209afdc8 8129d414 [47103.281354] 8800209afe08 8104233d 242d209afd80 [47103.281356] 8800262e0db0 8800262e0e30 8802153f2000 818367a0 [47103.281358] Call Trace: [47103.281362] [] dump_stack+0x4d/0x63 [47103.281365] [] __warn+0xb8/0xd3 [47103.281366] [] warn_slowpath_null+0x18/0x1a [47103.281368] [] btrfs_destroy_inode+0xad/0x224 [47103.281371] [] destroy_inode+0x38/0x50 [47103.281372] [] evict+0x166/0x16d [47103.281374] [] iput+0x160/0x169 [47103.281377] [] do_unlinkat+0x116/0x1a6 [47103.281379] [] SyS_unlink+0x11/0x13 [47103.281382] [] entry_SYSCALL_64_fastpath+0x17/0x93 [47103.281384] ---[ end trace f6f5069f352abf68 ]--- Variant 3 [47201.848251] [ cut here ] [47201.848258] WARNING: CPU: 1 PID: 19909 at fs/btrfs/inode.c:9261 btrfs_destroy_inode+0xad/0x224 [47201.848259] Modules linked in: hmac drbg ansi_cprng ctr ccm uas usbhid acpi_call(O) vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) binfmt_misc x86_pkg_temp_thermal intel_powerclamp kvm irqbypass crc32c_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd iwlmvm mac80211 iwlwifi cfg80211 acpi_als kfifo_buf industrialio sony_laptop ipv6 autofs4 [47201.848277] CPU: 1 PID: 19909 Comm: aptitude Tainted: GW O 4.6.0-rc2 #161 [47201.848278] Hardware name: Sony Corporation SVP1322A1J/VAIO, BIOS R2092V7 04/24/2015 [47201.848279] 8800209afd28 8129d414 [47201.848281] 8800209afd68 8104233d 242d209afce0 [47201.848283] 880132c631c8 880132c63248 8802153f2000 818367a0 [47201.848284] Call Trace: [47201.848288] [] dump_stack+0x4d/0x63 [47201.848291] [] __warn+0xb8/0xd3 [47201.848292] [] warn_slowpath_null+0x18/0x1a [47201.848294] [] btrfs_destroy_inode+0xad/0x224 [47201.848296] [] destroy_inode+0x38/0x50 [47201.848298] [] evict+0x166/0x16d [47201.848299] [] iput+0x160/0x169 [47201.848301] [] __dentry_kill+0xee/0x157 [47201.848302] [] dput+0x1aa/0x1cf [47201.848304] [] __fput+0x15f/0x173 [47201.848306] [] fput+0x9/0xb [47201.848307] [] task_work_run+0x62/0x78 [47201.848309] [] prepare_exit_to_usermode+0x81/0x9f [47201.848310] [] syscall_return_slowpath+0x6e/0x73 [47201.848313] [] entry_SYSCALL_64_fastpath+0x91/0x93 [47201.848315] ---[ end trace f6f5069f352abf69 ]--- This is home-compiled kernel 4.6.0-rc2 on Debian/sid All the best (please Cc) Norbert PREINING
Re: 4.4-rc, intel dri i915, regular hangs and corruptions
Hi Chris, thanks for your answer. I will try the latest intel driver, but in case it helps or you get an idea, I found that it has to do with the Antialiasing settings: I am using an OTF font (Lucida Sans OT Regular) with cinnamon. Sometimes when I wake the computer up from suspend to ram the fonts are gone. *BUT*: Switching from (in Font Settings of Cinnamon settings) Antialiasing: Grayscale *away* fixes the problem. WIth Antialiasing: Rgba or None the fonts remain stable as far as I can see, while with Grayscale they are disappearing. In fact I can turn the fonts off and on without a problem by simply swithcing the antialiasing. Maybe this rings a bell at someone. Thanks Norbert (please Cc) > On 17 December 2015 at 18:34, Norbert Preining wrote: > > * font corruption > > sometime sets of glyphs, or practically all glyphs disappear > > related probably to bug > > https://bugs.freedesktop.org/show_bug.cgi?id=55500 > > I have sent some info there already, without response > > > > Currently my font displays some kind of strange symbols instead of > > an m ... looks a bit like a Kanji. > > I remember a similar bug around 2.99.917 but that tag is over a year > old now and there have been many bug fixes since. You'll need to > verify you can still reproduce your issue with the latest from > git://anongit.freedesktop.org/xorg/driver/xf86-video-intel and if so > do a bisect from the previous working kernel or xf86-video-intel to > identify the problematic commit. PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 4.4-rc, intel dri i915, regular hangs and corruptions
Hi Chris, thanks for your answer. I will try the latest intel driver, but in case it helps or you get an idea, I found that it has to do with the Antialiasing settings: I am using an OTF font (Lucida Sans OT Regular) with cinnamon. Sometimes when I wake the computer up from suspend to ram the fonts are gone. *BUT*: Switching from (in Font Settings of Cinnamon settings) Antialiasing: Grayscale *away* fixes the problem. WIth Antialiasing: Rgba or None the fonts remain stable as far as I can see, while with Grayscale they are disappearing. In fact I can turn the fonts off and on without a problem by simply swithcing the antialiasing. Maybe this rings a bell at someone. Thanks Norbert (please Cc) > On 17 December 2015 at 18:34, Norbert Preining <prein...@logic.at> wrote: > > * font corruption > > sometime sets of glyphs, or practically all glyphs disappear > > related probably to bug > > https://bugs.freedesktop.org/show_bug.cgi?id=55500 > > I have sent some info there already, without response > > > > Currently my font displays some kind of strange symbols instead of > > an m ... looks a bit like a Kanji. > > I remember a similar bug around 2.99.917 but that tag is over a year > old now and there have been many bug fixes since. You'll need to > verify you can still reproduce your issue with the latest from > git://anongit.freedesktop.org/xorg/driver/xf86-video-intel and if so > do a bisect from the previous working kernel or xf86-video-intel to > identify the problematic commit. PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
4.4-rc, intel dri i915, regular hangs and corruptions
Dear all, since 4.4-rc (at least rc2 it was the first I tested), the Intel DRI is in very broken state. Hardware: Sony VAIO Pro 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Sony Corporation Device 90b6 Flags: bus master, fast devsel, latency 0, IRQ 40 Memory at f5c0 (64-bit, non-prefetchable) [size=4M] Memory at e000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] Expansion ROM at [disabled] 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 Symptoms: * font corruption sometime sets of glyphs, or practically all glyphs disappear related probably to bug https://bugs.freedesktop.org/show_bug.cgi?id=55500 I have sent some info there already, without response Currently my font displays some kind of strange symbols instead of an m ... looks a bit like a Kanji. * drm/i915 hang: GPU HANG: ecode 7:0:0x86d2bff9, in cinnamon [9300], reason: Ring hung, action: reset opened a new bug as advised https://bugs.freedesktop.org/show_bug.cgi?id=93279 several other hangs like that, reported only one * intelfb is dead switching to the console often leaves a black console Most of the time this happens after a suspend to ram and wake up, but not always. Let me know if there is anything else one might want to know Thanks Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
4.4-rc, intel dri i915, regular hangs and corruptions
Dear all, since 4.4-rc (at least rc2 it was the first I tested), the Intel DRI is in very broken state. Hardware: Sony VAIO Pro 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Sony Corporation Device 90b6 Flags: bus master, fast devsel, latency 0, IRQ 40 Memory at f5c0 (64-bit, non-prefetchable) [size=4M] Memory at e000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] Expansion ROM at [disabled] 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 Symptoms: * font corruption sometime sets of glyphs, or practically all glyphs disappear related probably to bug https://bugs.freedesktop.org/show_bug.cgi?id=55500 I have sent some info there already, without response Currently my font displays some kind of strange symbols instead of an m ... looks a bit like a Kanji. * drm/i915 hang: GPU HANG: ecode 7:0:0x86d2bff9, in cinnamon [9300], reason: Ring hung, action: reset opened a new bug as advised https://bugs.freedesktop.org/show_bug.cgi?id=93279 several other hangs like that, reported only one * intelfb is dead switching to the console often leaves a black console Most of the time this happens after a suspend to ram and wake up, but not always. Let me know if there is anything else one might want to know Thanks Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: occasional kernel hang on shutdown - kernel/cgroup_pids.c
Hi Tejun, > Patches just got merged into mainline. Please let me know if the > current git master doesn't fix the issue. Seems to have worked - I don't see the kernel hangs anymore. What remains are problems with DRI/DRM, but I will report separately. Thanks a lot Norbert ---- PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: occasional kernel hang on shutdown - kernel/cgroup_pids.c
Hi Tejun, > Patches just got merged into mainline. Please let me know if the > current git master doesn't fix the issue. Seems to have worked - I don't see the kernel hangs anymore. What remains are problems with DRI/DRM, but I will report separately. Thanks a lot Norbert ---- PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: occasional kernel hang on shutdown - kernel/cgroup_pids.c
Hi Jeff, > I am seeing this too but I think its related to Centos 7 not the build. Here I am running: Debian sid gcc (Debian 5.3.1-2) 5.3.1 20151206 > > WARNING: CPU: 1 PID: 14 at kernel/cgroup_pids.c:97 > > pids_cancel.constrprop.8+0x2a > > Modules linked in: > > ... > > CPU: 1 PID: 14 Comm: ksoftirqd/1 Tainted: G O 4.4.0-rc3+ > > Hardware name: Sony Corporation SVP1322A1J/VAIO, BIOS R2092V7 04/24/2015 > > ... Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
occasional kernel hang on shutdown - kernel/cgroup_pids.c
Dear all (please Cc) running 4.4-rc4 (written as rc3+ but only the tag commit is missing), but I think also earlier in the rc releases, I occasionally see hangs on shutdown. Nothing works anymore, but this time at least there was some output on the console. Manually copied from screen: WARNING: CPU: 1 PID: 14 at kernel/cgroup_pids.c:97 pids_cancel.constrprop.8+0x2a Modules linked in: ... CPU: 1 PID: 14 Comm: ksoftirqd/1 Tainted: G O 4.4.0-rc3+ Hardware name: Sony Corporation SVP1322A1J/VAIO, BIOS R2092V7 04/24/2015 ... Does that help in any way? All the best Norbert (please Cc) PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
occasional kernel hang on shutdown - kernel/cgroup_pids.c
Dear all (please Cc) running 4.4-rc4 (written as rc3+ but only the tag commit is missing), but I think also earlier in the rc releases, I occasionally see hangs on shutdown. Nothing works anymore, but this time at least there was some output on the console. Manually copied from screen: WARNING: CPU: 1 PID: 14 at kernel/cgroup_pids.c:97 pids_cancel.constrprop.8+0x2a Modules linked in: ... CPU: 1 PID: 14 Comm: ksoftirqd/1 Tainted: G O 4.4.0-rc3+ Hardware name: Sony Corporation SVP1322A1J/VAIO, BIOS R2092V7 04/24/2015 ... Does that help in any way? All the best Norbert (please Cc) PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: occasional kernel hang on shutdown - kernel/cgroup_pids.c
Hi Jeff, > I am seeing this too but I think its related to Centos 7 not the build. Here I am running: Debian sid gcc (Debian 5.3.1-2) 5.3.1 20151206 > > WARNING: CPU: 1 PID: 14 at kernel/cgroup_pids.c:97 > > pids_cancel.constrprop.8+0x2a > > Modules linked in: > > ... > > CPU: 1 PID: 14 Comm: ksoftirqd/1 Tainted: G O 4.4.0-rc3+ > > Hardware name: Sony Corporation SVP1322A1J/VAIO, BIOS R2092V7 04/24/2015 > > ... Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Early test: hangs in mm/compact.c w. Linus's 12d7aacab56e9ef185c
Hi Vlastimil, hi all, On Sun, 09 Nov 2014, Vlastimil Babka wrote: > I don't want to send untested fix, and wasn't able to reproduce the bug > myself. I think Norbert could do it rather quickly so I hope he can tell > us soon. Sorry, weekend means I am away from my laptop for extended times, and I wanted to give it a bit of stress testing. No problems till now, no hangs, all working as expected with your latest patch. Thanks a lot Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Early test: hangs in mm/compact.c w. Linus's 12d7aacab56e9ef185c
Hi Vlastimil, hi all, On Sun, 09 Nov 2014, Vlastimil Babka wrote: I don't want to send untested fix, and wasn't able to reproduce the bug myself. I think Norbert could do it rather quickly so I hope he can tell us soon. Sorry, weekend means I am away from my laptop for extended times, and I wanted to give it a bit of stress testing. No problems till now, no hangs, all working as expected with your latest patch. Thanks a lot Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: khugepaged / firefox going wild in 3.18-rc
Hi Vlastimil, On Fri, 07 Nov 2014, Vlastimil Babka wrote: > Great, that's good news if I understand correctly, but ... no "but ..." > I suggested the commit to you for revert 1 day ago, and you say you > can't reproduce it for 2 days already? That's a bit suspicious. Did No, you suggested it yesterday during the day, and here in Japan the next day is already over, so my feeling is two days ;-) So all fine ;-) > I'll prepare a debugging patch and send with instructions. Meanwhile > you could send the /proc/zoneinfo contents? :) When? Running which kernel? Anyway, with the current kernel (reverted commit as before) I get the attached zoneinfo. Thanks, and waiting for your patches ;-) Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 Node 0, zone DMA pages free 3974 min 66 low 82 high 99 scanned 0 spanned 4095 present 3996 managed 3974 nr_free_pages 3974 nr_alloc_batch 17 nr_inactive_anon 0 nr_active_anon 0 nr_inactive_file 0 nr_active_file 0 nr_unevictable 0 nr_mlock 0 nr_anon_pages 0 nr_mapped0 nr_file_pages 0 nr_dirty 0 nr_writeback 0 nr_slab_reclaimable 0 nr_slab_unreclaimable 0 nr_page_table_pages 0 nr_kernel_stack 0 nr_unstable 0 nr_bounce0 nr_vmscan_write 0 nr_vmscan_immediate_reclaim 0 nr_writeback_temp 0 nr_isolated_anon 0 nr_isolated_file 0 nr_shmem 0 nr_dirtied 0 nr_written 0 nr_pages_scanned 0 workingset_refault 0 workingset_activate 0 workingset_nodereclaim 0 nr_anon_transparent_hugepages 0 nr_free_cma 0 protection: (0, 3399, 7878, 7878) pagesets cpu: 0 count: 0 high: 0 batch: 1 vm stats threshold: 6 cpu: 1 count: 0 high: 0 batch: 1 vm stats threshold: 6 cpu: 2 count: 0 high: 0 batch: 1 vm stats threshold: 6 cpu: 3 count: 0 high: 0 batch: 1 vm stats threshold: 6 all_unreclaimable: 1 start_pfn: 1 inactive_ratio:1 Node 0, zoneDMA32 pages free 557017 min 14552 low 18190 high 21828 scanned 0 spanned 1044480 present 889801 managed 871049 nr_free_pages 557017 nr_alloc_batch 3572 nr_inactive_anon 12444 nr_active_anon 67252 nr_inactive_file 86719 nr_active_file 125886 nr_unevictable 4 nr_mlock 4 nr_anon_pages 67107 nr_mapped22262 nr_file_pages 225198 nr_dirty 20 nr_writeback 0 nr_slab_reclaimable 11794 nr_slab_unreclaimable 5026 nr_page_table_pages 2369 nr_kernel_stack 226 nr_unstable 0 nr_bounce0 nr_vmscan_write 0 nr_vmscan_immediate_reclaim 0 nr_writeback_temp 0 nr_isolated_anon 0 nr_isolated_file 0 nr_shmem 12593 nr_dirtied 224825 nr_written 214052 nr_pages_scanned 0 workingset_refault 0 workingset_activate 0 workingset_nodereclaim 0 nr_anon_transparent_hugepages 28 nr_free_cma 0 protection: (0, 0, 4478, 4478) pagesets cpu: 0 count: 159 high: 186 batch: 31 vm stats threshold: 36 cpu: 1 count: 145 high: 186 batch: 31 vm stats threshold: 36 cpu: 2 count: 99 high: 186 batch: 31 vm stats threshold: 36 cpu: 3 count: 65 high: 186 batch: 31 vm stats threshold: 36 all_unreclaimable: 0 start_pfn: 4096 inactive_ratio:5 Node 0, zone Normal pages free 712051 min 19172 low 23965 high 28758 scanned 0 spanned 1179136 present 1179136 managed 1146604 nr_free_pages 712051 nr_alloc_batch 1771 nr_inactive_anon 11186 nr_active_anon 96996 nr_inactive_file 113106 nr_active_file 178825 nr_unevictable 8 nr_mlock 8 nr_anon_pages 96917 nr_mapped31145 nr_file_pages 303206 nr_dirty 13 nr_writeback 0 nr_slab_reclaimable 13001 nr_slab_unreclaimable 5053 nr_page_table_pages 3211 nr_kernel_stack 207 nr_unstable 0 nr_bounce0 nr_vmscan_write 0 nr_vmscan_immediate_reclaim 0 nr_writeback_temp 0 nr_isolated_anon 0 nr_isolated_file 0 nr_shmem 11275 nr_dirtied 3
Re: khugepaged / firefox going wild in 3.18-rc
Hi Vlastimil, On Thu, 06 Nov 2014, Vlastimil Babka wrote: > OK, one possibility is to do (it should apply cleanly) > git revert e14c720efdd73c6d69cd8d07fa894bcd11fe1973 I am running with this reverted now, and I cannot reproduce the khugepage going overboard anymore. I tried hard since 2 days now, no chance to reproduce. Before firefox or shotwell went into boom mode, but not now. (For now!) > > Again, as I mentioned, I don't have /proc/pid/stack for any "pid", is > > this depending on some specific kerenl option? > > Ah I missed that. Should be CONFIG_STACKTRACE to enable that. If you want, I can compile a "default" kernel without the above commit reverted, and turn on STACKTRACE (I have turned it one for *all* future kernels I compile ;-) I also didn't try the patch you send me, just the revert from above. Please let me know which other experiments you want to see. Thanks Norbert ---- PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: khugepaged / firefox going wild in 3.18-rc
Hi Vlastimil, On Thu, 06 Nov 2014, Vlastimil Babka wrote: OK, one possibility is to do (it should apply cleanly) git revert e14c720efdd73c6d69cd8d07fa894bcd11fe1973 I am running with this reverted now, and I cannot reproduce the khugepage going overboard anymore. I tried hard since 2 days now, no chance to reproduce. Before firefox or shotwell went into boom mode, but not now. (For now!) Again, as I mentioned, I don't have /proc/pid/stack for any pid, is this depending on some specific kerenl option? Ah I missed that. Should be CONFIG_STACKTRACE to enable that. If you want, I can compile a default kernel without the above commit reverted, and turn on STACKTRACE (I have turned it one for *all* future kernels I compile ;-) I also didn't try the patch you send me, just the revert from above. Please let me know which other experiments you want to see. Thanks Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: khugepaged / firefox going wild in 3.18-rc
Hi Vlastimil, On Fri, 07 Nov 2014, Vlastimil Babka wrote: Great, that's good news if I understand correctly, but ... no but ... I suggested the commit to you for revert 1 day ago, and you say you can't reproduce it for 2 days already? That's a bit suspicious. Did No, you suggested it yesterday during the day, and here in Japan the next day is already over, so my feeling is two days ;-) So all fine ;-) I'll prepare a debugging patch and send with instructions. Meanwhile you could send the /proc/zoneinfo contents? :) When? Running which kernel? Anyway, with the current kernel (reverted commit as before) I get the attached zoneinfo. Thanks, and waiting for your patches ;-) Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 Node 0, zone DMA pages free 3974 min 66 low 82 high 99 scanned 0 spanned 4095 present 3996 managed 3974 nr_free_pages 3974 nr_alloc_batch 17 nr_inactive_anon 0 nr_active_anon 0 nr_inactive_file 0 nr_active_file 0 nr_unevictable 0 nr_mlock 0 nr_anon_pages 0 nr_mapped0 nr_file_pages 0 nr_dirty 0 nr_writeback 0 nr_slab_reclaimable 0 nr_slab_unreclaimable 0 nr_page_table_pages 0 nr_kernel_stack 0 nr_unstable 0 nr_bounce0 nr_vmscan_write 0 nr_vmscan_immediate_reclaim 0 nr_writeback_temp 0 nr_isolated_anon 0 nr_isolated_file 0 nr_shmem 0 nr_dirtied 0 nr_written 0 nr_pages_scanned 0 workingset_refault 0 workingset_activate 0 workingset_nodereclaim 0 nr_anon_transparent_hugepages 0 nr_free_cma 0 protection: (0, 3399, 7878, 7878) pagesets cpu: 0 count: 0 high: 0 batch: 1 vm stats threshold: 6 cpu: 1 count: 0 high: 0 batch: 1 vm stats threshold: 6 cpu: 2 count: 0 high: 0 batch: 1 vm stats threshold: 6 cpu: 3 count: 0 high: 0 batch: 1 vm stats threshold: 6 all_unreclaimable: 1 start_pfn: 1 inactive_ratio:1 Node 0, zoneDMA32 pages free 557017 min 14552 low 18190 high 21828 scanned 0 spanned 1044480 present 889801 managed 871049 nr_free_pages 557017 nr_alloc_batch 3572 nr_inactive_anon 12444 nr_active_anon 67252 nr_inactive_file 86719 nr_active_file 125886 nr_unevictable 4 nr_mlock 4 nr_anon_pages 67107 nr_mapped22262 nr_file_pages 225198 nr_dirty 20 nr_writeback 0 nr_slab_reclaimable 11794 nr_slab_unreclaimable 5026 nr_page_table_pages 2369 nr_kernel_stack 226 nr_unstable 0 nr_bounce0 nr_vmscan_write 0 nr_vmscan_immediate_reclaim 0 nr_writeback_temp 0 nr_isolated_anon 0 nr_isolated_file 0 nr_shmem 12593 nr_dirtied 224825 nr_written 214052 nr_pages_scanned 0 workingset_refault 0 workingset_activate 0 workingset_nodereclaim 0 nr_anon_transparent_hugepages 28 nr_free_cma 0 protection: (0, 0, 4478, 4478) pagesets cpu: 0 count: 159 high: 186 batch: 31 vm stats threshold: 36 cpu: 1 count: 145 high: 186 batch: 31 vm stats threshold: 36 cpu: 2 count: 99 high: 186 batch: 31 vm stats threshold: 36 cpu: 3 count: 65 high: 186 batch: 31 vm stats threshold: 36 all_unreclaimable: 0 start_pfn: 4096 inactive_ratio:5 Node 0, zone Normal pages free 712051 min 19172 low 23965 high 28758 scanned 0 spanned 1179136 present 1179136 managed 1146604 nr_free_pages 712051 nr_alloc_batch 1771 nr_inactive_anon 11186 nr_active_anon 96996 nr_inactive_file 113106 nr_active_file 178825 nr_unevictable 8 nr_mlock 8 nr_anon_pages 96917 nr_mapped31145 nr_file_pages 303206 nr_dirty 13 nr_writeback 0 nr_slab_reclaimable 13001 nr_slab_unreclaimable 5053 nr_page_table_pages 3211 nr_kernel_stack 207 nr_unstable 0 nr_bounce0 nr_vmscan_write 0 nr_vmscan_immediate_reclaim 0 nr_writeback_temp 0 nr_isolated_anon 0 nr_isolated_file 0 nr_shmem 11275 nr_dirtied 327684 nr_written 314671
Re: khugepaged / firefox going wild in 3.18-rc
Hi Vlastimil thanks for your answer. In the meantime I have tried rc3, too, with the same effects. Interestingly, once it goes into a bad state, every future approach does the same. I started shotwell (photo organizer) and it went into the same state (khugepaged / shotwell each using about 100% of CPu time). On Thu, 06 Nov 2014, Vlastimil Babka wrote: > Could be that another task holds the mmap_sem during THP allocation attempt on > its own page fault, and compaction goes in some kind of infinite loop. There > are My feeling somehow is about the plugin-container in firefox ... (flashplayer or something similar, but I might be wrong!). With shotwell, I have no idea why. > I suggested testing a commit revert in one thread, and a possible fix in the > other. If you can reproduce this well, that would be very useful. Which commit are you talking about? I can easily revert some/all of what you want and do test runs. > khugepaged using CPU also points to either the address space scanning, or > compaction going wrong. Since 8b1645685ac it shouldn't hold mmap_sem during > compaction, but that still leaves page faulters to possibly hold it. So, do you mean I should try reverting 8b1645685ac? > So yeah we would need the stacks of processes that do hog the CPU's, not those > that sleep. As David suggested, a /proc/pid/stack could work. Also can you > please provide /proc/zoneinfo ? Again, as I mentioned, I don't have /proc/pid/stack for any "pid", is this depending on some specific kerenl option? /proc/zoneinfo I have and can send you the next time. Thanks a lot and all the best Norbert ---- PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: khugepaged / firefox going wild in 3.18-rc
Hi Vlastimil thanks for your answer. In the meantime I have tried rc3, too, with the same effects. Interestingly, once it goes into a bad state, every future approach does the same. I started shotwell (photo organizer) and it went into the same state (khugepaged / shotwell each using about 100% of CPu time). On Thu, 06 Nov 2014, Vlastimil Babka wrote: Could be that another task holds the mmap_sem during THP allocation attempt on its own page fault, and compaction goes in some kind of infinite loop. There are My feeling somehow is about the plugin-container in firefox ... (flashplayer or something similar, but I might be wrong!). With shotwell, I have no idea why. I suggested testing a commit revert in one thread, and a possible fix in the other. If you can reproduce this well, that would be very useful. Which commit are you talking about? I can easily revert some/all of what you want and do test runs. khugepaged using CPU also points to either the address space scanning, or compaction going wrong. Since 8b1645685ac it shouldn't hold mmap_sem during compaction, but that still leaves page faulters to possibly hold it. So, do you mean I should try reverting 8b1645685ac? So yeah we would need the stacks of processes that do hog the CPU's, not those that sleep. As David suggested, a /proc/pid/stack could work. Also can you please provide /proc/zoneinfo ? Again, as I mentioned, I don't have /proc/pid/stack for any pid, is this depending on some specific kerenl option? /proc/zoneinfo I have and can send you the next time. Thanks a lot and all the best Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: khugepaged / firefox going wild in 3.18-rc
Hi David, one more thing, attached dmesg output with some page faults, maybe this is connected? On Wed, 05 Nov 2014, Norbert Preining wrote: > Hi David, > > thanks for your answer. > > On Tue, 04 Nov 2014, David Rientjes wrote: > > If you have the ability to kill your X session, then you presumably are > > able to capture /proc/pid/stack for these pids to see where it is busy. > > Yes I can do that, I can even reproduce it on *every* start of iceweasel > after it happened the first time. > > There is no /proc/PID/stack, though . > > > It might also be helpful to see how the grep ^thp_ /proc/vmstat and > > grep ^compact_ /proc/vmstat counters change over time. > > I captured that over timne, as well as the contents of > /proc/PID/stat > for iceweasel and khugepaged. There are some numbers steadily > increasing. > > Here is what I got: > > START > thp_fault_alloc 9092 > thp_fault_fallback 87 > thp_collapse_alloc 5003 > thp_collapse_alloc_failed 19 > thp_split 2889 > thp_zero_page_alloc 2 > thp_zero_page_alloc_failed 0 > compact_migrate_scanned 400301 > compact_free_scanned 8634053 > compact_isolated 687993 > compact_stall 567 > compact_fail 101 > compact_success 466 > > > thp_fault_alloc 9127 > thp_fault_fallback 100 > thp_collapse_alloc 5008 > thp_collapse_alloc_failed 19 > thp_split 2892 > thp_zero_page_alloc 2 > thp_zero_page_alloc_failed 0 > compact_migrate_scanned 430094 > compact_free_scanned 10444689 > compact_isolated 709843 > compact_stall 603 > compact_fail 130 > compact_success 473 > === > thp_fault_alloc 9127 > thp_fault_fallback 100 > thp_collapse_alloc 5008 > thp_collapse_alloc_failed 19 > thp_split 2892 > thp_zero_page_alloc 2 > thp_zero_page_alloc_failed 0 > compact_migrate_scanned 430094 > compact_free_scanned 10444689 > compact_isolated 709843 > compact_stall 603 > compact_fail 130 > compact_success 473 > === > thp_fault_alloc 9127 > thp_fault_fallback 100 > thp_collapse_alloc 5008 > thp_collapse_alloc_failed 19 > thp_split 2892 > thp_zero_page_alloc 2 > thp_zero_page_alloc_failed 0 > compact_migrate_scanned 430094 > compact_free_scanned 10444689 > compact_isolated 709843 > compact_stall 603 > compact_fail 130 > compact_success 473 > === > thp_fault_alloc 9127 > thp_fault_fallback 100 > thp_collapse_alloc 5008 > thp_collapse_alloc_failed 19 > thp_split 2892 > thp_zero_page_alloc 2 > thp_zero_page_alloc_failed 0 > compact_migrate_scanned 430094 > compact_free_scanned 10444689 > compact_isolated 709843 > compact_stall 603 > compact_fail 130 > compact_success 473 > === > > > /proc/PID/stat for iceweasel over some time: > 8927 (iceweasel) R 27016 26901 26901 0 -1 4204544 100479 2248 5 0 565 14849 1 > 0 20 0 47 0 38224838 1134931968 84204 18446744073709551615 139840244875264 > 139840244981188 140737356374240 140737356331656 139840166756100 0 0 4096 > 17583 18446744073709551615 0 0 17 2 0 0 1 0 0 139840247078912 139840247080712 > 139840278519808 140737356376815 140737356376825 140737356376825 > 140737356378085 0 > 8927 (iceweasel) R 27016 26901 26901 0 -1 4204544 100479 2248 5 0 565 15130 1 > 0 20 0 47 0 38224838 1134931968 84204 18446744073709551615 139840244875264 > 139840244981188 140737356374240 140737356331656 139840166756100 0 0 4096 > 17583 18446744073709551615 0 0 17 1 0 0 1 0 0 139840247078912 139840247080712 > 139840278519808 140737356376815 140737356376825 140737356376825 > 140737356378085 0 > 8927 (iceweasel) R 27016 26901 26901 0 -1 4204544 100479 2248 5 0 565 15460 1 > 0 20 0 47 0 38224838 1134931968 84204 18446744073709551615 139840244875264 > 139840244981188 140737356374240 140737356331656 139840166756100 0 0 4096 > 17583 18446744073709551615 0 0 17 1 0 0 1 0 0 139840247078912 139840247080712 > 139840278519808 140737356376815 140737356376825 140737356376825 > 140737356378085 0 > 8927 (iceweasel) R 27016 26901 26901 0 -1 4204544 100479 2248 5 0 565 15724 1 > 0 20 0 47 0 38224838 1134931968 84204 18446744073709551615 139840244875264 > 139840244981188 140737356374240 140737356331656 139840166756100 0 0 4096 > 17583 18446744073709551615 0 0 17 1 0 0 1 0 0 139840247078912 139840247080712 > 139840278519808 140737356376815 140737356376825 140737356376825 > 140737356378085 0 > > > /proc/PID/stat for khugepaged over some time: > 35 (khugepaged) R 2 0 0 0 -1 2107456 0 0 0 0 0 39779 0 0 39 19 1 0 22 0 0 > 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 > 35 (khugepaged) R 2 0 0 0 -1 2107456 0 0 0 0 0 40104 0 0 39 19 1 0 22 0 0 > 18446744073709551615 0 0 0 0 0 0 0
Re: khugepaged / firefox going wild in 3.18-rc
Hi David, thanks for your answer. On Tue, 04 Nov 2014, David Rientjes wrote: > If you have the ability to kill your X session, then you presumably are > able to capture /proc/pid/stack for these pids to see where it is busy. Yes I can do that, I can even reproduce it on *every* start of iceweasel after it happened the first time. There is no /proc/PID/stack, though . > It might also be helpful to see how the grep ^thp_ /proc/vmstat and > grep ^compact_ /proc/vmstat counters change over time. I captured that over timne, as well as the contents of /proc/PID/stat for iceweasel and khugepaged. There are some numbers steadily increasing. Here is what I got: START thp_fault_alloc 9092 thp_fault_fallback 87 thp_collapse_alloc 5003 thp_collapse_alloc_failed 19 thp_split 2889 thp_zero_page_alloc 2 thp_zero_page_alloc_failed 0 compact_migrate_scanned 400301 compact_free_scanned 8634053 compact_isolated 687993 compact_stall 567 compact_fail 101 compact_success 466 thp_fault_alloc 9127 thp_fault_fallback 100 thp_collapse_alloc 5008 thp_collapse_alloc_failed 19 thp_split 2892 thp_zero_page_alloc 2 thp_zero_page_alloc_failed 0 compact_migrate_scanned 430094 compact_free_scanned 10444689 compact_isolated 709843 compact_stall 603 compact_fail 130 compact_success 473 === thp_fault_alloc 9127 thp_fault_fallback 100 thp_collapse_alloc 5008 thp_collapse_alloc_failed 19 thp_split 2892 thp_zero_page_alloc 2 thp_zero_page_alloc_failed 0 compact_migrate_scanned 430094 compact_free_scanned 10444689 compact_isolated 709843 compact_stall 603 compact_fail 130 compact_success 473 === thp_fault_alloc 9127 thp_fault_fallback 100 thp_collapse_alloc 5008 thp_collapse_alloc_failed 19 thp_split 2892 thp_zero_page_alloc 2 thp_zero_page_alloc_failed 0 compact_migrate_scanned 430094 compact_free_scanned 10444689 compact_isolated 709843 compact_stall 603 compact_fail 130 compact_success 473 === thp_fault_alloc 9127 thp_fault_fallback 100 thp_collapse_alloc 5008 thp_collapse_alloc_failed 19 thp_split 2892 thp_zero_page_alloc 2 thp_zero_page_alloc_failed 0 compact_migrate_scanned 430094 compact_free_scanned 10444689 compact_isolated 709843 compact_stall 603 compact_fail 130 compact_success 473 === /proc/PID/stat for iceweasel over some time: 8927 (iceweasel) R 27016 26901 26901 0 -1 4204544 100479 2248 5 0 565 14849 1 0 20 0 47 0 38224838 1134931968 84204 18446744073709551615 139840244875264 139840244981188 140737356374240 140737356331656 139840166756100 0 0 4096 17583 18446744073709551615 0 0 17 2 0 0 1 0 0 139840247078912 139840247080712 139840278519808 140737356376815 140737356376825 140737356376825 140737356378085 0 8927 (iceweasel) R 27016 26901 26901 0 -1 4204544 100479 2248 5 0 565 15130 1 0 20 0 47 0 38224838 1134931968 84204 18446744073709551615 139840244875264 139840244981188 140737356374240 140737356331656 139840166756100 0 0 4096 17583 18446744073709551615 0 0 17 1 0 0 1 0 0 139840247078912 139840247080712 139840278519808 140737356376815 140737356376825 140737356376825 140737356378085 0 8927 (iceweasel) R 27016 26901 26901 0 -1 4204544 100479 2248 5 0 565 15460 1 0 20 0 47 0 38224838 1134931968 84204 18446744073709551615 139840244875264 139840244981188 140737356374240 140737356331656 139840166756100 0 0 4096 17583 18446744073709551615 0 0 17 1 0 0 1 0 0 139840247078912 139840247080712 139840278519808 140737356376815 140737356376825 140737356376825 140737356378085 0 8927 (iceweasel) R 27016 26901 26901 0 -1 4204544 100479 2248 5 0 565 15724 1 0 20 0 47 0 38224838 1134931968 84204 18446744073709551615 139840244875264 139840244981188 140737356374240 140737356331656 139840166756100 0 0 4096 17583 18446744073709551615 0 0 17 1 0 0 1 0 0 139840247078912 139840247080712 139840278519808 140737356376815 140737356376825 140737356376825 140737356378085 0 /proc/PID/stat for khugepaged over some time: 35 (khugepaged) R 2 0 0 0 -1 2107456 0 0 0 0 0 39779 0 0 39 19 1 0 22 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 0 0 0 0 0 0 0 0 0 0 0 0 0 0 35 (khugepaged) R 2 0 0 0 -1 2107456 0 0 0 0 0 40104 0 0 39 19 1 0 22 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 2 0 0 0 0 0 0 0 0 0 0 0 0 0 35 (khugepaged) R 2 0 0 0 -1 2107456 0 0 0 0 0 40516 0 0 39 19 1 0 22 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 2 0 0 0 0 0 0 0 0 0 0 0 0 0 35 (khugepaged) R 2 0 0 0 -1 2107456 0 0 0 0 0 40797 0 0 39 19 1 0 22 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Hope that helps Norbert ---- PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line "uns
khugepaged / firefox going wild in 3.18-rc
Dear all, (please Cc) since 3.18-rc started, regularly, but unpredictably, firefox (Debian iceweasel) goes completely boom to 100% CPU, and there is also a kernel task khugepaged doing the same. I need to kill firefox, or better the X session to get it back to normal. THe logs don't show any strange output top's top process: 27021 norbert 20 0 1351536 449868 88788 R 100.4 5.6 4:46.16 iceweasel 35 root 39 19 0 0 0 R 100.0 0.0 2:41.10 khugepaged Switching back to 3.17 does Not* exhibit the same behaviour. Is this a bug in Firefox/Iceweasel, or is there something luring in the kernel. All the best Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
khugepaged / firefox going wild in 3.18-rc
Dear all, (please Cc) since 3.18-rc started, regularly, but unpredictably, firefox (Debian iceweasel) goes completely boom to 100% CPU, and there is also a kernel task khugepaged doing the same. I need to kill firefox, or better the X session to get it back to normal. THe logs don't show any strange output top's top process: 27021 norbert 20 0 1351536 449868 88788 R 100.4 5.6 4:46.16 iceweasel 35 root 39 19 0 0 0 R 100.0 0.0 2:41.10 khugepaged Switching back to 3.17 does Not* exhibit the same behaviour. Is this a bug in Firefox/Iceweasel, or is there something luring in the kernel. All the best Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: khugepaged / firefox going wild in 3.18-rc
Hi David, thanks for your answer. On Tue, 04 Nov 2014, David Rientjes wrote: If you have the ability to kill your X session, then you presumably are able to capture /proc/pid/stack for these pids to see where it is busy. Yes I can do that, I can even reproduce it on *every* start of iceweasel after it happened the first time. There is no /proc/PID/stack, though . It might also be helpful to see how the grep ^thp_ /proc/vmstat and grep ^compact_ /proc/vmstat counters change over time. I captured that over timne, as well as the contents of /proc/PID/stat for iceweasel and khugepaged. There are some numbers steadily increasing. Here is what I got: START thp_fault_alloc 9092 thp_fault_fallback 87 thp_collapse_alloc 5003 thp_collapse_alloc_failed 19 thp_split 2889 thp_zero_page_alloc 2 thp_zero_page_alloc_failed 0 compact_migrate_scanned 400301 compact_free_scanned 8634053 compact_isolated 687993 compact_stall 567 compact_fail 101 compact_success 466 thp_fault_alloc 9127 thp_fault_fallback 100 thp_collapse_alloc 5008 thp_collapse_alloc_failed 19 thp_split 2892 thp_zero_page_alloc 2 thp_zero_page_alloc_failed 0 compact_migrate_scanned 430094 compact_free_scanned 10444689 compact_isolated 709843 compact_stall 603 compact_fail 130 compact_success 473 === thp_fault_alloc 9127 thp_fault_fallback 100 thp_collapse_alloc 5008 thp_collapse_alloc_failed 19 thp_split 2892 thp_zero_page_alloc 2 thp_zero_page_alloc_failed 0 compact_migrate_scanned 430094 compact_free_scanned 10444689 compact_isolated 709843 compact_stall 603 compact_fail 130 compact_success 473 === thp_fault_alloc 9127 thp_fault_fallback 100 thp_collapse_alloc 5008 thp_collapse_alloc_failed 19 thp_split 2892 thp_zero_page_alloc 2 thp_zero_page_alloc_failed 0 compact_migrate_scanned 430094 compact_free_scanned 10444689 compact_isolated 709843 compact_stall 603 compact_fail 130 compact_success 473 === thp_fault_alloc 9127 thp_fault_fallback 100 thp_collapse_alloc 5008 thp_collapse_alloc_failed 19 thp_split 2892 thp_zero_page_alloc 2 thp_zero_page_alloc_failed 0 compact_migrate_scanned 430094 compact_free_scanned 10444689 compact_isolated 709843 compact_stall 603 compact_fail 130 compact_success 473 === /proc/PID/stat for iceweasel over some time: 8927 (iceweasel) R 27016 26901 26901 0 -1 4204544 100479 2248 5 0 565 14849 1 0 20 0 47 0 38224838 1134931968 84204 18446744073709551615 139840244875264 139840244981188 140737356374240 140737356331656 139840166756100 0 0 4096 17583 18446744073709551615 0 0 17 2 0 0 1 0 0 139840247078912 139840247080712 139840278519808 140737356376815 140737356376825 140737356376825 140737356378085 0 8927 (iceweasel) R 27016 26901 26901 0 -1 4204544 100479 2248 5 0 565 15130 1 0 20 0 47 0 38224838 1134931968 84204 18446744073709551615 139840244875264 139840244981188 140737356374240 140737356331656 139840166756100 0 0 4096 17583 18446744073709551615 0 0 17 1 0 0 1 0 0 139840247078912 139840247080712 139840278519808 140737356376815 140737356376825 140737356376825 140737356378085 0 8927 (iceweasel) R 27016 26901 26901 0 -1 4204544 100479 2248 5 0 565 15460 1 0 20 0 47 0 38224838 1134931968 84204 18446744073709551615 139840244875264 139840244981188 140737356374240 140737356331656 139840166756100 0 0 4096 17583 18446744073709551615 0 0 17 1 0 0 1 0 0 139840247078912 139840247080712 139840278519808 140737356376815 140737356376825 140737356376825 140737356378085 0 8927 (iceweasel) R 27016 26901 26901 0 -1 4204544 100479 2248 5 0 565 15724 1 0 20 0 47 0 38224838 1134931968 84204 18446744073709551615 139840244875264 139840244981188 140737356374240 140737356331656 139840166756100 0 0 4096 17583 18446744073709551615 0 0 17 1 0 0 1 0 0 139840247078912 139840247080712 139840278519808 140737356376815 140737356376825 140737356376825 140737356378085 0 /proc/PID/stat for khugepaged over some time: 35 (khugepaged) R 2 0 0 0 -1 2107456 0 0 0 0 0 39779 0 0 39 19 1 0 22 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 0 0 0 0 0 0 0 0 0 0 0 0 0 0 35 (khugepaged) R 2 0 0 0 -1 2107456 0 0 0 0 0 40104 0 0 39 19 1 0 22 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 2 0 0 0 0 0 0 0 0 0 0 0 0 0 35 (khugepaged) R 2 0 0 0 -1 2107456 0 0 0 0 0 40516 0 0 39 19 1 0 22 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 2 0 0 0 0 0 0 0 0 0 0 0 0 0 35 (khugepaged) R 2 0 0 0 -1 2107456 0 0 0 0 0 40797 0 0 39 19 1 0 22 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Hope that helps Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body
Re: khugepaged / firefox going wild in 3.18-rc
Hi David, one more thing, attached dmesg output with some page faults, maybe this is connected? On Wed, 05 Nov 2014, Norbert Preining wrote: Hi David, thanks for your answer. On Tue, 04 Nov 2014, David Rientjes wrote: If you have the ability to kill your X session, then you presumably are able to capture /proc/pid/stack for these pids to see where it is busy. Yes I can do that, I can even reproduce it on *every* start of iceweasel after it happened the first time. There is no /proc/PID/stack, though . It might also be helpful to see how the grep ^thp_ /proc/vmstat and grep ^compact_ /proc/vmstat counters change over time. I captured that over timne, as well as the contents of /proc/PID/stat for iceweasel and khugepaged. There are some numbers steadily increasing. Here is what I got: START thp_fault_alloc 9092 thp_fault_fallback 87 thp_collapse_alloc 5003 thp_collapse_alloc_failed 19 thp_split 2889 thp_zero_page_alloc 2 thp_zero_page_alloc_failed 0 compact_migrate_scanned 400301 compact_free_scanned 8634053 compact_isolated 687993 compact_stall 567 compact_fail 101 compact_success 466 thp_fault_alloc 9127 thp_fault_fallback 100 thp_collapse_alloc 5008 thp_collapse_alloc_failed 19 thp_split 2892 thp_zero_page_alloc 2 thp_zero_page_alloc_failed 0 compact_migrate_scanned 430094 compact_free_scanned 10444689 compact_isolated 709843 compact_stall 603 compact_fail 130 compact_success 473 === thp_fault_alloc 9127 thp_fault_fallback 100 thp_collapse_alloc 5008 thp_collapse_alloc_failed 19 thp_split 2892 thp_zero_page_alloc 2 thp_zero_page_alloc_failed 0 compact_migrate_scanned 430094 compact_free_scanned 10444689 compact_isolated 709843 compact_stall 603 compact_fail 130 compact_success 473 === thp_fault_alloc 9127 thp_fault_fallback 100 thp_collapse_alloc 5008 thp_collapse_alloc_failed 19 thp_split 2892 thp_zero_page_alloc 2 thp_zero_page_alloc_failed 0 compact_migrate_scanned 430094 compact_free_scanned 10444689 compact_isolated 709843 compact_stall 603 compact_fail 130 compact_success 473 === thp_fault_alloc 9127 thp_fault_fallback 100 thp_collapse_alloc 5008 thp_collapse_alloc_failed 19 thp_split 2892 thp_zero_page_alloc 2 thp_zero_page_alloc_failed 0 compact_migrate_scanned 430094 compact_free_scanned 10444689 compact_isolated 709843 compact_stall 603 compact_fail 130 compact_success 473 === /proc/PID/stat for iceweasel over some time: 8927 (iceweasel) R 27016 26901 26901 0 -1 4204544 100479 2248 5 0 565 14849 1 0 20 0 47 0 38224838 1134931968 84204 18446744073709551615 139840244875264 139840244981188 140737356374240 140737356331656 139840166756100 0 0 4096 17583 18446744073709551615 0 0 17 2 0 0 1 0 0 139840247078912 139840247080712 139840278519808 140737356376815 140737356376825 140737356376825 140737356378085 0 8927 (iceweasel) R 27016 26901 26901 0 -1 4204544 100479 2248 5 0 565 15130 1 0 20 0 47 0 38224838 1134931968 84204 18446744073709551615 139840244875264 139840244981188 140737356374240 140737356331656 139840166756100 0 0 4096 17583 18446744073709551615 0 0 17 1 0 0 1 0 0 139840247078912 139840247080712 139840278519808 140737356376815 140737356376825 140737356376825 140737356378085 0 8927 (iceweasel) R 27016 26901 26901 0 -1 4204544 100479 2248 5 0 565 15460 1 0 20 0 47 0 38224838 1134931968 84204 18446744073709551615 139840244875264 139840244981188 140737356374240 140737356331656 139840166756100 0 0 4096 17583 18446744073709551615 0 0 17 1 0 0 1 0 0 139840247078912 139840247080712 139840278519808 140737356376815 140737356376825 140737356376825 140737356378085 0 8927 (iceweasel) R 27016 26901 26901 0 -1 4204544 100479 2248 5 0 565 15724 1 0 20 0 47 0 38224838 1134931968 84204 18446744073709551615 139840244875264 139840244981188 140737356374240 140737356331656 139840166756100 0 0 4096 17583 18446744073709551615 0 0 17 1 0 0 1 0 0 139840247078912 139840247080712 139840278519808 140737356376815 140737356376825 140737356376825 140737356378085 0 /proc/PID/stat for khugepaged over some time: 35 (khugepaged) R 2 0 0 0 -1 2107456 0 0 0 0 0 39779 0 0 39 19 1 0 22 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 0 0 0 0 0 0 0 0 0 0 0 0 0 0 35 (khugepaged) R 2 0 0 0 -1 2107456 0 0 0 0 0 40104 0 0 39 19 1 0 22 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 2 0 0 0 0 0 0 0 0 0 0 0 0 0 35 (khugepaged) R 2 0 0 0 -1 2107456 0 0 0 0 0 40516 0 0 39 19 1 0 22 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 2 0 0 0 0 0 0 0 0 0 0 0 0 0 35 (khugepaged) R 2 0 0 0 -1 2107456 0 0 0 0 0 40797 0 0 39 19 1 0 22 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Norbert PREINING, Norbert http://www.preining.info JAIST, Japan
Re: /dev/root changes with 3.17-rc
On Fri, 10 Oct 2014, Pavel Machek wrote: > > I am not sure whether this is a kernel bug, but: > > - booting with 3.16 I get > > / mounted on /dev/sda6 > > - booting with 3.17-rc* I get > > / mounted on /dev/root > > Where do you see the this? /proc/mounts? After loads of testing I found out what is the problem: initramfs. I normally compile my own kernel with all the drivers built-in, and no initramfs ... and in this case, without initrd, it seems that / is somehow not remounted to a proper scsi device, but remains at /dev/root. Hope that helps Norbert ---- PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/root changes with 3.17-rc
On Fri, 10 Oct 2014, Pavel Machek wrote: I am not sure whether this is a kernel bug, but: - booting with 3.16 I get / mounted on /dev/sda6 - booting with 3.17-rc* I get / mounted on /dev/root Where do you see the this? /proc/mounts? After loads of testing I found out what is the problem: initramfs. I normally compile my own kernel with all the drivers built-in, and no initramfs ... and in this case, without initrd, it seems that / is somehow not remounted to a proper scsi device, but remains at /dev/root. Hope that helps Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
/dev/root changes with 3.17-rc
Hi everyone, (please cc) I am not sure whether this is a kernel bug, but: - booting with 3.16 I get / mounted on /dev/sda6 - booting with 3.17-rc* I get / mounted on /dev/root The later case disturbs grub (cannot find root device) as there is no /dev/root. I normally to make oldconfig when compiling a new kernel, all of the above are self-compiled. Thanks Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
/dev/root changes with 3.17-rc
Hi everyone, (please cc) I am not sure whether this is a kernel bug, but: - booting with 3.16 I get / mounted on /dev/sda6 - booting with 3.17-rc* I get / mounted on /dev/root The later case disturbs grub (cannot find root device) as there is no /dev/root. I normally to make oldconfig when compiling a new kernel, all of the above are self-compiled. Thanks Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: btrfs hanging since 3.16-rc3 or so
Hi Liu, > [PATCH] Btrfs: fix abnormal long waiting in fsync > https://patchwork.kernel.org/patch/4564961/ Looks fine! And also is explains why aptitude was hanging as it does several fsync operations. I will have it running from now and report in case of problems. Thanks Norbert ---- PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: btrfs hanging since 3.16-rc3 or so
Hi Liu, [PATCH] Btrfs: fix abnormal long waiting in fsync https://patchwork.kernel.org/patch/4564961/ Looks fine! And also is explains why aptitude was hanging as it does several fsync operations. I will have it running from now and report in case of problems. Thanks Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
btrfs hanging since 3.16-rc3 or so
Dear all (please keep Cc) Since 3.16-rc3 or so I regularly get btrfs hanging in some transations. Usually during apt-get upgrade or some other large file operations (cowbuilder building of packages). The log files give me for loads of processes things like: [ 6236.746546] INFO: task aptitude:22775 blocked for more than 120 seconds. [ 6236.746547] Tainted: GW O 3.16.0-rc5 #27 [ 6236.746548] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 6236.746549] aptitudeD 8800b21a3868 0 22775 22709 0x [ 6236.746550] 88003644fd10 0082 81a15500 88003644ffd8 [ 6236.746552] 8800b21a3430 00011c00 880147da9c30 880147da9c30 [ 6236.746553] 88003644fd58 880034b3ed48 880034b3ed38 88003644fd20 [ 6236.746555] Call Trace: [ 6236.746557] [] schedule+0x64/0x66 [ 6236.746560] [] btrfs_wait_logged_extents+0xa4/0xdc [ 6236.746561] [] ? finish_wait+0x5d/0x5d [ 6236.746564] [] btrfs_sync_log+0x5ef/0x8a2 [ 6236.746567] [] btrfs_sync_file+0x21b/0x24d [ 6236.746569] [] ? btrfs_sync_file+0x21b/0x24d [ 6236.746571] [] vfs_fsync_range+0x1c/0x1e [ 6236.746574] [] SyS_msync+0x15d/0x1ea [ 6236.746575] [] system_call_fastpath+0x16/0x1b THis is aptitude, but I have all the other tasks accessing the disk hanging, too. This time, issueing a Sysrq-s for emergency syncing did the laptop out of the hang. Hardware: Sonly VAIO Pro 13 Distribution: Debian/sid self compiled kernel, config on request. Please let me know if there is anything else I can provide. Thanks a lot Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
btrfs hanging since 3.16-rc3 or so
Dear all (please keep Cc) Since 3.16-rc3 or so I regularly get btrfs hanging in some transations. Usually during apt-get upgrade or some other large file operations (cowbuilder building of packages). The log files give me for loads of processes things like: [ 6236.746546] INFO: task aptitude:22775 blocked for more than 120 seconds. [ 6236.746547] Tainted: GW O 3.16.0-rc5 #27 [ 6236.746548] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 6236.746549] aptitudeD 8800b21a3868 0 22775 22709 0x [ 6236.746550] 88003644fd10 0082 81a15500 88003644ffd8 [ 6236.746552] 8800b21a3430 00011c00 880147da9c30 880147da9c30 [ 6236.746553] 88003644fd58 880034b3ed48 880034b3ed38 88003644fd20 [ 6236.746555] Call Trace: [ 6236.746557] [81585b4a] schedule+0x64/0x66 [ 6236.746560] [811bb22e] btrfs_wait_logged_extents+0xa4/0xdc [ 6236.746561] [810635c1] ? finish_wait+0x5d/0x5d [ 6236.746564] [811d9489] btrfs_sync_log+0x5ef/0x8a2 [ 6236.746567] [811b43cf] btrfs_sync_file+0x21b/0x24d [ 6236.746569] [811b43cf] ? btrfs_sync_file+0x21b/0x24d [ 6236.746571] [8110db8a] vfs_fsync_range+0x1c/0x1e [ 6236.746574] [810d1681] SyS_msync+0x15d/0x1ea [ 6236.746575] [81588712] system_call_fastpath+0x16/0x1b THis is aptitude, but I have all the other tasks accessing the disk hanging, too. This time, issueing a Sysrq-s for emergency syncing did the laptop out of the hang. Hardware: Sonly VAIO Pro 13 Distribution: Debian/sid self compiled kernel, config on request. Please let me know if there is anything else I can provide. Thanks a lot Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTL driver for RTL8191SEvB and/or wpa-supplicant really broken at times
Hi everyone, sorry for the late reply, business trip to Tokyo. On Do, 09 Mai 2013, Larry Finger wrote: > absolutely critical, namely the PCI ID. There are at least three 10ec:8172 > I also recommend that you try either the wireless-testing git repo or the > mainline git repo. There are a lot of changes that cannot be backported. Ok, I will try. On Fr, 10 Mai 2013, Matt Causey wrote: > Seems to indicate that the access point is ignoring your probe requests. > If that is happening for your client somehow, wpa_supplicant won't work > well. :-) I rebooted the rooter, after that it worked, for one day. After that agian problems. Then I rebooted also linux and it works again. > "NecAcces" - but I'm not familiar with that vendor. Also, do you have a Aterm WR8600N http://121ware.com/aterm/ which is a NEC part, probably sold in other places under a different name. In Japan it is sold as this. > WLAN packet capture (from another host nearby on the same channel)? That > would be helpful as well. Difficult, I only have an iPhone, and a wireless repeater for the TV, and I guess both are not enough for wlan sniffing. In the meantime I have also tried wpa_supplicatn 2.0, without chagnes. In the current log there are strange things: May 15 20:36:38 tofuschnitzel kernel: [78541.678861] wlan0: send auth to 00:3a :9d:b4:54:5a (try 1/3) May 15 20:36:38 tofuschnitzel NetworkManager[16128]: (wlan0): supplican t interface state: scanning -> authenticating May 15 20:36:38 tofuschnitzel kernel: [78541.681046] wlan0: authenticated May 15 20:36:43 tofuschnitzel kernel: [78546.680713] wlan0: deauthenticating from 00:3a:9d:b4:54:5a by local choice (reason=3) May 15 20:36:43 tofuschnitzel NetworkManager[16128]: (wlan0): supplicant interface state: authenticating -> disconnected May 15 20:36:44 tofuschnitzel NetworkManager[16128]: (wlan0): supplicant interface state: disconnected -> scanning Why does it go from authenticated -> directly to deauthenticating. Uffa. Anyway, I will try some more things, esp wireless-testing. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTL driver for RTL8191SEvB and/or wpa-supplicant really broken at times
Hi everyone, sorry for the late reply, business trip to Tokyo. On Do, 09 Mai 2013, Larry Finger wrote: absolutely critical, namely the PCI ID. There are at least three 10ec:8172 I also recommend that you try either the wireless-testing git repo or the mainline git repo. There are a lot of changes that cannot be backported. Ok, I will try. On Fr, 10 Mai 2013, Matt Causey wrote: Seems to indicate that the access point is ignoring your probe requests. If that is happening for your client somehow, wpa_supplicant won't work well. :-) I rebooted the rooter, after that it worked, for one day. After that agian problems. Then I rebooted also linux and it works again. NecAcces - but I'm not familiar with that vendor. Also, do you have a Aterm WR8600N http://121ware.com/aterm/ which is a NEC part, probably sold in other places under a different name. In Japan it is sold as this. WLAN packet capture (from another host nearby on the same channel)? That would be helpful as well. Difficult, I only have an iPhone, and a wireless repeater for the TV, and I guess both are not enough for wlan sniffing. In the meantime I have also tried wpa_supplicatn 2.0, without chagnes. In the current log there are strange things: May 15 20:36:38 tofuschnitzel kernel: [78541.678861] wlan0: send auth to 00:3a :9d:b4:54:5a (try 1/3) May 15 20:36:38 tofuschnitzel NetworkManager[16128]: info (wlan0): supplican t interface state: scanning - authenticating May 15 20:36:38 tofuschnitzel kernel: [78541.681046] wlan0: authenticated May 15 20:36:43 tofuschnitzel kernel: [78546.680713] wlan0: deauthenticating from 00:3a:9d:b4:54:5a by local choice (reason=3) May 15 20:36:43 tofuschnitzel NetworkManager[16128]: info (wlan0): supplicant interface state: authenticating - disconnected May 15 20:36:44 tofuschnitzel NetworkManager[16128]: info (wlan0): supplicant interface state: disconnected - scanning Why does it go from authenticated - directly to deauthenticating. Uffa. Anyway, I will try some more things, esp wireless-testing. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RTL driver for RTL8191SEvB and/or wpa-supplicant really broken at times
=3 May 8 20:48:27 tofuschnitzel kernel: [18677.928400] wlan0: deauthenticating from 00:3a:9d:b4:54:5a by local choice (reason=3) May 8 20:48:27 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3 May 8 20:48:36 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:48:52 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:49:15 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:49:25 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:49:41 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:49:50 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:49:57 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:53:20 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:53:30 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:53:51 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:54:01 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:54:27 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:54:45 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:55:07 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:55:36 tofuschnitzel kernel: [19106.844710] wlan0: deauthenticating from 00:3a:9d:b4:54:5a by local choice (reason=3) May 8 20:55:36 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=3 May 8 21:10:07 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 21:10:58 tofuschnitzel kernel: [20029.040231] wlan0: deauthenticating from 00:3a:9d:b4:54:5a by local choice (reason=3) May 8 21:10:58 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3 May 8 21:23:20 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 My feeling is also that things like wpa_supplicant[5513]: wlan0: WPA: Key negotiation completed with 00:3a:9d:b4:54:5a [PTK=CCMP GTK=CCMP] have a strong effect on the actual connection. 4) conclusion = in the current state, that is release 3.9.0, but the same happened in earlier kernels, this driver and/or NM is completely useless at times. At times it just works, at times it does nothing. In this case, now the 5th day in series ... Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RTL driver for RTL8191SEvB and/or wpa-supplicant really broken at times
:00 reason=3 May 8 20:48:27 tofuschnitzel kernel: [18677.928400] wlan0: deauthenticating from 00:3a:9d:b4:54:5a by local choice (reason=3) May 8 20:48:27 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3 May 8 20:48:36 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:48:52 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:49:15 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:49:25 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:49:41 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:49:50 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:49:57 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:53:20 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:53:30 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:53:51 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:54:01 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:54:27 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:54:45 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:55:07 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 20:55:36 tofuschnitzel kernel: [19106.844710] wlan0: deauthenticating from 00:3a:9d:b4:54:5a by local choice (reason=3) May 8 20:55:36 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=3 May 8 21:10:07 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 May 8 21:10:58 tofuschnitzel kernel: [20029.040231] wlan0: deauthenticating from 00:3a:9d:b4:54:5a by local choice (reason=3) May 8 21:10:58 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3 May 8 21:23:20 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2 My feeling is also that things like wpa_supplicant[5513]: wlan0: WPA: Key negotiation completed with 00:3a:9d:b4:54:5a [PTK=CCMP GTK=CCMP] have a strong effect on the actual connection. 4) conclusion = in the current state, that is release 3.9.0, but the same happened in earlier kernels, this driver and/or NM is completely useless at times. At times it just works, at times it does nothing. In this case, now the 5th day in series ... Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dire state of rtl8192se driver in 3.7
Hi Larry, hi all, it is some time that I didn't post, but here I want to come back to this item. On Sa, 22 Dez 2012, Larry Finger wrote: >> But the DMAR item I also reported points to a real problem I guess. > > Yes, I would agree. That seems to be gone with current kernels 3.8.0-rc3 I have had the hanging issue today again, but this time it showed a very interesting rythm, that might help to understand. Pinging my router I normally have about ~1ms response time. When it hanged (and this is now several thousand seconds long test) the hang times are *always very close: 4sec 3sec 2sec 1sec is one block. This block might repeat a few times, or only once, but it is always in this rythm: 64 bytes from 192.168.0.1: icmp_req=407 ttl=255 time=1.23 ms 64 bytes from 192.168.0.1: icmp_req=408 ttl=255 time=1.89 ms 64 bytes from 192.168.0.1: icmp_req=409 ttl=255 time=3925 ms 64 bytes from 192.168.0.1: icmp_req=410 ttl=255 time=2918 ms 64 bytes from 192.168.0.1: icmp_req=411 ttl=255 time=1910 ms 64 bytes from 192.168.0.1: icmp_req=412 ttl=255 time=903 ms 64 bytes from 192.168.0.1: icmp_req=413 ttl=255 time=1.15 ms ... 64 bytes from 192.168.0.1: icmp_req=418 ttl=255 time=1.16 ms 64 bytes from 192.168.0.1: icmp_req=419 ttl=255 time=4040 ms 64 bytes from 192.168.0.1: icmp_req=420 ttl=255 time=3033 ms 64 bytes from 192.168.0.1: icmp_req=421 ttl=255 time=2025 ms 64 bytes from 192.168.0.1: icmp_req=422 ttl=255 time=1018 ms 64 bytes from 192.168.0.1: icmp_req=423 ttl=255 time=4087 ms 64 bytes from 192.168.0.1: icmp_req=424 ttl=255 time=3081 ms 64 bytes from 192.168.0.1: icmp_req=425 ttl=255 time=2073 ms 64 bytes from 192.168.0.1: icmp_req=426 ttl=255 time=1065 ms 64 bytes from 192.168.0.1: icmp_req=427 ttl=255 time=4124 ms 64 bytes from 192.168.0.1: icmp_req=428 ttl=255 time=3121 ms 64 bytes from 192.168.0.1: icmp_req=429 ttl=255 time=2114 ms 64 bytes from 192.168.0.1: icmp_req=430 ttl=255 time=1109 ms 64 bytes from 192.168.0.1: icmp_req=431 ttl=255 time=4169 ms 64 bytes from 192.168.0.1: icmp_req=432 ttl=255 time=3163 ms 64 bytes from 192.168.0.1: icmp_req=433 ttl=255 time=2155 ms 64 bytes from 192.168.0.1: icmp_req=434 ttl=255 time=1147 ms 64 bytes from 192.168.0.1: icmp_req=521 ttl=255 time=1.30 ms 64 bytes from 192.168.0.1: icmp_req=522 ttl=255 time=1.25 ms 64 bytes from 192.168.0.1: icmp_req=523 ttl=255 time=4300 ms 64 bytes from 192.168.0.1: icmp_req=524 ttl=255 time=3293 ms 64 bytes from 192.168.0.1: icmp_req=525 ttl=255 time=2295 ms 64 bytes from 192.168.0.1: icmp_req=526 ttl=255 time=1287 ms 64 bytes from 192.168.0.1: icmp_req=527 ttl=255 time=4357 ms 64 bytes from 192.168.0.1: icmp_req=528 ttl=255 time=3351 ms 64 bytes from 192.168.0.1: icmp_req=529 ttl=255 time=2344 ms 64 bytes from 192.168.0.1: icmp_req=530 ttl=255 time=1336 ms 64 bytes from 192.168.0.1: icmp_req=531 ttl=255 time=4408 ms 64 bytes from 192.168.0.1: icmp_req=532 ttl=255 time=3403 ms 64 bytes from 192.168.0.1: icmp_req=533 ttl=255 time=2395 ms 64 bytes from 192.168.0.1: icmp_req=534 ttl=255 time=1387 ms 64 bytes from 192.168.0.1: icmp_req=535 ttl=255 time=4453 ms 64 bytes from 192.168.0.1: icmp_req=536 ttl=255 time=3449 ms 64 bytes from 192.168.0.1: icmp_req=537 ttl=255 time=2441 ms 64 bytes from 192.168.0.1: icmp_req=538 ttl=255 time=1433 ms 64 bytes from 192.168.0.1: icmp_req=539 ttl=255 time=4499 ms ... In addition, the responses for these blocks come *together*, not after 4sec the first, then after 3 sec the next. No. It is wait 10 sec, ba, all 4, wait 10secs, bam all 4. Does that ring *any* bell* Norbert ---- PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dire state of rtl8192se driver in 3.7
Hi Larry, hi all, it is some time that I didn't post, but here I want to come back to this item. On Sa, 22 Dez 2012, Larry Finger wrote: But the DMAR item I also reported points to a real problem I guess. Yes, I would agree. That seems to be gone with current kernels 3.8.0-rc3 I have had the hanging issue today again, but this time it showed a very interesting rythm, that might help to understand. Pinging my router I normally have about ~1ms response time. When it hanged (and this is now several thousand seconds long test) the hang times are *always very close: 4sec 3sec 2sec 1sec is one block. This block might repeat a few times, or only once, but it is always in this rythm: 64 bytes from 192.168.0.1: icmp_req=407 ttl=255 time=1.23 ms 64 bytes from 192.168.0.1: icmp_req=408 ttl=255 time=1.89 ms 64 bytes from 192.168.0.1: icmp_req=409 ttl=255 time=3925 ms 64 bytes from 192.168.0.1: icmp_req=410 ttl=255 time=2918 ms 64 bytes from 192.168.0.1: icmp_req=411 ttl=255 time=1910 ms 64 bytes from 192.168.0.1: icmp_req=412 ttl=255 time=903 ms 64 bytes from 192.168.0.1: icmp_req=413 ttl=255 time=1.15 ms ... 64 bytes from 192.168.0.1: icmp_req=418 ttl=255 time=1.16 ms 64 bytes from 192.168.0.1: icmp_req=419 ttl=255 time=4040 ms 64 bytes from 192.168.0.1: icmp_req=420 ttl=255 time=3033 ms 64 bytes from 192.168.0.1: icmp_req=421 ttl=255 time=2025 ms 64 bytes from 192.168.0.1: icmp_req=422 ttl=255 time=1018 ms 64 bytes from 192.168.0.1: icmp_req=423 ttl=255 time=4087 ms 64 bytes from 192.168.0.1: icmp_req=424 ttl=255 time=3081 ms 64 bytes from 192.168.0.1: icmp_req=425 ttl=255 time=2073 ms 64 bytes from 192.168.0.1: icmp_req=426 ttl=255 time=1065 ms 64 bytes from 192.168.0.1: icmp_req=427 ttl=255 time=4124 ms 64 bytes from 192.168.0.1: icmp_req=428 ttl=255 time=3121 ms 64 bytes from 192.168.0.1: icmp_req=429 ttl=255 time=2114 ms 64 bytes from 192.168.0.1: icmp_req=430 ttl=255 time=1109 ms 64 bytes from 192.168.0.1: icmp_req=431 ttl=255 time=4169 ms 64 bytes from 192.168.0.1: icmp_req=432 ttl=255 time=3163 ms 64 bytes from 192.168.0.1: icmp_req=433 ttl=255 time=2155 ms 64 bytes from 192.168.0.1: icmp_req=434 ttl=255 time=1147 ms 64 bytes from 192.168.0.1: icmp_req=521 ttl=255 time=1.30 ms 64 bytes from 192.168.0.1: icmp_req=522 ttl=255 time=1.25 ms 64 bytes from 192.168.0.1: icmp_req=523 ttl=255 time=4300 ms 64 bytes from 192.168.0.1: icmp_req=524 ttl=255 time=3293 ms 64 bytes from 192.168.0.1: icmp_req=525 ttl=255 time=2295 ms 64 bytes from 192.168.0.1: icmp_req=526 ttl=255 time=1287 ms 64 bytes from 192.168.0.1: icmp_req=527 ttl=255 time=4357 ms 64 bytes from 192.168.0.1: icmp_req=528 ttl=255 time=3351 ms 64 bytes from 192.168.0.1: icmp_req=529 ttl=255 time=2344 ms 64 bytes from 192.168.0.1: icmp_req=530 ttl=255 time=1336 ms 64 bytes from 192.168.0.1: icmp_req=531 ttl=255 time=4408 ms 64 bytes from 192.168.0.1: icmp_req=532 ttl=255 time=3403 ms 64 bytes from 192.168.0.1: icmp_req=533 ttl=255 time=2395 ms 64 bytes from 192.168.0.1: icmp_req=534 ttl=255 time=1387 ms 64 bytes from 192.168.0.1: icmp_req=535 ttl=255 time=4453 ms 64 bytes from 192.168.0.1: icmp_req=536 ttl=255 time=3449 ms 64 bytes from 192.168.0.1: icmp_req=537 ttl=255 time=2441 ms 64 bytes from 192.168.0.1: icmp_req=538 ttl=255 time=1433 ms 64 bytes from 192.168.0.1: icmp_req=539 ttl=255 time=4499 ms ... In addition, the responses for these blocks come *together*, not after 4sec the first, then after 3 sec the next. No. It is wait 10 sec, ba, all 4, wait 10secs, bam all 4. Does that ring *any* bell* Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dire state of rtl8192se driver in 3.7
Hi Larry,, hi all
On Sa, 22 Dez 2012, Larry Finger wrote:
> It is not that no one cares; however, your attitude does nothing to
> induce me to work on this problem. The facts are not needed "to make
Aehm, ... after my initial report you asked me several more questions,
which I answered within a few hours. After that no as in 0 response,
although I pinged back a few times.
So am I supposed to deduce from 0 reactions that anyone is interested?
> people happy", they are necessary to try to reproduce the problem. If I
> cannot make it happen here, then I cannot fix it. Also, remember that I
Disagree. I am involved in tracking down a nasty regression in the intel
drm driver, which the intel people can *not* reproduce, but several
other people, and after long trials and patches and converse it is
starting to look much better.
> am a volunteer. I get nothing from Realtek but starting code of varying
> quality and some sample chips. At least my versions do not crash your
Ok, that is a problem I understand. If this is the case, that it is
a single volunteer caring for the code, then I see a real problem.
(And I also will try to stay away from rtl wlan cards on my next laptop)
> I have never tested forcing a reset on the chip the way you did. I am not
> surprised that bad things happen.
But the DMAR item I also reported points to a real problem I guess.
> From some of the material that you report, it appears that you have an
> 802.11n connection using WPA1 encryption. (More of those pesky details!)
WPA PSK, yes. I don't know the difference between WPA2 and WPA, though.
Best wishes, and merry christmas
Norbert
--------
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
`This must be Thursday,' said Arthur to himself, sinking
low over his beer, `I never could get the hang of
Thursdays.'
--- Arthur, on what was to be his last Thursday on Earth.
--- Douglas Adams, The Hitchhikers Guide to the Galaxy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
dire state of rtl driver in 3.7
e: disconnected -> scanning
Dec 22 23:43:12 tofuschnitzel kernel: [ 3719.089498]
rtl8192se:rtl92s_phy_set_rf_power_state():<0-1> IPS Set eRf nic enable
Dec 22 23:43:12 tofuschnitzel kernel: [ 3719.112723]
rtl8192se:_rtl92se_macconfig_after_fwdownload():<0-1> EFUSE CONFIG OK
Dec 22 23:43:12 tofuschnitzel kernel: [ 3719.112726]
rtl8192se:_rtl92se_macconfig_after_fwdownload():<0-1> OK
^LDec 22 23:43:12 tofuschnitzel wpa_supplicant[4641]: wlan0: SME: Trying to
authenticate with 00:3a:9d:b4:54:5a (SSID='norbujp' freq=2447 MHz)
Dec 22 23:43:12 tofuschnitzel kernel: [ 3719.996208] wlan0: authenticate with
00:3a:9d:b4:54:5a
Dec 22 23:43:12 tofuschnitzel NetworkManager[7546]: (wlan0): supplicant
interface state: scanning -> authenticating
Dec 22 23:43:12 tofuschnitzel kernel: [ 3720.015206]
rtlwifi:rtl_op_bss_info_changed():<0-0> 00:3a:9d:b4:54:5a
Dec 22 23:43:12 tofuschnitzel kernel: [ 3720.015285] wlan0: send auth to
00:3a:9d:b4:54:5a (try 1/3)
Dec 22 23:43:12 tofuschnitzel kernel: [ 3720.015301]
rtlwifi:rtl_pci_tx():<200-1> MAC80211_LINKING
Dec 22 23:43:13 tofuschnitzel kernel: [ 3720.218612] wlan0: send auth to
00:3a:9d:b4:54:5a (try 2/3)
Dec 22 23:43:13 tofuschnitzel kernel: [ 3720.218630]
rtlwifi:rtl_pci_tx():<200-1> MAC80211_LINKING
Dec 22 23:43:13 tofuschnitzel kernel: [ 3720.422100] wlan0: send auth to
00:3a:9d:b4:54:5a (try 3/3)
Dec 22 23:43:13 tofuschnitzel kernel: [ 3720.422120]
rtlwifi:rtl_pci_tx():<200-1> MAC80211_LINKING
Dec 22 23:43:13 tofuschnitzel kernel: [ 3720.625545] wlan0: authentication with
00:3a:9d:b4:54:5a timed out
==
It seems that often when something happens it is related to WPA Group rekeying
or somethin, because
immediately afterwards it starts hanging.
Dec 22 23:55:50 tofuschnitzel wpa_supplicant[4650]: wlan0: WPA: Group rekeying
completed with 00:3a:9d:b4:54:5a [GTK=CCMP]
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278193]
rtlwifi:rtl_op_set_key():<0-0> Disabling hardware based encryption for keyidx:
1, mac: ff:ff:ff
:ff:ff:ff
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278200]
rtlwifi:rtl_op_set_key():<0-0> alg:CCMP
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278203] rtlwifi:rtl_op_set_key():<
0-0> disable key delete one entry
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278206]
rtlwifi:rtl_cam_delete_one_entry():<0-0> key_idx:1
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278209]
rtlwifi:rtl_cam_delete_one_entry():<0-0> rtl_cam_delete_one_entry(): WRITE A4: 0
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278212]
rtlwifi:rtl_cam_delete_one_entry():<0-0> rtl_cam_delete_one_entry(): WRITE A0:
80010008
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278275]
rtlwifi:rtl_op_set_key():<0-0> Using hardware based encryption for keyidx: 1,
mac: ff:ff:ff:ff:ff:ff
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278278]
rtlwifi:rtl_op_set_key():<0-0> alg:CCMP
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278281]
rtlwifi:rtl_op_set_key():<0-0> set enable_hw_sec, key_type:4(OPEN:0 WEP40:1
TKIP:2 AES:4 WEP104:5)
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278284]
rtlwifi:rtl_op_set_key():<0-0> set group key
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278288]
rtl8192se:rtl92se_set_key():<0-0> add one entry
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278290]
rtl8192se:rtl92se_set_key():<0-0> set group key
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278891]
rtlwifi:rtl_cam_add_one_entry():<0-0> <===
Dec 22 23:55:52 tofuschnitzel kernel: [ 489.272265] wlan0: deauthenticated
from 00:3a:9d:b4:54:5a (Reason: 2)
Another strange message I got was this beautiful one:
Dec 22 23:45:55 tofuschnitzel kernel: [ 3882.413599]
rtl8192se:rtl92s_phy_set_rf_power_state():<0-1> awake, sleeped:3591952 ms
state_inap:0
***sleeped:3591952 ms***
This is *VERY* close to exactely 1 hours 60*60 = 36 ms whatever that
might be
I don't know what other information I can provide.
I don't know if there is anyone who feels responsible.
I am willing to test and provide more data.
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
CRANLEIGH (n.)
A mood of irrational irritation with everyone and everything.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
dire state of rtl driver in 3.7
Set eRf nic enable
Dec 22 23:43:12 tofuschnitzel kernel: [ 3719.112723]
rtl8192se:_rtl92se_macconfig_after_fwdownload():0-1 EFUSE CONFIG OK
Dec 22 23:43:12 tofuschnitzel kernel: [ 3719.112726]
rtl8192se:_rtl92se_macconfig_after_fwdownload():0-1 OK
^LDec 22 23:43:12 tofuschnitzel wpa_supplicant[4641]: wlan0: SME: Trying to
authenticate with 00:3a:9d:b4:54:5a (SSID='norbujp' freq=2447 MHz)
Dec 22 23:43:12 tofuschnitzel kernel: [ 3719.996208] wlan0: authenticate with
00:3a:9d:b4:54:5a
Dec 22 23:43:12 tofuschnitzel NetworkManager[7546]: info (wlan0): supplicant
interface state: scanning - authenticating
Dec 22 23:43:12 tofuschnitzel kernel: [ 3720.015206]
rtlwifi:rtl_op_bss_info_changed():0-0 00:3a:9d:b4:54:5a
Dec 22 23:43:12 tofuschnitzel kernel: [ 3720.015285] wlan0: send auth to
00:3a:9d:b4:54:5a (try 1/3)
Dec 22 23:43:12 tofuschnitzel kernel: [ 3720.015301]
rtlwifi:rtl_pci_tx():200-1 MAC80211_LINKING
Dec 22 23:43:13 tofuschnitzel kernel: [ 3720.218612] wlan0: send auth to
00:3a:9d:b4:54:5a (try 2/3)
Dec 22 23:43:13 tofuschnitzel kernel: [ 3720.218630]
rtlwifi:rtl_pci_tx():200-1 MAC80211_LINKING
Dec 22 23:43:13 tofuschnitzel kernel: [ 3720.422100] wlan0: send auth to
00:3a:9d:b4:54:5a (try 3/3)
Dec 22 23:43:13 tofuschnitzel kernel: [ 3720.422120]
rtlwifi:rtl_pci_tx():200-1 MAC80211_LINKING
Dec 22 23:43:13 tofuschnitzel kernel: [ 3720.625545] wlan0: authentication with
00:3a:9d:b4:54:5a timed out
==
It seems that often when something happens it is related to WPA Group rekeying
or somethin, because
immediately afterwards it starts hanging.
Dec 22 23:55:50 tofuschnitzel wpa_supplicant[4650]: wlan0: WPA: Group rekeying
completed with 00:3a:9d:b4:54:5a [GTK=CCMP]
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278193]
rtlwifi:rtl_op_set_key():0-0 Disabling hardware based encryption for keyidx:
1, mac: ff:ff:ff
:ff:ff:ff
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278200]
rtlwifi:rtl_op_set_key():0-0 alg:CCMP
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278203] rtlwifi:rtl_op_set_key():
0-0 disable key delete one entry
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278206]
rtlwifi:rtl_cam_delete_one_entry():0-0 key_idx:1
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278209]
rtlwifi:rtl_cam_delete_one_entry():0-0 rtl_cam_delete_one_entry(): WRITE A4: 0
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278212]
rtlwifi:rtl_cam_delete_one_entry():0-0 rtl_cam_delete_one_entry(): WRITE A0:
80010008
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278275]
rtlwifi:rtl_op_set_key():0-0 Using hardware based encryption for keyidx: 1,
mac: ff:ff:ff:ff:ff:ff
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278278]
rtlwifi:rtl_op_set_key():0-0 alg:CCMP
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278281]
rtlwifi:rtl_op_set_key():0-0 set enable_hw_sec, key_type:4(OPEN:0 WEP40:1
TKIP:2 AES:4 WEP104:5)
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278284]
rtlwifi:rtl_op_set_key():0-0 set group key
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278288]
rtl8192se:rtl92se_set_key():0-0 add one entry
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278290]
rtl8192se:rtl92se_set_key():0-0 set group key
Dec 22 23:55:50 tofuschnitzel kernel: [ 487.278891]
rtlwifi:rtl_cam_add_one_entry():0-0 ===
Dec 22 23:55:52 tofuschnitzel kernel: [ 489.272265] wlan0: deauthenticated
from 00:3a:9d:b4:54:5a (Reason: 2)
Another strange message I got was this beautiful one:
Dec 22 23:45:55 tofuschnitzel kernel: [ 3882.413599]
rtl8192se:rtl92s_phy_set_rf_power_state():0-1 awake, sleeped:3591952 ms
state_inap:0
***sleeped:3591952 ms***
This is *VERY* close to exactely 1 hours 60*60 = 36 ms whatever that
might be
I don't know what other information I can provide.
I don't know if there is anyone who feels responsible.
I am willing to test and provide more data.
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
CRANLEIGH (n.)
A mood of irrational irritation with everyone and everything.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: dire state of rtl8192se driver in 3.7
Hi Larry,, hi all
On Sa, 22 Dez 2012, Larry Finger wrote:
It is not that no one cares; however, your attitude does nothing to
induce me to work on this problem. The facts are not needed to make
Aehm, ... after my initial report you asked me several more questions,
which I answered within a few hours. After that no as in 0 response,
although I pinged back a few times.
So am I supposed to deduce from 0 reactions that anyone is interested?
people happy, they are necessary to try to reproduce the problem. If I
cannot make it happen here, then I cannot fix it. Also, remember that I
Disagree. I am involved in tracking down a nasty regression in the intel
drm driver, which the intel people can *not* reproduce, but several
other people, and after long trials and patches and converse it is
starting to look much better.
am a volunteer. I get nothing from Realtek but starting code of varying
quality and some sample chips. At least my versions do not crash your
Ok, that is a problem I understand. If this is the case, that it is
a single volunteer caring for the code, then I see a real problem.
(And I also will try to stay away from rtl wlan cards on my next laptop)
I have never tested forcing a reset on the chip the way you did. I am not
surprised that bad things happen.
But the DMAR item I also reported points to a real problem I guess.
From some of the material that you report, it appears that you have an
802.11n connection using WPA1 encryption. (More of those pesky details!)
WPA PSK, yes. I don't know the difference between WPA2 and WPA, though.
Best wishes, and merry christmas
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
`This must be Thursday,' said Arthur to himself, sinking
low over his beer, `I never could get the hang of
Thursdays.'
--- Arthur, on what was to be his last Thursday on Earth.
--- Douglas Adams, The Hitchhikers Guide to the Galaxy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: rtl8192se: ping router gives mdev of 25387.102???
There we go again, rtl is completely hosed ... $ ping 192.168.0.1 # this is my router!!! PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. >From 192.168.0.6 icmp_seq=21 Destination Host Unreachable >From 192.168.0.6 icmp_seq=22 Destination Host Unreachable >From 192.168.0.6 icmp_seq=23 Destination Host Unreachable >From 192.168.0.6 icmp_seq=24 Destination Host Unreachable >From 192.168.0.6 icmp_seq=25 Destination Host Unreachable >From 192.168.0.6 icmp_seq=26 Destination Host Unreachable >From 192.168.0.6 icmp_seq=27 Destination Host Unreachable >From 192.168.0.6 icmp_seq=28 Destination Host Unreachable >From 192.168.0.6 icmp_seq=29 Destination Host Unreachable >From 192.168.0.6 icmp_seq=30 Destination Host Unreachable >From 192.168.0.6 icmp_seq=31 Destination Host Unreachable >From 192.168.0.6 icmp_seq=32 Destination Host Unreachable >From 192.168.0.6 icmp_seq=33 Destination Host Unreachable >From 192.168.0.6 icmp_seq=34 Destination Host Unreachable >From 192.168.0.6 icmp_seq=35 Destination Host Unreachable >From 192.168.0.6 icmp_seq=36 Destination Host Unreachable >From 192.168.0.6 icmp_seq=37 Destination Host Unreachable >From 192.168.0.6 icmp_seq=38 Destination Host Unreachable 64 bytes from 192.168.0.1: icmp_req=1 ttl=255 time=38455 ms 64 bytes from 192.168.0.1: icmp_req=2 ttl=255 time=37453 ms 64 bytes from 192.168.0.1: icmp_req=3 ttl=255 time=36445 ms 64 bytes from 192.168.0.1: icmp_req=4 ttl=255 time=35437 ms 64 bytes from 192.168.0.1: icmp_req=5 ttl=255 time=34429 ms 64 bytes from 192.168.0.1: icmp_req=6 ttl=255 time=33421 ms 64 bytes from 192.168.0.1: icmp_req=7 ttl=255 time=32413 ms 64 bytes from 192.168.0.1: icmp_req=8 ttl=255 time=31405 ms 64 bytes from 192.168.0.1: icmp_req=9 ttl=255 time=30397 ms 64 bytes from 192.168.0.1: icmp_req=10 ttl=255 time=29388 ms 64 bytes from 192.168.0.1: icmp_req=11 ttl=255 time=28381 ms 64 bytes from 192.168.0.1: icmp_req=12 ttl=255 time=27373 ms 64 bytes from 192.168.0.1: icmp_req=13 ttl=255 time=26365 ms 64 bytes from 192.168.0.1: icmp_req=14 ttl=255 time=25357 ms 64 bytes from 192.168.0.1: icmp_req=15 ttl=255 time=24349 ms 64 bytes from 192.168.0.1: icmp_req=16 ttl=255 time=23341 ms 64 bytes from 192.168.0.1: icmp_req=17 ttl=255 time=22333 ms 64 bytes from 192.168.0.1: icmp_req=18 ttl=255 time=21325 ms 64 bytes from 192.168.0.1: icmp_req=19 ttl=255 time=20317 ms 64 bytes from 192.168.0.1: icmp_req=20 ttl=255 time=19309 ms 64 bytes from 192.168.0.1: icmp_req=39 ttl=255 time=207 ms 64 bytes from 192.168.0.1: icmp_req=40 ttl=255 time=1.36 ms 64 bytes from 192.168.0.1: icmp_req=41 ttl=255 time=1.22 ms 64 bytes from 192.168.0.1: icmp_req=42 ttl=255 time=1.76 ms ^C --- 192.168.0.1 ping statistics --- 42 packets transmitted, 24 received, +18 errors, 42% packet loss, time 41261ms rtt min/avg/max/mdev = 1.229/24079.534/38455.055/11983.493 ms, pipe 39 $ Yeah. we are talking about my router, and a stability that is below the quality of morse code ... On Sa, 15 Sep 2012, Norbert Preining wrote: > Hi Larry, hi all, > > On Fr, 14 Sep 2012, wrote: > > I am running on top of default kernel git, will try wireless-testing, too. > > I tried now with wireless-testing from yesterday, and had the same problem. > Actually, I got even *better* results: > 64 bytes from 192.168.0.1: icmp_req=75 ttl=255 time=137856 ms > 64 bytes from 192.168.0.1: icmp_req=76 ttl=255 time=136848 ms > 64 bytes from 192.168.0.1: icmp_req=78 ttl=255 time=134943 ms > > ... > rtt min/avg/max/mdev = 1.110/46967.879/137856.232/49666.671 ms, pipe 138 > > > So now we are mdev of 50secs sometimes ;-) > > > Another interesting things: > At home I have the problems with the NEC router, but I am now at > the university. I am writing this email over a very very stable > ssh link to another server. > > Here is the output iof ifconfig: > $ ifconfig > eth0 Link encap:Ethernet HWaddr 60:eb:69:c9:0c:ea > UP BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > > loLink encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:20418 errors:0 dropped:0 overruns:0 frame:0 > TX packets:20418 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:1950587 (1.8 MiB) TX bytes:1950587 (1.8 MiB) > > wlan0 Link encap:Ethernet HWaddr 88:9f:fa:f9:07:28 > inet addr:150.65.206.200 Bcast:150.65.207.255 Mask:255.255.252.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:232640 errors:0 dropped:1
Re: rtl8192se: ping router gives mdev of 25387.102???
There we go again, rtl is completely hosed ... $ ping 192.168.0.1 # this is my router!!! PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. From 192.168.0.6 icmp_seq=21 Destination Host Unreachable From 192.168.0.6 icmp_seq=22 Destination Host Unreachable From 192.168.0.6 icmp_seq=23 Destination Host Unreachable From 192.168.0.6 icmp_seq=24 Destination Host Unreachable From 192.168.0.6 icmp_seq=25 Destination Host Unreachable From 192.168.0.6 icmp_seq=26 Destination Host Unreachable From 192.168.0.6 icmp_seq=27 Destination Host Unreachable From 192.168.0.6 icmp_seq=28 Destination Host Unreachable From 192.168.0.6 icmp_seq=29 Destination Host Unreachable From 192.168.0.6 icmp_seq=30 Destination Host Unreachable From 192.168.0.6 icmp_seq=31 Destination Host Unreachable From 192.168.0.6 icmp_seq=32 Destination Host Unreachable From 192.168.0.6 icmp_seq=33 Destination Host Unreachable From 192.168.0.6 icmp_seq=34 Destination Host Unreachable From 192.168.0.6 icmp_seq=35 Destination Host Unreachable From 192.168.0.6 icmp_seq=36 Destination Host Unreachable From 192.168.0.6 icmp_seq=37 Destination Host Unreachable From 192.168.0.6 icmp_seq=38 Destination Host Unreachable 64 bytes from 192.168.0.1: icmp_req=1 ttl=255 time=38455 ms 64 bytes from 192.168.0.1: icmp_req=2 ttl=255 time=37453 ms 64 bytes from 192.168.0.1: icmp_req=3 ttl=255 time=36445 ms 64 bytes from 192.168.0.1: icmp_req=4 ttl=255 time=35437 ms 64 bytes from 192.168.0.1: icmp_req=5 ttl=255 time=34429 ms 64 bytes from 192.168.0.1: icmp_req=6 ttl=255 time=33421 ms 64 bytes from 192.168.0.1: icmp_req=7 ttl=255 time=32413 ms 64 bytes from 192.168.0.1: icmp_req=8 ttl=255 time=31405 ms 64 bytes from 192.168.0.1: icmp_req=9 ttl=255 time=30397 ms 64 bytes from 192.168.0.1: icmp_req=10 ttl=255 time=29388 ms 64 bytes from 192.168.0.1: icmp_req=11 ttl=255 time=28381 ms 64 bytes from 192.168.0.1: icmp_req=12 ttl=255 time=27373 ms 64 bytes from 192.168.0.1: icmp_req=13 ttl=255 time=26365 ms 64 bytes from 192.168.0.1: icmp_req=14 ttl=255 time=25357 ms 64 bytes from 192.168.0.1: icmp_req=15 ttl=255 time=24349 ms 64 bytes from 192.168.0.1: icmp_req=16 ttl=255 time=23341 ms 64 bytes from 192.168.0.1: icmp_req=17 ttl=255 time=22333 ms 64 bytes from 192.168.0.1: icmp_req=18 ttl=255 time=21325 ms 64 bytes from 192.168.0.1: icmp_req=19 ttl=255 time=20317 ms 64 bytes from 192.168.0.1: icmp_req=20 ttl=255 time=19309 ms 64 bytes from 192.168.0.1: icmp_req=39 ttl=255 time=207 ms 64 bytes from 192.168.0.1: icmp_req=40 ttl=255 time=1.36 ms 64 bytes from 192.168.0.1: icmp_req=41 ttl=255 time=1.22 ms 64 bytes from 192.168.0.1: icmp_req=42 ttl=255 time=1.76 ms ^C --- 192.168.0.1 ping statistics --- 42 packets transmitted, 24 received, +18 errors, 42% packet loss, time 41261ms rtt min/avg/max/mdev = 1.229/24079.534/38455.055/11983.493 ms, pipe 39 $ Yeah. we are talking about my router, and a stability that is below the quality of morse code ... On Sa, 15 Sep 2012, Norbert Preining wrote: Hi Larry, hi all, On Fr, 14 Sep 2012, wrote: I am running on top of default kernel git, will try wireless-testing, too. I tried now with wireless-testing from yesterday, and had the same problem. Actually, I got even *better* results: 64 bytes from 192.168.0.1: icmp_req=75 ttl=255 time=137856 ms 64 bytes from 192.168.0.1: icmp_req=76 ttl=255 time=136848 ms 64 bytes from 192.168.0.1: icmp_req=78 ttl=255 time=134943 ms ... rtt min/avg/max/mdev = 1.110/46967.879/137856.232/49666.671 ms, pipe 138 So now we are mdev of 50secs sometimes ;-) Another interesting things: At home I have the problems with the NEC router, but I am now at the university. I am writing this email over a very very stable ssh link to another server. Here is the output iof ifconfig: $ ifconfig eth0 Link encap:Ethernet HWaddr 60:eb:69:c9:0c:ea UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:20418 errors:0 dropped:0 overruns:0 frame:0 TX packets:20418 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1950587 (1.8 MiB) TX bytes:1950587 (1.8 MiB) wlan0 Link encap:Ethernet HWaddr 88:9f:fa:f9:07:28 inet addr:150.65.206.200 Bcast:150.65.207.255 Mask:255.255.252.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:232640 errors:0 dropped:1 overruns:0 frame:0 TX packets:69798 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:85599897 (81.6 MiB) TX bytes:8925832 (8.5 MiB) But the kernel is convinced that I am not connected
Re: drm i915 hangs on heavy io load
On So, 04 Nov 2012, Dave Airlie wrote:
> Yeah thats fine, bisecting works by going to where commits were
> originally committed, so drm-intel-next was 3.6.0-rc2 at some point
> was only merged into Linus later.
Ok, thanks, didn't know that. Have started the bisect game now,
coming back in about 1 year ;-)
Best wishes
Norbert
----
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
SCOPWICK (n.)
The flap of skin which is torn off you lip when trying to smoke an
untipped cigarette.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drm i915 hangs on heavy io load
On So, 04 Nov 2012, Dave Airlie wrote:
Yeah thats fine, bisecting works by going to where commits were
originally committed, so drm-intel-next was 3.6.0-rc2 at some point
was only merged into Linus later.
Ok, thanks, didn't know that. Have started the bisect game now,
coming back in about 1 year ;-)
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
SCOPWICK (n.)
The flap of skin which is torn off you lip when trying to smoke an
untipped cigarette.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drm i915 hangs on heavy io load
Hi all,
On Di, 30 Okt 2012, Dave Airlie wrote:
> I would suggest starting a bisect on drivers/gpu/drm/i915 from 3.6
> final to 3.7-rc1 or maybe -rc2.
Sorry for my ignorance ... I did on master branch
$ git checkout v3.7-rc1
...
$ git bisect start drivers/gpu/drm/i915
$ git bisect bad
$ git bisect good v3.6
Bisecting: 121 revisions left to test after this (roughly 7 steps)
[25c5b2665fe4cc5a93edd29b62e7c05c1526] drm/i915: implement new
set_mode code flow
$
after that I am back somewhere around
3.6.0-rc2
???
Am I doing something wrong? I thought I am bisecting between 3.6 and 3.7.-rc2?
How can I go back to 3.6.0-rc2?
Best wishes
Norbert
----
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
SCREEB (n.)
To make the noise of a nylon anorak rubbing against a pair of corduroy
trousers.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drm i915 hangs on heavy io load
Hi all,
On Di, 30 Okt 2012, Dave Airlie wrote:
I would suggest starting a bisect on drivers/gpu/drm/i915 from 3.6
final to 3.7-rc1 or maybe -rc2.
Sorry for my ignorance ... I did on master branch
$ git checkout v3.7-rc1
...
$ git bisect start drivers/gpu/drm/i915
$ git bisect bad
$ git bisect good v3.6
Bisecting: 121 revisions left to test after this (roughly 7 steps)
[25c5b2665fe4cc5a93edd29b62e7c05c1526] drm/i915: implement new
set_mode code flow
$
after that I am back somewhere around
3.6.0-rc2
???
Am I doing something wrong? I thought I am bisecting between 3.6 and 3.7.-rc2?
How can I go back to 3.6.0-rc2?
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
SCREEB (n.)
To make the noise of a nylon anorak rubbing against a pair of corduroy
trousers.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drm i915 hangs on heavy io load
On Mo, 29 Okt 2012, Ben Widawsky wrote:
> Hi Norbert. In addition to the above, if this truly appears to be
> related to i/o, can we try to decrease the time to failure with some
I am *not* sure. As I said, the last thing was shotwell photo
editing. It might be some io while loading the photos, but
after that they are in the cache, and the only thing is done is
lots of displaying.
> serious i/o tests? Off the top of my head I am not sure what's
Anyway, that is my idea. I think I don't need google. A simple
svn up
on my 15Gb svn repository creates enough io. And doing some git pull
or so on same sized repositories in parallel brings anyway the
laptop to its knees (actually, badly to its knees).
Best wishes
Norbert
----
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
Far out in the uncharted backwaters of the unfashionable
end of the western spiral arm of the Galaxy lies a small
unregarded yellow sun.
--- Douglas Adams, The Hitchhikers Guide to the Galaxy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drm i915 hangs on heavy io load
Hi Dave,
On Di, 30 Okt 2012, Dave Airlie wrote:
> > Thanks, running now with SNA. Let us see what happens.
>
> Please don't, we ain't going to find the bug any quicker changing
> variables, if the only thing that changed on your system was the
Sorry, didn't know. I supposed from the email of Chris that I should try
it "to stress different code path" ... anyway, disabling it again.
> How long does it take you to reproduce, and does it happen when in
Very hard to say, most of the times it is in a few days scale.
Though it happened also after a few hours once.
> actual use. On my laptop I've noticed I come back to it sometimes and
Concerning actual use: I had instances on several occassions. Just 30min
ago it was while working with shotwell on my photo collection, tagging
photos. So there should not be a big disk activity or so, but a lot
of screen redraws etc when going through the photos.
On other times it was locked screen without screen saver.
Concerning coming back: For me it never worked. I always have to reboot
to get a working state again. Ok, to be more specific. GNome3 is dead.
I can close the windows normally with kbd shortcuts and some mouse
interaction, but no new windows, no moving etc.
> gnome-shell is dead. This never happened pre 3.7-rc's. But for me its
> a 3-4 day window so far for it to die, which makes bisecting it a bit
That sounds pretty much like my case, but since I often don't use
the laptop for 2 days or so, it might be a bit longer.
> of a major problem. and I'm just finished bisecting the last Ironlake
> regression that took over a month.
Ouch ...
> I would suggest starting a bisect on drivers/gpu/drm/i915 from 3.6
> final to 3.7-rc1 or maybe -rc2.
Ok, thanks. I will try.
Best wishes
Norbert
----
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
QUALL (vb.)
To speak with the voice of one who requires another to do something
for them.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drm i915 hangs on heavy io load
On Mo, 29 Okt 2012, Tino Keitel wrote:
> Section "Device"
> Option "AccelMethod" "SNA"
> Identifier "Card0"
> Driver "intel"
> EndSection
Thanks, running now with SNA. Let us see what happens.
Best wishes
Norbert
----
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
RECULVER (n.)
The sort of remark only ever made during Any Questions.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drm i915 hangs on heavy io load
Hi Chris,
On So, 28 Okt 2012, Chris Wilson wrote:
> > I pulled the whole branch into my compile branch, and removed everything
> > from kernel cmd line regarding rc6, and got the
> > [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
> > [drm] capturing error event; look for more information in
> > /debug/dri/0/i915_error_state
> > [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
> > [drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged!
> > [drm:i915_reset] *ERROR* Failed to reset chip.
> > new i915_error_state.gz at the same place.
> >
> > So it seems that the patches in the ilk-wa-pile branch do not help.
>
> Yeah, looks like we have another issue to contend with, so can you
> please file a bug on bugzilla.freedesktop.org (or bugzilla.kernel.org)
> so that we don't lose track of it.
I have seen this here:
https://bugs.freedesktop.org/show_bug.cgi?id=55984
does it make sense to start a new bug for that?
Best wishes
Norbert
----
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
SCREMBY (n.)
The dehydrated felt-tip pen attached by a string to the 'Don't Forget'
board in the kitchen which has never worked in living memory but which
no one can be bothered to throw away.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drm i915 hangs on heavy io load
Hi Chris,
On So, 28 Okt 2012, Chris Wilson wrote:
I pulled the whole branch into my compile branch, and removed everything
from kernel cmd line regarding rc6, and got the
[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[drm] capturing error event; look for more information in
/debug/dri/0/i915_error_state
[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged!
[drm:i915_reset] *ERROR* Failed to reset chip.
new i915_error_state.gz at the same place.
So it seems that the patches in the ilk-wa-pile branch do not help.
Yeah, looks like we have another issue to contend with, so can you
please file a bug on bugzilla.freedesktop.org (or bugzilla.kernel.org)
so that we don't lose track of it.
I have seen this here:
https://bugs.freedesktop.org/show_bug.cgi?id=55984
does it make sense to start a new bug for that?
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
SCREMBY (n.)
The dehydrated felt-tip pen attached by a string to the 'Don't Forget'
board in the kitchen which has never worked in living memory but which
no one can be bothered to throw away.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drm i915 hangs on heavy io load
On Mo, 29 Okt 2012, Tino Keitel wrote:
Section Device
Option AccelMethod SNA
Identifier Card0
Driver intel
EndSection
Thanks, running now with SNA. Let us see what happens.
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
RECULVER (n.)
The sort of remark only ever made during Any Questions.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drm i915 hangs on heavy io load
Hi Dave,
On Di, 30 Okt 2012, Dave Airlie wrote:
Thanks, running now with SNA. Let us see what happens.
Please don't, we ain't going to find the bug any quicker changing
variables, if the only thing that changed on your system was the
Sorry, didn't know. I supposed from the email of Chris that I should try
it to stress different code path ... anyway, disabling it again.
How long does it take you to reproduce, and does it happen when in
Very hard to say, most of the times it is in a few days scale.
Though it happened also after a few hours once.
actual use. On my laptop I've noticed I come back to it sometimes and
Concerning actual use: I had instances on several occassions. Just 30min
ago it was while working with shotwell on my photo collection, tagging
photos. So there should not be a big disk activity or so, but a lot
of screen redraws etc when going through the photos.
On other times it was locked screen without screen saver.
Concerning coming back: For me it never worked. I always have to reboot
to get a working state again. Ok, to be more specific. GNome3 is dead.
I can close the windows normally with kbd shortcuts and some mouse
interaction, but no new windows, no moving etc.
gnome-shell is dead. This never happened pre 3.7-rc's. But for me its
a 3-4 day window so far for it to die, which makes bisecting it a bit
That sounds pretty much like my case, but since I often don't use
the laptop for 2 days or so, it might be a bit longer.
of a major problem. and I'm just finished bisecting the last Ironlake
regression that took over a month.
Ouch ...
I would suggest starting a bisect on drivers/gpu/drm/i915 from 3.6
final to 3.7-rc1 or maybe -rc2.
Ok, thanks. I will try.
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
QUALL (vb.)
To speak with the voice of one who requires another to do something
for them.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drm i915 hangs on heavy io load
On Mo, 29 Okt 2012, Ben Widawsky wrote:
Hi Norbert. In addition to the above, if this truly appears to be
related to i/o, can we try to decrease the time to failure with some
I am *not* sure. As I said, the last thing was shotwell photo
editing. It might be some io while loading the photos, but
after that they are in the cache, and the only thing is done is
lots of displaying.
serious i/o tests? Off the top of my head I am not sure what's
Anyway, that is my idea. I think I don't need google. A simple
svn up
on my 15Gb svn repository creates enough io. And doing some git pull
or so on same sized repositories in parallel brings anyway the
laptop to its knees (actually, badly to its knees).
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
Far out in the uncharted backwaters of the unfashionable
end of the western spiral arm of the Galaxy lies a small
unregarded yellow sun.
--- Douglas Adams, The Hitchhikers Guide to the Galaxy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drm i915 hangs on heavy io load
Hi Chris, > so can you > please file a bug on bugzilla.freedesktop.org (or bugzilla.kernel.org) > so that we don't lose track of it. Will do when I'm back from the mountains. > If your have the option, can you switch the ddx between using SNA and > UXA. ??? Is that a BIOS option? Or kernel? I can try both. Norbert (on mobile) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm i915 hangs on heavy io load
Hi Chris, so can you please file a bug on bugzilla.freedesktop.org (or bugzilla.kernel.org) so that we don't lose track of it. Will do when I'm back from the mountains. If your have the option, can you switch the ddx between using SNA and UXA. ??? Is that a BIOS option? Or kernel? I can try both. Norbert (on mobile) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm i915 hangs on heavy io load
Hi Chris,
I haven't answered due to several reboots necessary (sometimes
I have to work on Win***) and no effect, but ..
On Mi, 24 Okt 2012, Chris Wilson wrote:
> > > http://cgit.freedesktop.org/~danvet/drm/commit/?h=ilk-wa-pile=0d5fed2de763b49bb1a90140758153481f043757
> > > is the missing ingredient.
> >
> > I am compiling a kernel with this patch based on current git now.
> > Should I still use the above kernel cmd argument (i915...rc6=0)
> > or try without it?
>
> Without any rc6 parameter would be best. But if rc6=0 wasn't the
> solution for you, then I may have identified the wrong w/a. Can I ask
> you try the patches in that branch until you find one (or more perhaps)
> that stabilise your system?
I pulled the whole branch into my compile branch, and removed everything
from kernel cmd line regarding rc6, and got the
[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[drm] capturing error event; look for more information in
/debug/dri/0/i915_error_state
[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged!
[drm:i915_reset] *ERROR* Failed to reset chip.
new i915_error_state.gz at the same place.
So it seems that the patches in the ilk-wa-pile branch do not help.
All the best
Norbert
----
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
SCRONKEY (n.)
Something that hits the window as a result of a violent sneeze.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drm i915 hangs on heavy io load
Hi Chris,
I haven't answered due to several reboots necessary (sometimes
I have to work on Win***) and no effect, but ..
On Mi, 24 Okt 2012, Chris Wilson wrote:
http://cgit.freedesktop.org/~danvet/drm/commit/?h=ilk-wa-pileid=0d5fed2de763b49bb1a90140758153481f043757
is the missing ingredient.
I am compiling a kernel with this patch based on current git now.
Should I still use the above kernel cmd argument (i915...rc6=0)
or try without it?
Without any rc6 parameter would be best. But if rc6=0 wasn't the
solution for you, then I may have identified the wrong w/a. Can I ask
you try the patches in that branch until you find one (or more perhaps)
that stabilise your system?
I pulled the whole branch into my compile branch, and removed everything
from kernel cmd line regarding rc6, and got the
[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[drm] capturing error event; look for more information in
/debug/dri/0/i915_error_state
[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged!
[drm:i915_reset] *ERROR* Failed to reset chip.
new i915_error_state.gz at the same place.
So it seems that the patches in the ilk-wa-pile branch do not help.
All the best
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
SCRONKEY (n.)
Something that hits the window as a result of a violent sneeze.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drm i915 hangs on heavy io load
Hi Dave, hi Chris,
thanks for your answers.
On Di, 23 Okt 2012, Dave Airlie wrote:
> Does booting with i915.i915_enable_rc6=0 help?
No,booted with that, it happened again on a completely idle
system (well, I believe completely idle, I was doing the
dishes ;-)
[12437.995026] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU
hung
[12437.995034] [drm] capturing error event; look for more information in
/debug/dri/0/i915_error_state
[12438.000213] [drm:init_ring_common] *ERROR* failed to set render ring head to
zero ctl head 5ee06f14 tail start 3000
[12438.054894] [drm:init_ring_common] *ERROR* render ring initialization failed
ctl 0001f001 head 5ee06f14 tail start 3000
[12439.583064] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU
hung
[12439.583176] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged!
[12439.583182] [drm:i915_reset] *ERROR* Failed to reset chip.
New output see here:
http://www.logic.at/people/preining/i915_error_state.gz
> http://cgit.freedesktop.org/~danvet/drm/commit/?h=ilk-wa-pile=0d5fed2de763b49bb1a90140758153481f043757
> is the missing ingredient.
I am compiling a kernel with this patch based on current git now.
Should I still use the above kernel cmd argument (i915...rc6=0)
or try without it?
Best wishes
Norbert
----
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
What are you talking about?
Never mind, eat the fruit.
You know, this place almost looks like the Garden of Eden.
Eat the fruit.
Sounds quite like it too.
--- Douglas Adams, The Hitchhikers Guide to the Galaxy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drm i915 hangs on heavy io load
Hi Dave,
(switched to freedesktop for dri-dvel)
> Does booting with i915.i915_enable_rc6=0 help?
Will try immediately.
> (Daniel, looks like an ironlake).
Sorry, I forgot that one ... how stupid>
>From XOrg.0.log:
...
[ 13535.841] (II) intel(0): Integrated Graphics Chipset: Intel(R) Arrandale
[ 13535.841] (--) intel(0): Chipset: "Arrandale"
...
00:02.0 0300: 8086:0046 (rev 02) (prog-if 00 [VGA controller])
Subsystem: 17aa:215a
Flags: bus master, fast devsel, latency 0, IRQ 42
Memory at f000 (64-bit, non-prefetchable) [size=4M]
Memory at d000 (64-bit, prefetchable) [size=256M]
I/O ports at 1800 [size=8]
Expansion ROM at [disabled]
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
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated
Graphics Controller (rev 02)
Does that make any differences?
Best wishes
Norbert
--------
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
WIKE (vb.)
To rip a piece of sticky plaster off your skin as fast as possible in
the hope that it will (a) show how brave you are, and (b) not hurt.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
drm i915 hangs on heavy io load
Hi everyone,
(please Cc)
I am running 3.7-rc2 and got recently hit a few times (under rc1, too)
by hanging drm i915 while doing large io operations.
The efect in the dmesg:
[13193.297751] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU
hung
[13193.297758] [drm] capturing error event; look for more information in
/debug/dri/0/i915_error_state
[13193.302728] [drm:init_ring_common] *ERROR* failed to set render ring head to
zero ctl head 85a05e3c tail start 3000
[13193.357584] [drm:init_ring_common] *ERROR* render ring initialization failed
ctl 0001f001 head 85a05e3c tail start 3000
[13194.861769] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU
hung
[13194.861838] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged!
[13194.861840] [drm:i915_reset] *ERROR* Failed to reset chip.
I captured the i915_error_state and uploaded it here:
http://www.logic.at/people/preining/drm_i915_error_state.gz
The hangs have been normally initiated on svn up in a very big
repository, or git checkout on a very big repository or so.
Other system is Debian/unstable. The above output and error state is
from after a reboot without any suspends or other tricks inbetween,
uptime 3.5h.
Best wishes and thanks for any suggestions
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
CORRIEMOILLIE (n.)
The dreadful sinking sensation in a long passageway encounter when
both protagonists immediately realise they have plumped for the
corriedoo (q.v.) much too early as they are still a good thirty yards
apart. They were embarrassed by the pretence of corriecravie (q.v.)
and decided to make use of the corriedoo because they felt silly. This
was a mistake as corrievorrie (q.v.) will make them seem far sillier.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
drm i915 hangs on heavy io load
Hi everyone,
(please Cc)
I am running 3.7-rc2 and got recently hit a few times (under rc1, too)
by hanging drm i915 while doing large io operations.
The efect in the dmesg:
[13193.297751] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU
hung
[13193.297758] [drm] capturing error event; look for more information in
/debug/dri/0/i915_error_state
[13193.302728] [drm:init_ring_common] *ERROR* failed to set render ring head to
zero ctl head 85a05e3c tail start 3000
[13193.357584] [drm:init_ring_common] *ERROR* render ring initialization failed
ctl 0001f001 head 85a05e3c tail start 3000
[13194.861769] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU
hung
[13194.861838] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged!
[13194.861840] [drm:i915_reset] *ERROR* Failed to reset chip.
I captured the i915_error_state and uploaded it here:
http://www.logic.at/people/preining/drm_i915_error_state.gz
The hangs have been normally initiated on svn up in a very big
repository, or git checkout on a very big repository or so.
Other system is Debian/unstable. The above output and error state is
from after a reboot without any suspends or other tricks inbetween,
uptime 3.5h.
Best wishes and thanks for any suggestions
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
CORRIEMOILLIE (n.)
The dreadful sinking sensation in a long passageway encounter when
both protagonists immediately realise they have plumped for the
corriedoo (q.v.) much too early as they are still a good thirty yards
apart. They were embarrassed by the pretence of corriecravie (q.v.)
and decided to make use of the corriedoo because they felt silly. This
was a mistake as corrievorrie (q.v.) will make them seem far sillier.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drm i915 hangs on heavy io load
Hi Dave,
(switched to freedesktop for dri-dvel)
Does booting with i915.i915_enable_rc6=0 help?
Will try immediately.
(Daniel, looks like an ironlake).
Sorry, I forgot that one ... how stupid
From XOrg.0.log:
...
[ 13535.841] (II) intel(0): Integrated Graphics Chipset: Intel(R) Arrandale
[ 13535.841] (--) intel(0): Chipset: Arrandale
...
00:02.0 0300: 8086:0046 (rev 02) (prog-if 00 [VGA controller])
Subsystem: 17aa:215a
Flags: bus master, fast devsel, latency 0, IRQ 42
Memory at f000 (64-bit, non-prefetchable) [size=4M]
Memory at d000 (64-bit, prefetchable) [size=256M]
I/O ports at 1800 [size=8]
Expansion ROM at unassigned [disabled]
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
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated
Graphics Controller (rev 02)
Does that make any differences?
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
WIKE (vb.)
To rip a piece of sticky plaster off your skin as fast as possible in
the hope that it will (a) show how brave you are, and (b) not hurt.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drm i915 hangs on heavy io load
Hi Dave, hi Chris,
thanks for your answers.
On Di, 23 Okt 2012, Dave Airlie wrote:
Does booting with i915.i915_enable_rc6=0 help?
No,booted with that, it happened again on a completely idle
system (well, I believe completely idle, I was doing the
dishes ;-)
[12437.995026] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU
hung
[12437.995034] [drm] capturing error event; look for more information in
/debug/dri/0/i915_error_state
[12438.000213] [drm:init_ring_common] *ERROR* failed to set render ring head to
zero ctl head 5ee06f14 tail start 3000
[12438.054894] [drm:init_ring_common] *ERROR* render ring initialization failed
ctl 0001f001 head 5ee06f14 tail start 3000
[12439.583064] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU
hung
[12439.583176] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged!
[12439.583182] [drm:i915_reset] *ERROR* Failed to reset chip.
New output see here:
http://www.logic.at/people/preining/i915_error_state.gz
http://cgit.freedesktop.org/~danvet/drm/commit/?h=ilk-wa-pileid=0d5fed2de763b49bb1a90140758153481f043757
is the missing ingredient.
I am compiling a kernel with this patch based on current git now.
Should I still use the above kernel cmd argument (i915...rc6=0)
or try without it?
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
What are you talking about?
Never mind, eat the fruit.
You know, this place almost looks like the Garden of Eden.
Eat the fruit.
Sounds quite like it too.
--- Douglas Adams, The Hitchhikers Guide to the Galaxy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: rtl8192se: ping router gives mdev of 25387.102???
Hi Larry, hi all,
On Fr, 14 Sep 2012, wrote:
> I am running on top of default kernel git, will try wireless-testing, too.
I tried now with wireless-testing from yesterday, and had the same problem.
Actually, I got even *better* results:
64 bytes from 192.168.0.1: icmp_req=75 ttl=255 time=137856 ms
64 bytes from 192.168.0.1: icmp_req=76 ttl=255 time=136848 ms
64 bytes from 192.168.0.1: icmp_req=78 ttl=255 time=134943 ms
...
rtt min/avg/max/mdev = 1.110/46967.879/137856.232/49666.671 ms, pipe 138
So now we are mdev of 50secs sometimes ;-)
Another interesting things:
At home I have the problems with the NEC router, but I am now at
the university. I am writing this email over a very very stable
ssh link to another server.
Here is the output iof ifconfig:
$ ifconfig
eth0 Link encap:Ethernet HWaddr 60:eb:69:c9:0c:ea
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
loLink encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:20418 errors:0 dropped:0 overruns:0 frame:0
TX packets:20418 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1950587 (1.8 MiB) TX bytes:1950587 (1.8 MiB)
wlan0 Link encap:Ethernet HWaddr 88:9f:fa:f9:07:28
inet addr:150.65.206.200 Bcast:150.65.207.255 Mask:255.255.252.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:232640 errors:0 dropped:1 overruns:0 frame:0
TX packets:69798 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:85599897 (81.6 MiB) TX bytes:8925832 (8.5 MiB)
But the kernel is convinced that I am not connected ...:
$ iw dev wlan0 link
Not connected.
$ iwconfig wlan0
wlan0 IEEE 802.11bgn ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=20 dBm
Retry long limit:7 RTS thr=2347 B Fragment thr:off
Encryption key:off
Power Management:off
And no, I guarantee you there is no ethernet cable plugged in ;-)
I can only assume that is a problem with iwconfig/iw being too old,
although according to the output of iwconfig it is fine:
# iw --version
iw version 3.4
# iwconfig --version
iwconfig Wireless-Tools version 30
Compatible with Wireless Extension v11 to v22.
KernelCurrently compiled with Wireless Extension v22.
wlan0 Recommend Wireless Extension v21 or later,
Currently compiled with Wireless Extension v22.
# uname -a
Linux tofuschnitzel 3.6.0-rc5-wl+ #19 SMP PREEMPT Fri Sep 14 13:14:15 JST 2012
x86_64 GNU/Linux
Best wishes
Norbert
----
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
CHICAGO (n.)
The foul-smelling wind which precedes an underground railway train.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: rtl8192se: ping router gives mdev of 25387.102???
Hi Larry, hi all,
On Fr, 14 Sep 2012, wrote:
I am running on top of default kernel git, will try wireless-testing, too.
I tried now with wireless-testing from yesterday, and had the same problem.
Actually, I got even *better* results:
64 bytes from 192.168.0.1: icmp_req=75 ttl=255 time=137856 ms
64 bytes from 192.168.0.1: icmp_req=76 ttl=255 time=136848 ms
64 bytes from 192.168.0.1: icmp_req=78 ttl=255 time=134943 ms
...
rtt min/avg/max/mdev = 1.110/46967.879/137856.232/49666.671 ms, pipe 138
So now we are mdev of 50secs sometimes ;-)
Another interesting things:
At home I have the problems with the NEC router, but I am now at
the university. I am writing this email over a very very stable
ssh link to another server.
Here is the output iof ifconfig:
$ ifconfig
eth0 Link encap:Ethernet HWaddr 60:eb:69:c9:0c:ea
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
loLink encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:20418 errors:0 dropped:0 overruns:0 frame:0
TX packets:20418 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1950587 (1.8 MiB) TX bytes:1950587 (1.8 MiB)
wlan0 Link encap:Ethernet HWaddr 88:9f:fa:f9:07:28
inet addr:150.65.206.200 Bcast:150.65.207.255 Mask:255.255.252.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:232640 errors:0 dropped:1 overruns:0 frame:0
TX packets:69798 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:85599897 (81.6 MiB) TX bytes:8925832 (8.5 MiB)
But the kernel is convinced that I am not connected ...:
$ iw dev wlan0 link
Not connected.
$ iwconfig wlan0
wlan0 IEEE 802.11bgn ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=20 dBm
Retry long limit:7 RTS thr=2347 B Fragment thr:off
Encryption key:off
Power Management:off
And no, I guarantee you there is no ethernet cable plugged in ;-)
I can only assume that is a problem with iwconfig/iw being too old,
although according to the output of iwconfig it is fine:
# iw --version
iw version 3.4
# iwconfig --version
iwconfig Wireless-Tools version 30
Compatible with Wireless Extension v11 to v22.
KernelCurrently compiled with Wireless Extension v22.
wlan0 Recommend Wireless Extension v21 or later,
Currently compiled with Wireless Extension v22.
# uname -a
Linux tofuschnitzel 3.6.0-rc5-wl+ #19 SMP PREEMPT Fri Sep 14 13:14:15 JST 2012
x86_64 GNU/Linux
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
CHICAGO (n.)
The foul-smelling wind which precedes an underground railway train.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: rtl8192se: ping router gives mdev of 25387.102???
Hi Larry,
thanks for the answer, here some more information as requested
AP infos:distance: 3m
NEC Aterm WR8600N ATERM-B45459
firmware 1.0.11
Network card is built in into a Lenovo Thinkpad Edge
# lspci -nnv -s 03:00.0
03:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8191SEvB
Wireless LAN Controller [10ec:8172] (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. Device [10ec:e020]
Flags: bus master, fast devsel, latency 0, IRQ 17
I/O ports at 2000 [size=256]
Memory at f050 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 88-55-22-fe-ff-4c-e0-00
Kernel driver in use: rtl8192se
# iwconfig wlan0
wlan0 IEEE 802.11bgn ESSID:"norbujp"
Mode:Managed Frequency:2.442 GHz Access Point: 00:3A:9D:B4:54:5A
Bit Rate=150 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr=2347 B Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=70/70 Signal level=-35 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:9 Missed beacon:0
at this point there is according to ifconfig/iwconfig a connection
up and running, but ping tells me:
# ping 192.168.0.1
...
>From 192.168.0.2 icmp_seq=77 Destination Host Unreachable
..
I tried with network-manager as well as without and wpa_supplicant
directly, no change.
Also removing the module and reloading it did not help.
On Thu, 13 Sep 2012, Larry Finger wrote:
> the details of your AP - STA configuration. What is the distance? Is
I think it is pretty standard WPA-PSK, is there anything more I can
tell you, please let me know.
> it 802.11n or 802.11g? What is the signal strength as indicated by
> iwconfig or a scan?
See above.
> From what you posted earlier, I think your card is like my Cards 1 &
> 3, but the PCI ID will tell for sure. These tests were run with
> commit 0a92aec2f22d of wireless-testing. There are some test patches
> installed, but non of them affect rtl8192se.
I am running on top of default kernel git, will try wireless-testing, too.
Thanks a lot and all the best, and let me know what I can provide more!
Norbert
--------
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live and Debian Developer
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
IPING (participial vb.)
The increasingly anxious shifting from leg to leg you go through when
you are desperate to go to the lavatory and the person you are talking
to keeps on remembering a few final things he want to mention.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
rtl8192se: ping router gives mdev of 25387.102???
Hi everyone,
(please cc)
see $subject ...
No warning, nothing in the logs, but pinging my router I get
things like:
--- 192.168.0.1 ping statistics ---
376 packets transmitted, 315 received, +33 errors, 16% packet loss, time
405164ms
rtt min/avg/max/mdev = 0.873/10077.793/95935.698/25387.102 ms, pipe 68
or
--- 192.168.0.1 ping statistics ---
1252 packets transmitted, 1225 received, 2% packet loss, time 1252976ms
rtt min/avg/max/mdev = 0.941/764.171/19929.265/2758.225 ms, pipe 20
Has anyone *ever* seen a mdev of 25387.102 ms ???
At the same time I am pinging the same router from an iphone with a
steady stream of 40ms or so, no problem whatsoever ...
$ lspci -v -s 03:00.0
03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8191SEvB
Wireless LAN Controller (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. Device e020
Flags: bus master, fast devsel, latency 0, IRQ 17
I/O ports at 2000 [size=256]
Memory at f050 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 88-55-22-fe-ff-4c-e0-00
Kernel driver in use: rtl8192se
That is with git from yesterday or so.
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live and Debian Developer
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
`Ford, you're turning into a penguin. Stop it.'
--- Arthur experiences the improbability drive at work.
--- Douglas Adams, The Hitchhikers Guide to the Galaxy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
rtl8192se: ping router gives mdev of 25387.102???
Hi everyone,
(please cc)
see $subject ...
No warning, nothing in the logs, but pinging my router I get
things like:
--- 192.168.0.1 ping statistics ---
376 packets transmitted, 315 received, +33 errors, 16% packet loss, time
405164ms
rtt min/avg/max/mdev = 0.873/10077.793/95935.698/25387.102 ms, pipe 68
or
--- 192.168.0.1 ping statistics ---
1252 packets transmitted, 1225 received, 2% packet loss, time 1252976ms
rtt min/avg/max/mdev = 0.941/764.171/19929.265/2758.225 ms, pipe 20
Has anyone *ever* seen a mdev of 25387.102 ms ???
At the same time I am pinging the same router from an iphone with a
steady stream of 40ms or so, no problem whatsoever ...
$ lspci -v -s 03:00.0
03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8191SEvB
Wireless LAN Controller (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. Device e020
Flags: bus master, fast devsel, latency 0, IRQ 17
I/O ports at 2000 [size=256]
Memory at f050 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 88-55-22-fe-ff-4c-e0-00
Kernel driver in use: rtl8192se
That is with git from yesterday or so.
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live and Debian Developer
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
`Ford, you're turning into a penguin. Stop it.'
--- Arthur experiences the improbability drive at work.
--- Douglas Adams, The Hitchhikers Guide to the Galaxy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: rtl8192se: ping router gives mdev of 25387.102???
Hi Larry,
thanks for the answer, here some more information as requested
AP infos:distance: 3m
NEC Aterm WR8600N ATERM-B45459
firmware 1.0.11
Network card is built in into a Lenovo Thinkpad Edge
# lspci -nnv -s 03:00.0
03:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8191SEvB
Wireless LAN Controller [10ec:8172] (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. Device [10ec:e020]
Flags: bus master, fast devsel, latency 0, IRQ 17
I/O ports at 2000 [size=256]
Memory at f050 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 88-55-22-fe-ff-4c-e0-00
Kernel driver in use: rtl8192se
# iwconfig wlan0
wlan0 IEEE 802.11bgn ESSID:norbujp
Mode:Managed Frequency:2.442 GHz Access Point: 00:3A:9D:B4:54:5A
Bit Rate=150 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr=2347 B Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=70/70 Signal level=-35 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:9 Missed beacon:0
at this point there is according to ifconfig/iwconfig a connection
up and running, but ping tells me:
# ping 192.168.0.1
...
From 192.168.0.2 icmp_seq=77 Destination Host Unreachable
..
I tried with network-manager as well as without and wpa_supplicant
directly, no change.
Also removing the module and reloading it did not help.
On Thu, 13 Sep 2012, Larry Finger wrote:
the details of your AP - STA configuration. What is the distance? Is
I think it is pretty standard WPA-PSK, is there anything more I can
tell you, please let me know.
it 802.11n or 802.11g? What is the signal strength as indicated by
iwconfig or a scan?
See above.
From what you posted earlier, I think your card is like my Cards 1
3, but the PCI ID will tell for sure. These tests were run with
commit 0a92aec2f22d of wireless-testing. There are some test patches
installed, but non of them affect rtl8192se.
I am running on top of default kernel git, will try wireless-testing, too.
Thanks a lot and all the best, and let me know what I can provide more!
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live and Debian Developer
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
IPING (participial vb.)
The increasingly anxious shifting from leg to leg you go through when
you are desperate to go to the lavatory and the person you are talking
to keeps on remembering a few final things he want to mention.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: rtl8192se hanging completely
Hi all, (please cc) I have now changed my home router and with the new one it is working without problems at home, and with a few hickups at work, too. But still, at work after some time the connection breaks. I found the following interesting messages in the log: dmar: DRHD: handling fault status reg 3 dmar: DMAR:[DMA Read] Request device [03:00.0] fault addr fff73000 DMAR:[fault reason 06] PTE Read access is not set around the time the connection hangs and never comes back. The mentioned device 03:00.0 is the wlan adapter: $ lspci -v -s 03:00.0 03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8191SEvB Wireless LAN Controller (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. Device e020 Flags: bus master, fast devsel, latency 0, IRQ 17 I/O ports at 2000 [size=256] Memory at f050 (32-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Legacy Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Device Serial Number 88-55-22-fe-ff-4c-e0-00 Kernel driver in use: rtl8192se $ That is with latest git kernel from yesterday. Any suggestions would be appreciated. On Wed, 22 Aug 2012, Norbert Preining wrote: > Dear all, > > (please cc) > > I am having serious troubles with my rtl8192se card: > > kernel: 3.6.0-rc2+, compiled from git today, same with rc1 > rtl8192se in kernel driver, loaded with debug=3 > Debian sid > Lenovo Thinkpad Edge > > When starting from cold boot, the driver associates, but no packet > whatsoever leaves the computer it seems, pinging the gateway > does not return anything, and ns lookups are not working. > > In the logs I see many instances of: > rtlwifi:rtl_tx_agg_start():<0-0> on ra = 00:0a:79:eb:56:10 tid = 6 seq:39 > rtlwifi:rtl_action_proc():<200-1> Tx ACT_ADDBAREQ From :88:9f:fa:f9:07:28 > rtlwifi:rtl_tx_agg_stop():<0-0> on ra = 00:0a:79:eb:56:10 tid = 6 > rtlwifi:rtl_action_proc():<400-1> ACT_ADDBADEL From :88:9f:fa:f9:07:28 > rtlwifi:rtl_action_proc():<1-1> Rx ACT_ADDBARSP From :00:0a:79:eb:56:10 > in various orders. > > > trying to remove the module gave me: > [ 649.459652] wlan0: deauthenticating from 00:0a:79:eb:56:10 by local choice > (reason=3) > [ 649.459701] rtlwifi:rtl_tx_agg_stop():<0-0> on ra = 00:0a:79:eb:56:10 tid > = 0 > [ 659.094654] rtlwifi:rtl_op_set_key():<0-0> Disabling hardware based > encryption for keyidx: 0, mac: 00:0a:79:eb:56:10 > [ 659.094659] rtlwifi:rtl_op_set_key():<0-0> alg:CCMP > [ 659.094663] rtlwifi:rtl_op_set_key():<0-0> set enable_hw_sec, > key_type:4(OPEN:0 WEP40:1 TKIP:2 AES:4 WEP104:5) > [ 659.094667] rtlwifi:rtl_op_set_key():<0-0> disable key delete one entry > [ 659.094670] rtlwifi:rtl_cam_delete_one_entry():<0-0> key_idx:0 > [ 659.094673] rtlwifi:rtl_cam_delete_one_entry():<0-0> > rtl_cam_delete_one_entry(): WRITE A4: 0 > [ 659.094676] rtlwifi:rtl_cam_delete_one_entry():<0-0> > rtl_cam_delete_one_entry(): WRITE A0: 8001 > [ 659.094719] rtlwifi:rtl_op_sta_remove():<0-0> Remove sta addr is > 00:0a:79:eb:56:10 > [ 659.142712] rtlwifi:rtl_op_bss_info_changed():<0-0> BSS_CHANGED_UN_ASSOC > [ 659.142725] rtlwifi:rtl_op_bss_info_changed():<0-0> 00:00:00:00:00:00 > [ 659.190740] rtlwifi:rtl_op_set_key():<0-0> Disabling hardware based > encryption for keyidx: 1, mac: ff:ff:ff:ff:ff:ff > [ 659.190744] rtlwifi:rtl_op_set_key():<0-0> alg:TKIP > [ 659.190747] rtlwifi:rtl_op_set_key():<0-0> set enable_hw_sec, > key_type:2(OPEN:0 WEP40:1 TKIP:2 AES:4 WEP104:5) > [ 659.190750] rtlwifi:rtl_op_set_key():<0-0> disable key delete one entry > [ 659.190753] rtlwifi:rtl_cam_delete_one_entry():<0-0> key_idx:1 > [ 659.190756] rtlwifi:rtl_cam_delete_one_entry():<0-0> > rtl_cam_delete_one_entry(): WRITE A4: 0 > [ 659.190759] rtlwifi:rtl_cam_delete_one_entry():<0-0> > rtl_cam_delete_one_entry(): WRITE A0: 80010008 > > > After that I reloaded the module and then it is getting worse: > rtl8192se :03:00.0: Refused to change power state, currently in D3 > rtl8192se:_rtl92se_read_adapter_info():<0-0> RTL819X Not boot from eeprom, > check it !! > tl8192se: FW Power Save off (module option) > rtl8192se: Driver for Realtek RTL8192SE/RTL8191SE > Loading firmware rtlwifi/rtl8192sefw.bin > ... > rtl8192se:_rtl92se_macconfig_after_fwdownload():<0-0> OK > rtl8192se:rtl92s_phy_bb_config():<0-0> RF_Type(0) does not match RF_Num(4)!! > rtl8192se:rtl92s_phy_bb_config():<0-0&
Re: rtl8192se hanging completely
Hi all, (please cc) I have now changed my home router and with the new one it is working without problems at home, and with a few hickups at work, too. But still, at work after some time the connection breaks. I found the following interesting messages in the log: dmar: DRHD: handling fault status reg 3 dmar: DMAR:[DMA Read] Request device [03:00.0] fault addr fff73000 DMAR:[fault reason 06] PTE Read access is not set around the time the connection hangs and never comes back. The mentioned device 03:00.0 is the wlan adapter: $ lspci -v -s 03:00.0 03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8191SEvB Wireless LAN Controller (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. Device e020 Flags: bus master, fast devsel, latency 0, IRQ 17 I/O ports at 2000 [size=256] Memory at f050 (32-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Legacy Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Device Serial Number 88-55-22-fe-ff-4c-e0-00 Kernel driver in use: rtl8192se $ That is with latest git kernel from yesterday. Any suggestions would be appreciated. On Wed, 22 Aug 2012, Norbert Preining wrote: Dear all, (please cc) I am having serious troubles with my rtl8192se card: kernel: 3.6.0-rc2+, compiled from git today, same with rc1 rtl8192se in kernel driver, loaded with debug=3 Debian sid Lenovo Thinkpad Edge When starting from cold boot, the driver associates, but no packet whatsoever leaves the computer it seems, pinging the gateway does not return anything, and ns lookups are not working. In the logs I see many instances of: rtlwifi:rtl_tx_agg_start():0-0 on ra = 00:0a:79:eb:56:10 tid = 6 seq:39 rtlwifi:rtl_action_proc():200-1 Tx ACT_ADDBAREQ From :88:9f:fa:f9:07:28 rtlwifi:rtl_tx_agg_stop():0-0 on ra = 00:0a:79:eb:56:10 tid = 6 rtlwifi:rtl_action_proc():400-1 ACT_ADDBADEL From :88:9f:fa:f9:07:28 rtlwifi:rtl_action_proc():1-1 Rx ACT_ADDBARSP From :00:0a:79:eb:56:10 in various orders. trying to remove the module gave me: [ 649.459652] wlan0: deauthenticating from 00:0a:79:eb:56:10 by local choice (reason=3) [ 649.459701] rtlwifi:rtl_tx_agg_stop():0-0 on ra = 00:0a:79:eb:56:10 tid = 0 [ 659.094654] rtlwifi:rtl_op_set_key():0-0 Disabling hardware based encryption for keyidx: 0, mac: 00:0a:79:eb:56:10 [ 659.094659] rtlwifi:rtl_op_set_key():0-0 alg:CCMP [ 659.094663] rtlwifi:rtl_op_set_key():0-0 set enable_hw_sec, key_type:4(OPEN:0 WEP40:1 TKIP:2 AES:4 WEP104:5) [ 659.094667] rtlwifi:rtl_op_set_key():0-0 disable key delete one entry [ 659.094670] rtlwifi:rtl_cam_delete_one_entry():0-0 key_idx:0 [ 659.094673] rtlwifi:rtl_cam_delete_one_entry():0-0 rtl_cam_delete_one_entry(): WRITE A4: 0 [ 659.094676] rtlwifi:rtl_cam_delete_one_entry():0-0 rtl_cam_delete_one_entry(): WRITE A0: 8001 [ 659.094719] rtlwifi:rtl_op_sta_remove():0-0 Remove sta addr is 00:0a:79:eb:56:10 [ 659.142712] rtlwifi:rtl_op_bss_info_changed():0-0 BSS_CHANGED_UN_ASSOC [ 659.142725] rtlwifi:rtl_op_bss_info_changed():0-0 00:00:00:00:00:00 [ 659.190740] rtlwifi:rtl_op_set_key():0-0 Disabling hardware based encryption for keyidx: 1, mac: ff:ff:ff:ff:ff:ff [ 659.190744] rtlwifi:rtl_op_set_key():0-0 alg:TKIP [ 659.190747] rtlwifi:rtl_op_set_key():0-0 set enable_hw_sec, key_type:2(OPEN:0 WEP40:1 TKIP:2 AES:4 WEP104:5) [ 659.190750] rtlwifi:rtl_op_set_key():0-0 disable key delete one entry [ 659.190753] rtlwifi:rtl_cam_delete_one_entry():0-0 key_idx:1 [ 659.190756] rtlwifi:rtl_cam_delete_one_entry():0-0 rtl_cam_delete_one_entry(): WRITE A4: 0 [ 659.190759] rtlwifi:rtl_cam_delete_one_entry():0-0 rtl_cam_delete_one_entry(): WRITE A0: 80010008 After that I reloaded the module and then it is getting worse: rtl8192se :03:00.0: Refused to change power state, currently in D3 rtl8192se:_rtl92se_read_adapter_info():0-0 RTL819X Not boot from eeprom, check it !! tl8192se: FW Power Save off (module option) rtl8192se: Driver for Realtek RTL8192SE/RTL8191SE Loading firmware rtlwifi/rtl8192sefw.bin ... rtl8192se:_rtl92se_macconfig_after_fwdownload():0-0 OK rtl8192se:rtl92s_phy_bb_config():0-0 RF_Type(0) does not match RF_Num(4)!! rtl8192se:rtl92s_phy_bb_config():0-0 path1 0xf, path2 0xf, pathmap 0xf rtlwifi:rtl_pci_start():0-0 OK rtl8192se:rtl92s_phy_chk_fwcmd_iodone():0-0 Set FW Cmd fail!! rtl8192se:rtl92s_phy_chk_fwcmd_iodone():0-0 Set FW Cmd fail!! rtl8192se:rtl92s_phy_set_rf_power_state():0-0 IPS Set eRf nic disable rtl8192se:rtl92s_phy_set_rf_power_state():0-1 IPS Set eRf nic enable rtl8192se:_rtl92se_macconfig_after_fwdownload():0-1 OK ... rtl8192se:rtl92s_phy_chk_fwcmd_iodone():0-0 Set FW Cmd fail!! rtlwifi:rtl_pci_tx():200-1
rtl8192se hanging completely
Dear all,
(please cc)
I am having serious troubles with my rtl8192se card:
kernel: 3.6.0-rc2+, compiled from git today, same with rc1
rtl8192se in kernel driver, loaded with debug=3
Debian sid
Lenovo Thinkpad Edge
When starting from cold boot, the driver associates, but no packet
whatsoever leaves the computer it seems, pinging the gateway
does not return anything, and ns lookups are not working.
In the logs I see many instances of:
rtlwifi:rtl_tx_agg_start():<0-0> on ra = 00:0a:79:eb:56:10 tid = 6 seq:39
rtlwifi:rtl_action_proc():<200-1> Tx ACT_ADDBAREQ From :88:9f:fa:f9:07:28
rtlwifi:rtl_tx_agg_stop():<0-0> on ra = 00:0a:79:eb:56:10 tid = 6
rtlwifi:rtl_action_proc():<400-1> ACT_ADDBADEL From :88:9f:fa:f9:07:28
rtlwifi:rtl_action_proc():<1-1> Rx ACT_ADDBARSP From :00:0a:79:eb:56:10
in various orders.
trying to remove the module gave me:
[ 649.459652] wlan0: deauthenticating from 00:0a:79:eb:56:10 by local choice
(reason=3)
[ 649.459701] rtlwifi:rtl_tx_agg_stop():<0-0> on ra = 00:0a:79:eb:56:10 tid = 0
[ 659.094654] rtlwifi:rtl_op_set_key():<0-0> Disabling hardware based
encryption for keyidx: 0, mac: 00:0a:79:eb:56:10
[ 659.094659] rtlwifi:rtl_op_set_key():<0-0> alg:CCMP
[ 659.094663] rtlwifi:rtl_op_set_key():<0-0> set enable_hw_sec,
key_type:4(OPEN:0 WEP40:1 TKIP:2 AES:4 WEP104:5)
[ 659.094667] rtlwifi:rtl_op_set_key():<0-0> disable key delete one entry
[ 659.094670] rtlwifi:rtl_cam_delete_one_entry():<0-0> key_idx:0
[ 659.094673] rtlwifi:rtl_cam_delete_one_entry():<0-0>
rtl_cam_delete_one_entry(): WRITE A4: 0
[ 659.094676] rtlwifi:rtl_cam_delete_one_entry():<0-0>
rtl_cam_delete_one_entry(): WRITE A0: 8001
[ 659.094719] rtlwifi:rtl_op_sta_remove():<0-0> Remove sta addr is
00:0a:79:eb:56:10
[ 659.142712] rtlwifi:rtl_op_bss_info_changed():<0-0> BSS_CHANGED_UN_ASSOC
[ 659.142725] rtlwifi:rtl_op_bss_info_changed():<0-0> 00:00:00:00:00:00
[ 659.190740] rtlwifi:rtl_op_set_key():<0-0> Disabling hardware based
encryption for keyidx: 1, mac: ff:ff:ff:ff:ff:ff
[ 659.190744] rtlwifi:rtl_op_set_key():<0-0> alg:TKIP
[ 659.190747] rtlwifi:rtl_op_set_key():<0-0> set enable_hw_sec,
key_type:2(OPEN:0 WEP40:1 TKIP:2 AES:4 WEP104:5)
[ 659.190750] rtlwifi:rtl_op_set_key():<0-0> disable key delete one entry
[ 659.190753] rtlwifi:rtl_cam_delete_one_entry():<0-0> key_idx:1
[ 659.190756] rtlwifi:rtl_cam_delete_one_entry():<0-0>
rtl_cam_delete_one_entry(): WRITE A4: 0
[ 659.190759] rtlwifi:rtl_cam_delete_one_entry():<0-0>
rtl_cam_delete_one_entry(): WRITE A0: 80010008
After that I reloaded the module and then it is getting worse:
rtl8192se :03:00.0: Refused to change power state, currently in D3
rtl8192se:_rtl92se_read_adapter_info():<0-0> RTL819X Not boot from eeprom,
check it !!
tl8192se: FW Power Save off (module option)
rtl8192se: Driver for Realtek RTL8192SE/RTL8191SE
Loading firmware rtlwifi/rtl8192sefw.bin
...
rtl8192se:_rtl92se_macconfig_after_fwdownload():<0-0> OK
rtl8192se:rtl92s_phy_bb_config():<0-0> RF_Type(0) does not match RF_Num(4)!!
rtl8192se:rtl92s_phy_bb_config():<0-0> path1 0xf, path2 0xf, pathmap 0xf
rtlwifi:rtl_pci_start():<0-0> OK
rtl8192se:rtl92s_phy_chk_fwcmd_iodone():<0-0> Set FW Cmd fail!!
rtl8192se:rtl92s_phy_chk_fwcmd_iodone():<0-0> Set FW Cmd fail!!
rtl8192se:rtl92s_phy_set_rf_power_state():<0-0> IPS Set eRf nic disable
rtl8192se:rtl92s_phy_set_rf_power_state():<0-1> IPS Set eRf nic enable
rtl8192se:_rtl92se_macconfig_after_fwdownload():<0-1> OK
...
rtl8192se:rtl92s_phy_chk_fwcmd_iodone():<0-0> Set FW Cmd fail!!
rtlwifi:rtl_pci_tx():<200-1> No more TX desc@6, ring->idx = 0, idx = 0,
skb_queue_len = 0x0
etc etc.
That is the end, no connection at all, and no way (AFAIS) to get
it back.
Are there any suggestions, patches, ideas to fix and track that down?
THanks a lot
Norbert
(please cc)
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
MOTSPUR (n.)
The fourth wheel of a supermarket trolley which looks identical to the
other tree but renders the trolley completely uncontrollable.
MO I RANA Imagine being on a vacation, and it's raining all the time,
you are driving and the kids are making you a nervous wreck. Well you
are definitive in Mo i Rana.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
rtl8192se hanging completely
Dear all,
(please cc)
I am having serious troubles with my rtl8192se card:
kernel: 3.6.0-rc2+, compiled from git today, same with rc1
rtl8192se in kernel driver, loaded with debug=3
Debian sid
Lenovo Thinkpad Edge
When starting from cold boot, the driver associates, but no packet
whatsoever leaves the computer it seems, pinging the gateway
does not return anything, and ns lookups are not working.
In the logs I see many instances of:
rtlwifi:rtl_tx_agg_start():0-0 on ra = 00:0a:79:eb:56:10 tid = 6 seq:39
rtlwifi:rtl_action_proc():200-1 Tx ACT_ADDBAREQ From :88:9f:fa:f9:07:28
rtlwifi:rtl_tx_agg_stop():0-0 on ra = 00:0a:79:eb:56:10 tid = 6
rtlwifi:rtl_action_proc():400-1 ACT_ADDBADEL From :88:9f:fa:f9:07:28
rtlwifi:rtl_action_proc():1-1 Rx ACT_ADDBARSP From :00:0a:79:eb:56:10
in various orders.
trying to remove the module gave me:
[ 649.459652] wlan0: deauthenticating from 00:0a:79:eb:56:10 by local choice
(reason=3)
[ 649.459701] rtlwifi:rtl_tx_agg_stop():0-0 on ra = 00:0a:79:eb:56:10 tid = 0
[ 659.094654] rtlwifi:rtl_op_set_key():0-0 Disabling hardware based
encryption for keyidx: 0, mac: 00:0a:79:eb:56:10
[ 659.094659] rtlwifi:rtl_op_set_key():0-0 alg:CCMP
[ 659.094663] rtlwifi:rtl_op_set_key():0-0 set enable_hw_sec,
key_type:4(OPEN:0 WEP40:1 TKIP:2 AES:4 WEP104:5)
[ 659.094667] rtlwifi:rtl_op_set_key():0-0 disable key delete one entry
[ 659.094670] rtlwifi:rtl_cam_delete_one_entry():0-0 key_idx:0
[ 659.094673] rtlwifi:rtl_cam_delete_one_entry():0-0
rtl_cam_delete_one_entry(): WRITE A4: 0
[ 659.094676] rtlwifi:rtl_cam_delete_one_entry():0-0
rtl_cam_delete_one_entry(): WRITE A0: 8001
[ 659.094719] rtlwifi:rtl_op_sta_remove():0-0 Remove sta addr is
00:0a:79:eb:56:10
[ 659.142712] rtlwifi:rtl_op_bss_info_changed():0-0 BSS_CHANGED_UN_ASSOC
[ 659.142725] rtlwifi:rtl_op_bss_info_changed():0-0 00:00:00:00:00:00
[ 659.190740] rtlwifi:rtl_op_set_key():0-0 Disabling hardware based
encryption for keyidx: 1, mac: ff:ff:ff:ff:ff:ff
[ 659.190744] rtlwifi:rtl_op_set_key():0-0 alg:TKIP
[ 659.190747] rtlwifi:rtl_op_set_key():0-0 set enable_hw_sec,
key_type:2(OPEN:0 WEP40:1 TKIP:2 AES:4 WEP104:5)
[ 659.190750] rtlwifi:rtl_op_set_key():0-0 disable key delete one entry
[ 659.190753] rtlwifi:rtl_cam_delete_one_entry():0-0 key_idx:1
[ 659.190756] rtlwifi:rtl_cam_delete_one_entry():0-0
rtl_cam_delete_one_entry(): WRITE A4: 0
[ 659.190759] rtlwifi:rtl_cam_delete_one_entry():0-0
rtl_cam_delete_one_entry(): WRITE A0: 80010008
After that I reloaded the module and then it is getting worse:
rtl8192se :03:00.0: Refused to change power state, currently in D3
rtl8192se:_rtl92se_read_adapter_info():0-0 RTL819X Not boot from eeprom,
check it !!
tl8192se: FW Power Save off (module option)
rtl8192se: Driver for Realtek RTL8192SE/RTL8191SE
Loading firmware rtlwifi/rtl8192sefw.bin
...
rtl8192se:_rtl92se_macconfig_after_fwdownload():0-0 OK
rtl8192se:rtl92s_phy_bb_config():0-0 RF_Type(0) does not match RF_Num(4)!!
rtl8192se:rtl92s_phy_bb_config():0-0 path1 0xf, path2 0xf, pathmap 0xf
rtlwifi:rtl_pci_start():0-0 OK
rtl8192se:rtl92s_phy_chk_fwcmd_iodone():0-0 Set FW Cmd fail!!
rtl8192se:rtl92s_phy_chk_fwcmd_iodone():0-0 Set FW Cmd fail!!
rtl8192se:rtl92s_phy_set_rf_power_state():0-0 IPS Set eRf nic disable
rtl8192se:rtl92s_phy_set_rf_power_state():0-1 IPS Set eRf nic enable
rtl8192se:_rtl92se_macconfig_after_fwdownload():0-1 OK
...
rtl8192se:rtl92s_phy_chk_fwcmd_iodone():0-0 Set FW Cmd fail!!
rtlwifi:rtl_pci_tx():200-1 No more TX desc@6, ring-idx = 0, idx = 0,
skb_queue_len = 0x0
etc etc.
That is the end, no connection at all, and no way (AFAIS) to get
it back.
Are there any suggestions, patches, ideas to fix and track that down?
THanks a lot
Norbert
(please cc)
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
MOTSPUR (n.)
The fourth wheel of a supermarket trolley which looks identical to the
other tree but renders the trolley completely uncontrollable.
MO I RANA Imagine being on a vacation, and it's raining all the time,
you are driving and the kids are making you a nervous wreck. Well you
are definitive in Mo i Rana.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Ilw] Re: 3.4-rc2, ilwagn still most of the time completely unusable
Hi Johannes,
Sorry for the late reply, I was travelling around the world ...
I have now tested the =2 and =4 settings at home, with the following
outcome:
On Do, 12 Jul 2012, Johannes Berg wrote:
> With the latest, I've extended 11n_disable to have more bits.
>
> 11n_disable=1 will disable HT completely
> 11n_disable=2 will disable TX aggregation
> 11n_disable=4 will disable RX aggregation
11n_disabled=2:
lots of messages
Open BA session requested for 00:0a:79:eb:56:10 tid 0
BA request denied - HW unavailable for tid 0
and
Rx BA session stop requested for 00:0a:79:eb:56:10 tid 0 inititator reason: 0
Rx A-MPDU request on tid 0 result 0
Connection is stable for quite some time, but after 1-2 hours I got
a bad hang, grinding to a halt. pings to kernel.org gives 26%
packet loss, but the rest of the packets are fast 130ms
(Isn't that a strange thing - 25+% packet loss and all others are fast?)
I assume the packaet loss is related to the above messages.
11n_disabled=4:
lots of messages
Rx A-MPDU request on tid 0 result -22
and at some point ping timeouts of 80+ secs (!) and then total hang
(as far as I remember)
Best wishes
Norbert
--------
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
PERRANZABULOE (n.)
One of those spray things used to wet ironing with.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Ilw] Re: 3.4-rc2, ilwagn still most of the time completely unusable
Hi Johannes,
Sorry for the late reply, I was travelling around the world ...
I have now tested the =2 and =4 settings at home, with the following
outcome:
On Do, 12 Jul 2012, Johannes Berg wrote:
With the latest, I've extended 11n_disable to have more bits.
11n_disable=1 will disable HT completely
11n_disable=2 will disable TX aggregation
11n_disable=4 will disable RX aggregation
11n_disabled=2:
lots of messages
Open BA session requested for 00:0a:79:eb:56:10 tid 0
BA request denied - HW unavailable for tid 0
and
Rx BA session stop requested for 00:0a:79:eb:56:10 tid 0 inititator reason: 0
Rx A-MPDU request on tid 0 result 0
Connection is stable for quite some time, but after 1-2 hours I got
a bad hang, grinding to a halt. pings to kernel.org gives 26%
packet loss, but the rest of the packets are fast 130ms
(Isn't that a strange thing - 25+% packet loss and all others are fast?)
I assume the packaet loss is related to the above messages.
11n_disabled=4:
lots of messages
Rx A-MPDU request on tid 0 result -22
and at some point ping timeouts of 80+ secs (!) and then total hang
(as far as I remember)
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
PERRANZABULOE (n.)
One of those spray things used to wet ironing with.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: regression 918227bb -> -rc7: does not wake up from sleep
Hi all,
On Mo, 16 Jul 2012, Srivatsa S. Bhat wrote:
> Not sure if this is the same problem, but here is a discussion around
> a recent commit that broke resume. May be you can try out that patch?
>
> https://lkml.org/lkml/2012/7/16/113
Yes, works for me, too.
Thanks, and sorry for the noise.
Best wishes
Norbert
--------
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
Having been erased,
The document you're seeking
Must now be retyped.
--- Windows Error Haiku
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
