Re: i915 driver update testing

2014-10-07 Thread Adam McDougall 


On 10/7/2014 12:20 AM, Konstantin Belousov wrote:

On Mon, Oct 06, 2014 at 07:30:20PM -0400, Adam McDougall wrote:

On 10/05/2014 13:00, Konstantin Belousov wrote:

On Sun, Oct 05, 2014 at 11:01:14AM -0400, Adam McDougall wrote:

(kgdb) #0  doadump (textdump=1) at pcpu.h:219
#1  0x80661efd in kern_reboot (howto=260)
 at /usr/src/sys/kern/kern_shutdown.c:447
#2  0x80662450 in panic (fmt=)
 at /usr/src/sys/kern/kern_shutdown.c:746
#3  0x808fe52f in trap_fatal (frame=,
 eva=) at /usr/src/sys/amd64/amd64/trap.c:866
#4  0x808fe87c in trap_pfault (frame=0xfe01fe0b21b0,
 usermode=) at /usr/src/sys/amd64/amd64/trap.c:677
#5  0x808fde9e in trap (frame=0xfe01fe0b21b0)
 at /usr/src/sys/amd64/amd64/trap.c:426
#6  0x808e00a2 in calltrap ()
 at /usr/src/sys/amd64/amd64/exception.S:231
#7  0x8166808e in i915_write32 (dev_priv=0xf800031f1c00,
 reg=20736, val=0)
 at
/usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_drv.c:992

In kgdb, from this frame, please do
p *dev_priv
p *(dev_priv->dev)
p *(dev_priv->info)

http://www.egr.msu.edu/~mcdouga9/i915-1b.txt

Sorry for the delay.  I duplicated this on a spare computer of the same
model so I can test easier.

Great, thank you.  Please also do, from the frame 12,
p *dev


http://www.egr.msu.edu/~mcdouga9/i915-2.txt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Looping during boot-up process in FreeBSD-11 current

2014-10-07 Thread Mike. 
On 10/5/2014 at 1:57 AM Alexander V. Chernikov wrote:

|On 01.10.2014 02:02, Mike. wrote:
|> On 9/30/2014 at 7:25 PM José Pérez Arauzo wrote:
|> 
|> 
|> |[snip]
|> |Try the 271146,
|> |[snip]
|>  =
|
|This might be related with r271207.
|Can you try r271206 (or any recent HEAD with reverted r271207) ?
|
 =

Thanks for the reply.

Apologies for the delay in responding, I've been off the grid since
last Thursday.


I tried r271206 and r271207.  They both worked.   The boot sequence
progressed up to and including the login prompt.


If there's anything else you'd like me to try, let me know.


Thanks,
Mike


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

Re: i915 driver update testing

2014-10-07 Thread Konstantin Belousov 
On Tue, Oct 07, 2014 at 09:00:56AM -0400, Adam McDougall wrote:
> 
> On 10/7/2014 12:20 AM, Konstantin Belousov wrote:
> > On Mon, Oct 06, 2014 at 07:30:20PM -0400, Adam McDougall wrote:
> >> On 10/05/2014 13:00, Konstantin Belousov wrote:
> >>> On Sun, Oct 05, 2014 at 11:01:14AM -0400, Adam McDougall wrote:
>  (kgdb) #0  doadump (textdump=1) at pcpu.h:219
>  #1  0x80661efd in kern_reboot (howto=260)
>   at /usr/src/sys/kern/kern_shutdown.c:447
>  #2  0x80662450 in panic (fmt=)
>   at /usr/src/sys/kern/kern_shutdown.c:746
>  #3  0x808fe52f in trap_fatal (frame=,
>   eva=) at /usr/src/sys/amd64/amd64/trap.c:866
>  #4  0x808fe87c in trap_pfault (frame=0xfe01fe0b21b0,
>   usermode=) at 
>  /usr/src/sys/amd64/amd64/trap.c:677
>  #5  0x808fde9e in trap (frame=0xfe01fe0b21b0)
>   at /usr/src/sys/amd64/amd64/trap.c:426
>  #6  0x808e00a2 in calltrap ()
>   at /usr/src/sys/amd64/amd64/exception.S:231
>  #7  0x8166808e in i915_write32 (dev_priv=0xf800031f1c00,
>   reg=20736, val=0)
>   at
>  /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_drv.c:992
> >>> In kgdb, from this frame, please do
> >>> p *dev_priv
> >>> p *(dev_priv->dev)
> >>> p *(dev_priv->info)
> >> http://www.egr.msu.edu/~mcdouga9/i915-1b.txt
> >>
> >> Sorry for the delay.  I duplicated this on a spare computer of the same
> >> model so I can test easier.
> > Great, thank you.  Please also do, from the frame 12,
> > p *dev
> >
> http://www.egr.msu.edu/~mcdouga9/i915-2.txt

