https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
Alexey Dokuchaev changed:
What|Removed |Added
Resolution|--- |FIXED
Status|In Pro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #28 from Jan Kokemüller ---
This can be closed for sure. It's been a long time, but I think this was fixed
in base. Most of the relevant DRM bits now live out of base, anyway.
--
You are receiving this mail because:
You are th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
Alexey Dokuchaev changed:
What|Removed |Added
Status|New |In Progress
CC|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #26 from wolfg...@lyxys.ka.sub.org ---
I have now removed the patch from #11 from my source tree; I do no longer see
the problem with 10.2-Stable r291408
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
Max Brazhnikov changed:
What|Removed |Added
CC||m...@freebsd.org
--- Comment #25
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #24 from wolfg...@lyxys.ka.sub.org ---
(In reply to wolfgang from comment #23)
patch from #11 applied cleanly to 10.1-STABLE r282622 and fixes problem on T500
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
wolfg...@lyxys.ka.sub.org changed:
What|Removed |Added
CC||wolfg...@lyxys.ka.sub.or
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #22 from Adrian Chadd ---
... just to be clear:
* kib's opregion + zero'ing GMBUS4 patch didn't work
* jan's patch in comment #11 works
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #21 from Adrian Chadd ---
(In reply to Jan Kokemüller from comment #11)
This also works for me, on my GM45 mobile chipset.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
Adrian Chadd changed:
What|Removed |Added
CC||adr...@freebsd.org
--- Comment #20
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
Juha Nygård changed:
What|Removed |Added
CC||moert...@hotmail.com
--- Comment #19
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #18 from Jan Kokemüller ---
(In reply to Konstantin Belousov from comment #17)
> Try this, please. It is somewhat closer to the current Linux code, by not
> setting asle->ardy in irq_postinstall hook. It is different from Linu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #17 from Konstantin Belousov ---
Created attachment 147377
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147377&action=edit
Do not call intel_opregion_enable_asle() from the i915_driver_irq_postinstall
Try this, ple
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #16 from Jan Kokemüller ---
Created attachment 147363
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147363&action=edit
ktrdump while loading i915kms (debug.ktr.mask=4)
(In reply to Konstantin Belousov from comment #
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #15 from Konstantin Belousov ---
(In reply to Jan Kokemüller from comment #14)
> It is not related, except that there seems to be some kind of hardware bug.
> Sadly, zeroing GMBUS4 in intel_iic_reset does not seem to help.
So c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #14 from jan.kokemuel...@gmail.com ---
(In reply to Konstantin Belousov from comment #12)
> Could you, please, describe how the discussion and fix from Linux commit
> c12aba5aa0e60b7 is related to your patch ?
It is not related,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #13 from Konstantin Belousov ---
Created attachment 147359
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147359&action=edit
Reset gmbus interrupt mask register explicitely
--
You are receiving this mail because:
Yo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
Konstantin Belousov changed:
What|Removed |Added
CC||k...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #11 from jan.kokemuel...@gmail.com ---
Created attachment 147358
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147358&action=edit
Fix/workaround for interrupt storm on GM45 when loading i915kms
This seems to be a kno
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #10 from jan.kokemuel...@gmail.com ---
Slight correction: The GPU uses irq260 before *and* after the suspend/resume
cycle if hw.drm.msi=1. So the interrupt storm on irq16 is in addition to the
"correct" behavior.
--
You are rec
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #9 from jan.kokemuel...@gmail.com ---
So to clarify, setting "hw.drm.msi=0" is fine as a workaround. When hw.drm.msi
is set to 1, I have to do one suspend/resume cycle for the interrupts on irq16
to stop. Then the GPU uses irq260
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #8 from jan.kokemuel...@gmail.com ---
Indeed, it wasn't set properly. I could have sworn I checked that, but
apparently not… I made an error when backporting the sysctl changes. I now get
about 60 interrupts per second when runni
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #7 from Ed Maste ---
It's strange that globally disabling MSI works, but disabling it just for drm
does not. hw.drm.msi is also available as a read-only sysctl after boot - can
you confirm in the "hw.drm.msi=0" case that it man
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
Ed Maste changed:
What|Removed |Added
Keywords||i915
--
You are receiving this mail be
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #6 from jan.kokemuel...@gmail.com ---
OK, then I get:
interrupt total rate
irq1: atkbd0 900 3
irq9: acpi0 3605 13
irq12: psm0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #5 from Ed Maste ---
Thanks.
It's odd to me that in both the hw.drm.msi=0 and hw.drm.msi=1 cases exactly 1
MSI is delivered. Could you try disabling msi altogether perhaps, via
hw.pci.enable_msi=0 in the loader?
--
You are r
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #4 from jan.kokemuel...@gmail.com ---
Created attachment 147255
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147255&action=edit
output of "vmstat -i" for hw.drm.msi=0/1
With the opregion patch I get the "irq16: uhci
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #3 from Ed Maste ---
Can you add a vmstat -i taken while the storm's happening, with / without
hw.drm.msi=0 set
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
Ed Maste changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #2 from jan.kokemuel...@gmail.com ---
Created attachment 147135
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147135&action=edit
output of "pciconf -lvc"
--
You are receiving this mail because:
You are the assignee
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #1 from jan.kokemuel...@gmail.com ---
Created attachment 147134
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147134&action=edit
contents of /var/run/dmesg.boot
--
You are receiving this mail because:
You are the as
31 matches
Mail list logo
