Re: EFI and i915kms questions

[John Baldwin]

On Thursday, December 03, 2015 07:16:45 PM Joe Maloney wrote:
> It works!  Would it be helpful if I did a pull request from github, or just 
> let you guys take it from here?  Thanks for helping me figure out how to get 
> up, and running!  This will be so much better than the framebuffer driver I 
> was having to use.

I've posted this at https://reviews.freebsd.org/D4599 for review.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: EFI and i915kms questions

[Joe Maloney]

FYI it’s changed a bit more, and line 372 is now line 364 with different 
options.  Going to try this first which was now at line 364.

https://github.com/pkgdemon/freebsd/commit/f72323b10a9dd6da79f0dae1a6fd68823ec66f7d

Joe Maloney

> On Dec 3, 2015, at 11:58 AM, Joe Maloney  wrote:
> 
> Will give this a try, build an image and report back for sure.  Thanks!
> 
> Joe Maloney
> 
>> On Dec 2, 2015, at 1:39 AM, Jean-Sébastien Pédron 
>>  wrote:
>> 
>> On 02/12/2015 02:00, John Baldwin wrote:
>>> Note that at the top of the function it invokes IICBUS_TRANSFER on a 
>>> different
>>> device when force_bit_dev is true:
>>> 
>>> 370 sx_xlock(_priv->gmbus_sx);
>>> 371 if (sc->force_bit_dev) {
>>> 372 dumbbell282199  error = 
>>> -IICBUS_TRANSFER(dev_priv->bbbus[unit], msgs, nmsgs);
>>> 373 kib 235783  goto out;
>>> 374 }
>>> 
>>> Hmm, I would try changing the line at 470 to match the line at 372.
>>> 
>>> They used to match, and then this change:
>> 
>> You're right. This is something I fixed in my i915 update branch but
>> forgot to commit to HEAD...
>> 
>> Joe, could you please try what John suggests to confirm?
>> 
>> -- 
>> Jean-Sébastien Pédron
>> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: EFI and i915kms questions

[Joe Maloney]

It works!  Would it be helpful if I did a pull request from github, or just let 
you guys take it from here?  Thanks for helping me figure out how to get up, 
and running!  This will be so much better than the framebuffer driver I was 
having to use.

Joe Maloney

> On Dec 3, 2015, at 12:33 PM, Joe Maloney  wrote:
> 
> FYI it’s changed a bit more, and line 372 is now line 364 with different 
> options.  Going to try this first which was now at line 364.
> 
> https://github.com/pkgdemon/freebsd/commit/f72323b10a9dd6da79f0dae1a6fd68823ec66f7d
> 
> Joe Maloney
> 
>> On Dec 3, 2015, at 11:58 AM, Joe Maloney  wrote:
>> 
>> Will give this a try, build an image and report back for sure.  Thanks!
>> 
>> Joe Maloney
>> 
>>> On Dec 2, 2015, at 1:39 AM, Jean-Sébastien Pédron 
>>>  wrote:
>>> 
>>> On 02/12/2015 02:00, John Baldwin wrote:
 Note that at the top of the function it invokes IICBUS_TRANSFER on a 
 different
 device when force_bit_dev is true:
 
 370sx_xlock(_priv->gmbus_sx);
 371if (sc->force_bit_dev) {
 372dumbbell282199  error = 
 -IICBUS_TRANSFER(dev_priv->bbbus[unit], msgs, nmsgs);
 373kib 235783  goto out;
 374}
 
 Hmm, I would try changing the line at 470 to match the line at 372.
 
 They used to match, and then this change:
>>> 
>>> You're right. This is something I fixed in my i915 update branch but
>>> forgot to commit to HEAD...
>>> 
>>> Joe, could you please try what John suggests to confirm?
>>> 
>>> -- 
>>> Jean-Sébastien Pédron
>>> 
>> 
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: EFI and i915kms questions

[Joe Maloney]

Will give this a try, build an image and report back for sure.  Thanks!

Joe Maloney

> On Dec 2, 2015, at 1:39 AM, Jean-Sébastien Pédron 
>  wrote:
> 
> On 02/12/2015 02:00, John Baldwin wrote:
>> Note that at the top of the function it invokes IICBUS_TRANSFER on a 
>> different
>> device when force_bit_dev is true:
>> 
>> 370  sx_xlock(_priv->gmbus_sx);
>> 371  if (sc->force_bit_dev) {
>> 372  dumbbell282199  error = 
>> -IICBUS_TRANSFER(dev_priv->bbbus[unit], msgs, nmsgs);
>> 373  kib 235783  goto out;
>> 374  }
>> 
>> Hmm, I would try changing the line at 470 to match the line at 372.
>> 
>> They used to match, and then this change:
> 
> You're right. This is something I fixed in my i915 update branch but
> forgot to commit to HEAD...
> 
> Joe, could you please try what John suggests to confirm?
> 
> -- 
> Jean-Sébastien Pédron
> 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: EFI and i915kms questions

