Re: i915 DRMKMS GPU hang

2016-02-02 Thread Iain Hibbert 
On Tue, 2 Feb 2016, John D. Baker wrote:

> the display freezes for a couple of minutes shortly after starting X
> following a reboot--usually a couple of minutes after logging in via
> 'xdm'.  I then see the following in 'dmesg' and XConsole.  It seems only
> to occur once.  If it happened more than once in a session, it's been
> too long ago for me to remember.
> 
> drm: stuck on render ring
> drm: GPU HANG: ecode 0:0x3c8160c1, reason: Ring hung, action: reset
> drm: GPU hangs can indicate a bug anywhere in the entire gfx stack, including 
> userspace.
> drm: Please file a _new_ bug report on bugs.freedesktop.org against DRI -> 
> DRM/Intel
> drm: drm/i915 developers can then reassign to the right component if it's not 
> a kernel issue.
> drm: The gpu crash dump is required to analyze gpu hangs, so please always 
> attach it.
> drm: GPU crash dump saved to /sys/class/drm/card0/error
> DRM error in i915_reset: Failed to reset chip: -19
> 
> After this, it seems to operate normally essentially indefinitely.

I think after this, it is not any longer using the DRM (KMS?) magic code 
so it won't happen again.

I also see this GPU hang on a T60; from my dmesg

agp0 at pchb0: i915-family chipset
i915drmkms0 at pci0 dev 2 function 0: vendor 8086 product 27a2 (rev. 0x03)
drm: Memory usable by graphics device = 256M
drm: Supports vblank timestamp caching Rev 2 (21.10.2013).
drm: Driver supports precise vblank timestamp query.
i915drmkms0: interrupting at ioapic0 pin 16 (i915)
drm: initialized overlay support
intelfb0 at i915drmkms0
i915drmkms0: info: registered panic notifier
intelfb0: framebuffer at 0xdb1b9000, size 1400x1050, depth 32, stride 5632
wsdisplay0 at intelfb0 kbdmux 1: console (default, vt100 emulation), using 
wskbd0
wsmux1: connecting to wsdisplay0
vendor 8086 product 27a6 (miscellaneous display, revision 0x03) at pci0 dev 2 
function 1 not configured

and then a very short time after or during boot, I usually see

DRM error in i915_irq_handler: pipe A underrun

though I have done nothing about this - I run with the intel_old driver 
instead, which works seemingly well enough.

iain

Re: i915 DRMKMS GPU hang

2016-02-02 Thread Taylor R Campbell 
   Date: Tue, 2 Feb 2016 10:59:28 -0600 (CST)
   From: "John D. Baker" 

   Of course, the reported GPU crash dump does not exist.  Does our flavor
   of DRMKMS try to save the GPU crash dump someplace?  Perhaps the reported
   path is expected to exist first?  I'll try creating it and see if
   something is saved there the next time it happens.

No...  That never got hooked up.  I experimented with exposing it
kludgily via sysctl or dmesg or something to debug some hangs, but
never got anywhere useful with it.

Re: /stand 10x grows

2016-02-02 Thread Andreas Gustafsson 
Manuel Bouyer wrote:
> Hello,
> on recent amd65 builds, /stand is bigger than it used to be
> (10x bigger than on netbsd-7): netbsd-7 /stand is 20M, HEAD is 200M.
> It seems that all modules did get bigger (e.g. zfs is 10M when it was just
> below 1M), I didn't spot a subdir that accounts for most of the space.
> 
> Any idea why modules are that big these days ?

Presumably this is because of src/share/mk/bsd.kmodule.mk 1.56,
"If we are building CTF, keep debugging symbols."
-- 
Andreas Gustafsson, g...@gson.org

Re: /stand 10x grows

2016-02-02 Thread Paul Goyette 

On Tue, 2 Feb 2016, Kamil Rytarowski wrote:


--[PinePGP]--[begin]--
On 02.02.2016 11:40, Manuel Bouyer wrote:

