Re: i915 crash

Very sorry, I didn't see your reply until Adrian's reply brought this thread back to the top of my email stack. On 2015-01-07 13:23, Konstantin Belousov wrote: > On Wed, Jan 07, 2015 at 01:01:23AM -0500, Allan Jude wrote: >> I grabbed the latest i915.8.patch from kib@'s website and compiled it >>

Re: [RFC] kern/kern_timeout.c rewrite in progress

On 01/17/15 23:18, Hans Petter Selasky wrote: On 01/17/15 20:11, Jason Wolfe wrote: HPS, Just to give a quick status update, this patch has most certainly resolved our spin lock held too long panics on stable/10. Thank you to JHB for spending some time digging into the issue and leading us to

Re: Broadwell support ?

On Tue, 20 Jan 2015 08:12:45 +0100 Kurt Jaeger wrote: > Hi! > > Is the state of Broadwell support sufficient to play around with > it on new laptops ? > > Thanks! > I doubt this, a look at Haswell and its support (concerning iGPU) should be sufficient.

Broadwell support ?

Hi! Is the state of Broadwell support sufficient to play around with it on new laptops ? Thanks! -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/

Re: i915 crash

I'm running with this patch right now; I was seeing "panic: in GPU write domain" and with this patch I'm not. -a On 7 January 2015 at 10:23, Konstantin Belousov wrote: > On Wed, Jan 07, 2015 at 01:01:23AM -0500, Allan Jude wrote: >> I grabbed the latest i915.8.patch from kib@'s website and co

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

Nope, spoke too soon: Unread portion of the kernel message buffer: panic: In GPU write domain cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper(c09d59ce,0,c09ad9fe,205,f1ce2938,...) at db_trace_self_wrapper+0x2d/frame 0xf1ce2908 kdb_backtrace(c0a10b67,1,c82fb835,f1ce29f8,f1ce2998,...) at kdb_

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

Hi, I finally fired this up on an older Intel to test. this is patch 8 from your website: vgapci0@pci0:0:2:0: class=0x03 card=0x20e417aa chip=0x2a428086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset Integrated Graphics Controller' cla

FreeBSD Quarterly Status Report - Fourth Quarter 2014

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 FreeBSD Project Quarterly Status Report: October - December 2014 This report covers FreeBSD-related projects between October and December 2014. This is the last of four reports planned for 2014. The fourth quarter of 2014 included a number

Re: old bug: mount_nfs path/name is limited to 88 chars

Xin Li wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 01/19/15 13:20, Garrett Cooper wrote: > > On Jan 19, 2015, at 8:46, Brandon Allbery > > wrote: > > > >> On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht > >> wrote: > >> > >>> So perhaps changing MNAMELEN will break s

Re: old bug: mount_nfs path/name is limited to 88 chars

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/19/15 13:20, Garrett Cooper wrote: > On Jan 19, 2015, at 8:46, Brandon Allbery > wrote: > >> On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht >> wrote: >> >>> So perhaps changing MNAMELEN will break statfs(2) on -stable >>> too? >>> >>

Re: old bug: mount_nfs path/name is limited to 88 chars

On 2015-01-19 16:20, Garrett Cooper wrote: > On Jan 19, 2015, at 8:46, Brandon Allbery wrote: > >> On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht >> wrote: >> >>> So perhaps changing MNAMELEN will break statfs(2) on >>> -stable too? >>> >> >> I believe the context there is not so much "-cu

Re: old bug: mount_nfs path/name is limited to 88 chars

On 19-1-2015 22:20, Garrett Cooper wrote: > On Jan 19, 2015, at 8:46, Brandon Allbery > wrote: > >> On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht >> wrote: >> >>> So perhaps changing MNAMELEN will break statfs(2) on -stable >>> too? >>> >> >> I believe the context there is not so much

[PATCH] nmbclusters should be always positive

Currently, the following is allowed in FreeBSD: root@rabbit1:/home/davide/udp-clt # sysctl kern.ipc.nmbclusters=2147483647 kern.ipc.nmbclusters: 2036598 -> -2147483648 The following is an attempt of fixing. I also think nmbcluster should actually be u_int and not it, but this is a discussion for

Re: old bug: mount_nfs path/name is limited to 88 chars

On Jan 19, 2015, at 8:46, Brandon Allbery wrote: > On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht > wrote: > >> So perhaps changing MNAMELEN will break statfs(2) on >> -stable too? >> > > I believe the context there is not so much "-current is special", as > "changing it for everyone is

Re: SVN r377448 breaks net-snmp on -current

Am Mon, 19 Jan 2015 14:40:09 -0500 Michael Butler schrieb: > Apparently, there was some 'magic' to accessing these sysctls: > > libtool: link: cc -DNETSNMP_ENABLE_IPV6 -fno-strict-aliasing -O2 -pipe > -march=pentium4 -I/usr/local/include -I/include -D_WANT_IFADDR > -fstack-protector -fno-strict-

SVN r377448 breaks net-snmp on -current

Apparently, there was some 'magic' to accessing these sysctls: libtool: link: cc -DNETSNMP_ENABLE_IPV6 -fno-strict-aliasing -O2 -pipe -march=pentium4 -I/usr/local/include -I/include -D_WANT_IFADDR -fstack-protector -fno-strict-aliasing -Ufreebsd11 -Dfreebsd11=freebsd11 -DHAS_FPSETMASK -DHAS_FLOATI

Re: old bug: mount_nfs path/name is limited to 88 chars

On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht wrote: > So perhaps changing MNAMELEN will break statfs(2) on > -stable too? > I believe the context there is not so much "-current is special", as "changing it for everyone is bad news" (and this would necessarily need to originate in -curren

Re: old bug: mount_nfs path/name is limited to 88 chars

>From rmack...@uoguelph.ca Mon Jan 19 15:37:25 2015 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167105 >> >> is a show stopper for me. The path/name length is >> beyond my control, so I cannot make it shorter. >> >> This discussion seems inconclusive: >> http://lists.freebsd.org/pipermai

Re: old bug: mount_nfs path/name is limited to 88 chars

Anton Shterenlikht wrote: > This bug: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167105 > > is a show stopper for me. The path/name length is > beyond my control, so I cannot make it shorter. > > This discussion seems inconclusive: > http://lists.freebsd.org/pipermail/freebsd-hackers/201

Jenkins build is back to normal : FreeBSD_HEAD #2243

See ___ 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"

old bug: mount_nfs path/name is limited to 88 chars

This bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167105 is a show stopper for me. The path/name length is beyond my control, so I cannot make it shorter. This discussion seems inconclusive: http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038543.html Is there no easy solu

Build failed in Jenkins: FreeBSD_HEAD #2242

See Changes: [ngie] Integrate contrib/netbsd-tests/bin/expr into the build/kyua as bin/expr/tests MFC after: 1 week Sponsored by: EMC / Isilon Storage Division [ngie] Expect :overflow to fail with FreeBSD's expr as it doesn't have str