Re: r302773: non-removable files with "make delete-old"

> On Jul 13, 2016, at 11:20, O. Hartmann wrote: > > Am Wed, 13 Jul 2016 09:40:05 -0700 > David Wolfskill schrieb: > >> On Wed, Jul 13, 2016 at 06:35:10PM +0200, O. Hartmann wrote: >>> make delete-old removes these files on CURRENT (FreeBSD

CURRENT: frequent crashes if mpd5 is running

I'm experiencing frequent CURRENT ( 12.0-CURRENT r302535 amd64 ) crashes triggered by mpd5: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x10 fault code = supervisor read data, page not present instruction pointer =

Re: ptrace attach in multi-threaded processes

On Thu, Jul 14, 2016 at 08:25:37AM +0300, Konstantin Belousov wrote: > On Wed, Jul 13, 2016 at 01:01:39PM -0700, Mark Johnston wrote: > > On Wed, Jul 13, 2016 at 10:19:47PM +0300, Konstantin Belousov wrote: > > > Hmm, I think no, we can not make such change. Issue is, debugger > > > interface

RoCE v2 on FreeBSD

Hi All, Does FreeBSD support RoCE v2 ? Thanks David S. ___ 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: CURRENT: frequent crashes if mpd5 is running

On 2016-07-14 13:13, Oleg V. Nauman wrote: > I'm experiencing frequent CURRENT ( 12.0-CURRENT r302535 amd64 ) crashes > triggered by mpd5: > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x10 > fault code = supervisor read

Re: panic with tcp timers

Hi, On 6/20/16 11:55 AM, Julien Charbon wrote: > On 6/20/16 9:39 AM, Gleb Smirnoff wrote: >> On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote: >> J> > Comparing stable/10 and head, I see two changes that could >> J> > affect that: >> J> > >> J> > - callout_async_drain >> J> > -

Re: panic with tcp timers

On 2016-07-14 12:01, Julien Charbon wrote: Hi, On 6/20/16 11:55 AM, Julien Charbon wrote: On 6/20/16 9:39 AM, Gleb Smirnoff wrote: On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote: J> > Comparing stable/10 and head, I see two changes that could J> > affect that: J> > J> > -

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

Thank you for the additional information. I finally found my old laptop's internal CD-ROM drive, so I'll be able to at least check if the issue is USB-related. I just need to open the laptop to install it. After which I'll tinker with the cluster sizes and test further. Glen On Wed, Jul 13,

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

With additional tweaks, I was able to get the CD to boot both with a real internal CD-ROM drive, as well as USB CD-ROM. I have uploaded a disc1.iso image here: https://people.freebsd.org/~gjb/disc1_uzip.iso Could people try this on various hardware, KVM setups, and so on? I'm mainly

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

On Thu, Jul 14, 2016 at 11:13:56PM +, Glen Barber wrote: > Could people try this on various hardware, KVM setups, and so on? I'm > mainly interested if you get to the bsdinstall(8) screen, not issues not > directly related to using GEOM_UZIP to compress the image further. > (Meaning, I'm not

Re: 11.0-BETA2 may be delayed

On Wed, Jul 13, 2016 at 11:10:17PM +, Glen Barber wrote: > As I am sure you have already seen, there is an issue in 11.0-BETA1 that > has caused some headaches for people. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210884 > > The issue is actively being investigated, and despite

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

> On Wed, Jul 13, 2016 at 3:12 PM, Glen Barber wrote: > > > Just replying to the first email in the thread, since it's a general > > reply, and only related to the original topic at hand, and only for > > informative purposes at this point. > > > > On Mon, Jul 11, 2016 at

Re: svn commit: r302601 - in head/sys: arm/include arm64/include [clang 3.8.0: powerpc int instead of 32-bit SYSVR4's long and 64-bit ELF V2 long]

On 2016-Jul-13, at 6:00 PM, Andrey Chernov wrote: > On 13.07.2016 11:53, Mark Millard wrote: >> [The below does note that TARGET=powerpc has a mix of signed wchar_t and >> unsigned char types and most architectures have both being signed types.] > > POSIX says nothing about

Jenkins build is back to normal : FreeBSD_HEAD_sparc64 #148

See ___ 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: svn commit: r302601 - in head/sys: arm/include arm64/include [clang 3.8.0: powerpc int instead of 32-bit SYSVR4's long and 64-bit ELF V2 long]

[Top post of a history note for powerpc and wchar_t's type in FreeBSD. The history is from looking around in svn.] [The below is not a complaint or a request for a change. It just looks like int for wchar_t for powerpc was a choice made long ago for simpler code given FreeBSD's pre-existing

Re: ath (AR9460) no longer works after going to 11-STABLE r302483

Hi, * Adrian Chadd [160710 21:47]: > Since you've reverted the ath driver directories without success, I'm > mostly out of simple ideas. I think you need to bisect the whole > kernel version until you find the commit that broke things. done. The commit is 11-STABLE r302410.

Re: ath (AR9460) no longer works after going to 11-STABLE r302483

On 14 July 2016 at 14:37, Wolfgang Zenker wrote: > Hi, > > * Adrian Chadd [160710 21:47]: >> Since you've reverted the ath driver directories without success, I'm >> mostly out of simple ideas. I think you need to bisect the whole >> kernel version

Re: refcnt 0 on LLE at boot....

On Thu, 07 Jul 2016 06:36:19 -0700 Larry Rosenman wrote > Thanks for that. I've added myself to the cc list, and a comment about > having 2 vmcore's. > This was introduced by 302350. It broke the return value of callout_{stop,drain}. returning 1 even if

Re: callout_drain either broken or man page needs updating

On Thu, 14 Jul 2016 21:21:57 -0700 Hans Petter Selasky wrote > On 07/15/16 05:45, Matthew Macy wrote: > > glebius last commit needs some further re-work. > > Hi, > > Glebius commit needs to be backed out, at least the API change that > changes the

callout_drain either broken or man page needs updating

Upon updating my drm-next branch to the latest -CURRENT callout_drain returning no longer means that the function was in fact pending when it was called. This little bit of code will panic because dwork->wq is NULL, because the callout was _not_ in fact enqueued. So either it's no longer

Re: callout_drain either broken or man page needs updating

On 07/15/16 05:45, Matthew Macy wrote: glebius last commit needs some further re-work. Hi, Glebius commit needs to be backed out, at least the API change that changes the return value when calling callout_stop() when the callout is scheduled and being serviced. Simply because there is code