Re: Linux 4.13.4
Hi, It works with 14-rc2, so I rebuilt 13.4 with the commit included again and its behaving too :-/ Something strange must have happened in the original 13.4 build or my hw was in a strange state (for two boots...) Sorry for the noise. Thanks Ed Tomlinson On Saturday, September 30, 2017 11:48:49 AM EDT, Ed Tomlinson wrote: Hi It looks to be this commit. 4.14-rc2 is building Thanks Ed commit 2890decfd9969cac21067ca0c734fbccaf74d634 Author: Zhang, Jerry <jerry.zh...@amd.com> Date: Fri Jul 14 18:20:17 2017 +0800 drm/amdgpu: read reg in each iterator of psp_wait_for loop v2: fix the SOS loading failure for PSP v3.1 Signed-off-by: Junwei Zhang <jerry.zh...@amd.com> Cc: sta...@vger.kernel.org Acked-by: Alex Deucher <alexander.deuc...@amd.com> (v1) Acked-by: Huang Rui <ray.hu...@amd.com> (v1) Reviewed-by: Alex Deucher <alexander.deuc...@amd.com> Signed-off-by: Alex Deucher <alexander.deuc...@amd.com> On Saturday, September 30, 2017 11:31:06 AM EDT, Greg KH wrote: On Sat, Sep 30, 2017 at 11:14:42AM -0400, Ed Tomlinson wrote: ...
Re: Linux 4.13.4
Hi, It works with 14-rc2, so I rebuilt 13.4 with the commit included again and its behaving too :-/ Something strange must have happened in the original 13.4 build or my hw was in a strange state (for two boots...) Sorry for the noise. Thanks Ed Tomlinson On Saturday, September 30, 2017 11:48:49 AM EDT, Ed Tomlinson wrote: Hi It looks to be this commit. 4.14-rc2 is building Thanks Ed commit 2890decfd9969cac21067ca0c734fbccaf74d634 Author: Zhang, Jerry Date: Fri Jul 14 18:20:17 2017 +0800 drm/amdgpu: read reg in each iterator of psp_wait_for loop v2: fix the SOS loading failure for PSP v3.1 Signed-off-by: Junwei Zhang Cc: sta...@vger.kernel.org Acked-by: Alex Deucher (v1) Acked-by: Huang Rui (v1) Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher On Saturday, September 30, 2017 11:31:06 AM EDT, Greg KH wrote: On Sat, Sep 30, 2017 at 11:14:42AM -0400, Ed Tomlinson wrote: ...
Re: Linux 4.13.4
Hi It looks to be this commit. 4.14-rc2 is building Thanks Ed commit 2890decfd9969cac21067ca0c734fbccaf74d634 Author: Zhang, Jerry <jerry.zh...@amd.com> Date: Fri Jul 14 18:20:17 2017 +0800 drm/amdgpu: read reg in each iterator of psp_wait_for loop v2: fix the SOS loading failure for PSP v3.1 Signed-off-by: Junwei Zhang <jerry.zh...@amd.com> Cc: sta...@vger.kernel.org Acked-by: Alex Deucher <alexander.deuc...@amd.com> (v1) Acked-by: Huang Rui <ray.hu...@amd.com> (v1) Reviewed-by: Alex Deucher <alexander.deuc...@amd.com> Signed-off-by: Alex Deucher <alexander.deuc...@amd.com> On Saturday, September 30, 2017 11:31:06 AM EDT, Greg KH wrote: On Sat, Sep 30, 2017 at 11:14:42AM -0400, Ed Tomlinson wrote: Hi I did things old school via patch -R. This is what I reverted: --- diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c ... Any chance to dig out _which_ patch this was? I don't have access to my tree at the moment... And what about 4.14-rc2? thanks, greg k-h
Re: Linux 4.13.4
Hi It looks to be this commit. 4.14-rc2 is building Thanks Ed commit 2890decfd9969cac21067ca0c734fbccaf74d634 Author: Zhang, Jerry Date: Fri Jul 14 18:20:17 2017 +0800 drm/amdgpu: read reg in each iterator of psp_wait_for loop v2: fix the SOS loading failure for PSP v3.1 Signed-off-by: Junwei Zhang Cc: sta...@vger.kernel.org Acked-by: Alex Deucher (v1) Acked-by: Huang Rui (v1) Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher On Saturday, September 30, 2017 11:31:06 AM EDT, Greg KH wrote: On Sat, Sep 30, 2017 at 11:14:42AM -0400, Ed Tomlinson wrote: Hi I did things old school via patch -R. This is what I reverted: --- diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c ... Any chance to dig out _which_ patch this was? I don't have access to my tree at the moment... And what about 4.14-rc2? thanks, greg k-h
Re: Linux 4.13.4
Hi
I did things old school via patch -R. This is what I reverted:
---
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index 4083be61b328..6417febe18b9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -95,9 +95,8 @@ int psp_wait_for(struct psp_context *psp, uint32_t
reg_index,
int i;
struct amdgpu_device *adev = psp->adev;
- val = RREG32(reg_index);
-
for (i = 0; i < adev->usec_timeout; i++) {
+ val = RREG32(reg_index);
if (check_changed) {
if (val != reg_val)
return 0;
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
b/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
index c98d77d0c8f8..6f80ad8f588b 100644
--- a/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
+++ b/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
@@ -237,11 +237,9 @@ int psp_v3_1_bootloader_load_sos(struct psp_context
*psp)
/* there might be handshake issue with hardware which needs delay
*/
mdelay(20);
-#if 0
ret = psp_wait_for(psp, SOC15_REG_OFFSET(MP0, 0,
mmMP0_SMN_C2PMSG_81),
RREG32_SOC15(MP0, 0, mmMP0_SMN_C2PMSG_81),
0, true);
-#endif
return ret;
}
---
Thanks
Ed
On Saturday, September 30, 2017 10:24:17 AM EDT, Greg KH wrote:
On Sat, Sep 30, 2017 at 09:49:28AM -0400, Ed Tomlinson wrote:
Hi,
This build causes very annoying flickering on my display. I
am using the in
kernel amdgpu module to drive a RX480 with 4G via display port. When X is
started (kde) I get flickers that are extrememly distracting. The linux
install is arch stable and is up to date. Nothing interesting
in dmesg. ...
What was the git commit id that you reverted to fix the issue?
Is the issue in 4.14-rc2?
thanks,
greg k-h
Re: Linux 4.13.4
Hi
I did things old school via patch -R. This is what I reverted:
---
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index 4083be61b328..6417febe18b9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -95,9 +95,8 @@ int psp_wait_for(struct psp_context *psp, uint32_t
reg_index,
int i;
struct amdgpu_device *adev = psp->adev;
- val = RREG32(reg_index);
-
for (i = 0; i < adev->usec_timeout; i++) {
+ val = RREG32(reg_index);
if (check_changed) {
if (val != reg_val)
return 0;
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
b/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
index c98d77d0c8f8..6f80ad8f588b 100644
--- a/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
+++ b/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
@@ -237,11 +237,9 @@ int psp_v3_1_bootloader_load_sos(struct psp_context
*psp)
/* there might be handshake issue with hardware which needs delay
*/
mdelay(20);
-#if 0
ret = psp_wait_for(psp, SOC15_REG_OFFSET(MP0, 0,
mmMP0_SMN_C2PMSG_81),
RREG32_SOC15(MP0, 0, mmMP0_SMN_C2PMSG_81),
0, true);
-#endif
return ret;
}
---
Thanks
Ed
On Saturday, September 30, 2017 10:24:17 AM EDT, Greg KH wrote:
On Sat, Sep 30, 2017 at 09:49:28AM -0400, Ed Tomlinson wrote:
Hi,
This build causes very annoying flickering on my display. I
am using the in
kernel amdgpu module to drive a RX480 with 4G via display port. When X is
started (kde) I get flickers that are extrememly distracting. The linux
install is arch stable and is up to date. Nothing interesting
in dmesg. ...
What was the git commit id that you reverted to fix the issue?
Is the issue in 4.14-rc2?
thanks,
greg k-h
Re: Linux 4.13.4
Hi, This build causes very annoying flickering on my display. I am using the in kernel amdgpu module to drive a RX480 with 4G via display port. When X is started (kde) I get flickers that are extrememly distracting. The linux install is arch stable and is up to date. Nothing interesting in dmesg. Reverting the changes to: drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c|3 drivers/gpu/drm/amd/amdgpu/psp_v3_1.c |2 fixes the issue here. Thanks Ed Tomlinson On Thursday, September 28, 2017 4:33:02 AM EDT, Greg KH wrote: I'm announcing the release of the 4.13.4 kernel. All users of the 4.13 kernel series must upgrade. The updated 4.13.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.13.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/dev-tools/gdb-kernel-debugging.rst |6 Makefile |2 arch/arc/kernel/entry.S|6 arch/arc/mm/tlb.c |3 arch/mips/math-emu/dp_fmax.c | 84 +-- arch/mips/math-emu/dp_fmin.c | 86 +-- arch/mips/math-emu/dp_maddf.c | 246 + arch/mips/math-emu/ieee754int.h|4 arch/mips/math-emu/ieee754sp.h |4 arch/mips/math-emu/sp_fmax.c | 84 +-- arch/mips/math-emu/sp_fmin.c | 86 +-- arch/mips/math-emu/sp_maddf.c | 229 +-- arch/powerpc/kernel/align.c| 119 ++ arch/powerpc/platforms/powernv/npu-dma.c | 12 - arch/powerpc/platforms/pseries/hotplug-memory.c|4 arch/s390/include/asm/mmu.h|2 arch/s390/include/asm/mmu_context.h|8 arch/s390/include/asm/tlbflush.h | 30 -- block/blk-core.c |9 block/blk-mq.c | 16 + block/blk-mq.h |1 crypto/algif_skcipher.c|4 crypto/scompress.c |4 drivers/block/skd_main.c | 21 + drivers/crypto/caam/caamalg_qi.c | 11 drivers/crypto/ccp/ccp-crypto-aes-xts.c|4 drivers/crypto/ccp/ccp-dev-v5.c|2 drivers/crypto/ccp/ccp-dev.h |2 drivers/crypto/ccp/ccp-ops.c | 43 ++- drivers/devfreq/devfreq.c |5 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c|3 drivers/gpu/drm/amd/amdgpu/psp_v3_1.c |2 drivers/infiniband/hw/hfi1/init.c |1 drivers/infiniband/hw/hfi1/rc.c|3 drivers/infiniband/hw/mlx5/mr.c| 18 + drivers/infiniband/hw/qib/qib_rc.c |4 drivers/input/joystick/xpad.c | 10 drivers/input/serio/i8042-x86ia64io.h |7 drivers/mailbox/bcm-flexrm-mailbox.c |2 drivers/md/bcache/bcache.h |1 drivers/md/bcache/request.c| 12 - drivers/md/bcache/super.c |7 drivers/md/bcache/sysfs.c |4 drivers/md/bcache/util.c | 50 ++-- drivers/md/bcache/writeback.c | 20 + drivers/md/bcache/writeback.h | 21 + drivers/md/bitmap.c|9 drivers/media/i2c/adv7180.c|2 drivers/media/platform/qcom/venus/helpers.c|2 drivers/media/rc/lirc_dev.c|4 drivers/media/usb/uvc/uvc_ctrl.c |7 drivers/media/v4l2-core/v4l2-compat-ioctl32.c |3 drivers/misc/cxl/api.c |4 drivers/misc/cxl/file.c|8 drivers/net/wireless/ath/wcn36xx/main.c| 52 drivers/net/wireless/ath/wcn36xx/wcn36xx.h |3 drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 62 - drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.h |3 drivers/net/wireless/intel/iwlwifi/mvm/nvm.c |3 drivers/pci/hotplug/pciehp_hpc.c |8 drivers/pci/hotplug/shpchp_hpc.c |2 drivers/pinctrl/pinctrl-amd.c | 75 ++ drivers/pinctrl/pinctrl-amd.h |1 drivers/pinctrl/samsung/pinctrl-exynos.c |8 drivers/pinctrl/samsung/pinctrl-s3c24xx.c | 37
Re: Linux 4.13.4
Hi, This build causes very annoying flickering on my display. I am using the in kernel amdgpu module to drive a RX480 with 4G via display port. When X is started (kde) I get flickers that are extrememly distracting. The linux install is arch stable and is up to date. Nothing interesting in dmesg. Reverting the changes to: drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c|3 drivers/gpu/drm/amd/amdgpu/psp_v3_1.c |2 fixes the issue here. Thanks Ed Tomlinson On Thursday, September 28, 2017 4:33:02 AM EDT, Greg KH wrote: I'm announcing the release of the 4.13.4 kernel. All users of the 4.13 kernel series must upgrade. The updated 4.13.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.13.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/dev-tools/gdb-kernel-debugging.rst |6 Makefile |2 arch/arc/kernel/entry.S|6 arch/arc/mm/tlb.c |3 arch/mips/math-emu/dp_fmax.c | 84 +-- arch/mips/math-emu/dp_fmin.c | 86 +-- arch/mips/math-emu/dp_maddf.c | 246 + arch/mips/math-emu/ieee754int.h|4 arch/mips/math-emu/ieee754sp.h |4 arch/mips/math-emu/sp_fmax.c | 84 +-- arch/mips/math-emu/sp_fmin.c | 86 +-- arch/mips/math-emu/sp_maddf.c | 229 +-- arch/powerpc/kernel/align.c| 119 ++ arch/powerpc/platforms/powernv/npu-dma.c | 12 - arch/powerpc/platforms/pseries/hotplug-memory.c|4 arch/s390/include/asm/mmu.h|2 arch/s390/include/asm/mmu_context.h|8 arch/s390/include/asm/tlbflush.h | 30 -- block/blk-core.c |9 block/blk-mq.c | 16 + block/blk-mq.h |1 crypto/algif_skcipher.c|4 crypto/scompress.c |4 drivers/block/skd_main.c | 21 + drivers/crypto/caam/caamalg_qi.c | 11 drivers/crypto/ccp/ccp-crypto-aes-xts.c|4 drivers/crypto/ccp/ccp-dev-v5.c|2 drivers/crypto/ccp/ccp-dev.h |2 drivers/crypto/ccp/ccp-ops.c | 43 ++- drivers/devfreq/devfreq.c |5 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c|3 drivers/gpu/drm/amd/amdgpu/psp_v3_1.c |2 drivers/infiniband/hw/hfi1/init.c |1 drivers/infiniband/hw/hfi1/rc.c|3 drivers/infiniband/hw/mlx5/mr.c| 18 + drivers/infiniband/hw/qib/qib_rc.c |4 drivers/input/joystick/xpad.c | 10 drivers/input/serio/i8042-x86ia64io.h |7 drivers/mailbox/bcm-flexrm-mailbox.c |2 drivers/md/bcache/bcache.h |1 drivers/md/bcache/request.c| 12 - drivers/md/bcache/super.c |7 drivers/md/bcache/sysfs.c |4 drivers/md/bcache/util.c | 50 ++-- drivers/md/bcache/writeback.c | 20 + drivers/md/bcache/writeback.h | 21 + drivers/md/bitmap.c|9 drivers/media/i2c/adv7180.c|2 drivers/media/platform/qcom/venus/helpers.c|2 drivers/media/rc/lirc_dev.c|4 drivers/media/usb/uvc/uvc_ctrl.c |7 drivers/media/v4l2-core/v4l2-compat-ioctl32.c |3 drivers/misc/cxl/api.c |4 drivers/misc/cxl/file.c|8 drivers/net/wireless/ath/wcn36xx/main.c| 52 drivers/net/wireless/ath/wcn36xx/wcn36xx.h |3 drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 62 - drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.h |3 drivers/net/wireless/intel/iwlwifi/mvm/nvm.c |3 drivers/pci/hotplug/pciehp_hpc.c |8 drivers/pci/hotplug/shpchp_hpc.c |2 drivers/pinctrl/pinctrl-amd.c | 75 ++ drivers/pinctrl/pinctrl-amd.h |1 drivers/pinctrl/samsung/pinctrl-exynos.c |8 drivers/pinctrl/samsung/pinctrl-s3c24xx.c | 37
Re: Linux 4.9.7
On Saturday, February 4, 2017 2:59:05 AM EST, Greg KH wrote: On Fri, Feb 03, 2017 at 11:07:08PM -0500, Ed Tomlinson wrote: Hi, Any reports of 4.9.7 breaking X? I run arch and keep it up to date. With todays updates and 4.9.7 built here X will not start kde correctly. Reverting to 4.9.6 fixes things. Config is the same for both builds. I have three btrfs patches and the BFQ 4.9.0-v8r7 ... There was a report of a PCI issue affecting 4.9.6, and the fix for that should be hitting Linus's tree soon (if it's not there already), but I haven't heard anything about problems with 4.9.7. Like the others said, if you could use 'git bisect' to track down the offending problem, that would be wonderful. Greg Looks like the original 4.9.7 build here must have failed in some wierd way. I've run the bisect twice and its good till the end. Sorry for the noise, Ed
Re: Linux 4.9.7
On Saturday, February 4, 2017 2:59:05 AM EST, Greg KH wrote: On Fri, Feb 03, 2017 at 11:07:08PM -0500, Ed Tomlinson wrote: Hi, Any reports of 4.9.7 breaking X? I run arch and keep it up to date. With todays updates and 4.9.7 built here X will not start kde correctly. Reverting to 4.9.6 fixes things. Config is the same for both builds. I have three btrfs patches and the BFQ 4.9.0-v8r7 ... There was a report of a PCI issue affecting 4.9.6, and the fix for that should be hitting Linus's tree soon (if it's not there already), but I haven't heard anything about problems with 4.9.7. Like the others said, if you could use 'git bisect' to track down the offending problem, that would be wonderful. Greg Looks like the original 4.9.7 build here must have failed in some wierd way. I've run the bisect twice and its good till the end. Sorry for the noise, Ed
Re: Linux 4.9.7
Hi,
Any reports of 4.9.7 breaking X?
I run arch and keep it up to date. With todays updates and 4.9.7 built
here X will not start kde correctly. Reverting to 4.9.6 fixes things.
Config is the same for both builds. I have three btrfs patches and the BFQ
4.9.0-v8r7 patchset applied on top of stable git's 4.9.{6|7}.
Suggestions on what to look for or to try reverting (via git)
xorg-server is 1.19.1-1
xf86-video-amdgpu 1.2.0-2
mesa is 13.0.4-1
kernel is x86_64
Thanks
Ed
On Thursday, February 2, 2017 5:10:47 AM EST, Greg KH wrote:
I'm announcing the release of the 4.9.7 kernel.
All users of the 4.9 kernel series must upgrade.
The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
Makefile |2
arch/arc/include/asm/delay.h |4
arch/arc/kernel/unaligned.c |3
arch/parisc/include/asm/bitops.h |8 +
arch/parisc/include/uapi/asm/bitsperlong.h |2
arch/parisc/include/uapi/asm/swab.h |5
arch/s390/kernel/ptrace.c|8 +
arch/s390/mm/pgtable.c |7 -
arch/tile/kernel/ptrace.c|2
arch/x86/platform/mellanox/mlx-platform.c|2
drivers/base/memory.c|4
drivers/gpu/drm/drm_atomic_helper.c |2
drivers/gpu/drm/drm_modes.c |7 +
drivers/gpu/drm/drm_probe_helper.c | 12 +-
drivers/gpu/drm/i915/i915_drv.c |2
drivers/gpu/drm/i915/i915_gem_evict.c|1
drivers/gpu/drm/i915/intel_crt.c |9 -
drivers/gpu/drm/i915/intel_display.c | 14 ++
drivers/gpu/drm/i915/intel_fbdev.c |3
drivers/gpu/drm/i915/intel_lrc.c |3
drivers/gpu/drm/i915/intel_ringbuffer.c |8 -
drivers/gpu/drm/radeon/radeon_drv.c |7 -
drivers/gpu/drm/vc4/vc4_crtc.c |2
drivers/gpu/drm/vc4/vc4_gem.c|4
drivers/gpu/drm/vc4/vc4_render_cl.c |2
drivers/infiniband/core/cma.c|3
drivers/infiniband/core/umem.c |2
drivers/infiniband/hw/cxgb4/device.c |9 +
drivers/infiniband/hw/cxgb4/iw_cxgb4.h | 18 +++
drivers/infiniband/hw/cxgb4/provider.c | 20 ++-
drivers/infiniband/hw/cxgb4/qp.c | 35 --
drivers/infiniband/sw/rxe/rxe_net.c |2
drivers/infiniband/sw/rxe/rxe_qp.c |3
drivers/infiniband/ulp/iser/iscsi_iser.c |7 -
drivers/infiniband/ulp/srp/ib_srp.c | 15 ++
drivers/isdn/hardware/eicon/message.c|3
drivers/media/i2c/Kconfig|1
drivers/media/i2c/tvp5150.c | 56 ++---
drivers/media/i2c/tvp5150_reg.h |9 +
drivers/media/usb/dvb-usb/pctv452e.c | 133
---
drivers/net/can/c_can/c_can_pci.c|1
drivers/net/can/ti_hecc.c| 16 ++
drivers/pinctrl/intel/pinctrl-baytrail.c | 28 ++--
drivers/pinctrl/intel/pinctrl-broxton.c |2
drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c |2
drivers/platform/x86/intel_mid_powerbtn.c|2
drivers/video/fbdev/core/fbcmap.c| 26 ++--
drivers/virtio/virtio_mmio.c | 20 +++
drivers/virtio/virtio_ring.c |7 +
fs/btrfs/inode.c |8 -
fs/nfs/nfs4proc.c|4
fs/xfs/xfs_qm.c |3
include/linux/memory_hotplug.h |4
include/linux/mmzone.h |6 -
include/linux/nfs4.h |3
include/linux/sunrpc/clnt.h |1
include/uapi/rdma/cxgb3-abi.h|2
kernel/events/core.c | 58 +-
kernel/sysctl.c |1
kernel/ucount.c | 14 +-
mm/huge_memory.c | 18 ++-
mm/memcontrol.c |4
mm/memory_hotplug.c | 28 ++--
mm/mempolicy.c |2
mm/page_alloc.c | 68 ---
net/sunrpc/clnt.c|5
net/sunrpc/sunrpc_syms.c |1
67 files changed, 534 insertions(+),
Re: Linux 4.9.7
Hi,
Any reports of 4.9.7 breaking X?
I run arch and keep it up to date. With todays updates and 4.9.7 built
here X will not start kde correctly. Reverting to 4.9.6 fixes things.
Config is the same for both builds. I have three btrfs patches and the BFQ
4.9.0-v8r7 patchset applied on top of stable git's 4.9.{6|7}.
Suggestions on what to look for or to try reverting (via git)
xorg-server is 1.19.1-1
xf86-video-amdgpu 1.2.0-2
mesa is 13.0.4-1
kernel is x86_64
Thanks
Ed
On Thursday, February 2, 2017 5:10:47 AM EST, Greg KH wrote:
I'm announcing the release of the 4.9.7 kernel.
All users of the 4.9 kernel series must upgrade.
The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
Makefile |2
arch/arc/include/asm/delay.h |4
arch/arc/kernel/unaligned.c |3
arch/parisc/include/asm/bitops.h |8 +
arch/parisc/include/uapi/asm/bitsperlong.h |2
arch/parisc/include/uapi/asm/swab.h |5
arch/s390/kernel/ptrace.c|8 +
arch/s390/mm/pgtable.c |7 -
arch/tile/kernel/ptrace.c|2
arch/x86/platform/mellanox/mlx-platform.c|2
drivers/base/memory.c|4
drivers/gpu/drm/drm_atomic_helper.c |2
drivers/gpu/drm/drm_modes.c |7 +
drivers/gpu/drm/drm_probe_helper.c | 12 +-
drivers/gpu/drm/i915/i915_drv.c |2
drivers/gpu/drm/i915/i915_gem_evict.c|1
drivers/gpu/drm/i915/intel_crt.c |9 -
drivers/gpu/drm/i915/intel_display.c | 14 ++
drivers/gpu/drm/i915/intel_fbdev.c |3
drivers/gpu/drm/i915/intel_lrc.c |3
drivers/gpu/drm/i915/intel_ringbuffer.c |8 -
drivers/gpu/drm/radeon/radeon_drv.c |7 -
drivers/gpu/drm/vc4/vc4_crtc.c |2
drivers/gpu/drm/vc4/vc4_gem.c|4
drivers/gpu/drm/vc4/vc4_render_cl.c |2
drivers/infiniband/core/cma.c|3
drivers/infiniband/core/umem.c |2
drivers/infiniband/hw/cxgb4/device.c |9 +
drivers/infiniband/hw/cxgb4/iw_cxgb4.h | 18 +++
drivers/infiniband/hw/cxgb4/provider.c | 20 ++-
drivers/infiniband/hw/cxgb4/qp.c | 35 --
drivers/infiniband/sw/rxe/rxe_net.c |2
drivers/infiniband/sw/rxe/rxe_qp.c |3
drivers/infiniband/ulp/iser/iscsi_iser.c |7 -
drivers/infiniband/ulp/srp/ib_srp.c | 15 ++
drivers/isdn/hardware/eicon/message.c|3
drivers/media/i2c/Kconfig|1
drivers/media/i2c/tvp5150.c | 56 ++---
drivers/media/i2c/tvp5150_reg.h |9 +
drivers/media/usb/dvb-usb/pctv452e.c | 133
---
drivers/net/can/c_can/c_can_pci.c|1
drivers/net/can/ti_hecc.c| 16 ++
drivers/pinctrl/intel/pinctrl-baytrail.c | 28 ++--
drivers/pinctrl/intel/pinctrl-broxton.c |2
drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c |2
drivers/platform/x86/intel_mid_powerbtn.c|2
drivers/video/fbdev/core/fbcmap.c| 26 ++--
drivers/virtio/virtio_mmio.c | 20 +++
drivers/virtio/virtio_ring.c |7 +
fs/btrfs/inode.c |8 -
fs/nfs/nfs4proc.c|4
fs/xfs/xfs_qm.c |3
include/linux/memory_hotplug.h |4
include/linux/mmzone.h |6 -
include/linux/nfs4.h |3
include/linux/sunrpc/clnt.h |1
include/uapi/rdma/cxgb3-abi.h|2
kernel/events/core.c | 58 +-
kernel/sysctl.c |1
kernel/ucount.c | 14 +-
mm/huge_memory.c | 18 ++-
mm/memcontrol.c |4
mm/memory_hotplug.c | 28 ++--
mm/mempolicy.c |2
mm/page_alloc.c | 68 ---
net/sunrpc/clnt.c|5
net/sunrpc/sunrpc_syms.c |1
67 files changed, 534 insertions(+),
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Kick out vga console
Hi Daniel,
The patch below also works. You can use my Tested By for it.
Thanks
Ed Tomlinson
PS. I _really_ need to get a serial console working on my i7 box.
On Monday 07 July 2014 14:26:54 Daniel Vetter wrote:
> On Mon, Jul 07, 2014 at 06:45:49AM -0400, Ed Tomlinson wrote:
> > Daniel,
> >
> > I am not quite sure I understand what you want me to test?
> > Do you want me to try it without:
> >
> > > > + if (ret == 0) {
> > > > + ret = do_unregister_con_driver(_con);
>
> Below the diff of what I mean.
> -Daniel
>
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 5e583a1838f8..bd8517151479 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1466,12 +1466,13 @@ static int i915_kick_out_vgacon(struct
> drm_i915_private *dev_priv)
> #else
> static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> {
> - int ret;
> + int ret = 0;
>
> DRM_INFO("Replacing VGA console driver\n");
>
> console_lock();
> - ret = do_take_over_console(_con, 0, MAX_NR_CONSOLES - 1, 1);
> + if (con_is_bound(_con))
> + ret = do_take_over_console(_con, 0, MAX_NR_CONSOLES - 1,
> 1);
> if (ret == 0) {
> ret = do_unregister_con_driver(_con);
>
>
--
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: [Intel-gfx] [PATCH 5/5] drm/i915: Kick out vga console
Daniel,
Just to be sure. The intel card here should not be claiming the real console.
It does
not have an output device and the bios set set so the radeon is the primary
device.
Ed
On Monday 07 July 2014 10:48:26 Daniel Vetter wrote:
> On Mon, Jun 30, 2014 at 07:59:55AM +0100, Chris Wilson wrote:
> > On Sat, Jun 28, 2014 at 11:55:19PM -0400, Ed Tomlinson wrote:
> > > On Saturday 28 June 2014 15:28:22 Ed Tomlinson wrote:
> > >
> > > Resend without html krud which causes list to bounce the message.
> > >
> > > > Hi
> > > >
> > > > This commit ( a4de05268e674e8ed31df6348269e22d6c6a1803 ) hangs my boot
> > > > with 3.16-git. Reverting it lets the boot proceed.
> > > >
> > > > I have an i7 with a built-in i915 and an pcie r7 260x. The R7 is the
> > > > primary console. The i915 is initialized
> > > > but does not have a physical display attached.
> > > >
> > > > With the patch applied the boot stops at the messages:
> > > >
> > > > [drm] Memory usable by graphics device = 2048M
> > > > [drm] Replacing VGA console driver
> >
> > The issue looks like that we are ripping out the radeon fb_con whilst it
> > is active and that upsets everyone. In which case, I think the
> > compromise is:
> >
> >
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index 5f44581..4915f1d 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -1439,18 +1439,20 @@ static int i915_kick_out_vgacon(struct
> > drm_i915_private *dev_priv)
> > #else
> > static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> > {
> > - int ret;
> > + int ret = 0;
> >
> > DRM_INFO("Replacing VGA console driver\n");
> >
> > console_lock();
> > - ret = do_take_over_console(_con, 0, MAX_NR_CONSOLES - 1, 1);
> > - if (ret == 0) {
> > - ret = do_unregister_con_driver(_con);
> > -
> > - /* Ignore "already unregistered". */
> > - if (ret == -ENODEV)
> > - ret = 0;
> > + if (con_is_bound(_con)) {
> > + ret = do_take_over_console(_con, 0, MAX_NR_CONSOLES -
> > 1, 1);
> > + if (ret == 0) {
> > + ret = do_unregister_con_driver(_con);
>
> Hm, we should only conditionalize the take_over_console - unregistering
> vga_con is kinda the point to make sure it's gone for real. Ed, can you
> please retest with the if (con_is_bound) check just for the
> do_take_over_console call?
>
> Still puzzled wtf is going on here since as David says this should be a
> no-op.
>
> Thanks, Daniel
> > +
> > + /* Ignore "already unregistered". */
> > + if (ret == -ENODEV)
> > + ret = 0;
> > + }
> > }
> > console_unlock();
> >
> > -Chris
> >
>
>
--
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: [Intel-gfx] [PATCH 5/5] drm/i915: Kick out vga console
Daniel,
I am not quite sure I understand what you want me to test?
Do you want me to try it without:
> > + if (ret == 0) {
> > + ret = do_unregister_con_driver(_con);
Thanks
Ed
On Monday 07 July 2014 10:48:26 Daniel Vetter wrote:
> On Mon, Jun 30, 2014 at 07:59:55AM +0100, Chris Wilson wrote:
> > On Sat, Jun 28, 2014 at 11:55:19PM -0400, Ed Tomlinson wrote:
> > > On Saturday 28 June 2014 15:28:22 Ed Tomlinson wrote:
> > >
> > > Resend without html krud which causes list to bounce the message.
> > >
> > > > Hi
> > > >
> > > > This commit ( a4de05268e674e8ed31df6348269e22d6c6a1803 ) hangs my boot
> > > > with 3.16-git. Reverting it lets the boot proceed.
> > > >
> > > > I have an i7 with a built-in i915 and an pcie r7 260x. The R7 is the
> > > > primary console. The i915 is initialized
> > > > but does not have a physical display attached.
> > > >
> > > > With the patch applied the boot stops at the messages:
> > > >
> > > > [drm] Memory usable by graphics device = 2048M
> > > > [drm] Replacing VGA console driver
> >
> > The issue looks like that we are ripping out the radeon fb_con whilst it
> > is active and that upsets everyone. In which case, I think the
> > compromise is:
> >
> >
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index 5f44581..4915f1d 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -1439,18 +1439,20 @@ static int i915_kick_out_vgacon(struct
> > drm_i915_private *dev_priv)
> > #else
> > static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> > {
> > - int ret;
> > + int ret = 0;
> >
> > DRM_INFO("Replacing VGA console driver\n");
> >
> > console_lock();
> > - ret = do_take_over_console(_con, 0, MAX_NR_CONSOLES - 1, 1);
> > - if (ret == 0) {
> > - ret = do_unregister_con_driver(_con);
> > -
> > - /* Ignore "already unregistered". */
> > - if (ret == -ENODEV)
> > - ret = 0;
> > + if (con_is_bound(_con)) {
> > + ret = do_take_over_console(_con, 0, MAX_NR_CONSOLES -
> > 1, 1);
> > + if (ret == 0) {
> > + ret = do_unregister_con_driver(_con);
>
> Hm, we should only conditionalize the take_over_console - unregistering
> vga_con is kinda the point to make sure it's gone for real. Ed, can you
> please retest with the if (con_is_bound) check just for the
> do_take_over_console call?
>
> Still puzzled wtf is going on here since as David says this should be a
> no-op.
>
> Thanks, Daniel
> > +
> > + /* Ignore "already unregistered". */
> > + if (ret == -ENODEV)
> > + ret = 0;
> > + }
> > }
> > console_unlock();
> >
> > -Chris
> >
>
>
--
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: [Intel-gfx] [PATCH 5/5] drm/i915: Kick out vga console
Daniel,
I am not quite sure I understand what you want me to test?
Do you want me to try it without:
+ if (ret == 0) {
+ ret = do_unregister_con_driver(vga_con);
Thanks
Ed
On Monday 07 July 2014 10:48:26 Daniel Vetter wrote:
On Mon, Jun 30, 2014 at 07:59:55AM +0100, Chris Wilson wrote:
On Sat, Jun 28, 2014 at 11:55:19PM -0400, Ed Tomlinson wrote:
On Saturday 28 June 2014 15:28:22 Ed Tomlinson wrote:
Resend without html krud which causes list to bounce the message.
Hi
This commit ( a4de05268e674e8ed31df6348269e22d6c6a1803 ) hangs my boot
with 3.16-git. Reverting it lets the boot proceed.
I have an i7 with a built-in i915 and an pcie r7 260x. The R7 is the
primary console. The i915 is initialized
but does not have a physical display attached.
With the patch applied the boot stops at the messages:
[drm] Memory usable by graphics device = 2048M
[drm] Replacing VGA console driver
The issue looks like that we are ripping out the radeon fb_con whilst it
is active and that upsets everyone. In which case, I think the
compromise is:
diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c
index 5f44581..4915f1d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1439,18 +1439,20 @@ static int i915_kick_out_vgacon(struct
drm_i915_private *dev_priv)
#else
static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
{
- int ret;
+ int ret = 0;
DRM_INFO(Replacing VGA console driver\n);
console_lock();
- ret = do_take_over_console(dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
- if (ret == 0) {
- ret = do_unregister_con_driver(vga_con);
-
- /* Ignore already unregistered. */
- if (ret == -ENODEV)
- ret = 0;
+ if (con_is_bound(vga_con)) {
+ ret = do_take_over_console(dummy_con, 0, MAX_NR_CONSOLES -
1, 1);
+ if (ret == 0) {
+ ret = do_unregister_con_driver(vga_con);
Hm, we should only conditionalize the take_over_console - unregistering
vga_con is kinda the point to make sure it's gone for real. Ed, can you
please retest with the if (con_is_bound) check just for the
do_take_over_console call?
Still puzzled wtf is going on here since as David says this should be a
no-op.
Thanks, Daniel
+
+ /* Ignore already unregistered. */
+ if (ret == -ENODEV)
+ ret = 0;
+ }
}
console_unlock();
-Chris
--
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: [Intel-gfx] [PATCH 5/5] drm/i915: Kick out vga console
Daniel,
Just to be sure. The intel card here should not be claiming the real console.
It does
not have an output device and the bios set set so the radeon is the primary
device.
Ed
On Monday 07 July 2014 10:48:26 Daniel Vetter wrote:
On Mon, Jun 30, 2014 at 07:59:55AM +0100, Chris Wilson wrote:
On Sat, Jun 28, 2014 at 11:55:19PM -0400, Ed Tomlinson wrote:
On Saturday 28 June 2014 15:28:22 Ed Tomlinson wrote:
Resend without html krud which causes list to bounce the message.
Hi
This commit ( a4de05268e674e8ed31df6348269e22d6c6a1803 ) hangs my boot
with 3.16-git. Reverting it lets the boot proceed.
I have an i7 with a built-in i915 and an pcie r7 260x. The R7 is the
primary console. The i915 is initialized
but does not have a physical display attached.
With the patch applied the boot stops at the messages:
[drm] Memory usable by graphics device = 2048M
[drm] Replacing VGA console driver
The issue looks like that we are ripping out the radeon fb_con whilst it
is active and that upsets everyone. In which case, I think the
compromise is:
diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c
index 5f44581..4915f1d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1439,18 +1439,20 @@ static int i915_kick_out_vgacon(struct
drm_i915_private *dev_priv)
#else
static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
{
- int ret;
+ int ret = 0;
DRM_INFO(Replacing VGA console driver\n);
console_lock();
- ret = do_take_over_console(dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
- if (ret == 0) {
- ret = do_unregister_con_driver(vga_con);
-
- /* Ignore already unregistered. */
- if (ret == -ENODEV)
- ret = 0;
+ if (con_is_bound(vga_con)) {
+ ret = do_take_over_console(dummy_con, 0, MAX_NR_CONSOLES -
1, 1);
+ if (ret == 0) {
+ ret = do_unregister_con_driver(vga_con);
Hm, we should only conditionalize the take_over_console - unregistering
vga_con is kinda the point to make sure it's gone for real. Ed, can you
please retest with the if (con_is_bound) check just for the
do_take_over_console call?
Still puzzled wtf is going on here since as David says this should be a
no-op.
Thanks, Daniel
+
+ /* Ignore already unregistered. */
+ if (ret == -ENODEV)
+ ret = 0;
+ }
}
console_unlock();
-Chris
--
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: [Intel-gfx] [PATCH 5/5] drm/i915: Kick out vga console
Hi Daniel,
The patch below also works. You can use my Tested By for it.
Thanks
Ed Tomlinson edt...@gmail.com
PS. I _really_ need to get a serial console working on my i7 box.
On Monday 07 July 2014 14:26:54 Daniel Vetter wrote:
On Mon, Jul 07, 2014 at 06:45:49AM -0400, Ed Tomlinson wrote:
Daniel,
I am not quite sure I understand what you want me to test?
Do you want me to try it without:
+ if (ret == 0) {
+ ret = do_unregister_con_driver(vga_con);
Below the diff of what I mean.
-Daniel
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5e583a1838f8..bd8517151479 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1466,12 +1466,13 @@ static int i915_kick_out_vgacon(struct
drm_i915_private *dev_priv)
#else
static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
{
- int ret;
+ int ret = 0;
DRM_INFO(Replacing VGA console driver\n);
console_lock();
- ret = do_take_over_console(dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
+ if (con_is_bound(vga_con))
+ ret = do_take_over_console(dummy_con, 0, MAX_NR_CONSOLES - 1,
1);
if (ret == 0) {
ret = do_unregister_con_driver(vga_con);
--
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: [git pull] drm fixes
Hi Dave, This is NOT fixing problems with a stalled boot due to VGA problems as reported in thread: [PATCH 5/5] drm/i915: Kick out vga console It can be fixed by reverting: a4de05268e674e8ed31df6348269e22d6c6a1803 or applying the patch from Chris Wilson which can be found as a reply to my report. Thanks Ed Tomlinson On Saturday 05 July 2014 23:13:27 Dave Airlie wrote: > > Hi Linus, > > i915, tda998x and vmwgfx fixes, the main one is i915 fix for missing VGA > connectors, along with some fixes for the tda998x from Russell fixing some > modesetting problems > > (still on holidays, but got a spare moment to find these). > > Dave. > > The following changes since commit e1a08b855f56d6528e7f85aae9ca8123f4c3ae04: > > Merge tag 'arm64-fixes' of > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux (2014-07-05 > 10:12:52 -0700) > > are available in the git repository at: > > > git://people.freedesktop.org/~airlied/linux drm-fixes > > for you to fetch changes up to dfd7aecfd6d227831d77719379d4c7137f444fee: > > Merge tag 'drm-intel-fixes-2014-07-03' of > git://anongit.freedesktop.org/drm-intel (2014-07-06 07:49:59 +1000) > > > > Dave Airlie (3): > Merge branch 'tda998x-fixes' of > git://ftp.arm.linux.org.uk/~rmk/linux-cubox > Merge branch 'vmwgfx-fixes-3.16' of > git://people.freedesktop.org/~thomash/linux > Merge tag 'drm-intel-fixes-2014-07-03' of > git://anongit.freedesktop.org/drm-intel > > Deepak S (1): > drm/i915: Drop early VLV WA to fix Voltage not getting dropped to Vmin > > Guido Martínez (1): > drm/i2c: tda998x: move drm_i2c_encoder_destroy call > > Jesse Barnes (1): > drm/i915: only apply crt_present check on VLV > > Russell King (2): > drm/i2c: tda998x: faster polling for edid > drm/i2c: tda998x: add some basic mode validation > > Thomas Hellstrom (1): > drm/vmwgfx: Fix incorrect write to read-only register v2: > > Ville Syrjälä (1): > drm/i915: Wait for vblank after enabling the primary plane on BDW > > drivers/gpu/drm/i2c/tda998x_drv.c| 12 +--- > drivers/gpu/drm/i915/intel_display.c | 27 ++- > drivers/gpu/drm/i915/intel_pm.c | 8 > drivers/gpu/drm/i915/intel_sprite.c | 8 > drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 1 - > 5 files changed, 51 insertions(+), 5 deletions(-) -- 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: [USB spamming log] with 3.16-rc (git) my pl2303 is spaming my logs
Hi, The kernel in question is running on a i7 with a pi connected via to the i6 via the pl2303 to view the pi's console. The kernel on the i7 is at level: commit 77c4cf17ae867ba93233b3832bda3de7adaae326 Merge: 88b5a85 133d452 Author: Linus Torvalds Date: Fri Jul 4 09:37:43 2014 -0700 There is one extra patch applied to fix a problem with the boot stalling see the patch from Chris Wilson in the thread: [PATCH 5/5] drm/i915: Kick out vga console Here is a lsusb -v Bus 001 Device 011: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x067b Prolific Technology, Inc. idProduct 0x2303 PL2303 Serial Port bcdDevice3.00 iManufacturer 1 Prolific Technology Inc. iProduct2 USB-Serial Controller iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x (Bus Powered) Thanks Ed On Saturday 05 July 2014 11:02:06 Greg KH wrote: > On Sat, Jul 05, 2014 at 10:55:57AM -0400, Ed Tomlinson wrote: > > Hi > > > > I have a raspberry PI sending its console to my box via a pl2303 > > What exact pl2303 is this? Can you provide the output from 'lsusb'? > > > [5.184385] usbserial: USB Serial support registered for pl2303 > > [5.184398] pl2303 1-2.6:1.0: pl2303 converter detected > > [5.185353] usb 1-2.6: pl2303 converter now attached to ttyUSB0 > > > > and with the latest fixes from git on 3.16 its now started spamming my logs > > with: > > > > [55507.155354] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > > nonzero urb status: -71 > > [55510.736558] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > > nonzero urb status: -71 > > [55517.238586] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > > nonzero urb status: -71 > > [55521.099938] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > > nonzero urb status: -71 > > [55521.778520] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > > nonzero urb status: -71 > > [55523.229808] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > > nonzero urb status: -71 > > [55523.229846] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > > nonzero urb status: -71 > > [55525.074519] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > > nonzero urb status: -71 > > [55527.270207] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > > nonzero urb status: -71 > > That's saying there was one of the following errors in this device: > a) bitstuff error > b) no response packet received within the prescribed bus turn-around > time > c) unknown USB error > > All of which point to either a problem in the USB host controller, or > the usb device itself. > > Is this an "unpatched" 3.16-rc kernel running on t
[USB spamming log] with 3.16-rc (git) my pl2303 is spaming my logs
Hi I have a raspberry PI sending its console to my box via a pl2303 [5.184385] usbserial: USB Serial support registered for pl2303 [5.184398] pl2303 1-2.6:1.0: pl2303 converter detected [5.185353] usb 1-2.6: pl2303 converter now attached to ttyUSB0 and with the latest fixes from git on 3.16 its now started spamming my logs with: [55507.155354] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55510.736558] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55517.238586] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55521.099938] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55521.778520] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55523.229808] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55523.229846] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55525.074519] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55527.270207] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 Please fix. Thanks Ed Tomlinson -- 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/
[USB spamming log] with 3.16-rc (git) my pl2303 is spaming my logs
Hi I have a raspberry PI sending its console to my box via a pl2303 [5.184385] usbserial: USB Serial support registered for pl2303 [5.184398] pl2303 1-2.6:1.0: pl2303 converter detected [5.185353] usb 1-2.6: pl2303 converter now attached to ttyUSB0 and with the latest fixes from git on 3.16 its now started spamming my logs with: [55507.155354] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55510.736558] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55517.238586] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55521.099938] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55521.778520] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55523.229808] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55523.229846] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55525.074519] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55527.270207] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 Please fix. Thanks Ed Tomlinson -- 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: [USB spamming log] with 3.16-rc (git) my pl2303 is spaming my logs
Hi, The kernel in question is running on a i7 with a pi connected via to the i6 via the pl2303 to view the pi's console. The kernel on the i7 is at level: commit 77c4cf17ae867ba93233b3832bda3de7adaae326 Merge: 88b5a85 133d452 Author: Linus Torvalds torva...@linux-foundation.org Date: Fri Jul 4 09:37:43 2014 -0700 There is one extra patch applied to fix a problem with the boot stalling see the patch from Chris Wilson in the thread: [PATCH 5/5] drm/i915: Kick out vga console Here is a lsusb -v Bus 001 Device 011: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x067b Prolific Technology, Inc. idProduct 0x2303 PL2303 Serial Port bcdDevice3.00 iManufacturer 1 Prolific Technology Inc. iProduct2 USB-Serial Controller iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x (Bus Powered) Thanks Ed On Saturday 05 July 2014 11:02:06 Greg KH wrote: On Sat, Jul 05, 2014 at 10:55:57AM -0400, Ed Tomlinson wrote: Hi I have a raspberry PI sending its console to my box via a pl2303 What exact pl2303 is this? Can you provide the output from 'lsusb'? [5.184385] usbserial: USB Serial support registered for pl2303 [5.184398] pl2303 1-2.6:1.0: pl2303 converter detected [5.185353] usb 1-2.6: pl2303 converter now attached to ttyUSB0 and with the latest fixes from git on 3.16 its now started spamming my logs with: [55507.155354] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55510.736558] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55517.238586] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55521.099938] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55521.778520] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55523.229808] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55523.229846] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55525.074519] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 [55527.270207] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 That's saying there was one of the following errors in this device: a) bitstuff error b) no response packet received within the prescribed bus turn-around time c) unknown USB error All of which point to either a problem in the USB host controller, or the usb device itself. Is this an unpatched 3.16-rc kernel running on the rpi? If so, odds are it's a host controller issue... thanks, greg k-h -- 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
Re: [git pull] drm fixes
Hi Dave, This is NOT fixing problems with a stalled boot due to VGA problems as reported in thread: [PATCH 5/5] drm/i915: Kick out vga console It can be fixed by reverting: a4de05268e674e8ed31df6348269e22d6c6a1803 or applying the patch from Chris Wilson which can be found as a reply to my report. Thanks Ed Tomlinson On Saturday 05 July 2014 23:13:27 Dave Airlie wrote: Hi Linus, i915, tda998x and vmwgfx fixes, the main one is i915 fix for missing VGA connectors, along with some fixes for the tda998x from Russell fixing some modesetting problems (still on holidays, but got a spare moment to find these). Dave. The following changes since commit e1a08b855f56d6528e7f85aae9ca8123f4c3ae04: Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux (2014-07-05 10:12:52 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to dfd7aecfd6d227831d77719379d4c7137f444fee: Merge tag 'drm-intel-fixes-2014-07-03' of git://anongit.freedesktop.org/drm-intel (2014-07-06 07:49:59 +1000) Dave Airlie (3): Merge branch 'tda998x-fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox Merge branch 'vmwgfx-fixes-3.16' of git://people.freedesktop.org/~thomash/linux Merge tag 'drm-intel-fixes-2014-07-03' of git://anongit.freedesktop.org/drm-intel Deepak S (1): drm/i915: Drop early VLV WA to fix Voltage not getting dropped to Vmin Guido Martínez (1): drm/i2c: tda998x: move drm_i2c_encoder_destroy call Jesse Barnes (1): drm/i915: only apply crt_present check on VLV Russell King (2): drm/i2c: tda998x: faster polling for edid drm/i2c: tda998x: add some basic mode validation Thomas Hellstrom (1): drm/vmwgfx: Fix incorrect write to read-only register v2: Ville Syrjälä (1): drm/i915: Wait for vblank after enabling the primary plane on BDW drivers/gpu/drm/i2c/tda998x_drv.c| 12 +--- drivers/gpu/drm/i915/intel_display.c | 27 ++- drivers/gpu/drm/i915/intel_pm.c | 8 drivers/gpu/drm/i915/intel_sprite.c | 8 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 1 - 5 files changed, 51 insertions(+), 5 deletions(-) -- 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: [PATCH 5/5] drm/i915: Kick out vga console
Hi Chris,
I had to rediff to get a patch that applies... I am not hanging with this
applied - it
does look like the i915 is starting is initialization later boot the new kernel.
[2.389796] [drm] Radeon Display Connectors
[2.389798] [drm] Connector 0:
[2.389799] [drm] DP-1
[2.389799] [drm] HPD2
[2.389801] [drm] DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c
0x653c
[2.389802] [drm] Encoders:
[2.389803] [drm] DFP1: INTERNAL_UNIPHY2
[2.389804] [drm] Connector 1:
[2.389805] [drm] HDMI-A-1
[2.389805] [drm] HPD3
[2.389806] [drm] DDC: 0x6550 0x6550 0x6554 0x6554 0x6558 0x6558 0x655c
0x655c
[2.389807] [drm] Encoders:
[2.389808] [drm] DFP2: INTERNAL_UNIPHY2
[2.389809] [drm] Connector 2:
[2.389810] [drm] DVI-D-1
[2.389811] [drm] HPD1
[2.389812] [drm] DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 0x656c
0x656c
[2.389813] [drm] Encoders:
[2.389814] [drm] DFP3: INTERNAL_UNIPHY1
[2.389815] [drm] Connector 3:
[2.389815] [drm] DVI-I-1
[2.389816] [drm] HPD6
[2.389817] [drm] DDC: 0x6580 0x6580 0x6584 0x6584 0x6588 0x6588 0x658c
0x658c
[2.389818] [drm] Encoders:
[2.389819] [drm] DFP4: INTERNAL_UNIPHY
[2.389820] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[2.435689] raid6: avx2x2 24564 MB/s
[2.435691] Switched to clocksource tsc
[2.489087] usb 1-8: new low-speed USB device number 7 using xhci_hcd
[2.492403] raid6: avx2x4 34887 MB/s
[2.492404] raid6: using algorithm avx2x4 (34887 MB/s)
[2.492405] raid6: using avx2x2 recovery algorithm
[2.492789] xor: automatically using best checksumming function:
[2.502557] Adding 5779452k swap on /dev/sdb2. Priority:-2 extents:1
across:5779452k FS
[2.511532] [drm] fb mappable at 0xE098E000
[2.511536] [drm] vram apper at 0xE000
[2.511538] [drm] size 9216000
[2.511539] [drm] fb depth is 24
[2.511541] [drm]pitch is 7680
[2.511590] fbcon: radeondrmfb (fb0) is primary device
[2.516691] nct6775: Found NCT6776D/F or compatible chip at 0x2e:0x290
[2.525778]avx : 41474.400 MB/sec
[2.532408] Console: switching to colour frame buffer device 240x75
[2.535567] radeon :01:00.0: fb0: radeondrmfb frame buffer device
[2.535567] radeon :01:00.0: registered panic notifier
[2.544968] Btrfs loaded
[2.545276] BTRFS: device fsid 9d4254aa-6715-4fa8-986a-1af0d51768ad devid 1
transid 308068 /dev/sdc1
[2.545739] BTRFS: device fsid 9d4254aa-6715-4fa8-986a-1af0d51768ad devid 2
transid 308068 /dev/sdb1
[2.552946] [drm] Initialized radeon 2.39.0 20080528 for :01:00.0 on
minor 0
[2.553248] [drm] Memory usable by graphics device = 2048M
[2.553273] [drm] Replacing VGA console driver
[2.572539] i915 :00:02.0: irq 46 for MSI/MSI-X
[2.572546] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[2.572565] [drm] Driver supports precise vblank timestamp query.
If you are happy with this you can give this patch my tested by.
Thanks
Ed Tomlinson
On Monday 30 June 2014 07:59:55 Chris Wilson wrote:
> On Sat, Jun 28, 2014 at 11:55:19PM -0400, Ed Tomlinson wrote:
> > On Saturday 28 June 2014 15:28:22 Ed Tomlinson wrote:
> >
> > Resend without html krud which causes list to bounce the message.
> >
> > > Hi
> > >
> > > This commit ( a4de05268e674e8ed31df6348269e22d6c6a1803 ) hangs my boot
> > > with 3.16-git. Reverting it lets the boot proceed.
> > >
> > > I have an i7 with a built-in i915 and an pcie r7 260x. The R7 is the
> > > primary console. The i915 is initialized
> > > but does not have a physical display attached.
> > >
> > > With the patch applied the boot stops at the messages:
> > >
> > > [drm] Memory usable by graphics device = 2048M
> > > [drm] Replacing VGA console driver
>
> The issue looks like that we are ripping out the radeon fb_con whilst it
> is active and that upsets everyone. In which case, I think the
> compromise is:
>
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 5f44581..4915f1d 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1439,18 +1439,20 @@ static int i915_kick_out_vgacon(struct
> drm_i915_private *dev_priv)
> #else
> static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> {
> - int ret;
> + int ret = 0;
>
> DRM_INFO("Replacing VGA console driver\n");
>
> console_lock();
> - ret = do_take_over_console(_con, 0, MAX_NR_CONSOLES - 1, 1);
> - if (ret == 0) {
> - ret = do_unregister_con_driver(_con);
> -
> - /* Ignore "already unregistered". */
> -
Re: [PATCH 5/5] drm/i915: Kick out vga console
Hi Chris,
I had to rediff to get a patch that applies... I am not hanging with this
applied - it
does look like the i915 is starting is initialization later boot the new kernel.
[2.389796] [drm] Radeon Display Connectors
[2.389798] [drm] Connector 0:
[2.389799] [drm] DP-1
[2.389799] [drm] HPD2
[2.389801] [drm] DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c
0x653c
[2.389802] [drm] Encoders:
[2.389803] [drm] DFP1: INTERNAL_UNIPHY2
[2.389804] [drm] Connector 1:
[2.389805] [drm] HDMI-A-1
[2.389805] [drm] HPD3
[2.389806] [drm] DDC: 0x6550 0x6550 0x6554 0x6554 0x6558 0x6558 0x655c
0x655c
[2.389807] [drm] Encoders:
[2.389808] [drm] DFP2: INTERNAL_UNIPHY2
[2.389809] [drm] Connector 2:
[2.389810] [drm] DVI-D-1
[2.389811] [drm] HPD1
[2.389812] [drm] DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 0x656c
0x656c
[2.389813] [drm] Encoders:
[2.389814] [drm] DFP3: INTERNAL_UNIPHY1
[2.389815] [drm] Connector 3:
[2.389815] [drm] DVI-I-1
[2.389816] [drm] HPD6
[2.389817] [drm] DDC: 0x6580 0x6580 0x6584 0x6584 0x6588 0x6588 0x658c
0x658c
[2.389818] [drm] Encoders:
[2.389819] [drm] DFP4: INTERNAL_UNIPHY
[2.389820] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[2.435689] raid6: avx2x2 24564 MB/s
[2.435691] Switched to clocksource tsc
[2.489087] usb 1-8: new low-speed USB device number 7 using xhci_hcd
[2.492403] raid6: avx2x4 34887 MB/s
[2.492404] raid6: using algorithm avx2x4 (34887 MB/s)
[2.492405] raid6: using avx2x2 recovery algorithm
[2.492789] xor: automatically using best checksumming function:
[2.502557] Adding 5779452k swap on /dev/sdb2. Priority:-2 extents:1
across:5779452k FS
[2.511532] [drm] fb mappable at 0xE098E000
[2.511536] [drm] vram apper at 0xE000
[2.511538] [drm] size 9216000
[2.511539] [drm] fb depth is 24
[2.511541] [drm]pitch is 7680
[2.511590] fbcon: radeondrmfb (fb0) is primary device
[2.516691] nct6775: Found NCT6776D/F or compatible chip at 0x2e:0x290
[2.525778]avx : 41474.400 MB/sec
[2.532408] Console: switching to colour frame buffer device 240x75
[2.535567] radeon :01:00.0: fb0: radeondrmfb frame buffer device
[2.535567] radeon :01:00.0: registered panic notifier
[2.544968] Btrfs loaded
[2.545276] BTRFS: device fsid 9d4254aa-6715-4fa8-986a-1af0d51768ad devid 1
transid 308068 /dev/sdc1
[2.545739] BTRFS: device fsid 9d4254aa-6715-4fa8-986a-1af0d51768ad devid 2
transid 308068 /dev/sdb1
[2.552946] [drm] Initialized radeon 2.39.0 20080528 for :01:00.0 on
minor 0
[2.553248] [drm] Memory usable by graphics device = 2048M
[2.553273] [drm] Replacing VGA console driver
[2.572539] i915 :00:02.0: irq 46 for MSI/MSI-X
[2.572546] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[2.572565] [drm] Driver supports precise vblank timestamp query.
If you are happy with this you can give this patch my tested by.
Thanks
Ed Tomlinson
On Monday 30 June 2014 07:59:55 Chris Wilson wrote:
On Sat, Jun 28, 2014 at 11:55:19PM -0400, Ed Tomlinson wrote:
On Saturday 28 June 2014 15:28:22 Ed Tomlinson wrote:
Resend without html krud which causes list to bounce the message.
Hi
This commit ( a4de05268e674e8ed31df6348269e22d6c6a1803 ) hangs my boot
with 3.16-git. Reverting it lets the boot proceed.
I have an i7 with a built-in i915 and an pcie r7 260x. The R7 is the
primary console. The i915 is initialized
but does not have a physical display attached.
With the patch applied the boot stops at the messages:
[drm] Memory usable by graphics device = 2048M
[drm] Replacing VGA console driver
The issue looks like that we are ripping out the radeon fb_con whilst it
is active and that upsets everyone. In which case, I think the
compromise is:
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5f44581..4915f1d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1439,18 +1439,20 @@ static int i915_kick_out_vgacon(struct
drm_i915_private *dev_priv)
#else
static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
{
- int ret;
+ int ret = 0;
DRM_INFO(Replacing VGA console driver\n);
console_lock();
- ret = do_take_over_console(dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
- if (ret == 0) {
- ret = do_unregister_con_driver(vga_con);
-
- /* Ignore already unregistered. */
- if (ret == -ENODEV)
- ret = 0;
+ if (con_is_bound(vga_con)) {
+ ret = do_take_over_console(dummy_con, 0, MAX_NR_CONSOLES -
1, 1);
+ if (ret == 0) {
+ ret = do_unregister_con_driver(vga_con);
+
+ /* Ignore
Re: [PATCH 5/5] drm/i915: Kick out vga console
On Saturday 28 June 2014 15:28:22 Ed Tomlinson wrote: Resend without html krud which causes list to bounce the message. > Hi > > This commit ( a4de05268e674e8ed31df6348269e22d6c6a1803 ) hangs my boot with > 3.16-git. Reverting it lets the boot proceed. > > I have an i7 with a built-in i915 and an pcie r7 260x. The R7 is the primary > console. The i915 is initialized > but does not have a physical display attached. > > With the patch applied the boot stops at the messages: > > [drm] Memory usable by graphics device = 2048M > [drm] Replacing VGA console driver > > and I need to interrupt or power off the box to get it back. > > (I did not notice messages about the R7 but they could have easily been > missed - this box does not have a serial console) > > Without the patch I get: > > Jun 28 14:53:54 localhost kernel: [2.075351] e1000e: Intel(R) PRO/1000 > Network Driver - 2.3.2-k > Jun 28 14:53:54 localhost kernel: [2.075796] [drm] Initialized drm 1.1.0 > 20060810 > Jun 28 14:53:54 localhost kernel: [2.075958] microcode: CPU0 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077289] microcode: CPU1 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077299] microcode: CPU2 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077307] microcode: CPU3 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077315] microcode: CPU4 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077325] microcode: CPU5 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077335] microcode: CPU6 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077342] microcode: CPU7 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077378] microcode: Microcode Update > Driver: v2.00 , Peter Oruba > Jun 28 14:53:54 localhost kernel: [2.079726] input: PC Speaker as > /devices/platform/pcspkr/input/input4 > Jun 28 14:53:54 localhost kernel: [2.083930] e1000e: Copyright(c) 1999 - > 2014 Intel Corporation. > Jun 28 14:53:54 localhost kernel: [2.084787] ACPI Warning: SystemIO range > 0xf040-0xf05f conflicts with OpRegion > 0xf040-0xf04f (\_SB_.PCI0.SBUS.SMBI) > (20140424/utaddress-258) > Jun 28 14:53:54 localhost kernel: [2.084788] ACPI: If an ACPI driver is > available for this device, you should use it instead of the native driver > Jun 28 14:53:54 localhost kernel: [2.084894] e1000e :00:19.0: > Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode > Jun 28 14:53:54 localhost kernel: [2.084905] e1000e :00:19.0: irq 44 > for MSI/MSI-X > Jun 28 14:53:54 localhost kernel: [2.096721] iTCO_vendor_support: > vendor-support=0 > Jun 28 14:53:54 localhost kernel: [2.096780] AVX2 version of gcm_enc/dec > engaged. > Jun 28 14:53:54 localhost kernel: [2.098512] iTCO_wdt: Intel TCO WatchDog > Timer Driver v1.11 > Jun 28 14:53:54 localhost kernel: [2.099042] iTCO_wdt: Found a Lynx Point > TCO device (Version=2, TCOBASE=0x1860) > Jun 28 14:53:54 localhost kernel: [2.099561] iTCO_wdt: initialized. > heartbeat=30 sec (nowayout=0) > Jun 28 14:53:54 localhost kernel: [2.100401] [drm] radeon kernel > modesetting enabled. > Jun 28 14:53:54 localhost kernel: [2.100918] checking generic (e000 > 30) vs hw (e000 1000) > Jun 28 14:53:54 localhost kernel: [2.100919] fb: switching to radeondrmfb > from simple > Jun 28 14:53:54 localhost kernel: [2.101372] Console: switching to colour > dummy device 80x25 > Jun 28 14:53:54 localhost kernel: [2.101527] [drm] initializing kernel > modesetting (BONAIRE 0x1002:0x6658 0x174B:0xE253). > Jun 28 14:53:54 localhost kernel: [2.101534] [drm] register mmio base: > 0xF080 > Jun 28 14:53:54 localhost kernel: [2.101535] [drm] register mmio size: > 262144 > Jun 28 14:53:54 localhost kernel: [2.101540] [drm] doorbell mmio base: > 0xF000 > Jun 28 14:53:54 localhost kernel: [2.101541] [drm] doorbell mmio size: > 8388608 > Jun 28 14:53:54 localhost kernel: [2.101579] ATOM BIOS: Bonaire > Jun 28 14:53:54 localhost kernel: [2.101627] radeon :01:00.0: VRAM: > 2048M 0x - 0x7FFF (2048M used) > Jun 28 14:53:54 localhost kernel: [2.101629] radeon :01:00.0: GTT: > 1024M 0x8000 - 0xBFFF > Jun 28 14:53:54 localhost kernel: [2.101630] [drm] Detected VRAM > RAM=2048M, BAR=256M > Jun 28 14:53:54 localhost kernel: [2.101631] [drm] RAM width 128bits
Re: [PATCH 5/5] drm/i915: Kick out vga console
On Saturday 28 June 2014 15:28:22 Ed Tomlinson wrote: Resend without html krud which causes list to bounce the message. Hi This commit ( a4de05268e674e8ed31df6348269e22d6c6a1803 ) hangs my boot with 3.16-git. Reverting it lets the boot proceed. I have an i7 with a built-in i915 and an pcie r7 260x. The R7 is the primary console. The i915 is initialized but does not have a physical display attached. With the patch applied the boot stops at the messages: [drm] Memory usable by graphics device = 2048M [drm] Replacing VGA console driver and I need to interrupt or power off the box to get it back. (I did not notice messages about the R7 but they could have easily been missed - this box does not have a serial console) Without the patch I get: Jun 28 14:53:54 localhost kernel: [2.075351] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k Jun 28 14:53:54 localhost kernel: [2.075796] [drm] Initialized drm 1.1.0 20060810 Jun 28 14:53:54 localhost kernel: [2.075958] microcode: CPU0 sig=0x306c3, pf=0x2, revision=0x17 Jun 28 14:53:54 localhost kernel: [2.077289] microcode: CPU1 sig=0x306c3, pf=0x2, revision=0x17 Jun 28 14:53:54 localhost kernel: [2.077299] microcode: CPU2 sig=0x306c3, pf=0x2, revision=0x17 Jun 28 14:53:54 localhost kernel: [2.077307] microcode: CPU3 sig=0x306c3, pf=0x2, revision=0x17 Jun 28 14:53:54 localhost kernel: [2.077315] microcode: CPU4 sig=0x306c3, pf=0x2, revision=0x17 Jun 28 14:53:54 localhost kernel: [2.077325] microcode: CPU5 sig=0x306c3, pf=0x2, revision=0x17 Jun 28 14:53:54 localhost kernel: [2.077335] microcode: CPU6 sig=0x306c3, pf=0x2, revision=0x17 Jun 28 14:53:54 localhost kernel: [2.077342] microcode: CPU7 sig=0x306c3, pf=0x2, revision=0x17 Jun 28 14:53:54 localhost kernel: [2.077378] microcode: Microcode Update Driver: v2.00 tig...@aivazian.fsnet.co.uk, Peter Oruba Jun 28 14:53:54 localhost kernel: [2.079726] input: PC Speaker as /devices/platform/pcspkr/input/input4 Jun 28 14:53:54 localhost kernel: [2.083930] e1000e: Copyright(c) 1999 - 2014 Intel Corporation. Jun 28 14:53:54 localhost kernel: [2.084787] ACPI Warning: SystemIO range 0xf040-0xf05f conflicts with OpRegion 0xf040-0xf04f (\_SB_.PCI0.SBUS.SMBI) (20140424/utaddress-258) Jun 28 14:53:54 localhost kernel: [2.084788] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver Jun 28 14:53:54 localhost kernel: [2.084894] e1000e :00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode Jun 28 14:53:54 localhost kernel: [2.084905] e1000e :00:19.0: irq 44 for MSI/MSI-X Jun 28 14:53:54 localhost kernel: [2.096721] iTCO_vendor_support: vendor-support=0 Jun 28 14:53:54 localhost kernel: [2.096780] AVX2 version of gcm_enc/dec engaged. Jun 28 14:53:54 localhost kernel: [2.098512] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 Jun 28 14:53:54 localhost kernel: [2.099042] iTCO_wdt: Found a Lynx Point TCO device (Version=2, TCOBASE=0x1860) Jun 28 14:53:54 localhost kernel: [2.099561] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) Jun 28 14:53:54 localhost kernel: [2.100401] [drm] radeon kernel modesetting enabled. Jun 28 14:53:54 localhost kernel: [2.100918] checking generic (e000 30) vs hw (e000 1000) Jun 28 14:53:54 localhost kernel: [2.100919] fb: switching to radeondrmfb from simple Jun 28 14:53:54 localhost kernel: [2.101372] Console: switching to colour dummy device 80x25 Jun 28 14:53:54 localhost kernel: [2.101527] [drm] initializing kernel modesetting (BONAIRE 0x1002:0x6658 0x174B:0xE253). Jun 28 14:53:54 localhost kernel: [2.101534] [drm] register mmio base: 0xF080 Jun 28 14:53:54 localhost kernel: [2.101535] [drm] register mmio size: 262144 Jun 28 14:53:54 localhost kernel: [2.101540] [drm] doorbell mmio base: 0xF000 Jun 28 14:53:54 localhost kernel: [2.101541] [drm] doorbell mmio size: 8388608 Jun 28 14:53:54 localhost kernel: [2.101579] ATOM BIOS: Bonaire Jun 28 14:53:54 localhost kernel: [2.101627] radeon :01:00.0: VRAM: 2048M 0x - 0x7FFF (2048M used) Jun 28 14:53:54 localhost kernel: [2.101629] radeon :01:00.0: GTT: 1024M 0x8000 - 0xBFFF Jun 28 14:53:54 localhost kernel: [2.101630] [drm] Detected VRAM RAM=2048M, BAR=256M Jun 28 14:53:54 localhost kernel: [2.101631] [drm] RAM width 128bits DDR Jun 28 14:53:54 localhost kernel: [2.101659] [TTM] Zone kernel: Available graphics memory: 8145364 kiB Jun 28 14:53:54 localhost kernel: [2.101660] [TTM] Zone dma32: Available graphics memory: 2097152 kiB Jun 28 14:53:54 localhost kernel: [2.101662] [TTM] Initializing pool allocator Jun 28 14:53:54 localhost kernel
Re: [PANIC] at drivers/drm/drm_irq.c:976 with 3.16-rc2+git
Hi Third try at getting the attachment with the jpg of the panic onto the lists (sorry if some recipients get multiple copies). https://plus.google.com/u/0/photos/108244876431105742323/albums/6029631260384977873/6029631269719723986?pid=6029631269719723986=108244876431105742323 Thanks Ed On Friday 27 June 2014 09:17:08 Ed Tomlinson wrote: > Hi > > Got the following panic runing 16-rc2 + git. The latest commit was: > > commit d91d66e88ea95b6dd21958834414009614385153 > Merge: 07f4695 6663a4f > Author: Linus Torvalds > Date: Wed Jun 25 05:44:17 2014 -0700 > > I was not doing anything interesting (displaying a photo from facebook with > firefox) > when this happened. The distribution is arch at is up to date as of june > 26th. > > Thanks > Ed Tomlinson > -- > 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/ > -- 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/
[PANIC] at drivers/drm/drm_irq.c:976 with 3.16-rc2+git
Hi Got the following panic runing 16-rc2 + git. The latest commit was: commit d91d66e88ea95b6dd21958834414009614385153 Merge: 07f4695 6663a4f Author: Linus Torvalds Date: Wed Jun 25 05:44:17 2014 -0700 I was not doing anything interesting (displaying a photo from facebook with firefox) when this happened. The distribution is arch at is up to date as of june 26th. Thanks Ed Tomlinson -- 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/
[PANIC] at drivers/drm/drm_irq.c:976 with 3.16-rc2+git
Hi Got the following panic runing 16-rc2 + git. The latest commit was: commit d91d66e88ea95b6dd21958834414009614385153 Merge: 07f4695 6663a4f Author: Linus Torvalds torva...@linux-foundation.org Date: Wed Jun 25 05:44:17 2014 -0700 I was not doing anything interesting (displaying a photo from facebook with firefox) when this happened. The distribution is arch at is up to date as of june 26th. Thanks Ed Tomlinson -- 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: [PANIC] at drivers/drm/drm_irq.c:976 with 3.16-rc2+git
Hi Third try at getting the attachment with the jpg of the panic onto the lists (sorry if some recipients get multiple copies). https://plus.google.com/u/0/photos/108244876431105742323/albums/6029631260384977873/6029631269719723986?pid=6029631269719723986oid=108244876431105742323 Thanks Ed On Friday 27 June 2014 09:17:08 Ed Tomlinson wrote: Hi Got the following panic runing 16-rc2 + git. The latest commit was: commit d91d66e88ea95b6dd21958834414009614385153 Merge: 07f4695 6663a4f Author: Linus Torvalds torva...@linux-foundation.org Date: Wed Jun 25 05:44:17 2014 -0700 I was not doing anything interesting (displaying a photo from facebook with firefox) when this happened. The distribution is arch at is up to date as of june 26th. Thanks Ed Tomlinson -- 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/ -- 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: hang on boot due to tests
On Monday 09 June 2014 12:17:50 Sasha Levin wrote: > On 06/09/2014 11:59 AM, Chris Mason wrote: > > On 06/09/2014 11:16 AM, Sasha Levin wrote: > >> > Hi all, > >> > > >> > It seems that some recent changes to btrfs tests make it hang during > >> > boot: > >> > > >> > [ 49.730033] NMI watchdog: BUG: soft lockup - CPU#34 stuck for 23s! > >> > [swapper/0:1] > >> > [ 49.730033] Modules linked in: > >> > [ 49.730033] hardirqs last enabled at (6389143): restore_args > >> > (arch/x86/kernel/entry_64.S:829) > >> > [ 49.730033] hardirqs last disabled at (6389144): apic_timer_interrupt > >> > (arch/x86/kernel/entry_64.S:1021) > >> > [ 49.730033] softirqs last enabled at (6389142): __do_softirq > >> > (./arch/x86/include/asm/preempt.h:22 kernel/softirq.c:296) > >> > [ 49.730033] softirqs last disabled at (6389139): irq_exit > >> > (kernel/softirq.c:346 kernel/softirq.c:387) > >> > [ 49.730033] CPU: 34 PID: 1 Comm: swapper/0 Not tainted > >> > 3.15.0-rc8-next-20140606-sasha-00021-ga9d3a0b-dirty #597 > > > > This is 3.15-rc8 + linux-next? I'll try to reproduce here, but the > > tests were working for me. > > Yes, it's the latest -next tree available. > > Also note that it doesn't happen every time, so might be some sort of a race? I've noticed that with -rc8 and now .15 btrfs fails to automount (or mount) about 1 in 2 times requiring a reboot to get it to work. I have not seen anything in logs. Might this be related? Thanks, Ed Tomlinson -- 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: hang on boot due to tests
On Monday 09 June 2014 12:17:50 Sasha Levin wrote: On 06/09/2014 11:59 AM, Chris Mason wrote: On 06/09/2014 11:16 AM, Sasha Levin wrote: Hi all, It seems that some recent changes to btrfs tests make it hang during boot: [ 49.730033] NMI watchdog: BUG: soft lockup - CPU#34 stuck for 23s! [swapper/0:1] [ 49.730033] Modules linked in: [ 49.730033] hardirqs last enabled at (6389143): restore_args (arch/x86/kernel/entry_64.S:829) [ 49.730033] hardirqs last disabled at (6389144): apic_timer_interrupt (arch/x86/kernel/entry_64.S:1021) [ 49.730033] softirqs last enabled at (6389142): __do_softirq (./arch/x86/include/asm/preempt.h:22 kernel/softirq.c:296) [ 49.730033] softirqs last disabled at (6389139): irq_exit (kernel/softirq.c:346 kernel/softirq.c:387) [ 49.730033] CPU: 34 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc8-next-20140606-sasha-00021-ga9d3a0b-dirty #597 This is 3.15-rc8 + linux-next? I'll try to reproduce here, but the tests were working for me. Yes, it's the latest -next tree available. Also note that it doesn't happen every time, so might be some sort of a race? I've noticed that with -rc8 and now .15 btrfs fails to automount (or mount) about 1 in 2 times requiring a reboot to get it to work. I have not seen anything in logs. Might this be related? Thanks, Ed Tomlinson -- 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: [git pull] drm radeon and nouveau fixes
On Thursday 22 May 2014 04:13:22 Dave Airlie wrote: > > Hi Linus, > > Fixes for the other big two, the radeon VCE one is large but it fixes some > userspace triggerable issues, otherwise its blackscreens and oopses, > > nouveau fixes a bleeding laptop panel issue when displayport is used > sometimes, Hi Dave, These are not breaking anything here. I also have v4 of Christian König's VRAM page table entry compression patch applied. Its also good here and speeds things up a few percent. Thanks Ed Tomlinson > The following changes since commit 4b660a7f5c8099d88d1a43d8ae138965112592c7: > > Linux 3.15-rc6 (2014-05-22 06:42:02 +0900) > > are available in the git repository at: > > git://people.freedesktop.org/~airlied/linux drm-fixes > > for you to fetch changes up to 77c01bef72a5ce5cb24adae6066ed81a52004d30: > > Merge branch 'drm-fixes-3.15' of > git://people.freedesktop.org/~deathsimple/linux into drm-fixes (2014-05-22 > 09:15:57 +1000) > > > > Alex Deucher (4): > drm/radeon: fix DCE83 check for mullins > drm/radeon: handle non-VGA class pci devices with ATRM > drm/radeon: fix register typo on si > drm/radeon/pm: don't allow debugfs/sysfs access when PX card is off (v2) > > Ben Skeggs (1): > drm/gf119-/disp: fix nasty bug which can clobber SOR0's clock setup > > Christian König (4): > drm/radeon: also try GART for CPU accessed buffers > drm/radeon: fix page directory update size estimation > drm/radeon: fix buffer placement under memory pressure v2 > drm/radeon: fix typo in finding PLL params > > Dave Airlie (2): > Merge branch 'drm-nouveau-next' of > git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes > Merge branch 'drm-fixes-3.15' of > git://people.freedesktop.org/~deathsimple/linux into drm-fixes > > Jérôme Glisse (1): > drm/radeon: avoid segfault on device open when accel is not working. > > Leo Liu (1): > drm/radeon: check VCE relocation buffer range v3 > > Martin Peres (1): > drm/nvd9/therm: handle another kind of PWM fan > > drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c | 2 +- > drivers/gpu/drm/nouveau/core/subdev/therm/nvd0.c | 1 + > drivers/gpu/drm/radeon/radeon.h | 6 +- > drivers/gpu/drm/radeon/radeon_bios.c | 14 +++ > drivers/gpu/drm/radeon/radeon_display.c | 2 +- > drivers/gpu/drm/radeon/radeon_kms.c | 55 +- > drivers/gpu/drm/radeon/radeon_object.c | 40 --- > drivers/gpu/drm/radeon/radeon_pm.c | 42 +++- > drivers/gpu/drm/radeon/radeon_vce.c | 130 > +-- > drivers/gpu/drm/radeon/radeon_vm.c | 2 +- > drivers/gpu/drm/radeon/sid.h | 4 +- > 11 files changed, 218 insertions(+), 80 deletions(-) -- 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: [git pull] drm radeon and nouveau fixes
On Thursday 22 May 2014 04:13:22 Dave Airlie wrote: Hi Linus, Fixes for the other big two, the radeon VCE one is large but it fixes some userspace triggerable issues, otherwise its blackscreens and oopses, nouveau fixes a bleeding laptop panel issue when displayport is used sometimes, Hi Dave, These are not breaking anything here. I also have v4 of Christian König's VRAM page table entry compression patch applied. Its also good here and speeds things up a few percent. Thanks Ed Tomlinson The following changes since commit 4b660a7f5c8099d88d1a43d8ae138965112592c7: Linux 3.15-rc6 (2014-05-22 06:42:02 +0900) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 77c01bef72a5ce5cb24adae6066ed81a52004d30: Merge branch 'drm-fixes-3.15' of git://people.freedesktop.org/~deathsimple/linux into drm-fixes (2014-05-22 09:15:57 +1000) Alex Deucher (4): drm/radeon: fix DCE83 check for mullins drm/radeon: handle non-VGA class pci devices with ATRM drm/radeon: fix register typo on si drm/radeon/pm: don't allow debugfs/sysfs access when PX card is off (v2) Ben Skeggs (1): drm/gf119-/disp: fix nasty bug which can clobber SOR0's clock setup Christian König (4): drm/radeon: also try GART for CPU accessed buffers drm/radeon: fix page directory update size estimation drm/radeon: fix buffer placement under memory pressure v2 drm/radeon: fix typo in finding PLL params Dave Airlie (2): Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes Merge branch 'drm-fixes-3.15' of git://people.freedesktop.org/~deathsimple/linux into drm-fixes Jérôme Glisse (1): drm/radeon: avoid segfault on device open when accel is not working. Leo Liu (1): drm/radeon: check VCE relocation buffer range v3 Martin Peres (1): drm/nvd9/therm: handle another kind of PWM fan drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c | 2 +- drivers/gpu/drm/nouveau/core/subdev/therm/nvd0.c | 1 + drivers/gpu/drm/radeon/radeon.h | 6 +- drivers/gpu/drm/radeon/radeon_bios.c | 14 +++ drivers/gpu/drm/radeon/radeon_display.c | 2 +- drivers/gpu/drm/radeon/radeon_kms.c | 55 +- drivers/gpu/drm/radeon/radeon_object.c | 40 --- drivers/gpu/drm/radeon/radeon_pm.c | 42 +++- drivers/gpu/drm/radeon/radeon_vce.c | 130 +-- drivers/gpu/drm/radeon/radeon_vm.c | 2 +- drivers/gpu/drm/radeon/sid.h | 4 +- 11 files changed, 218 insertions(+), 80 deletions(-) -- 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: PROBLEM: Pulseaudio hung at schedule in 3.15-rc1
Takashi,
I also hit this one with a webcam. Your patch below fixes it here too.
You can add:
Tested-by: Ed Tomlinson
If you want
Thanks
Ed
On Friday 02 May 2014 09:36:32 Takashi Iwai wrote:
> At Wed, 30 Apr 2014 13:40:11 -0400,
> Bryan Quigley wrote:
> >
> > > Hm, what about the one below instead?
> > >
> > >
> > > Takashi
> >
> > It works now! Still gives me some errors, but both the webcam and
> > microphone function fine..
> >
> > On pluging it in, all seems normal:
> > Apr 30 13:33:29 dell-laptop kernel: [ 467.144143] usb 2-2: new
> > high-speed USB device number 4 using ehci-pci
> > Apr 30 13:33:30 dell-laptop kernel: [ 467.492931] usb 2-2: New USB
> > device found, idVendor=046d, idProduct=0825
> > Apr 30 13:33:30 dell-laptop kernel: [ 467.492939] usb 2-2: New USB
> > device strings: Mfr=0, Product=0, SerialNumber=2
> > Apr 30 13:33:30 dell-laptop kernel: [ 467.492943] usb 2-2:
> > SerialNumber: 0911F220
> > Apr 30 13:33:30 dell-laptop kernel: [ 467.493799] uvcvideo: Found UVC
> > 1.00 device (046d:0825)
> > Apr 30 13:33:30 dell-laptop kernel: [ 467.590713] input: UVC Camera
> > (046d:0825) as
> > /devices/pci:00/:00:1d.7/usb2/2-2/2-2:1.0/input/input20
> > Apr 30 13:33:31 dell-laptop kernel: [ 468.753801] usb 2-2: set
> > resolution quirk: cval->res = 384
> >
> > But on any access (sudo lsusb -v, open webcam, etc), it will give:
> > Apr 30 13:35:21 dell-laptop kernel: [ 578.788135] usb 2-2: reset
> > high-speed USB device number 4 using ehci-pci
> > Apr 30 13:35:21 dell-laptop kernel: [ 579.142380] snd-usb-audio
> > 2-2:1.2: reset_resume error -5
> >
> > Doesn't seem to affect performance at all though..
>
> OK, the error above comes from my patch returning an error at auto
> suspend callback. How about the revised patch below?
>
>
> thanks,
>
> Takashi
>
> ---
> diff --git a/sound/usb/card.c b/sound/usb/card.c
> index 893d5a1afc3c..c3b5b7dca1c3 100644
> --- a/sound/usb/card.c
> +++ b/sound/usb/card.c
> @@ -651,7 +651,7 @@ int snd_usb_autoresume(struct snd_usb_audio *chip)
> int err = -ENODEV;
>
> down_read(>shutdown_rwsem);
> - if (chip->probing)
> + if (chip->probing && chip->in_pm)
> err = 0;
> else if (!chip->shutdown)
> err = usb_autopm_get_interface(chip->pm_intf);
> @@ -663,7 +663,7 @@ int snd_usb_autoresume(struct snd_usb_audio *chip)
> void snd_usb_autosuspend(struct snd_usb_audio *chip)
> {
> down_read(>shutdown_rwsem);
> - if (!chip->shutdown && !chip->probing)
> + if (!chip->shutdown && !chip->probing && !chip->in_pm)
> usb_autopm_put_interface(chip->pm_intf);
> up_read(>shutdown_rwsem);
> }
> @@ -695,8 +695,9 @@ static int usb_audio_suspend(struct usb_interface *intf,
> pm_message_t message)
> chip->autosuspended = 1;
> }
>
> - list_for_each_entry(mixer, >mixer_list, list)
> - snd_usb_mixer_suspend(mixer);
> + if (chip->num_suspended_intf == 1)
> + list_for_each_entry(mixer, >mixer_list, list)
> + snd_usb_mixer_suspend(mixer);
>
> return 0;
> }
> @@ -711,6 +712,8 @@ static int __usb_audio_resume(struct usb_interface *intf,
> bool reset_resume)
> return 0;
> if (--chip->num_suspended_intf)
> return 0;
> +
> + chip->in_pm = 1;
> /*
>* ALSA leaves material resumption to user space
>* we just notify and restart the mixers
> @@ -726,6 +729,7 @@ static int __usb_audio_resume(struct usb_interface *intf,
> bool reset_resume)
> chip->autosuspended = 0;
>
> err_out:
> + chip->in_pm = 0;
> return err;
> }
>
> diff --git a/sound/usb/usbaudio.h b/sound/usb/usbaudio.h
> index 25c4c7e217de..91d0380431b4 100644
> --- a/sound/usb/usbaudio.h
> +++ b/sound/usb/usbaudio.h
> @@ -40,6 +40,7 @@ struct snd_usb_audio {
> struct rw_semaphore shutdown_rwsem;
> unsigned int shutdown:1;
> unsigned int probing:1;
> + unsigned int in_pm:1;
> unsigned int autosuspended:1;
> unsigned int txfr_quirk:1; /* Subframe boundaries on transfers */
>
> --
> 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/
>
--
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: PROBLEM: Pulseaudio hung at schedule in 3.15-rc1
Takashi,
I also hit this one with a webcam. Your patch below fixes it here too.
You can add:
Tested-by: Ed Tomlinson edt...@gmail.com
If you want
Thanks
Ed
On Friday 02 May 2014 09:36:32 Takashi Iwai wrote:
At Wed, 30 Apr 2014 13:40:11 -0400,
Bryan Quigley wrote:
Hm, what about the one below instead?
Takashi
It works now! Still gives me some errors, but both the webcam and
microphone function fine..
On pluging it in, all seems normal:
Apr 30 13:33:29 dell-laptop kernel: [ 467.144143] usb 2-2: new
high-speed USB device number 4 using ehci-pci
Apr 30 13:33:30 dell-laptop kernel: [ 467.492931] usb 2-2: New USB
device found, idVendor=046d, idProduct=0825
Apr 30 13:33:30 dell-laptop kernel: [ 467.492939] usb 2-2: New USB
device strings: Mfr=0, Product=0, SerialNumber=2
Apr 30 13:33:30 dell-laptop kernel: [ 467.492943] usb 2-2:
SerialNumber: 0911F220
Apr 30 13:33:30 dell-laptop kernel: [ 467.493799] uvcvideo: Found UVC
1.00 device unnamed (046d:0825)
Apr 30 13:33:30 dell-laptop kernel: [ 467.590713] input: UVC Camera
(046d:0825) as
/devices/pci:00/:00:1d.7/usb2/2-2/2-2:1.0/input/input20
Apr 30 13:33:31 dell-laptop kernel: [ 468.753801] usb 2-2: set
resolution quirk: cval-res = 384
But on any access (sudo lsusb -v, open webcam, etc), it will give:
Apr 30 13:35:21 dell-laptop kernel: [ 578.788135] usb 2-2: reset
high-speed USB device number 4 using ehci-pci
Apr 30 13:35:21 dell-laptop kernel: [ 579.142380] snd-usb-audio
2-2:1.2: reset_resume error -5
Doesn't seem to affect performance at all though..
OK, the error above comes from my patch returning an error at auto
suspend callback. How about the revised patch below?
thanks,
Takashi
---
diff --git a/sound/usb/card.c b/sound/usb/card.c
index 893d5a1afc3c..c3b5b7dca1c3 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -651,7 +651,7 @@ int snd_usb_autoresume(struct snd_usb_audio *chip)
int err = -ENODEV;
down_read(chip-shutdown_rwsem);
- if (chip-probing)
+ if (chip-probing chip-in_pm)
err = 0;
else if (!chip-shutdown)
err = usb_autopm_get_interface(chip-pm_intf);
@@ -663,7 +663,7 @@ int snd_usb_autoresume(struct snd_usb_audio *chip)
void snd_usb_autosuspend(struct snd_usb_audio *chip)
{
down_read(chip-shutdown_rwsem);
- if (!chip-shutdown !chip-probing)
+ if (!chip-shutdown !chip-probing !chip-in_pm)
usb_autopm_put_interface(chip-pm_intf);
up_read(chip-shutdown_rwsem);
}
@@ -695,8 +695,9 @@ static int usb_audio_suspend(struct usb_interface *intf,
pm_message_t message)
chip-autosuspended = 1;
}
- list_for_each_entry(mixer, chip-mixer_list, list)
- snd_usb_mixer_suspend(mixer);
+ if (chip-num_suspended_intf == 1)
+ list_for_each_entry(mixer, chip-mixer_list, list)
+ snd_usb_mixer_suspend(mixer);
return 0;
}
@@ -711,6 +712,8 @@ static int __usb_audio_resume(struct usb_interface *intf,
bool reset_resume)
return 0;
if (--chip-num_suspended_intf)
return 0;
+
+ chip-in_pm = 1;
/*
* ALSA leaves material resumption to user space
* we just notify and restart the mixers
@@ -726,6 +729,7 @@ static int __usb_audio_resume(struct usb_interface *intf,
bool reset_resume)
chip-autosuspended = 0;
err_out:
+ chip-in_pm = 0;
return err;
}
diff --git a/sound/usb/usbaudio.h b/sound/usb/usbaudio.h
index 25c4c7e217de..91d0380431b4 100644
--- a/sound/usb/usbaudio.h
+++ b/sound/usb/usbaudio.h
@@ -40,6 +40,7 @@ struct snd_usb_audio {
struct rw_semaphore shutdown_rwsem;
unsigned int shutdown:1;
unsigned int probing:1;
+ unsigned int in_pm:1;
unsigned int autosuspended:1;
unsigned int txfr_quirk:1; /* Subframe boundaries on transfers */
--
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/
--
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: [git pull] drm fixes
On Wednesday 23 April 2014 07:54:17 Dave Airlie wrote: > On Wed, Apr 23, 2014 at 1:59 AM, Linus Torvalds > wrote: > > Dave, mind sending me a pull request for drm fixes? > > > > There's now at least these two: > > > > - "drm/radeon/aux: fix hpd assignment for aux bus" > > - "drm/radeon: use fixed PPL ref divider if needed" > > > > that look like fairly fatal regressions when they affect somebody. > > > > The fact that we already had *two* independent bugs be reported within > > days of that last out-of-merge-window pull request makes me very > > unhappy with the state of drm pulls. > > > > So please make sure that future fixes really are *fixes*. For > > regressions only. No more games like this. > > The pll fallout is fixes for the initial feature that was in the merge window, > Tuning plls for monitors is always a pain in the ass, the previous algorithm > took a couple of kernels a few years back to get where it was, unfortunately > HDMI came along and showed up a bunch of its shortcomings. I'm happy > Alex and Christian are on top of things in terms of tracking regressions > and making sure they get fixed, > > the AUX fix yes I'm a bit pissed off about myself, but I missed a pull > from a few > weeks ago, felt guilty, and maybe should have chosen the other path and let it > wait a merge, > > Christian just sent me a -fixes pull with all of these in it and I'll > send it on to you > in a few mins. Hi Given the fun I had with rc1 I decided to try this pull before rc2 and its working fine here. Thanks! Ed Tomlinson -- 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: [git pull] drm fixes
On Wednesday 23 April 2014 07:54:17 Dave Airlie wrote: On Wed, Apr 23, 2014 at 1:59 AM, Linus Torvalds torva...@linux-foundation.org wrote: Dave, mind sending me a pull request for drm fixes? There's now at least these two: - drm/radeon/aux: fix hpd assignment for aux bus - drm/radeon: use fixed PPL ref divider if needed that look like fairly fatal regressions when they affect somebody. The fact that we already had *two* independent bugs be reported within days of that last out-of-merge-window pull request makes me very unhappy with the state of drm pulls. So please make sure that future fixes really are *fixes*. For regressions only. No more games like this. The pll fallout is fixes for the initial feature that was in the merge window, Tuning plls for monitors is always a pain in the ass, the previous algorithm took a couple of kernels a few years back to get where it was, unfortunately HDMI came along and showed up a bunch of its shortcomings. I'm happy Alex and Christian are on top of things in terms of tracking regressions and making sure they get fixed, the AUX fix yes I'm a bit pissed off about myself, but I missed a pull from a few weeks ago, felt guilty, and maybe should have chosen the other path and let it wait a merge, Christian just sent me a -fixes pull with all of these in it and I'll send it on to you in a few mins. Hi Given the fun I had with rc1 I decided to try this pull before rc2 and its working fine here. Thanks! Ed Tomlinson -- 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: [git pull] drm fixes
On Monday 21 April 2014 17:26:15 Ed Tomlinson wrote: > On Monday 21 April 2014 15:08:24 Ed Tomlinson wrote: > > On Monday 21 April 2014 10:25:25 Ed Tomlinson wrote: > > > On Saturday 19 April 2014 21:03:05 Markus Trippelsdorf wrote: > > > > On 2014.04.19 at 08:19 +0100, Dave Airlie wrote: > > > > > > > > > > Unfortunately this contains no easter eggs, its a bit larger than I'd > > > > > like, but I included a patch that just moves code from one file to > > > > > another > > > > > and I'd like to avoid merge conflicts with that later, so it makes it > > > > > seem > > > > > worse than it is, > > > > > > > > > Christian König (2): > > > > > drm/radeon: apply more strict limits for PLL params v2 > > > > > drm/radeon: improve PLL params if we don't match exactly v2 > > > > > > > > commit f8a2645ecede4eaf90b3d785f2805c8ecb76d43e > > > > Author: Christian König > > > > Date: Wed Apr 16 11:54:21 2014 +0200 > > > > > > > > drm/radeon: improve PLL params if we don't match exactly v2 > > > > > > > > The commit above causes my monitor to just stay blank after boot. > > > > No framebuffer, no Xorg, no nothing. I'm using a Radeon RS780. > > Reverting > > commit 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef > Author: Alex Deucher > Date: Mon Apr 7 10:33:46 2014 -0400 > > drm/radeon/dp: switch to the common i2c over aux code > > Provides a nice cleanup in radeon. > > Signed-off-by: Alex Deucher > Signed-off-by: Christian König > > Restores the display - no more i2c errors This fixed here without reverts by the patch from Alex Deucher attached in the thread: "Re: 3.15.0-rc2 radeon HD 7480D [Aruba] blank display" Thanks Ed > > > I have the same symptoms with rc2 and a r7 260x using display port. I > > > cannot > > > seem to get a dmesg of a failure (I _really_ need to figure out how to add > > > a serial console). I'll try reverting once I figure out how to get > > > pacman to > > > do a revert when building from git. > > > > Neither reverting the above patch or add the fix from > > "https://bugs.freedesktop.org/show_bug.cgi?id=77673; > > helps here. I managed to get dmesg(s) from 14.1 and 15-rc2. The major > > difference has to do with i2c. On the > > 14.1 kernel I see: -- 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.15.0-rc2 radeon HD 7480D [Aruba] blank display
On Tuesday 22 April 2014 01:54:01 Alex Deucher wrote: > On Mon, Apr 21, 2014 at 10:34 PM, Ken Moffat wrote: > > On Tue, Apr 22, 2014 at 03:31:06AM +0100, Ken Moffat wrote: > > > > [ resending, somehow lkml dropped out of the Cc. ] > > > >> On Tue, Apr 22, 2014 at 12:19:40AM +0100, Ken Moffat wrote: > >> > On Mon, Apr 21, 2014 at 05:29:27PM -0400, Ed Tomlinson wrote: > >> > >> > > Ken, > >> > > > >> > > You might want to try reverting: > >> > > > >> > > commit 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef > >> > > Author: Alex Deucher > >> > > Date: Mon Apr 7 10:33:46 2014 -0400 > >> > > > >> > > drm/radeon/dp: switch to the common i2c over aux code > >> > > > >> > > Provides a nice cleanup in radeon. > >> > > > >> > > Signed-off-by: Alex Deucher > >> > > Signed-off-by: Christian König > >> > > > >> > > This fixed a similar problem here (see the drm pull thread for rc1) > >> > > > >> > > Thanks > >> > > Ed Tomlinson > >> > > >> > Tried reverting that from rc2, but it didn't help. Thanks anyway. > >> > > >> > >> Well, I *believed* I had created a patch for that commit, and > >> reverted it from -rc2 with patch -R. But I've now bisected through > >> drivers/gpu/drm between v3.14.0 and v3.15-rc2 and the bisection > >> pointed to that same commit, so I guess I did something wrong. > >> > >> There were a couple of other issues along the way (mounting nfs > >> hung on one commit, startx hung on several of the commits, but I've > >> marked those as "good" because I had a display, even if the system > >> was not usable). > >> > >> I've now gone back to linus' tree that I cloned a few hours ago, > >> i.e. > >> commit c089b229dfdd09d59a11d8bc2344bf8196d575ce > >> Merge: 9ac03675010a 0565103d1adb > >> Author: Linus Torvalds > >> Date: Mon Apr 21 10:05:35 2014 -0700 > >> > >> Merge branch 'for-linus' of > >> git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml > >> > >> created a branch, and *definitely* reverted > >> 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef (using git revert) in that > >> branch. And this version works fine. > >> > >> So belatedly I see that I seem to have the same problem as Ed. Or > >> at least that the same commit is causing both our problems. > >> > >> Alex - do you need any more information from me to help with this ? > > The attached patch should fix it. And it does here (on bonaire, r7 260x). You can add my tested by Tested-by: Ed Tomlinson Thanks, Ed Tomlinson -- 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.15.0-rc2 radeon HD 7480D [Aruba] blank display
On Tuesday 22 April 2014 01:54:01 Alex Deucher wrote: On Mon, Apr 21, 2014 at 10:34 PM, Ken Moffat zarniwh...@ntlworld.com wrote: On Tue, Apr 22, 2014 at 03:31:06AM +0100, Ken Moffat wrote: [ resending, somehow lkml dropped out of the Cc. ] On Tue, Apr 22, 2014 at 12:19:40AM +0100, Ken Moffat wrote: On Mon, Apr 21, 2014 at 05:29:27PM -0400, Ed Tomlinson wrote: Ken, You might want to try reverting: commit 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef Author: Alex Deucher alexdeuc...@gmail.com Date: Mon Apr 7 10:33:46 2014 -0400 drm/radeon/dp: switch to the common i2c over aux code Provides a nice cleanup in radeon. Signed-off-by: Alex Deucher alexander.deuc...@amd.com Signed-off-by: Christian König christian.koe...@amd.com This fixed a similar problem here (see the drm pull thread for rc1) Thanks Ed Tomlinson Tried reverting that from rc2, but it didn't help. Thanks anyway. Well, I *believed* I had created a patch for that commit, and reverted it from -rc2 with patch -R. But I've now bisected through drivers/gpu/drm between v3.14.0 and v3.15-rc2 and the bisection pointed to that same commit, so I guess I did something wrong. There were a couple of other issues along the way (mounting nfs hung on one commit, startx hung on several of the commits, but I've marked those as good because I had a display, even if the system was not usable). I've now gone back to linus' tree that I cloned a few hours ago, i.e. commit c089b229dfdd09d59a11d8bc2344bf8196d575ce Merge: 9ac03675010a 0565103d1adb Author: Linus Torvalds torva...@linux-foundation.org Date: Mon Apr 21 10:05:35 2014 -0700 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml created a branch, and *definitely* reverted 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef (using git revert) in that branch. And this version works fine. So belatedly I see that I seem to have the same problem as Ed. Or at least that the same commit is causing both our problems. Alex - do you need any more information from me to help with this ? The attached patch should fix it. And it does here (on bonaire, r7 260x). You can add my tested by Tested-by: Ed Tomlinson edt...@gmail.com Thanks, Ed Tomlinson -- 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: [git pull] drm fixes
On Monday 21 April 2014 17:26:15 Ed Tomlinson wrote: On Monday 21 April 2014 15:08:24 Ed Tomlinson wrote: On Monday 21 April 2014 10:25:25 Ed Tomlinson wrote: On Saturday 19 April 2014 21:03:05 Markus Trippelsdorf wrote: On 2014.04.19 at 08:19 +0100, Dave Airlie wrote: Unfortunately this contains no easter eggs, its a bit larger than I'd like, but I included a patch that just moves code from one file to another and I'd like to avoid merge conflicts with that later, so it makes it seem worse than it is, Christian König (2): drm/radeon: apply more strict limits for PLL params v2 drm/radeon: improve PLL params if we don't match exactly v2 commit f8a2645ecede4eaf90b3d785f2805c8ecb76d43e Author: Christian König christian.koe...@amd.com Date: Wed Apr 16 11:54:21 2014 +0200 drm/radeon: improve PLL params if we don't match exactly v2 The commit above causes my monitor to just stay blank after boot. No framebuffer, no Xorg, no nothing. I'm using a Radeon RS780. Reverting commit 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef Author: Alex Deucher alexdeuc...@gmail.com Date: Mon Apr 7 10:33:46 2014 -0400 drm/radeon/dp: switch to the common i2c over aux code Provides a nice cleanup in radeon. Signed-off-by: Alex Deucher alexander.deuc...@amd.com Signed-off-by: Christian König christian.koe...@amd.com Restores the display - no more i2c errors This fixed here without reverts by the patch from Alex Deucher attached in the thread: Re: 3.15.0-rc2 radeon HD 7480D [Aruba] blank display Thanks Ed I have the same symptoms with rc2 and a r7 260x using display port. I cannot seem to get a dmesg of a failure (I _really_ need to figure out how to add a serial console). I'll try reverting once I figure out how to get pacman to do a revert when building from git. Neither reverting the above patch or add the fix from https://bugs.freedesktop.org/show_bug.cgi?id=77673; helps here. I managed to get dmesg(s) from 14.1 and 15-rc2. The major difference has to do with i2c. On the 14.1 kernel I see: -- 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: [git pull] drm fixes
On Monday 21 April 2014 15:08:24 Ed Tomlinson wrote: > On Monday 21 April 2014 10:25:25 Ed Tomlinson wrote: > > On Saturday 19 April 2014 21:03:05 Markus Trippelsdorf wrote: > > > On 2014.04.19 at 08:19 +0100, Dave Airlie wrote: > > > > > > > > Unfortunately this contains no easter eggs, its a bit larger than I'd > > > > like, but I included a patch that just moves code from one file to > > > > another > > > > and I'd like to avoid merge conflicts with that later, so it makes it > > > > seem > > > > worse than it is, > > > > > > > Christian König (2): > > > > drm/radeon: apply more strict limits for PLL params v2 > > > > drm/radeon: improve PLL params if we don't match exactly v2 > > > > > > commit f8a2645ecede4eaf90b3d785f2805c8ecb76d43e > > > Author: Christian König > > > Date: Wed Apr 16 11:54:21 2014 +0200 > > > > > > drm/radeon: improve PLL params if we don't match exactly v2 > > > > > > The commit above causes my monitor to just stay blank after boot. > > > No framebuffer, no Xorg, no nothing. I'm using a Radeon RS780. Reverting commit 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef Author: Alex Deucher Date: Mon Apr 7 10:33:46 2014 -0400 drm/radeon/dp: switch to the common i2c over aux code Provides a nice cleanup in radeon. Signed-off-by: Alex Deucher Signed-off-by: Christian König Restores the display - no more i2c errors I have dmesgs of all three tests if anyone wants them. Thanks Ed Tomlinson > > I have the same symptoms with rc2 and a r7 260x using display port. I > > cannot > > seem to get a dmesg of a failure (I _really_ need to figure out how to add > > a serial console). I'll try reverting once I figure out how to get pacman > > to > > do a revert when building from git. > > Neither reverting the above patch or add the fix from > "https://bugs.freedesktop.org/show_bug.cgi?id=77673; > helps here. I managed to get dmesg(s) from 14.1 and 15-rc2. The major > difference has to do with i2c. On the > 14.1 kernel I see: > > [2.679029] [drm] ib test on ring 5 succeeded > [2.699317] [drm:radeon_dp_i2c_aux_ch], aux_i2c nack > [2.699478] [drm:radeon_dp_i2c_aux_ch], aux_i2c nack > [2.699535] [drm] Radeon Display Connectors > [2.699536] [drm] Connector 0: > [2.699537] [drm] DP-1 > [2.699537] [drm] HPD2 > [2.699538] [drm] DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c > 0x653c > [2.699538] [drm] Encoders: > [2.699539] [drm] DFP1: INTERNAL_UNIPHY2 > > skipping the rest of the connectors > [2.699647] [drm:radeon_atom_encoder_dpms], encoder dpms 33 to mode 3, > devices 0008, acti > ve_devices > [2.699648] [drm:radeon_atom_encoder_dpms], encoder dpms 33 to mode 3, > devices 0080, acti > ve_devices > [2.699649] [drm:radeon_atom_encoder_dpms], encoder dpms 32 to mode 3, > devices 0200, acti > ve_devices > [2.699650] [drm:radeon_atom_encoder_dpms], encoder dpms 30 to mode 3, > devices 0400, acti > ve_devices > [2.699651] [drm:radeon_atom_encoder_dpms], encoder dpms 21 to mode 3, > devices 0001, acti > ve_devices > [2.706746] [drm:drm_helper_probe_single_connector_modes], > [CONNECTOR:19:DP-1] > [2.712729] [drm:radeon_dp_getdpcd], DPCD: > [2.712731] [drm:radeon_dp_getdpcd], 11 > [2.712732] [drm:radeon_dp_getdpcd], 0a > [2.712733] [drm:radeon_dp_getdpcd], 84 > [2.712733] [drm:radeon_dp_getdpcd], 00 > [2.712734] [drm:radeon_dp_getdpcd], 01 > [2.712735] [drm:radeon_dp_getdpcd], 00 > [2.712735] [drm:radeon_dp_getdpcd], 00 > [2.712736] [drm:radeon_dp_getdpcd], 00 > [2.712736] [drm:radeon_dp_getdpcd], 00 > [2.712737] [drm:radeon_dp_getdpcd], 00 > [2.712738] [drm:radeon_dp_getdpcd], 00 > [2.712739] [drm:radeon_dp_getdpcd], 00 > [2.712739] [drm:radeon_dp_getdpcd], 00 > [2.712740] [drm:radeon_dp_getdpcd], 00 > [2.712741] [drm:radeon_dp_getdpcd], 00 > [2.712741] [drm:radeon_dp_getdpcd], > [2.712746] [drm:radeon_atombios_connected_scratch_regs], DFP1 connected > [2.713618] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 > [2.738573] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 > [2.770849] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 > [2.770907] [drm:drm_helper_probe_single_connector_modes], > [CONNECTOR:19:DP-1] probed modes : > [2.770908] [drm:drm_mode_debug_printmodeline], Modeline 28:"1920x1200" 60 > 154000 1920 1968
Re: [git pull] drm fixes
On Monday 21 April 2014 10:25:25 Ed Tomlinson wrote: > On Saturday 19 April 2014 21:03:05 Markus Trippelsdorf wrote: > > On 2014.04.19 at 08:19 +0100, Dave Airlie wrote: > > > > > > Unfortunately this contains no easter eggs, its a bit larger than I'd > > > like, but I included a patch that just moves code from one file to > > > another > > > and I'd like to avoid merge conflicts with that later, so it makes it > > > seem > > > worse than it is, > > > > > Christian König (2): > > > drm/radeon: apply more strict limits for PLL params v2 > > > drm/radeon: improve PLL params if we don't match exactly v2 > > > > commit f8a2645ecede4eaf90b3d785f2805c8ecb76d43e > > Author: Christian König > > Date: Wed Apr 16 11:54:21 2014 +0200 > > > > drm/radeon: improve PLL params if we don't match exactly v2 > > > > The commit above causes my monitor to just stay blank after boot. > > No framebuffer, no Xorg, no nothing. I'm using a Radeon RS780. > > I have the same symptoms with rc2 and a r7 260x using display port. I cannot > seem to get a dmesg of a failure (I _really_ need to figure out how to add > a serial console). I'll try reverting once I figure out how to get pacman to > do a revert when building from git. Neither reverting the above patch or add the fix from "https://bugs.freedesktop.org/show_bug.cgi?id=77673; helps here. I managed to get dmesg(s) from 14.1 and 15-rc2. The major difference has to do with i2c. On the 14.1 kernel I see: [2.679029] [drm] ib test on ring 5 succeeded [2.699317] [drm:radeon_dp_i2c_aux_ch], aux_i2c nack [2.699478] [drm:radeon_dp_i2c_aux_ch], aux_i2c nack [2.699535] [drm] Radeon Display Connectors [2.699536] [drm] Connector 0: [2.699537] [drm] DP-1 [2.699537] [drm] HPD2 [2.699538] [drm] DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c [2.699538] [drm] Encoders: [2.699539] [drm] DFP1: INTERNAL_UNIPHY2 skipping the rest of the connectors [2.699647] [drm:radeon_atom_encoder_dpms], encoder dpms 33 to mode 3, devices 0008, acti ve_devices [2.699648] [drm:radeon_atom_encoder_dpms], encoder dpms 33 to mode 3, devices 0080, acti ve_devices [2.699649] [drm:radeon_atom_encoder_dpms], encoder dpms 32 to mode 3, devices 0200, acti ve_devices [2.699650] [drm:radeon_atom_encoder_dpms], encoder dpms 30 to mode 3, devices 0400, acti ve_devices [2.699651] [drm:radeon_atom_encoder_dpms], encoder dpms 21 to mode 3, devices 0001, acti ve_devices [2.706746] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:19:DP-1] [2.712729] [drm:radeon_dp_getdpcd], DPCD: [2.712731] [drm:radeon_dp_getdpcd], 11 [2.712732] [drm:radeon_dp_getdpcd], 0a [2.712733] [drm:radeon_dp_getdpcd], 84 [2.712733] [drm:radeon_dp_getdpcd], 00 [2.712734] [drm:radeon_dp_getdpcd], 01 [2.712735] [drm:radeon_dp_getdpcd], 00 [2.712735] [drm:radeon_dp_getdpcd], 00 [2.712736] [drm:radeon_dp_getdpcd], 00 [2.712736] [drm:radeon_dp_getdpcd], 00 [2.712737] [drm:radeon_dp_getdpcd], 00 [2.712738] [drm:radeon_dp_getdpcd], 00 [2.712739] [drm:radeon_dp_getdpcd], 00 [2.712739] [drm:radeon_dp_getdpcd], 00 [2.712740] [drm:radeon_dp_getdpcd], 00 [2.712741] [drm:radeon_dp_getdpcd], 00 [2.712741] [drm:radeon_dp_getdpcd], [2.712746] [drm:radeon_atombios_connected_scratch_regs], DFP1 connected [2.713618] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 [2.738573] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 [2.770849] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 [2.770907] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:19:DP-1] probed modes : [2.770908] [drm:drm_mode_debug_printmodeline], Modeline 28:"1920x1200" 60 154000 1920 1968 2 000 2080 1200 1203 1209 1235 0x48 0x9 And on the 15-rc2 kernel [2.580468] [drm] ib test on ring 4 succeeded in 0 usecs [2.601369] [drm] ib test on ring 5 succeeded [2.622309] [drm] ib test on ring 6 succeeded [2.623058] [drm] ib test on ring 7 succeeded [2.623449] [drm] Radeon Display Connectors [2.623452] [drm] Connector 0: [2.623453] [drm] DP-1 [2.623455] [drm] HPD2 [2.623457] [drm] DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c [2.623459] [drm] Encoders: [2.623461] [drm] DFP1: INTERNAL_UNIPHY2 (connectors skipped) [2.623618] [drm:radeon_atom_encoder_dpms] encoder dpms 33 to mode 3, devices 0080, activ e_devices [2.623620] [drm:radeon_atom_encoder_dpms] encoder dpms 32 to mode 3, devices 0200, activ e_devices [2.623621] [drm:radeon_atom_encoder_dpms] encoder dpms
Re: [git pull] drm fixes
On Saturday 19 April 2014 21:03:05 Markus Trippelsdorf wrote: > On 2014.04.19 at 08:19 +0100, Dave Airlie wrote: > > > > Unfortunately this contains no easter eggs, its a bit larger than I'd > > like, but I included a patch that just moves code from one file to another > > and I'd like to avoid merge conflicts with that later, so it makes it seem > > worse than it is, > > > Christian König (2): > > drm/radeon: apply more strict limits for PLL params v2 > > drm/radeon: improve PLL params if we don't match exactly v2 > > commit f8a2645ecede4eaf90b3d785f2805c8ecb76d43e > Author: Christian König > Date: Wed Apr 16 11:54:21 2014 +0200 > > drm/radeon: improve PLL params if we don't match exactly v2 > > The commit above causes my monitor to just stay blank after boot. > No framebuffer, no Xorg, no nothing. I'm using a Radeon RS780. I have the same symptoms with rc2 and a r7 260x using display port. I cannot seem to get a dmesg of a failure (I _really_ need to figure out how to add a serial console). I'll try reverting once I figure out how to get pacman to do a revert when building from git. Thanks, Ed Tomlinson -- 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: [git pull] drm fixes
On Saturday 19 April 2014 21:03:05 Markus Trippelsdorf wrote: On 2014.04.19 at 08:19 +0100, Dave Airlie wrote: Unfortunately this contains no easter eggs, its a bit larger than I'd like, but I included a patch that just moves code from one file to another and I'd like to avoid merge conflicts with that later, so it makes it seem worse than it is, Christian König (2): drm/radeon: apply more strict limits for PLL params v2 drm/radeon: improve PLL params if we don't match exactly v2 commit f8a2645ecede4eaf90b3d785f2805c8ecb76d43e Author: Christian König christian.koe...@amd.com Date: Wed Apr 16 11:54:21 2014 +0200 drm/radeon: improve PLL params if we don't match exactly v2 The commit above causes my monitor to just stay blank after boot. No framebuffer, no Xorg, no nothing. I'm using a Radeon RS780. I have the same symptoms with rc2 and a r7 260x using display port. I cannot seem to get a dmesg of a failure (I _really_ need to figure out how to add a serial console). I'll try reverting once I figure out how to get pacman to do a revert when building from git. Thanks, Ed Tomlinson -- 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: [git pull] drm fixes
On Monday 21 April 2014 10:25:25 Ed Tomlinson wrote: On Saturday 19 April 2014 21:03:05 Markus Trippelsdorf wrote: On 2014.04.19 at 08:19 +0100, Dave Airlie wrote: Unfortunately this contains no easter eggs, its a bit larger than I'd like, but I included a patch that just moves code from one file to another and I'd like to avoid merge conflicts with that later, so it makes it seem worse than it is, Christian König (2): drm/radeon: apply more strict limits for PLL params v2 drm/radeon: improve PLL params if we don't match exactly v2 commit f8a2645ecede4eaf90b3d785f2805c8ecb76d43e Author: Christian König christian.koe...@amd.com Date: Wed Apr 16 11:54:21 2014 +0200 drm/radeon: improve PLL params if we don't match exactly v2 The commit above causes my monitor to just stay blank after boot. No framebuffer, no Xorg, no nothing. I'm using a Radeon RS780. I have the same symptoms with rc2 and a r7 260x using display port. I cannot seem to get a dmesg of a failure (I _really_ need to figure out how to add a serial console). I'll try reverting once I figure out how to get pacman to do a revert when building from git. Neither reverting the above patch or add the fix from https://bugs.freedesktop.org/show_bug.cgi?id=77673; helps here. I managed to get dmesg(s) from 14.1 and 15-rc2. The major difference has to do with i2c. On the 14.1 kernel I see: [2.679029] [drm] ib test on ring 5 succeeded [2.699317] [drm:radeon_dp_i2c_aux_ch], aux_i2c nack [2.699478] [drm:radeon_dp_i2c_aux_ch], aux_i2c nack [2.699535] [drm] Radeon Display Connectors [2.699536] [drm] Connector 0: [2.699537] [drm] DP-1 [2.699537] [drm] HPD2 [2.699538] [drm] DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c [2.699538] [drm] Encoders: [2.699539] [drm] DFP1: INTERNAL_UNIPHY2 skipping the rest of the connectors [2.699647] [drm:radeon_atom_encoder_dpms], encoder dpms 33 to mode 3, devices 0008, acti ve_devices [2.699648] [drm:radeon_atom_encoder_dpms], encoder dpms 33 to mode 3, devices 0080, acti ve_devices [2.699649] [drm:radeon_atom_encoder_dpms], encoder dpms 32 to mode 3, devices 0200, acti ve_devices [2.699650] [drm:radeon_atom_encoder_dpms], encoder dpms 30 to mode 3, devices 0400, acti ve_devices [2.699651] [drm:radeon_atom_encoder_dpms], encoder dpms 21 to mode 3, devices 0001, acti ve_devices [2.706746] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:19:DP-1] [2.712729] [drm:radeon_dp_getdpcd], DPCD: [2.712731] [drm:radeon_dp_getdpcd], 11 [2.712732] [drm:radeon_dp_getdpcd], 0a [2.712733] [drm:radeon_dp_getdpcd], 84 [2.712733] [drm:radeon_dp_getdpcd], 00 [2.712734] [drm:radeon_dp_getdpcd], 01 [2.712735] [drm:radeon_dp_getdpcd], 00 [2.712735] [drm:radeon_dp_getdpcd], 00 [2.712736] [drm:radeon_dp_getdpcd], 00 [2.712736] [drm:radeon_dp_getdpcd], 00 [2.712737] [drm:radeon_dp_getdpcd], 00 [2.712738] [drm:radeon_dp_getdpcd], 00 [2.712739] [drm:radeon_dp_getdpcd], 00 [2.712739] [drm:radeon_dp_getdpcd], 00 [2.712740] [drm:radeon_dp_getdpcd], 00 [2.712741] [drm:radeon_dp_getdpcd], 00 [2.712741] [drm:radeon_dp_getdpcd], [2.712746] [drm:radeon_atombios_connected_scratch_regs], DFP1 connected [2.713618] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 [2.738573] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 [2.770849] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 [2.770907] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:19:DP-1] probed modes : [2.770908] [drm:drm_mode_debug_printmodeline], Modeline 28:1920x1200 60 154000 1920 1968 2 000 2080 1200 1203 1209 1235 0x48 0x9 And on the 15-rc2 kernel [2.580468] [drm] ib test on ring 4 succeeded in 0 usecs [2.601369] [drm] ib test on ring 5 succeeded [2.622309] [drm] ib test on ring 6 succeeded [2.623058] [drm] ib test on ring 7 succeeded [2.623449] [drm] Radeon Display Connectors [2.623452] [drm] Connector 0: [2.623453] [drm] DP-1 [2.623455] [drm] HPD2 [2.623457] [drm] DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c [2.623459] [drm] Encoders: [2.623461] [drm] DFP1: INTERNAL_UNIPHY2 (connectors skipped) [2.623618] [drm:radeon_atom_encoder_dpms] encoder dpms 33 to mode 3, devices 0080, activ e_devices [2.623620] [drm:radeon_atom_encoder_dpms] encoder dpms 32 to mode 3, devices 0200, activ e_devices [2.623621] [drm:radeon_atom_encoder_dpms] encoder dpms 30 to mode 3, devices 0400, activ e_devices [2.623623] [drm:radeon_atom_encoder_dpms] encoder dpms 21 to mode 3, devices 0001, activ e_devices [2.630704] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:26:DP-1
Re: [git pull] drm fixes
On Monday 21 April 2014 15:08:24 Ed Tomlinson wrote: On Monday 21 April 2014 10:25:25 Ed Tomlinson wrote: On Saturday 19 April 2014 21:03:05 Markus Trippelsdorf wrote: On 2014.04.19 at 08:19 +0100, Dave Airlie wrote: Unfortunately this contains no easter eggs, its a bit larger than I'd like, but I included a patch that just moves code from one file to another and I'd like to avoid merge conflicts with that later, so it makes it seem worse than it is, Christian König (2): drm/radeon: apply more strict limits for PLL params v2 drm/radeon: improve PLL params if we don't match exactly v2 commit f8a2645ecede4eaf90b3d785f2805c8ecb76d43e Author: Christian König christian.koe...@amd.com Date: Wed Apr 16 11:54:21 2014 +0200 drm/radeon: improve PLL params if we don't match exactly v2 The commit above causes my monitor to just stay blank after boot. No framebuffer, no Xorg, no nothing. I'm using a Radeon RS780. Reverting commit 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef Author: Alex Deucher alexdeuc...@gmail.com Date: Mon Apr 7 10:33:46 2014 -0400 drm/radeon/dp: switch to the common i2c over aux code Provides a nice cleanup in radeon. Signed-off-by: Alex Deucher alexander.deuc...@amd.com Signed-off-by: Christian König christian.koe...@amd.com Restores the display - no more i2c errors I have dmesgs of all three tests if anyone wants them. Thanks Ed Tomlinson I have the same symptoms with rc2 and a r7 260x using display port. I cannot seem to get a dmesg of a failure (I _really_ need to figure out how to add a serial console). I'll try reverting once I figure out how to get pacman to do a revert when building from git. Neither reverting the above patch or add the fix from https://bugs.freedesktop.org/show_bug.cgi?id=77673; helps here. I managed to get dmesg(s) from 14.1 and 15-rc2. The major difference has to do with i2c. On the 14.1 kernel I see: [2.679029] [drm] ib test on ring 5 succeeded [2.699317] [drm:radeon_dp_i2c_aux_ch], aux_i2c nack [2.699478] [drm:radeon_dp_i2c_aux_ch], aux_i2c nack [2.699535] [drm] Radeon Display Connectors [2.699536] [drm] Connector 0: [2.699537] [drm] DP-1 [2.699537] [drm] HPD2 [2.699538] [drm] DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c [2.699538] [drm] Encoders: [2.699539] [drm] DFP1: INTERNAL_UNIPHY2 skipping the rest of the connectors [2.699647] [drm:radeon_atom_encoder_dpms], encoder dpms 33 to mode 3, devices 0008, acti ve_devices [2.699648] [drm:radeon_atom_encoder_dpms], encoder dpms 33 to mode 3, devices 0080, acti ve_devices [2.699649] [drm:radeon_atom_encoder_dpms], encoder dpms 32 to mode 3, devices 0200, acti ve_devices [2.699650] [drm:radeon_atom_encoder_dpms], encoder dpms 30 to mode 3, devices 0400, acti ve_devices [2.699651] [drm:radeon_atom_encoder_dpms], encoder dpms 21 to mode 3, devices 0001, acti ve_devices [2.706746] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:19:DP-1] [2.712729] [drm:radeon_dp_getdpcd], DPCD: [2.712731] [drm:radeon_dp_getdpcd], 11 [2.712732] [drm:radeon_dp_getdpcd], 0a [2.712733] [drm:radeon_dp_getdpcd], 84 [2.712733] [drm:radeon_dp_getdpcd], 00 [2.712734] [drm:radeon_dp_getdpcd], 01 [2.712735] [drm:radeon_dp_getdpcd], 00 [2.712735] [drm:radeon_dp_getdpcd], 00 [2.712736] [drm:radeon_dp_getdpcd], 00 [2.712736] [drm:radeon_dp_getdpcd], 00 [2.712737] [drm:radeon_dp_getdpcd], 00 [2.712738] [drm:radeon_dp_getdpcd], 00 [2.712739] [drm:radeon_dp_getdpcd], 00 [2.712739] [drm:radeon_dp_getdpcd], 00 [2.712740] [drm:radeon_dp_getdpcd], 00 [2.712741] [drm:radeon_dp_getdpcd], 00 [2.712741] [drm:radeon_dp_getdpcd], [2.712746] [drm:radeon_atombios_connected_scratch_regs], DFP1 connected [2.713618] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 [2.738573] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 [2.770849] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 [2.770907] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:19:DP-1] probed modes : [2.770908] [drm:drm_mode_debug_printmodeline], Modeline 28:1920x1200 60 154000 1920 1968 2 000 2080 1200 1203 1209 1235 0x48 0x9 And on the 15-rc2 kernel [2.580468] [drm] ib test on ring 4 succeeded in 0 usecs [2.601369] [drm] ib test on ring 5 succeeded [2.622309] [drm] ib test on ring 6 succeeded [2.623058] [drm] ib test on ring 7 succeeded [2.623449] [drm] Radeon Display Connectors [2.623452] [drm] Connector 0: [2.623453] [drm] DP-1 [2.623455] [drm] HPD2 [2.623457] [drm] DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c
Re: [BUG] 3.14-rc6 problems with an R7 260X
On Sunday 23 March 2014 16:08:37 Ed Tomlinson wrote: > On Monday 10 March 2014 13:29:41 Ed Tomlinson wrote: > > On Monday 10 March 2014 12:38:42 Alex Deucher wrote: > > > On Mon, Mar 10, 2014 at 11:47 AM, Ed Tomlinson wrote: > > > > Hi, > > > > > > > > I recently added a R7 260X to my system. While the card works with > > > > 3.13 its supposed work much better with 14-rc. > > > > This is not the case. My system is unstable without radeon.dpm=0 which > > > > was the default in .13. Here are some extracts > > > > from the logs of the latest fun with dpm enabled: > > > > omitted > > > > > > The above type of errors repeat hundreds of times and eventually the > > > > display freezes (this box does not have a serial console and it did not > > > > check with ssh) > > > > > > > > When X started I did notice some corruption. There are sets of two > > > > rectangles about of a height of 2 or 3 mm, width of 25m or so with a > > > > second > > > > about a cm below. The often occurs in chomium especially when > > > > scrolling. Runing the unigine-sanctuary or unigine-tropics > > > > demo/benchmark > > > > programs also produce the above problems and eventually stall. > > > > > > > > The problem is reproducible - I am not that familiar with gpu problems > > > > though, what else will help debug this? > > > > > > > > > > Please file a bug at https://bugs.freedesktop.org (Product: DRI, > > > Component: DRM/Radeon) and attach your dmesg output and xorg log. > > > > Filed as bug 75992 > > > > Let me know if you want me to test anything or if more info is needed. > > This still occurrs with rc7. With dpm enabled X is not usable. It stalls, > sometimes with nasty screen corruption, after a few minute. With dpm disabled > its much better (not perfect though). This has been solved via a firmware fix and a patch see: https://bugs.freedesktop.org/show_bug.cgi?id=75992 Ed Tomlinson -- 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: [BUG] 3.14-rc6 problems with an R7 260X
On Sunday 23 March 2014 16:08:37 Ed Tomlinson wrote: On Monday 10 March 2014 13:29:41 Ed Tomlinson wrote: On Monday 10 March 2014 12:38:42 Alex Deucher wrote: On Mon, Mar 10, 2014 at 11:47 AM, Ed Tomlinson e...@aei.ca wrote: Hi, I recently added a R7 260X to my system. While the card works with 3.13 its supposed work much better with 14-rc. This is not the case. My system is unstable without radeon.dpm=0 which was the default in .13. Here are some extracts from the logs of the latest fun with dpm enabled: omitted The above type of errors repeat hundreds of times and eventually the display freezes (this box does not have a serial console and it did not check with ssh) When X started I did notice some corruption. There are sets of two rectangles about of a height of 2 or 3 mm, width of 25m or so with a second about a cm below. The often occurs in chomium especially when scrolling. Runing the unigine-sanctuary or unigine-tropics demo/benchmark programs also produce the above problems and eventually stall. The problem is reproducible - I am not that familiar with gpu problems though, what else will help debug this? Please file a bug at https://bugs.freedesktop.org (Product: DRI, Component: DRM/Radeon) and attach your dmesg output and xorg log. Filed as bug 75992 Let me know if you want me to test anything or if more info is needed. This still occurrs with rc7. With dpm enabled X is not usable. It stalls, sometimes with nasty screen corruption, after a few minute. With dpm disabled its much better (not perfect though). This has been solved via a firmware fix and a patch see: https://bugs.freedesktop.org/show_bug.cgi?id=75992 Ed Tomlinson -- 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: [BUG] 3.14-rc6 at mousedev_open_device+0x77/0x100
On Monday 10 March 2014 12:07:56 Ed Tomlinson wrote: This seems fixed by "[PATCH] Input: mousedev - fix race when creating mixed device" which is in 3.14 Thanks Ed > This happens every couple of boots with 3.14-rc kernels have not noticed it > with 3.13. Not really sure where else this should be sent... > > Mar 10 10:45:05 localhost kernel: [4.740750] BUG: unable to handle kernel > NULL pointer dereference at (null) > Mar 10 10:45:05 localhost kernel: [4.740845] IP: [] > mousedev_open_device+0x77/0x100 [mousedev] > Mar 10 10:45:05 localhost kernel: [4.740930] PGD 412cfa067 PUD 41881e067 > PMD 0 > Mar 10 10:45:05 localhost kernel: [4.740989] Oops: [#1] PREEMPT SMP > Mar 10 10:45:05 localhost kernel: [4.741043] Modules linked in: > mousedev(+) pl2303 usbserial btusb joydev hid_generic snd_usb_audio usbhid > snd_usbmidi_lib snd_ > rawmidi hid snd_seq_device zram nct6775 hwmon_vid radeon ttm btrfs > snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi raid6_pq xor > iTCO_wdt iTCO_vendor > _support x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm > crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel > aes_x86_64 lrw gf1 > 28mul glue_helper ablk_helper cryptd psmouse pcspkr i2c_i801 serio_raw > tpm_tis tpm i915 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm drm_kms_helper > mei_me snd_tim > er e1000e drm nuvoton_cir mei snd rc_core shpchp intel_gtt ptp i2c_algo_bit > pps_core soundcore lpc_ich evdev microcode ath3k bluetooth 6lowpan_iphc > rfkill gspca_pa > c7311 gspca_ov519 gspca_main videodev media i2c_core video acpi_power_meter > thermal processor pci chipreg mtd fan button battery acpi_pad acpi_ipmi > ipmi_msghandler > ext4 crc16 mbcache jbd2 usb_storage sd_mod crc_t10dif crct10dif_common atkbd > libps2 ahci libahci libata ehci_pci xhci_hcd ehci_hcd scsi_mod usbcore > usb_common i80 > 42 serio > Mar 10 10:45:05 localhost kernel: [4.742722] CPU: 4 PID: 338 Comm: acpid > Not tainted 3.14.0-1-mainline #1 > Mar 10 10:45:05 localhost kernel: [4.742822] Hardware name: To Be Filled > By O.E.M. To Be Filled By O.E.M./Z87E-ITX, BIOS P2.30 12/06/2013 > Mar 10 10:45:05 localhost kernel: [4.742916] task: 8804170889e0 ti: > 8800c280 task.ti: 8800c280 > Mar 10 10:45:05 localhost kernel: [4.743013] RIP: > 0010:[] [] > mousedev_open_device+0x77/0x100 [mousedev] > Mar 10 10:45:05 localhost kernel: [4.743015] RSP: 0018:8800c2801c10 > EFLAGS: 00010202 > Mar 10 10:45:05 localhost kernel: [4.743021] RAX: RBX: > 880404650800 RCX: 880404650868 > Mar 10 10:45:05 localhost kernel: [4.743023] RDX: RSI: > RDI: 0246 > Mar 10 10:45:05 localhost kernel: [4.743024] RBP: 8800c2801c28 R08: > R09: 88041e803600 > Mar 10 10:45:05 localhost kernel: [4.743025] R10: R11: > 0004 R12: > Mar 10 10:45:05 localhost kernel: [4.743027] R13: 880404650880 R14: > 88040a78f778 R15: 880417744c00 > Mar 10 10:45:05 localhost kernel: [4.743029] FS: 7f93d2f6c700() > GS:88042f30() knlGS: > Mar 10 10:45:05 localhost kernel: [4.743031] CS: 0010 DS: ES: > CR0: 80050033 > Mar 10 10:45:05 localhost kernel: [4.743032] CR2: CR3: > 000417542000 CR4: 001407e0 > Mar 10 10:45:05 localhost kernel: [4.743033] Stack: > Mar 10 10:45:05 localhost kernel: [4.743038] 880412de1c00 > 880404650800 880404650878 8800c2801c60 > Mar 10 10:45:05 localhost kernel: [4.743041] a02ef0cc > 880404650b48 88040a78f778 880417744c00 > Mar 10 10:45:05 localhost kernel: [4.743045] a02efe80 > 880417744c10 8800c2801c98 811b5e2f > Mar 10 10:45:05 localhost kernel: [4.743046] Call Trace: > Mar 10 10:45:05 localhost kernel: [4.743054] [] > mousedev_open+0xcc/0x150 [mousedev] > Mar 10 10:45:05 localhost kernel: [4.743061] [] > chrdev_open+0x9f/0x1d0 > Mar 10 10:45:05 localhost kernel: [4.743068] [] > do_dentry_open+0x1b7/0x2c0 > Mar 10 10:45:05 localhost kernel: [4.743073] [] ? > __inode_permission+0x41/0xb0 > Mar 10 10:45:05 localhost kernel: [4.743077] [] ? > cdev_put+0x30/0x30 > Mar 10 10:45:05 localhost kernel: [4.743081] [] > finish_open+0x31/0x40 > Mar 10 10:45:05 localhost kernel: [4.743086] [] > do_last+0x572/0xe90 > Mar 10 10:45:05 localhost kernel: [4.743091] [] ? > link_path_walk+0x236/0x8d0 > Mar 10 10:45:05 localhost kernel: [4.743097] [] > path_openat+0xbb/0x6
Re: [BUG] 3.14-rc6 at mousedev_open_device+0x77/0x100
On Monday 10 March 2014 12:07:56 Ed Tomlinson wrote: This seems fixed by [PATCH] Input: mousedev - fix race when creating mixed device which is in 3.14 Thanks Ed This happens every couple of boots with 3.14-rc kernels have not noticed it with 3.13. Not really sure where else this should be sent... Mar 10 10:45:05 localhost kernel: [4.740750] BUG: unable to handle kernel NULL pointer dereference at (null) Mar 10 10:45:05 localhost kernel: [4.740845] IP: [a02ee317] mousedev_open_device+0x77/0x100 [mousedev] Mar 10 10:45:05 localhost kernel: [4.740930] PGD 412cfa067 PUD 41881e067 PMD 0 Mar 10 10:45:05 localhost kernel: [4.740989] Oops: [#1] PREEMPT SMP Mar 10 10:45:05 localhost kernel: [4.741043] Modules linked in: mousedev(+) pl2303 usbserial btusb joydev hid_generic snd_usb_audio usbhid snd_usbmidi_lib snd_ rawmidi hid snd_seq_device zram nct6775 hwmon_vid radeon ttm btrfs snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi raid6_pq xor iTCO_wdt iTCO_vendor _support x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf1 28mul glue_helper ablk_helper cryptd psmouse pcspkr i2c_i801 serio_raw tpm_tis tpm i915 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm drm_kms_helper mei_me snd_tim er e1000e drm nuvoton_cir mei snd rc_core shpchp intel_gtt ptp i2c_algo_bit pps_core soundcore lpc_ich evdev microcode ath3k bluetooth 6lowpan_iphc rfkill gspca_pa c7311 gspca_ov519 gspca_main videodev media i2c_core video acpi_power_meter thermal processor pci chipreg mtd fan button battery acpi_pad acpi_ipmi ipmi_msghandler ext4 crc16 mbcache jbd2 usb_storage sd_mod crc_t10dif crct10dif_common atkbd libps2 ahci libahci libata ehci_pci xhci_hcd ehci_hcd scsi_mod usbcore usb_common i80 42 serio Mar 10 10:45:05 localhost kernel: [4.742722] CPU: 4 PID: 338 Comm: acpid Not tainted 3.14.0-1-mainline #1 Mar 10 10:45:05 localhost kernel: [4.742822] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z87E-ITX, BIOS P2.30 12/06/2013 Mar 10 10:45:05 localhost kernel: [4.742916] task: 8804170889e0 ti: 8800c280 task.ti: 8800c280 Mar 10 10:45:05 localhost kernel: [4.743013] RIP: 0010:[a02ee317] [a02ee317] mousedev_open_device+0x77/0x100 [mousedev] Mar 10 10:45:05 localhost kernel: [4.743015] RSP: 0018:8800c2801c10 EFLAGS: 00010202 Mar 10 10:45:05 localhost kernel: [4.743021] RAX: RBX: 880404650800 RCX: 880404650868 Mar 10 10:45:05 localhost kernel: [4.743023] RDX: RSI: RDI: 0246 Mar 10 10:45:05 localhost kernel: [4.743024] RBP: 8800c2801c28 R08: R09: 88041e803600 Mar 10 10:45:05 localhost kernel: [4.743025] R10: R11: 0004 R12: Mar 10 10:45:05 localhost kernel: [4.743027] R13: 880404650880 R14: 88040a78f778 R15: 880417744c00 Mar 10 10:45:05 localhost kernel: [4.743029] FS: 7f93d2f6c700() GS:88042f30() knlGS: Mar 10 10:45:05 localhost kernel: [4.743031] CS: 0010 DS: ES: CR0: 80050033 Mar 10 10:45:05 localhost kernel: [4.743032] CR2: CR3: 000417542000 CR4: 001407e0 Mar 10 10:45:05 localhost kernel: [4.743033] Stack: Mar 10 10:45:05 localhost kernel: [4.743038] 880412de1c00 880404650800 880404650878 8800c2801c60 Mar 10 10:45:05 localhost kernel: [4.743041] a02ef0cc 880404650b48 88040a78f778 880417744c00 Mar 10 10:45:05 localhost kernel: [4.743045] a02efe80 880417744c10 8800c2801c98 811b5e2f Mar 10 10:45:05 localhost kernel: [4.743046] Call Trace: Mar 10 10:45:05 localhost kernel: [4.743054] [a02ef0cc] mousedev_open+0xcc/0x150 [mousedev] Mar 10 10:45:05 localhost kernel: [4.743061] [811b5e2f] chrdev_open+0x9f/0x1d0 Mar 10 10:45:05 localhost kernel: [4.743068] [811af527] do_dentry_open+0x1b7/0x2c0 Mar 10 10:45:05 localhost kernel: [4.743073] [811bc7e1] ? __inode_permission+0x41/0xb0 Mar 10 10:45:05 localhost kernel: [4.743077] [811b5d90] ? cdev_put+0x30/0x30 Mar 10 10:45:05 localhost kernel: [4.743081] [811af941] finish_open+0x31/0x40 Mar 10 10:45:05 localhost kernel: [4.743086] [811bf612] do_last+0x572/0xe90 Mar 10 10:45:05 localhost kernel: [4.743091] [811bcad6] ? link_path_walk+0x236/0x8d0 Mar 10 10:45:05 localhost kernel: [4.743097] [811bffeb] path_openat+0xbb/0x6b0 Mar 10 10:45:05 localhost kernel: [4.743102] [811c16fa] do_filp_open+0x3a/0x90 Mar 10 10:45:05 localhost kernel: [4.743106
Re: [BUG] 3.14-rc6 problems with an R7 260X
On Monday 10 March 2014 13:29:41 Ed Tomlinson wrote: > On Monday 10 March 2014 12:38:42 Alex Deucher wrote: > > On Mon, Mar 10, 2014 at 11:47 AM, Ed Tomlinson wrote: > > > Hi, > > > > > > I recently added a R7 260X to my system. While the card works with 3.13 > > > its supposed work much better with 14-rc. > > > This is not the case. My system is unstable without radeon.dpm=0 which > > > was the default in .13. Here are some extracts > > > from the logs of the latest fun with dpm enabled: > > omitted > > > > The above type of errors repeat hundreds of times and eventually the > > > display freezes (this box does not have a serial console and it did not > > > check with ssh) > > > > > > When X started I did notice some corruption. There are sets of two > > > rectangles about of a height of 2 or 3 mm, width of 25m or so with a > > > second > > > about a cm below. The often occurs in chomium especially when scrolling. > > > Runing the unigine-sanctuary or unigine-tropics demo/benchmark > > > programs also produce the above problems and eventually stall. > > > > > > The problem is reproducible - I am not that familiar with gpu problems > > > though, what else will help debug this? > > > > > > > Please file a bug at https://bugs.freedesktop.org (Product: DRI, > > Component: DRM/Radeon) and attach your dmesg output and xorg log. > > Filed as bug 75992 > > Let me know if you want me to test anything or if more info is needed. This still occurrs with rc7. With dpm enabled X is not usable. It stalls, sometimes with nasty screen corruption, after a few minute. With dpm disabled its much better (not perfect though). Ed Tomlinson -- 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: [BUG] 3.14-rc6 problems with an R7 260X
On Monday 10 March 2014 13:29:41 Ed Tomlinson wrote: > On Monday 10 March 2014 12:38:42 Alex Deucher wrote: > > On Mon, Mar 10, 2014 at 11:47 AM, Ed Tomlinson wrote: > > > Hi, > > > > > > I recently added a R7 260X to my system. While the card works with 3.13 > > > its supposed work much better with 14-rc. > > > This is not the case. My system is unstable without radeon.dpm=0 which > > > was the default in .13. Here are some extracts > > > from the logs of the latest fun with dpm enabled: > > omitted > > > > The above type of errors repeat hundreds of times and eventually the > > > display freezes (this box does not have a serial console and it did not > > > check with ssh) > > > > > > When X started I did notice some corruption. There are sets of two > > > rectangles about of a height of 2 or 3 mm, width of 25m or so with a > > > second > > > about a cm below. The often occurs in chomium especially when scrolling. > > > Runing the unigine-sanctuary or unigine-tropics demo/benchmark > > > programs also produce the above problems and eventually stall. > > > > > > The problem is reproducible - I am not that familiar with gpu problems > > > though, what else will help debug this? > > > > > > > Please file a bug at https://bugs.freedesktop.org (Product: DRI, > > Component: DRM/Radeon) and attach your dmesg output and xorg log. > > Filed as bug 75992 > > Let me know if you want me to test anything or if more info is needed. This bug also occurs with rc7. My system is not useable when booted without radeon.dpm=0 - X stalls after a minute or two of use. Thanks Ed Tomlinson -- 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: [BUG] 3.14-rc6 problems with an R7 260X
On Monday 10 March 2014 13:29:41 Ed Tomlinson wrote: On Monday 10 March 2014 12:38:42 Alex Deucher wrote: On Mon, Mar 10, 2014 at 11:47 AM, Ed Tomlinson e...@aei.ca wrote: Hi, I recently added a R7 260X to my system. While the card works with 3.13 its supposed work much better with 14-rc. This is not the case. My system is unstable without radeon.dpm=0 which was the default in .13. Here are some extracts from the logs of the latest fun with dpm enabled: omitted The above type of errors repeat hundreds of times and eventually the display freezes (this box does not have a serial console and it did not check with ssh) When X started I did notice some corruption. There are sets of two rectangles about of a height of 2 or 3 mm, width of 25m or so with a second about a cm below. The often occurs in chomium especially when scrolling. Runing the unigine-sanctuary or unigine-tropics demo/benchmark programs also produce the above problems and eventually stall. The problem is reproducible - I am not that familiar with gpu problems though, what else will help debug this? Please file a bug at https://bugs.freedesktop.org (Product: DRI, Component: DRM/Radeon) and attach your dmesg output and xorg log. Filed as bug 75992 Let me know if you want me to test anything or if more info is needed. This bug also occurs with rc7. My system is not useable when booted without radeon.dpm=0 - X stalls after a minute or two of use. Thanks Ed Tomlinson -- 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: [BUG] 3.14-rc6 problems with an R7 260X
On Monday 10 March 2014 13:29:41 Ed Tomlinson wrote: On Monday 10 March 2014 12:38:42 Alex Deucher wrote: On Mon, Mar 10, 2014 at 11:47 AM, Ed Tomlinson e...@aei.ca wrote: Hi, I recently added a R7 260X to my system. While the card works with 3.13 its supposed work much better with 14-rc. This is not the case. My system is unstable without radeon.dpm=0 which was the default in .13. Here are some extracts from the logs of the latest fun with dpm enabled: omitted The above type of errors repeat hundreds of times and eventually the display freezes (this box does not have a serial console and it did not check with ssh) When X started I did notice some corruption. There are sets of two rectangles about of a height of 2 or 3 mm, width of 25m or so with a second about a cm below. The often occurs in chomium especially when scrolling. Runing the unigine-sanctuary or unigine-tropics demo/benchmark programs also produce the above problems and eventually stall. The problem is reproducible - I am not that familiar with gpu problems though, what else will help debug this? Please file a bug at https://bugs.freedesktop.org (Product: DRI, Component: DRM/Radeon) and attach your dmesg output and xorg log. Filed as bug 75992 Let me know if you want me to test anything or if more info is needed. This still occurrs with rc7. With dpm enabled X is not usable. It stalls, sometimes with nasty screen corruption, after a few minute. With dpm disabled its much better (not perfect though). Ed Tomlinson -- 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: [BUG] 3.14-rc6 problems with an R7 260X
On Monday 10 March 2014 12:38:42 Alex Deucher wrote: > On Mon, Mar 10, 2014 at 11:47 AM, Ed Tomlinson wrote: > > Hi, > > > > I recently added a R7 260X to my system. While the card works with 3.13 > > its supposed work much better with 14-rc. > > This is not the case. My system is unstable without radeon.dpm=0 which was > > the default in .13. Here are some extracts > > from the logs of the latest fun with dpm enabled: omitted > > The above type of errors repeat hundreds of times and eventually the > > display freezes (this box does not have a serial console and it did not > > check with ssh) > > > > When X started I did notice some corruption. There are sets of two > > rectangles about of a height of 2 or 3 mm, width of 25m or so with a second > > about a cm below. The often occurs in chomium especially when scrolling. > > Runing the unigine-sanctuary or unigine-tropics demo/benchmark > > programs also produce the above problems and eventually stall. > > > > The problem is reproducible - I am not that familiar with gpu problems > > though, what else will help debug this? > > > > Please file a bug at https://bugs.freedesktop.org (Product: DRI, > Component: DRM/Radeon) and attach your dmesg output and xorg log. Filed as bug 75992 Let me know if you want me to test anything or if more info is needed. TIA Ed -- 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/
[BUG] 3.14-rc6 at mousedev_open_device+0x77/0x100
85 c0 89 0a 75 c6 48 8b 05 37 1f 00 00 48 3d 60 Mar 10 10:45:05 localhost kernel: [4.743156] RIP [] mousedev_open_device+0x77/0x100 [mousedev] Mar 10 10:45:05 localhost kernel: [4.743157] RSP Mar 10 10:45:05 localhost kernel: [4.743158] CR2: Mar 10 10:45:05 localhost kernel: [4.743200] ---[ end trace 9ee5bcb02f264a08 ]--- The bug does not seem to hurt things much but... TIA Ed Tomlinson -- 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/
[BUG] 3.14-rc6 problems with an R7 260X
CTION_FAULT_STATUS 0x The above type of errors repeat hundreds of times and eventually the display freezes (this box does not have a serial console and it did not check with ssh) When X started I did notice some corruption. There are sets of two rectangles about of a height of 2 or 3 mm, width of 25m or so with a second about a cm below. The often occurs in chomium especially when scrolling. Runing the unigine-sanctuary or unigine-tropics demo/benchmark programs also produce the above problems and eventually stall. The problem is reproducible - I am not that familiar with gpu problems though, what else will help debug this? TIA Ed Tomlinson -- 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/
[BUG] 3.14-rc6 problems with an R7 260X
freezes (this box does not have a serial console and it did not check with ssh) When X started I did notice some corruption. There are sets of two rectangles about of a height of 2 or 3 mm, width of 25m or so with a second about a cm below. The often occurs in chomium especially when scrolling. Runing the unigine-sanctuary or unigine-tropics demo/benchmark programs also produce the above problems and eventually stall. The problem is reproducible - I am not that familiar with gpu problems though, what else will help debug this? TIA Ed Tomlinson -- 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/
[BUG] 3.14-rc6 at mousedev_open_device+0x77/0x100
: [4.743120] [8153702d] system_call_fastpath+0x1a/0x1f Mar 10 10:45:05 localhost kernel: [4.743151] Code: c0 f2 23 e1 5b 44 89 e0 41 5c 41 5d 5d c3 66 0f 1f 44 00 00 4c 89 ef 41 bc ed ff ff ff e8 a2 f2 23 e1 eb e0 48 8b 15 c9 21 00 00 8b 02 8d 48 01 85 c0 89 0a 75 c6 48 8b 05 37 1f 00 00 48 3d 60 Mar 10 10:45:05 localhost kernel: [4.743156] RIP [a02ee317] mousedev_open_device+0x77/0x100 [mousedev] Mar 10 10:45:05 localhost kernel: [4.743157] RSP 8800c2801c10 Mar 10 10:45:05 localhost kernel: [4.743158] CR2: Mar 10 10:45:05 localhost kernel: [4.743200] ---[ end trace 9ee5bcb02f264a08 ]--- The bug does not seem to hurt things much but... TIA Ed Tomlinson -- 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: [BUG] 3.14-rc6 problems with an R7 260X
On Monday 10 March 2014 12:38:42 Alex Deucher wrote: On Mon, Mar 10, 2014 at 11:47 AM, Ed Tomlinson e...@aei.ca wrote: Hi, I recently added a R7 260X to my system. While the card works with 3.13 its supposed work much better with 14-rc. This is not the case. My system is unstable without radeon.dpm=0 which was the default in .13. Here are some extracts from the logs of the latest fun with dpm enabled: omitted The above type of errors repeat hundreds of times and eventually the display freezes (this box does not have a serial console and it did not check with ssh) When X started I did notice some corruption. There are sets of two rectangles about of a height of 2 or 3 mm, width of 25m or so with a second about a cm below. The often occurs in chomium especially when scrolling. Runing the unigine-sanctuary or unigine-tropics demo/benchmark programs also produce the above problems and eventually stall. The problem is reproducible - I am not that familiar with gpu problems though, what else will help debug this? Please file a bug at https://bugs.freedesktop.org (Product: DRI, Component: DRM/Radeon) and attach your dmesg output and xorg log. Filed as bug 75992 Let me know if you want me to test anything or if more info is needed. TIA Ed -- 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/
2.6.24 Panic
Hi, Here is a trace back: This is grover.unknown_domain (Linux x86_64 2.6.24-gentoo-crc) 12:47:13 Booted with: kernel /boot/2.6.24-gentoo-crc root=/dev/sda3 vga=0x318 video=vesafb:ywrap,mtrr:3 console=tty0 console=ttyS0,38400 nmi_watchdog=2 idle=poll grover login: [ 75.987618] NMI Watchdog detected LOCKUP on CPU 0 [ 76.006096] CPU 0 [ 76.016515] Modules linked in: ipv6 af_packet rfcomm l2cap bluetooth snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device xfs usbhid pl2303 usbserial usbmouse ohci_hcd ehci_hcd video1394 w83627hf hwmon_vid i2c_nforce2 forcedeth sr_mod cdrom sbp2 parport_pc parport floppy rtc evdev ohci1394 radeonfb ieee1394 fb_ddc i2c_algo_bit i2c_core snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm thermal processor button snd_timer snd soundcore snd_page_alloc psmouse k8temp hwmon pcspkr unix [ 76.179223] Pid: 0, comm: swapper Not tainted 2.6.24-gentoo-crc #1 [ 76.202663] RIP: 0010:[] [] hrtimer_reprogram+0x0/0x50 [ 76.232721] RSP: 0018:805f7e90 EFLAGS: 0002 [ 76.253592] RAX: 805b6760 RBX: 81004efc5e98 RCX: 0001 [ 76.279968] RDX: 0001 RSI: 805b67b0 RDI: 8064ee80 [ 76.306300] RBP: 805f7ec8 R08: R09: [ 76.332666] R10: 0001 R11: 0001 R12: 8064ee80 [ 76.359053] R13: 81004efc5e88 R14: 805b67b0 R15: 805b67c0 [ 76.385438] FS: 2b69384386f0() GS:805ed000() knlGS: [ 76.414815] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b [ 76.437133] CR2: 2abdf10a8370 CR3: 4f9dd000 CR4: 06e0 [ 76.463733] DR0: DR1: DR2: [ 76.490267] DR3: DR6: 0ff0 DR7: 0400 [ 76.516749] Process swapper (pid: 0, threadinfo 805f6000, task 805ac360) [ 76.546119] Stack: 802464e7 805f7ec8 8064ee80 805b67b0 [ 76.575463] 0086 000c83273e02 805f7f08 [ 76.602941] 80246c85 00018020a7c0 fffedf4c 000c7d315d0c [ 76.624835] Call Trace: [ 76.642724] [] enqueue_hrtimer+0xa7/0x110 [ 76.664832] [] hrtimer_start+0x75/0x110 [ 76.686378] [] tick_nohz_stop_sched_tick+0x205/0x2b0 [ 76.711324] [] poll_idle+0x0/0x10 [ 76.731313] [] cpu_idle+0x2a/0x90 [ 76.751204] [] rest_init+0x69/0x70 [ 76.771262] [] start_kernel+0x25a/0x2a0 [ 76.792637] [] _sinittext+0x107/0x110 [ 76.813478] [ 76.822851] [ 76.822851] Code: 55 48 89 e5 53 48 83 ec 08 48 8b 5f 18 48 2b 5e 40 f6 47 30 [ 76.859658] ---[ end trace bbed4a3078ba58f5 ]--- [ 76.878661] Kernel panic - not syncing: Attempted to kill the idle task! If this is timer related, the kernel uses 'tsc' as a the clocksource 'acpi_pm' is also available. What else will help track this down to fix it? TIA, Ed Tomlinson -- 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.24 Panic
Hi, Here is a trace back: This is grover.unknown_domain (Linux x86_64 2.6.24-gentoo-crc) 12:47:13 Booted with: kernel /boot/2.6.24-gentoo-crc root=/dev/sda3 vga=0x318 video=vesafb:ywrap,mtrr:3 console=tty0 console=ttyS0,38400 nmi_watchdog=2 idle=poll grover login: [ 75.987618] NMI Watchdog detected LOCKUP on CPU 0 [ 76.006096] CPU 0 [ 76.016515] Modules linked in: ipv6 af_packet rfcomm l2cap bluetooth snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device xfs usbhid pl2303 usbserial usbmouse ohci_hcd ehci_hcd video1394 w83627hf hwmon_vid i2c_nforce2 forcedeth sr_mod cdrom sbp2 parport_pc parport floppy rtc evdev ohci1394 radeonfb ieee1394 fb_ddc i2c_algo_bit i2c_core snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm thermal processor button snd_timer snd soundcore snd_page_alloc psmouse k8temp hwmon pcspkr unix [ 76.179223] Pid: 0, comm: swapper Not tainted 2.6.24-gentoo-crc #1 [ 76.202663] RIP: 0010:[802462c0] [802462c0] hrtimer_reprogram+0x0/0x50 [ 76.232721] RSP: 0018:805f7e90 EFLAGS: 0002 [ 76.253592] RAX: 805b6760 RBX: 81004efc5e98 RCX: 0001 [ 76.279968] RDX: 0001 RSI: 805b67b0 RDI: 8064ee80 [ 76.306300] RBP: 805f7ec8 R08: R09: [ 76.332666] R10: 0001 R11: 0001 R12: 8064ee80 [ 76.359053] R13: 81004efc5e88 R14: 805b67b0 R15: 805b67c0 [ 76.385438] FS: 2b69384386f0() GS:805ed000() knlGS: [ 76.414815] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b [ 76.437133] CR2: 2abdf10a8370 CR3: 4f9dd000 CR4: 06e0 [ 76.463733] DR0: DR1: DR2: [ 76.490267] DR3: DR6: 0ff0 DR7: 0400 [ 76.516749] Process swapper (pid: 0, threadinfo 805f6000, task 805ac360) [ 76.546119] Stack: 802464e7 805f7ec8 8064ee80 805b67b0 [ 76.575463] 0086 000c83273e02 805f7f08 [ 76.602941] 80246c85 00018020a7c0 fffedf4c 000c7d315d0c [ 76.624835] Call Trace: [ 76.642724] [802464e7] enqueue_hrtimer+0xa7/0x110 [ 76.664832] [80246c85] hrtimer_start+0x75/0x110 [ 76.686378] [8024d215] tick_nohz_stop_sched_tick+0x205/0x2b0 [ 76.711324] [8020a7c0] poll_idle+0x0/0x10 [ 76.731313] [8020a88a] cpu_idle+0x2a/0x90 [ 76.751204] [8047ef79] rest_init+0x69/0x70 [ 76.771262] [805f9aaa] start_kernel+0x25a/0x2a0 [ 76.792637] [805f9107] _sinittext+0x107/0x110 [ 76.813478] [ 76.822851] [ 76.822851] Code: 55 48 89 e5 53 48 83 ec 08 48 8b 5f 18 48 2b 5e 40 f6 47 30 [ 76.859658] ---[ end trace bbed4a3078ba58f5 ]--- [ 76.878661] Kernel panic - not syncing: Attempted to kill the idle task! If this is timer related, the kernel uses 'tsc' as a the clocksource 'acpi_pm' is also available. What else will help track this down to fix it? TIA, Ed Tomlinson -- 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: Fwd: laptop / computer hardlocks during execution of 32bit applications(binaries) on 64bit system (Gentoo)
On January 15, 2008, Ingo Molnar wrote: > > * Ed Tomlinson <[EMAIL PROTECTED]> wrote: > > > This is _not_ a regression. This has been occuring for ages here. A > > backport of this fix to 2.6.23 would be a very good thing - IMHO its > > something that should go into stable asap. > > the problem is that this bug was only present in x86.git. I.e. neither > 2.6.24 nor 2.6.23 has this particular bug. > > perhaps something else in x86.git fixed your box, but this > x86.git-specific hang 'took over its place', and now that it got fixed, > you've got a working box? In any case, please monitor your box, it might > still lock up the same way it did previously ... I am now testing with a .24-rc7+fix kernel. So far so good. Running gentoo's 32 bit firefox with flash 9 is a good way to trigger the problem here as is running Delftship (freeship) under wine. The problem is usually worst with a fully preemptive kernel. I have been using both on a kernel with preempt and have an uptime of 22 hours - this is really good. I have rarely been able to get this much uptime using these apps. If it manages to run for a few more days without a lockup it would really be worth trying to figure out what in .24 fixes the problem... THANKS! Ed Tomlinson -- 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: Fwd: laptop / computer hardlocks during execution of 32bit applications(binaries) on 64bit system (Gentoo)
On January 15, 2008, Ingo Molnar wrote: * Ed Tomlinson [EMAIL PROTECTED] wrote: This is _not_ a regression. This has been occuring for ages here. A backport of this fix to 2.6.23 would be a very good thing - IMHO its something that should go into stable asap. the problem is that this bug was only present in x86.git. I.e. neither 2.6.24 nor 2.6.23 has this particular bug. perhaps something else in x86.git fixed your box, but this x86.git-specific hang 'took over its place', and now that it got fixed, you've got a working box? In any case, please monitor your box, it might still lock up the same way it did previously ... I am now testing with a .24-rc7+fix kernel. So far so good. Running gentoo's 32 bit firefox with flash 9 is a good way to trigger the problem here as is running Delftship (freeship) under wine. The problem is usually worst with a fully preemptive kernel. I have been using both on a kernel with preempt and have an uptime of 22 hours - this is really good. I have rarely been able to get this much uptime using these apps. If it manages to run for a few more days without a lockup it would really be worth trying to figure out what in .24 fixes the problem... THANKS! Ed Tomlinson -- 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: Fwd: laptop / computer hardlocks during execution of 32bit applications(binaries) on 64bit system (Gentoo)
On January 14, 2008, Ingo Molnar wrote: > > * Matthew <[EMAIL PROTECTED]> wrote: > > > > FYI, latest x86.git should have this fix included. So if your box > > > still hangs there must be some other bug lurking as well. > > > > > > the fix from Roland ?: http://lkml.org/lkml/2008/1/11/108 > > http://forums.gentoo.org/viewtopic-p-4719206.html#4719206 (+ following > > posts) > > > > works like a charm :) > > wine-problems should be solved, > > > > 64bit firefox & 32bit flash, 32bit firefox, 32bit thunderbird, > > realplayer work fine again without hardlocking so far (at least for > > me) > > great - thanks for following through with this, this was an important > regression to get fixed! I've added: > > Tested-by: Matthew <[EMAIL PROTECTED]> Ingo, This is _not_ a regression. This has been occuring for ages here. A backport of this fix to 2.6.23 would be a very good thing - IMHO its something that should go into stable asap. Thanks, Ed Tomlinson -- 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: Fwd: laptop / computer hardlocks during execution of 32bit applications(binaries) on 64bit system (Gentoo)
On January 14, 2008, Ingo Molnar wrote: * Matthew [EMAIL PROTECTED] wrote: FYI, latest x86.git should have this fix included. So if your box still hangs there must be some other bug lurking as well. the fix from Roland ?: http://lkml.org/lkml/2008/1/11/108 http://forums.gentoo.org/viewtopic-p-4719206.html#4719206 (+ following posts) works like a charm :) wine-problems should be solved, 64bit firefox 32bit flash, 32bit firefox, 32bit thunderbird, realplayer work fine again without hardlocking so far (at least for me) great - thanks for following through with this, this was an important regression to get fixed! I've added: Tested-by: Matthew [EMAIL PROTECTED] Ingo, This is _not_ a regression. This has been occuring for ages here. A backport of this fix to 2.6.23 would be a very good thing - IMHO its something that should go into stable asap. Thanks, Ed Tomlinson -- 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: Fwd: laptop / computer hardlocks during execution of 32bit applications(binaries) on 64bit system (Gentoo)
>> - if yes, does booting with "nmi_watchdog=2 idle=poll" give you a >> working NMI watchdog? (working NMI watchdog means the NMI counts >> increase for all cores in /proc/interrupts). > booting with the above gives me an incrementing NMI counter in > /proc/interrupts Ingo, Is there anything else that needs to be set in the kernel config for the nmi watchdog to trigger? I ask because I just had a hang but nothing showed on the _serial_ console - I waited a couple of minutes before rebooting Is there any other way to verify the watchdog is working? I seem to need X active with mix of 32 and 64 bit applications active to get hung here. A massivily threaded 64 bit java app along with 32 bit firefox and a wine active will eventually trigger things here. If I had to guess I would say that it the switch from 32 to 64 (or vise versa) that triggers the isuue. TIA & test/debug patches welcome, Ed Tomlinson -- 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: Fwd: laptop / computer hardlocks during execution of 32bit applications(binaries) on 64bit system (Gentoo)
On January 10, 2008, Ingo Molnar wrote: > > * Ed Tomlinson <[EMAIL PROTECTED]> wrote: > > > Matthew is not alone with this problem. I have it too. Its not new > > here. Its been happening as long as I have had gentoo amd64 > > installed. It can be hard to reproduce but eventually, when 32 bit > > apps are used, my box bricks. There is nothing in the logs (nor on a > > serial console) - the box just freezes. > > > > My kernel is _not_ tainted. [...] > > ok, good. A series of questions: > > - can you reproduce it from the VGA console? No - though I do have a serial console to see logs. > - if yes, does booting with "nmi_watchdog=2 idle=poll" give you a > working NMI watchdog? (working NMI watchdog means the NMI counts > increase for all cores in /proc/interrupts). booting with the above gives me an incrementing NMI counter in /proc/interrupts > if still 'yes', then try to reproduce the hard hang on the VGA text > console - do you perhaps get an NMI backtrace printed within 1-2 minutes > after the hard hang happens? If yes then take a photo of that or write > it down. I am booted with the NMI watchdog and serial consoles active running apps that eventually will trigger a hang... Ed Tomlinson -- 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: Fwd: laptop / computer hardlocks during execution of 32bit applications(binaries) on 64bit system (Gentoo)
On January 10, 2008, Ingo Molnar wrote: > > * Matthew <[EMAIL PROTECTED]> wrote: > > > this also happens with rc7-based kernels, btw > > hm, exactly what rc7 based kernel? Vanilla 2.6.24-rc7, built by you? Or > any patches ontop of it? (x86.git perhaps?) Matthew is not alone with this problem. I have it too. Its not new here. Its been happening as long as I have had gentoo amd64 installed. It can be hard to reproduce but eventually, when 32 bit apps are used, my box bricks. There is nothing in the logs (nor on a serial console) - the box just freezes. My kernel is _not_ tainted. The kernel is currently 2.6.23-gentoo-r5-crc with the latest cfs backport applied; it does not seem to be critical though as it has happen with all kernels I have tried (mm, linux and gentoo varients). The processor is: processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 4 model name : AMD Athlon(tm) 64 Processor 2800+ stepping: 10 cpu MHz : 1808.802 cache size : 512 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow rep_good bogomips: 3620.77 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp I asked about this lkml before and was told it was probably a cpu/hardware issue... Its interesting that Matthew is also running gentoo. Thanks, Ed Tomlinson -- 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: Fwd: laptop / computer hardlocks during execution of 32bit applications(binaries) on 64bit system (Gentoo)
On January 10, 2008, Ingo Molnar wrote: * Matthew [EMAIL PROTECTED] wrote: this also happens with rc7-based kernels, btw hm, exactly what rc7 based kernel? Vanilla 2.6.24-rc7, built by you? Or any patches ontop of it? (x86.git perhaps?) Matthew is not alone with this problem. I have it too. Its not new here. Its been happening as long as I have had gentoo amd64 installed. It can be hard to reproduce but eventually, when 32 bit apps are used, my box bricks. There is nothing in the logs (nor on a serial console) - the box just freezes. My kernel is _not_ tainted. The kernel is currently 2.6.23-gentoo-r5-crc with the latest cfs backport applied; it does not seem to be critical though as it has happen with all kernels I have tried (mm, linux and gentoo varients). The processor is: processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 4 model name : AMD Athlon(tm) 64 Processor 2800+ stepping: 10 cpu MHz : 1808.802 cache size : 512 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow rep_good bogomips: 3620.77 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp I asked about this lkml before and was told it was probably a cpu/hardware issue... Its interesting that Matthew is also running gentoo. Thanks, Ed Tomlinson -- 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: Fwd: laptop / computer hardlocks during execution of 32bit applications(binaries) on 64bit system (Gentoo)
On January 10, 2008, Ingo Molnar wrote: * Ed Tomlinson [EMAIL PROTECTED] wrote: Matthew is not alone with this problem. I have it too. Its not new here. Its been happening as long as I have had gentoo amd64 installed. It can be hard to reproduce but eventually, when 32 bit apps are used, my box bricks. There is nothing in the logs (nor on a serial console) - the box just freezes. My kernel is _not_ tainted. [...] ok, good. A series of questions: - can you reproduce it from the VGA console? No - though I do have a serial console to see logs. - if yes, does booting with nmi_watchdog=2 idle=poll give you a working NMI watchdog? (working NMI watchdog means the NMI counts increase for all cores in /proc/interrupts). booting with the above gives me an incrementing NMI counter in /proc/interrupts if still 'yes', then try to reproduce the hard hang on the VGA text console - do you perhaps get an NMI backtrace printed within 1-2 minutes after the hard hang happens? If yes then take a photo of that or write it down. I am booted with the NMI watchdog and serial consoles active running apps that eventually will trigger a hang... Ed Tomlinson -- 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: Fwd: laptop / computer hardlocks during execution of 32bit applications(binaries) on 64bit system (Gentoo)
- if yes, does booting with nmi_watchdog=2 idle=poll give you a working NMI watchdog? (working NMI watchdog means the NMI counts increase for all cores in /proc/interrupts). booting with the above gives me an incrementing NMI counter in /proc/interrupts Ingo, Is there anything else that needs to be set in the kernel config for the nmi watchdog to trigger? I ask because I just had a hang but nothing showed on the _serial_ console - I waited a couple of minutes before rebooting Is there any other way to verify the watchdog is working? I seem to need X active with mix of 32 and 64 bit applications active to get hung here. A massivily threaded 64 bit java app along with 32 bit firefox and a wine active will eventually trigger things here. If I had to guess I would say that it the switch from 32 to 64 (or vise versa) that triggers the isuue. TIA test/debug patches welcome, Ed Tomlinson -- 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: Scheduler benchmarks - a follow-up
Rob, I gather this was with the complete -ck patchset? It would be interesting to see if just SD performed as well. If it does, CFS needs more work. if not there are other things in -ck that really do improve performance and should be looked into. Thanks Ed Tomlinson On September 17, 2007, Rob Hussey wrote: > Hi all, > > After posting some benchmarks involving cfs > (http://lkml.org/lkml/2007/9/13/385), I got some feedback, so I > decided to do a follow-up that'll hopefully fill in the gaps many > people wanted to see filled. > > This time around I've done the benchmarks against 2.6.21, 2.6.22-ck1, > and 2.6.23-rc6-cfs-devel (latest git as of 12 hours ago). All three > .configs are attached. The benchmarks consist of lat_ctx and > hackbench, both with a growing number of processes, as well as > pipe-test. All benchmarks were also run bound to a single core. > > Since this time there are hundreds of lines of data, I'll post a > reasonable amount here and attach the data files. There are graphs > again this time, which I'll post links to as well as attach. > > I'll start with some selected numbers, which are preceded by the > command used for the benchmark. > > for((i=2; i < 201; i++)); do lat_ctx -s 0 $i; done: > (the left most column is the number of processes ($i)) > > 2.6.21 2.6.22-ck1 2.6.23-rc6-cfs-devel > > 155.884.855.14 > 165.804.774.76 > 175.914.844.92 > 185.794.864.83 > 195.894.944.93 > 205.784.815.13 > 215.885.024.94 > 225.794.794.84 > 235.934.865.05 > 245.734.764.90 > 256.004.945.19 > > for((i=1; i < 100; i++)); do hackbench $i; done: > > 2.6.21 2.6.22-ck1 2.6.23-rc6-cfs-devel > > 809.75 8.959.52 > 8111.54 8.879.57 > 8211.29 8.929.67 > 8310.76 8.969.82 > 8412.04 9.209.91 > 8511.74 9.3910.09 > 8612.01 9.3710.18 > 8711.39 9.4310.13 > 8812.48 9.6010.38 > 8911.85 9.7710.52 > 9013.78 9.7610.65 > > pipe-test: > (the left most column is the run #) > > 2.6.21 2.6.22-ck1 2.6.23-rc6-cfs-devel > > 1 13.84 12.59 13.01 > 2 13.90 12.57 13.00 > 3 13.84 12.62 13.06 > 4 13.87 12.61 13.04 > 5 13.82 12.62 13.03 > 6 13.86 12.60 13.02 > 7 13.85 12.61 13.02 > 8 13.88 12.45 13.04 > 9 13.83 12.46 13.03 > 1013.88 12.46 13.03 > > Bound to Single core: > > for((i=2; i < 201; i++)); do lat_ctx -s 0 $i; done: > > 2.6.21 2.6.22-ck1 2.6.23-rc6-cfs-devel > > 152.902.762.21 > 162.882.792.36 > 172.872.772.52 > 182.862.782.66 > 192.892.722.81 > 202.872.722.95 > 212.862.693.10 > 222.882.723.26 > 232.862.713.39 > 242.842.723.56 > 252.822.733.72 > > > for((i=1; i < 100; i++)); do hackbench $i; done: > > 2.6.21 2.6.22-ck1 2.6.23-rc6-cfs-devel > > 8014.29 10.86 12.03 > 8114.40 11.25 12.17 > 8215.00 11.42 12.33 > 8314.87 11.12 12.51 > 8415.37 11.42 12.66 > 8515.75 11.68 12.79 > 8615.64 11.95 12.95 > 8715.80 11.64 13.12 > 8815.70 11.91 13.25 > 8915.10 12.19 13.42 > 9016.24 12.53 13.54 > > pipe-test: > > 2.6.21 2.6.22-ck1 2.6.23-rc6-cfs-devel > > 1 9.278.508.55 > 2 9.278.478.55 > 3 9.288.478.54 > 4 9.288
Re: Scheduler benchmarks - a follow-up
Rob, I gather this was with the complete -ck patchset? It would be interesting to see if just SD performed as well. If it does, CFS needs more work. if not there are other things in -ck that really do improve performance and should be looked into. Thanks Ed Tomlinson On September 17, 2007, Rob Hussey wrote: Hi all, After posting some benchmarks involving cfs (http://lkml.org/lkml/2007/9/13/385), I got some feedback, so I decided to do a follow-up that'll hopefully fill in the gaps many people wanted to see filled. This time around I've done the benchmarks against 2.6.21, 2.6.22-ck1, and 2.6.23-rc6-cfs-devel (latest git as of 12 hours ago). All three .configs are attached. The benchmarks consist of lat_ctx and hackbench, both with a growing number of processes, as well as pipe-test. All benchmarks were also run bound to a single core. Since this time there are hundreds of lines of data, I'll post a reasonable amount here and attach the data files. There are graphs again this time, which I'll post links to as well as attach. I'll start with some selected numbers, which are preceded by the command used for the benchmark. for((i=2; i 201; i++)); do lat_ctx -s 0 $i; done: (the left most column is the number of processes ($i)) 2.6.21 2.6.22-ck1 2.6.23-rc6-cfs-devel 155.884.855.14 165.804.774.76 175.914.844.92 185.794.864.83 195.894.944.93 205.784.815.13 215.885.024.94 225.794.794.84 235.934.865.05 245.734.764.90 256.004.945.19 for((i=1; i 100; i++)); do hackbench $i; done: 2.6.21 2.6.22-ck1 2.6.23-rc6-cfs-devel 809.75 8.959.52 8111.54 8.879.57 8211.29 8.929.67 8310.76 8.969.82 8412.04 9.209.91 8511.74 9.3910.09 8612.01 9.3710.18 8711.39 9.4310.13 8812.48 9.6010.38 8911.85 9.7710.52 9013.78 9.7610.65 pipe-test: (the left most column is the run #) 2.6.21 2.6.22-ck1 2.6.23-rc6-cfs-devel 1 13.84 12.59 13.01 2 13.90 12.57 13.00 3 13.84 12.62 13.06 4 13.87 12.61 13.04 5 13.82 12.62 13.03 6 13.86 12.60 13.02 7 13.85 12.61 13.02 8 13.88 12.45 13.04 9 13.83 12.46 13.03 1013.88 12.46 13.03 Bound to Single core: for((i=2; i 201; i++)); do lat_ctx -s 0 $i; done: 2.6.21 2.6.22-ck1 2.6.23-rc6-cfs-devel 152.902.762.21 162.882.792.36 172.872.772.52 182.862.782.66 192.892.722.81 202.872.722.95 212.862.693.10 222.882.723.26 232.862.713.39 242.842.723.56 252.822.733.72 for((i=1; i 100; i++)); do hackbench $i; done: 2.6.21 2.6.22-ck1 2.6.23-rc6-cfs-devel 8014.29 10.86 12.03 8114.40 11.25 12.17 8215.00 11.42 12.33 8314.87 11.12 12.51 8415.37 11.42 12.66 8515.75 11.68 12.79 8615.64 11.95 12.95 8715.80 11.64 13.12 8815.70 11.91 13.25 8915.10 12.19 13.42 9016.24 12.53 13.54 pipe-test: 2.6.21 2.6.22-ck1 2.6.23-rc6-cfs-devel 1 9.278.508.55 2 9.278.478.55 3 9.288.478.54 4 9.288.488.54 5 9.288.488.54 6 9.298.468.54 7 9.288.478.55 8 9.298.478.55 9 9.298.458.54 109.288.468.54 Links to the graphs (the .dat files are in the same directory): http://www.healthcarelinen.com/misc/benchmarks/lat_ctx_benchmark2.png http://www.healthcarelinen.com/misc/benchmarks/hackbench_benchmark2.png http
Re: [patch] CFS scheduler, -v19
On Monday 16 July 2007 05:17, Ingo Molnar wrote: > > * Ed Tomlinson <[EMAIL PROTECTED]> wrote: > > > I run a java application at nice 15. Its been a background > > application here for as long as SD and CFS have been around. If I > > have a compile running at nice 0, with v19 java gets so little cpu > > that the the wrapper that runs to monitor it is timing out waiting for > > it to start. This is new in v19 - something in v19 is not meshing > > well with my mix of applications... > > how much longer did the startup of the java app get relative to say v18? > > to debug this, could you check whether this problem goes away if you use > nice 10 (or nice 5) instead of nice 15? Ingo, It may take a day to two before I get to test this. I have had to revert to 2.6.21 - it seems that 22 triggers a stall here (21 also can trigger this but its harder)... Thanks Ed - 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] CFS scheduler, -v19
On Monday 16 July 2007 05:17, Ingo Molnar wrote: * Ed Tomlinson [EMAIL PROTECTED] wrote: I run a java application at nice 15. Its been a background application here for as long as SD and CFS have been around. If I have a compile running at nice 0, with v19 java gets so little cpu that the the wrapper that runs to monitor it is timing out waiting for it to start. This is new in v19 - something in v19 is not meshing well with my mix of applications... how much longer did the startup of the java app get relative to say v18? to debug this, could you check whether this problem goes away if you use nice 10 (or nice 5) instead of nice 15? Ingo, It may take a day to two before I get to test this. I have had to revert to 2.6.21 - it seems that 22 triggers a stall here (21 also can trigger this but its harder)... Thanks Ed - 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] CFS scheduler, -v19
Hi, I run a java application at nice 15. Its been a background application here for as long as SD and CFS have been around. If I have a compile running at nice 0, with v19 java gets so little cpu that the the wrapper that runs to monitor it is timing out waiting for it to start. This is new in v19 - something in v19 is not meshing well with my mix of applications... Kernel is gentoo 2.6.22-r1 + cfs v19 How can I help to debug this? Ed Tomlinson On Friday 06 July 2007 13:33, Ingo Molnar wrote: > i'm pleased to announce release -v19 of the CFS scheduler patchset. > > The rolled-up CFS patch against today's -git kernel, v2.6.22-rc7, > v2.6.22-rc6-mm1, v2.6.21.5 or v2.6.20.14 can be downloaded from the > usual place: > > http://people.redhat.com/mingo/cfs-scheduler/ > > The biggest user-visible change in -v19 is reworked sleeper fairness: > it's similar in behavior to -v18 but works more consistently across nice > levels. Fork-happy workloads (like kernel builds) should behave better > as well. There are also a handful of speedups: unsigned math, 32-bit > speedups, O(1) task pickup, debloating and other micro-optimizations. - 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] CFS scheduler, -v19
Hi, I run a java application at nice 15. Its been a background application here for as long as SD and CFS have been around. If I have a compile running at nice 0, with v19 java gets so little cpu that the the wrapper that runs to monitor it is timing out waiting for it to start. This is new in v19 - something in v19 is not meshing well with my mix of applications... Kernel is gentoo 2.6.22-r1 + cfs v19 How can I help to debug this? Ed Tomlinson On Friday 06 July 2007 13:33, Ingo Molnar wrote: i'm pleased to announce release -v19 of the CFS scheduler patchset. The rolled-up CFS patch against today's -git kernel, v2.6.22-rc7, v2.6.22-rc6-mm1, v2.6.21.5 or v2.6.20.14 can be downloaded from the usual place: http://people.redhat.com/mingo/cfs-scheduler/ The biggest user-visible change in -v19 is reworked sleeper fairness: it's similar in behavior to -v18 but works more consistently across nice levels. Fork-happy workloads (like kernel builds) should behave better as well. There are also a handful of speedups: unsigned math, 32-bit speedups, O(1) task pickup, debloating and other micro-optimizations. - 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: [RFC PATCH 0/5 v2] Convert all tasklets to workqueues V2
Hi, Applied this to 2.6.21-5 along with an older version of dyntick and cfs v18, durring boot I got: [ 54.154077] hci_usb_isoc_rx_submit: hci0 isoc rx submit failed urb 81004ec55628 err -38 [ 54.154086] hci_usb_isoc_rx_submit: hci0 isoc rx submit failed urb 81004ec55628 err -38 [ 54.168147] BUG: at kernel/mutex.c:132 __mutex_lock_common() [ 54.170801] [ 54.170802] Call Trace: [ 54.175975] [] check_preempt_curr_fair+0x70/0x90 [ 54.178694] [] __mutex_lock_slowpath+0x6f/0x200 [ 54.181417] [] mutex_lock+0x19/0x20 [ 54.184165] [] flush_workqueue+0x31/0x50 [ 54.186975] [] tasklet_disable+0x15/0x20 [ 54.189829] [] :bluetooth:hci_cc_host_ctl+0x17f/0x240 [ 54.192767] [] :bluetooth:hci_event_packet+0x139c/0x1560 [ 54.195712] [] :bluetooth:hci_send_to_sock+0x134/0x180 [ 54.198657] [] :bluetooth:hci_rx_task+0x9f/0x270 [ 54.201588] [] work_tasklet_exec+0x0/0x50 [ 54.204473] [] work_tasklet_exec+0x3c/0x50 [ 54.207282] [] run_workqueue+0x94/0x130 [ 54.210032] [] worker_thread+0x149/0x190 [ 54.212781] [] default_wake_function+0x0/0x10 [ 54.215539] [] worker_thread+0x0/0x190 [ 54.218241] [] kthread+0xd3/0x110 [ 54.220880] [] child_rip+0xa/0x12 [ 54.223484] [] kthread+0x0/0x110 [ 54.226075] [] child_rip+0x0/0x12 Has this patch uncovered a problem in bluetooth or is it a problem with the patch? TIA, Ed Tomlinson On Friday 22 June 2007 14:20, Steven Rostedt wrote: > -- > > This is version 2 of the tasklet to workqueue conversion. > > Changes from version 1. > > - removed config option and simply replace the old implementation > with the work queue one (recommended by Ingo Molnar). > > - replaced clear_bit with test_and_clear_bit to avoid the race of > executing the tasklet function twice. (thanks to Oleg Nesterov > for pointing that out). > > - Removed most of the pr_debug prints. (Kept one) > (recommended by Ingo Molnar) > > - Removed call to softirq_init. > > - Added Author credit to Dipankar Sarma for the RCU tasklet to > softirq conversion. > > - Tested on my Powerbook to add another arch to the mix :-) > Funny that booting with this change was the first time that > the bcm43xx didn't get stuck for several seconds on bootup. > It's also one of the few drivers that use tasklet_disable_nosync. > So either this shows that the change fixed something, or that > it broke something (or was just a fluke). > > > -- Steve > > - > 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/ > > - 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: [RFC PATCH 0/5 v2] Convert all tasklets to workqueues V2
Hi, Applied this to 2.6.21-5 along with an older version of dyntick and cfs v18, durring boot I got: [ 54.154077] hci_usb_isoc_rx_submit: hci0 isoc rx submit failed urb 81004ec55628 err -38 [ 54.154086] hci_usb_isoc_rx_submit: hci0 isoc rx submit failed urb 81004ec55628 err -38 [ 54.168147] BUG: at kernel/mutex.c:132 __mutex_lock_common() [ 54.170801] [ 54.170802] Call Trace: [ 54.175975] [801790a0] check_preempt_curr_fair+0x70/0x90 [ 54.178694] [8015b11f] __mutex_lock_slowpath+0x6f/0x200 [ 54.181417] [8015b2c9] mutex_lock+0x19/0x20 [ 54.184165] [80185c01] flush_workqueue+0x31/0x50 [ 54.186975] [80190e75] tasklet_disable+0x15/0x20 [ 54.189829] [8815289f] :bluetooth:hci_cc_host_ctl+0x17f/0x240 [ 54.192767] [88153e4c] :bluetooth:hci_event_packet+0x139c/0x1560 [ 54.195712] [88154d24] :bluetooth:hci_send_to_sock+0x134/0x180 [ 54.198657] [8815073f] :bluetooth:hci_rx_task+0x9f/0x270 [ 54.201588] [80190df0] work_tasklet_exec+0x0/0x50 [ 54.204473] [80190e2c] work_tasklet_exec+0x3c/0x50 [ 54.207282] [801488d4] run_workqueue+0x94/0x130 [ 54.210032] [80145c59] worker_thread+0x149/0x190 [ 54.212781] [80177430] default_wake_function+0x0/0x10 [ 54.215539] [80145b10] worker_thread+0x0/0x190 [ 54.218241] [801300f3] kthread+0xd3/0x110 [ 54.220880] [801581c8] child_rip+0xa/0x12 [ 54.223484] [80130020] kthread+0x0/0x110 [ 54.226075] [801581be] child_rip+0x0/0x12 Has this patch uncovered a problem in bluetooth or is it a problem with the patch? TIA, Ed Tomlinson On Friday 22 June 2007 14:20, Steven Rostedt wrote: -- This is version 2 of the tasklet to workqueue conversion. Changes from version 1. - removed config option and simply replace the old implementation with the work queue one (recommended by Ingo Molnar). - replaced clear_bit with test_and_clear_bit to avoid the race of executing the tasklet function twice. (thanks to Oleg Nesterov for pointing that out). - Removed most of the pr_debug prints. (Kept one) (recommended by Ingo Molnar) - Removed call to softirq_init. - Added Author credit to Dipankar Sarma for the RCU tasklet to softirq conversion. - Tested on my Powerbook to add another arch to the mix :-) Funny that booting with this change was the first time that the bcm43xx didn't get stuck for several seconds on bootup. It's also one of the few drivers that use tasklet_disable_nosync. So either this shows that the change fixed something, or that it broke something (or was just a fluke). -- Steve - 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/ - 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: [REPORT] First "glitch1" results, 2.6.21-rc7-git6-CFSv5 + SD 0.46
On Thursday 26 April 2007 18:56, Con Kolivas wrote: > On Friday 27 April 2007 08:00, Bill Davidsen wrote: > > Ingo Molnar wrote: > > > * Ed Tomlinson <[EMAIL PROTECTED]> wrote: > > >>> SD 0.46 1-2 FPS > > >>> cfs v5 nice -19 219-233 FPS > > >>> cfs v5 nice 0 1000-1996 > > >> > > >>cfs v5 nice -10 60-65 FPS > > > > > > the problem is, the glxgears portion of this test is an _inverse_ > > > testcase. > > > > > > The reason? glxgears on true 3D hardware will _not_ use X, it will > > > directly use the 3D driver of the kernel. So by renicing X to -19 you > > > give the xterms more chance to show stuff - the performance of the > > > glxgears will 'degrade' - but that is what you asked for: glxgears is > > > 'just another CPU hog' that competes with X, it's not a "true" X client. > > > > > > if you are after glxgears performance in this test then you'll get the > > > best performance out of this by renicing X to +19 or even SCHED_BATCH. > > > > Several points on this... > > > > First, I don't think this is accelerated in the way you mean, the > > machine is a test server, with motherboard video using the 945G video > > driver. Given the limitations of the support in that setup, I don't > > think it qualified as "true 3D hardware," although I guess I could try > > using the vesafb version as a test. > > > > The 2nd thing I note is that on FC6 this scheduler seems to confuse > > 'top' to some degree, since the glxgears is shown as taking 51% of the > > CPU (one core), while the state breakdown shows about 73% in idle, > > waitio, and int. image attached. > > top by itself certainly cannot be trusted to give true representation of the > cpu usage I'm afraid. It's not as convoluted as, say, trying to track memory > usage of an application, but top's resolution being tied to HZ accounting > makes it not reliable in that regard. > > > > After I upgrade the kernel and cfs to the absolute latest I'll repeat > > this, as well as test with vesafb, and my planned run under heavy load. > > I have a problem with your test case Bill. Its behaviour would depend on how > gpu bound vs cpu bound vs accelerated vs non-accelerated your graphics card > is. I get completely different results to those of the other testers given > the different hardware configuration and I don't think my results are > valuable. My problem with this testcase is - What would you define > as "perfect" behaviour for your test case? It seems far too arbitrary. Con, One thing I did not mention in all this is that renicing the glxgears process to -10 gets SD to give about 1000FPS, indeed you get most of this performance at -5 too. All in all SD does a very good job here. Get well soon! Ed - 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: [REPORT] First glitch1 results, 2.6.21-rc7-git6-CFSv5 + SD 0.46
On Thursday 26 April 2007 18:56, Con Kolivas wrote: On Friday 27 April 2007 08:00, Bill Davidsen wrote: Ingo Molnar wrote: * Ed Tomlinson [EMAIL PROTECTED] wrote: SD 0.46 1-2 FPS cfs v5 nice -19 219-233 FPS cfs v5 nice 0 1000-1996 cfs v5 nice -10 60-65 FPS the problem is, the glxgears portion of this test is an _inverse_ testcase. The reason? glxgears on true 3D hardware will _not_ use X, it will directly use the 3D driver of the kernel. So by renicing X to -19 you give the xterms more chance to show stuff - the performance of the glxgears will 'degrade' - but that is what you asked for: glxgears is 'just another CPU hog' that competes with X, it's not a true X client. if you are after glxgears performance in this test then you'll get the best performance out of this by renicing X to +19 or even SCHED_BATCH. Several points on this... First, I don't think this is accelerated in the way you mean, the machine is a test server, with motherboard video using the 945G video driver. Given the limitations of the support in that setup, I don't think it qualified as true 3D hardware, although I guess I could try using the vesafb version as a test. The 2nd thing I note is that on FC6 this scheduler seems to confuse 'top' to some degree, since the glxgears is shown as taking 51% of the CPU (one core), while the state breakdown shows about 73% in idle, waitio, and int. image attached. top by itself certainly cannot be trusted to give true representation of the cpu usage I'm afraid. It's not as convoluted as, say, trying to track memory usage of an application, but top's resolution being tied to HZ accounting makes it not reliable in that regard. After I upgrade the kernel and cfs to the absolute latest I'll repeat this, as well as test with vesafb, and my planned run under heavy load. I have a problem with your test case Bill. Its behaviour would depend on how gpu bound vs cpu bound vs accelerated vs non-accelerated your graphics card is. I get completely different results to those of the other testers given the different hardware configuration and I don't think my results are valuable. My problem with this testcase is - What would you define as perfect behaviour for your test case? It seems far too arbitrary. Con, One thing I did not mention in all this is that renicing the glxgears process to -10 gets SD to give about 1000FPS, indeed you get most of this performance at -5 too. All in all SD does a very good job here. Get well soon! Ed - 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: [RFC] another scheduler beater
On Tuesday 24 April 2007 04:17, Ingo Molnar wrote: > > * Bill Davidsen <[EMAIL PROTECTED]> wrote: > > > The small attached script does a nice job of showing animation > > glitches in the glxgears animation. I have run one set of tests, and > > will have several more tomorrow. I'm off to a poker game, and would > > like to let people draw their own conclusions. > > > > Based on just this script as load I would say renice on X isn't a good > > thing. Based on one small test, I would say that renice of X in > > conjunction with heavy disk i/o and a single fast scrolling xterm > > (think kernel compile) seems to slow the raid6 thread measurably. > > Results late tomorrow, it will be an early and long day :-( > > hm, i'm wondering what you would expect the scheduler to do here? > > for this particular test you'll get the best result by renicing X to > +19! Why? Because, as far as i can see this is a partially 'inverted' > test of X's scheduling. > > While the script is definitely useful (you taught me that nice xterm > -geom trick to automate the placing of busy xterms :), some caveats do > apply when interpreting the results: > > If you have a kernel 3D driver (which you seem to have, judging by the > glxgears numbers you are getting) then running 'glxgears' wont involve X > at all. glxgears just gets its own window and then the kernel driver > draws straight into it, without any side-trips to X. You can see this > for yourself by starting glitch1.sh from an ssh terminal, and then > _totally stop_ the X server via "kill -STOP 12345" - all the xterms will > stop, the X desktop freezes, but the glxgears instance will still > happily draw its stuff and wheels are happily turning on the screen. > > So in this sense glxgears is a 'CPU hog' workload, largely independent > of X. > > now, by renicing X to -10 and running the xterms you'll definitely hurt > "CPU hogs" - even if it happens to be a glxgears process that draws 3D > graphics in a window provided by X. But this is precisely what is > supposed to happen in this case. You should get the best glxgears > performance by renicing X to _+19_, and that seems to be happening > according to your numbers - and that's what happens in my own testing > too. I Ingo, This turns out to be only part of the story. There are two scroll options for the glitch1 script. With 'jump' scrolling I get: cfs v5 jump-19 500 FPS cfs v5 jump-10 500 FPS cfs v5 jump-5 150 FPS cfs v5 jump0 25 FPS cfs v5 1 line -19 230 FPS cfs v5 1 line -10 195 FPS cfs v5 1 line -5 720 FPS cfs v5 1 line 0 970 FPS cfs v5 1 line 10 430 FPS sd 0.46 1 line -19 0.5 FPS sd 0.46 1 line -10 0.8 FPS sd 0.46 1 line 0 2.3 FPS sd 0.46 1 line 10 93 FPS sd 0.46 1 line 19 93 FPS sd 0.46 jump is basically the same as the 1 line case. glxgears alone gets about 1500 FPS So in one case nice -10 gives us the worst performance. In the other case, where you predicted nice 19 would get the best numbers nice 0 does... Nor does the SD scheduler produce the results predicted. Thanks, Ed Tomlinson (2.6.20.7 gentoo, amd64 UP HZ=300, voluntary preempt, radeon 9200 agp with in kernel drivers) - 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: [RFC] another scheduler beater
On Tuesday 24 April 2007 04:17, Ingo Molnar wrote: * Bill Davidsen [EMAIL PROTECTED] wrote: The small attached script does a nice job of showing animation glitches in the glxgears animation. I have run one set of tests, and will have several more tomorrow. I'm off to a poker game, and would like to let people draw their own conclusions. Based on just this script as load I would say renice on X isn't a good thing. Based on one small test, I would say that renice of X in conjunction with heavy disk i/o and a single fast scrolling xterm (think kernel compile) seems to slow the raid6 thread measurably. Results late tomorrow, it will be an early and long day :-( hm, i'm wondering what you would expect the scheduler to do here? for this particular test you'll get the best result by renicing X to +19! Why? Because, as far as i can see this is a partially 'inverted' test of X's scheduling. While the script is definitely useful (you taught me that nice xterm -geom trick to automate the placing of busy xterms :), some caveats do apply when interpreting the results: If you have a kernel 3D driver (which you seem to have, judging by the glxgears numbers you are getting) then running 'glxgears' wont involve X at all. glxgears just gets its own window and then the kernel driver draws straight into it, without any side-trips to X. You can see this for yourself by starting glitch1.sh from an ssh terminal, and then _totally stop_ the X server via kill -STOP 12345 - all the xterms will stop, the X desktop freezes, but the glxgears instance will still happily draw its stuff and wheels are happily turning on the screen. So in this sense glxgears is a 'CPU hog' workload, largely independent of X. now, by renicing X to -10 and running the xterms you'll definitely hurt CPU hogs - even if it happens to be a glxgears process that draws 3D graphics in a window provided by X. But this is precisely what is supposed to happen in this case. You should get the best glxgears performance by renicing X to _+19_, and that seems to be happening according to your numbers - and that's what happens in my own testing too. I Ingo, This turns out to be only part of the story. There are two scroll options for the glitch1 script. With 'jump' scrolling I get: cfs v5 jump-19 500 FPS cfs v5 jump-10 500 FPS cfs v5 jump-5 150 FPS cfs v5 jump0 25 FPS cfs v5 1 line -19 230 FPS cfs v5 1 line -10 195 FPS cfs v5 1 line -5 720 FPS cfs v5 1 line 0 970 FPS cfs v5 1 line 10 430 FPS sd 0.46 1 line -19 0.5 FPS sd 0.46 1 line -10 0.8 FPS sd 0.46 1 line 0 2.3 FPS sd 0.46 1 line 10 93 FPS sd 0.46 1 line 19 93 FPS sd 0.46 jump is basically the same as the 1 line case. glxgears alone gets about 1500 FPS So in one case nice -10 gives us the worst performance. In the other case, where you predicted nice 19 would get the best numbers nice 0 does... Nor does the SD scheduler produce the results predicted. Thanks, Ed Tomlinson (2.6.20.7 gentoo, amd64 UP HZ=300, voluntary preempt, radeon 9200 agp with in kernel drivers) - 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: [REPORT] First "glitch1" results, 2.6.21-rc7-git6-CFSv5 + SD 0.46
On Monday 23 April 2007 19:45, Ed Tomlinson wrote: > On Monday 23 April 2007 17:57, Bill Davidsen wrote: > > I am not sure a binary attachment will go thru, I will move to the web > > ste if not. > > I did a quick try of this script here. > > With SD 0.46 with X at nice 0 I was getting 1-2 frames per second. I decided > to try cfs v5. > The option disable auto renicing did not work so many threads other than X > are now at -19... > > SD 0.46 1-2 FPS > cfs v5 nice -19 219-233 FPS > cfs v5 nice 0 1000-1996 cfs v5 nice -10 60-65 FPS > > Looks like, in this case, nice -19 for X is NOT a good idea. > > Kernel is 2.6.20.7 (gentoo) UP amd64 with HZ 300 voluntary prempt (a fully > premptable kernel eventually > locks up switching between 32 and 64 apps) Thanks Ed - 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: [REPORT] First "glitch1" results, 2.6.21-rc7-git6-CFSv5 + SD 0.46
On Monday 23 April 2007 17:57, Bill Davidsen wrote: > I am not sure a binary attachment will go thru, I will move to the web > ste if not. I did a quick try of this script here. With SD 0.46 with X at nice 0 I was getting 1-2 frames per second. I decided to try cfs v5. The option disable auto renicing did not work so many threads other than X are now at -19... SD 0.46 1-2 FPS cfs v5 nice -19 219-233 FPS cfs v5 nice 0 1000-1996 Looks like, in this case, nice -19 for X is NOT a good idea. Kernel is 2.6.20.7 (gentoo) UP amd64 with HZ 300 voluntary prempt (a fully premptable kernel eventually locks up switching between 32 and 64 apps) Thanks, Ed Tomlinson - 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: [REPORT] First glitch1 results, 2.6.21-rc7-git6-CFSv5 + SD 0.46
On Monday 23 April 2007 17:57, Bill Davidsen wrote: I am not sure a binary attachment will go thru, I will move to the web ste if not. I did a quick try of this script here. With SD 0.46 with X at nice 0 I was getting 1-2 frames per second. I decided to try cfs v5. The option disable auto renicing did not work so many threads other than X are now at -19... SD 0.46 1-2 FPS cfs v5 nice -19 219-233 FPS cfs v5 nice 0 1000-1996 Looks like, in this case, nice -19 for X is NOT a good idea. Kernel is 2.6.20.7 (gentoo) UP amd64 with HZ 300 voluntary prempt (a fully premptable kernel eventually locks up switching between 32 and 64 apps) Thanks, Ed Tomlinson - 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: [REPORT] First glitch1 results, 2.6.21-rc7-git6-CFSv5 + SD 0.46
On Monday 23 April 2007 19:45, Ed Tomlinson wrote: On Monday 23 April 2007 17:57, Bill Davidsen wrote: I am not sure a binary attachment will go thru, I will move to the web ste if not. I did a quick try of this script here. With SD 0.46 with X at nice 0 I was getting 1-2 frames per second. I decided to try cfs v5. The option disable auto renicing did not work so many threads other than X are now at -19... SD 0.46 1-2 FPS cfs v5 nice -19 219-233 FPS cfs v5 nice 0 1000-1996 cfs v5 nice -10 60-65 FPS Looks like, in this case, nice -19 for X is NOT a good idea. Kernel is 2.6.20.7 (gentoo) UP amd64 with HZ 300 voluntary prempt (a fully premptable kernel eventually locks up switching between 32 and 64 apps) Thanks Ed - 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: Renice X for cpu schedulers
On Thursday 19 April 2007 12:15, Mark Lord wrote: > Con Kolivas wrote: > > On Thursday 19 April 2007 23:17, Mark Lord wrote: > >> Con Kolivas wrote: > >> s go ahead and think up great ideas for other ways of metering out cpu > >> > >>> bandwidth for different purposes, but for X, given the absurd simplicity > >>> of renicing, why keep fighting it? Again I reiterate that most users of > >>> SD have not found the need to renice X anyway except if they stick to old > >>> habits of make -j4 on uniprocessor and the like, and I expect that those > >>> on CFS and Nicksched would also have similar experiences. > >> Just plain "make" (no -j2 or -j) is enough to kill interactivity > >> on my 2GHz P-M single-core non-HT machine with SD. > >> > >> But with the very first posted version of CFS by Ingo, > >> I can do "make -j2" no problem and still have a nicely interactive destop. > > > > Cool. Then there's clearly a bug with SD that manifests on your machine as > > it > > should not have that effect at all (and doesn't on other people's > > machines). > > I suggest trying the latest version which fixes some bugs. > > SD just doesn't do nearly as good as the stock scheduler, or CFS, here. > > I'm quite likely one of the few single-CPU/non-HT testers of this stuff. > If it should ever get more widely used I think we'd hear a lot more > complaints. amd64 UP here. SD with several makes running works just fine. Ed Tomlinson - 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: Renice X for cpu schedulers
On Thursday 19 April 2007 12:15, Mark Lord wrote: Con Kolivas wrote: On Thursday 19 April 2007 23:17, Mark Lord wrote: Con Kolivas wrote: s go ahead and think up great ideas for other ways of metering out cpu bandwidth for different purposes, but for X, given the absurd simplicity of renicing, why keep fighting it? Again I reiterate that most users of SD have not found the need to renice X anyway except if they stick to old habits of make -j4 on uniprocessor and the like, and I expect that those on CFS and Nicksched would also have similar experiences. Just plain make (no -j2 or -j) is enough to kill interactivity on my 2GHz P-M single-core non-HT machine with SD. But with the very first posted version of CFS by Ingo, I can do make -j2 no problem and still have a nicely interactive destop. Cool. Then there's clearly a bug with SD that manifests on your machine as it should not have that effect at all (and doesn't on other people's machines). I suggest trying the latest version which fixes some bugs. SD just doesn't do nearly as good as the stock scheduler, or CFS, here. I'm quite likely one of the few single-CPU/non-HT testers of this stuff. If it should ever get more widely used I think we'd hear a lot more complaints. amd64 UP here. SD with several makes running works just fine. Ed Tomlinson - 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: Ten percent test
On Monday 09 April 2007 22:39, Mike Galbraith wrote: > On Mon, 2007-04-09 at 07:38 +0200, Mike Galbraith wrote: > > > I don't think you can have very much effect on latency using nice with > > SD once the CPU is fully utilized. See below. > > > > /* > > * This contains a bitmap for each dynamic priority level with empty slots > > * for the valid priorities each different nice level can have. It allows > > * us to stagger the slots where differing priorities run in a way that > > * keeps latency differences between different nice levels at a minimum. > > * ie, where 0 means a slot for that priority, priority running from left to > > * right: > > * nice -20 > > * nice -10 1001000100100010001001000100010010001000 > > * nice 0 0101010101010101010101010101010101010101 > > * nice 5 1101011010110101101011010110101101011011 > > * nice 10 0110111011011101110110111011101101110111 > > * nice 15 0101101101011011 > > * nice 19 1110 > > */ > > > > Nice allocates bandwidth, but as long as the CPU is busy, tasks always > > proceed downward in priority until they hit the expired array. That's > > the design. > > There's another aspect of this that may require some thought - kernel > threads. As load increases, so does rotation length. Would you really > want CPU hogs routinely preempting house-keepers under load? SD has a schedule batch nice level. This is good for tasks that want lots of cpu when they can get it. If you overload your cpu I expect the box to slow down - including kernel threads. If really required they can be started with a higher priority... Ed - 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: Ten percent test
On Monday 09 April 2007 22:39, Mike Galbraith wrote: On Mon, 2007-04-09 at 07:38 +0200, Mike Galbraith wrote: I don't think you can have very much effect on latency using nice with SD once the CPU is fully utilized. See below. /* * This contains a bitmap for each dynamic priority level with empty slots * for the valid priorities each different nice level can have. It allows * us to stagger the slots where differing priorities run in a way that * keeps latency differences between different nice levels at a minimum. * ie, where 0 means a slot for that priority, priority running from left to * right: * nice -20 * nice -10 1001000100100010001001000100010010001000 * nice 0 0101010101010101010101010101010101010101 * nice 5 1101011010110101101011010110101101011011 * nice 10 0110111011011101110110111011101101110111 * nice 15 0101101101011011 * nice 19 1110 */ Nice allocates bandwidth, but as long as the CPU is busy, tasks always proceed downward in priority until they hit the expired array. That's the design. There's another aspect of this that may require some thought - kernel threads. As load increases, so does rotation length. Would you really want CPU hogs routinely preempting house-keepers under load? SD has a schedule batch nice level. This is good for tasks that want lots of cpu when they can get it. If you overload your cpu I expect the box to slow down - including kernel threads. If really required they can be started with a higher priority... Ed - 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: Ten percent test
On Monday 09 April 2007 01:38, Mike Galbraith wrote: > On Sun, 2007-04-08 at 09:08 -0400, Ed Tomlinson wrote: > > Hi, > > > > I am one of those who have been happily testing Con's patches. > > > > They work better than mainline here. > > (I tried a UP kernel yesterday, and even a single kernel build would > make noticeable hitches if I move a window around. YMMV etc.) Interesting. I run UP amd64, 1000HZ, 1.25G, preempt off (on causes kernel stalls with no messages - but that is another story). I do not notice a single make. When several are running the desktop slows down a bit. I do not have X niced. Wonder why we see such different results? I am not saying that SD is perfect - I fully expect that more bugs will turn up in its code (some will affect mainline too). I do however like the idea of a scheduler that does not need alchemy to achieve good results. Nor do I necessarily expect it to be 100% transparent. If one changes something as basic as the scheduler some tweaking should be expected. IMO this is fine as long as we get consistant results. > > If one really needs some sort of interactivity booster (I do not with SD), > > why > > not move it into user space? With SD it would be simple enough to export > > some info on estimated latency. With this user space could make a good > > attempt to keep latency within bounds for a set of tasks just by > > renicing > > I don't think you can have very much effect on latency using nice with > SD once the CPU is fully utilized. See below. > > /* > * This contains a bitmap for each dynamic priority level with empty slots > * for the valid priorities each different nice level can have. It allows > * us to stagger the slots where differing priorities run in a way that > * keeps latency differences between different nice levels at a minimum. > * ie, where 0 means a slot for that priority, priority running from left to > * right: > * nice -20 > * nice -10 1001000100100010001001000100010010001000 > * nice 0 0101010101010101010101010101010101010101 > * nice 5 1101011010110101101011010110101101011011 > * nice 10 0110111011011101110110111011101101110111 > * nice 15 0101101101011011 > * nice 19 1110 > */ > > Nice allocates bandwidth, but as long as the CPU is busy, tasks always > proceed downward in priority until they hit the expired array. That's > the design. If X gets busy and expires, and a nice 20 CPU hog wakes up > after it's previous rotation has ended, but before the current rotation > is ended (ie there is 1 task running at wakeup time), X will take a > guaranteed minimum 160ms latency hit (quite noticeable) independent of > nice level. The only way to avoid it is to use a realtime class. > > A nice -20 task has maximum bandwidth allocated, but that also makes it > a bigger target for preemption from tasks at all nice levels as it > proceeds downward toward expiration. AFAIKT, low latency scheduling > just isn't possible once the CPU becomes 100% utilized, but it is > bounded to runqueue length. In mainline OTOH, a nice -20 task will > always preempt a nice 0 task, giving it instant gratification, and > latency of lower priority tasks is bounded by the EXPIRED_STARVING(rq) > safety net. Mike I made no mention of low latency. I did mention predictable latency. If you are 100% utilized, and have a nice -20 task cpu hog, I would expect it to run and that it _should_ affect other tasks - thats why it runs with -20... This is why I suggest that user space may be a better place to boost interactive tasks. A daemon that posted a message telling me that the nice -20 cpu hog is causing 300ms delays for X would, IMHO, be a good thing. That same daemon could then propose a fix telling me the expected latencies and let me decide if I want to change priorities. It could also be set to automaticily adjust nice levels... Thanks Ed - 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: Ten percent test
On Monday 09 April 2007 01:38, Mike Galbraith wrote: On Sun, 2007-04-08 at 09:08 -0400, Ed Tomlinson wrote: Hi, I am one of those who have been happily testing Con's patches. They work better than mainline here. (I tried a UP kernel yesterday, and even a single kernel build would make noticeable hitches if I move a window around. YMMV etc.) Interesting. I run UP amd64, 1000HZ, 1.25G, preempt off (on causes kernel stalls with no messages - but that is another story). I do not notice a single make. When several are running the desktop slows down a bit. I do not have X niced. Wonder why we see such different results? I am not saying that SD is perfect - I fully expect that more bugs will turn up in its code (some will affect mainline too). I do however like the idea of a scheduler that does not need alchemy to achieve good results. Nor do I necessarily expect it to be 100% transparent. If one changes something as basic as the scheduler some tweaking should be expected. IMO this is fine as long as we get consistant results. If one really needs some sort of interactivity booster (I do not with SD), why not move it into user space? With SD it would be simple enough to export some info on estimated latency. With this user space could make a good attempt to keep latency within bounds for a set of tasks just by renicing I don't think you can have very much effect on latency using nice with SD once the CPU is fully utilized. See below. /* * This contains a bitmap for each dynamic priority level with empty slots * for the valid priorities each different nice level can have. It allows * us to stagger the slots where differing priorities run in a way that * keeps latency differences between different nice levels at a minimum. * ie, where 0 means a slot for that priority, priority running from left to * right: * nice -20 * nice -10 1001000100100010001001000100010010001000 * nice 0 0101010101010101010101010101010101010101 * nice 5 1101011010110101101011010110101101011011 * nice 10 0110111011011101110110111011101101110111 * nice 15 0101101101011011 * nice 19 1110 */ Nice allocates bandwidth, but as long as the CPU is busy, tasks always proceed downward in priority until they hit the expired array. That's the design. If X gets busy and expires, and a nice 20 CPU hog wakes up after it's previous rotation has ended, but before the current rotation is ended (ie there is 1 task running at wakeup time), X will take a guaranteed minimum 160ms latency hit (quite noticeable) independent of nice level. The only way to avoid it is to use a realtime class. A nice -20 task has maximum bandwidth allocated, but that also makes it a bigger target for preemption from tasks at all nice levels as it proceeds downward toward expiration. AFAIKT, low latency scheduling just isn't possible once the CPU becomes 100% utilized, but it is bounded to runqueue length. In mainline OTOH, a nice -20 task will always preempt a nice 0 task, giving it instant gratification, and latency of lower priority tasks is bounded by the EXPIRED_STARVING(rq) safety net. Mike I made no mention of low latency. I did mention predictable latency. If you are 100% utilized, and have a nice -20 task cpu hog, I would expect it to run and that it _should_ affect other tasks - thats why it runs with -20... This is why I suggest that user space may be a better place to boost interactive tasks. A daemon that posted a message telling me that the nice -20 cpu hog is causing 300ms delays for X would, IMHO, be a good thing. That same daemon could then propose a fix telling me the expected latencies and let me decide if I want to change priorities. It could also be set to automaticily adjust nice levels... Thanks Ed - 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: Ten percent test
Hi, I am one of those who have been happily testing Con's patches. They work better than mainline here. There seems to be a disconnect on what Con is trying to achieve with SD. They do not improve interactivity per say. Instead they make the scheduler predictable by removing the alchemy used by the interactivity estimator. Mikes patches may be better alchemy but they continue down the same path - from prior experience, we can say with fairly good confidence, that there will be new corner cases that trigger problems. With SD, if you ask too much of the machine it slows down. You can fix this, if required, by renicing tasks some tasks - or by reducing the load on the box. If one really needs some sort of interactivity booster (I do not with SD), why not move it into user space? With SD it would be simple enough to export some info on estimated latency. With this user space could make a good attempt to keep latency within bounds for a set of tasks just by renicing Thanks Ed Tomlinson PS. Get well soon Con. On Saturday 07 April 2007 02:50, Con Kolivas wrote: > On Friday 06 April 2007 20:03, Ingo Molnar wrote: > > * Con Kolivas <[EMAIL PROTECTED]> wrote: > > > > I was more focused on the general case, but all I should have to do > > > > to de-claw all of these sleep exploits is account rr time (only a > > > > couple of lines, done and building now). It's only a couple of > > > > lines. > > > > > > The more you try to "de-claw" these sleep exploits the less effective > > > you make your precious interactive estimator. Feel free to keep adding > > > endless tweaks to undo the other tweaks in order to try and achieve > > > what SD has by design. > > > > firstly, testing on various workloads Mike's tweaks work pretty well, > > while SD still doesnt handle the high-load case all that well. Note that > > it was you who raised this whole issue to begin with: everything was > > pretty quiet in scheduling interactivity land. > > I'm terribly sorry but you have completely missed my intentions then. I was > _not_ trying to improve mainline's interactivity at all. My desire was to fix > the unfairness that mainline has, across the board without compromising > fairness. You said yourself that an approach that fixed a lot and had a small > number of regressions would be worth it. In a surprisingly ironic turnaround > two bizarre things happened. People found SD fixed a lot of their > interactivity corner cases which were showstoppers. That didn't surprise me > because any unfair design will by its nature get it wrong sometimes. The even > _more_ surprising thing is that you're now using interactivity as the > argument against SD. I did not set out to create better interactivity, I set > out to create widespread fairness without too much compromise to > interactivity. As I said from the _very first email_, there would be cases of > interactivity in mainline that performed better. > > > (There was one person who > > reported wide-scale interactivity regressions against mainline but he > > didnt answer my followup posts to trace/debug the scenario.) > > That was one user. As I mentioned in an earlier thread, the problem with > email > threads on drawn out issues on lkml is that all that people remember is the > last one creating noise, and that has only been the noise from Mike for 2 > weeks now. Has everyone forgotten the many many users who reported the > advantages first up which generated the interest in the first place? Why have > they stopped reporting? Well the answer is obvious; all the signs suggest > that SD is slated for mainline. It is on the path, Linus has suggested it and > now akpm is asking if it's ready for 2.6.22. So they figure there is no point > testing and replying any further. SD is ready for prime time, finalised and > does everything I intended it to. This is where I have to reveal to them the > horrible truth. This is no guarantee it will go in. In fact, this one point > that you (Ingo) go on and on about is not only a quibble, but you will call > it an absolute showstopper. As maintainer of the cpu scheduler, in its > current form you will flatly refuse it goes to mainline citing the 5% of > cases where interactivity has regressed. So people will tell me to fix it, > right?... Read on for this to unfold. > > > SD has a built-in "interactivity estimator" as well, but hardcoded into > > its design. SD has its own set of ugly-looking tweaks as well - for > > example the prio_matrix. > > I'm sorry but this is a mis-representation to me, as I suggested on an > earlier > thread where I disagree about what an interactivity estimator is. The
Re: Ten percent test
Hi, I am one of those who have been happily testing Con's patches. They work better than mainline here. There seems to be a disconnect on what Con is trying to achieve with SD. They do not improve interactivity per say. Instead they make the scheduler predictable by removing the alchemy used by the interactivity estimator. Mikes patches may be better alchemy but they continue down the same path - from prior experience, we can say with fairly good confidence, that there will be new corner cases that trigger problems. With SD, if you ask too much of the machine it slows down. You can fix this, if required, by renicing tasks some tasks - or by reducing the load on the box. If one really needs some sort of interactivity booster (I do not with SD), why not move it into user space? With SD it would be simple enough to export some info on estimated latency. With this user space could make a good attempt to keep latency within bounds for a set of tasks just by renicing Thanks Ed Tomlinson PS. Get well soon Con. On Saturday 07 April 2007 02:50, Con Kolivas wrote: On Friday 06 April 2007 20:03, Ingo Molnar wrote: * Con Kolivas [EMAIL PROTECTED] wrote: I was more focused on the general case, but all I should have to do to de-claw all of these sleep exploits is account rr time (only a couple of lines, done and building now). It's only a couple of lines. The more you try to de-claw these sleep exploits the less effective you make your precious interactive estimator. Feel free to keep adding endless tweaks to undo the other tweaks in order to try and achieve what SD has by design. firstly, testing on various workloads Mike's tweaks work pretty well, while SD still doesnt handle the high-load case all that well. Note that it was you who raised this whole issue to begin with: everything was pretty quiet in scheduling interactivity land. I'm terribly sorry but you have completely missed my intentions then. I was _not_ trying to improve mainline's interactivity at all. My desire was to fix the unfairness that mainline has, across the board without compromising fairness. You said yourself that an approach that fixed a lot and had a small number of regressions would be worth it. In a surprisingly ironic turnaround two bizarre things happened. People found SD fixed a lot of their interactivity corner cases which were showstoppers. That didn't surprise me because any unfair design will by its nature get it wrong sometimes. The even _more_ surprising thing is that you're now using interactivity as the argument against SD. I did not set out to create better interactivity, I set out to create widespread fairness without too much compromise to interactivity. As I said from the _very first email_, there would be cases of interactivity in mainline that performed better. (There was one person who reported wide-scale interactivity regressions against mainline but he didnt answer my followup posts to trace/debug the scenario.) That was one user. As I mentioned in an earlier thread, the problem with email threads on drawn out issues on lkml is that all that people remember is the last one creating noise, and that has only been the noise from Mike for 2 weeks now. Has everyone forgotten the many many users who reported the advantages first up which generated the interest in the first place? Why have they stopped reporting? Well the answer is obvious; all the signs suggest that SD is slated for mainline. It is on the path, Linus has suggested it and now akpm is asking if it's ready for 2.6.22. So they figure there is no point testing and replying any further. SD is ready for prime time, finalised and does everything I intended it to. This is where I have to reveal to them the horrible truth. This is no guarantee it will go in. In fact, this one point that you (Ingo) go on and on about is not only a quibble, but you will call it an absolute showstopper. As maintainer of the cpu scheduler, in its current form you will flatly refuse it goes to mainline citing the 5% of cases where interactivity has regressed. So people will tell me to fix it, right?... Read on for this to unfold. SD has a built-in interactivity estimator as well, but hardcoded into its design. SD has its own set of ugly-looking tweaks as well - for example the prio_matrix. I'm sorry but this is a mis-representation to me, as I suggested on an earlier thread where I disagree about what an interactivity estimator is. The idea of fence posts in a clock that are passed as a way of metering out earliest-deadline-first in a design is well established. The matrix is simply an array designed for O(1) lookups of the fence posts. That is not the same as oh how much have we slept in the last $magic_number period and how much extra time should we get for that. So it all comes down on 'what interactivity heuristics
