Re: UEFI GOP: screen goes blank during boot after loader is finished

[Subbsd]

On Fri, Nov 16, 2018 at 8:03 AM Warner Losh  wrote:
>
>
>
> On Thu, Nov 15, 2018 at 12:10 PM Rebecca Cran  wrote:
>>
>> On Wednesday, 14 November 2018 19:56:56 MST Warner Losh wrote:
>>
>> > What is the ConOut evifar look like? We set serial when the UEFI env says
>> > to do  so.
>>
>> Booting with:
>>
>> sudo bhyve -A -P -c 2 -H -m 4G -s 0:0,hostbridge -s 31:0,lpc -s 2,ahci-
>> cd,FreeBSD-12.0-BETA4-amd64-disc1.iso -s
>> 29,fbuf,tcp=0.0.0.0:5900,w=800,h=600,wait -l bootrom,/usr/local/share/uefi-
>> firmware/BHYVE_UEFI.fd -u vm5
>>
>> dh in the shell shows:
>>
>> 7D: ConsoleOut SimpleTextOut GraphicsOutput(GraphicsOutput)
>> PCIIO DevicePath(PciRoot (0x0)/Pci(0x1D,0x0))
>>
>> 84: StdErr ConsoleOut ConsoleIn SimpleTextOut SimpleTextInEx SimpleTextIn
>> DevicePath(t(115200,8,N,1)/VenVt100Plus())
>>
>> 89: SimpleTextOut SimpleTextInEx SimpleTextIn DevicePath(Uart(115200,8,N,1)/
>> VenPcAnsi())
>
>
> If I read that right, then the ConOut variable first has the video device 
> listed, then the serial port (this wasn't the form I expected to see it in, 
> so I'm not sure thats the case). In either event, we should get console 
> output on both the serial and the video at least until the /etc/rc script 
> starts...
>
> Warner

Perhaps this is not a special case of FreeBSD guest, since the latest
versions of FreeBSD are loaded normally in other UEFI systems (e.g
Virtualbox, KVM). For example someone from CBSD Telegram chat reported
a similar problem for OpenIndiana 2018 ( which uses FreeBSD loader
however) in bhyve.
Thus, perhaps the root of this problem should be sought in
uefi-edk2-bhyve the package. Latest CBSD release (12.0.1) fixed this
problem by disabling serial console. However, CBSD uses an alternative
boot method  for bhyve ( uefi-edk2-bhyve + reFIND )
___
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: UEFI GOP: screen goes blank during boot after loader is finished

[Subbsd]

On Thu, Nov 15, 2018 at 1:33 AM Kyle Evans  wrote:
>
> On Wed, Nov 14, 2018 at 4:30 PM Kyle Evans  wrote:
> >
> > On Wed, Nov 14, 2018 at 4:23 PM Subbsd  wrote:
> > >
> > > On Thu, Nov 15, 2018 at 1:05 AM Subbsd  wrote:
> > > >
> > > > On Thu, Nov 15, 2018 at 12:21 AM Rebecca Cran  
> > > > wrote:
> > > > >
> > > > > On November 14, 2018 at 2:18:04 PM, Subbsd (sub...@gmail.com) wrote:
> > > > >>
> > > > >>
> > > > >> My current host: FreeBSD 13.0-CURRENT r340319 and the problem is
> > > > >> still present.
> > > > >
> > > > > Rod was asking about the guest OS version, not the host though.
> > > > >
> > > > >
> > > >
> > > > I apologize, it seemed to me that I wrote earlier) Guest version:
> > > > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/FreeBSD-13.0-CURRENT-amd64-20181101-r339979-disc1.iso.xz
> > >
> > > Hm, it seems the problem is 'boot_serial' which is sets to YES by default 
> > > in gop
> > >
> > > set boot_serial=NO
> > > boot
> > >
> > > solve this issue
> >
> > Huh? This is perhaps going to be a stupid question, but where is
> > boot_serial=YES getting set? Loader will not set it by itself and UEFI
> > doesn't respect /boot.config, so this must be explicitly set in
> > /boot/loader.conf or /boot/defaults/loader.conf, but it's not clear to
> > me what's putting it there.
>
> http://src.illumos.org/source/xref/freebsd-head/usr.sbin/bhyveload/bhyveload.c#832
> is the only place I can see immediately that this might be happening,
> but do UEFI boots go through bhyveload? I'm ignorant here.

This is UEFI GOP methodvia bootrom/uefi-firmware, no bhyveload:

bhyve -AHP -s 0:0,hostbridge -s 31:0,lpc -s
4:0,ahci-cd,/tmp/FreeBSD-13.0-CURRENT-amd64-20181101-r339979-disc1.iso
-c 1 -m 1024M -s 29,fbuf,tcp=0.0.0.0:5900,w=1024,h=768,wait -l
bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd freebsd1

https://snag.gy/0MH7zU.jpg
https://snag.gy/kF5cxZ.jpg
https://snag.gy/htHMG0.jpg
https://snag.gy/vK1ALN.jpg
https://snag.gy/qKNPGU.jpg
___
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: UEFI GOP: screen goes blank during boot after loader is finished

[Subbsd]