>From the same frame, please do
p *(struct drm_i915_private *)(dev->private)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Ver 2 of the patch [was: Re: i915 driver update testing]

2014-10-07 Thread Konstantin Belousov 
On Tue, Oct 07, 2014 at 07:44:19PM +0300, Konstantin Belousov wrote:
> >From the same frame, please do
> p *(struct drm_i915_private *)(dev->private)

I probably figured out what is wrong, but it is still interesting to
see this piece of data.

For everybody who has the issue with blank screen or panic after
the patch:
1. please try the updated patch,
https://www.kib.kiev.ua/kib/drm/i915.2.patch
2. if you use "kldload i915kms" to test the patch and get the blank
   screen, verify do you get panic or just a black screen.  It is
   expected for sc, not so for vt.  For vt, if you do get blank screen
   and not a panic, do not load i915kms manually and run the X server.
   I am interested if running X server does show proper output.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Heads-up: Removing gperf from base

2014-10-07 Thread Ed Maste 
gperf is a tool that generates perfect hash functions. It is used as a
bootstrap tool when building gcc, and by a few ports.

Today we unconditionally build and install gperf, including on clang
architectures where it's not required. I plan to switch this so that
gperf is only built when gcc is (that is, make it conditional on
MK_GCC).

The ports tree will use the devel/gperf port if gperf is not available
from the base system. A ports exp-run is planned to verify this works,
and I expect to commit the change after that's confirmed.

PR: https://bugs.freebsd.org/194103
Review: https://reviews.freebsd.org/D886

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

Re: i915 driver update testing

2014-10-07 Thread Adam McDougall 
On 10/07/2014 12:44, Konstantin Belousov wrote:
> On Tue, Oct 07, 2014 at 09:00:56AM -0400, Adam McDougall wrote:
>>
>> On 10/7/2014 12:20 AM, Konstantin Belousov wrote:
>>> On Mon, Oct 06, 2014 at 07:30:20PM -0400, Adam McDougall wrote:
 On 10/05/2014 13:00, Konstantin Belousov wrote:
> On Sun, Oct 05, 2014 at 11:01:14AM -0400, Adam McDougall wrote:
>> (kgdb) #0  doadump (textdump=1) at pcpu.h:219
>> #1  0x80661efd in kern_reboot (howto=260)
>>  at /usr/src/sys/kern/kern_shutdown.c:447
>> #2  0x80662450 in panic (fmt=)
>>  at /usr/src/sys/kern/kern_shutdown.c:746
>> #3  0x808fe52f in trap_fatal (frame=,
>>  eva=) at /usr/src/sys/amd64/amd64/trap.c:866
>> #4  0x808fe87c in trap_pfault (frame=0xfe01fe0b21b0,
>>  usermode=) at 
>> /usr/src/sys/amd64/amd64/trap.c:677
>> #5  0x808fde9e in trap (frame=0xfe01fe0b21b0)
>>  at /usr/src/sys/amd64/amd64/trap.c:426
>> #6  0x808e00a2 in calltrap ()
>>  at /usr/src/sys/amd64/amd64/exception.S:231
>> #7  0x8166808e in i915_write32 (dev_priv=0xf800031f1c00,
>>  reg=20736, val=0)
>>  at
>> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_drv.c:992
> In kgdb, from this frame, please do
> p *dev_priv
> p *(dev_priv->dev)
> p *(dev_priv->info)
 http://www.egr.msu.edu/~mcdouga9/i915-1b.txt

 Sorry for the delay.  I duplicated this on a spare computer of the same
 model so I can test easier.
>>> Great, thank you.  Please also do, from the frame 12,
>>> p *dev
>>>
>> http://www.egr.msu.edu/~mcdouga9/i915-2.txt
> 
> From the same frame, please do
> p *(struct drm_i915_private *)(dev->private)
> 

(kgdb) f 12
#12 0x81681bd7 in intel_modeset_init (dev=0xf80003bd9000)
at
/usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_display.c:6603
6603found = intel_sdvo_init(dev, PCH_SDVOB, true);
Current language:  auto; currently minimal
(kgdb) p *(struct drm_i915_private *)(dev->private)
There is no member named private.

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

Re: i915 driver update testing

