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
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&m=150579298505484&w=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
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&script=true&cardinfo= !! !!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 [0x5f
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&id=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
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/
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 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/
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 1127
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 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 "unsubscribe
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: /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/
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/
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/
RTL driver for RTL8191SEvB and/or wpa-supplicant really broken at times
om 00:3a:9d:b4:54:5a by local choice (reason=3) May 8 20:47:34 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00: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
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/
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: 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
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, > 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&id=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&id=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/
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/
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&
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: 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/
regression 918227bb -> -rc7: does not wake up from sleep
Hi everyone,
(please cc)
I recently upgraded from git918227bb to rc7 and suddenly my laptop
does not wake up from sleep again, all dead.
I will try to bisect as soon as possible, but I am on a conference
and give two talks, so not so much time.
Is the above problem known? intel graphics card.
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
BANFF
Pertaining to, or descriptive of, that kind of facial expression which
is impossible to achieve except when having a passport photograph
taken.
--- 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
In preach for decent iwl driver ... On Do, 28 Jun 2012, Norbert Preining wrote: > > You seem to be on 3.5.0-rc now, is that really no different from 3.4? > > The feeling is that it is definitely better. > > I can actually work now wirelessly, and in case of hangs an rfkill block > rfkill unblock practically always, and mostly is not needed. Ok, that was said *UNTIL* I reenabled 11n. Up to now I was loading the iwlwifi module with 11n_disable=1 Now, latest git from today, I though, let us try to enable 11n again, and there we go, boot from cold machine and after short time everything is dead without reaction. Dmesg gives many many funny messages: [ 30.047943] iwlwifi :06:00.0: L1 Enabled; Disabling L0S [ 30.051933] iwlwifi :06:00.0: Radio type=0x1-0x2-0x0 [ 30.164836] iwlwifi :06:00.0: L1 Enabled; Disabling L0S [ 30.167876] iwlwifi :06:00.0: Radio type=0x1-0x2-0x0 [ 37.533619] wlan0: authenticate with 00:0a:79:eb:56:10 [ 37.536433] wlan0: send auth to 00:0a:79:eb:56:10 (try 1/3) [ 37.538241] wlan0: authenticated [ 37.538391] wlan0: associating with AP with corrupt beacon [ 37.540056] wlan0: associate with 00:0a:79:eb:56:10 (try 1/3) [ 37.543844] wlan0: RX AssocResp from 00:0a:79:eb:56:10 (capab=0x411 status=0 aid=3) [ 37.543848] wlan0: associated [ 37.547219] cfg80211: Calling CRDA for country: JP [ 37.551474] cfg80211: Regulatory domain changed to country: JP [ 37.551477] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 37.551479] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 mBm) [ 37.551481] cfg80211: (2457000 KHz - 2482000 KHz @ 2 KHz), (N/A, 2000 mBm) [ 37.551483] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 mBm) [ 37.551485] cfg80211: (491 KHz - 493 KHz @ 1 KHz), (N/A, 2300 mBm) [ 37.551486] cfg80211: (491 KHz - 499 KHz @ 4 KHz), (N/A, 2300 mBm) [ 37.551488] cfg80211: (493 KHz - 495 KHz @ 1 KHz), (N/A, 2300 mBm) [ 37.551490] cfg80211: (503 KHz - 5045000 KHz @ 1 KHz), (N/A, 2300 mBm) [ 37.551492] cfg80211: (503 KHz - 509 KHz @ 4 KHz), (N/A, 2300 mBm) [ 37.551494] cfg80211: (505 KHz - 506 KHz @ 1 KHz), (N/A, 2300 mBm) [ 37.551495] cfg80211: (517 KHz - 525 KHz @ 4 KHz), (N/A, 2000 mBm) [ 37.551497] cfg80211: (525 KHz - 533 KHz @ 4 KHz), (N/A, 2000 mBm) [ 37.551499] cfg80211: (549 KHz - 571 KHz @ 4 KHz), (N/A, 2300 mBm) [ 39.526929] Rx A-MPDU request on tid 0 result 0 [ 46.907606] type=1305 audit(1342079160.633:43563): auid=4294967295 ses=4294967295 op="remove rule" key=(null) list=4 res=1 [ 46.907619] type=1305 audit(1342079160.633:43564): audit_enabled=0 old=1 auid=4294967295 ses=4294967295 res=1 [ 49.372661] Open BA session requested for 00:0a:79:eb:56:10 tid 0 [ 49.392528] activated addBA response timer on tid 0 [ 49.394760] switched off addBA timer for tid 0 [ 49.394769] Aggregation is on for tid 0 [ 52.416068] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames [ 52.416081] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames [ 52.416089] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames [ 52.416096] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames [ 52.416103] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames [ 52.416110] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames [ 52.416117] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames [ 52.416124] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames [ 52.416131] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames [ 52.416138] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames [ 69.252057] tx session timer expired on tid 0 [ 69.252125] Tx BA session stop requested for 00:0a:79:eb:56:10 tid 0 [ 69.272673] Stopping Tx BA session for 00:0a:79:eb:56:10 tid 0 [ 99.933558] Open BA session requested for 00:0a:79:eb:56:10 tid 0 [ 99.952530] activated addBA response timer on tid 0 [ 99.954667] switched off addBA timer for tid 0 [ 99.954676] Aggregation is on for tid 0 [ 115.075768] net_ratelimit: 25 callbacks suppressed [ 115.075783] Rx BA session stop requested for 00:0a:79:eb:56:10 tid 0 inititator reason: 0 [ 122.721571] Rx A-MPDU request on tid 0 result 0 [ 132.008042] tx session timer expired on tid 0 [ 132.008099] Tx BA session stop requested for 00:0a:79:eb:56:10 tid 0 [ 132.028663] Stopping Tx BA session for 00:0a:79:eb:56:10 tid 0 [ 150.396166] Open BA session requested for 00:0a:79:eb:56:10 tid 0 [ 150.416568] activated addBA response timer on tid 0 [ 150.418855] switched off addBA timer for tid 0 [ 150.4188
Re: Huawei E220 and usb storage
On Do, 14 Feb 2008, Pete Zaitcev wrote: > that you did, after taking care of detection and initialization. > Look at his dmesg in comment #44 in this: Yes, that looks very similar. > > - changing the penultimage argument in the usb_stor_huawei_e220_init > > function from 0x1 to 0 stopped this misbehaviour, but > > > > - with the change from 0x1 to 0 the initialization works automatically. > > I may be able to test this. I test it regularly, last with 2.6.25-rc1, and it works, always. Maybe it is not the optimal solution, but who knows. > As you recall, Huawei people themselves suggested nonzero length, Umpf, ahh, very interesting. Best wishes Norbert ------- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- Serious error. All shortcuts have disappeared. Screen. Mind. Both are blank. --- Windows Error Haiku -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG: Eeek! page_mapcount(page) went negative!
Hi all! On Mo, 10 Dez 2007, Peter Zijlstra wrote: > How reproducable is this? You make it sound like its easy to reproduce, I tried and re-tried and re-tried to reproduce this, without success. Sorry. I guess we can forget that one and assume that it was a strange coincidence. Sorry for the noise. Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- PAPWORTH EVERARD (n.) Technical term for the third take of an orgasm scene during the making of a pornographic film. --- Douglas Adams, The Meaning of Liff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG: Eeek! page_mapcount(page) went negative!
On Mo, 10 Dez 2007, Avi Kivity wrote: > >kernel 2.6.24-rc4 > >kvm 55 (debian sid 55+dfsg-1) > > Is the kvm kernel module pure 2.6.24-rc1, or are you running the kernel > module provided by kvm-55? pure 2.6.24-rc4 (not -rc1), not the one by kvm-55. Best wishes Norbert ------- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- STURRY (n.,vb.) A token run. Pedestrians who have chosen to cross a road immediately in front of an approaching vehicle generally give a little wave and break into a sturry. This gives the impression of hurrying without having any practical effect on their speed whatsoever. --- Douglas Adams, The Meaning of Liff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG: Eeek! page_mapcount(page) went negative!
On Mo, 10 Dez 2007, preining wrote: > I was running a kvm installing windows, and eek it crashed happily my > computer, probably because I forgot to give kvm -no-acpi option. I forgot: kernel 2.6.24-rc4 kvm 55 (debian sid 55+dfsg-1) Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- FLIMBY (n.) One of those irritating handle-less slippery translucent plastic bags you get in supermarkets which, no matter how you hold them, always contrive to let something fall out. --- Douglas Adams, The Meaning of Liff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel BUG: Eeek! page_mapcount(page) went negative!
crc_itu_t
Pid: 20473, comm: kvm Tainted: G D (2.6.24-rc4 #1)
EIP: 0060:[] EFLAGS: 00010286 CPU: 0
EIP is at page_remove_rmap+0xe5/0x104
EAX: 003a EBX: c1333500 ECX: c04a5892 EDX: 0002
ESI: e6e8eba8 EDI: a74b9000 EBP: d82c52e4 ESP: df4cfdd8
DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
Process kvm (pid: 20473, ti=df4ce000 task=df61c550 task.ti=df4ce000)
Stack: c03bf622 c1333500 0020 c0155e35 c04940e0 c17f80f0 b7a25fff
e6e8eba8 df4cfe58 0001 a780 e9c4ea74 e9c4ea74
e6e8a040 c17f80e0 fffd 5000 b7a26000 df4cfe58
Call Trace:
[] unmap_vmas+0x261/0x4ed
[] exit_mmap+0x7c/0x106
[] mmput+0x1c/0x75
[] do_exit+0x1cf/0x642
[] __dequeue_signal+0x10/0x14c
[] recalc_sigpending+0xb/0x30
[] sys_exit_group+0x0/0xd
[] get_signal_to_deliver+0x3f8/0x41d
[] do_notify_resume+0x84/0x612
[] dequeue_signal+0x95/0x111
[] tick_program_event+0x33/0x52
[] getnstimeofday+0x2b/0xac
[] hrtimer_start+0xf1/0xfd
[] kvm_vcpu_ioctl+0x0/0xc60 [kvm]
[] do_ioctl+0x1f/0x62
[] vfs_ioctl+0x220/0x232
[] sys_ioctl+0x43/0x4c
[] work_notifysig+0x13/0x19
===
Code: 8b 46 40 8b 50 08 b8 71 f6 3b c0 e8 a2 76 fe ff 8b 46 48 85 c0 74 14 8b
40 10 85 c0 74 0d 8b 50 2c b8 8f f6 3b c0 e8 87 76 fe ff <0f> 0b eb fe 8b 53 10
89 d8 59 5b 5b 83 e2 01 5e f7 da 83 c2 04
EIP: [] page_remove_rmap+0xe5/0x104 SS:ESP 0068:df4cfdd8
Fixing recursive fault but reboot is needed!
BUG: scheduling while atomic: kvm/20473/0x0003
Pid: 20473, comm: kvm Tainted: G D 2.6.24-rc4 #1
[] schedule+0x93/0x5a8
[] free_as_io_context+0x7/0x79
[] do_exit+0xc3/0x642
[] do_unblank_screen+0xd/0x103
[] die+0x1d6/0x1de
[] do_invalid_op+0x0/0x8a
[] do_invalid_op+0x81/0x8a
[] page_remove_rmap+0xe5/0x104
[] __call_console_drivers+0x4f/0x5b
[] release_console_sem+0x17f/0x198
[] handle_IRQ_event+0x1a/0x3f
[] do_IRQ+0x5c/0x70
[] irq_exit+0x53/0x75
[] do_IRQ+0x5c/0x70
[] error_code+0x72/0x78
[] page_remove_rmap+0xe5/0x104
[] unmap_vmas+0x261/0x4ed
[] exit_mmap+0x7c/0x106
[] mmput+0x1c/0x75
[] do_exit+0x1cf/0x642
[] __dequeue_signal+0x10/0x14c
[] recalc_sigpending+0xb/0x30
[] sys_exit_group+0x0/0xd
[] get_signal_to_deliver+0x3f8/0x41d
[] do_notify_resume+0x84/0x612
[] dequeue_signal+0x95/0x111
[] tick_program_event+0x33/0x52
[] getnstimeofday+0x2b/0xac
[] hrtimer_start+0xf1/0xfd
[] kvm_vcpu_ioctl+0x0/0xc60 [kvm]
[] do_ioctl+0x1f/0x62
[] vfs_ioctl+0x220/0x232
[] sys_ioctl+0x43/0x4c
[] work_notifysig+0x13/0x19
===
Best wishes
Norbert
-------
Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology
Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
---
PEN-TRE-TAFARN-Y-FEDW (n.)
Welsh word which literally translates as
'leaking-biro-by-the-glass-hole-of-the-clerk-of-the-bank-has-been-
-taken-to-another-place-leaving-only-the-special-inkwell-and-three-
-inches-of-tin-chain'.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: option: Bind to the correct interface of the Huawei E220
On Sa, 01 Dez 2007, Pete Zaitcev wrote:
> > is this the only addition that should be needed, ortogether with the
> > changes in option to call the huawei init function?
>
> The only one.
Ok.
> Your problem is something else. Neither my patch nor Jaime's patch
> address it. Honestly, I'm not even sure how to tackle it. I seem to
Ah, ok.
> recall that I had a usbmon trace from you but I'm unable to find it now.
> Gettin it (again?) probably would be a good place to restart that
> investigation.
I am not sure that I used usbmon ...,I can't recall it, but I know what
the problem is, I need this patch:
--- drivers/usb/storage/initializers.c.orig 2007-11-17 12:29:25.0
+0100
+++ drivers/usb/storage/initializers.c 2007-11-17 12:29:37.0 +0100
@@ -100,7 +100,7 @@
result = usb_stor_control_msg(us, us->send_ctrl_pipe,
USB_REQ_SET_FEATURE,
USB_TYPE_STANDARD | USB_RECIP_DEVICE,
- 0x01, 0x0, us->iobuf, 0x1, 1000);
+ 0x01, 0x0, us->iobuf, 0, 1000);
US_DEBUGP("usb_control_msg performing result is %d\n", result);
return (result ? 0 : -1);
}
With this everything works really smoothly. Even better, now I do get
only 2 (instead of prior 3) /dev/ttyUSB devices (that caused some
problems with umtsmon).
Best wishes
Norbert
-------
Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology
Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
---
POLBATHIC (adj.)
Gifted with ability to manipulate taps using only the feet.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: option: Bind to the correct interface of the Huawei E220
Hi all, is this the only addition that should be needed, ortogether with the changes in option to call the huawei init function? I tried 2.6.24-rc3 with this patch only and it I again got the infinite loop of connect/disconnect events instantiating cdroms. Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- `Maybe somebody here tipped off the Galactic Police,' said Trillian. `Everybody saw you come in.' `You mean they want to arrest me over the phone?' said Zaphod, `Could be. I'm a pretty dangerous dude when I'm cornered.' `Yeah,' said a voice from under the table [Ford's now completely rat- arsed at this point], `you go to pieces so fast people get hit by the shrapnel.' --- Zaphod getting paranoid over a phone call. --- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
On Do, 29 Nov 2007, preining wrote: > So to be clear: kernl 2.6.24-rc3 + your patch gives me permanent cycles > and an error: > option_start_huawei: HUAWEI E220 setup failed (1) > I attach the syslog part which exhibits the behaviour. Now really attached. Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- YONDER BOGINE (n.) The kind of restaurant advertised as 'just three minutes from this cinema' which clearly nobody ever goes to and, even if they had ever contemplated it, have certainly changed their mind since seeing the advert. --- Douglas Adams, The Meaning of Liff usb 2-2: new full speed USB device using uhci_hcd and address 2 PM: Adding info for usb:2-2 PM: Adding info for No Bus:usbdev2.2_ep00 usb 2-2: configuration #1 chosen from 1 choice PM: Adding info for usb:2-2:1.0 PM: Adding info for No Bus:usbdev2.2_ep83 PM: Adding info for No Bus:usbdev2.2_ep04 PM: Adding info for No Bus:usbdev2.2 Initializing USB Mass Storage driver... scsi2 : SCSI emulation for USB Mass Storage devices PM: Adding info for No Bus:host2 usbcore: registered new interface driver usb-storage USB Mass Storage support registered. usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning usbcore: registered new interface driver usbserial drivers/usb/serial/usb-serial.c: USB Serial support registered for generic usbcore: registered new interface driver usbserial_generic drivers/usb/serial/usb-serial.c: USB Serial Driver core drivers/usb/serial/usb-serial.c: USB Serial support registered for GSM modem (1-port) usbcore: registered new interface driver option drivers/usb/serial/option.c: USB Driver for GSM modems: v0.7.1 usb 2-2: USB disconnect, address 2 PM: Removing info for No Bus:usbdev2.2_ep83 PM: Removing info for No Bus:usbdev2.2_ep04 PM: Removing info for No Bus:host2 PM: Removing info for usb:2-2:1.0 PM: Removing info for No Bus:usbdev2.2 PM: Removing info for No Bus:usbdev2.2_ep00 PM: Removing info for usb:2-2 usb 2-2: new full speed USB device using uhci_hcd and address 3 PM: Adding info for usb:2-2 PM: Adding info for No Bus:usbdev2.3_ep00 usb 2-2: configuration #1 chosen from 1 choice PM: Adding info for usb:2-2:1.0 usb-storage: probe of 2-2:1.0 failed with error -5 option 2-2:1.0: GSM modem (1-port) converter detected option_start_huawei: HUAWEI E220 setup failed (1) PM: Adding info for usb-serial:ttyUSB0 PM: Adding info for No Bus:ttyUSB0 usb 2-2: GSM modem (1-port) converter now attached to ttyUSB0 PM: Adding info for No Bus:usbdev2.3_ep81 PM: Adding info for No Bus:usbdev2.3_ep82 PM: Adding info for No Bus:usbdev2.3_ep02 PM: Adding info for usb:2-2:1.1 usb-storage: probe of 2-2:1.1 failed with error -5 option 2-2:1.1: GSM modem (1-port) converter detected option_start_huawei: HUAWEI E220 setup failed (1) PM: Adding info for usb-serial:ttyUSB1 PM: Adding info for No Bus:ttyUSB1 usb 2-2: GSM modem (1-port) converter now attached to ttyUSB1 PM: Adding info for No Bus:usbdev2.3_ep85 PM: Adding info for No Bus:usbdev2.3_ep05 PM: Adding info for usb:2-2:1.2 scsi5 : SCSI emulation for USB Mass Storage devices PM: Adding info for No Bus:host5 PM: Adding info for No Bus:usbdev2.3_ep83 PM: Adding info for No Bus:usbdev2.3_ep04 PM: Adding info for No Bus:usbdev2.3 usb-storage: device found at 3 usb-storage: waiting for device to settle before scanning PM: Adding info for No Bus:target5:0:0 scsi 5:0:0:0: CD-ROMHUAWEI Mass Storage 2.31 PQ: 0 ANSI: 2 PM: Adding info for scsi:5:0:0:0 PM: Adding info for No Bus:target5:0:1 PM: Removing info for No Bus:target5:0:1 PM: Adding info for No Bus:target5:0:2 PM: Removing info for No Bus:target5:0:2 PM: Adding info for No Bus:target5:0:3 PM: Removing info for No Bus:target5:0:3 PM: Adding info for No Bus:target5:0:4 PM: Removing info for No Bus:target5:0:4 PM: Adding info for No Bus:target5:0:5 PM: Removing info for No Bus:target5:0:5 PM: Adding info for No Bus:target5:0:6 PM: Removing info for No Bus:target5:0:6 PM: Adding info for No Bus:target5:0:7 PM: Removing info for No Bus:target5:0:7 usb-storage: device scan complete sr0: scsi-1 drive Uniform CD-ROM driver Revision: 3.20 sr 5:0:0:0: Attached scsi CD-ROM sr0 sd 0:0:0:0: Attached scsi generic sg0 type 0 sr 5:0:0:0: Attached scsi generic sg1 type 5 usb 2-2: reset full speed USB device using uhci_hcd and address 3 usb 2-2: reset full speed USB device using uhci_hcd and address 3 usb 2-2: device descriptor read/64, error -71 usb 2-2: USB disconnect, address 3 PM: Removing info for No Bus:usbdev2.3_ep81 PM: Removing info for No Bus:usbdev2.3_ep82 PM: Removing
Re: Add the infamous Huawei E220 to option.c
Hi Pete, hi all, On Mi, 28 Nov 2007, Pete Zaitcev wrote: > It looks like the Huawei E220 saga is not over yet. A collegue of mine, > David Russll, reported that the modem does not work reliably on Fedora 8, > which does have the initializer in usb-storage. That is what I said. > it's random which wins. If usb-storage wins, everything is fine. If option > wins, it binds to modem still in storage mode and does not work. That could be the source of my disconnect/reconnect cycles. > This way no matter which driver wins the modem gets initialized. The > patch is tested on David's modem, but I would like someone give it more > testing. > > I dunno, do we want some kind of code sharing between storage and option? > They both could use the normal usb_control_msg, I think. > > Also, from archives it looks like Johann may need PID 0x1004 added. > > Since we're on topic, David's modem has exactly same IDs as Norbert's, > but works fine with the length of 1. Although it's possible that the > firmware is different without different firmware reported in USB desc- > riptors. Does anyone know a magic AT command? ATI or something? > Norbert, please try my patch, maybe it'll work this time. I tried your patch with the reverted 0x1 -> 0 change. But it didn't work. I get connects/reconnects. So to be clear: kernl 2.6.24-rc3 + your patch gives me permanent cycles and an error: option_start_huawei: HUAWEI E220 setup failed (1) I attach the syslog part which exhibits the behaviour. > And finally, pleas stop using that script from the polish website and Did it already, but without the 0x1->0 change it does not work here. > above all quit using the generic serial subdriver. The option must Long done, I assume that the option module depending on usbserial is not the problem. > work now with the patch. Please let me know if it fails. It does. Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- MUNDERFIELD (n.) A meadow selected, whilst driving past, as being ideal for a picnic which, from a sitting position, turns out to be full of stubble, dust and cowpats, and almost impossible to enjoy yourself in. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Huawei E220 and usb storage
Dear Pete, dear all, On Mi, 31 Okt 2007, preining wrote: > On Di, 30 Okt 2007, Pete Zaitcev wrote: > > The difference with huaweiAktBbo.c seems that kernel uses a nonzero length. > > Can you try zero length with the kernel? It's the second argument to the > > last. > > I tried with the git patch plus changing the penultimage argument from > 0x1 to 0. Ok, did new tests with 2.6.24-rc2: - with plain kernel the usb-storage modules attaches and detaches permanently a virtual cd drive, I stopped after 30+ iterations. - changing the penultimage argument in the usb_stor_huawei_e220_init function from 0x1 to 0 stopped this misbehaviour, but - with the change from 0x1 to 0 the initialization works automatically. Can we place change this 0x1 to 0? Best wishes Norbert ------- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- MOLESBY (n.) The kind of family that drives to the seaside and then sits in the car with all the windows closed, reading the Sunday Express and wearing sidcups (q.v.) --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major SATA / EXT3 Issue?
Hi all! (Please Cc) I alsohave to report a very similar incident. Debian/sid, kernel 2.6.22. Doing some hard work for the disk (svn up of two big repositories, some copying of files, etc etc). Suddently the PC froze. Nothing, I had to reboot. But then: - BIOS didn't detect the disks, or better, it took extremely long - booting into linux gave those time out messages already mentioned (I am away, cannot give you details for now till sunday) - booting into windows frooze windows when accessing the second harddisk (from which stuff was copied). - reseting the computer didn't help., but turning physically off, and turning on again did the trick, some fsck-ing. - booting into windows needed chkdsk from ewindows, and severalk files destroyed. Both the disks and the computer are quite new, and are NOT heavily used, only now and then. AFAIR nv SATA driver. Ic ould repeat these problems with big copying actions. The problem with logging is that the computer freezes hard and nothing remains in the log files. Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- JARROW (adj.) An agricultural device which, when towed behind a tractor, enables the farmer to spread his dung evenly across the width of the road. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Huawei E220 and usb storage
On Di, 30 Okt 2007, Pete Zaitcev wrote: > > printk(KERN_ERR "ENTERING usb_stor_huawei_e220_init!\n"); > > at the beginning of the function but it never showed up in my log files. > > So it seems that the UNUSUAL_DEV entry does not match. > > This doesn't seem to be possible, considering the /proc/bus/usb/devices > that you posted. I would rather suspect that you forgot to perform Compiling both -- usb-storage and option/usb-serial -- as modules did work. Ok, thanks a lot. I assume that is because the built-in usb-serial/option did grab the device so the init function wasn't executed. Putting both into modules allowed that usb-storage grabbed the device first. Anyway, my interpretation without any knowledge. Best wishes Norbert ------- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- SCONSER (n.) A person who looks around then when talking to you, to see if there's anyone more interesting about. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Huawei E220 and usb storage
On Di, 30 Okt 2007, Pete Zaitcev wrote: > This doesn't seem to be possible, considering the /proc/bus/usb/devices > that you posted. I would rather suspect that you forgot to perform > some step in your kernel installation, and end using a stale > usb-storage module. No. $ uname -r 2.6.23 $ cd /lib/modules/2.6.23 $ find . -name usb-storage.ko ./kernel/drivers/usb/storage/usb-storage.ko $ strings ./kernel/drivers/usb/storage/usb-storage.ko | grep -i huawei_e22a <3>ENTERING usb_stor_huawei_e220_init! $ So it is there ... and it is the only module. Best wishes Norbert ------- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- `The first ten million years were the worst,' said Marvin, `and the second ten million, they were the worst too. The third ten million I didn't enjoy at all. After that I went into a bit of a decline.' --- Marvin reflecting back on his 576,000,003,579 year --- career as Milliways' car park attendent. --- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Huawei E220 and usb storage
On Mi, 31 Okt 2007, preining wrote: > On Di, 30 Okt 2007, Pete Zaitcev wrote: > > The difference with huaweiAktBbo.c seems that kernel uses a nonzero length. > > Can you try zero length with the kernel? It's the second argument to the > > last. > > I tried with the git patch plus changing the penultimage argument from > 0x1 to 0. Hmm, in addition I added a printk(KERN_ERR "ENTERING usb_stor_huawei_e220_init!\n"); at the beginning of the function but it never showed up in my log files. So it seems that the UNUSUAL_DEV entry does not match. Best wishes Norbert ------- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- TIDPIT (n.) The corner of a toenail from which satisfying little black deposits may be sprung. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Huawei E220 and usb storage
On Di, 30 Okt 2007, Pete Zaitcev wrote: > The difference with huaweiAktBbo.c seems that kernel uses a nonzero length. > Can you try zero length with the kernel? It's the second argument to the last. I tried with the git patch plus changing the penultimage argument from 0x1 to 0. The switch of the modem is still not done automatically, but calling huaweiAktBbo does effect the switch. In my tests I did NOT reboot since usb-storage was compiled as module (usbserial and option fix in the kernel). But I made sure that I loaded the right (the module with the patched code) after removing the old one. Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- GALASHIELS (pl.n.) A form of particularly long sparse sideburns which are part of the mandatory uniform of British Rail guards. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Huawei E220 and usb storage
On Di, 30 Okt 2007, Pete Zaitcev wrote: > Please post your /proc/bus/usb/devices. Maybe it just fails to match. Here is the relevant part: T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 25 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=12d1 ProdID=1003 Rev= 0.00 S: Manufacturer=HUAWEI Technologies S: Product=HUAWEI Mobile C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms The VendorID and ProductID do match, the strings seem to be different (HUAWEI MOBILE in the patch, in the usb/devices "HUAWEI Mobile")., but I don't know what counts here. Best wishes Norbert ------- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- TINGRITH (n.) The feeling of silver paper against your fillings. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Huawei E220 and usb storage
On Di, 30 Okt 2007, Chuck Ebbert wrote: > Did you see commit d853d872c14b9adc4adad29e56cd378b291f86e0 ? 2.6.23 + this commit exhibits the same problems I describe before ... permanent disconnect/connect problems. Not even using the mentioned program does switch the usb modem into the right mode. So this patch seems to be bogus... Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- HEVER (n.) The panic caused by half-hearing Tannoy in an airport. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Huawei E220 and usb storage
On Di, 30 Okt 2007, Chuck Ebbert wrote:
> Did you see commit d853d872c14b9adc4adad29e56cd378b291f86e0 ?
No, where can I see that one?
I tried the attached patch which I found on the usb list, but it didn't
work, the cdrom was still always found, and it was
connected/disconnected permanently. Currently I was at:
...
Oct 30 22:20:32 mithrandir kernel: usb 2-2: new full speed USB device using
uhci_hcd and address 13
Oct 30 22:20:32 mithrandir kernel: usb 2-2: configuration #1 chosen from 1
choice
Oct 30 22:20:32 mithrandir kernel: usb-storage: probe of 2-2:1.0 failed with
error -5
Oct 30 22:20:32 mithrandir kernel: option 2-2:1.0: GSM modem (1-port) converter
detected
Oct 30 22:20:32 mithrandir kernel: usb 2-2: GSM modem (1-port) converter now
attached to ttyUSB0
Oct 30 22:20:32 mithrandir kernel: usb-storage: probe of 2-2:1.1 failed with
error -5
Oct 30 22:20:32 mithrandir kernel: option 2-2:1.1: GSM modem (1-port) converter
detected
Oct 30 22:20:32 mithrandir kernel: usb 2-2: GSM modem (1-port) converter now
attached to ttyUSB1
Oct 30 22:20:32 mithrandir kernel: scsi35 : SCSI emulation for USB Mass Storage
devices
Note the SCSI35 !!!
So is there any other patch I can try?
Best wishes
Norbert
---
Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology
Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
---
BARSTIBLEY
A humorous device such as a china horse or small naked porcelain
infant which jocular hosts use of piss water into your Scotch with.
--- Douglas Adams, The Meaning of Liff
--- ./drivers/usb/storage/initializers.c.orig 2007-04-26 09:20:58.0 +0200
+++ ./drivers/usb/storage/initializers.c 2007-10-30 22:03:29.0 +0100
@@ -90,3 +90,14 @@
return (res ? -1 : 0);
}
+
+/* This places the HUAWEI E220 devices in multi-port mode */
+int usb_stor_switch_ports_init(struct us_data *us)
+{
+ us->iobuf[0] = 0x1;
+ (void)usb_control_msg(us->pusb_dev, usb_sndctrlpipe(us->pusb_dev, 0),
+ USB_REQ_SET_FEATURE, USB_TYPE_STANDARD | USB_RECIP_DEVICE,
+ 0x01, 0x0, us->iobuf, 0x1, 1000);
+ return 0;
+}
+
--- ./drivers/usb/storage/initializers.h.orig 2006-12-09 15:26:06.0 +0100
+++ ./drivers/usb/storage/initializers.h 2007-10-30 22:03:29.0 +0100
@@ -47,3 +47,6 @@
/* This function is required to activate all four slots on the UCR-61S2B
* flash reader */
int usb_stor_ucr61s2b_init(struct us_data *us);
+
+/* This places the HUAWEI E220 devices in multi-port mode */
+int usb_stor_switch_ports_init(struct us_data *us);
--- ./drivers/usb/storage/unusual_devs.h.orig 2007-10-30 19:40:17.0 +0100
+++ ./drivers/usb/storage/unusual_devs.h 2007-10-30 22:05:51.0 +0100
@@ -1463,6 +1463,16 @@
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_IGNORE_RESIDUE ),
+/* This tells the usb driver to place the HUAWEI E220 devices into multi-port mode
+ * Reported by fangxiaozhi <[EMAIL PROTECTED]>
+ * and by linlei <[EMAIL PROTECTED]>
+ */
+UNUSUAL_DEV( 0x12d1, 0x1003, 0x, 0x,
+"HUAWEI",
+ "HUAWEI MOBILE Mass Storage",
+ US_SC_DEVICE, US_PR_DEVICE, usb_stor_switch_ports_init,
+ 0),
+
/* Reported by Vilius Bilinkevicius
Re: Huawei E220 and usb storage
Hi Kristoffer, thanks for the feedback. On Di, 30 Okt 2007, Kristoffer Ericson wrote: > Im using a Huawei E220 USB modem, currently running 2.6.22.5 vanilla kernel. > It has worked fine for me since 2.6.21. Strange. I rebuilt the kernel, compiled the usb serial and options into the kernel, while leaving usb-storage as module. Still I have to issue the huaweiAktBbo program to get it working/switching into the *right* modus. > The lights give you a hint what mode its in. Green = usb_storage, Dark-blue = > MODEM_slow, bright-blue = MODEM_fast (3G). BTW, I have seen a slightly different pattern: Green blinking from the beginning calling huaweiAktBbo to make the switch still blinking green calling the internet provider when the connection is established (on the hardware level, not on ip level) the modem starts blinking blue and then solid blue turning off the ppp connection it goes into blinking blue mode > If the light is green after reboot, I need to reboot again until it turns > blue. I know this sucks, but just something I've noticed. Probably you could use the huaweiAktBbo program for this, too. Best wishes Norbert ------- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- HASELBURY PLUCKNETT (n.) A mechanical device for cleaning combs invented during the industrial revolution at the same time as Arkwright's Spinning Jenny, but which didn't catch on in the same way. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Huawei E220 and usb storage
Dear all, I recently got an Huawei E220 usb modem. Reading a bit on the net I found that: The Huaweii E220 modem is a composite USB device: in fact it acts like a mass storage device, and also as three serial communication ports. The Linux's developers dealt with this ignoring the mass device storage (which is a read-only mass storage, i.e. a CD-ROM with preload software only for Windows). For more information see http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.20-rc2 or http://lwn.net/Articles/220545/ where you read the changelog for 2.6.20 linux kernel. The interesting part is reported here below: [...] Johann Wilhelm (2): usb-storage: Ignore the virtual cd-drive of the Huawei E220 USB Modem usb-gsm-driver: Added VendorId and ProductId for Huawei E220 USB Modem [...] This modification is present from Linux kernel 2.6.20 and more recent ones. See: http://ske.sourceforge.net/html/projects/huawei/huawei_tre.html Now that I plug my modem I definitely get this usb storage device, and I need to call a special program to switch to the other mode (huaweiAktBbo, from http://www.kanoistika.sk/bobovsky/archiv/umts/huaweiAktBbo.c). Several pages on the web state that it should work *without* this switch program. Is this a regression from 2.6.20, or is it supposed to work? Thanks a lot and all the best Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- DEAL (n.) The gummy substance found between damp toes. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel Oops in ext3 code
Hi all, On Fr, 28 Sep 2007, Mingming Cao wrote: > i_block_alloc_info, it should be 0x14(20 bytes)...Are you running a > vanilla 2.6.23-rc6? Well yes, I add one patch for reducing the usb device resetting time, but this was definitely not the problem, no usb device was attached. > from the cache, so racing is not a issue there. Possible random memory > corruption? Could be could be. I would say since it is such a strange thing and nobody has an idea we leave it for now, random memory corruption sounds nice. If it occurs I can come back. Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- in the space-time continuum.' is he? Is he?' --- Arthur failing in his first lesson of galactic physics --- in four years. --- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel Oops in ext3 code
On Do, 27 Sep 2007, Rafael J. Wysocki wrote: > Does it happen with 2.6.22? Hard to say. It didn't happen as long as I used -22, but it didn't happen for a long time (since I run -rc6), and it is not reproducible. What I did at this time is a: tar -cjf foo.tar.bz2 a-big-dir-with-more-than-800Mb I retried it again with -rc6 and it succeeded. So hard to say. Best wishes Norbert ------- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- ALDCLUNE (n.) One who collects ten-year-old telephone directories. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel Oops in ext3 code
Hi all! (Please Cc) kernel 2.6.23-rc6 Debian/sid kernel ooops: BUG: unable to handle kernel paging request at virtual address 104b printing eip: c0195bd3 *pde = Oops: [#1] PREEMPT SMP Modules linked in: vboxdrv binfmt_misc fuse coretemp hwmon gspca videodev v4l2_common v4l1_compat iwl3945 mac80211 tifm_7xx1 tifm_core joydev irda crc_ccitt 8250_pnp 8250 serial_core firewire_ohci firewire_core crc_itu_t CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010206 (2.6.23-rc6 #1) EIP is at ext3_discard_reservation+0x18/0x4d eax: dff23800 ebx: 1033 ecx: dfc15ec0 edx: esi: c0007c44 edi: 1033 ebp: dfc2bef4 esp: dfc2beac ds: 007b es: 007b fs: 00d8 gs: ss: 0068 Process kswapd0 (pid: 261, ti=dfc2a000 task=dfcac570 task.ti=dfc2a000) Stack: c0007ba4 c0007c44 1033 c019ec51 c0007c44 c0007d8c 002c c0171b1b 002c c0007c44 c0007c4c c0171da2 c050880c 0080 0080 c0171fb8 0080 c0007e48 df9e3910 7404 c03f5634 0080 00d0 Call Trace: [] ext3_clear_inode+0x5d/0x76 [] clear_inode+0x6b/0xb9 [] dispose_list+0x48/0xc9 [] shrink_icache_memory+0x195/0x1bd [] shrink_slab+0xe2/0x159 [] kswapd+0x2d3/0x431 [] autoremove_wake_function+0x0/0x33 [] kswapd+0x0/0x431 [] kthread+0x38/0x5d [] kthread+0x0/0x5d [] kernel_thread_helper+0x7/0x10 === Code: 83 f8 01 19 c0 f7 d0 83 e0 08 89 42 0c 89 56 b4 5b 5e c3 57 56 89 c6 53 8b 58 b4 8b 80 a4 00 00 00 85 db 8b 80 78 01 00 00 74 30 <83> 7b 18 00 74 2a 8d b8 00 03 00 00 89 f8 e8 b8 ca 1a 00 83 7b EIP: [] ext3_discard_reservation+0x18/0x4d SS:ESP 0068:dfc2beac Sysrq did work, so the oops was saved. Good. Any ideas? Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- As he came into the light they could see his black and gold uniform on which the buttons were so highly polished that they shone with an intensity that would have made an approaching motorist flash his lights in annoyance. --- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: Re: 2.6.23-rc3 regression and bisection query]
Hi Len, On Die, 14 Aug 2007, Len Brown wrote: > > But there is still the strange thing that > > ACPI: Battery Slot [BAT1] (battery absent) > > is present in the dmesg, while > > $ acpi > > Battery 1: charging, 46%, 00:00:49 until charged > > Does the system support more than 1 battery? At least not physically ... > Can you show the full dmesg and the full contents of /proc/acpi/battery/*/*? dmesg I sent already, but attached here from 2.6.23-rc3 + acpi-ec-fix-regression $ ls /proc/acpi/battery/ BAT1 $ ls /proc/acpi/battery/BAT1 alarm info state $ cat /proc/acpi/battery/BAT1/alarm alarm: unsupported $ cat /proc/acpi/battery/BAT1/info present: yes design capacity: 2000 mAh last full capacity: 1649 mAh battery technology: rechargeable design voltage: 11100 mV design capacity warning: 300 mAh design capacity low: 65 mAh capacity granularity 1: 32 mAh capacity granularity 2: 32 mAh model number:ZH01 serial number: 40110 battery type:LION OEM info:SANYO $ cat /proc/acpi/battery/BAT1/state present: yes capacity state: ok charging state: charged present rate:0 mA remaining capacity: 1649 mAh present voltage: 12538 mV Best wishes Norbert ------- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- DULEEK (n.) Sudden realisation, as you lie in bed waiting for the alarm to go off, that it should have gone off an hour ago. --- Douglas Adams, The Meaning of Liff Linux version 2.6.23-rc3 ([EMAIL PROTECTED]) (gcc version 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)) #7 SMP PREEMPT Tue Aug 14 08:59:17 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 3f68 (usable) BIOS-e820: 3f68 - 3f696000 (ACPI data) BIOS-e820: 3f696000 - 3f70 (ACPI NVS) BIOS-e820: 3f70 - 4000 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fed0 - fed00400 (reserved) BIOS-e820: fed14000 - fed1a000 (reserved) BIOS-e820: fed1c000 - fed9 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ff00 - 0001 (reserved) 118MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000f69f0 Entering add_active_range(0, 0, 259712) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 229376 HighMem229376 -> 259712 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -> 259712 On node 0 totalpages: 259712 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 HighMem zone: 237 pages used for memmap HighMem zone: 30099 pages, LIFO batch:7 Movable zone: 0 pages used for memmap DMI present. ACPI: RSDP 000F6920, 0014 (r0 PTLTD ) ACPI: RSDT 3F68CF85, 0040 (r1 PTLTDRSDT604 LTP0) ACPI: FACP 3F695E20, 0074 (r1 INTEL CALISTGA 604 LOHR 5A) ACPI: DSDT 3F68D941, 84DF (r1 INTEL CALISTGA 604 MSFT 202) ACPI: FACS 3F696FC0, 0040 ACPI: APIC 3F695E94, 0068 (r1 INTEL CALISTGA 604 LOHR 5A) ACPI: HPET 3F695EFC, 0038 (r1 INTEL CALISTGA 604 LOHR 5A) ACPI: MCFG 3F695F34, 003C (r1 INTEL CALISTGA 604 LOHR 5A) ACPI: APIC 3F695F70, 0068 (r1 PTLTD APIC604 LTP0) ACPI: BOOT 3F695FD8, 0028 (r1 PTLTD $SBFTBL$ 604 LTP1) ACPI: SSDT 3F68CFC5, 04F6 (r1 PmRefCpuPm 3000 INTL 20050624) ACPI: BIOS bug: multiple APIC/MADT found, using 0 ACPI: If "acpi_apic_instance=2" works better, notify [EMAIL PROTECTED] ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:14 APIC version 20 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 6:14 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, version 32, address
Re: [Fwd: Re: 2.6.23-rc3 regression and bisection query]
Hi Alexey, On Die, 14 Aug 2007, Alexey Starikovskiy wrote: > ACPI: EC: Fix regression > Undelete call to register query methods. I am now using a kernel with only this patch (reapplied ec/battery which you sent me). On Die, 14 Aug 2007, Alexey Starikovskiy wrote: > cat /proc/acpi/battery/C1BE/state > > does not change after this file has been read for the the first time; This does not occur with this patch. But there is still the strange thing that ACPI: Battery Slot [BAT1] (battery absent) is present in the dmesg, while $ acpi Battery 1: charging, 46%, 00:00:49 until charged But this seems to be a minor issue. Thanks a lot. Best wishes Norbert ------- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- DUNBAR (n.) A highly specialised fiscal term used solely by turnstile operatives at Regnet's Part zoo. It refers to the variable amount of increase in the variable gate takings on a Sunday afternoon, caused by persons going to the zoo because they are in love and believe that the feeling of romance will be somehow enhanced by the smell of panther sweat and rank incontinence in the reptile house. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression from 2.6.23-rc2 to -rc3 BAT missing
On Mon, 13 Aug 2007, Alexey Starikovskiy wrote: > Please check if the attached patch helps. No, didn't help, same behaviour. Do you need dsdt or anything else? Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- NACTION (n.) The 'n' with which cheap advertising copywriters replace the word 'and' (as in 'fish 'n' chips', 'mix 'n' match', 'assault 'n' battery'), in the mistaken belief that this is in some way chummy or endearing. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression from 2.6.23-rc2 to -rc3 BAT missing
On Mon, 13 Aug 2007, Alexey Starikovskiy wrote: > Do you know if you have SBS or CM battery? > What driver do you use: sbs.ko or battery.ko? I am quite sure that it is a CM battery, not a SBS: CONFIG_ACPI_BATTERY=y did normal work, and CONFIG_ACPI_SBS=m but module not loaded. Same setting as always. I also loaded sbs.ko without any change. Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
regression from 2.6.23-rc2 to -rc3 BAT missing
Hi all! Starting with 2.6.23-rc3 the battery from my laptop (Acer TM3012) is missing for linux (but not physically): ACPI: AC Adapter [ACAD] (on-line) ACPI: Battery Slot [BAT1] (battery absent) But it is definitely there and running, even when I unplug the AC power. Any patch I can use to change this? Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- GLOSSOP (n.) A rouge blob of food. Glossops, which are generally streaming hot and highly adhesive invariably fall off your spoon and on to the surface of your host's highly polished antique-rosewood dining table. If this has not, or may not have, been noticed by the company present, swanage (q.v.) may be employed. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.22-rc3][ACPI?] Resume from s2r doesn't work.
Hi Pavel, hi all, On Son, 22 Jul 2007, Pavel Machek wrote: > > Ok, no beeping at all. Nothing after resume, only fan. And I did not > > forget to activate the BEEP line. > > > > So where can I go from here? DSDT hacking? Anything else? > > Hmm, it was 'hardware debugger' time when I hit similar problem few > years ago :-(. Something else helped, don't ask me what, but with 2.6.32-rc2 and s2ram -f -p it does work. Even with X and 3D running. Nice. Anything I should do now? Best wishes Norbert ------- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- RAMSGATE (n.) All institutional buildings must, by law, contain at least twenty ramsgates. These are doors which open the opposite way to the one you expect. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: recognizing memory sticks in tifm
Hi Alex, On Die, 03 Jul 2007, Alex Dubov wrote: > major difference: mmc/sd has an open spec, sony ms has none. Thanks for the clarification. If you need some help testing I can do it. Compiling/svn/etc should be no problem. Let me know. Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- BODMIN The irrational and inevitable discrepancy between the amount pooled and the amount needed when a large group of people try to pay a bill together after a meal. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
recognizing memory sticks in tifm
Hi Alex, hi all, I have an Acer TM3012 with 0a:09.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD) but only when I plug in an SD card I get a device created, while plugging in a Memory Stick I do not get any reaction of the kernel. This is with kernel 2.6.22-rc6. Is this feature missing or could it be a configuration error (.config if you need it). Inserting a sd card gives: tifm_core: MMC/SD card detected in socket 0:1 mmcblk0: mmc0:bffc SD02G 1985024KiB mmcblk0: p1 >From the "MMC/SD card detected" I assumed that MS should work, too. Thanks for any clarification. Best wishes Norbert ------- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- MAENTWROG (n. Welsh) The height by which the top of a wave exceeds the heigh to which you have rolled up your 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.22-rc3][ACPI?] Resume from s2r doesn't work.
Hi all! On Die, 12 Jun 2007, Pavel Machek wrote: > > When I resume, everything seems to come up (fan becomes busy, disk and > > dvd spin up for a short time), but the machine is not responding to > > anything - neither keyboard, mouse nor ping from another machine. The > > laptop is effectively dead and only a power cycle helps. > > > > I've tried a minimal config and init=/bin/bash as well, but the result > > is the same. > > Beeping patch? It is in -mm now. noapic nolapic and nosmp are useful, > too. Ok, no beeping at all. Nothing after resume, only fan. And I did not forget to activate the BEEP line. So where can I go from here? DSDT hacking? Anything else? Best wishes Norbert ------- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- Anyone who is capable of getting themselves made President should on no account be allowed to do the job. --- Some wisdom from The Book. --- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ipw3945-devel] [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
Hi all! On Fre, 09 Feb 2007, James Ketrenos wrote: > We are pleased to announce the availability of a new driver for the > Intel PRO/Wireless 3945ABG Network Connection adapter. This new driver I am impressed: I had 2.6.20 running with ipw3945 + wpa_supplicant. I installed the d80211 system and the new driver, rebooted, and you won't believe it, I had network connection even with WEP encryption. That was a big surprise for me that it worked out of the box without any magic. If you are interested in any dmesg/log output, please let me know. Ahhh ... one thing: The LED on my Acer Laptop (TM3012) does not show up, maybe because I have CONFIG_D80211_LEDS off? Again, thanks a lot for the good work! Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Università di Siena Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- HARPENDEN (n.) The coda to a phone conversion, consisting of about eight exchanges, by which people try gracefully to get off the line. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.19 does not boot, while 2.6.19-rc4 does
Hi all! [Please Cc] I copied my old config-2.6.19-rc4 to a clean linux-2.6.19 tree, called make oldconfig; make, installed the kernel and modules, but the kernel cannot find the root file system. I diffed the two config files and the only not-comment diff is: -# CONFIG_SYSCTL_SYSCALL is not set +CONFIG_SYSCTL_SYSCALL=y (how did this happen?) a part of the dmesg is included here (from -rc4): libata version 2.00 loaded. ata_piix :00:1f.2: version 2.00ac6 ata_piix :00:1f.2: MAP [ P0 P2 IDE IDE ] ACPI: PCI Interrupt :00:1f.2[B] -> GSI 19 (level, low) -> IRQ 20 PCI: Setting latency timer of device :00:1f.2 to 64 ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x18B0 irq 14 ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x18B8 irq 15 scsi0 : ata_piix PM: Adding info for No Bus:host0 ata1.00: ATA-7, max UDMA/133, 195371568 sectors: LBA48 NCQ (depth 0/32) ata1.00: ata1: dev 0 multi count 16 ata1.00: configured for UDMA/133 scsi1 : ata_piix Hardware: Acer TravelMate 3012 Any suggestions what to do next? Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Università di Siena Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- HARBLEDOWN (vb.) To manoeuvre a double mattress down a winding staircase. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] Re: Problems with connect/disconnect cycles
On Sam, 20 Aug 2005, Alan Stern wrote: > Speaking in broad terms, it's normal to see new device connection and > configuration messages like the ones above when a USB device is plugged in > to your computer. What's not normal is to see disconnects. So you should Mind that this is an *internal* builtin card reader on my laptop. I will go through the log files and look if I find patterns. > why is the card reader disconnecting? Turning on CONFIG_USB_DEBUG may ok. Best wishes Norbert ------- Dr. Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- AASLEAGH (n.) A liqueur made only for drinking at the end of a revoltingly long bottle party when all the drinkable drink has been drunk. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with connect/disconnect cycles
Hi USB developers, hi Andrew! On Mon, 21 Mär 2005, preining wrote: > Dear usb developers, dear Andrew! > > I found that my builtin sd card reader connected via USB port > experiences several connect/reconnect cycles every time I boot. > > I am using 2.6.11-mm4. Same now with 2.6.13-rc6-mm1. This time it got really bad: Aug 20 14:00:19 gandalf vmunix: usb 2-2: USB disconnect, address 2 Aug 20 14:00:19 gandalf kernel: usb 2-2: new full speed USB device using uhci_hcd and address 3 Aug 20 14:00:19 gandalf kernel: scsi1 : SCSI emulation for USB Mass Storage devices Aug 20 14:00:19 gandalf kernel: usb-storage: device found at 3 Aug 20 14:00:19 gandalf kernel: usb-storage: waiting for device to settle before scanning Aug 20 14:00:21 gandalf usb.agent[6109]: usb-storage: already loaded Aug 20 14:00:24 gandalf vmunix: Vendor: Generic Model: Flash R/W Rev: 2002 Aug 20 14:00:24 gandalf vmunix: Type: Direct-Access ANSI SCSI revision: 02 Aug 20 14:00:24 gandalf vmunix: Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0 Aug 20 14:00:24 gandalf kernel: usb-storage: device scan complete Aug 20 14:00:26 gandalf scsi.agent[6154]: sd_mod: loaded successfully (for disk) Aug 21 01:55:44 gandalf vmunix: usb 2-2: USB disconnect, address 32 Aug 21 01:55:44 gandalf kernel: usb 2-2: new full speed USB device using uhci_hcd and address 33 Aug 21 01:55:44 gandalf kernel: scsi32 : SCSI emulation for USB Mass Storage devices Aug 21 01:55:44 gandalf kernel: usb-storage: device found at 33 Aug 21 01:55:44 gandalf kernel: usb-storage: waiting for device to settle before scanning Aug 21 01:55:47 gandalf usb.agent[17503]: usb-storage: already loaded Aug 21 01:55:49 gandalf vmunix: Vendor: Generic Model: Flash R/W Rev: 2002 Aug 21 01:55:49 gandalf vmunix: Type: Direct-Access ANSI SCSI revision: 02 Aug 21 01:55:49 gandalf kernel: Attached scsi removable disk sda at scsi32, channel 0, id 0, lun 0 Aug 21 01:55:49 gandalf vmunix: usb-storage: device scan complete Aug 21 01:55:50 gandalf scsi.agent[17544]: sd_mod: loaded successfully (for disk) uuu, now many of these Aug 21 02:09:18 gandalf vmunix: ACPI-0131: *** Error: Invalid owner_id: 00 and many many more of these: Aug 21 03:07:19 gandalf vmunix: ACPI-0096: *** Error: Could not allocate new owner_id (32 max), AE_OWNER_ID_LIMIT Unfortunately I cannot in any way track down this problem to specific kernels, or specific work situations. It sometimes happens, sometimes not. If anyone has any idea how to debug such a stupid problem, I would be glad. Best wishes Norbert ------- Dr. Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- HUCKNALL (vb.) To crouch upwards: as in the movement of a seated person's feet and legs made in order to allow a cleaner's hoover to pass beneath 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
b44 transmit timeout with kernel 2.6
Dear Pekka, dear developers! Some time ago I reported problems with transmit timeouts with b44 and kernel 2.4 (http://lkml.org/lkml/2003/9/1/197 and followin discussion). Now I have very similar problems with kernel 2.6: Aug 2 09:53:15 gandalf vmunix: b44: eth0: Link is up at 100 Mbps, full duplex. Aug 2 09:53:15 gandalf vmunix: b44: eth0: Flow control is off for TX and off for RX. Aug 2 09:53:15 gandalf ifplugd(eth0)[3291]: Link beat detected. Aug 2 09:53:20 gandalf dnsmasq[3005]: reading /var/run/dnsmasq/resolv.conf Aug 2 09:53:20 gandalf dnsmasq[3005]: using nameserver 193.205.4.2#53 Aug 2 09:53:20 gandalf dnsmasq[3005]: using nameserver 193.205.4.11#53 Aug 2 09:53:25 gandalf vmunix: NETDEV WATCHDOG: eth0: transmit timed out Aug 2 09:53:25 gandalf vmunix: b44: eth0: transmit timed out, resetting Aug 2 09:53:26 gandalf kernel: b44: eth0: Link is down. Aug 2 09:53:26 gandalf ifplugd(eth0)[3291]: Link beat lost. Aug 2 09:53:28 gandalf vmunix: b44: eth0: Link is up at 100 Mbps, full duplex. Aug 2 09:53:28 gandalf vmunix: b44: eth0: Flow control is off for TX and off for RX. and wanted to ask what I can do to overcome this problems again. Currently I am running 2.6.13-rc4-mm1 on an acer travelmate 654LCi. Best wishes Norbert --- Dr. Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- `I am so amazingly cool you could keep a side of meat in me for a month. I am so hip I have difficulty seeing over my pelvis.' --- Zaphod being cool. --- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
build system changed? cannot build any module
Hi Andrew! I cannot build any external module (acerhk, pwc), in all the cases it the make run looks similar: make -C /lib/modules/`uname -r`/build SUBDIRS=/src/hotkey/acerhk-0.5.25 modules make[1]: Entering directory `/usr/src/linux-2.6.13-rc3-mm2' scripts/Makefile.build:14: /usr/src/linux-2.6.13-rc3-mm2//src/hotkey/acerhk-0.5.25/Makefile: No such file or directory make[2]: *** No rule to make target `/usr/src/linux-2.6.13-rc3-mm2//src/hotkey/acerhk-0.5.25/Makefile'. Stop. Has something fundamentally changed in the way external modules should be build? Best wishes Norbert --- Dr. Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- `My doctor says that I have a malformed public-duty gland and a natural deficiency in moral fibre, and that I am therefore excused from saving Universes.' --- Ford's last ditch attempt to get out of helping --- Slartibartfast. --- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: synaptics touchpad not recognized by Xorg X server with recent -mm kernels
On Mit, 13 Jul 2005, Peter Osterlund wrote: > Looks correct. My guess is that something is wrong with your device > nodes. What's the output from "ls -l /dev/input/event*"? Bingo. THere was no event0 and event1, although the evdev module was loaded! I had to unload evdev and reload it again to get the event devices. Seems to be either a bug in evdev or in udev. Sorry for the noise. Whom should I ask now? Best wishes Norbert ------- Dr. Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair. --- One of the laws of computers and programming revealed. --- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: synaptics touchpad not recognized by Xorg X server with recent -mm kernels
On Die, 12 Jul 2005, Peter Osterlund wrote: > What's the output from "cat /proc/bus/input/devices"? good (rc1-mm1) $ cat /proc/bus/input/devices I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 H: Handlers=kbd event0 B: EV=120013 B: KEY=4 f200 3802078 f870f401 f2df ffef B: MSC=10 B: LED=7 I: Bus=0011 Vendor=0002 Product=0007 Version= N: Name="SynPS/2 Synaptics TouchPad" P: Phys=isa0060/serio1/input0 H: Handlers=mouse0 event1 B: EV=b B: KEY=6420 0 7000f 0 0 0 0 0 0 0 0 B: ABS=1103 I: Bus= Vendor= Product= Version= N: Name="" P: Phys= H: Handlers=kbd event2 B: EV=3 B: KEY= bad (rc2-mm2) $ cat /proc/bus/input/devices I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 H: Handlers=kbd event0 B: EV=120013 B: KEY=4 f200 3802078 f870f401 f2df ffef B: MSC=10 B: LED=7 I: Bus=0011 Vendor=0002 Product=0007 Version= N: Name="SynPS/2 Synaptics TouchPad" P: Phys=isa0060/serio1/input0 H: Handlers=mouse0 event1 B: EV=b B: KEY=6420 0 7000f 0 0 0 0 0 0 0 0 B: ABS=1103 Best wishes Norbert ------- Dr. Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- SNITTERFIELD (n.) Office noticeboard on which snitters (q.v.), cards saying 'You don't have to be mad to work here, but if you are it helps !!!' and slightly smutty postcards from Ibiza get pinned up by snitterbies (q.v.) --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
synaptics touchpad not recognized by Xorg X server with recent -mm kernels
Hello Peter, hi Andrew! Since 2.6.13-rc2-mm1 my X does not find my synaptics touchpad driver. With kernel 2.6.13-rc2-mm2 (same with rc2-mm1) I get from the kernel: Synaptics Touchpad, model: 1, fw: 5.8, id: 0x9d48b1, caps: 0x904713/0x4006 input: SynPS/2 Synaptics TouchPad on isa0060/serio1 and Xorg.0.log gives: (II) Synaptics touchpad driver version 0.14.2 touchpad no synaptics event device found (checked 10 nodes) touchpad The evdev kernel module seems to be missing Query no Synaptics: 6003C8 (EE) touchpad no synaptics touchpad detected and no repeater device (EE) touchpad Unable to query/initialize Synaptics hardware. (EE) PreInit failed for input device "touchpad" (but evdev is definitely loaded!) WIth 2.6.13-rc1-mm1 I get: Synaptics Touchpad, model: 1, fw: 5.8, id: 0x9d48b1, caps: 0x904713/0x4006 input: SynPS/2 Synaptics TouchPad on isa0060/serio1 and Xorg.0.log gives: (II) Synaptics touchpad driver version 0.14.2 (--) touchpad auto-dev sets device to /dev/input/event1 (--) touchpad touchpad found Any idea what could be the reason for this? Best wishes Norbert --- Dr. Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- SITTINGBOURNE (n.) One of those conversions where both people are waiting for the other one to shut up so they can get on with their bit. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
firewire and/or sbp2 problem with rc2-mm3, but not rc2-mm2
Hi Andrew! Hi 1394 developers! I have a bit of a problem with firewire. WIth 2.6.12-rc2-mm3 it does not recognize my external hard disk any more: I use an external hard disk via firewire, and when I plug it in I get: vmunix: sbp2: $Rev: 1219 $ Ben Collins <[EMAIL PROTECTED]> vmunix: Device not ready. Make sure there is a disc in the drive. With -mm2 it was working, also with older kernels. Now, there is also a problem with removing modules: I remove sbp2, works. Then I try to remove ohci1394 and it stucks: vmunix: rmmod D C036EBC0 0 5310 5175 (NOTLB) vmunix: cec79de8 00200246 cec79dd0 c036ebc0 cec79e18 d9c40500 dec808ec df7923bc vmunix:0941 f7ae5f13 004d cf8dea90 cf8debb8 defc4058 cec78000 cec78000 vmunix:cec79e3c c0305e08 cf8dea90 c0117bb0 defc4150 vmunix: Call Trace: vmunix: [] wait_for_completion+0x78/0xf0 vmunix: [] default_wake_function+0x0/0x10 vmunix: [] class_dev_release+0x64/0x70 vmunix: [] default_wake_function+0x0/0x10 vmunix: [] kobject_cleanup+0x8b/0xa0 vmunix: [] __nodemgr_remove_host_dev+0x0/0x10 [ieee1394] vmunix: [] device_del+0x1b/0x80 vmunix: [] device_unregister+0x8/0x10 vmunix: [] nodemgr_remove_ne+0x70/0x90 [ieee1394] vmunix: [] __nodemgr_remove_host_dev+0x8/0x10 [ieee1394] vmunix: [] device_for_each_child+0x33/0x50 vmunix: [] nodemgr_remove_host_dev+0x12/0x40 [ieee1394] kernel: [exit_notify+766/2080] exit_notify+0x2fe/0x820 vmunix: [] __unregister_host+0xc7/0xd0 [ieee1394] vmunix: [] autoremove_wake_function+0x0/0x50 vmunix: [] highlevel_remove_host+0x3b/0x70 [ieee1394] vmunix: [] hpsb_remove_host+0x38/0x60 [ieee1394] vmunix: [] ohci1394_pci_remove+0x60/0x230 [ohci1394] vmunix: [] sysfs_hash_and_remove+0xd5/0x105 vmunix: [] pci_device_remove+0x28/0x30 vmunix: [] device_release_driver+0x7f/0x90 vmunix: [] __remove_driver+0x5/0x10 vmunix: [] driver_for_each_device+0x45/0x60 vmunix: [] driver_detach+0x13/0x15 vmunix: [] __remove_driver+0x0/0x10 vmunix: [] bus_remove_driver+0x26/0x40 vmunix: [] driver_unregister+0xb/0x20 vmunix: [] pci_unregister_driver+0xb/0x20 vmunix: [] ohci1394_cleanup+0x0/0xa [ohci1394] vmunix: [] sys_delete_module+0x12d/0x160 vmunix: [] unmap_vma_list+0x1a/0x30 vmunix: [] do_munmap+0xfa/0x130 vmunix: [] sys_munmap+0x40/0x70 vmunix: [] syscall_call+0x7/0xb kernel: [do_futex+53/144] do_futex+0x35/0x90 Best wishes Norbert --- Dr. Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- TINGRITH (n.) The feeling of silver paper against your fillings. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: It's getting worse: 2.6.12-rc2-mm1 and suspend2ram
On Die, 05 Apr 2005, Andrew Morton wrote: > > 2.6.12-rc2 suspends and resumes with the very same config file (well, > > after running make oldconfig) without any problem. > > > > So there is a change in -mm1 which triggers this. Should I start with > > backing out bk-acpi? or anything else? > > bk-acpi would be a good choice. It might be easier to start with > 2.6.12-rc2 and add stuff, see when it breaks. Ok, 2.6.12-rc2 suspend and resumes works + bk-acpi.patch immediate reboot at resume. > bk-acpi and bk-driver-core would be prime suspects. I didn't try bk-driver-core. Best wishes Norbert ------- Dr. Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: It's getting worse: 2.6.12-rc2-mm1 and suspend2ram
On Die, 05 Apr 2005, Pavel Machek wrote: > Well, I do not have working suspend-to-RAM setup close to me... Could > you try 2.6.12-rc1 to see if reboot problem is -mm specific or not? 2.6.12-rc2 suspends and resumes with the very same config file (well, after running make oldconfig) without any problem. So there is a change in -mm1 which triggers this. Should I start with backing out bk-acpi? or anything else? > input is known for some funky behaviour, especially with > synaptics. Disabling cpufreq might be good idea, too... rc2 with input compiled in and cpufreq compiled in did resume. Best wishes Norbert --- Dr. Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- THRUMSTRER (n.) The irritating man next to you in a concert who thinks he's (a) the conductor, (b) the brass section. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: It's getting worse: 2.6.12-rc2-mm1 and suspend2ram
On Die, 05 Apr 2005, Pavel Machek wrote: > Well, I do not have working suspend-to-RAM setup close to me... Could > you try 2.6.12-rc1 to see if reboot problem is -mm specific or not? You mean rc2? with rc1-mm4 it is working. > input is known for some funky behaviour, especially with > synaptics. Disabling cpufreq might be good idea, too... Hmm, ok, I compile it modular, and also cpufreq, and try again wiht init=/bin/bash. But not today, time for going home. Best wishes Norbert --- Dr. Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- CLUNES (pl.n.) People who just won't go. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