On Thu, Nov 15, 2018 at 1:05 AM Subbsd  wrote:
>
> On Thu, Nov 15, 2018 at 12:21 AM Rebecca Cran  wrote:
> >
> > On November 14, 2018 at 2:18:04 PM, Subbsd (sub...@gmail.com) wrote:
> >>
> >>
> >> My current host: FreeBSD 13.0-CURRENT r340319 and the problem is
> >> still present.
> >
> > Rod was asking about the guest OS version, not the host though.
> >
> >
>
> I apologize, it seemed to me that I wrote earlier) Guest version:
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/FreeBSD-13.0-CURRENT-amd64-20181101-r339979-disc1.iso.xz

Hm, it seems the problem is 'boot_serial' which is sets to YES by default in gop

set boot_serial=NO
boot

solve this issue
___
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: UEFI GOP: screen goes blank during boot after loader is finished

[Subbsd]

On Thu, Nov 15, 2018 at 12:21 AM Rebecca Cran  wrote:
>
> On November 14, 2018 at 2:18:04 PM, Subbsd (sub...@gmail.com) wrote:
>>
>>
>> My current host: FreeBSD 13.0-CURRENT r340319 and the problem is
>> still present.
>
> Rod was asking about the guest OS version, not the host though.
>
>

I apologize, it seemed to me that I wrote earlier) Guest version:
https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/FreeBSD-13.0-CURRENT-amd64-20181101-r339979-disc1.iso.xz
___
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: UEFI GOP: screen goes blank during boot after loader is finished

[Subbsd]

On Wed, Nov 14, 2018 at 6:52 PM Rodney W. Grimes
 wrote:
>
> > On Wed, Nov 14, 2018 at 3:49 PM Kyle Evans  wrote:
> >
> > > Good, good, so the loader <-> kernel transition would appear to be
> > > intact and information appears good at first blush. If you don't have
> > > time to dig into this, I'll try poking at it this weekend, but it
> > > looks to be either kernel problem or VNC server.
> >
> > FreeBSD 11.{1,2} and various Linux distros boot fine with UEFI GOP in
> > the same time, the problem is only with FreeBSD 12-ALPHA+.
> > Therefore it does not look like VNC server issue.
>
> Lets make sure this is not the invalid instruction trap (CLFLUSH)
> that has already been fixed by BETA3.  Is everyone infact using
> BETA3 or later as a guest?   We know of and have fixed this other
> bug and I want to make sure we are not chassing a red hearing.


My current host: FreeBSD 13.0-CURRENT r340319  and the problem is
still present. As I recall, I first encountered this problem when
FreeBSD-CURRENT (12) moved to the ALPHA-1 state. At least a month
before the ALPHA-1, everything worked fine. At this time, the
bootloader was changed to work with lua (and the distinguishing
feature is that during this transition the boot menu lost color in the
UEFI GOP mode).
So, the first thing I thought was that it was related to the lua based
menu. Now we know that it is not. However, the root of the problem
lies at this time.
___
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: UEFI GOP: screen goes blank during boot after loader is finished

[Subbsd]

On Wed, Nov 14, 2018 at 3:49 PM Kyle Evans  wrote:

> Good, good, so the loader <-> kernel transition would appear to be
> intact and information appears good at first blush. If you don't have
> time to dig into this, I'll try poking at it this weekend, but it
> looks to be either kernel problem or VNC server.

FreeBSD 11.{1,2} and various Linux distros boot fine with UEFI GOP in
the same time, the problem is only with FreeBSD 12-ALPHA+.
Therefore it does not look like VNC server issue.
___
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: UEFI GOP: screen goes blank during boot after loader is finished

[Subbsd]

Hi,



On Tue, Nov 13, 2018 at 7:22 PM Rodney W. Grimes
 wrote:
>
> Uh oh, ok, thats not what I was thinking of then.  I do not have any
> bhyve capable hardware running on 12BETA at this time to test with.
>
> I wonder if we have a bad interaction between the loader and
> bhyve again, we have had a few of those.
>

it's broken before 12-ALPHA1, my post from 14-Sep to current@

https://lists.freebsd.org/pipermail/freebsd-current/2018-September/071206.html

probably the lua loader doesn't understand efifb/term very well
___
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 12 regression: unable to boot in UEFI/bhyve: blank screen after loader

[Subbsd]

The problem started before FreeBSD 12 ALPHA1  but still exist in ALPHA6.

If you try to run FreeBSD 12  (e.g.
FreeBSD-12.0-ALPHA6-amd64-20180914-r338675-disc1.iso from
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/12.0/
) in bhyve UEFI mode with command from handbook
(https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/virtualization-host-bhyve.html)
in chapter "21.7.5. Graphical UEFI Framebuffer for bhyve Guests" you
will see a black screen after loader:

https://pasteboard.co/HDSVqEE.png

Apparently, this is due to recent changes in the [lua]loader.

How to reproduce:

1) fetch -o /tmp/FreeBSD-12.0-ALPHA6-amd64-20180914-r338675-disc1.iso
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-ALPHA6-amd64-20180914-r338675-disc1.iso

2) truncate -s1g /tmp/guest.img

3) ifconfig tap1 create

4) kldload vmm

