6.4 on 2017 Thinkpad w HD620 blank+reboots on boot, how disable inteldrm on boot?
Hi, When EFI-booting OpenBSD 6.4 AMD64 on a 2017 Thinkpad with an Intel i7- 7600U CPU and Intel HD 620 graphics, will load the kernel, then it quickly prints something like "entry point" on the screen, after which the screen turn blanks, about 30 seconds pass, and then the computer reboots. I have not had the opportunity to catch boot output via serial console so I don't have any dmesg presently. Funny enough, the EFI installer booted off a USB memory stick, works perfectly. I was thinking, can this be because of some quirk in the console framebuffer driver for Intel, which is in the installed system's kernel but not in the installer's kernel and therefore could explain why the installer boots but not the installed system, right. Therefore accordingly, * Can you instruct me how to disable IntelDRM for the text console, so the EFI graphics driver is used instead? The installer * Can I do this live in the boot prompt, or must I apply the "config" program on the kernel image e.g. from the installer USB stick? Thanks, Tinker
Re: Disable inteldrm
On Fri, Jun 07, 2013 at 04:06:15PM +0200, pet...@schwertfisch.de wrote: > > In what way will audio be unreliable (or non-deterministic) when > inteldrm is enabled? While the CPU is running in kernel code (eg, syscall), programs cannot submit audio data before the syscall completes (or releases the CPU by sleeping). If the device has no data to play, it inserts a block of silence which results in "stuttering". On the contrary, any program running in user-mode, can be preempted by the audio program, which can manage to submit audio data in time to the device. The X server, when using the inteldrm driver, involves a lot the kernel to run hardware accelerated graphic operations. This prevents other programs to get the CPU and to submit audio data in time. On the other hand, X, when using the vesa driver, maps the video memory in its address space during initialization; then it access it without involving the kernel, allowing audio programs to run concurently. The symptom is not specific to the inteldrm driver, but to any cpu-intensive kernel code or to programs using (abusing) too much kernel services. The most notable subsystems hurting audio are uvm and kernel crypto. This holds for SP kernels. The problem becomes agravated by MP kernels because interrupts of the audio device may be missed while programs on a secondary cpu are running in kernel mode. -- Alexandre
Re: Disable inteldrm
On Fri, Jun 07, 2013 at 16:06, pet...@schwertfisch.de wrote: > Alexandre Ratchov wrote: > >> On Thu, Jun 06, 2013 at 02:37:54PM +0200, Gregor Best wrote: >> > >> > Might I ask why you want to disable inteldrm? A bug report that leads to >> > an actual fix for your problem might be more useful than sidestepping >> > the issue. >> >> I used to disable inteldrm and to use the vesa Xorg driver to get >> reliable audio. Indeed, in this case once started, X uses only a >> bare framebuffer (slower and higher cpu usage), but raster ops are >> all done in userspace without involving the kernel resulting in >> more deterministic audio. > > In what way will audio be unreliable (or non-deterministic) when > inteldrm is enabled? interrupt latency becomes longer and less predictable. audio won't run while inteldrm is running. this remains true even if audio doesn't wait for biglock if audio shares an interrupt with inteldrm.
Re: Disable inteldrm
Alexandre Ratchov wrote: > On Thu, Jun 06, 2013 at 02:37:54PM +0200, Gregor Best wrote: > > > > Might I ask why you want to disable inteldrm? A bug report that leads to > > an actual fix for your problem might be more useful than sidestepping > > the issue. > > I used to disable inteldrm and to use the vesa Xorg driver to get > reliable audio. Indeed, in this case once started, X uses only a > bare framebuffer (slower and higher cpu usage), but raster ops are > all done in userspace without involving the kernel resulting in > more deterministic audio. In what way will audio be unreliable (or non-deterministic) when inteldrm is enabled? Dirk
Re: Disable inteldrm
On Thu, Jun 06, 2013 at 02:37:54PM +0200, Gregor Best wrote: > > Might I ask why you want to disable inteldrm? A bug report that leads to > an actual fix for your problem might be more useful than sidestepping > the issue. I used to disable inteldrm and to use the vesa Xorg driver to get reliable audio. Indeed, in this case once started, X uses only a bare framebuffer (slower and higher cpu usage), but raster ops are all done in userspace without involving the kernel resulting in more deterministic audio. -- Alexandre
Re: Disable inteldrm
On 2013 Jun 06 (Thu) at 21:06:02 -0300 (-0300), Daniel Bolgheroni wrote: :On Thu, Jun 06, 2013 at 02:37:54PM +0200, Gregor Best wrote: :> :> Just for the record, that URL links to a post about IPSEC. I'm quite :> confident you meant another post :) : :Sorry. This is the thread: : :http://marc.info/?l=openbsd-misc&m=136689079009585&w=2 : :> Might I ask why you want to disable inteldrm? A bug report that leads to :> an actual fix for your problem might be more useful than sidestepping :> the issue. : :I explained in the link above (now the correct one). : :The hardware is pretty generic, and only one person signaled to have the :same issue, so I thought it was pretty specific to my configuration. : :Thank you. : Update, and report again if it is still happening with a brand new snapshot. Many things have changed there since April. We'd need a new dmesg and Xorg.0.log. -- Stop searching. Happiness is right next to you. Now, if they'd only take a bath ...
Re: Disable inteldrm
On Thu, Jun 06, 2013 at 02:37:54PM +0200, Gregor Best wrote: > > Just for the record, that URL links to a post about IPSEC. I'm quite > confident you meant another post :) Sorry. This is the thread: http://marc.info/?l=openbsd-misc&m=136689079009585&w=2 > Might I ask why you want to disable inteldrm? A bug report that leads to > an actual fix for your problem might be more useful than sidestepping > the issue. I explained in the link above (now the correct one). The hardware is pretty generic, and only one person signaled to have the same issue, so I thought it was pretty specific to my configuration. Thank you.
Re: Disable inteldrm
On Wed, Jun 05, 2013 at 09:18:26AM -0300, Daniel Bolgheroni wrote: > [...] > http://marc.info/?l=openbsd-misc&m=136688870408752&w=2 > [...] Just for the record, that URL links to a post about IPSEC. I'm quite confident you meant another post :) > Disabling with 'boot -c' is OK, X works, but I can't set my native > resolution. Setting Option "DRI" to "False" in xorg.conf doesn't help > either. > [...] That is because the intel driver in current Xenocara needs inteldrm for the modesetting. If the modesetting is not available, the intel driver fails to attach and Xenocara falls back to vesa, which only supports the most basic resolutions. Might I ask why you want to disable inteldrm? A bug report that leads to an actual fix for your problem might be more useful than sidestepping the issue. -- Gregor Best