2014-10-07 Thread Konstantin Belousov 
On Tue, Oct 07, 2014 at 02:08:06PM -0400, Adam McDougall wrote:
> On 10/07/2014 12:44, Konstantin Belousov wrote:
> > On Tue, Oct 07, 2014 at 09:00:56AM -0400, Adam McDougall wrote:
> >>
> >> On 10/7/2014 12:20 AM, Konstantin Belousov wrote:
> >>> On Mon, Oct 06, 2014 at 07:30:20PM -0400, Adam McDougall wrote:
>  On 10/05/2014 13:00, Konstantin Belousov wrote:
> > On Sun, Oct 05, 2014 at 11:01:14AM -0400, Adam McDougall wrote:
> >> (kgdb) #0  doadump (textdump=1) at pcpu.h:219
> >> #1  0x80661efd in kern_reboot (howto=260)
> >>  at /usr/src/sys/kern/kern_shutdown.c:447
> >> #2  0x80662450 in panic (fmt=)
> >>  at /usr/src/sys/kern/kern_shutdown.c:746
> >> #3  0x808fe52f in trap_fatal (frame=,
> >>  eva=) at /usr/src/sys/amd64/amd64/trap.c:866
> >> #4  0x808fe87c in trap_pfault (frame=0xfe01fe0b21b0,
> >>  usermode=) at 
> >> /usr/src/sys/amd64/amd64/trap.c:677
> >> #5  0x808fde9e in trap (frame=0xfe01fe0b21b0)
> >>  at /usr/src/sys/amd64/amd64/trap.c:426
> >> #6  0x808e00a2 in calltrap ()
> >>  at /usr/src/sys/amd64/amd64/exception.S:231
> >> #7  0x8166808e in i915_write32 (dev_priv=0xf800031f1c00,
> >>  reg=20736, val=0)
> >>  at
> >> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_drv.c:992
> > In kgdb, from this frame, please do
> > p *dev_priv
> > p *(dev_priv->dev)
> > p *(dev_priv->info)
>  http://www.egr.msu.edu/~mcdouga9/i915-1b.txt
> 
>  Sorry for the delay.  I duplicated this on a spare computer of the same
>  model so I can test easier.
> >>> Great, thank you.  Please also do, from the frame 12,
> >>> p *dev
> >>>
> >> http://www.egr.msu.edu/~mcdouga9/i915-2.txt
> > 
> > From the same frame, please do
> > p *(struct drm_i915_private *)(dev->private)
> > 
> 
> (kgdb) f 12
> #12 0x81681bd7 in intel_modeset_init (dev=0xf80003bd9000)
> at
> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_display.c:6603
> 6603  found = intel_sdvo_init(dev, PCH_SDVOB, true);
> Current language:  auto; currently minimal
> (kgdb) p *(struct drm_i915_private *)(dev->private)
> There is no member named private.
It is dev_private, typo.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Ver 2 of the patch [was: Re: i915 driver update testing]

2014-10-07 Thread Ranjan1018 . 
2014-10-07 20:01 GMT+02:00 Konstantin Belousov :

> On Tue, Oct 07, 2014 at 07:44:19PM +0300, Konstantin Belousov wrote:
> > >From the same frame, please do
> > p *(struct drm_i915_private *)(dev->private)
>
> I probably figured out what is wrong, but it is still interesting to
> see this piece of data.
>
> For everybody who has the issue with blank screen or panic after
> the patch:
> 1. please try the updated patch,
> https://www.kib.kiev.ua/kib/drm/i915.2.patch
> 2. if you use "kldload i915kms" to test the patch and get the blank
>screen, verify do you get panic or just a black screen.  It is
>expected for sc, not so for vt.  For vt, if you do get blank screen
>and not a panic, do not load i915kms manually and run the X server.
>I am interested if running X server does show proper output.
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>

Hi,

applying the patch I receive this message:
# patch -p1 -C < ~/downloads/i915.2.patch
.
.
.
Patching file sys/amd64/amd64/pmap.c using Plan A...
Hunk #1 succeeded at 1710.
Hunk #2 succeeded at 6226.
Hunk #3 succeeded at 6562.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--
|diff --git a/sys/amd64/conf/X b/sys/amd64/conf/X
|index 0cd80c6..2d630d5 100644
|--- a/sys/amd64/conf/X
|+++ b/sys/amd64/conf/X
--
File to patch:

I haven't the file X.

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

11-CURRENT redports builders miscompiling? (was: svn commit: r370388 - in head: devel/e2fsprogs-libss misc/e2fsprogs-libblkid misc/e2fsprogs-libuuid sysutils/e2fsprogs sysutils/e2fsprogs/files)

2014-10-07 Thread Matthias Andree 
Greetings,

I have just updated sysutils/e2fsprogs and its slave ports(*), and test
drove them on redports.  The self-test suite is failing on 11-CURRENT
i386 and amd64, but not on 10 or older releases.

11-amd64: https://redports.org/buildarchive/20141007190638-31576
11-i386:  https://redports.org/buildarchive/20141007185700-4151

I am now wondering
- if there are issues with the toolchain on 11 that causes
miscompilation, or
- whether 11 is misbehaving on redports, or
- if e2fsprogs has code bugs that don't show on older toolchains.

Any insights into the 11-CURRENT tool chain quality?

Thanks.


(*) as of SVN ports revision 370388.

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