5) pkg install -y  uefi-edk2-bhyve

6) bhyve -AHP -s 0:0,hostbridge -s 31:0,lpc \
-s 2:0,virtio-net,tap1 -s 3:0,virtio-blk,/tmp/guest.img \
-s 4:0,ahci-cd,/tmp/FreeBSD-12.0-ALPHA6-amd64-20180914-r338675-disc1.iso
-c 4 -m 1024M \
-s 29,fbuf,tcp=0.0.0.0:5900,w=800,h=600,wait \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \

7) vncviewer :5900
___
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: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4

[Subbsd]

On Thu, Sep 6, 2018 at 3:28 AM Mark Johnston  wrote:
>
> On Wed, Sep 05, 2018 at 11:15:03PM +0300, Subbsd wrote:
> > On Wed, Sep 5, 2018 at 5:58 PM Allan Jude  wrote:
> > >
> > > On 2018-09-05 10:04, Subbsd wrote:
> > > > Hi,
> > > >
> > > > I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12
> > > > to latest revision (r338466 the moment) and related to ARC.
> > > >
> > > > I can not say which revision was before except that the newver.sh
> > > > pointed to ALPHA3.
> > > >
> > > > Problems are observed if you try to limit ARC. In my case:
> > > >
> > > > vfs.zfs.arc_max="128M"
> > > >
> > > > I know that this is very small. However, for two years with this there
> > > > were no problems.
> > > >
> > > > When i send SIGINFO to process which is currently working with ZFS, i
> > > > see "arc_reclaim_waiters_cv":
> > > >
> > > > e.g when i type:
> > > >
> > > > /bin/csh
> > > >
> > > > I have time (~5 seconds) to press several times 'ctrl+t' before csh is 
> > > > executed:
> > > >
> > > > load: 0.70  cmd: csh 5935 [arc_reclaim_waiters_cv] 1.41r 0.00u 0.00s 0% 
> > > > 3512k
> > > > load: 0.70  cmd: csh 5935 [zio->io_cv] 1.69r 0.00u 0.00s 0% 3512k
> > > > load: 0.70  cmd: csh 5935 [arc_reclaim_waiters_cv] 1.98r 0.00u 0.01s 0% 
> > > > 3512k
> > > > load: 0.73  cmd: csh 5935 [arc_reclaim_waiters_cv] 2.19r 0.00u 0.01s 0% 
> > > > 4156k
> > > >
> > > > same story with find or any other commans:
> > > >
> > > > load: 0.34  cmd: find 5993 [zio->io_cv] 0.99r 0.00u 0.00s 0% 2676k
> > > > load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.13r 0.00u 0.00s 
> > > > 0% 2676k
> > > > load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.25r 0.00u 0.00s 
> > > > 0% 2680k
> > > > load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.38r 0.00u 0.00s 
> > > > 0% 2684k
> > > > load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.51r 0.00u 0.00s 
> > > > 0% 2704k
> > > > load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.64r 0.00u 0.00s 
> > > > 0% 2716k
> > > > load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.78r 0.00u 0.00s 
> > > > 0% 2760k
> > > >
> > > > this problem goes away after increasing vfs.zfs.arc_max
> > > > ___
> > > > 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"
> > > >
> > >
> > > Previously, ZFS was not actually able to evict enough dnodes to keep
> > > your arc_max under 128MB, it would have been much higher based on the
> > > number of open files you had. A recent improvement from upstream ZFS
> > > (r337653 and r337660) was pulled in that fixed this, so setting an
> > > arc_max of 128MB is much more effective now, and that is causing the
> > > side effect of "actually doing what you asked it to do", in this case,
> > > what you are asking is a bit silly. If you have a working set that is
> > > greater than 128MB, and you ask ZFS to use less than that, it'll have to
> > > constantly try to reclaim memory to keep under that very low bar.
> > >
> >
> > Thanks for comments. Mark was right when he pointed to r338416 (
> > https://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c?r1=338416=338415=338416
> > ). Commenting aggsum_value returns normal speed regardless of the rest
> > of the new code from upstream.
> > I would like to repeat that the speed with these two lines is not just
> > slow, but _INCREDIBLY_ slow! Probably, this should be written in the
> > relevant documentation for FreeBSD 12+
>
> Could you please retest with the patch below applied, instead of
> reverting r338416?
>
> diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c 
> b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
> index 2bc065e12509..9b039b7d4a96 100644
> --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
> +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
> @@ -538,7 +538,7 @@ typedef struct arc_state {
>   */
>  int zfs_

Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4

[Subbsd]

On Wed, Sep 5, 2018 at 5:58 PM Allan Jude  wrote:
>
> On 2018-09-05 10:04, Subbsd wrote:
> > Hi,
> >
> > I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12
> > to latest revision (r338466 the moment) and related to ARC.
> >
> > I can not say which revision was before except that the newver.sh
> > pointed to ALPHA3.
> >
> > Problems are observed if you try to limit ARC. In my case:
> >
> > vfs.zfs.arc_max="128M"
> >
> > I know that this is very small. However, for two years with this there
> > were no problems.
> >
> > When i send SIGINFO to process which is currently working with ZFS, i
> > see "arc_reclaim_waiters_cv":
> >
> > e.g when i type:
> >
> > /bin/csh
> >
> > I have time (~5 seconds) to press several times 'ctrl+t' before csh is 
> > executed:
> >
> > load: 0.70  cmd: csh 5935 [arc_reclaim_waiters_cv] 1.41r 0.00u 0.00s 0% 
> > 3512k
> > load: 0.70  cmd: csh 5935 [zio->io_cv] 1.69r 0.00u 0.00s 0% 3512k
> > load: 0.70  cmd: csh 5935 [arc_reclaim_waiters_cv] 1.98r 0.00u 0.01s 0% 
> > 3512k
> > load: 0.73  cmd: csh 5935 [arc_reclaim_waiters_cv] 2.19r 0.00u 0.01s 0% 
> > 4156k
> >
> > same story with find or any other commans:
> >
> > load: 0.34  cmd: find 5993 [zio->io_cv] 0.99r 0.00u 0.00s 0% 2676k
> > load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.13r 0.00u 0.00s 0% 
> > 2676k
> > load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.25r 0.00u 0.00s 0% 
> > 2680k
> > load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.38r 0.00u 0.00s 0% 
> > 2684k
> > load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.51r 0.00u 0.00s 0% 
> > 2704k
> > load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.64r 0.00u 0.00s 0% 
> > 2716k
> > load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.78r 0.00u 0.00s 0% 
> > 2760k
> >
> > this problem goes away after increasing vfs.zfs.arc_max
> > ___
> > 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"
> >
>
> Previously, ZFS was not actually able to evict enough dnodes to keep
> your arc_max under 128MB, it would have been much higher based on the
> number of open files you had. A recent improvement from upstream ZFS
> (r337653 and r337660) was pulled in that fixed this, so setting an
> arc_max of 128MB is much more effective now, and that is causing the
> side effect of "actually doing what you asked it to do", in this case,
> what you are asking is a bit silly. If you have a working set that is
> greater than 128MB, and you ask ZFS to use less than that, it'll have to
> constantly try to reclaim memory to keep under that very low bar.
>
> --
> Allan Jude
>


Hi,

Thanks for comments. Mark was right when he pointed to r338416 (
https://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c?r1=338416=338415=338416
). Commenting aggsum_value returns normal speed regardless of the rest
of the new code from upstream.
I would like to repeat that the speed with these two lines is not just
slow, but _INCREDIBLY_ slow! Probably, this should be written in the
relevant documentation for FreeBSD 12+
___
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"

ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4

[Subbsd]

Hi,

I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12
to latest revision (r338466 the moment) and related to ARC.

I can not say which revision was before except that the newver.sh
pointed to ALPHA3.

Problems are observed if you try to limit ARC. In my case:

vfs.zfs.arc_max="128M"

I know that this is very small. However, for two years with this there
were no problems.

When i send SIGINFO to process which is currently working with ZFS, i
see "arc_reclaim_waiters_cv":

e.g when i type:

/bin/csh

I have time (~5 seconds) to press several times 'ctrl+t' before csh is executed:

load: 0.70  cmd: csh 5935 [arc_reclaim_waiters_cv] 1.41r 0.00u 0.00s 0% 3512k
load: 0.70  cmd: csh 5935 [zio->io_cv] 1.69r 0.00u 0.00s 0% 3512k
load: 0.70  cmd: csh 5935 [arc_reclaim_waiters_cv] 1.98r 0.00u 0.01s 0% 3512k
load: 0.73  cmd: csh 5935 [arc_reclaim_waiters_cv] 2.19r 0.00u 0.01s 0% 4156k

same story with find or any other commans:

load: 0.34  cmd: find 5993 [zio->io_cv] 0.99r 0.00u 0.00s 0% 2676k
load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.13r 0.00u 0.00s 0% 2676k
load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.25r 0.00u 0.00s 0% 2680k
load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.38r 0.00u 0.00s 0% 2684k
load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.51r 0.00u 0.00s 0% 2704k
load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.64r 0.00u 0.00s 0% 2716k
load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.78r 0.00u 0.00s 0% 2760k

this problem goes away after increasing vfs.zfs.arc_max
___
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: kernel crash r326347: Cannot access memory at address 0x65657246

[Subbsd]

The same problem started the last week. The problem arises when on the
CPU + I/O load  - also when I recompile ports.
I'm not completely sure but apparently I see a problem on the server (
with the same revision ) with SSDs only:
on slow HDD disk still did not hang, while the server with SSD dies
within 10-15 minutes after poudriere launching