Hello, on recent amd65 builds, /stand is bigger than it used to be
(10x bigger than on netbsd-7): netbsd-7 /stand is 20M, HEAD is
200M. It seems that all modules did get bigger (e.g. zfs is 10M
when it was just below 1M), I didn't spot a subdir that accounts
for most of the space.

Any idea why modules are that big these days ?



Have we enabled MKCTF by default?


Yup.  From cvsweb:

Revision 1.423 / (download) - annotate - [select for diffs], Sat Jan 30 
04:12:38 2016 UTC (3 days, 6 hours ago) by christos

Branch: MAIN
CVS Tags: HEAD
Changes since 1.422: +3 -3 lines
Diff to previous 1.422 (colored)

compile full symbol table for CTF so FBT can get function arguments.

Revision 1.422 / (download) - annotate - [select for diffs], Fri Jan 22 
21:56:56 2016 UTC (10 days, 12 hours ago) by riz

Branch: MAIN
Changes since 1.421: +3 -3 lines
Diff to previous 1.421 (colored)

Enable KDTRACE_HOOKS on i386 and amd64 GENERIC.



+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++

Re: /stand 10x grows

2016-02-02 Thread Martin Husemann 
On Tue, Feb 02, 2016 at 12:48:07PM +0200, Andreas Gustafsson wrote:
> Presumably this is because of src/share/mk/bsd.kmodule.mk 1.56,
> "If we are building CTF, keep debugging symbols."

We need to send a HEADS UP to current users about this, especially on
evbarm it may be a bad suprise.

What are the proper options to turn it off?

 MKDTRACE=no
 MKCTF=no

?

How usefull is MKDTRACE=yes MKCTF=no ?

Btw: MKCTF and MKDTRACE are still documented as defaulting to "no".

Martin

Re: Disk full on anita/amd64?

2016-02-02 Thread Manuel Bouyer 
On Tue, Feb 02, 2016 at 09:28:30AM +0200, Andreas Gustafsson wrote:
> Ryota Ozaki wrote:
> > I've noticed increase of test failures on anita/amd64:
> > http://releng.netbsd.org/b5reports/amd64/commits-2016.01.html#2016.01.30.03.38.39
> > 
> > A test failure indicates disk full of the system:
> > http://releng.netbsd.org/b5reports/amd64/build/2016.01.30.03.38.39/test.html#atf_atf-c_detail_fs_test_mkdtemp_err
> > 
> > A sanity check of ATF also indicates that:
> >   df-pre-test Filesystem  1K-blocks  UsedAvail %Cap Mounted on
> >   df-pre-test /dev/wd0a 862463 810271 9069  98% /
> > 
> > I guess it happens due to dtrace stuffs added to the base
> > recently and keeping debugging symbols of kernel modules
> > for dtrace (this is the just previous commit where test
> > failures increased).
> 
> I just incrased the disk size in the configuration of the amd64 tests
> on babylon5, and will also increase anita's default disk size in the
> next release (assuming the increase in disk use is permanent).

actually it's because /stand did grow 10x. I don't think that's intended.

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

/stand 10x grows

2016-02-02 Thread Manuel Bouyer 
Hello,
on recent amd65 builds, /stand is bigger than it used to be
(10x bigger than on netbsd-7): netbsd-7 /stand is 20M, HEAD is 200M.
It seems that all modules did get bigger (e.g. zfs is 10M when it was just
below 1M), I didn't spot a subdir that accounts for most of the space.

Any idea why modules are that big these days ?


-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: /stand 10x grows