Re: Ver 2 of the patch [was: Re: i915 driver update testing]

2014-10-07 Thread Ed Maste 
On 7 October 2014 15:20, Ranjan1018 . <21474...@gmail.com> wrote:
>
> Hmm...  The next patch looks like a unified diff to me...
> The text leading up to this was:
> --
> |diff --git a/sys/amd64/conf/X b/sys/amd64/conf/X
> |index 0cd80c6..2d630d5 100644
> |--- a/sys/amd64/conf/X
> |+++ b/sys/amd64/conf/X
> --
> File to patch:
>
> I haven't the file X.

You can just hit Enter and then answer 'y' to the "skip this patch" question:

File to patch:
No file found--skip this patch? [n] y
Skipping patch...
Hunk #1 ignored at 67.
1 out of 1 hunks ignored--saving rejects to Oops.rej

X in the patch is a kernel config file that's not important for the
change itself.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD 2014Q3 status reports due today!

2014-10-07 Thread Benjamin Kaduk 
Dear FreeBSD Community,

As previously announced, today is the deadline for submitting items for
the next FreeBSD Quarterly Status Update, covering work done in July
through September.

If you still need some time to prepare a submission, please note that we
will continue to accept submissions as we work on assembling the report,
but cannot guarantee that anything received after October 10 will be
included.


Status report submissions do not have to be very long.  They may be
about anything happening in the FreeBSD project and community, and
provide a great way to inform FreeBSD users and developers about what
you're working on.  Submission of reports is not restricted to
committers.  Anyone doing anything interesting and FreeBSD-related
can -- and should -- write one!

The preferred and easiest submission method is to use the XML generator [1]
with the results emailed to the status report team at mont...@freebsd.org .
There is also an XML template [2] which can be filled out manually and
attached if preferred.  For the expected content and style, please study
our guidelines on how to write a good status report [3].  You can also
review previous issues [4][5] for ideas on the style and format.

We are looking forward to all of your 2014Q3 reports!

Thanks,
Ben (on behalf of monthly@)

[1] http://www.freebsd.org/cgi/monthly.cgi
[2] http://www.freebsd.org/news/status/report-sample.xml
[3] http://www.freebsd.org/news/status/howto.html
[4] http://www.freebsd.org/news/status/report-2014-01-2014-03.html
[4] http://www.freebsd.org/news/status/report-2014-04-2014-06.html

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

Re: 11-CURRENT redports builders miscompiling? (was: svn commit: r370388 - in head: devel/e2fsprogs-libss misc/e2fsprogs-libblkid misc/e2fsprogs-libuuid sysutils/e2fsprogs sysutils/e2fsprogs/files)

2014-10-07 Thread Antoine Brodin 
On Tue, Oct 7, 2014 at 9:26 PM, Matthias Andree  wrote:
> Greetings,
>
> I have just updated sysutils/e2fsprogs and its slave ports(*), and test
> drove them on redports.  The self-test suite is failing on 11-CURRENT
> i386 and amd64, but not on 10 or older releases.
>
> 11-amd64: https://redports.org/buildarchive/20141007190638-31576
> 11-i386:  https://redports.org/buildarchive/20141007185700-4151
>
> I am now wondering
> - if there are issues with the toolchain on 11 that causes
> miscompilation, or
> - whether 11 is misbehaving on redports, or
> - if e2fsprogs has code bugs that don't show on older toolchains.

Hi,

e2fsprogs version 1.42.10 tests were succeeding in a jail with a world
from r272576 (1.5 day old)

http://gohan2.ysv.freebsd.org/data/head-amd64-default-baseline/p370135_s272576/logs/e2fsprogs-1.42.10.log

(this is poudriere,  not tinderbox)

Cheers,

Antoine

>
> Any insights into the 11-CURRENT tool chain quality?
>
> Thanks.
>
>
> (*) as of SVN ports revision 370388.
>
> Cheers,
> Matthias
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: i915 driver update testing

2014-10-07 Thread Adam McDougall 
On 10/07/2014 14:24, Konstantin Belousov wrote:
> On Tue, Oct 07, 2014 at 02:08:06PM -0400, Adam McDougall wrote:
>> On 10/07/2014 12:44, Konstantin Belousov wrote:
>>> On Tue, Oct 07, 2014 at 09:00:56AM -0400, Adam McDougall wrote:

 On 10/7/2014 12:20 AM, Konstantin Belousov wrote:
> On Mon, Oct 06, 2014 at 07:30:20PM -0400, Adam McDougall wrote:
>> On 10/05/2014 13:00, Konstantin Belousov wrote:
>>> On Sun, Oct 05, 2014 at 11:01:14AM -0400, Adam McDougall wrote:
 (kgdb) #0  doadump (textdump=1) at pcpu.h:219
 #1  0x80661efd in kern_reboot (howto=260)
  at /usr/src/sys/kern/kern_shutdown.c:447
 #2  0x80662450 in panic (fmt=)
  at /usr/src/sys/kern/kern_shutdown.c:746
 #3  0x808fe52f in trap_fatal (frame=,
  eva=) at /usr/src/sys/amd64/amd64/trap.c:866
 #4  0x808fe87c in trap_pfault (frame=0xfe01fe0b21b0,
  usermode=) at 
 /usr/src/sys/amd64/amd64/trap.c:677
 #5  0x808fde9e in trap (frame=0xfe01fe0b21b0)
  at /usr/src/sys/amd64/amd64/trap.c:426
 #6  0x808e00a2 in calltrap ()
  at /usr/src/sys/amd64/amd64/exception.S:231
 #7  0x8166808e in i915_write32 (dev_priv=0xf800031f1c00,
  reg=20736, val=0)
  at
 /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_drv.c:992
>>> In kgdb, from this frame, please do
>>> p *dev_priv
>>> p *(dev_priv->dev)
>>> p *(dev_priv->info)
>> http://www.egr.msu.edu/~mcdouga9/i915-1b.txt
>>
>> Sorry for the delay.  I duplicated this on a spare computer of the same
>> model so I can test easier.
> Great, thank you.  Please also do, from the frame 12,
> p *dev
>
 http://www.egr.msu.edu/~mcdouga9/i915-2.txt
>>>
>>> From the same frame, please do
>>> p *(struct drm_i915_private *)(dev->private)
>>>
>>
>> (kgdb) f 12
>> #12 0x81681bd7 in intel_modeset_init (dev=0xf80003bd9000)
>> at
>> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_display.c:6603
>> 6603 found = intel_sdvo_init(dev, PCH_SDVOB, true);
>> Current language:  auto; currently minimal
>> (kgdb) p *(struct drm_i915_private *)(dev->private)
>> There is no member named private.
> It is dev_private, typo.
> 
I actually took a guess at that too, but this didn't look helpful:
(kgdb) p *(struct drm_i915_private *)(dev_private)
No symbol "dev_private" in current context.

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

Re: Ver 2 of the patch [was: Re: i915 driver update testing]

2014-10-07 Thread Ranjan1018 . 
2014-10-07 21:29 GMT+02:00 Ed Maste :

> On 7 October 2014 15:20, Ranjan1018 . <21474...@gmail.com> wrote:
> >
> > Hmm...  The next patch looks like a unified diff to me...
> > The text leading up to this was:
> > --
> > |diff --git a/sys/amd64/conf/X b/sys/amd64/conf/X
> > |index 0cd80c6..2d630d5 100644
> > |--- a/sys/amd64/conf/X
> > |+++ b/sys/amd64/conf/X
> > --
> > File to patch:
> >
> > I haven't the file X.
>
> You can just hit Enter and then answer 'y' to the "skip this patch"
> question:
>
> File to patch:
> No file found--skip this patch? [n] y
> Skipping patch...
> Hunk #1 ignored at 67.
> 1 out of 1 hunks ignored--saving rejects to Oops.rej
>
> X in the patch is a kernel config file that's not important for the
> change itself.
>

Thanks Ed, it works.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 11-CURRENT redports builders miscompiling?

2014-10-07 Thread Matthias Andree 
Am 07.10.2014 um 21:32 schrieb Antoine Brodin:
> On Tue, Oct 7, 2014 at 9:26 PM, Matthias Andree  wrote:
>> Greetings,
>>
>> I have just updated sysutils/e2fsprogs and its slave ports(*), and test
>> drove them on redports.  The self-test suite is failing on 11-CURRENT
>> i386 and amd64, but not on 10 or older releases.
>>
>> 11-amd64: https://redports.org/buildarchive/20141007190638-31576
>> 11-i386:  https://redports.org/buildarchive/20141007185700-4151
>>
>> I am now wondering
>> - if there are issues with the toolchain on 11 that causes
>> miscompilation, or
>> - whether 11 is misbehaving on redports, or
>> - if e2fsprogs has code bugs that don't show on older toolchains.
> 
> Hi,
> 
> e2fsprogs version 1.42.10 tests were succeeding in a jail with a world
> from r272576 (1.5 day old)
> 
> http://gohan2.ysv.freebsd.org/data/head-amd64-default-baseline/p370135_s272576/logs/e2fsprogs-1.42.10.log
> 
> (this is poudriere,  not tinderbox)

Hi Antoine,

merci for that.

There are probably multiple changes, so if someone else can take the
newer 1.42.12 for a test on 11-current, either on a naked system or with
poudriere, that will be appreciated.  What I find odd is that the
redports logs also show output deviations from expected, for instance,
here:

> ==> 
> /work/a/ports/sysutils/e2fsprogs/work/e2fsprogs-1.42.12/tests/r_resize_inode.failed
>  <==
> --- r_resize_inode/expect 2014-08-25 03:08:16.0 +
> +++ r_resize_inode.log2014-10-07 19:10:00.0 +
> @@ -1,7 +1,7 @@
>  mke2fs -q -F -O resize_inode -o Linux -b 1024 -g 1024 test.img 16384
>  resize2fs test.img 65536
>  Resizing the filesystem on test.img to 65536 (1k) blocks.
> -The filesystem on test.img is now 65536 (1k) blocks long.
> +The filesystem on test.img is now 65536 (1480342k) blocks long.
>  
>  Pass 1: Checking inodes, blocks, and sizes
>  Pass 2: Checking directory structure

The block size is bogus, and this happens on i386 and amd64 so is not
/obviously/ an issue of sizeof(long) or thereabouts.

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

Re: Ver 2 of the patch [was: Re: i915 driver update testing]

2014-10-07 Thread Adam McDougall 
On 10/07/2014 14:01, Konstantin Belousov wrote:
> On Tue, Oct 07, 2014 at 07:44:19PM +0300, Konstantin Belousov wrote:
>> >From the same frame, please do
>> p *(struct drm_i915_private *)(dev->private)
> 
> I probably figured out what is wrong, but it is still interesting to
> see this piece of data.
> 
> For everybody who has the issue with blank screen or panic after
> the patch:
> 1. please try the updated patch,
>   https://www.kib.kiev.ua/kib/drm/i915.2.patch
> 2. if you use "kldload i915kms" to test the patch and get the blank
>screen, verify do you get panic or just a black screen.  It is
>expected for sc, not so for vt.  For vt, if you do get blank screen
>and not a panic, do not load i915kms manually and run the X server.
>I am interested if running X server does show proper output.
> 

Backtrace seems the same, I repeated the prior commands:
http://www.egr.msu.edu/~mcdouga9/i915-patch2-1.txt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 11-CURRENT redports builders miscompiling?

2014-10-07 Thread Antoine Brodin 
On Tue, Oct 7, 2014 at 9:49 PM, Matthias Andree  wrote:
> Am 07.10.2014 um 21:32 schrieb Antoine Brodin:
>> On Tue, Oct 7, 2014 at 9:26 PM, Matthias Andree  wrote:
>>> Greetings,
>>>
>>> I have just updated sysutils/e2fsprogs and its slave ports(*), and test
>>> drove them on redports.  The self-test suite is failing on 11-CURRENT
>>> i386 and amd64, but not on 10 or older releases.
>>>
>>> 11-amd64: https://redports.org/buildarchive/20141007190638-31576
>>> 11-i386:  https://redports.org/buildarchive/20141007185700-4151
>>>
>>> I am now wondering
>>> - if there are issues with the toolchain on 11 that causes
>>> miscompilation, or
>>> - whether 11 is misbehaving on redports, or
>>> - if e2fsprogs has code bugs that don't show on older toolchains.
>>
>> Hi,
>>
>> e2fsprogs version 1.42.10 tests were succeeding in a jail with a world
>> from r272576 (1.5 day old)
>>
>> http://gohan2.ysv.freebsd.org/data/head-amd64-default-baseline/p370135_s272576/logs/e2fsprogs-1.42.10.log
>>
>> (this is poudriere,  not tinderbox)
>
> Hi Antoine,
>
> merci for that.
>
> There are probably multiple changes, so if someone else can take the
> newer 1.42.12 for a test on 11-current, either on a naked system or with
> poudriere, that will be appreciated.  What I find odd is that the
> redports logs also show output deviations from expected, for instance,
> here:
>
>> ==> 
>> /work/a/ports/sysutils/e2fsprogs/work/e2fsprogs-1.42.12/tests/r_resize_inode.failed
>>  <==
>> --- r_resize_inode/expect 2014-08-25 03:08:16.0 +
>> +++ r_resize_inode.log2014-10-07 19:10:00.0 +
>> @@ -1,7 +1,7 @@
>>  mke2fs -q -F -O resize_inode -o Linux -b 1024 -g 1024 test.img 16384
>>  resize2fs test.img 65536
>>  Resizing the filesystem on test.img to 65536 (1k) blocks.
>> -The filesystem on test.img is now 65536 (1k) blocks long.
>> +The filesystem on test.img is now 65536 (1480342k) blocks long.
>>
>>  Pass 1: Checking inodes, blocks, and sizes
>>  Pass 2: Checking directory structure
>
> The block size is bogus, and this happens on i386 and amd64 so is not
> /obviously/ an issue of sizeof(long) or thereabouts.


So,  the test fail on head,  but if you look carefully,  1480342*1024
= 0x5a5a... which looks like malloc junk.