OS: FreeBSD 12.0-CURRENT amd64 r326361
real memory  = 68719476736 (65536 MB)
CPU: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (3408.17-MHz K8-class CPU)
FS: ZFS

On Wed, Nov 29, 2017 at 11:56 AM, Hartmann, O.  wrote:
> Since yesterday's CURRENT update, I face worse and nasty problems on
> all of our CURRENT systems!
>
> Most recent CURRENT, as with r326363, crashes on booting the kernel, in
> another case the kernel is stuck and freezing after initialising the
> USB subsystem (the last thing I see on screen, keyboard fully
> functional, but no ACPI shutdown any more).
>
> Another box is now two days in row after subsequent updates of CURRENT
> multiple times a day crashing on load on ZFS filesystem. The last
> known half-ways good kernel is 12.0-CURRENT #157 r326347: Wed Nov 29
> 01:02:47 CET 2017 amd64. When performing
> buildworld/buildkernel/relaese/package or poudriere on a ZFS
> filessystem, I can now bring down the system almost in a reproducable
> way.
>
> Last error seen when core is dumped is:
>
> /dev/stdin:1: Error in sourced command file:
> Cannot access memory at address 0x65657246
> /dev/stdin:1: Error in sourced command file:
> Cannot access memory at address 0x65657246
> /dev/stdin:1: Error in sourced command file:
> Cannot access memory at address 0x65657246
> /dev/stdin:1: Error in sourced command file:
> Cannot access memory at address 0x65657246
> ___
> 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-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-current, panic on UEFI boot after recent changes