[Jean-Sébastien Pédron]

On 02/12/2015 02:00, John Baldwin wrote:
> Note that at the top of the function it invokes IICBUS_TRANSFER on a different
> device when force_bit_dev is true:
> 
> 370   sx_xlock(_priv->gmbus_sx);
> 371   if (sc->force_bit_dev) {
> 372   dumbbell282199  error = 
> -IICBUS_TRANSFER(dev_priv->bbbus[unit], msgs, nmsgs);
> 373   kib 235783  goto out;
> 374   }
> 
> Hmm, I would try changing the line at 470 to match the line at 372.
> 
> They used to match, and then this change:

You're right. This is something I fixed in my i915 update branch but
forgot to commit to HEAD...

Joe, could you please try what John suggests to confirm?

-- 
Jean-Sébastien Pédron



signature.asc
Description: OpenPGP digital signature

Re: EFI and i915kms questions

[John Baldwin]

On Saturday, November 28, 2015 04:50:41 PM Joe Maloney wrote:
> Thank you.  For what it’s worth I was able to grab a dump after setting that 
> sysctl.  It looks like this maybe the culprit?
> 
> panic: _sx_xlock_hard: recursed on non-recursive sx gmbus @ 
> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:362
> 
> Since it is to large for posting here.  I will include a link to the entire 
> dump on pastebin if anyone is interesting in looking at it.
> 
> http://pastebin.com/mzS5svy8
> 
> In addition I did a little further testing to narrow down the issue.
> 
> 10.1-RELEASE WORKS
> 10.2-RELEASE WORKS

Hmm, the relevant file (intel_iic.c) hasn't changed since 10.2.  However, the 
code looks
rather dubious.  It seems that the function is recursing onto itself here:

465 /*
466  * Hardware may not support GMBUS over these 
pins?
467  * Try GPIO bitbanging instead.
468  */
469 sc->force_bit_dev = true;
470 dumbbell282199  error = -IICBUS_TRANSFER(idev, msgs, 
nmsgs);
471 kib 280369  goto out;


Note that at the top of the function it invokes IICBUS_TRANSFER on a different
device when force_bit_dev is true:

370 sx_xlock(_priv->gmbus_sx);
371 if (sc->force_bit_dev) {
372 dumbbell282199  error = 
-IICBUS_TRANSFER(dev_priv->bbbus[unit], msgs, nmsgs);
373 kib 235783  goto out;
374 }

Hmm, I would try changing the line at 470 to match the line at 372.

They used to match, and then this change:

https://svnweb.freebsd.org/base?view=revision=277487

converted direct calls to an iic routine to IICBUS_TRANSFER.  However, it
also changed the first parameter of the IICBUS_TRANSFER() to idev at line 470
when it was the longer expression in the previous diff.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: EFI and i915kms questions

[Joe Maloney]

Thank you.  For what it’s worth I was able to grab a dump after setting that 
sysctl.  It looks like this maybe the culprit?

panic: _sx_xlock_hard: recursed on non-recursive sx gmbus @ 
/usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:362

Since it is to large for posting here.  I will include a link to the entire 
dump on pastebin if anyone is interesting in looking at it.

http://pastebin.com/mzS5svy8

In addition I did a little further testing to narrow down the issue.

10.1-RELEASE WORKS
10.2-RELEASE WORKS

I recall trying a 10.2-STABLE image that crashed as well.  I can tell you for 
sure that the following releases all the way back to August have the issue for 
CURRENT.

FreeBSD-11.0-CURRENT-amd64-20150804-r286285-memstick.img
FreeBSD-11.0-CURRENT-amd64-20150917-r287930-memstick.img
FreeBSD-11.0-CURRENT-amd64-20151001-r288459-memstick.img
FreeBSD-11.0-CURRENT-amd64-20151119-r291085-memstick.img

If there is an archive of older images for CURRENT I would be happy to try 
those to help further narrow down where things broke.

Joe Maloney