But when I turn off malloc debugging ( ln -s 'abort:false,junk:false'
/etc/malloc.conf ) the tests succeed.

So it looks like a bug in e2fsprogs.

Cheers,

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

Re: Need help fixing tests in CURRENT

2014-10-07 Thread Craig Rodrigues 
Hi,

After committing this fix to yacc in HEAD (
https://lists.freebsd.org/pipermail/svn-src-all/2014-October/092553.html )
I've been able to do:  "cd /usr/tests; kyua test"

and get 0 test failures:

https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/16/testReport/

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

Automatically running /usr/tests under Jenkins

2014-10-07 Thread Craig Rodrigues 
Hi,

I have created this Jenkins job:

https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/1577/BuildGraph/

(1)  does a buildworld/buildkernel on amd64 when someone checks new
  code into CURRENT
(2)  Creates a bootable UFS image with makefs
(3)  Boots the image under bhyve
(4)  Runs these commands inside the bhyve VM:

  cd /usr/tests
  kyua test
  kyua report-junit --output=test-output.xml

(5)  Shuts down the bhyve VM
(6)  imports test-output.xml into Jenkins.


Hopefully we will be able to run this job very frequently,
so the tests will be run every time new commits hit the tree.

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

Re: 11-CURRENT redports builders miscompiling?

2014-10-07 Thread Matthias Andree 
Am 07.10.2014 um 22:17 schrieb Antoine Brodin:

> So,  the test fail on head,  but if you look carefully,  1480342*1024
> = 0x5a5a... which looks like malloc junk.

Bingo, thanks for the pointer.

> But when I turn off malloc debugging ( ln -s 'abort:false,junk:false'
> /etc/malloc.conf ) the tests succeed.
> 
> So it looks like a bug in e2fsprogs.

Yup, reproduced with "make post-build MALLOC_OPTIONS=J", and valgrind
also has something to complain about, so I'll forward a report upstream.

I haven't seen something in the "maint" branch since the release that
looks like an obvious fix.

This lets 11-CURRENT and redports off the hook for now.  I wasn't aware
redports-on-11 set MALLOC_OPTIONS=J or equivalent.

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

Re: 11-CURRENT redports builders miscompiling?

2014-10-07 Thread Matthias Andree 
Am 07.10.2014 um 23:57 schrieb Matthias Andree:
> Am 07.10.2014 um 22:17 schrieb Antoine Brodin:
> 
>> So,  the test fail on head,  but if you look carefully,  1480342*1024
>> = 0x5a5a... which looks like malloc junk.
> 
> Bingo, thanks for the pointer.
> 
>> But when I turn off malloc debugging ( ln -s 'abort:false,junk:false'
>> /etc/malloc.conf ) the tests succeed.
>>
>> So it looks like a bug in e2fsprogs.
> 
> Yup, reproduced with "make post-build MALLOC_OPTIONS=J", and valgrind
> also has something to complain about, so I'll forward a report upstream.
> 
> I haven't seen something in the "maint" branch since the release that
> looks like an obvious fix.
> 
> This lets 11-CURRENT and redports off the hook for now.  I wasn't aware
> redports-on-11 set MALLOC_OPTIONS=J or equivalent.

I have bisected this on upstream's Git, and the failure-inducing change
is apparently 47fee2ef



I reported this in greater detail to the authors/reviewers of the patch.

Let's see what we get.  For -current/-toolchain and decke@ I consider
this closed.

Thanks to Antoine for setting me on the right track.

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

Re: Need help fixing tests in CURRENT

2014-10-07 Thread NGie Cooper 
On Tue, Oct 7, 2014 at 2:04 PM, Craig Rodrigues  wrote:
> Hi,
>
> After committing this fix to yacc in HEAD (
> https://lists.freebsd.org/pipermail/svn-src-all/2014-October/092553.html )
> I've been able to do:  "cd /usr/tests; kyua test"
>
> and get 0 test failures:
>
> https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/16/testReport/

Awesome -- hopefully this will be sustained for several runs (this
is part of the reason why I haven't integrated all of the NetBSD tests
yet).
Thank you for all your work in getting us to green!
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Need help fixing tests in CURRENT

2014-10-07 Thread Craig Rodrigues 
On Tue, Oct 7, 2014 at 4:30 PM, NGie Cooper  wrote:

> On Tue, Oct 7, 2014 at 2:04 PM, Craig Rodrigues 
> wrote:
> > Hi,
> >
> > After committing this fix to yacc in HEAD (
> > https://lists.freebsd.org/pipermail/svn-src-all/2014-October/092553.html
> )
> > I've been able to do:  "cd /usr/tests; kyua test"
> >
> > and get 0 test failures:
> >
> >
> https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/16/testReport/
>
> Awesome -- hopefully this will be sustained for several runs (this
> is part of the reason why I haven't integrated all of the NetBSD tests
> yet).
> Thank you for all your work in getting us to green!
>
>
For any type of test framework, if the tests aren't run regularly
and reported in an easy to understand manner,
then the tests will bitrot and people will ignore them.

I've seen this happen in multiple companies I have worked at.

Hopefully we can do better with FreeBSD, and foster a community
of people who are actively updating the tests, and taking test failures
seriously.

If we don't do this, then people will just ignore the tests.
--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Need help fixing tests in CURRENT

2014-10-07 Thread NGie Cooper 
On Tue, Oct 7, 2014 at 4:38 PM, Craig Rodrigues  wrote:
>
> On Tue, Oct 7, 2014 at 4:30 PM, NGie Cooper  wrote:
>>
>> On Tue, Oct 7, 2014 at 2:04 PM, Craig Rodrigues 
>> wrote:
>> > Hi,
>> >
>> > After committing this fix to yacc in HEAD (
>> > https://lists.freebsd.org/pipermail/svn-src-all/2014-October/092553.html
>> > )
>> > I've been able to do:  "cd /usr/tests; kyua test"
>> >
>> > and get 0 test failures:
>> >
>> >
>> > https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/16/testReport/
>>
>> Awesome -- hopefully this will be sustained for several runs (this
>> is part of the reason why I haven't integrated all of the NetBSD tests
>> yet).
>> Thank you for all your work in getting us to green!
>>
>
> For any type of test framework, if the tests aren't run regularly
> and reported in an easy to understand manner,
> then the tests will bitrot and people will ignore them.
>
> I've seen this happen in multiple companies I have worked at.
>
> Hopefully we can do better with FreeBSD, and foster a community
> of people who are actively updating the tests, and taking test failures
> seriously.
>
> If we don't do this, then people will just ignore the tests.

Agreed. The problem with the NetBSD testcases and some of the bits
in tools/regression is that there are a certain batch which are
non-deterministic and blur the lines between functional and unittest.
Thanks!
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

zfs hang

2014-10-07 Thread Steve Wills 
Hi,

Not sure which thread this belongs to, but I have a zfs hang on one of my boxes
running r272152. Running procstat -kka looks like:

http://pastebin.com/szZZP8Tf

My zpool commands seem to be hung in spa_errlog_lock while others are hung in
zfs_lookup. Suggestions?

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

Re: zfs hang

2014-10-07 Thread Andriy Gapon 
On 08/10/2014 03:40, Steve Wills wrote:
> Hi,
> 
> Not sure which thread this belongs to, but I have a zfs hang on one of my 
> boxes
> running r272152. Running procstat -kka looks like:
> 
> http://pastebin.com/szZZP8Tf
> 
> My zpool commands seem to be hung in spa_errlog_lock while others are hung in
> zfs_lookup. Suggestions?

There are several threads in zio_wait.  If this is their permanent state then
there is some problem with I/O somewhere below ZFS.


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

Re: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support

2014-10-07 Thread Yonghyeon PYUN 
On Thu, Oct 02, 2014 at 02:07:30PM +0900, Yonghyeon PYUN wrote:
> On Wed, Oct 01, 2014 at 10:36:37AM +0900, Yonghyeon PYUN wrote:
> > On Tue, Sep 30, 2014 at 10:57:41AM +0900, Yonghyeon PYUN wrote:
> > > Hi,
> > > I've added support for QAC AR816x/AR817x ethernet controllers.  It
> > > passed my limited testing and I need more testers.  You can find
> > > patches from the following URLs.
> > > 
> > > http://people.freebsd.org/~yongari/alc/pci.quirk.diff
> > > and
> > > http://people.freebsd.org/~yongari/alc/alc.diff.20140930
> > > 
> > > pci.qurik.diff is to workaround silicon bug of AR816x. Without it
> > > MSI/MSIX interrupt wouldn't work.  If you just want to use
> > > legacy INTx interrupt you don't have to apply it but you have to
> > > tell alc(4) not to use MSI/MSIX interrupt with tunables(
> > > hw.alc.msi.disable and hw.alc.msix_disable).
> > > 
> > > alc.diff.20140930 will add support for AR8161/AR8162/AR8171/AR8172
> > > and E2200 controllers.  It supports all hardware features except
> > > RSS.  If you have any QAC AR816x/AR817x or old AR813x/AR815x
> > > controllers please test and report how the diff works for you.
> > > Thanks.
> > 
> > http://people.freebsd.org/~yongari/alc/pci.quirk.diff
> > http://people.freebsd.org/~yongari/alc/alc.diff.20141001
> > 
> > Patch updated to address link establishment issue.
> 
> http://people.freebsd.org/~yongari/alc/alc.diff.20141002
> Patch updated again to correct wrong lock assertion.

FYI: I've committed all the changes required to support
AR816x/AR817x.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"