[Subbsd]

Hi,

( I apologize if this is a duplicate - first I wrote this as reply-all
on https://lists.freebsd.org/pipermail/freebsd-current/2017-March/064971.html
thread )

After recent changes and fixes (
https://lists.freebsd.org/pipermail/freebsd-current/2017-March/065093.html
) I still had problems on host with increased EFI_STAGING_SIZE value.
I have custom FreeBSD distribution which has a sufficiently large
mfsroot which is loaded through UEFI mode.

To solve the problem, it was suggested to increase this variable and
rebuild /sys/boot:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209944

Also, it has to be increased periodically for some reason:

https://svnweb.freebsd.org/base/stable/11/sys/boot/efi/loader/copy.c?r1=305779=305778=305779

I've try to ask why than threatens to increase this parameter at once
large (or make it dependent on RAM):
https://lists.freebsd.org/pipermail/freebsd-hackers/2016-November/050142.html
but there are no answer options.

At the moment, on r315141 boot via UEFI is fine with default
EFI_STAGING_SIZE (64)

With EFI_STAGING_SIZE=768 i got panic after recent changes with follow message:

failed to allocate staging area:9
failed to allocate stating area
Failed to start image provided by ZFS (5)

http://pasteboard.co/IvbhU9Ffu.jpg

I believe that there mfsroot may be greater than 64MB soon or later.

Also there are no problems with loading big mfsroot images when MBR
method is used.

PS:  I have ZFS-on-root system. With EFI_STAGING_SIZE=768 I lived with
constant CURRENT svnup/rebuilds for about a year. So I will be glad if
you pay attention to this.

PPS: How to reproduce:

1) EFI_STAGING_SIZE=768 in /etc/make.conf
2) make -C /sys/boot clean
3) make -C /sys/boot
4) make -C /sys/boot install
5) reboot

Thanks!
___
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: Boot failure - svn up from this morning

[Subbsd]

Hi,

I had the same problems, however, there is one more regression after
these changes. It stably reproduces if you use EFI_STAGING_SIZE.
I have custom FreeBSD distributive which has a sufficiently large
mfsroot which is loaded through UEFI mode.

To solve the problem, it was suggested to increase this variable and
rebuild /sys/boot:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209944

Also, it has to be increased periodically for some reason:

https://svnweb.freebsd.org/base/stable/11/sys/boot/efi/loader/copy.c?r1=305779=305778=305779

I've try to ask why than threatens to increase this parameter at once
large (or make it dependent on RAM):
https://lists.freebsd.org/pipermail/freebsd-hackers/2016-November/050142.html
but there are no answer options.

At the moment, on r315141 boot via UEFI is fixed without EFI_STAGING_SIZE.

With EFI_STAGING_SIZE=768 i got regression after last changes in panic
with follow message:

failed to allocate staging area:9
failed to allocate stating area
Failed to start image provided by ZFS (5)

http://pasteboard.co/IvbhU9Ffu.jpg

I believe that there mfsroot may be greater than 64MB soon or later.

Also there are no problems with loading big mfsroot images when MBR
method is used.

PS:  I have ZFS-on-root system. With EFI_STAGING_SIZE=768 I lived with
constant CURRENT svnup/rebuilds for about a year. So I will be glad if
you pay attention to this.

PPS: How to reproduce:

1) EFI_STAGING_SIZE=768 in /etc/make.conf
2) make -C /sys/boot clean
3) make -C /sys/boot
4) make -C /sys/boot install
5) reboot

Thanks!
___
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: effect of strip(1) on du(1)

[Subbsd]

On Fri, Mar 3, 2017 at 2:04 AM, Peter Jeremy <pe...@rulingia.com> wrote:
> On 2017-Mar-02 22:29:46 +0300, Subbsd <sub...@gmail.com> wrote:
>>During some interval after strip call, du will show 512B for any file.
>>If execute du(1) after strip(1) without delay, this behavior is reproduced 
>>100%:
>
> What filesystem are you using?  strip(1) rewrites the target file and du(1)
> reports the number of blocks reported by stat(2).  It seems that you are
> hitting a situation where the file metadata isn't immediately updated.
>
> --
> Peter Jeremy


Got it. My filesystem is ZFS. Looks like when ZFS open and write data
to file, we get wrong number of blocks during a small interval after
writing. Thanks for pointing this out!
___
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"