> On Nov 21, 2015, at 5:53 AM, Jean-Sébastien Pédron 
>  wrote:
> 
> On 13/11/2015 18:15, Joe Maloney wrote:
>> Hello,
> 
> Hi!
> 
>> Sometime after changes in FreeBSD 10-STABLE, 10.2 onwards, and 
>> recent 11 CURRENT the resolution no longer sets properly when using
>> UEFI boot. It now boots with a 640x480 resolution, and kldload
>> i915kms results in a black screen. I have not been able to grab a
>> debug log, or crash dump even with all of the debugging features
>> turned on. I cannot ssh into the laptop when this panic occurs, and
>> the screen is black so I can’t really see what happened. I’m curious
>> if there is anything else I can do besides enabling dumpdev or
>> kldload -v i915kms > output.txt that doesn’t give me any detail.
>> Nothing shows up in /var/crash or whatever the directory was.
> 
> You could try to set debug.debugger_on_panic=0 in /etc/sysctl.conf. It
> often helps to at least get core dumps when the crash happens in a video
> driver.
> 
> -- 
> Jean-Sébastien Pédron
> 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: EFI and i915kms questions

[Jean-Sébastien Pédron]

On 13/11/2015 18:15, Joe Maloney wrote:
> Hello,

Hi!

> Sometime after changes in FreeBSD 10-STABLE, 10.2 onwards, and 
> recent 11 CURRENT the resolution no longer sets properly when using
> UEFI boot. It now boots with a 640x480 resolution, and kldload
> i915kms results in a black screen. I have not been able to grab a
> debug log, or crash dump even with all of the debugging features
> turned on. I cannot ssh into the laptop when this panic occurs, and
> the screen is black so I can’t really see what happened. I’m curious
> if there is anything else I can do besides enabling dumpdev or
> kldload -v i915kms > output.txt that doesn’t give me any detail.
> Nothing shows up in /var/crash or whatever the directory was.

You could try to set debug.debugger_on_panic=0 in /etc/sysctl.conf. It
often helps to at least get core dumps when the crash happens in a video
driver.

-- 
Jean-Sébastien Pédron



signature.asc
Description: OpenPGP digital signature

EFI and i915kms questions

[Joe Maloney]

Hello,
please let me know if this isn’t the best list to ask these particular 
questions, and which list is.  I have an Acer Travelmate P653 model MS2352 with 
an Intel HD4000 (I think) Gen 3 graphics card.  Unfortunately pciconf, and 
dmesg do not show useful information other than intel gen3 graphics.  This 
laptop doesn’t give me the option to disable CSM.  It also boots whatever is 
available whether EFI only is selected or not.  FreeBSD 10.1 worked on this 
laptop, and loaded i915kms properly.  PCBSD has always worked, and still works 
even with their 11 CURRENT images which no longer use grub.

Sometime after changes in FreeBSD 10-STABLE, 10.2 onwards, and recent 11 
CURRENT the resolution no longer sets properly when using UEFI boot.  It now 
boots with a 640x480 resolution, and kldload i915kms results in a black screen. 
 I have not been able to grab a debug log, or crash dump even with all of the 
debugging features turned on.  I cannot ssh into the laptop when this panic 
occurs, and the screen is black so I can’t really see what happened.  I’m 
curious if there is anything else I can do besides enabling dumpdev or kldload 
-v i915kms > output.txt that doesn’t give me any detail.  Nothing shows up in 
/var/crash or whatever the directory was.

I’ve noticed if I compile from PCBSD’s fork of FreeBSD current source on top of 
FreeBSD it works.  I have been unable to track down the difference at this 
point.  I’ve been working on it for a few months but I have not figured it out. 
 I would appreciate any help I could get in tracking down the cause to fix the 
problem for others.  I can’t seem to find that it’s a problem for anyone else 
however after months of research.

I did find one interesting thing.  If I mount the EFI partition, and replace 
/mnt/efi/boot/bootx64.efi (boot1.efi) with loader.efi by cp /boot/loader.efi 
/mnt/efi/boot/bootx64.efi i get full 1366x768 console resolution.  I can then 
use scfb at least if I delete the i915kms* drivers to start X.

I tested boot1.efi on a mac, and it of course sets the proper 1920x1080 
resolution it should.  I am curious what the difference is between boot1.efi, 
and loader.efi.  Is a device id or something missing from boot1.efi for my 
laptop to set the proper resolution?  It’s it the fact that I can’t disable 
CSM, and it’s somehow booting non EFI?  Can I remove certain things don’t force 
EFI only, or somehow force FreeBSD to disable CSM?  Can I somehow roll an EFI 
only release of FreeBSD for further testing?  If so what would I need to 
remove, or disable?  Does anyone have any suggestions on what I could try to 
gather dump information as well regarding the i915kms lockup?

Joe Maloney



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"