FreeBSD_HEAD_i386 - Build #2244 - Failure

FreeBSD_HEAD_i386 - Build #2244 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2244/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2244/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2244/console Change summaries: 2

Jenkins build is unstable: FreeBSD_HEAD #76

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"

FreeBSD_HEAD_i386 - Build #2245 - Still Failing

FreeBSD_HEAD_i386 - Build #2245 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2245/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2245/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2245/console Change summari

CURRENT: buildworld failure due to nvmecontrol source error

Buildworld (r295070) fails in building nvmecontrol patches correctly: [...] (cd /usr/src/lib/libc/tests/gen && DEPENDFILE=.depend.raise_test NO_SUBDIR=1 make -f /usr/src/lib/libc/tests/gen/Makefile _RECURSING_PROGS=t PROG=raise_test ) --- all_subdir_share --- ===> share/i18n/csmapper/APPLE (a

FreeBSD_HEAD_i386 - Build #2246 - Still Failing

FreeBSD_HEAD_i386 - Build #2246 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2246/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2246/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2246/console Change summari

Re: CURRENT: buildworld failure due to nvmecontrol source error

On Sat, Jan 30, 2016 at 12:39 PM, O. Hartmann wrote: > Buildworld (r295070) fails in building nvmecontrol patches correctly: > > [...] > (cd /usr/src/lib/libc/tests/gen && DEPENDFILE=.depend.raise_test > NO_SUBDIR=1 make > -f /usr/src/lib/libc/tests/gen/Makefile _RECURSING_PROGS=t > PROG=raise_t

Re: ZFSROOT UEFI boot

I did some more work on the review last night, if you could apply the latest patch set diff4 to see if that helps. If not compile with debugging using -DEFI_DEBUG on your make line then you will get a lot more information about which disk is being used to load from as well as info about the probe

FreeBSD_HEAD_i386 - Build #2247 - Still Failing

FreeBSD_HEAD_i386 - Build #2247 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2247/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2247/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2247/console Change summari

Re: ZFSROOT UEFI boot

I just realised an important point, does your usb disk have a UFS root partition and your internal disk ZFS root partition? If so then I know what the issue is, I'll have quick look now, so wait for a diff5 to appear before testing. On Saturday, 30 January 2016, Steven Hartland wrote: > I did so

thread-unsafety problems as spl*() ones are NOP

Hi. in kbd.c there are many places spltty()/splx() used assuming it locks/unlocks. though there is bug filed for this, and ive asked in #bsddev, Ive preferred to ask and ensure it from here again. As these functions are obsoleted now, this assumption is incorrect and some places we have thread-unsa

Re: CURRENT: buildworld failure due to nvmecontrol source error

> On Jan 30, 2016, at 04:10, Outback Dingo wrote: > > On Sat, Jan 30, 2016 at 12:39 PM, O. Hartmann > wrote: > >> Buildworld (r295070) fails in building nvmecontrol patches correctly: >> >> [...] >> (cd /usr/src/lib/libc/tests/gen && DEPENDFILE=.depend.raise_test >> NO_SUBDIR=1 make >> -f /u

Re: thread-unsafety problems as spl*() ones are NOP

On Sat, Jan 30, 2016 at 06:56:00PM +0330, mokhi wrote: > Hi. > in kbd.c there are many places spltty()/splx() used assuming it locks/unlocks. > though there is bug filed for this, and ive asked in #bsddev, Ive > preferred to ask and ensure it from here again. > As these functions are obsoleted now

Re: thread-unsafety problems as spl*() ones are NOP

i currently only wanna do patch on kbd.c (because i'm sure there is a thread-unsafety) and i don't want to add anything to spltty() nor splx(), i just wanna add things under where they've been used. isn't problem with using mutex/spin/lock/unlock etc there? _

FreeBSD_HEAD_i386 - Build #2248 - Fixed

FreeBSD_HEAD_i386 - Build #2248 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2248/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2248/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2248/console Change summaries: 295

Re: thread-unsafety problems as spl*() ones are NOP

On Sat, Jan 30, 2016 at 09:42:13PM +0330, mokhi wrote: > i currently only wanna do patch on kbd.c (because i'm sure there is a > thread-unsafety) > and i don't want to add anything to spltty() nor splx(), i just wanna > add things under where they've been used. > isn't problem with using mutex/spi

Re: thread-unsafety problems as spl*() ones are NOP

On Sat, Jan 30, 2016 at 09:25:21PM +0300, Slawa Olhovchenkov wrote: > On Sat, Jan 30, 2016 at 09:42:13PM +0330, mokhi wrote: > > > i currently only wanna do patch on kbd.c (because i'm sure there is a > > thread-unsafety) > > and i don't want to add anything to spltty() nor splx(), i just wanna >

Re: ZFSROOT UEFI boot

I believe, based on testing, that the from Diff 5 onwards of https://reviews.freebsd.org/D5108 this should work as you expect it i.e. If boot1 is loaded from a device which has either a UFS or ZFS bootable install then this is the device that will be used to boot. If said device has both then

Re: ZFSROOT UEFI boot

I believe, based on testing, that the from Diff 5 onwards of https://reviews.freebsd.org/D5108 this should work as you expect it i.e. If boot1 is loaded from a device which has either a UFS or ZFS bootable install then this is the device that will be used to boot. If said device has both then

Re: thread-unsafety problems as spl*() ones are NOP

On 01/30/16 19:31, Slawa Olhovchenkov wrote: On Sat, Jan 30, 2016 at 09:25:21PM +0300, Slawa Olhovchenkov wrote: On Sat, Jan 30, 2016 at 09:42:13PM +0330, mokhi wrote: i currently only wanna do patch on kbd.c (because i'm sure there is a thread-unsafety) and i don't want to add anything to sp

Re: thread-unsafety problems as spl*() ones are NOP

So in your opinion I shouldn't put mutex/spin/lock/unlock under splitty/splx? Can you please explain a bit more about MPSAFE using for me too? Regards, Mokhi. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd

Re: thread-unsafety problems as spl*() ones are NOP

On Sat, 2016-01-30 at 18:56 +0330, mokhi wrote: > Hi. > in kbd.c there are many places spltty()/splx() used assuming it > locks/unlocks. > though there is bug filed for this, and ive asked in #bsddev, Ive > preferred to ask and ensure it from here again. > As these functions are obsoleted now, this

Jenkins build is unstable: FreeBSD_HEAD #81

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: thread-unsafety problems as spl*() ones are NOP

On Sat, Jan 30, 2016 at 2:09 PM, Ian Lepore wrote: > On Sat, 2016-01-30 at 18:56 +0330, mokhi wrote: > > Hi. > > in kbd.c there are many places spltty()/splx() used assuming it > > locks/unlocks. > > though there is bug filed for this, and ive asked in #bsddev, Ive > > preferred to ask and ensure

Jenkins build is still unstable: FreeBSD_HEAD #82

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: ZFSROOT UEFI boot

On Sat, 30 Jan 2016 12:53:46 + Steven Hartland wrote: > I just realised an important point, does your usb disk have a UFS > root partition and your internal disk ZFS root partition? Yes. That's it, as shown in my prior post (`gpart show` output). The USB memstick is dd'ed with memstick.img o

Re: thread-unsafety problems as spl*() ones are NOP

@imp So you think I should start to put locks there and see what happens? :) ___ 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: thread-unsafety problems as spl*() ones are NOP

> On Jan 30, 2016, at 9:37 PM, mokhi wrote: > > @imp So you think I should start to put locks there and see what happens? :) I’d advocate a deeper understanding of the code. splXXX() is for code path exclusion. Locks are for data protection. These are subtly different concepts and may cause iss

Jenkins build is back to normal : FreeBSD_HEAD #86

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: thread-unsafety problems as spl*() ones are NOP

@imp: i exactly mean (Okay not so exact but very near ;D) what you said. after analyzing kbd.c functions (eg, kbd_realloc_array()) i concluded there are race conditions (and at result in some places there are un-protected data too) i don't mean to blindly replace splXXX() with locks, but the plac

Jenkins build is unstable: FreeBSD_HEAD #86

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"