effect of strip(1) on du(1)

[Subbsd]

Hi,

Not sure for FreeBSD < 12, but i found interesting behavior strip
effect(1) on du(1) command:

--
%  strip /bin/pax && sleep 4 && du -sh /bin/pax
 65K/bin/pax
% strip /bin/pax && sleep 3 && du -sh /bin/pax
 65K/bin/pax
% strip /bin/pax && sleep 2 && du -sh /bin/pax
512B/bin/pax
% strip /bin/pax && sleep 3 && du -sh /bin/pax
 65K/bin/pax
--

During some interval after strip call, du will show 512B for any file.
If execute du(1) after strip(1) without delay, this behavior is reproduced 100%:

% strip /bin/sh && du /bin/sh
1   /bin/sh

What such behavior is connected with?
___
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: Mozilla firefox freezes/zombie on FreeBSD current

[Subbsd]

On Tue, Dec 27, 2016 at 6:31 PM, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> On Mon, Dec 26, 2016 at 10:29:33PM +0300, Subbsd wrote:
>
>> Hi,
>>
>> On recent FreeBSD version (tested on two host: one from
>> svn://svn.freebsd.org/base/head ( r310507 now) and second from
>> https://github.com/FreeBSDDesktop/freebsd-base-graphics.git /
>> drm-next-4.7 ) and latest firefox ( firefox-50.1.0_4,1 ) I often get
>> into a situation where firefox is hands.
>
> What about downgrade to ff-48?

Sorry for delay. Not sure but it is a fresh error so far as I
regularly update packages ( including firefox ) and FreeBSD revision.
Patch from 
https://lists.freebsd.org/pipermail/freebsd-current/2016-December/064254.html
fix this behavior on both my system ( drm-next and master branch ),
thanks to Konstantin!
___
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"

Mozilla firefox freezes/zombie on FreeBSD current

[Subbsd]

Hi,

On recent FreeBSD version (tested on two host: one from
svn://svn.freebsd.org/base/head ( r310507 now) and second from
https://github.com/FreeBSDDesktop/freebsd-base-graphics.git /
drm-next-4.7 ) and latest firefox ( firefox-50.1.0_4,1 ) I often get
into a situation where firefox is hands.

It looks like unresponsive window: https://snag.gy/gKPhnb.jpg

with follow information from procstat:

---
% procstat -t 18827
  PIDTID COMMTDNAME  CPU  PRI STATE   WCHAN
18827 100754 firefox --1  152 sleep   uwait
18827 101508 firefox Gecko_IOThread   -1  130 sleep   kqread
18827 101509 firefox Socket Thread-1  128 sleep   select
18827 101510 firefox JS Watchdog  -1  121 sleep   uwait
18827 101511 firefox JS Helper-1  120 sleep   uwait
18827 101512 firefox JS Helper-1  120 sleep   uwait
18827 101513 firefox JS Helper-1  120 sleep   uwait
18827 101514 firefox JS Helper-1  120 sleep   uwait
18827 101515 firefox JS Helper-1  120 sleep   uwait
18827 101516 firefox JS Helper-1  120 sleep   uwait
18827 101517 firefox JS Helper-1  120 sleep   uwait
18827 101518 firefox JS Helper-1  120 sleep   uwait
18827 101519 firefox JS Helper-1  120 sleep   uwait
18827 101520 firefox JS Helper-1  120 sleep   uwait
18827 101521 firefox JS Helper-1  120 sleep   uwait
18827 101522 firefox JS Helper-1  120 sleep   uwait
18827 101523 firefox Hang Monitor -1  132 sleep   uwait
18827 101524 firefox BgHangManager-1  125 sleep   uwait
18827 101525 firefox --1  129 sleep   select
18827 101526 firefox --1  129 sleep   select
18827 101527 firefox Cache2 I/O   -1  120 sleep   uwait
18827 101528 firefox Timer-1  120 sleep   uwait
18827 101529 firefox DataStorage  -1  145 sleep   uwait
18827 101530 firefox GMPThread-1  148 sleep   uwait
18827 101532 firefox --1  149 sleep   kqread
18827 101533 firefox HTML5 Parser -1  152 sleep   uwait
18827 101534 firefox IPDL Background  -1  138 sleep   uwait
18827 101538 firefox ImgDecoder #1-1  152 sleep   uwait
18827 101539 firefox ImgDecoder #2-1  152 sleep   uwait
18827 101540 firefox ImgDecoder #3-1  152 sleep   uwait
18827 101541 firefox ImgDecoder #4-1  152 sleep   uwait
18827 101542 firefox ImgDecoder #5-1  152 sleep   uwait
18827 101543 firefox ImgDecoder #6-1  152 sleep   uwait
18827 101544 firefox ImgDecoder #7-1  152 sleep   uwait
18827 101545 firefox ImageIO  -1  152 sleep   uwait
18827 101546 firefox Compositor   -1  152 sleep   vmpfw
18827 101547 firefox SoftwareVsyncThread  -1  120 sleep   uwait
18827 101548 firefox DOM Worker   -1  120 sleep   uwait
18827 101552 firefox DOM Worker   -1  120 sleep   uwait
18827 101556 firefox StreamTrans #11  -1  120 sleep   uwait
18827 101557 firefox URL Classifier   -1  152 sleep   uwait
18827 101558 firefox ImageBridgeChild -1  152 sleep   uwait
18827 101559 firefox Cache I/O-1  152 sleep   uwait
18827 101560 firefox mozStorage #1-1  152 sleep   uwait
18827 101561 firefox mozStorage #2-1  152 sleep   uwait
---