2016-02-02 Thread Kamil Rytarowski 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02.02.2016 11:40, Manuel Bouyer wrote:
> Hello, on recent amd65 builds, /stand is bigger than it used to be 
> (10x bigger than on netbsd-7): netbsd-7 /stand is 20M, HEAD is
> 200M. It seems that all modules did get bigger (e.g. zfs is 10M
> when it was just below 1M), I didn't spot a subdir that accounts
> for most of the space.
> 
> Any idea why modules are that big these days ?
> 
> 
Have we enabled MKCTF by default?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWsIhqAAoJEEuzCOmwLnZs8+wP/jqAp91YHqfCXAmDySfjORP4
b204miz5+IUdKHBE6LkTSGp+D5GqiighQn/2JYqKTBRngsTugA34RwsCwFxTzZfm
i8ojMpNLniDpMo2nSjz91cceLmaqnogGIkcwUgjStq6NO9ttfa+6T9Rn+I4lean1
+XT35LYCqiIzOV3WjuNO6sGXAxGC2o0pEtxsVb3MHGesS7aRKIggy2UIEk4M85ja
8rMQ0O2fKyJvAtbYpse5bGNyQU13lxCLKXAc54Wji7XS+0VXUTJ/RgN/dHwzFa0i
2EHDiHoa6sO1D/6TuwcBzaZyOkVNqvP1plrqXKB85WaFBAWcPAkabQsksv3C77UX
Cik98TbN547IVz3Txd2ntXmoGx2t3ysIOVJt6tAYO5rxS1R5OZZ5PrsGJabUNvu4
VY8ma65VOdzgJrudsObxy45QD3Y8bubXaVmfYio+MDlSzcJcfllUz9iqbx8F4Rhr
leJN8Owxfekrqbwcl54JzGq/bDBNk6V2g8H0C496pe3oFgTrse8dUQbFVnSVyH2/
Xy90p4G5o1nTK2IPgSnjeA+U0x2jWigUgHab21n4rH1j54Uk3znZmX6TqEsaonPM
LP/PJNxKLjEZ3aOSpdRMbq2IIbuCr5nT/6ByZEEM0A3tK+6P8yXIFtd4CYa8dtBM
0CjSuClK9jZLTDSQJ/7p
=yRiE
-END PGP SIGNATURE-

Re: /stand 10x grows

2016-02-02 Thread Manuel Bouyer 
On Tue, Feb 02, 2016 at 06:47:24PM +0800, Paul Goyette wrote:
> On Tue, 2 Feb 2016, Kamil Rytarowski wrote:
> 
> >--[PinePGP]--[begin]--
> >On 02.02.2016 11:40, Manuel Bouyer wrote:
> >>Hello, on recent amd65 builds, /stand is bigger than it used to be
> >>(10x bigger than on netbsd-7): netbsd-7 /stand is 20M, HEAD is
> >>200M. It seems that all modules did get bigger (e.g. zfs is 10M
> >>when it was just below 1M), I didn't spot a subdir that accounts
> >>for most of the space.
> >>
> >>Any idea why modules are that big these days ?
> >>
> >>
> >Have we enabled MKCTF by default?
> 
> Yup.  From cvsweb:
> 
> Revision 1.423 / (download) - annotate - [select for diffs], Sat Jan 30
> 04:12:38 2016 UTC (3 days, 6 hours ago) by christos
> Branch: MAIN
> CVS Tags: HEAD
> Changes since 1.422: +3 -3 lines
> Diff to previous 1.422 (colored)
> 
> compile full symbol table for CTF so FBT can get function arguments.

ops. That's a lot of space in / now ...

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: /stand 10x grows

2016-02-02 Thread Paul Goyette 

On Tue, 2 Feb 2016, Martin Husemann wrote:


On Tue, Feb 02, 2016 at 12:48:07PM +0200, Andreas Gustafsson wrote:

Presumably this is because of src/share/mk/bsd.kmodule.mk 1.56,
"If we are building CTF, keep debugging symbols."


We need to send a HEADS UP to current users about this, especially on
evbarm it may be a bad suprise.


Also an entry in UPDATING ??


What are the proper options to turn it off?

MKDTRACE=no
MKCTF=no

?

How usefull is MKDTRACE=yes MKCTF=no ?

Btw: MKCTF and MKDTRACE are still documented as defaulting to "no".

Martin

!DSPAM:56b08af4122235131035579!




+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++

i915 DRMKMS GPU hang

2016-02-02 Thread John D. Baker 
On an IBM ThinkCentre S51:

