Re: Kernel 5.9-rc Regression: Boot failure with nvme
On 29.08.20 20:40, Linus Torvalds wrote: On Sat, Aug 29, 2020 at 11:36 AM Gabriel C wrote: This kinda looks like the sqsize regression we had in earlier 5.9-rc, but that should have been fixed in -rc2 with git tag --contains 7442ddcedc344b6fa073692f165dffdd1889e780 returns nothing, that commit only exits in master, so probably in -rc3. Right you are - that commit is not in rc2. Daniel - that commit will be in rc3 when I cut that tomorrow, but if you are willing to check current -git to verify that yes, it's fixed, that would be lovely. Tried current git and indeed it boots just fine. Thanks everyone! Greetings Daniel
Kernel 5.9-rc Regression: Boot failure with nvme
Hi, (please keep me in the loop, as I'm currently not suscribed) both 5.9-rc1 and -rc2 fail to boot with my TOSHIBA-RD400 NVME: [1.015590] [ cut here ] [1.015594] WARNING: CPU: 7 PID: 99 at mm/page_alloc.c:4864 __alloc_pages_nodemask+0x299/0x330 [1.015594] Modules linked in: syscopyarea xhci_pci(+) xhci_pci_renesas sysfillrect xhci_hcd nvme aesni_intel(+) crypto_simd sysimgblt fb_sys_fops cryptd nvme_core t10_pi glue_helper drm hwmon scsi_mod agpgart i2c_core usbcore video wmi button dm_mirror dm_region_hash dm_log dm_mod unix ipv6 autofs4 [1.015602] CPU: 7 PID: 99 Comm: kworker/u16:1 Not tainted 5.9.0-rc2-dirty #12 [1.015603] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z170 Gaming K6, BIOS P7.50 10/18/2018 [1.015607] Workqueue: nvme-reset-wq nvme_reset_work [nvme] [1.015608] RIP: 0010:__alloc_pages_nodemask+0x299/0x330 [1.015609] Code: 66 0f 85 46 ff ff ff e8 24 46 dd ff e9 3c ff ff ff e8 4b 4f fc ff 48 89 c7 e9 ad fe ff ff 81 e5 00 20 00 00 0f 85 7b ff ff ff <0f> 0b e9 74 ff ff ff 31 c0 e9 1b fe ff ff 65 48 8b 04 25 00 6d 01 [1.015610] RSP: :b3ed002abcb8 EFLAGS: 00010246 [1.015611] RAX: RBX: 9c8e827c4118 RCX: [1.015611] RDX: RSI: 0034 RDI: 0cc0 [1.015612] RBP: R08: R09: [1.015612] R10: 0006 R11: b3ee002abb97 R12: [1.015613] R13: R14: 9c8e921060b0 R15: 0cc0 [1.015614] FS: () GS:9c8e96bc() knlGS: [1.015615] CS: 0010 DS: ES: CR0: 80050033 [1.015615] CR2: 559988e2f4d8 CR3: 0008433e4004 CR4: 003706e0 [1.015616] DR0: DR1: DR2: [1.015617] DR3: DR6: fffe0ff0 DR7: 0400 [1.015617] Call Trace: [1.015621] dma_direct_alloc_pages+0x1e9/0x2c0 [1.015623] ? pci_alloc_irq_vectors_affinity+0xa5/0x100 [1.015626] nvme_alloc_queue+0x10a/0x170 [nvme] [1.015629] nvme_reset_work+0x70b/0x12b0 [nvme] [1.015631] ? nvme_irq_check+0x30/0x30 [nvme] [1.015634] process_one_work+0x1da/0x3d0 [1.015636] worker_thread+0x4a/0x3c0 [1.015637] ? process_one_work+0x3d0/0x3d0 [1.015638] kthread+0x114/0x160 [1.015640] ? kthread_park+0x90/0x90 [1.015641] ret_from_fork+0x22/0x30 [1.015643] ---[ end trace 268d4f4db1ef121e ]--- Resulting in: [1.015644] nvme nvme0: Removing after probe failure status: -12 If you need more infos I can try to provide them. Greetings Daniel
Re: Regression: Kernel 4.6 DisplayPort Audio
Hi, Am 11.05.2016 um 10:48 schrieb Takashi Iwai: [..] > If the commit above alone breaks, does the patch below change the > behavior? Through a quick look at it, some ops are overridden only > conditionally while the older code always overwrote them. Yes, the patch fixes it. Thanks! I hope its possible to include that in 4.6. Greetings Daniel -- Daniel Exner Public-Key: https://www.dragonslave.de/pub_key.asc signature.asc Description: OpenPGP digital signature
Re: Regression: Kernel 4.6 DisplayPort Audio
Hi, Am 11.05.2016 um 10:48 schrieb Takashi Iwai: [..] > If the commit above alone breaks, does the patch below change the > behavior? Through a quick look at it, some ops are overridden only > conditionally while the older code always overwrote them. Yes, the patch fixes it. Thanks! I hope its possible to include that in 4.6. Greetings Daniel -- Daniel Exner Public-Key: https://www.dragonslave.de/pub_key.asc signature.asc Description: OpenPGP digital signature
Regression: Kernel 4.6 DisplayPort Audio
Hi, (Please keep me CC as I am currently not subscribed to LKML or any other Linux Kernel Dev ML, thanks) Since very first 4.6 rc1 the speakers integrated in my monitor (Dell U3415W) stopped working. It is connected via DisplayPort from a ATI R7 270X. Same setup works just fine in 4.5.3. The bug report about this is: https://bugzilla.kernel.org/show_bug.cgi?id=114981 I managed to bisect this down to: commit 739ffee97ed550a2899a925ed3f260fa1e8fa955 Author: Subhransu S. Prusty <subhransu.s.pru...@intel.com> Date: Fri Mar 4 19:59:49 2016 +0530 ALSA: hda - Add hdmi chmap verb programming ops to chmap object But I cannot easily revert this from current rc7. Please make me a happy DP Audio User again :) I can provide further informations or test possible patches. Greetings Daniel -- Daniel Exner Public-Key: https://www.dragonslave.de/pub_key.asc signature.asc Description: OpenPGP digital signature
Regression: Kernel 4.6 DisplayPort Audio
Hi, (Please keep me CC as I am currently not subscribed to LKML or any other Linux Kernel Dev ML, thanks) Since very first 4.6 rc1 the speakers integrated in my monitor (Dell U3415W) stopped working. It is connected via DisplayPort from a ATI R7 270X. Same setup works just fine in 4.5.3. The bug report about this is: https://bugzilla.kernel.org/show_bug.cgi?id=114981 I managed to bisect this down to: commit 739ffee97ed550a2899a925ed3f260fa1e8fa955 Author: Subhransu S. Prusty Date: Fri Mar 4 19:59:49 2016 +0530 ALSA: hda - Add hdmi chmap verb programming ops to chmap object But I cannot easily revert this from current rc7. Please make me a happy DP Audio User again :) I can provide further informations or test possible patches. Greetings Daniel -- Daniel Exner Public-Key: https://www.dragonslave.de/pub_key.asc signature.asc Description: OpenPGP digital signature
Re: 1e918876 breaks r8169 (linux-3.18+)
c_piix4 shpchp button acpi_cpufreq > processor thermal_sys ppdev snd_seq_midi snd_seq_midi_event snd_seq > snd_rawmidi snd_seq_device snd_timer snd soundcore asus_atk0110 hwmon > sch_fq_codel fuse lp binfmt_misc parport_pc parport ext4 crc16 jbd2 mbcache > hid_generic sr_mod cdrom sd_mod hid_microsoft usbhid hid firewire_ohci ahci > r8169 firewire_core libahci mii crc_itu_t xhci_pci ohci_pci ehci_pci > ohci_hcd xhci_hcd ehci_hcd libata usbcore scsi_mod usb_common sunrpc > dm_mirror dm_region_hash dm_log dm_mod > CPU: 5 PID: 35 Comm: ksoftirqd/5 Not tainted 4.1.0-rc2-36683-g979f4b5-dirty > #29 > Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./970 Extreme3 > # R2.0, BIOS P1.60 06/05/2014 > 815f162c 814b233e 88023620fce8 > 810526b7 880230d683a0 880230d68000 > 0005 0001 81052735 815f5700 > Call Trace: > [] ? dump_stack+0x47/0x67 > [] ? warn_slowpath_common+0x77/0xb0 > [] ? warn_slowpath_fmt+0x45/0x50 > [] ? dev_watchdog+0x23f/0x250 > [] ? dev_graft_qdisc+0x80/0x80 > [] ? call_timer_fn.isra.26+0x15/0x80 > [] ? dev_graft_qdisc+0x80/0x80 > [] ? run_timer_softirq+0x1c8/0x270 > [] ? __do_softirq+0x10c/0x220 > [] ? run_ksoftirqd+0x29/0x50 > [] ? smpboot_thread_fn+0x135/0x250 > [] ? sort_range+0x20/0x20 > [] ? kthread+0xce/0xf0 > [] ? smpboot_register_percpu_thread+0x63/0xf0 > [] ? kthread_create_on_node+0x180/0x180 > [] ? ret_from_fork+0x42/0x70 > [] ? kthread_create_on_node+0x180/0x180 > ---[ end trace 4f88915aa0200ae6 ]--- I would have bisected it but its hard to trigger. One thing that sticks out in the log: > r8169 :05:00.0: can't disable ASPM; OS doesn't have ASPM control but: > acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] > acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM Regards, Daniel Exner -- Daniel Exner Public-Key: https://www.dragonslave.de/pub_key.asc signature.asc Description: OpenPGP digital signature
Re: 1e918876 breaks r8169 (linux-3.18+)
snd_seq_midi snd_seq_midi_event snd_seq snd_rawmidi snd_seq_device snd_timer snd soundcore asus_atk0110 hwmon sch_fq_codel fuse lp binfmt_misc parport_pc parport ext4 crc16 jbd2 mbcache hid_generic sr_mod cdrom sd_mod hid_microsoft usbhid hid firewire_ohci ahci r8169 firewire_core libahci mii crc_itu_t xhci_pci ohci_pci ehci_pci ohci_hcd xhci_hcd ehci_hcd libata usbcore scsi_mod usb_common sunrpc dm_mirror dm_region_hash dm_log dm_mod CPU: 5 PID: 35 Comm: ksoftirqd/5 Not tainted 4.1.0-rc2-36683-g979f4b5-dirty #29 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./970 Extreme3 # R2.0, BIOS P1.60 06/05/2014 815f162c 814b233e 88023620fce8 810526b7 880230d683a0 880230d68000 0005 0001 81052735 815f5700 Call Trace: [814b233e] ? dump_stack+0x47/0x67 [810526b7] ? warn_slowpath_common+0x77/0xb0 [81052735] ? warn_slowpath_fmt+0x45/0x50 [813eaa0f] ? dev_watchdog+0x23f/0x250 [813ea7d0] ? dev_graft_qdisc+0x80/0x80 [810a8fe5] ? call_timer_fn.isra.26+0x15/0x80 [813ea7d0] ? dev_graft_qdisc+0x80/0x80 [810a9218] ? run_timer_softirq+0x1c8/0x270 [81055eac] ? __do_softirq+0x10c/0x220 [81055fe9] ? run_ksoftirqd+0x29/0x50 [8106ff55] ? smpboot_thread_fn+0x135/0x250 [8106fe20] ? sort_range+0x20/0x20 [8106d0be] ? kthread+0xce/0xf0 [81070303] ? smpboot_register_percpu_thread+0x63/0xf0 [8106cff0] ? kthread_create_on_node+0x180/0x180 [814b77a2] ? ret_from_fork+0x42/0x70 [8106cff0] ? kthread_create_on_node+0x180/0x180 ---[ end trace 4f88915aa0200ae6 ]--- I would have bisected it but its hard to trigger. One thing that sticks out in the log: r8169 :05:00.0: can't disable ASPM; OS doesn't have ASPM control but: acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM Regards, Daniel Exner -- Daniel Exner Public-Key: https://www.dragonslave.de/pub_key.asc signature.asc Description: OpenPGP digital signature
Regression in i915 intel_panel_setup_backligh
Hi, please keep me CC as I am currently not subscribed to the LKML. I recently tested 3.17-rc7 and found my Samsung AtivBook 7 unable to enable inteldrmfb (see attached output of the crash). I managed to bisect it to: commit 4dac3edfe68e5e1b3c2216b84ba160572420fa40 Merge: 486 e05444b Author: Daniel Vetter Date: Tue Jul 29 20:49:36 2014 +0200 Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next Pull in drm-next with Dave's DP MST support so that I can merge some conflicting patches which also touch the driver load sequencing around interrupt handling. Conflicts: drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_dp.c Signed-off-by: Daniel Vetter git bisect log: git bisect start 'v3.17.0-rc4' 'v3.15' 'drivers/gpu/drm/i915/intel_dp.c' # bad: [2ce7598c9a453e0acd0e07be7be3f5eb39608ebd] Linux 3.17-rc4 git bisect bad 2ce7598c9a453e0acd0e07be7be3f5eb39608ebd # good: [1860e379875dfe7271c649058aeddffe5afd9d0d] Linux 3.15 git bisect good 1860e379875dfe7271c649058aeddffe5afd9d0d # good: [7c8f8a7007cf0069488e0b4e3db5f89d715f297e] drm/i915: Force PSR exit by inactivating it. git bisect good 7c8f8a7007cf0069488e0b4e3db5f89d715f297e # good: [9ca153017e00550dbeda2718cfd69ca37de9c523] drm/i915: Fix up PSR frontbuffer tracking git bisect good 9ca153017e00550dbeda2718cfd69ca37de9c523 # bad: [5d42f82a9b8c5168d75cf59307cd271feca94464] Merge tag 'v3.16' into drm-next git bisect bad 5d42f82a9b8c5168d75cf59307cd271feca94464 # good: [0e32b39ceed665bfa4a77a4bc307b6652b991632] drm/i915: add DP 1.2 MST support (v0.7) git bisect good 0e32b39ceed665bfa4a77a4bc307b6652b991632 # bad: [4dac3edfe68e5e1b3c2216b84ba160572420fa40] Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next git bisect bad 4dac3edfe68e5e1b3c2216b84ba160572420fa40 # good: [eeefa889cddb8d7e4ee6ce0212e685dd624d66a1] drm/i915: Remove redundant HAS_PSR checks git bisect good eeefa889cddb8d7e4ee6ce0212e685dd624d66a1 # good: [4651fb23f6f1d86700b07a27ad7f137d28492342] drm/i915: remove useless runtime PM get calls git bisect good 4651fb23f6f1d86700b07a27ad7f137d28492342 # first bad commit: [4dac3edfe68e5e1b3c2216b84ba160572420fa40] Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next Any thoughts on that? Greetings Daniel -- Daniel Exner Public-Key: https://www.dragonslave.de/pub_key.asc [drm:drm_pci_init] [drm:drm_get_pci_dev] [drm:drm_minor_register] [drm:drm_minor_register] new minor registered 64 [drm:drm_minor_register] [drm:drm_minor_register] new minor registered 128 [drm:drm_minor_register] [drm:drm_minor_register] new minor registered 0 [drm:i915_dump_device_info] i915 device info: gen=7, pciid=0x0166 rev=0x09 flags=is_mobile,need_gfx_hws,is_ivybridge,has_fbc,has_hotplug,has_llc, [drm:intel_detect_pch] Found PantherPoint PCH [drm] Memory usable by graphics device = 2048M [drm:i915_gem_gtt_init] GMADR size = 256M [drm:i915_gem_gtt_init] GTT stolen size = 64M [drm:i915_gem_gtt_init] ppgtt mode: 1 [drm] Replacing VGA console driver checking generic (d000 1e) vs hw (d000 1000) fb: switching to inteldrmfb from EFI VGA Console: switching to colour dummy device 80x25 [drm:intel_opregion_setup] graphic opregion physical addr: 0xc9b55018 [drm:intel_opregion_setup] Public ACPI methods supported [drm:intel_opregion_setup] SWSCI supported [drm:swsci_setup] SWSCI GBDA callbacks 0cf3, SBCB callbacks 0241 [drm:intel_opregion_setup] ASLE supported i915 :00:02.0: irq 33 for MSI/MSI-X [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. [drm:init_vbt_defaults] Set default to SSC at 12 kHz [drm:validate_vbt] Using VBT from OpRegion: $VBT SNB/IVB-MOBILE d [drm:parse_general_features] BDB_GENERAL_FEATURES int_tv_support 0 int_crt_support 1 lvds_use_ssc 0 lvds_ssc_freq 12 display_clock_mode 0 fdi_rx_polarity_inverted 0 [drm:parse_general_definitions] crt_ddc_bus_pin: 2 [drm:parse_lfp_panel_data] DRRS supported mode is seamless [drm:parse_lfp_panel_data] Found panel mode in BIOS VBT tables: [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 0 148500 1920 2008 2053 2200 1080 1083 1089 1125 0x8 0xa [drm:parse_lfp_panel_data] VBT initial LVDS value 300 [drm:parse_lfp_backlight] VBT backlight PWM modulation frequency 210 Hz, active high, min brightness 255, level 255 [drm:parse_sdvo_panel_data] Found SDVO panel mode in BIOS VBT tables: [drm:drm_mode_debug_printmodeline] Modeline 0:"1600x1200" 0 162000 1600 1664 1856 2160 1200 1201 1204 1250 0x8 0xa [drm:parse_sdvo_device_mapping] No SDVO device info is found in VBT [drm:parse_driver_features] DRRS State Enabled:0 [drm:intel_dsm_pci_probe] no _DSM method for intel device [drm:i915_gem_init_stolen] found 67108864 bytes of stolen memory at cba0 [drm:intel_display_power_get] enabling always-on [drm:drm_irq_install] irq=33 [drm:intel_print_wm_latency] Primary WM0 latency 12 (1.2 usec) [drm:in
Regression in i915 intel_panel_setup_backligh
Hi, please keep me CC as I am currently not subscribed to the LKML. I recently tested 3.17-rc7 and found my Samsung AtivBook 7 unable to enable inteldrmfb (see attached output of the crash). I managed to bisect it to: commit 4dac3edfe68e5e1b3c2216b84ba160572420fa40 Merge: 486 e05444b Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Tue Jul 29 20:49:36 2014 +0200 Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next Pull in drm-next with Dave's DP MST support so that I can merge some conflicting patches which also touch the driver load sequencing around interrupt handling. Conflicts: drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_dp.c Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch git bisect log: git bisect start 'v3.17.0-rc4' 'v3.15' 'drivers/gpu/drm/i915/intel_dp.c' # bad: [2ce7598c9a453e0acd0e07be7be3f5eb39608ebd] Linux 3.17-rc4 git bisect bad 2ce7598c9a453e0acd0e07be7be3f5eb39608ebd # good: [1860e379875dfe7271c649058aeddffe5afd9d0d] Linux 3.15 git bisect good 1860e379875dfe7271c649058aeddffe5afd9d0d # good: [7c8f8a7007cf0069488e0b4e3db5f89d715f297e] drm/i915: Force PSR exit by inactivating it. git bisect good 7c8f8a7007cf0069488e0b4e3db5f89d715f297e # good: [9ca153017e00550dbeda2718cfd69ca37de9c523] drm/i915: Fix up PSR frontbuffer tracking git bisect good 9ca153017e00550dbeda2718cfd69ca37de9c523 # bad: [5d42f82a9b8c5168d75cf59307cd271feca94464] Merge tag 'v3.16' into drm-next git bisect bad 5d42f82a9b8c5168d75cf59307cd271feca94464 # good: [0e32b39ceed665bfa4a77a4bc307b6652b991632] drm/i915: add DP 1.2 MST support (v0.7) git bisect good 0e32b39ceed665bfa4a77a4bc307b6652b991632 # bad: [4dac3edfe68e5e1b3c2216b84ba160572420fa40] Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next git bisect bad 4dac3edfe68e5e1b3c2216b84ba160572420fa40 # good: [eeefa889cddb8d7e4ee6ce0212e685dd624d66a1] drm/i915: Remove redundant HAS_PSR checks git bisect good eeefa889cddb8d7e4ee6ce0212e685dd624d66a1 # good: [4651fb23f6f1d86700b07a27ad7f137d28492342] drm/i915: remove useless runtime PM get calls git bisect good 4651fb23f6f1d86700b07a27ad7f137d28492342 # first bad commit: [4dac3edfe68e5e1b3c2216b84ba160572420fa40] Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next Any thoughts on that? Greetings Daniel -- Daniel Exner Public-Key: https://www.dragonslave.de/pub_key.asc [drm:drm_pci_init] [drm:drm_get_pci_dev] [drm:drm_minor_register] [drm:drm_minor_register] new minor registered 64 [drm:drm_minor_register] [drm:drm_minor_register] new minor registered 128 [drm:drm_minor_register] [drm:drm_minor_register] new minor registered 0 [drm:i915_dump_device_info] i915 device info: gen=7, pciid=0x0166 rev=0x09 flags=is_mobile,need_gfx_hws,is_ivybridge,has_fbc,has_hotplug,has_llc, [drm:intel_detect_pch] Found PantherPoint PCH [drm] Memory usable by graphics device = 2048M [drm:i915_gem_gtt_init] GMADR size = 256M [drm:i915_gem_gtt_init] GTT stolen size = 64M [drm:i915_gem_gtt_init] ppgtt mode: 1 [drm] Replacing VGA console driver checking generic (d000 1e) vs hw (d000 1000) fb: switching to inteldrmfb from EFI VGA Console: switching to colour dummy device 80x25 [drm:intel_opregion_setup] graphic opregion physical addr: 0xc9b55018 [drm:intel_opregion_setup] Public ACPI methods supported [drm:intel_opregion_setup] SWSCI supported [drm:swsci_setup] SWSCI GBDA callbacks 0cf3, SBCB callbacks 0241 [drm:intel_opregion_setup] ASLE supported i915 :00:02.0: irq 33 for MSI/MSI-X [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. [drm:init_vbt_defaults] Set default to SSC at 12 kHz [drm:validate_vbt] Using VBT from OpRegion: $VBT SNB/IVB-MOBILE d [drm:parse_general_features] BDB_GENERAL_FEATURES int_tv_support 0 int_crt_support 1 lvds_use_ssc 0 lvds_ssc_freq 12 display_clock_mode 0 fdi_rx_polarity_inverted 0 [drm:parse_general_definitions] crt_ddc_bus_pin: 2 [drm:parse_lfp_panel_data] DRRS supported mode is seamless [drm:parse_lfp_panel_data] Found panel mode in BIOS VBT tables: [drm:drm_mode_debug_printmodeline] Modeline 0:1920x1080 0 148500 1920 2008 2053 2200 1080 1083 1089 1125 0x8 0xa [drm:parse_lfp_panel_data] VBT initial LVDS value 300 [drm:parse_lfp_backlight] VBT backlight PWM modulation frequency 210 Hz, active high, min brightness 255, level 255 [drm:parse_sdvo_panel_data] Found SDVO panel mode in BIOS VBT tables: [drm:drm_mode_debug_printmodeline] Modeline 0:1600x1200 0 162000 1600 1664 1856 2160 1200 1201 1204 1250 0x8 0xa [drm:parse_sdvo_device_mapping] No SDVO device info is found in VBT [drm:parse_driver_features] DRRS State Enabled:0 [drm:intel_dsm_pci_probe] no _DSM method for intel device [drm:i915_gem_init_stolen] found 67108864 bytes of stolen memory at cba0 [drm:intel_display_power_get] enabling always-on [drm:drm_irq_install] irq=33 [drm:intel_print_wm_latency] Primary WM0 latency 12
Re: Poor network performance x86_64.. also with 3.13
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, Am Mon, 20 Jan 2014 23:37:52 +0100 schrieb Borislav Petkov : > On Mon, Jan 20, 2014 at 11:27:25PM +0100, Daniel Exner wrote: > > I just did the same procedure with Kernel Version 3.13: same poor > > rates. > > > > I think I will try to see of 3.12.6 was still ok and bisect from > > there. > > Or try something more coarse-grained like 3.11 first, then 3.12 and > then the -rcs in between. > I must apologize for suspecting the kernel for my problems. After some bisect attempts I finaly noticed the following: > cat /etc/sysctl.d/net.conf > net.ipv4.tcp_window_scaling = 1 > net.core.rmem_max = 16777216 > net.ipv4.tcp_rmem = 4096 87380 16777 > net.ipv4.tcp_wmem = 4096 1638 After removing those values I finally had sane iperf values. No idea how those got there, perhaps they made sense when I first setup the box, which is some years ago.. Anyway, thanks all for your help :) Greetings Daniel Exner -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCgAGBQJS95knAAoJEPI6v6bI/QkfZYYP/37WBvygR7gLKqFTYfQA2ALE n6cOLrogoJT8Cf3q1fLqKiSzPToxSuPBTTmQtaNnhxLKTCPFHxLYPbTdtlXGTPB1 vFVJmXg8WAM/kQD/IoHrMsZsHfRWZE+RtQrUfeQ4Ava6abmniBufVe7ERMuF6ddW 02F5COtw74LJuSbxS70Cn3reog/ExoIYOYKQn6+FpoKTME4WnZtA8DJxo1r077RL mNqo3D4OMrYdPhxyRjLygtCnmXuX/yynV2czBnFkME4f1B4P/1hIzqYCxa2dBQIM Pfr+b/TtyVZA3DsE1d22f/+34EFWE/06EM5l8KwImmRHGA9Ffx77jKX4sAxN0Hhg 9ZJleeddk4NahXur5WNAV4lrkiLUgGauC0k721KwBFecFy2gYK/OUIyOm/oA3IPT WAEeGT4nCfCa1vYfoZVBn5UWOZo1eLm5qh6dmGb9FHukmwWTEplRRvYDPyJNfmRg 0j5mvn7ymFIbnmkVSnBFdfJH0I6XhhiHQ9H3cb9It9OLH5eEK1x4AW1okkAwrquQ oNYkpq54aJS/3oDokyWN/Gkvkmmk+4Q6tpxQge0AQPhrNeft5X7b8VhffstWhTSF kO1ULQ+zOtRUHF6T5523qVcS3pzFfqQKPYPhhQspGvuPJEr0M94i2JS016Z84Cz6 krmaHvSO/MKFkm7w+x5d =90En -END PGP SIGNATURE-
Re: Poor network performance x86_64.. also with 3.13
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, Am Mon, 20 Jan 2014 23:37:52 +0100 schrieb Borislav Petkov b...@alien8.de: On Mon, Jan 20, 2014 at 11:27:25PM +0100, Daniel Exner wrote: I just did the same procedure with Kernel Version 3.13: same poor rates. I think I will try to see of 3.12.6 was still ok and bisect from there. Or try something more coarse-grained like 3.11 first, then 3.12 and then the -rcs in between. I must apologize for suspecting the kernel for my problems. After some bisect attempts I finaly noticed the following: cat /etc/sysctl.d/net.conf net.ipv4.tcp_window_scaling = 1 net.core.rmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777 net.ipv4.tcp_wmem = 4096 1638 After removing those values I finally had sane iperf values. No idea how those got there, perhaps they made sense when I first setup the box, which is some years ago.. Anyway, thanks all for your help :) Greetings Daniel Exner -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCgAGBQJS95knAAoJEPI6v6bI/QkfZYYP/37WBvygR7gLKqFTYfQA2ALE n6cOLrogoJT8Cf3q1fLqKiSzPToxSuPBTTmQtaNnhxLKTCPFHxLYPbTdtlXGTPB1 vFVJmXg8WAM/kQD/IoHrMsZsHfRWZE+RtQrUfeQ4Ava6abmniBufVe7ERMuF6ddW 02F5COtw74LJuSbxS70Cn3reog/ExoIYOYKQn6+FpoKTME4WnZtA8DJxo1r077RL mNqo3D4OMrYdPhxyRjLygtCnmXuX/yynV2czBnFkME4f1B4P/1hIzqYCxa2dBQIM Pfr+b/TtyVZA3DsE1d22f/+34EFWE/06EM5l8KwImmRHGA9Ffx77jKX4sAxN0Hhg 9ZJleeddk4NahXur5WNAV4lrkiLUgGauC0k721KwBFecFy2gYK/OUIyOm/oA3IPT WAEeGT4nCfCa1vYfoZVBn5UWOZo1eLm5qh6dmGb9FHukmwWTEplRRvYDPyJNfmRg 0j5mvn7ymFIbnmkVSnBFdfJH0I6XhhiHQ9H3cb9It9OLH5eEK1x4AW1okkAwrquQ oNYkpq54aJS/3oDokyWN/Gkvkmmk+4Q6tpxQge0AQPhrNeft5X7b8VhffstWhTSF kO1ULQ+zOtRUHF6T5523qVcS3pzFfqQKPYPhhQspGvuPJEr0M94i2JS016Z84Cz6 krmaHvSO/MKFkm7w+x5d =90En -END PGP SIGNATURE-
Poor network performance x86_64.. also with 3.13
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Am 18.01.2014 23:46, schrieb Daniel Exner: > Hi again, > > Am 18.01.2014 20:50, schrieb Borislav Petkov: >> + netdev. > Thx > > Am 18.01.2014 20:49, schrieb Holger Hoffstätte:> [This mail was > also posted to gmane.linux.kernel.] > >> On Sat, 18 Jan 2014 20:30:55 +0100, Daniel Exner wrote: > >>> I recently upgraded the Kernel from version 3.10 to latest >>> stable 3.12.8, did the usual "make oldconfig" (resulting >>> config attached). >>> >>> But now I noticed some _really_ low network performance. > >> Try: sysctl net.ipv4.tcp_limit_output_bytes=262144 > > Tried that. Even 10 times the value. Same effect. I just did the same procedure with Kernel Version 3.13: same poor rates. I think I will try to see of 3.12.6 was still ok and bisect from there. Greetings Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJS3aLFAAoJEPI6v6bI/Qkf9+4QAJkfljUsRQn6DA6gWy3XYsn4 ZB3F2Mu8kLsCMVjpASsi7+km2qTiFv4qGOgezHCJmqMcdCFszBweGQrnYBLA5PCD XSZ7G4S0U71aHWtY6iQd1q4ywnA21pfnGRqIpc5+OuIiIOm+YY+RXpJAHC5y1OVo MxsPL1ZVp/enJoZuvblw6i+JT+soAbSypPWcNQ78qb+CYzLVMLZHcqQvMwpAsRvQ LNKx8nyj8p32CdZo1GoT3f/nWvBeh/V/ViLrtt64u/oXMJyk5INVRFpSNUUviP8c 42y+r2K31+nY11K2dHsdJYbv5lZ8p8g0SNoLG1SrjgDspaptnT8jptxxn7GcQqdL PZ3waUB7qYU15IxCA2iXwNPqjtsv8V5l55H/cunKQgxNbb318ui/a3cW7+R++CeL onv9HFNUkHJiP/MvZJ1/FXE0AsjX70un9NuQ0+xFjCRwJ/YLZzCHkWMERcev500O vS1yFTGiVY1HndoA4VFYzEkjOyHgDHHQA+0JkfBspVlhL7ow9hccmULZtEn9LzwU 9rooQHyXwdKr6KIbsjHECyjIsBhW4Jfj6195bZ9ddBDBXSqYyGqjiuy7l7TjlZVa YmPNTlkEfMeXkO2h3km8TD2f+MPntYXkYjZVVUcK8NucgnIdLuWDk/GLrt73VTd8 Cww6B/u4YnGJSF5v/nit =xCa3 -END PGP SIGNATURE- -- 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/
Poor network performance x86_64.. also with 3.13
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Am 18.01.2014 23:46, schrieb Daniel Exner: Hi again, Am 18.01.2014 20:50, schrieb Borislav Petkov: + netdev. Thx Am 18.01.2014 20:49, schrieb Holger Hoffstätte: [This mail was also posted to gmane.linux.kernel.] On Sat, 18 Jan 2014 20:30:55 +0100, Daniel Exner wrote: I recently upgraded the Kernel from version 3.10 to latest stable 3.12.8, did the usual make oldconfig (resulting config attached). But now I noticed some _really_ low network performance. Try: sysctl net.ipv4.tcp_limit_output_bytes=262144 Tried that. Even 10 times the value. Same effect. I just did the same procedure with Kernel Version 3.13: same poor rates. I think I will try to see of 3.12.6 was still ok and bisect from there. Greetings Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJS3aLFAAoJEPI6v6bI/Qkf9+4QAJkfljUsRQn6DA6gWy3XYsn4 ZB3F2Mu8kLsCMVjpASsi7+km2qTiFv4qGOgezHCJmqMcdCFszBweGQrnYBLA5PCD XSZ7G4S0U71aHWtY6iQd1q4ywnA21pfnGRqIpc5+OuIiIOm+YY+RXpJAHC5y1OVo MxsPL1ZVp/enJoZuvblw6i+JT+soAbSypPWcNQ78qb+CYzLVMLZHcqQvMwpAsRvQ LNKx8nyj8p32CdZo1GoT3f/nWvBeh/V/ViLrtt64u/oXMJyk5INVRFpSNUUviP8c 42y+r2K31+nY11K2dHsdJYbv5lZ8p8g0SNoLG1SrjgDspaptnT8jptxxn7GcQqdL PZ3waUB7qYU15IxCA2iXwNPqjtsv8V5l55H/cunKQgxNbb318ui/a3cW7+R++CeL onv9HFNUkHJiP/MvZJ1/FXE0AsjX70un9NuQ0+xFjCRwJ/YLZzCHkWMERcev500O vS1yFTGiVY1HndoA4VFYzEkjOyHgDHHQA+0JkfBspVlhL7ow9hccmULZtEn9LzwU 9rooQHyXwdKr6KIbsjHECyjIsBhW4Jfj6195bZ9ddBDBXSqYyGqjiuy7l7TjlZVa YmPNTlkEfMeXkO2h3km8TD2f+MPntYXkYjZVVUcK8NucgnIdLuWDk/GLrt73VTd8 Cww6B/u4YnGJSF5v/nit =xCa3 -END PGP SIGNATURE- -- 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: 3.12.8 poor network performance x86_64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi again, Am 18.01.2014 20:50, schrieb Borislav Petkov: > + netdev. Thx Am 18.01.2014 20:49, schrieb Holger Hoffstätte:> [This mail was also posted to gmane.linux.kernel.] > > On Sat, 18 Jan 2014 20:30:55 +0100, Daniel Exner wrote: > >> I recently upgraded the Kernel from version 3.10 to latest >> stable 3.12.8, did the usual "make oldconfig" (resulting config >> attached). >> >> But now I noticed some _really_ low network performance. > > Try: sysctl net.ipv4.tcp_limit_output_bytes=262144 Tried that. Even 10 times the value. Same effect. Is there something like that on a lower level of the network stack I might try to change? Could that be something in the cgroups layer? Should I send a dmesg or anything else? Greetings Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJS2wQtAAoJEPI6v6bI/QkfKakP/jsv7VG5bUuSbvXjLQklb8mY kGZvXRktpGMxHbUJe8NCLStbWcGLRoD+ilXh38e0U+icgU/f6uAa6a93cSaF+zi8 imjkyutQqAlevV3Ab3SAaSho6SsWgfTkWZ7kkFooIXU6UwIlqq41923OTpR2bXL4 qvYiYEOOO9Uzg/o0PXeV2VYcgxfnvTqRrpou3yQZK5YhLAZIHd8i9r1yqc+Un4dG 7+Ju/45YpqynX2CJVMx5kP62f9uQbdA9sEKoEkYInVtja0UGUwFXzHgy8RZLHDiM Qhy/yZTzkjR4vai4N+dx2UizGBwgBtng5IzUiXX2HGd8TOMJRBcoPaa0ZBA4CsA+ RjypqL9dOGpw1bxZ/87h9qpvjmZd3mPhb768VKXgzgdEVlp56u5rT1OQEBUju8aS Qprgtf6k1EkjJPWo3DVJrGr/Wk+k8cLASW5qm3wGS7V0k1H0EN+pw7UGvNY99kcf IllTKa6bTkKe15x1BaZjvAwFHR1Fdcdn3A+2WQwy+hha1CsjogHnbhzUjmxHDq+c 8i92oZ1nw2788/ULPKc5hK2o8C4Zsp0JVGHd4Cy4Dy6tvCLSQveDneM/2U3JvCL2 ViOdxh6LGGWFvDpe1w9x+e3QzvXYTFNEXawn/5OIEzbM1XP+VF8zIyHsLG4nNI88 +ICSvsTt86Zg8Zhm96YH =gsnO -END PGP SIGNATURE- -- 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: 3.12.8 poor network performance x86_64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi again, Am 18.01.2014 20:50, schrieb Borislav Petkov: + netdev. Thx Am 18.01.2014 20:49, schrieb Holger Hoffstätte: [This mail was also posted to gmane.linux.kernel.] On Sat, 18 Jan 2014 20:30:55 +0100, Daniel Exner wrote: I recently upgraded the Kernel from version 3.10 to latest stable 3.12.8, did the usual make oldconfig (resulting config attached). But now I noticed some _really_ low network performance. Try: sysctl net.ipv4.tcp_limit_output_bytes=262144 Tried that. Even 10 times the value. Same effect. Is there something like that on a lower level of the network stack I might try to change? Could that be something in the cgroups layer? Should I send a dmesg or anything else? Greetings Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJS2wQtAAoJEPI6v6bI/QkfKakP/jsv7VG5bUuSbvXjLQklb8mY kGZvXRktpGMxHbUJe8NCLStbWcGLRoD+ilXh38e0U+icgU/f6uAa6a93cSaF+zi8 imjkyutQqAlevV3Ab3SAaSho6SsWgfTkWZ7kkFooIXU6UwIlqq41923OTpR2bXL4 qvYiYEOOO9Uzg/o0PXeV2VYcgxfnvTqRrpou3yQZK5YhLAZIHd8i9r1yqc+Un4dG 7+Ju/45YpqynX2CJVMx5kP62f9uQbdA9sEKoEkYInVtja0UGUwFXzHgy8RZLHDiM Qhy/yZTzkjR4vai4N+dx2UizGBwgBtng5IzUiXX2HGd8TOMJRBcoPaa0ZBA4CsA+ RjypqL9dOGpw1bxZ/87h9qpvjmZd3mPhb768VKXgzgdEVlp56u5rT1OQEBUju8aS Qprgtf6k1EkjJPWo3DVJrGr/Wk+k8cLASW5qm3wGS7V0k1H0EN+pw7UGvNY99kcf IllTKa6bTkKe15x1BaZjvAwFHR1Fdcdn3A+2WQwy+hha1CsjogHnbhzUjmxHDq+c 8i92oZ1nw2788/ULPKc5hK2o8C4Zsp0JVGHd4Cy4Dy6tvCLSQveDneM/2U3JvCL2 ViOdxh6LGGWFvDpe1w9x+e3QzvXYTFNEXawn/5OIEzbM1XP+VF8zIyHsLG4nNI88 +ICSvsTt86Zg8Zhm96YH =gsnO -END PGP SIGNATURE- -- 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: 2.6.25 Regression: DriveStatusError
Hi!
Bartlomiej Zolnierkiewicz wrote:
> On Monday 11 February 2008, Daniel Exner wrote:
> > Hi!
> >
> > Please CC me as I'm not subscribed to any list, thx in advance.
> >
> > I tried all -git Kernels since begining of cycle and starting when they
> > finaly compiled fine, they weren't able to mount my root.
> >
> > As my laptop with the serial cable is on the run currently I wasn't able
> > to get a trace (perhaps by the we) but error written by hand from screen
> > was this:
> >
> > hda: task_no_data_intr: status=0x51 {DriveReady SeekComplete Error}
> > hda: task_no_data_intr: error=0x04 {DriveStatusError}
> > failed opcode was: 0xe1
>
> [...]
>
> Could you please try 2.6.25-rc1-git1:
>
> http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.25-rc1-git1.bz2
Fixed, as is in rc2.
thx
P.S. (OT)
2.6.25-rc2 gives 200 points more in Geekbench then 2.6.24.x :)
--
Greetings
Daniel Exner
--
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.25 Regression: DriveStatusError
Hi!
Bartlomiej Zolnierkiewicz wrote:
On Monday 11 February 2008, Daniel Exner wrote:
Hi!
Please CC me as I'm not subscribed to any list, thx in advance.
I tried all -git Kernels since begining of cycle and starting when they
finaly compiled fine, they weren't able to mount my root.
As my laptop with the serial cable is on the run currently I wasn't able
to get a trace (perhaps by the we) but error written by hand from screen
was this:
hda: task_no_data_intr: status=0x51 {DriveReady SeekComplete Error}
hda: task_no_data_intr: error=0x04 {DriveStatusError}
failed opcode was: 0xe1
[...]
Could you please try 2.6.25-rc1-git1:
http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.25-rc1-git1.bz2
Fixed, as is in rc2.
thx
P.S. (OT)
2.6.25-rc2 gives 200 points more in Geekbench then 2.6.24.x :)
--
Greetings
Daniel Exner
--
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/
Uvesafb and token-ring in 2.6.24-rc1 broken
Hi! Like always, pleas CC me as I'm currently not suscribed, I hope I got the right persons already in list. When booting my new shiny 2.6.24-rc1 I get a crash if uvesafb is compiled in. The trace mentiones something about "platform_match", so I guess this is due x86 unification. If helpfull I could try getting something over netconsole, but I think this is a minor glitch, as vesafb boots fine. :) Ah, and token ring tells me something like "/net/token-ring ,3.14 sysctl failed check procname does not match binary path procname" But kernel boots otherwise and I got no chance to test tr itself is working. -- Greetings Daniel Exner - 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/
Uvesafb and token-ring in 2.6.24-rc1 broken
Hi! Like always, pleas CC me as I'm currently not suscribed, I hope I got the right persons already in list. When booting my new shiny 2.6.24-rc1 I get a crash if uvesafb is compiled in. The trace mentiones something about platform_match, so I guess this is due x86 unification. If helpfull I could try getting something over netconsole, but I think this is a minor glitch, as vesafb boots fine. :) Ah, and token ring tells me something like /net/token-ring ,3.14 sysctl failed check procname does not match binary path procname But kernel boots otherwise and I got no chance to test tr itself is working. -- Greetings Daniel Exner - 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 Panic on 2.6.23-rc5 (solved)
Hi! Michal Piotrowski: > On 06/09/07, Daniel Exner <[EMAIL PROTECTED]> wrote: > > I'm not really sure if this is a regression or if I simply hit a hardware > > problem. > > After some time of work (mostly hours sometimes minutes) my system will > > freeze including Blinking LED's and unresponsiveness on SysRQ, but I > > finally got this using netconsole: > > > > CPU 0: Machine Check Exception: 0004 > > Bank 4: b2070f0f > > Kernel panic - not syncing: CPU context corrupt > It is a hardware problem. You where right. I switched the power suply (first guess of hardware guy ;) The Box is now up 2 days 9hrs and no kp so far :) I really should use sensord to show undervoltages in syslog.. > You may want to use mcelog ftp://ftp.x86-64.org/pub/linux/tools/mcelog/ This is a nice tool, but why is it only available for x86_64 ? The MCE reporting facility is in place in x86, too. Anyway I only send this mail to say: Not Kernel's fault. -- Greetings Daniel Exner - 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 Panic on 2.6.23-rc5 (solved)
Hi! Michal Piotrowski: On 06/09/07, Daniel Exner [EMAIL PROTECTED] wrote: I'm not really sure if this is a regression or if I simply hit a hardware problem. After some time of work (mostly hours sometimes minutes) my system will freeze including Blinking LED's and unresponsiveness on SysRQ, but I finally got this using netconsole: CPU 0: Machine Check Exception: 0004 Bank 4: b2070f0f Kernel panic - not syncing: CPU context corrupt It is a hardware problem. You where right. I switched the power suply (first guess of hardware guy ;) The Box is now up 2 days 9hrs and no kp so far :) I really should use sensord to show undervoltages in syslog.. You may want to use mcelog ftp://ftp.x86-64.org/pub/linux/tools/mcelog/ This is a nice tool, but why is it only available for x86_64 ? The MCE reporting facility is in place in x86, too. Anyway I only send this mail to say: Not Kernel's fault. -- Greetings Daniel Exner - 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 Panic on 2.6.23-rc5
06 September 2007 Michal Piotrowski wrote: [..] > > CPU 0: Machine Check Exception: 0004 > > Bank 4: b2070f0f > > Kernel panic - not syncing: CPU context corrupt > > It is a hardware problem. > > You may want to use mcelog ftp://ftp.x86-64.org/pub/linux/tools/mcelog/ Tried this on grml64 (cause I'm normaly on x86) Results: -- WARNING: with --dmi mcelog --ascii must run on the same machine with the same BIOS/memory configuration as where the machine check occurred. HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 0 0 data cache STATUS 0 MCGSTATUS 4 Bank 4: b2070f0f Kernel panic - not syncing: CPU context corrupt --- This really doesnt say me anything the above didn't. Next thing I tried was: parsemce-e 0 -b 4 -s b2070f0f -a 0 Output: Status: (0) Restart IP invalid. parsebank(4): b2070f0f @ 0 External tag parity error CPU state corrupt. Restart not possible Error enabled in control register Error not corrected. Bus and interconnect error Participation: Generic Timeout: Request: Generic error Transaction type : Invalid Memory/IO : Other Wich doesnt tell me anything either :( Google suggest anything from broken CPU(bad), broken RAM(even more bad) to broken mainboard(Ouch..) I'm going to let memtest run overnight. This is the easiest test I guess :) -- Greetings Daniel Exner -- Mit freundlichen Grüßen Daniel Exner - 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 Panic on 2.6.23-rc5
Hi! I'm not really sure if this is a regression or if I simply hit a hardware problem. After some time of work (mostly hours sometimes minutes) my system will freeze including Blinking LED's and unresponsiveness on SysRQ, but I finally got this using netconsole: CPU 0: Machine Check Exception: 0004 Bank 4: b2070f0f Kernel panic - not syncing: CPU context corrupt I Also keep getting ext3 errors about reading or writing in wrong zones. Will now have a - this means many - run of memtest. -- Greetings Daniel Exner - 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 Panic on 2.6.23-rc5
Hi! I'm not really sure if this is a regression or if I simply hit a hardware problem. After some time of work (mostly hours sometimes minutes) my system will freeze including Blinking LED's and unresponsiveness on SysRQ, but I finally got this using netconsole: CPU 0: Machine Check Exception: 0004 Bank 4: b2070f0f Kernel panic - not syncing: CPU context corrupt I Also keep getting ext3 errors about reading or writing in wrong zones. Will now have a - this means many - run of memtest. -- Greetings Daniel Exner - 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 Panic on 2.6.23-rc5
06 September 2007 Michal Piotrowski wrote: [..] CPU 0: Machine Check Exception: 0004 Bank 4: b2070f0f Kernel panic - not syncing: CPU context corrupt It is a hardware problem. You may want to use mcelog ftp://ftp.x86-64.org/pub/linux/tools/mcelog/ Tried this on grml64 (cause I'm normaly on x86) Results: -- WARNING: with --dmi mcelog --ascii must run on the same machine with the same BIOS/memory configuration as where the machine check occurred. HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 0 0 data cache STATUS 0 MCGSTATUS 4 Bank 4: b2070f0f Kernel panic - not syncing: CPU context corrupt --- This really doesnt say me anything the above didn't. Next thing I tried was: parsemce-e 0 -b 4 -s b2070f0f -a 0 Output: Status: (0) Restart IP invalid. parsebank(4): b2070f0f @ 0 External tag parity error CPU state corrupt. Restart not possible Error enabled in control register Error not corrected. Bus and interconnect error Participation: Generic Timeout: Request: Generic error Transaction type : Invalid Memory/IO : Other Wich doesnt tell me anything either :( Google suggest anything from broken CPU(bad), broken RAM(even more bad) to broken mainboard(Ouch..) I'm going to let memtest run overnight. This is the easiest test I guess :) -- Greetings Daniel Exner -- Mit freundlichen Grüßen Daniel Exner - 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/
[PATCH] Override 80-wire cable detection for Toshiba S1800-814 (resend)
Hi!
Please CC me, as I'm currently not subscribed to this list, thx.
Another try :)
--
Greetings
Daniel Exner
Add Toshiba S1800-814 to whitelist for both
pata_ali and alim15x3, as it is correctly detected as 40-wire connected but
this cable is short enough to still use transfer modes higher than UDMA33.
Signed-off-by: Daniel Exner <[EMAIL PROTECTED]>
--- linux-2.6.22.old/drivers/ata/pata_ali.c 2007-08-29 23:27:53.0 +0200
+++ linux-2.6.22/drivers/ata/pata_ali.c 2007-08-29 23:14:37.0 +0200
@@ -48,6 +48,13 @@
DMI_MATCH(DMI_BOARD_VERSION, "OmniBook N32N-736"),
},
},
+ {
+ .ident = "Toshiba Satelite S1800-814",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "S1800-814"),
+ },
+ },
{ }
};
--- linux-2.6.22.old/drivers/ide/pci/alim15x3.c 2007-08-29 22:17:14.0 +0200
+++ linux-2.6.22/drivers/ide/pci/alim15x3.c 2007-08-29 22:56:27.0 +0200
@@ -596,6 +596,13 @@
DMI_MATCH(DMI_BOARD_VERSION, "OmniBook N32N-736"),
},
},
+ {
+ .ident = "Toshiba Satellite S1800-814",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "S1800-814"),
+ },
+ },
{ }
};
[PATCH] Override 80-wire cable detection for Toshiba S1800-814 (resend)
Hi!
Please CC me, as I'm currently not subscribed to this list, thx.
Another try :)
--
Greetings
Daniel Exner
Add Toshiba S1800-814 to whitelist for both
pata_ali and alim15x3, as it is correctly detected as 40-wire connected but
this cable is short enough to still use transfer modes higher than UDMA33.
Signed-off-by: Daniel Exner [EMAIL PROTECTED]
--- linux-2.6.22.old/drivers/ata/pata_ali.c 2007-08-29 23:27:53.0 +0200
+++ linux-2.6.22/drivers/ata/pata_ali.c 2007-08-29 23:14:37.0 +0200
@@ -48,6 +48,13 @@
DMI_MATCH(DMI_BOARD_VERSION, OmniBook N32N-736),
},
},
+ {
+ .ident = Toshiba Satelite S1800-814,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
+ DMI_MATCH(DMI_PRODUCT_NAME, S1800-814),
+ },
+ },
{ }
};
--- linux-2.6.22.old/drivers/ide/pci/alim15x3.c 2007-08-29 22:17:14.0 +0200
+++ linux-2.6.22/drivers/ide/pci/alim15x3.c 2007-08-29 22:56:27.0 +0200
@@ -596,6 +596,13 @@
DMI_MATCH(DMI_BOARD_VERSION, OmniBook N32N-736),
},
},
+ {
+ .ident = Toshiba Satellite S1800-814,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
+ DMI_MATCH(DMI_PRODUCT_NAME, S1800-814),
+ },
+ },
{ }
};
[PATCH] Override 80-wire cable detection for Toshiba S1800-814
Hi!
Please CC me, as I'm currently not subscribed to this list, thx.
Attached patch will add above mentioned Laptop Model to whitelist for both
pata_ali and alim15x3, as it is correctly detected as 40-wire connected but
this cable is short enough to still do transfers higher than UDMA33.
Don't know if this is also true for other S1800 Laptops cause I own only one.
I hope I did this correctly as this is my first Patch Mail to LKML :)
--
Greetings
Daniel Exner
--- linux-2.6.22.old/drivers/ata/pata_ali.c 2007-08-29 23:27:53.0 +0200
+++ linux-2.6.22/drivers/ata/pata_ali.c 2007-08-29 23:14:37.0 +0200
@@ -48,6 +48,13 @@
DMI_MATCH(DMI_BOARD_VERSION, "OmniBook N32N-736"),
},
},
+ {
+ .ident = "Toshiba Satelite S1800-814",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "S1800-814"),
+ },
+ },
{ }
};
--- linux-2.6.22.old/drivers/ide/pci/alim15x3.c 2007-08-29 22:17:14.0 +0200
+++ linux-2.6.22/drivers/ide/pci/alim15x3.c 2007-08-29 22:56:27.0 +0200
@@ -596,6 +596,13 @@
DMI_MATCH(DMI_BOARD_VERSION, "OmniBook N32N-736"),
},
},
+ {
+ .ident = "Toshiba Satellite S1800-814",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "S1800-814"),
+ },
+ },
{ }
};
[PATCH] Override 80-wire cable detection for Toshiba S1800-814
Hi!
Please CC me, as I'm currently not subscribed to this list, thx.
Attached patch will add above mentioned Laptop Model to whitelist for both
pata_ali and alim15x3, as it is correctly detected as 40-wire connected but
this cable is short enough to still do transfers higher than UDMA33.
Don't know if this is also true for other S1800 Laptops cause I own only one.
I hope I did this correctly as this is my first Patch Mail to LKML :)
--
Greetings
Daniel Exner
--- linux-2.6.22.old/drivers/ata/pata_ali.c 2007-08-29 23:27:53.0 +0200
+++ linux-2.6.22/drivers/ata/pata_ali.c 2007-08-29 23:14:37.0 +0200
@@ -48,6 +48,13 @@
DMI_MATCH(DMI_BOARD_VERSION, OmniBook N32N-736),
},
},
+ {
+ .ident = Toshiba Satelite S1800-814,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
+ DMI_MATCH(DMI_PRODUCT_NAME, S1800-814),
+ },
+ },
{ }
};
--- linux-2.6.22.old/drivers/ide/pci/alim15x3.c 2007-08-29 22:17:14.0 +0200
+++ linux-2.6.22/drivers/ide/pci/alim15x3.c 2007-08-29 22:56:27.0 +0200
@@ -596,6 +596,13 @@
DMI_MATCH(DMI_BOARD_VERSION, OmniBook N32N-736),
},
},
+ {
+ .ident = Toshiba Satellite S1800-814,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
+ DMI_MATCH(DMI_PRODUCT_NAME, S1800-814),
+ },
+ },
{ }
};
Re: EHCI Regression in 2.6.23-rc2
David Brownell wrote: > > ehci_hcd :00:10.4: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 > > > > Build into: > > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge > > [K8T800/K8T890 South] > > Yeah, VT8235 was their first southbridge with integrated EHCI. > ISTR that the VT8237 worked a bit more smoothly. > > I think 8237 was about where they forked off the the VT6212 as > their first discrete EHCI (for addon cards) claiming EHCI 1.0 > conformance. Too bad they didn't recycle all the VT6202 chips > in their inventory at that time... No hardware producer would have done that ;) > Now ... are you reporting that this worked with Stuart's patch? > Or that it didn't? Or that you couldn't say? As I started this thread because Stuart's patch freezes my whole system (at least my bitsect did blame him), I therefore report that it doesnt work for me. Greetings Daniel Exner - 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: EHCI Regression in 2.6.23-rc2
David Brownell wrote: > On Monday 13 August 2007, Daniel Exner wrote: [..] > > Where exactly should I search for this? Neither lspci nor lsusb showed > > any hint on the EHCI rev. the chip conforms to.. > > The driver logs that information as it starts; on this sytem: > > ehci_hcd :00:02.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 > > vs "EHCI 0.95". ehci_hcd :00:10.4: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 Build into: 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] > > > > I've also acquired a card with an NEC EHCI controller on it, which > > > > I'm going to look at while I'm into it... > > > > > > Another case where there are a lot of add-on "EHCI 0.95" cards; but > > > in this case the quirks were less significant. > > > > Some guy donated me a PCMCIA card with one of those, cause it'll wont > > work in his Windows only Notebook :) > > A NEC 0.95 ?? Should be fine with Linux. Assuming no bugs have > crept in. Didn't test it yet with 2.6.23-rc2 or rc3, but up to 2.6.22 it was fine :) Regarding the option to blacklist VIA in the module: I would prefer blacklisting VIA by default but giving the module some parameter like "honours inactive bit" to override this. Perhaps there are newer VIA Chips out there, that indeed do this and some users trigger happy enough to test this. :) Greetings Daniel Exner - 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: EHCI Regression in 2.6.23-rc2
David Brownell wrote: > On Monday 13 August 2007, [EMAIL PROTECTED] wrote: > > With the VIA controller I have, > > Which kind is that? The VT6202 is buggy as all get-out, and > they sold a *LOT* of those discrete chips for use in add-on PCI > cards. We generally warn people away from those. A more current > version is the VT6212, which was much more usable. (If it says > EHCI 0.95, it's a VT6202... their EHCI 1.0 chips were much better.) Where exactly should I search for this? Neither lspci nor lsusb showed any hint on the EHCI rev. the chip conforms to.. [..] > > Perhaps for now the best thing would just be to bypass the EHCI CPU > > frequency notifier code (i.e., my patch) for VIA EHCI controllers, since > > they are broken. Would a hard-coded blacklist (just an "if > > (manufacturer==VIA)..." type thing) be OK? > > Yes ... although if you don't need to blacklist their EHCI 1.0 chips > don't do it. (Any VIA EHCI integrated into a southbridge is going > to follow spec rev 1.0 pretty well, modulo idiosyncratic timings.) I guess its needed to blacklist even the ECHI 1.0 chips, since my problem is with exactly one of those ;) I'm not really into USB protocol specs, but perhaps its possible to test wether the problem Stuarts patch addressed can actually happen on VIA EHCI chips? Perhaps those guys solved the problem in Hard/Firmware.. > > I've also acquired a card with an NEC EHCI controller on it, which I'm > > going to look at while I'm into it... > > Another case where there are a lot of add-on "EHCI 0.95" cards; but > in this case the quirks were less significant. Some guy donated me a PCMCIA card with one of those, cause it'll wont work in his Windows only Notebook :) Greetings Daniel Exner - 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: EHCI Regression in 2.6.23-rc2
David Brownell wrote: On Monday 13 August 2007, [EMAIL PROTECTED] wrote: With the VIA controller I have, Which kind is that? The VT6202 is buggy as all get-out, and they sold a *LOT* of those discrete chips for use in add-on PCI cards. We generally warn people away from those. A more current version is the VT6212, which was much more usable. (If it says EHCI 0.95, it's a VT6202... their EHCI 1.0 chips were much better.) Where exactly should I search for this? Neither lspci nor lsusb showed any hint on the EHCI rev. the chip conforms to.. [..] Perhaps for now the best thing would just be to bypass the EHCI CPU frequency notifier code (i.e., my patch) for VIA EHCI controllers, since they are broken. Would a hard-coded blacklist (just an if (manufacturer==VIA)... type thing) be OK? Yes ... although if you don't need to blacklist their EHCI 1.0 chips don't do it. (Any VIA EHCI integrated into a southbridge is going to follow spec rev 1.0 pretty well, modulo idiosyncratic timings.) I guess its needed to blacklist even the ECHI 1.0 chips, since my problem is with exactly one of those ;) I'm not really into USB protocol specs, but perhaps its possible to test wether the problem Stuarts patch addressed can actually happen on VIA EHCI chips? Perhaps those guys solved the problem in Hard/Firmware.. I've also acquired a card with an NEC EHCI controller on it, which I'm going to look at while I'm into it... Another case where there are a lot of add-on EHCI 0.95 cards; but in this case the quirks were less significant. Some guy donated me a PCMCIA card with one of those, cause it'll wont work in his Windows only Notebook :) Greetings Daniel Exner - 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: EHCI Regression in 2.6.23-rc2
David Brownell wrote: On Monday 13 August 2007, Daniel Exner wrote: [..] Where exactly should I search for this? Neither lspci nor lsusb showed any hint on the EHCI rev. the chip conforms to.. The driver logs that information as it starts; on this sytem: ehci_hcd :00:02.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 vs EHCI 0.95. ehci_hcd :00:10.4: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 Build into: 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] I've also acquired a card with an NEC EHCI controller on it, which I'm going to look at while I'm into it... Another case where there are a lot of add-on EHCI 0.95 cards; but in this case the quirks were less significant. Some guy donated me a PCMCIA card with one of those, cause it'll wont work in his Windows only Notebook :) A NEC 0.95 ?? Should be fine with Linux. Assuming no bugs have crept in. Didn't test it yet with 2.6.23-rc2 or rc3, but up to 2.6.22 it was fine :) Regarding the option to blacklist VIA in the module: I would prefer blacklisting VIA by default but giving the module some parameter like honours inactive bit to override this. Perhaps there are newer VIA Chips out there, that indeed do this and some users trigger happy enough to test this. :) Greetings Daniel Exner - 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: EHCI Regression in 2.6.23-rc2
David Brownell wrote: ehci_hcd :00:10.4: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 Build into: 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] Yeah, VT8235 was their first southbridge with integrated EHCI. ISTR that the VT8237 worked a bit more smoothly. I think 8237 was about where they forked off the the VT6212 as their first discrete EHCI (for addon cards) claiming EHCI 1.0 conformance. Too bad they didn't recycle all the VT6202 chips in their inventory at that time... No hardware producer would have done that ;) Now ... are you reporting that this worked with Stuart's patch? Or that it didn't? Or that you couldn't say? As I started this thread because Stuart's patch freezes my whole system (at least my bitsect did blame him), I therefore report that it doesnt work for me. Greetings Daniel Exner - 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: EHCI Regression in 2.6.23-rc2
Jiri Kosina wrote: > On Fri, 10 Aug 2007, Daniel Exner wrote: > > Please CC me, as I'm currently not subscribed to this list, thx. > > Please also don't forget to CC relevant people/lists when reporting bugs, > thanks. Guess its ok, now? Thanks anyway :) > > After some serious hangs with 2.6.23-rc2 I did some bisects and this was > > the result: > > 196705c9bbc03540429b0f7cf9ee35c2f928a534 is first bad commit > > commit 196705c9bbc03540429b0f7cf9ee35c2f928a534 > > Author: [EMAIL PROTECTED] <[EMAIL PROTECTED]> > > Date: Thu May 3 08:58:49 2007 -0700 > > I guess that the patch attached to bug 8535 in kernel.org bugzilla -- > http://bugzilla.kernel.org/attachment.cgi?id=12228=view -- solves > your issues, right? Nope, this does _not_ fix my issue. Anything else I could try, or some files you need? I tried finding some clue in my logs, but without any results so far. Greetings Daniel Exner - 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/
EHCI Regression in 2.6.23-rc2
Hi! Please CC me, as I'm currently not subscribed to this list, thx. After some serious hangs with 2.6.23-rc2 I did some bisects and this was the result: 196705c9bbc03540429b0f7cf9ee35c2f928a534 is first bad commit commit 196705c9bbc03540429b0f7cf9ee35c2f928a534 Author: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Thu May 3 08:58:49 2007 -0700 USB: EHCI cpufreq fix EHCI controllers that don't cache enough microframes can get MMF errors when CPU frequency changes occur between the start and completion of split interrupt transactions, due to delays in reading main memory (caused by CPU cache snoop delays). This patch adds a cpufreq notifier to the EHCI driver that will inactivate split interrupt transactions during frequency transitions. It was tested on Intel ICH7 and Serverworks/Broadcom HT1000 EHCI controllers. Signed-off-by: Stuart Hayes <[EMAIL PROTECTED]> Signed-off-by: David Brownell <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> :04 04 0e6d518de17cf18155c7529f7b044a4660ca24e9 736bbcc7d3fb138138ee1840d8a6b83b959c07fc M drivers As expected my system only hangs when cpufreq, powernow-k8 and ehci modules are loaded, and some transition should occur. (Simulated by using userspace governour and changing freq manually) The corresponding EHCI Controller is: 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. A7V600/K8V-X/A8V Deluxe motherboard I could not get my hands on any output while the hang occurs, seems like the CPU is really bad locked. Greetings Daniel Exner - 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/
EHCI Regression in 2.6.23-rc2
Hi! Please CC me, as I'm currently not subscribed to this list, thx. After some serious hangs with 2.6.23-rc2 I did some bisects and this was the result: 196705c9bbc03540429b0f7cf9ee35c2f928a534 is first bad commit commit 196705c9bbc03540429b0f7cf9ee35c2f928a534 Author: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Thu May 3 08:58:49 2007 -0700 USB: EHCI cpufreq fix EHCI controllers that don't cache enough microframes can get MMF errors when CPU frequency changes occur between the start and completion of split interrupt transactions, due to delays in reading main memory (caused by CPU cache snoop delays). This patch adds a cpufreq notifier to the EHCI driver that will inactivate split interrupt transactions during frequency transitions. It was tested on Intel ICH7 and Serverworks/Broadcom HT1000 EHCI controllers. Signed-off-by: Stuart Hayes [EMAIL PROTECTED] Signed-off-by: David Brownell [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] :04 04 0e6d518de17cf18155c7529f7b044a4660ca24e9 736bbcc7d3fb138138ee1840d8a6b83b959c07fc M drivers As expected my system only hangs when cpufreq, powernow-k8 and ehci modules are loaded, and some transition should occur. (Simulated by using userspace governour and changing freq manually) The corresponding EHCI Controller is: 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. A7V600/K8V-X/A8V Deluxe motherboard I could not get my hands on any output while the hang occurs, seems like the CPU is really bad locked. Greetings Daniel Exner - 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: EHCI Regression in 2.6.23-rc2
Jiri Kosina wrote: On Fri, 10 Aug 2007, Daniel Exner wrote: Please CC me, as I'm currently not subscribed to this list, thx. Please also don't forget to CC relevant people/lists when reporting bugs, thanks. Guess its ok, now? Thanks anyway :) After some serious hangs with 2.6.23-rc2 I did some bisects and this was the result: 196705c9bbc03540429b0f7cf9ee35c2f928a534 is first bad commit commit 196705c9bbc03540429b0f7cf9ee35c2f928a534 Author: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Thu May 3 08:58:49 2007 -0700 I guess that the patch attached to bug 8535 in kernel.org bugzilla -- http://bugzilla.kernel.org/attachment.cgi?id=12228action=view -- solves your issues, right? Nope, this does _not_ fix my issue. Anything else I could try, or some files you need? I tried finding some clue in my logs, but without any results so far. Greetings Daniel Exner - 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/