--
% procstat -k 18827
  PIDTID COMMTDNAME  KSTACK
18827 100754 firefox -   mi_switch
sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait
__umtx_op_wait_uint_private amd64_syscall Xfast_syscall
18827 101508 firefox Gecko_IOThread  mi_switch
sleepq_catch_signals sleepq_wait_sig _sleep kqueue_kevent kern_kevent
sys_kevent amd64_syscall Xfast_syscall
18827 101509 firefox Socket Thread   mi_switch
sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait kern_poll
sys_poll amd64_syscall Xfast_syscall
18827 101510 firefox JS Watchdog mi_switch
sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait
__umtx_op_wait_uint_private amd64_syscall Xfast_syscall
18827 101511 firefox JS Helper   mi_switch
sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait
__umtx_op_wait_uint_private amd64_syscall Xfast_syscall
18827 101512 firefox JS Helper   mi_switch
sleepq_catch_signals 

syslogd 100% cpu usage on recent FreeBSD version

[Subbsd]

Probably after https://svnweb.freebsd.org/base?view=revision=310494,
 syslogd eat 100% cpu with follow messages:

Dec 24 14:19:15 samson syslogd: select: Bad file descriptor
Dec 24 14:19:45 samson last message repeated 464140 times
Dec 24 14:20:38 samson last message repeated 835899 times

truss -f for syslogd -ss:

http://pastebin.com/6XxmX89q
___
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-current, ioctl() invalid arguments on microcode update

[Subbsd]

Hello,

Not sure about FreeBSD 11 or 10, but when you try to use cpuctl(4) and
Intel microcode from
http://git.exherbo.org/summer/packages/firmware/intel-microcode/index.html
this causes an error.

CC for maintainer of sysutils/devcpu-data, but not sure this is port
problem. Possible KPI was changed?

if the problem is complex, may be necessary to mark the port not compatible with

.if ${OPSYS} == FreeBSD && ${OSVERSION} < 120
IGNORE= does not support FreeBSD versions < 12.0
.endif

How to reproduce:

% make -C /usr/ports/sysutils/devcpu-data install && service
microcode_update onestart

log:

Updating cpucodes...
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl0 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl0 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl1 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl1 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl2 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl2 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl3 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl3 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl4 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl4 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl5 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl5 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl6 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl6 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl7 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_009d_009e.fw: updating
cpu /dev/cpuctl7 from rev 0x55 to rev 0x9e... failed.
cpucontrol: ioctl(): Invalid argument
Done.
___
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: commits between r305191 - r305211 broke zfs list

[Subbsd]

Thanks for  the pointer, after server rebooting to new kernel problem is gone

On Sun, Sep 4, 2016 at 10:08 AM, Peter Wemm <pe...@wemm.org> wrote:
> On Saturday, September 03, 2016 10:31:04 PM Steven Hartland wrote:
>> Out of sync kernel / world?
>>
>> Do you have a crash dump?
>
> This has caused a considerable amount of excitement on the freebsd.org
> cluster.  Having kernel+world out of sync causes zfs(8) to abort rather
> ungracefully.
>
>> On 03/09/2016 21:50, Subbsd wrote:
>> > Hi.
>> >
>> > Can anybody test of output for:
>> >
>> > zfs list
>> >
>> > command on FreeBSD current after r305211 ? On my hosts his leads to
>> > zfs segfault.
>
> --
> Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
> UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246
___
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"

commits between r305191 - r305211 broke zfs list

[Subbsd]

Hi.

Can anybody test of output for:

zfs list

command on FreeBSD current after r305211 ? On my hosts his leads to
zfs segfault.
___
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: shells/bash port, add a knob which symlinks to /bin/bash ?

[Subbsd]