$ uname -a
NetBSD thinkcentre.technoskunk.fur 7.0_STABLE NetBSD 7.0_STABLE (GX260A) #5: 
Thu Jan 28 10:44:14 CST 2016  
sy...@x3650.technoskunk.fur:/r0/build/netbsd-7/obj/i386/sys/arch/i386/compile/GX260A
 i386

with:

[...]
pchb0 at pci0 dev 0 function 0: Intel 82915P/G/GL Host (rev. 0x04)
agp0 at pchb0: i915-family chipset
agp0: detected 7932k stolen memory
agp0: aperture at 0xc000, size 0x1000
i915drmkms0 at pci0 dev 2 function 0: Intel 82915G/GL Integrated Graphics 
Device (rev. 0x04)
drm: Memory usable by graphics device = 256M
drm: Supports vblank timestamp caching Rev 2 (21.10.2013).
drm: Driver supports precise vblank timestamp query.
i915drmkms0: interrupting at ioapic0 pin 16 (i915)
drm: initialized overlay support
intelfb0 at i915drmkms0
i915drmkms0: info: registered panic notifier
intelfb0: framebuffer at 0xda5a4000, size 1280x1024, depth 32, stride 5120
wsdisplay0 at intelfb0 kbdmux 1: console (default, vt100 emulation), using 
wskbd[...]

the display freezes for a couple of minutes shortly after starting X
following a reboot--usually a couple of minutes after logging in via
'xdm'.  I then see the following in 'dmesg' and XConsole.  It seems only
to occur once.  If it happened more than once in a session, it's been
too long ago for me to remember.

drm: stuck on render ring
drm: GPU HANG: ecode 0:0x3c8160c1, reason: Ring hung, action: reset
drm: GPU hangs can indicate a bug anywhere in the entire gfx stack, including 
userspace.
drm: Please file a _new_ bug report on bugs.freedesktop.org against DRI -> 
DRM/Intel
drm: drm/i915 developers can then reassign to the right component if it's not a 
kernel issue.
drm: The gpu crash dump is required to analyze gpu hangs, so please always 
attach it.
drm: GPU crash dump saved to /sys/class/drm/card0/error
DRM error in i915_reset: Failed to reset chip: -19

After this, it seems to operate normally essentially indefinitely.

Of course, the reported GPU crash dump does not exist.  Does our flavor
of DRMKMS try to save the GPU crash dump someplace?  Perhaps the reported
path is expected to exist first?  I'll try creating it and see if
something is saved there the next time it happens.

-- 
|/"\ John D. Baker, KN5UKS   NetBSD Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]comOpenBSDFreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645

Re: /stand 10x grows

2016-02-02 Thread Christos Zoulas 
In article <20160202105547.gd1...@asim.lip6.fr>,
Manuel Bouyer   wrote:
>On Tue, Feb 02, 2016 at 06:47:24PM +0800, Paul Goyette wrote:
>> On Tue, 2 Feb 2016, Kamil Rytarowski wrote:
>> 
>> >--[PinePGP]--[begin]--
>> >On 02.02.2016 11:40, Manuel Bouyer wrote:
>> >>Hello, on recent amd65 builds, /stand is bigger than it used to be
>> >>(10x bigger than on netbsd-7): netbsd-7 /stand is 20M, HEAD is
>> >>200M. It seems that all modules did get bigger (e.g. zfs is 10M
>> >>when it was just below 1M), I didn't spot a subdir that accounts
>> >>for most of the space.
>> >>
>> >>Any idea why modules are that big these days ?
>> >>
>> >>
>> >Have we enabled MKCTF by default?
>> 
>> Yup.  From cvsweb:
>> 
>> Revision 1.423 / (download) - annotate - [select for diffs], Sat Jan 30
>> 04:12:38 2016 UTC (3 days, 6 hours ago) by christos
>> Branch: MAIN
>> CVS Tags: HEAD
>> Changes since 1.422: +3 -3 lines
>> Diff to previous 1.422 (colored)
>> 
>> compile full symbol table for CTF so FBT can get function arguments.
>
>ops. That's a lot of space in / now ...

The better question is: Do installed modules have both ctf and dwarf debug
info? Because they should only have ctf. ctf debugging info is much more
compact...

christos