On Sat, Sep 13, 2014 at 2:23 AM, Craig Rodrigues rodr...@freebsd.org wrote:
 Hi,

 I could live with this solution of additional port outside of the main
 bash port, which creates the symlink and updates /etc/shells.

 One other thing I am seeing is that many, many shell scripts are written
 assuming #!/bin/bash.
 Forcing all upstream script writers to switch to #!/usr/bin/env bash, or
 to convert their scripts to #!/bin/sh and remove all bash-specific
 behaviors, is getting harder and harder,
 since many people are exposed to MacOS X and Linux on desktops.

 --
 Craig



 On Fri, Sep 12, 2014 at 3:02 PM, Alfred Perlstein bri...@mu.org wrote:

 The correct thing is to make a port/pkg that installs the symlink and
 /etc/shells this for the user.

 There is no need for changes to 'base' nor do we need a change to the
 system port.

 -Alfred


 On 9/12/14 2:40 PM, Baptiste Daroussin wrote:

 On Fri, Sep 12, 2014 at 02:12:45PM -0700, Craig Rodrigues wrote:

 Hi,

 In the last 3 jobs that I have worked at, there have been
 a mix of Linux machines and FreeBSD machines.
 When using an NIS or LDAP environment where
 there is a single login across multiple machines, it is useful to
 have a single shell setting.

 Since Linux and MacOS X have /bin/bash as the shell,
 in order to get the FreeBSD boxes to play in this environment,
 I have seen admins do the following on FreeBSD setups:
 ln -s /usr/local/bin/bash /bin/bash

 or

 ln /usr/local/bin/bash /bin/bash

 and then make sure that /etc/shells as:
 /usr/local/bin/bash
 /bin/bash

 Can we add an optional knob (turned off by default) which creates this
 symlink
 and updates /etc/shells?

 This would help with interoperability of FreeBSD hosts in environments
 mixed
 with Linux and MacOS X.

  Please no, no and no!

 We are fighting for a very long time to prevent the ports to pollute base.

 We have added the shebangfix USES to be able to catch with up with
 cleanup this
 properly as well as a qa test to discover it automatically.

 no interpreters at all have a symlink in base but perl and this one is
 going to
 be removed.

 If you want interoperability just use /usr/bin/env bash as a shebang. Btw
 you
 cannot get interoprability with OS-X in there because the bash they do
 provide
 is the last GPL-2 recent bash have many incompatiblities with this old
 version.

 regards,
 Bapt



Looks like variant symlink is may be useful for solving this problem
and it is not cluttered base

https://wiki.freebsd.org/200808DevSummit?action=AttachFiledo=gettarget=variant-symlinks-for-freebsd.pdf
___
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: [Heads Up] RCS removed from base

[Subbsd]

On Mon, Oct 7, 2013 at 6:43 AM, Eitan Adler li...@eitanadler.com wrote:

 Hey all,

 RCS was removed from the base system in r256095.  If you still want to
 use RCS please install either devel/rcs or devel/rcs57.  If not, be
 sure to check out the alternatives (pun stolen and intended).


rc.subr use rcs in backup_file function which no one uses. Maybe remove
backup_fіle that it does not provoke any errors?
___
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

msk0: watchdog timeout in the HEAD

[Subbsd]

After updating kernel from 9-STABLE to 10-CURRENT (amd64) msk
interfaces stop working with watchdog timout error.  Watchdog arises
at a traffic 100-300+ Kb, for example:

make - C /usr/ports fetchindex

(on the fresh boot) reaches 11-15%  before watchdog coming

pciconf -vl | grep -A4 ^msk
mskc0@pci0:3:0:0:   class=0x02 card=0x84391043 chip=0x438111ab
rev=0x11 hdr=0x00
vendor = 'Marvell Technology Group Ltd.'
device = 'Yukon Optima 88E8059 [PCIe Gigabit Ethernet
Controller with AVB]'
class  = network
subclass   = ethernet

msk(4)-related tunables doesn't change behavior.

svn://svn.freebsd.org/base/stable/9 works fine. What more can i give
for diagnostics?
___
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 9.0-beta2 can't reboot with ZFS raidz2

[Subbsd]

Hi,

My FreeBSD box (amd64, beta2, raidz2 on three disk) can't reboot after
syncing buffer stage:

http://www.scrnshots.com/users/subbsd/screenshots/293839

Also i got this issue on 8-disk system (GPT/ZFS).

With UFS filesystem all ok on the same hardware
___
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

part of the application to compile stops

[Subbsd]

Hello,

 From some revision of FreeBSD 9/Current, part of the application during
configure stops with a message


...

checking how to ignore standart include path...

...



One such application - /usr/ports/devel/ORBit.

If at this moment to press Ctrl + D - work resumes (and ive see:

sed: confdefs.h: No such file or directory

)


Looks like confdefs.h from some time move from place where sed waiting for
him.
___
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

check for jailed environment for adjkerntz

[Subbsd]

jail with complete type have standard crontab a file of tasks. However not
all standard task are adapted for work in jail an environment. For example
adjkerntz which generates

adjkerntz [46733]: sysctl (set: machdep.wall_cmos_clock): Operation not
permitted

I suggest to give adjkerntz concept about jail in which to it it is not
necessary to work:


--- adjkerntz.c-orig2010-03-01 01:53:01.0 +0300
+++ adjkerntz.c 2010-03-01 02:03:45.0 +0300
@@ -80,7 +80,7 @@
struct tm local;
struct timeval tv, *stv;
struct timezone tz, *stz;
-   int kern_offset, wall_clock, disrtcset;
+   int kern_offset, wall_clock, disrtcset, jailed;
size_t len;
/* Avoid time_t here, can be unsigned long or worse */
long offset, localsec, diff;
@@ -118,6 +118,16 @@
if (init)
sleep_mode = True;

+len = sizeof(jailed);
+if (sysctlbyname(security.jail.jailed, jailed, len, NULL, 0) ==
-1) {
+syslog(LOG_ERR, sysctl(\security.jail.jailed\): %m);
+return 1;
+}
+if (jailed!=0) {
+//not for jail
+return 1;
+}
+
sigemptyset(mask);
sigemptyset(emask);
sigaddset(mask, SIGTERM);
___
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