Re: nvidia-driver not work

[Ivan Klymenko]

В Sun, 15 Aug 2010 02:35:02 +0100
Álvaro Castillo  пишет:

> This is my kernel
> 
> http://pastebin.com/1NpvzNp6
> 
try the following:
Delete: AGP device from the kernel config
rebuild new kernel
and boot into single user mode, 
mount -u /
mount -a
and reinstall the NVIDIA driver port ...
cd /usr/ports/x11/nvidia-driver && make reinstall clean
reboot
___
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: nvidia-driver not work

[Ivan Klymenko]

В Tue, 17 Aug 2010 09:52:50 -0400
John Baldwin  пишет:

> On Saturday, August 14, 2010 9:35:02 pm Álvaro Castillo wrote:
> > $ dmesg (cut)
> > 
> > panic: mutex page lock not owned at /usr/src/sys/vm/vm_page.c:1759
> > cpuid = 0
> > Uptime: 3m35s
> 
> Use the latest nvidia driver from the website (256.44) and not from
> the port.
> 
Here the test port...
___
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: nvidia-driver not work

[Ivan Klymenko]

> >>> $ dmesg (cut)
> >>>
> >>> panic: mutex page lock not owned at /usr/src/sys/vm/vm_page.c:1759
> >>> cpuid = 0
> >>> Uptime: 3m35s
> >>
> >> Use the latest nvidia driver from the website (256.44) and not from
> >> the port.
> >>
> > Here the test port...
> 
> Sorry, I am afraid there is no attachment

another attempt...
___
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"

system hangs after logging into gdm

[Ivan Klymenko]

Hi!

My system has an svn r213507

FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507: Sun Oct
10 22:43:18 EEST 2010 r...@nonamehost:/usr/obj/usr/src/sys/mk9
amd64

after upgrading to r213666 my system hangs after logging into gdm

had to go back to r213507

Thanks!
___
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: system hangs after logging into gdm

[Ivan Klymenko]

В Sun, 10 Oct 2010 15:37:55 -0700
Garrett Cooper  пишет:

> On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko  wrote:
> > Hi!
> >
> > My system has an svn r213507
> >
> > FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507: Sun
> > Oct 10 22:43:18 EEST 2010
> > r...@nonamehost:/usr/obj/usr/src/sys/mk9 amd64
> >
> > after upgrading to r213666 my system hangs after logging into gdm
> >
> > had to go back to r213507
> 
> What video driver are you using?
> -Garrett
> 
> 

NVIDIA Driver Version: 260.19.06

but Xorg successfully starts and GDM login screen appears
system hangs after a few seconds after entering the password ...
I noticed the following: gvfsd does not create a directory of the
form / var/tmp/gvfs-- may hang system due to gvfsd?
___
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: system hangs after logging into gdm

[Ivan Klymenko]

В Mon, 11 Oct 2010 11:10:17 -0400
John Baldwin  пишет:

> On Monday, October 11, 2010 3:59:04 am Ivan Klymenko wrote:
> > В Sun, 10 Oct 2010 15:37:55 -0700
> > Garrett Cooper  пишет:
> > 
> > > On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko 
> > > wrote:
> > > > Hi!
> > > >
> > > > My system has an svn r213507
> > > >
> > > > FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507:
> > > > Sun Oct 10 22:43:18 EEST 2010
> > > > r...@nonamehost:/usr/obj/usr/src/sys/mk9 amd64
> > > >
> > > > after upgrading to r213666 my system hangs after logging into
> > > > gdm
> > > >
> > > > had to go back to r213507
> > > 
> > > What video driver are you using?
> > > -Garrett
> > > 
> > > 
> > 
> > NVIDIA Driver Version: 260.19.06
> > 
> > but Xorg successfully starts and GDM login screen appears
> > system hangs after a few seconds after entering the password ...
> > I noticed the following: gvfsd does not create a directory of the
> > form / var/tmp/gvfs-- may hang system due to gvfsd?
> 
> Did you recompile the nvidia.ko module after upgrading?
> 

Yes, of course.
___
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: system hangs after logging into gdm

[Ivan Klymenko]

В Mon, 11 Oct 2010 08:37:05 -0700
Garrett Cooper  пишет:

> On Mon, Oct 11, 2010 at 2:04 AM, Andriy Gapon  wrote:
> > on 11/10/2010 10:59 Ivan Klymenko said the following:
> >> В Sun, 10 Oct 2010 15:37:55 -0700
> >> Garrett Cooper  пишет:
> >>
> >>> On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko 
> >>> wrote:
> >>>> Hi!
> >>>>
> >>>> My system has an svn r213507
> >>>>
> >>>> FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507:
> >>>> Sun Oct 10 22:43:18 EEST 2010
> >>>> r...@nonamehost:/usr/obj/usr/src/sys/mk9 amd64
> >>>>
> >>>> after upgrading to r213666 my system hangs after logging into gdm
> >>>>
> >>>> had to go back to r213507
> >>>
> >>> What video driver are you using?
> >>> -Garrett
> >>>
> >>>
> >>
> >> NVIDIA Driver Version: 260.19.06
> >>
> >> but Xorg successfully starts and GDM login screen appears
> >> system hangs after a few seconds after entering the password ...
> >> I noticed the following: gvfsd does not create a directory of the
> >> form / var/tmp/gvfs-- may hang system due to gvfsd?
> 
> That seems a bit interesting.
> The other thing you can do is start running a binary search on the
> breakage because you have a range of good versions vs bad versions to
> look through.
> 
> > If you can access the system remotely or quickly switch to console,
> > then you should be able to examine state of your system and get
> > some facts.
> 
> If you have ddb compiled into the kernel (and you should) try
> CTRL-ALT-ESC after the lockup. You may also want to try KGDB instead,
> which would require a serial connection (RS-232 or IEEE-1394).
> HTH,
> -Garrett


Thank you!

I'll try to recompile the kernel with DDB shortly and after blocking
press ctrl+alt+esc, which would show the trace output...
___
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: system hangs after logging into gdm

[Ivan Klymenko]

В Mon, 11 Oct 2010 22:49:29 +0400
Anonymous  пишет:

> Ivan Klymenko  writes:
> 
> > В Sun, 10 Oct 2010 15:37:55 -0700
> > Garrett Cooper  writes:
> >
> >>On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko 
> >>wrote:
> >>> My system has an svn r213507
> >>>
> >>> FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507: Sun
> >>> Oct 10 22:43:18 EEST 2010
> >>> r...@nonamehost:/usr/obj/usr/src/sys/mk9 amd64
> >>>
> >>> after upgrading to r213666 my system hangs after logging into gdm
> >>>
> >>> had to go back to r213507
> >>
> >> What video driver are you using?
> >
> > NVIDIA Driver Version: 260.19.06
> 
> Do you have local patches to make it compile on /head? Could they be
> the cause of the hang? 260.19.04 and 260.19.06 use taskqueue_run(9)
> that was removed in /h...@r210377.

patches exist, but the cause is not in them - as Xorg starts, the
system hangs after a few seconds after entering the password box to
login gdm
without a password - it works

--- src/nvidia_os.c.orig2010-09-15 01:26:27.0 +0300
+++ src/nvidia_os.c 2010-09-15 01:27:51.0 +0300
@@ -13,6 +13,67 @@
 #include "nv.h"
 #include "nv-freebsd.h"
 
+struct taskqueue {
+STAILQ_HEAD(, task) tq_queue;
+const char  *tq_name;
+taskqueue_enqueue_fntq_enqueue;
+void*tq_context;
+struct task *tq_running;
+struct mtx  tq_mutex;
+struct thread   **tq_threads;
+int tq_tcount;
+int tq_spin;
+int tq_flags;
+};
+
+static void taskqueue_run(struct taskqueue *, struct task **);
+
+static __inline void
+TQ_LOCK(struct taskqueue *tq)
+{
+if (tq->tq_spin)
+   mtx_lock_spin(&tq->tq_mutex);
+else
+mtx_lock(&tq->tq_mutex);
+}
+
+static __inline void
+TQ_UNLOCK(struct taskqueue *tq)
+{
+   if (tq->tq_spin)
+  mtx_unlock_spin(&tq->tq_mutex);
+   else
+  mtx_unlock(&tq->tq_mutex);
+}
+
+static void
+taskqueue_run(struct taskqueue *queue, struct task **tpp)
+{   
+   struct task *task;
+   int pending;
+
+   mtx_assert(&queue->tq_mutex, MA_OWNED);
+   while (STAILQ_FIRST(&queue->tq_queue)) {
+   /*
+   * Carefully remove the first task from the queue and
+   * zero its pending count.
+   */
+   task = STAILQ_FIRST(&queue->tq_queue);
+   STAILQ_REMOVE_HEAD(&queue->tq_queue, ta_link);
+   pending = task->ta_pending;
+   task->ta_pending = 0;
+   task->ta_running = tpp;
+   *tpp = task;
+   TQ_UNLOCK(queue);
+
+   task->ta_func(task->ta_context, pending);
+
+   TQ_LOCK(queue);
+   *tpp = NULL;
+   wakeup(task);
+   }
+}
+
 MALLOC_DEFINE(M_NVIDIA, "nvidia", "NVIDIA memory allocations");
 TASKQUEUE_DEFINE_THREAD(nvidia);
 
@@ -332,7 +393,8 @@
 
 RM_STATUS NV_API_CALL os_flush_work_queue(void)
 {
-taskqueue_run(taskqueue_nvidia);
+//taskqueue_run(taskqueue_nvidia);
+taskqueue_run(taskqueue_nvidia, &taskqueue_nvidia->tq_running);
 return RM_OK;
 }
 
___
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: system hangs after logging into gdm

[Ivan Klymenko]

В Mon, 11 Oct 2010 08:37:05 -0700
Garrett Cooper  пишет:

> On Mon, Oct 11, 2010 at 2:04 AM, Andriy Gapon  wrote:
> > on 11/10/2010 10:59 Ivan Klymenko said the following:
> >> В Sun, 10 Oct 2010 15:37:55 -0700
> >> Garrett Cooper  пишет:
> >>
> >>> On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko 
> >>> wrote:
> >>>> Hi!
> >>>>
> >>>> My system has an svn r213507
> >>>>
> >>>> FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507:
> >>>> Sun Oct 10 22:43:18 EEST 2010
> >>>> r...@nonamehost:/usr/obj/usr/src/sys/mk9 amd64
> >>>>
> >>>> after upgrading to r213666 my system hangs after logging into gdm
> >>>>
> >>>> had to go back to r213507
> >>>
> >>> What video driver are you using?
> >>> -Garrett
> >>
> >> NVIDIA Driver Version: 260.19.06
> >>
> >> but Xorg successfully starts and GDM login screen appears
> >> system hangs after a few seconds after entering the password ...
> >> I noticed the following: gvfsd does not create a directory of the
> >> form / var/tmp/gvfs-- may hang system due to gvfsd?
> 
> That seems a bit interesting.
> The other thing you can do is start running a binary search on the
> breakage because you have a range of good versions vs bad versions to
> look through.
> 
> > If you can access the system remotely or quickly switch to console,
> > then you should be able to examine state of your system and get
> > some facts.
> 
> If you have ddb compiled into the kernel (and you should) try
> CTRL-ALT-ESC after the lockup. You may also want to try KGDB instead,
> which would require a serial connection (RS-232 or IEEE-1394).
> HTH,
> -Garrett

--I have updated the source code to r213666
--rebuilt and reinstall: world and kernel GENERIC
--reinstall nvidia driver with my patch:

#
--- src/nvidia_os.c.orig2010-09-15 01:26:27.0 +0300
+++ src/nvidia_os.c 2010-09-15 01:27:51.0 +0300
@@ -13,6 +13,67 @@
 #include "nv.h"
 #include "nv-freebsd.h"
 
+struct taskqueue {
+STAILQ_HEAD(, task) tq_queue;
+const char  *tq_name;
+taskqueue_enqueue_fntq_enqueue;
+void*tq_context;
+struct task *tq_running;
+struct mtx  tq_mutex;
+struct thread   **tq_threads;
+int tq_tcount;
+int tq_spin;
+int tq_flags;
+};
+
+static void taskqueue_run(struct taskqueue *, struct task **);
+
+static __inline void
+TQ_LOCK(struct taskqueue *tq)
+{
+if (tq->tq_spin)
+   mtx_lock_spin(&tq->tq_mutex);
+else
+mtx_lock(&tq->tq_mutex);
+}
+
+static __inline void
+TQ_UNLOCK(struct taskqueue *tq)
+{
+   if (tq->tq_spin)
+  mtx_unlock_spin(&tq->tq_mutex);
+   else
+  mtx_unlock(&tq->tq_mutex);
+}
+
+static void
+taskqueue_run(struct taskqueue *queue, struct task **tpp)
+{   
+   struct task *task;
+   int pending;
+
+   mtx_assert(&queue->tq_mutex, MA_OWNED);
+   while (STAILQ_FIRST(&queue->tq_queue)) {
+   /*
+   * Carefully remove the first task from the queue and
+   * zero its pending count.
+   */
+   task = STAILQ_FIRST(&queue->tq_queue);
+   STAILQ_REMOVE_HEAD(&queue->tq_queue, ta_link);
+   pending = task->ta_pending;
+   task->ta_pending = 0;
+   task->ta_running = tpp;
+   *tpp = task;
+   TQ_UNLOCK(queue);
+
+   task->ta_func(task->ta_context, pending);
+
+   TQ_LOCK(queue);
+   *tpp = NULL;
+   wakeup(task);
+   }
+}
+
 MALLOC_DEFINE(M_NVIDIA, "nvidia", "NVIDIA memory allocations");
 TASKQUEUE_DEFINE_THREAD(nvidia);
 
@@ -332,7 +393,8 @@
 
 RM_STATUS NV_API_CALL os_flush_work_queue(void)
 {
-taskqueue_run(taskqueue_nvidia);
+//taskqueue_run(taskqueue_nvidia);
+taskqueue_run(taskqueue_nvidia, &taskqueue_nvidia->tq_running);
 return RM_OK;
 }
#

--reboo
--authorization window will appear gdm
--i choose a user, enter a password and press "Enter"
--takes a few seconds and my system hangs
--I press CTRL + ALT + ESC, but nothing happens
:(

Here are some of the messages log at this loading:

Oct 12 01:06:57 nonamehost syslogd: kernel boot file is /boot/kernel/kernel
Oct 12 01:06:57 nonamehost kernel: Copyright (c) 1992-2010 The FreeBSD Project.
Oct 12 01:06:57 nonameh

Re: system hangs after logging into gdm

[Ivan Klymenko]

В Tue, 12 Oct 2010 11:51:05 +0300
Andriy Gapon  пишет:

> on 12/10/2010 11:35 Ivan Klymenko said the following:
> > --i choose a user, enter a password and press "Enter"
> 
> have you switched to text console after the above and before the next?

After the system hangs - no
after a reboot - yes - I went to the console and rebuilt world and kernel 
version r231507 again ...

> 
> > --takes a few seconds and my system hangs
> > --I press CTRL + ALT + ESC, but nothing happens
> 
> You might want to add DEBUG_VFS_LOCKS.
> 

Yes, I can, but this whole procedure takes me many hours ...
I have FreeBSD - the only system on the PC and I need it in working order - I'm 
working on it

Surely no one will be able to repeat my steps, that would verify this
especially since I've written previously that the cause may be in the vfs ...
___
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: system hangs after logging into gdm

[Ivan Klymenko]

В Tue, 12 Oct 2010 02:07:01 -0700
Garrett Cooper  пишет:

> On Tue, Oct 12, 2010 at 2:04 AM, Andriy Gapon  wrote:
> > on 12/10/2010 12:00 Ivan Klymenko said the following:
> >> В Tue, 12 Oct 2010 11:51:05 +0300
> >> Andriy Gapon  пишет:
> >>
> >>> on 12/10/2010 11:35 Ivan Klymenko said the following:
> >>>> --i choose a user, enter a password and press "Enter"
> >>>
> >>> have you switched to text console after the above and before the
> >>> next?
> >>
> >> After the system hangs - no
> >
> > I specifically asked if you switched to text console right after
> > pressing Enter in the above step.  Sorry if that was not clear.
> >
> >> after a reboot - yes - I went to the console and rebuilt world and
> >> kernel version r231507 again ...
> >>
> >>>
> >>>> --takes a few seconds and my system hangs
> >>>> --I press CTRL + ALT + ESC, but nothing happens
> >>>
> >>> You might want to add DEBUG_VFS_LOCKS.
> >>>
> >>
> >> Yes, I can, but this whole procedure takes me many hours ...
> >> I have FreeBSD - the only system on the PC and I need it in
> >> working order - I'm working on it
> >>
> >> Surely no one will be able to repeat my steps, that would verify
> >> this especially since I've written previously that the cause may
> >> be in the vfs ...
> >
> > Not sure what your point is.
> > So far you seem to be the only one who has the problem (or has
> > reported it, at least).
> 
> Could you try disabling some of your modules (fuse, nvidia, etc)
> in a stepwise manner? fuse is of particular interest for me to see
> whether or not it resolves the problem.
> Thanks,
> -Garrett

--I have updated the source code to r213666
--rebuilt and reinstall: ONLY kernel GENERIC + options DEBUG_VFS_LOCKS
--i NOT reinstall nvidia driver with my patch...
--i removed fusefs_enable="YES" in /etc/rc.conf  <<<<http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: system hangs after logging into gdm

[Ivan Klymenko]

> > --I have updated the source code to r213666
> > --rebuilt and reinstall: ONLY kernel GENERIC + options
> > DEBUG_VFS_LOCKS --i NOT reinstall nvidia driver with my patch...
> > --i removed fusefs_enable="YES" in /etc/rc.conf   >        fusefs-kmod-0.3.9.p1.20080208_6
> >
> > system booted fine and I successfully logged on to gdm! :)
> >
> > cause system hangs at the entrance to gdm was a module of the ports
> > of fuse.ko
> 
> Try recompiling the module and load it to see whether or not the
> module has been broken in your recent CURRENT update.
> Thanks!
> -Garrett

I updated the kernel source code and the world to r213666
I rebuilt the port fusefs-kmod-0.3.9.p1.20080208_6
everything works fine!
In fact, there is no problem!

Thank you all!

P.S. I am ashamed that I could not find the problem yourself, the more that 
once during the FreeBSD 5.4 I am on such a problem with fuse.ko already 
stumbled. : (
___
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: bge0 does not work anymore

[Ivan Klymenko]

В Mon, 18 Oct 2010 10:38:45 +0200
Marius Strobl  пишет:

> On Mon, Oct 18, 2010 at 09:32:13AM +0800, Buganini wrote:
> > my last known usable kernel revision is r213813
> > with r213920, leds are extinguished when executing dhclient
> 
> Sorry, it looks like it was my fault this time, should be fixed again
> with r214012.
> 
> Marius

r214012.
Thank you! it worked! :)
___
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"

the world is not built gcc after upgrade svn r214735

[Ivan Klymenko]

Hello, people!
After the upgrade to FreeBSD 9.0-CURRENT svn revision 214735 does not
build world: ...
===> usr.sbin/wpa/wpa_passphrase (depend)
rm -f .depend
mkdep -f .depend -a-I/usr/src/usr.sbin/wpa/wpa_passphrase
-I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src
-I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/common
-I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto
-I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/l2_packet
-I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/utils
-DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX -DINTERNAL_SHA1
-DINTERNAL_MD5 -I/usr/src/usr.sbin/wpa/wpa_passphrase
-I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src
-I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/common
-I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto
-I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/l2_packet
-I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/utils
-DCONFIG_CTRL_IFACE
-DCONFIG_CTRL_IFACE_UNIX 
/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//wpa_supplicant/wpa_passphrase.c
 /usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/sha1.c 
/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/sha1-internal.c
 
/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/sha1-pbkdf2.c
 /usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/md5.c 
/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/md5-internal.c
echo wpa_passphrase: /usr/obj/usr/src/tmp/usr/lib/libc.a  >> .depend
===> usr.sbin/wpa/hostapd (depend) make: don't know how to make
config_file.c. Stop *** Error code 2 1 error *** Error code 2

Stop in /usr/src/usr.sbin.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.


Thanks!
___
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"

the world is not built gcc after upgrade svn r214735

[Ivan Klymenko]

Hello, people!
After the upgrade to FreeBSD 9.0-CURRENT svn revision 214735 does not
build world: ...
===> usr.sbin/wpa/wpa_passphrase (depend)  
rm -f .depend
mkdep -f .depend -a-I/usr/src/usr.sbin/wpa/wpa_passphrase
-I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src
-I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/common
-I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto
-I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/l2_packet
-I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/utils
-DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX -DINTERNAL_SHA1
-DINTERNAL_MD5 -I/usr/src/usr.sbin/wpa/wpa_passphrase
-I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src
-I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/common
-I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto
-I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/l2_packet
-I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/utils
-DCONFIG_CTRL_IFACE
-DCONFIG_CTRL_IFACE_UNIX 
/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//wpa_supplicant/wpa_passphrase.c
 /usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/sha1.c 
/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/sha1-internal.c
 
/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/sha1-pbkdf2.c
 /usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/md5.c 
/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/md5-internal.c
echo wpa_passphrase: /usr/obj/usr/src/tmp/usr/lib/libc.a  >> .depend
===> usr.sbin/wpa/hostapd (depend) make: don't know how to make  
config_file.c. Stop *** Error code 2 1 error *** Error code 2

Stop in /usr/src/usr.sbin.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.


Thanks!
___
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: the world is not built gcc after upgrade svn r214735

[Ivan Klymenko]

В Thu, 4 Nov 2010 07:57:50 -0700
David Wolfskill  пишет:

> On Thu, Nov 04, 2010 at 04:53:16PM +0200, Ivan Klymenko wrote:
> > Hello, people!
> > After the upgrade to FreeBSD 9.0-CURRENT svn revision 214735 does
> > not build world: ...
> > 
> 
> I had no problem going from FreeBSD 9.0-CURRENT #33 r214732 to
> r214777.
> 
> Peace,
> david

Do you use when building make option -j?

I'm using -j 3
___
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: the world is not built gcc after upgrade svn r214735

[Ivan Klymenko]

В Thu, 4 Nov 2010 17:07:20 +0100
Bernd Walter  пишет:

> On Thu, Nov 04, 2010 at 05:15:43PM +0200, Ivan Klymenko wrote:
> > ?? Thu, 4 Nov 2010 07:57:50 -0700
> > David Wolfskill  ??:
> > 
> > > On Thu, Nov 04, 2010 at 04:53:16PM +0200, Ivan Klymenko wrote:
> > > > Hello, people!
> > > > After the upgrade to FreeBSD 9.0-CURRENT svn revision 214735
> > > > does not build world: ...
> > > > 
> > > 
> > > I had no problem going from FreeBSD 9.0-CURRENT #33 r214732 to
> > > r214777.
> > > 
> > > Peace,
> > > david
> > 
> > Do you use when building make option -j?
> > 
> > I'm using -j 3
> 
> You likely have stall dependencies in /usr/obj.
> 

How can I fix it?
___
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: the world is not built gcc after upgrade svn r214735

[Ivan Klymenko]

В Thu, 4 Nov 2010 09:19:01 -0700
Garrett Cooper  пишет:

> On Thu, Nov 4, 2010 at 9:11 AM, Ivan Klymenko  wrote:
> > В Thu, 4 Nov 2010 17:07:20 +0100
> > Bernd Walter  пишет:
> >
> >> On Thu, Nov 04, 2010 at 05:15:43PM +0200, Ivan Klymenko wrote:
> >> > ?? Thu, 4 Nov 2010 07:57:50 -0700
> >> > David Wolfskill  ??:
> >> >
> >> > > On Thu, Nov 04, 2010 at 04:53:16PM +0200, Ivan Klymenko wrote:
> >> > > > Hello, people!
> >> > > > After the upgrade to FreeBSD 9.0-CURRENT svn revision 214735
> >> > > > does not build world: ...
> >> > > > 
> >> > >
> >> > > I had no problem going from FreeBSD 9.0-CURRENT #33 r214732 to
> >> > > r214777.
> >> > >
> >> > > Peace,
> >> > > david
> >> >
> >> > Do you use when building make option -j?
> >> >
> >> > I'm using -j 3
> >>
> >> You likely have stall dependencies in /usr/obj.
> >>
> >
> > How can I fix it?
> 
> rm -Rf /usr/obj/*
>
:) I mean - the problem as a whole

I do not know what the reason, but the build process was successful only after 
completely remove all source codes
and update on the new:
svn checkout svn://svn.freebsd.org/base/head /usr/src
I have previously also used this type of update ... :(

sorry for the noise :(
___
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"

Error 1: gpart create -s GPT ad0

[Ivan Klymenko]

Hello! People.

I use the alternate installer pc-sysinstall based on FreeBSD
9.0-CURRENT r215176
When you load the virtual machine qemu disk ad0 is determined by:
http://img573.imageshack.us/i/qemu1.png/
but when trying to create a section displays the following error:
http://img80.imageshack.us/i/qemu.png/
Think all options for gpart are correct - what can there be a problem?

Thanks!
___
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: Error 1: gpart create -s GPT ad0

[Ivan Klymenko]

В Sat, 13 Nov 2010 08:45:02 +0300
"Andrey V. Elsukov"  пишет:

> On 12.11.2010 21:47, Ivan Klymenko wrote:
> > I use the alternate installer pc-sysinstall based on FreeBSD
> > 9.0-CURRENT r215176
> 
> Hmm, are you sure that your kernel is based on r215176?
> 

no doubt! :)
___
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: Error 1: gpart create -s GPT ad0

[Ivan Klymenko]

В Fri, 12 Nov 2010 22:09:30 -0500
Kris Moore  пишет:

> On Fri, Nov 12, 2010 at 08:47:00PM +0200, Ivan Klymenko wrote:
> > Hello! People.
> > 
> > I use the alternate installer pc-sysinstall based on FreeBSD
> > 9.0-CURRENT r215176
> > When you load the virtual machine qemu disk ad0 is determined by:
> > http://img573.imageshack.us/i/qemu1.png/
> > but when trying to create a section displays the following error:
> > http://img80.imageshack.us/i/qemu.png/
> > Think all options for gpart are correct - what can there be a
> > problem?
> > 
> > Thanks!
> 
> The gpart syntax looks correct, and ad0 is being used elsewhere in
> your install process successfully. Is this a fresh disk / image?
> Perhaps something has broken in the gpart command?
> 

Thank you!
Now try to recreate the virtual disk ...
___
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: Error 1: gpart create -s GPT ad0

[Ivan Klymenko]

В Sat, 13 Nov 2010 09:35:14 +0200
Ivan Klymenko  пишет:

> В Fri, 12 Nov 2010 22:09:30 -0500
> Kris Moore  пишет:
> 
> > On Fri, Nov 12, 2010 at 08:47:00PM +0200, Ivan Klymenko wrote:
> > > Hello! People.
> > > 
> > > I use the alternate installer pc-sysinstall based on FreeBSD
> > > 9.0-CURRENT r215176
> > > When you load the virtual machine qemu disk ad0 is determined by:
> > > http://img573.imageshack.us/i/qemu1.png/
> > > but when trying to create a section displays the following error:
> > > http://img80.imageshack.us/i/qemu.png/
> > > Think all options for gpart are correct - what can there be a
> > > problem?
> > > 
> > > Thanks!
> > 
> > The gpart syntax looks correct, and ad0 is being used elsewhere in
> > your install process successfully. Is this a fresh disk / image?
> > Perhaps something has broken in the gpart command?
> > 
> 
> Thank you!
> Now try to recreate the virtual disk ...

But it did not help avoid the problem :(
___
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: Error 1: gpart create -s GPT ad0

[Ivan Klymenko]

В Fri, 12 Nov 2010 20:02:08 -0800
Garrett Cooper  пишет:

> On Fri, Nov 12, 2010 at 7:09 PM, Kris Moore  wrote:
> > On Fri, Nov 12, 2010 at 08:47:00PM +0200, Ivan Klymenko wrote:
> >> Hello! People.
> >>
> >> I use the alternate installer pc-sysinstall based on FreeBSD
> >> 9.0-CURRENT r215176
> >> When you load the virtual machine qemu disk ad0 is determined by:
> >> http://img573.imageshack.us/i/qemu1.png/
> >> but when trying to create a section displays the following error:
> >> http://img80.imageshack.us/i/qemu.png/
> >> Think all options for gpart are correct - what can there be a
> >> problem?
> >>
> >> Thanks!
> >
> > The gpart syntax looks correct, and ad0 is being used elsewhere in
> > your install process successfully. Is this a fresh disk / image?
> > Perhaps something has broken in the gpart command?
> 
> According to the gpart(8) manpage, the invocation is correct. It'd
> be interesting to see what the log displayed yields, but before then
> have you tried kern.geom.debugflags=16? 

no.
after booting the system immediately executed script pc-sysinstall
now try to force the kern.geom.debugflags = 16 before running
pc-sysinstall

> I did a quick scan of
> lib/libgeom and sys/geom, and all of the places (minus one) that
> returned EINVAL were due to incorrect sector size. What are you using
> for your disk?
> 
> Thanks,
> -Garrett

I'm afraid I do not quite understand the essence
last question ... : (
I created a virtual disk command:
qemu-img create name_disk.img 40G
All the breakdown of disk partitions running script pc-sysinstall in
accordance with my config file pcinstall.cfg
___
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: Error 1: gpart create -s GPT ad0

[Ivan Klymenko]

В Sat, 13 Nov 2010 11:01:36 +0300
"Andrey V. Elsukov"  пишет:

> On 13.11.2010 10:34, Ivan Klymenko wrote:
> >> Hmm, are you sure that your kernel is based on r215176?
> >>
> > 
> > no doubt! :)
> 
> Do you use custom ISO image?

yes.

> Can you mount it and show
> output of command:
> # ident /mnt/boot/kernel/kernel.symbols | grep g_part.c
> 
Once mounted iso image of my drive to /mnt

ident error: /mnt/boot/kernel/kernel.symbols: No such file or directory

because this file (kernel.symbols) is really not in the iso image...
___
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: Error 1: gpart create -s GPT ad0

[Ivan Klymenko]

В Sat, 13 Nov 2010 10:10:32 +0200
Ivan Klymenko  пишет:

> В Fri, 12 Nov 2010 20:02:08 -0800
> Garrett Cooper  пишет:
> 
> > On Fri, Nov 12, 2010 at 7:09 PM, Kris Moore  wrote:
> > > On Fri, Nov 12, 2010 at 08:47:00PM +0200, Ivan Klymenko wrote:
> > >> Hello! People.
> > >>
> > >> I use the alternate installer pc-sysinstall based on FreeBSD
> > >> 9.0-CURRENT r215176
> > >> When you load the virtual machine qemu disk ad0 is determined by:
> > >> http://img573.imageshack.us/i/qemu1.png/
> > >> but when trying to create a section displays the following error:
> > >> http://img80.imageshack.us/i/qemu.png/
> > >> Think all options for gpart are correct - what can there be a
> > >> problem?
> > >>
> > >> Thanks!
> > >
> > > The gpart syntax looks correct, and ad0 is being used elsewhere in
> > > your install process successfully. Is this a fresh disk / image?
> > > Perhaps something has broken in the gpart command?
> > 
> > According to the gpart(8) manpage, the invocation is correct.
> > It'd be interesting to see what the log displayed yields, but
> > before then have you tried kern.geom.debugflags=16? 
> 
> no.
> after booting the system immediately executed script pc-sysinstall
> now try to force the kern.geom.debugflags = 16 before running
> pc-sysinstall

did not help ...

http://img152.imageshack.us/i/qemu2.png/

on the version of the source code a couple of weeks ago it worked
fine  I just updated the source tree and recompiled my CD/DVD ISO
image...

> 
> > I did a quick scan of
> > lib/libgeom and sys/geom, and all of the places (minus one) that
> > returned EINVAL were due to incorrect sector size. What are you
> > using for your disk?
> > 
> > Thanks,
> > -Garrett
> 
> I'm afraid I do not quite understand the essence
> last question ... : (
> I created a virtual disk command:
> qemu-img create name_disk.img 40G
> All the breakdown of disk partitions running script pc-sysinstall in
> accordance with my config file pcinstall.cfg
___
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: Error 1: gpart create -s GPT ad0

[Ivan Klymenko]

В Sat, 13 Nov 2010 11:34:12 +0300
"Andrey V. Elsukov"  пишет:

> On 13.11.2010 11:25, Ivan Klymenko wrote:
> > Once mounted iso image of my drive to /mnt
> > ident error: /mnt/boot/kernel/kernel.symbols: No such file or
> > directory because this file (kernel.symbols) is really not in the
> > iso image...
> 
> So, I can not reproduce this error. And I still think that you use
> older revision and you should rebuild your ISO image with fresh
> sources.
> 

well ...
but it will take a little time ...
___
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: Error 1: gpart create -s GPT ad0

[Ivan Klymenko]

В Sat, 13 Nov 2010 11:49:29 +0300
"Andrey V. Elsukov"  пишет:

> On 13.11.2010 11:40, Ivan Klymenko wrote:
> >> So, I can not reproduce this error. And I still think that you use
> >> older revision and you should rebuild your ISO image with fresh
> >> sources.
> >>
> > 
> > well ...
> > but it will take a little time ...
> 
> Just a note - as you may see from tinderbox's emails at the moment
> building of fresh current is broken :)
> 

Thanks!

I saw it - watch for the mailing too ;)
___
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: Error 1: gpart create -s GPT ad0

[Ivan Klymenko]

В Sat, 13 Nov 2010 08:38:16 +0300
"Andrey V. Elsukov"  пишет:

> On 12.11.2010 21:47, Ivan Klymenko wrote:
> > http://img80.imageshack.us/i/qemu.png/
> > Think all options for gpart are correct - what can there be a
> > problem?
> 
> This was temporary regression and it is fixed now in r215118.
> In any case it is harmless.
> 

I am ashamed ... :(
You were right!
I have an ISO audit r215110 ...

Is the current system on a PC r215176

now try to rebuild the ISO it
___
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: Error 1: gpart create -s GPT ad0

[Ivan Klymenko]

В Sat, 13 Nov 2010 11:03:00 +0200
Ivan Klymenko  пишет:

> В Sat, 13 Nov 2010 08:38:16 +0300
> "Andrey V. Elsukov"  пишет:
> 
> > On 12.11.2010 21:47, Ivan Klymenko wrote:
> > > http://img80.imageshack.us/i/qemu.png/
> > > Think all options for gpart are correct - what can there be a
> > > problem?
> > 
> > This was temporary regression and it is fixed now in r215118.
> > In any case it is harmless.
> > 
> 
> I am ashamed ... :(
> You were right!
> I have an ISO audit r215110 ...
> 
> Is the current system on a PC r215176
> 
> now try to rebuild the ISO it

I rebuild the ISO image based on r215176 and gpart did not return an
error.
Thank you all!
Topic can be closed. :)
___
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"

dev/psm0 not found

[Ivan Klymenko]

http://svn.freebsd.org/viewvc/base/head/sys/dev/atkbdc/psm.c?view=log

after updating svn revision => 216491 system is not detecting the device
psm
http://svn.freebsd.org/viewvc/base?view=revision&revision=216491




Copyright (c) 1992-2010 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-CURRENT #0 r216524: Sat Dec 18 19:51:17 EET 2010
i...@nonamehost:/usr/obj/usr/src/sys/mk9 amd64
CPU: Intel(R) Core(TM)2 Duo CPU T7250  @ 2.00GHz (1994.47-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x6fd  Family = 6  Model = f  Stepping = 13
  
Features=0xbfebfbff
  Features2=0xe3bd
  AMD Features=0x20100800
  AMD Features2=0x1
  TSC: P-state invariant
real memory  = 2147483648 (2048 MB)
avail memory = 2039611392 (1945 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0: Changing APIC ID to 2
ioapic0  irqs 0-23 on motherboard
Cuse4BSD v0.1.13 @ /dev/cuse
kbd1 at kbdmux0
acpi0:  on motherboard
hpet0:  iomem 0xfed0-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 900
Event timer "HPET" frequency 14318180 Hz quality 550
Event timer "HPET1" frequency 14318180 Hz quality 440
acpi0: reservation of 0, 9f000 (3) failed
acpi0: reservation of 10, 7fd6d800 (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
cpu0:  on acpi0
cpu1:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
vgapci0:  port 0xef00-0xef7f mem 
0xfd00-0xfdff,0xe000-0xefff,0xfa00-0xfbff irq 16 at 
device 0.0 on pci1
acpi_video0:  on vgapci0
nvidia0:  on vgapci0
vgapci0: child nvidia0 requested pci_enable_busmaster
vgapci0: child nvidia0 requested pci_enable_io
vgapci0: child nvidia0 requested pci_enable_io
uhci0:  port 0x6f20-0x6f3f irq 20 at 
device 26.0 on pci0
usbus0:  on uhci0
uhci1:  port 0x6f00-0x6f1f irq 21 at 
device 26.1 on pci0
usbus1:  on uhci1
ehci0:  mem 
0xfed1c400-0xfed1c7ff irq 22 at device 26.7 on pci0
usbus2: EHCI version 1.0
usbus2:  on ehci0
hdac0:  mem 
0xfebfc000-0xfebf irq 21 at device 27.0 on pci0
hdac0: HDA Driver Revision: 20100226_0142
pcib2:  at device 28.0 on pci0
pci11:  on pcib2
pcib3:  at device 28.1 on pci0
pci12:  on pcib3
pci12:  at device 0.0 (no driver attached)
pcib4:  at device 28.3 on pci0
pci13:  on pcib4
pcib5:  at device 28.5 on pci0
pci9:  on pcib5
bge0:  mem 0xf9bf-0xf9bf irq 
17 at device 0.0 on pci9
bge0: CHIP ID 0xc002; ASIC REV 0x0c; CHIP REV 0xc0; PCI-E
miibus0:  on bge0
brgphy0:  PHY 1 on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
bge0: Ethernet address: 00:1c:23:f9:bb:5f
uhci2:  port 0x6f80-0x6f9f irq 20 at 
device 29.0 on pci0
usbus3:  on uhci2
uhci3:  port 0x6f60-0x6f7f irq 21 at 
device 29.1 on pci0
usbus4:  on uhci3
uhci4:  port 0x6f40-0x6f5f irq 22 at 
device 29.2 on pci0
usbus5:  on uhci4
ehci1:  mem 
0xfed1c000-0xfed1c3ff irq 20 at device 29.7 on pci0
usbus6: EHCI version 1.0
usbus6:  on ehci1
pcib6:  at device 30.0 on pci0
pci3:  on pcib6
fwohci0: <1394 Open Host Controller Interface> mem 0xf9aff800-0xf9af irq 19 
at device 1.0 on pci3
fwohci0: OHCI version 1.10 (ROM=0)
fwohci0: No. of Isochronous channels is 4.
fwohci0: EUI64 32:4f:c0:00:1c:e5:20:70
fwohci0: Phy 1394a available S400, 1 ports.
fwohci0: Link S400, max_rec 2048 bytes.
firewire0:  on fwohci0
dcons_crom0:  on firewire0
dcons_crom0: bus_addr 0x3814000
fwe0:  on firewire0
if_fwe0: Fake Ethernet address: 32:4f:c0:e5:20:70
fwe0: Ethernet address: 32:4f:c0:e5:20:70
fwip0:  on firewire0
fwip0: Firewire address: 32:4f:c0:00:1c:e5:20:70 @ 0xfffe, S400, maxrec 
2048
sbp0:  on firewire0
fwohci0: Initiate bus reset
fwohci0: fwohci_intr_core: BUS reset
fwohci0: fwohci_intr_core: node_id=0x, SelfID Count=1, CYCLEMASTER mode
pci3:  at device 1.1 (no driver attached)
pci3:  at device 1.2 (no driver attached)
pci3:  at device 1.3 (no driver attached)
pci3:  at device 1.4 (no driver attached)
isab0:  at device 31.0 on pci0
isa0:  on isab0
atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x6fa0-0x6faf irq 16 at device 31.1 on pci0
ata0:  on atapci0
ahci0:  port 
0x6eb0-0x6eb7,0x6eb8-0x6ebb,0x6ec0-0x6ec7,0x6ec8-0x6ecb,0x6ee0-0x6eff mem 
0xfebfb800-0xfebfbfff irq 17 at device 31.2 on pci0
ahci0: AHCI v1.10 with 3 3Gbps ports, Port Multiplier not supported
ahcich0:  at channel 0 on ahci0
ahcich1:  at channel 2 on ahci0
pci0:  at device 31.3 (no driver attached)
acpi_lid0:  on acpi0
acpi_button0:  on acpi0
acpi_button1:  on acpi0
acpi_acad0:  on acpi0
battery0:  on acpi0
acpi_tz0:  on acpi0
atkbdc0:  port 0x60,0x64,0x62,0x66 irq 1 on acpi0
atkbd0:  i

Re: dev/psm0 not found

[Ivan Klymenko]

В Mon, 20 Dec 2010 14:51:15 -0500
John Baldwin  пишет:

> On Monday, December 20, 2010 1:14:35 pm Ivan Klymenko wrote:
> > В Mon, 20 Dec 2010 12:49:53 -0500
> > John Baldwin  пишет:
> > 
> > > On Monday, December 20, 2010 11:53:34 am Ivan Klymenko wrote:
> > > > В Mon, 20 Dec 2010 09:58:57 -0500
> > > > John Baldwin  пишет:
> > > > 
> > > > > On Saturday, December 18, 2010 1:30:20 pm Ivan Klymenko wrote:
> > > > > > 
> http://svn.freebsd.org/viewvc/base/head/sys/dev/atkbdc/psm.c?view=log
> > > > > > 
> > > > > > after updating svn revision => 216491 system is not
> > > > > > detecting the device psm
> > > > > > http://svn.freebsd.org/viewvc/base?view=revision&revision=216491
> > > > > 
> > > > > Can you please get verbose dmesg's from before and after?
> > > > > 
> > > > 
> > > > Voila.
> > > 
> > > Please boot with this and capture the output:
> > > 
> > > Index: psm.c
> > > ===
> > > --- psm.c (revision 216591)
> > > +++ psm.c (working copy)
> > > @@ -1100,11 +1100,17 @@
> > >*/
> > >   psmc = device_find_child(device_get_parent(parent),
> > >   PSMCPNP_DRIVER_NAME, unit);
> > > - if (psmc == NULL)
> > > + if (psmc == NULL) {
> > > + printf("psm%d: could not find %s%d\n", unit,
> > > + PSMCPNP_DRIVER_NAME, unit);
> > >   return;
> > > + }
> > >   irq = bus_get_resource_start(psmc, SYS_RES_IRQ, 0);
> > > - if (irq <= 0)
> > > + if (irq <= 0) {
> > > + printf("psm%d: no IRQ from %s%d\n", unit,
> > > PSMCPNP_DRIVER_NAME,
> > > + unit);
> > >   return;
> > > + }
> > >   bus_delete_resource(psmc, SYS_RES_IRQ, 0);
> > >   bus_set_resource(psm, SYS_RES_IRQ, KBDC_RID_AUX, irq, 1);
> > >  }
> 
> Try this instead.  You can use a non-verbose dmesg to trim the
> spammage.
> 
> Index: psm.c
> ===
> --- psm.c (revision 216591)
> +++ psm.c (working copy)
> @@ -1080,7 +1080,7 @@
>   device_t psmc;
>   device_t psm;
>   u_long irq;
> - int unit;
> + int error, unit;
>  
>   unit = device_get_unit(parent);
>  
> @@ -1090,8 +1090,10 @@
>   return;
>  
>   irq = bus_get_resource_start(psm, SYS_RES_IRQ, KBDC_RID_AUX);
> - if (irq > 0)
> + if (irq > 0) {
> + printf("psm%d: already has an IRQ?\n", unit);
>   return;
> + }
>  
>   /*
>* If the PS/2 mouse device has already been reported by
> ACPI or @@ -1100,13 +1102,27 @@
>*/
>   psmc = device_find_child(device_get_parent(parent),
>   PSMCPNP_DRIVER_NAME, unit);
> - if (psmc == NULL)
> + if (psmc == NULL) {
> + printf("psm%d: could not find %s%d\n", unit,
> + PSMCPNP_DRIVER_NAME, unit);
>   return;
> + }
>   irq = bus_get_resource_start(psmc, SYS_RES_IRQ, 0);
> - if (irq <= 0)
> + if (irq <= 0) {
> + printf("psm%d: no IRQ from %s\n", unit,
> + device_get_nameunit(psmc));
>   return;
> - bus_delete_resource(psmc, SYS_RES_IRQ, 0);
> - bus_set_resource(psm, SYS_RES_IRQ, KBDC_RID_AUX, irq, 1);
> + }
> + error = bus_delete_resource(psmc, SYS_RES_IRQ, 0);
> + if (error)
> + printf("psm%d: failed to remove IRQ from %s: %d\n",
> unit,
> + device_get_nameunit(psmc), error);
> + error = bus_set_resource(psm, SYS_RES_IRQ, KBDC_RID_AUX,
> irq, 1);
> + if (error)
> + printf("psm%d: failed to add IRQ %lu: %d\n", unit,
> irq,
> + error);
> + else
> + printf("psm%d: added IRQ %lu\n", unit, irq);
>  }
>  
>  #define  endprobe(v) do {\
> 

/usr/local/libexec/ccache/world-cc -c -O2 -pipe -mtune=native 
-fno-strict-aliasing -march=nocona -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  
-I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=8000 --param in

Re: dev/psm0 not found

[Ivan Klymenko]

В Mon, 20 Dec 2010 16:02:46 -0500
John Baldwin  пишет:

> On Monday, December 20, 2010 3:03:36 pm Ivan Klymenko wrote:
> > В Mon, 20 Dec 2010 14:51:15 -0500
> > John Baldwin  пишет:
> > 
> > > On Monday, December 20, 2010 1:14:35 pm Ivan Klymenko wrote:
> > > > В Mon, 20 Dec 2010 12:49:53 -0500
> > > > John Baldwin  пишет:
> > > > 
> > > > > On Monday, December 20, 2010 11:53:34 am Ivan Klymenko wrote:
> > > > > > В Mon, 20 Dec 2010 09:58:57 -0500
> > > > > > John Baldwin  пишет:
> > > > > > 
> > > > > > > On Saturday, December 18, 2010 1:30:20 pm Ivan Klymenko
> > > > > > > wrote:
> > > > > > > > 
> > > http://svn.freebsd.org/viewvc/base/head/sys/dev/atkbdc/psm.c?view=log
> > > > > > > > 
> > > > > > > > after updating svn revision => 216491 system is not
> > > > > > > > detecting the device psm
> > > > > > > > http://svn.freebsd.org/viewvc/base?view=revision&revision=216491
> > > > > > > 
> > > > > > > Can you please get verbose dmesg's from before and after?
> > > > > > > 
> > > > > > 
> > > > > > Voila.
> > /usr/src/sys/dev/atkbdc/psm.c: In function 'psmidentify':
> > /usr/src/sys/dev/atkbdc/psm.c:1116: error: void value not ignored
> > as it ought to be *** Error code 1
> 
> Ok, try this:
> 
> Index: psm.c
> ===
> --- psm.c (revision 216591)
> +++ psm.c (working copy)
> @@ -1080,7 +1080,7 @@
>   device_t psmc;
>   device_t psm;
>   u_long irq;
> - int unit;
> + int error, unit;
>  
>   unit = device_get_unit(parent);
>  
> @@ -1090,8 +1090,10 @@
>   return;
>  
>   irq = bus_get_resource_start(psm, SYS_RES_IRQ, KBDC_RID_AUX);
> - if (irq > 0)
> + if (irq > 0) {
> + printf("psm%d: already has an IRQ?\n", unit);
>   return;
> + }
>  
>   /*
>* If the PS/2 mouse device has already been reported by
> ACPI or @@ -1100,13 +1102,24 @@
>*/
>   psmc = device_find_child(device_get_parent(parent),
>   PSMCPNP_DRIVER_NAME, unit);
> - if (psmc == NULL)
> + if (psmc == NULL) {
> + printf("psm%d: could not find %s%d\n", unit,
> + PSMCPNP_DRIVER_NAME, unit);
>   return;
> + }
>   irq = bus_get_resource_start(psmc, SYS_RES_IRQ, 0);
> - if (irq <= 0)
> + if (irq <= 0) {
> + printf("psm%d: no IRQ from %s\n", unit,
> + device_get_nameunit(psmc));
>   return;
> + }
>   bus_delete_resource(psmc, SYS_RES_IRQ, 0);
> - bus_set_resource(psm, SYS_RES_IRQ, KBDC_RID_AUX, irq, 1);
> + error = bus_set_resource(psm, SYS_RES_IRQ, KBDC_RID_AUX,
> irq, 1);
> + if (error)
> + printf("psm%d: failed to add IRQ %lu: %d\n", unit,
> irq,
> + error);
> + else
> + printf("psm%d: added IRQ %lu\n", unit, irq);
>  }
>  
>  #define  endprobe(v) do {\
> 

Not working :(


dmesg.boot
Description: Binary data
___
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: dev/psm0 not found

[Ivan Klymenko]

В Mon, 20 Dec 2010 17:26:15 -0500
John Baldwin  пишет:

> On Monday, December 20, 2010 4:38:57 pm Ivan Klymenko wrote:
> > В Mon, 20 Dec 2010 16:02:46 -0500
> > John Baldwin  пишет:
> > 
> > Not working :(
> 
> This was debugging, not a fix.  Try this possible fix:
> 
> Index: atkbdc_isa.c
> ===
> --- atkbdc_isa.c  (revision 216591)
> +++ atkbdc_isa.c  (working copy)
> @@ -272,14 +272,16 @@
>* list entry so we can use a standard bus_get_resource()
>* method.
>*/
> - if (sc->irq == NULL) {
> - if (resource_int_value(name, unit, "irq", &t) != 0)
> - t = -1;
> - } else
> - t = rman_get_start(sc->irq);
> - if (t > 0)
> - resource_list_add(&ivar->resources, SYS_RES_IRQ,
> ivar->rid,
> -   t, t, 1);
> + if (order == KBDC_RID_KBD) {
> + if (sc->irq == NULL) {
> + if (resource_int_value(name, unit, "irq",
> &t) != 0)
> + t = -1;
> + } else
> + t = rman_get_start(sc->irq);
> + if (t > 0)
> + resource_list_add(&ivar->resources,
> SYS_RES_IRQ,
> + ivar->rid, t, t, 1);
> + }
>  
>   if (resource_disabled(name, unit))
>   device_disable(child);
> 

It works!
Thanks!
___
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: dev/psm0 not found

[Ivan Klymenko]

В Mon, 20 Dec 2010 17:26:15 -0500
John Baldwin  пишет:

> On Monday, December 20, 2010 4:38:57 pm Ivan Klymenko wrote:
> > В Mon, 20 Dec 2010 16:02:46 -0500
> > John Baldwin  пишет:
> > 
> > Not working :(
> 
> This was debugging, not a fix.  Try this possible fix:
> 
> Index: atkbdc_isa.c
> ===
> --- atkbdc_isa.c  (revision 216591)
> +++ atkbdc_isa.c  (working copy)
> @@ -272,14 +272,16 @@
>* list entry so we can use a standard bus_get_resource()
>* method.
>*/
> - if (sc->irq == NULL) {
> - if (resource_int_value(name, unit, "irq", &t) != 0)
> - t = -1;
> - } else
> - t = rman_get_start(sc->irq);
> - if (t > 0)
> - resource_list_add(&ivar->resources, SYS_RES_IRQ,
> ivar->rid,
> -   t, t, 1);
> + if (order == KBDC_RID_KBD) {
> + if (sc->irq == NULL) {
> + if (resource_int_value(name, unit, "irq",
> &t) != 0)
> + t = -1;
> + } else
> + t = rman_get_start(sc->irq);
> + if (t > 0)
> + resource_list_add(&ivar->resources,
> SYS_RES_IRQ,
> + ivar->rid, t, t, 1);
> + }
>  
>   if (resource_disabled(name, unit))
>   device_disable(child);
> 
I have a question:
these changes will appear in HEAD?

Thanks!
___
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: Intel i915 GPU hung

[Ivan Klymenko]

В Tue, 2 Dec 2014 18:51:53 +0900
"Lundberg, Johannes"  пишет:

> Waking up an old thread here but I thought I'd share what I've
> learned.
> 
> I think I found out what caused both tearing and crashing when I used
> OpenGL.
> Since I changed from using xcompmgr to compton with following options
> 
> compton --backend glx --vsync opengl-swc --paint-on-overlay
> --glx-no-stencil -b
> 
> I have never had a crash or tearing. Have no idea why this is but I
> am just happy I don't get hung GPU anymore.
> 
> 


I am afraid that is not the case.
This method helps to reduce hang GPU to a minimum, but I have with all
the same settings for compton - sometimes it hangs timer GPU.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194766
___
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"

11-CURRENT r275641 panic: Unrecoverable machine check exception

[Ivan Klymenko]

Hi.


I see such a panic the first time in 10 years.

Fri Dec 12 21:35:11 EET 2014

FreeBSD nonamehost.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r275641: Tue Dec  
9 17:03:43 EET 2014 ivan@nonamehost.local:/media/da0s1/obj/usr/src/sys/mk11 
 amd64

panic: Unrecoverable machine check exception

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
MCA: Bank 6, Status 0xfe241136
MCA: Global Cap 0x0c07, Status 0x0005
MCA: Vendor "GenuineIntel", ID 0x206a7, APIC ID 1
MCA: CPU 1 UNCOR PCC OVER DCACHE L2 DRD error
MCA: Address 0xbd8d4cc0
MCA: Misc 0x30e386
MCA: Bank 6, Status 0xfe241136
MCA: Global Cap 0x0c07, Status 0x0005
MCA: Vendor "GenuineIntel", ID 0x206a7, APIC ID 0
MCA: CPU 0 UNCOR PCC OVER DCACHE L2 DRD error
MCA: Address 0xbd8d4cc0
MCA: Misc 0x30e386
panic: Unrecoverable machine check exception
cpuid = 0
KDB: stack backtrace:
#0 0x80a00870 at kdb_backtrace+0x60
#1 0x809be5b1 at panic+0x1c1
#2 0x80f784ab at mca_intr+0x6b
#3 0x80e55bb9 at trap+0x99
#4 0x80e38b22 at calltrap+0x8
Uptime: 1h44m14s
Dumping 675 out of 6050 MB:..3%..12%..22%..31%..41%..53%..62%..72%..81%..93%

Reading symbols from /boot/kernel/coretemp.ko.symbols...done.
Loaded symbols for /boot/kernel/coretemp.ko.symbols
Reading symbols from /boot/kernel/ichwd.ko.symbols...done.
Loaded symbols for /boot/kernel/ichwd.ko.symbols
Reading symbols from /boot/kernel/fdescfs.ko.symbols...done.
Loaded symbols for /boot/kernel/fdescfs.ko.symbols
Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
Loaded symbols for /boot/kernel/linprocfs.ko.symbols
Reading symbols from /boot/kernel/linux.ko.symbols...done.
Loaded symbols for /boot/kernel/linux.ko.symbols
Reading symbols from /boot/kernel/linsysfs.ko.symbols...done.
Loaded symbols for /boot/kernel/linsysfs.ko.symbols
Reading symbols from /boot/kernel/if_bridge.ko.symbols...done.
Loaded symbols for /boot/kernel/if_bridge.ko.symbols
Reading symbols from /boot/kernel/bridgestp.ko.symbols...done.
Loaded symbols for /boot/kernel/bridgestp.ko.symbols
Reading symbols from /boot/kernel/cpuctl.ko.symbols...done.
Loaded symbols for /boot/kernel/cpuctl.ko.symbols
Reading symbols from /boot/kernel/aesni.ko.symbols...done.
Loaded symbols for /boot/kernel/aesni.ko.symbols
Reading symbols from /boot/kernel/crypto.ko.symbols...done.
Loaded symbols for /boot/kernel/crypto.ko.symbols
Reading symbols from /boot/kernel/cryptodev.ko.symbols...done.
Loaded symbols for /boot/kernel/cryptodev.ko.symbols
Reading symbols from /boot/kernel/sem.ko.symbols...done.
Loaded symbols for /boot/kernel/sem.ko.symbols
Reading symbols from /boot/kernel/accf_data.ko.symbols...done.
Loaded symbols for /boot/kernel/accf_data.ko.symbols
Reading symbols from /boot/kernel/accf_http.ko.symbols...done.
Loaded symbols for /boot/kernel/accf_http.ko.symbols
Reading symbols from /boot/kernel/accf_dns.ko.symbols...done.
Loaded symbols for /boot/kernel/accf_dns.ko.symbols
Reading symbols from /boot/kernel/h_ertt.ko.symbols...done.
Loaded symbols for /boot/kernel/h_ertt.ko.symbols
Reading symbols from /boot/kernel/cc_cdg.ko.symbols...done.
Loaded symbols for /boot/kernel/cc_cdg.ko.symbols
Reading symbols from /boot/kernel/cc_chd.ko.symbols...done.
Loaded symbols for /boot/kernel/cc_chd.ko.symbols
Reading symbols from /boot/kernel/cc_cubic.ko.symbols...done.
Loaded symbols for /boot/kernel/cc_cubic.ko.symbols
Reading symbols from /boot/kernel/cc_hd.ko.symbols...done.
Loaded symbols for /boot/kernel/cc_hd.ko.symbols
Reading symbols from /boot/kernel/cc_htcp.ko.symbols...done.
Loaded symbols for /boot/kernel/cc_htcp.ko.symbols
Reading symbols from /boot/kernel/cc_vegas.ko.symbols...done.
Loaded symbols for /boot/kernel/cc_vegas.ko.symbols
Reading symbols from /boot/kernel/aio.ko.symbols...done.
Loaded symbols for /boot/kernel/aio.ko.symbols
Reading symbols from /boot/kernel/tmpfs.ko.symbols...done.
Loaded symbols for /boot/kernel/tmpfs.ko.symbols
Reading symbols from /boot/kernel/fuse.ko.symbols...done.
Loaded symbols for /boot/kernel/fuse.ko.symbols
Reading symbols from /boot/kernel/acpi_hp.ko.symbols...done.
Loaded symbols for /boot/kernel/acpi_hp.ko.symbols
Reading symbols from /boot/kernel/acpi_wmi.ko.symbols...done.
Loaded symbols for /boot/kernel/acpi_wmi.ko.symbols
Reading symbols from /boot/kernel/acpi_video.ko.symbols...done.
Loaded symbols for /boot/kernel/acpi_video.ko.symbols
Reading symbols from /boot/kernel/drm.ko.symbols...done.
Loaded symbols for /boot/kernel/drm.ko.symbols
Reading symbols from /boot/kernel/smbus.ko.symbols...done.
Lo

Re: 11-CURRENT r275641 panic: Unrecoverable machine check exception

[Ivan Klymenko]

This panic is reproduced as follows:
I'm trying to write *.iso an optical disc in k3b.
___
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: 11-CURRENT r275641 panic: Unrecoverable machine check exception

[Ivan Klymenko]

В Sat, 13 Dec 2014 02:18:47 +0200
Andriy Gapon  пишет:

> On 12/12/2014 21:46, Ivan Klymenko wrote:
> > Hi.
> > 
> > 
> > I see such a panic the first time in 10 years.
> 
> good

and how

> 
> > Fri Dec 12 21:35:11 EET 2014
> > 
> > FreeBSD nonamehost.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0
> > r275641: Tue Dec  9 17:03:43 EET 2014
> > ivan@nonamehost.local:/media/da0s1/obj/usr/src/sys/mk11  amd64
> > 
> > panic: Unrecoverable machine check exception
> 
> Google for "machine check exception" if you haven't yet.
> 

I very much doubt that it is a hardware problem - in the other case, I
would not write about it here

-CPU is not overclocked
-Memory (RAM) is in order
-no overheating
-panic accurately reproduced - not occur randomly
-Panic occurs without high load CPU
-mcelog --no-dmi --ascii - nothing


I suspect that the added non-existent instructions for my CPU

CPU: Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz (2294.84-MHz K8-class CPU)
Origin="GenuineIntel"  Id=0x206a7  Family=0x6  Model=0x2a  Stepping=7
Dec 13 10:11:45 nonamehost kernel:
Features=0xbfebfbff
Features2=0x1fbae3bf
AMD Features=0x28100800
AMD Features2=0x1 Dec 13 10:11:45 nonamehost kernel:
XSAVE Features=0x1

and it manifests itself in the assembly source code with the flag
CPUTYPE?=corei7-avx

I certainly could be wrong - but how to know for sure the cause of the
panic?

Best regards.
___
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: 11-CURRENT r275641 panic: Unrecoverable machine check exception

[Ivan Klymenko]

В Sat, 13 Dec 2014 13:40:13 +0200
Andriy Gapon  пишет:

> On 13/12/2014 11:38, Ivan Klymenko wrote:
> > -mcelog --no-dmi --ascii - nothing
> 
> Really?
> mcelog: Unsupported new Family 6 Model 2a CPU: only decoding
> architectural errors HARDWARE ERROR. This is *NOT* a software problem!
> Please contact your hardware vendor
> CPU 1 BANK 6
> MISC 30e386 ADDR bd8d4cc0
> MCG status:RIPV MCIP
> MCi status:
> Error overflow
> Uncorrected error
> Error enabled
> MCi_MISC register valid
> MCi_ADDR register valid
> Processor context corrupt
> MCA: corrected filtering (some unreported errors in same region)
> Data CACHE Level-2 Data-Read Error
> STATUS fe241136 MCGSTATUS 5
> MCGCAP c07 APICID 1 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 42
> 

hm. sorry
I was wrong file core.txt.xxx
___
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: 11-CURRENT r275641 panic: Unrecoverable machine check exception

[Ivan Klymenko]

В Mon, 15 Dec 2014 17:49:54 +
"Rang, Anton"  пишет:

> > I certainly could be wrong - but how to know for sure the cause of
> > the panic?
> 
> > MCA: CPU 0 UNCOR PCC OVER DCACHE L2 DRD error
> > MCA: Address 0xbd8d4cc0
> > MCA: Misc 0x30e386
> 
> The "root cause" may be hard to determine, but the immediate cause
> was helpfully decoded by the kernel. (Though I don't know whether all
> of the model-specific fields were decoded.)
> 
> UNCOR = uncorrected error
> PCC = processor context corrupted (can't safely continue to execute,
> thus the panic) OVER = error overflow (hmmm, multiple errors occurred)
> DCACHE L2 DRD = data being read from L2 data cache
> 
> The miscellaneous register indicates that 0xbd8d4cc0 is a physical
> address.
> 
> So this looks like a processor failure. If it is repeatable, though,
> it may indicate either failed hardware or some problem in configuring
> the processor (though I'm not sure how that could lead to a cache
> error).
> 
> Anton

Thank you.
___
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: [RFC] kern/kern_timeout.c rewrite in progress

[Ivan Klymenko]

В Mon, 29 Dec 2014 21:03:24 +0100
Hans Petter Selasky  пишет:

> Hi,
> 
> I recently came across a class of errors which lead me into 
> investigating the "kern/kern_timeout.c" and its subsystem. From what
> I can see new features like the SMP awareness has been "added"
> instead of fully "integrated". When going into the cornercases I've
> uncovered that the internal callout statemachine can sometimes report
> wrong values via its callout_active() and callout_pending() bits to
> its clients, which in turn can make the clients behave badly. I
> further did an investigation on how the safety of callout migration
> between CPU's is maintained. When I looked into the code and found
> stuff like "volatile" and "while()" loops to figure which CPU a
> callout belongs I understood that such logic completely undermines
> the cleverness found in the turnstiles of mutexes and decided to go
> through all of the logic inside "kern_timeout.c". Also static code
> analysis is harder when we don't use the basic mutexes and condition
> variables available in the kernel.
> 
> First of all we need to make some driving rules for everyone:
> 
> 1) A new feature called direct callbacks which execute the timer 
> callbacks from the fast interrupt handler was added. All these
> callbacks _must_ be associated with a regular spinlocks, to maintain
> a safe callout_drain(). Else they should only be executed on CPU0.
> 
> 2) All Giant locked callbacks should only execute on CPU0 to avoid 
> congestion.
> 
> 3) Callbacks using read-only locks for its callback should also only 
> execute on CPU0 to avoid multiple instances pending for completion on 
> multiple CPU's, because read-only locks can be entered multiple
> times. From what I can see, there are currently no consumers of this
> feature in the kernel.
> 
...

panic: spin lock held too long
http://paste.org.ru/?acf7io
___
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"

[ZFS] [panic] Fatal trap 12: page fault while in kernel mode.

[Ivan Klymenko]

I do not know the conditions - it just happened.

http://pastebin.com/BASJB599
___
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: [ZFS] [panic] Fatal trap 12: page fault while in kernel mode.

[Ivan Klymenko]

В Tue, 10 Feb 2015 22:01:29 +0200
Ivan Klymenko  пишет:

> I do not know the conditions - it just happened.
> 
> http://pastebin.com/BASJB599
> ___
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscr...@freebsd.org"


http://pastebin.com/8HjebJKB

http://pastebin.com/dx8PJKNr
___
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: [ZFS] [panic] Fatal trap 12: page fault while in kernel mode.

[Ivan Klymenko]

В Tue, 10 Feb 2015 22:01:29 +0200
Ivan Klymenko  пишет:

> I do not know the conditions - it just happened.
> 
> http://pastebin.com/BASJB599

next
http://pastebin.com/hY8GYpjd
___
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: r279278 failed to build (yacc: maximum table size exceeded)

[Ivan Klymenko]

В Wed, 25 Feb 2015 15:43:27 +
Glen Barber  пишет:

> On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin wrote:
> > I have clean svn tree with base/head branch. I try to build world,
> > but I have some mysterious bugs. The latest is yacc failed to make
> > c file on phase 4.3:
> > 
> > ===> usr.sbin/acpi/iasl (depend)
> > m4 -P
> > -I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler
> >  
> > /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslparser.y
> > > aslcompiler.y
> > yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y
> > yacc: 89 shift/reduce conflicts.
> > yacc: f - maximum table size exceeded
> > *** Error code 2
> > 
> > /etc/make.conf is /dev/null.
> > I've also tried empty /etc/src.conf with no luck.
> > 
> 
> Out of curiosity, is your src tree mounted via NFS?
> 
> Glen
> 

I have a similar problem on revision 
/usr/src # svn info
Path: .
Working Copy Root Path: /usr/src
URL: svn://svn.freebsd.org/base/head
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 279213
Node Kind: directory
Schedule: normal
Last Changed Author: glebius
Last Changed Rev: 279213
Last Changed Date: 2015-02-23 20:57:09 +0200 (Mon, 23 Feb 2015)

http://pastebin.com/FuAUkBmX

Source tree is on the zfs
/usr/src # zfs list zroot/usr/src
NAMEUSED  AVAIL  REFER  MOUNTPOINT
zroot/usr/src  1.35G   408G  1.35G  /usr/src

what is most surprising, the same revision successfully building for the
other 2 computers, including amd64|zfs and i386|ufs.
___
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: r279278 failed to build (yacc: maximum table size exceeded)

[Ivan Klymenko]

В Wed, 25 Feb 2015 12:27:06 -0500
Jung-uk Kim  пишет:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 02/25/2015 11:22, Ivan Klymenko wrote:
> > В Wed, 25 Feb 2015 15:43:27 + Glen Barber 
> > пишет:
> > 
> >> On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin wrote:
> >>> I have clean svn tree with base/head branch. I try to build
> >>> world, but I have some mysterious bugs. The latest is yacc
> >>> failed to make c file on phase 4.3:
> >>> 
> >>> ===> usr.sbin/acpi/iasl (depend) m4 -P 
> >>> -I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler
> >>>
> >>> 
> /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslparser.y
> >>>> aslcompiler.y
> >>> yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y yacc:
> >>> 89 shift/reduce conflicts. yacc: f - maximum table size
> >>> exceeded *** Error code 2
> >>> 
> >>> /etc/make.conf is /dev/null. I've also tried empty
> >>> /etc/src.conf with no luck.
> >>> 
> >> 
> >> Out of curiosity, is your src tree mounted via NFS?
> >> 
> >> Glen
> >> 
> > 
> > I have a similar problem on revision /usr/src # svn info Path: . 
> > Working Copy Root Path: /usr/src URL:
> > svn://svn.freebsd.org/base/head Relative URL: ^/head Repository
> > Root: svn://svn.freebsd.org/base Repository UUID:
> > ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213 Node Kind:
> > directory Schedule: normal Last Changed Author: glebius Last
> > Changed Rev: 279213 Last Changed Date: 2015-02-23 20:57:09 +0200
> > (Mon, 23 Feb 2015)
> > 
> > http://pastebin.com/FuAUkBmX
> > 
> > Source tree is on the zfs /usr/src # zfs list zroot/usr/src NAME
> > USED  AVAIL  REFER  MOUNTPOINT zroot/usr/src  1.35G   408G  1.35G
> > /usr/src
> > 
> > what is most surprising, the same revision successfully building
> > for the other 2 computers, including amd64|zfs and i386|ufs.
> 
> Your installed yacc(1) is too old, i.e., your world was built from
> head before r274460.  FYI, this commit fixes the above problem for
> building from stable:
> 
> https://svnweb.freebsd.org/changeset/base/278975
> 
> For building from old head (pre-r274460), you have to manually
> bootstrap yacc first, e.g., something like this:
> 
> cd /usr/src/usr.bin/yacc
> make clean cleandepend
> make all && make install
> make clean cleandepend
> cd /usr/src
> make buildworld
> 

Thank you - it solved the problem.
___
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"

>r280312 - r280332 VirtualBox is broken.

[Ivan Klymenko]

After auditing the r280312 I just upgraded to revision r280332 and then
discovered that my VirtualBox is broken.

Thanks.
___
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"

[SOLVED] Re: >r280312 - r280332 VirtualBox is broken.

[Ivan Klymenko]

Sun, 22 Mar 2015 00:13:11 +0200
Ivan Klymenko  написав:

> After auditing the r280312 I just upgraded to revision r280332 and
> then discovered that my VirtualBox is broken.
> 
> Thanks.

The problem was to use the port security/openssl.

1. Added WITH_OPENSSL_BASE=yes > /etc/make.conf
2. Delete installed security/openssl
3. Rebuild VirtualBox and others depends ports
___
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"

Build world error after update from r284175 to r284207

[Ivan Klymenko]

...
===> bin/getfacl (all)
--- gnu.all__D ---
--- floatformat.o ---
cc   -O2 -pipe   -DBFD_DEFAULT_TARGET_SIZE=64 -I. 
-I/usr/src/gnu/usr.bin/binutils/libiberty 
-I/usr/src/gnu/usr.bin/binutils/libiberty/../libbfd 
-I/media/da0s1/obj/usr/src/gnu/usr.bin/binutils/libiberty/../libbfd 
-I/usr/src/gnu/usr.bin/binutils/libiberty/../../../../contrib/binutils/include 
-DHAVE_CONFIG_H -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall 
-Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter -Qunused-arguments -c 
/usr/src/gnu/usr.bin/binutils/libiberty/../../../../contrib/binutils/libiberty/floatformat.c
 -o floatformat.o
--- bin.all__D ---
--- getfacl.o ---
cc  -O2 -pipe   -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall 
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings 
-Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline 
-Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign 
-Wmissing-variable-declarations -Wthread-safety -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c 
/usr/src/bin/getfacl/getfacl.c -o getfacl.o
--- cddl.all__D ---
--- uu_dprintf.po ---
cc  -pg  -O2 -pipe   -DNATIVE_BUILD 
-I/usr/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common
 -I/usr/src/cddl/lib/libuutil/../../../sys/cddl/compat/opensolaris 
-I/usr/src/cddl/lib/libuutil/../../../sys/cddl/contrib/opensolaris/uts/common 
-I/usr/src/cddl/lib/libuutil/../../../cddl/compat/opensolaris/include 
-I/usr/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/head 
-DNEED_SOLARIS_BOOLEAN -std=gnu99 -fstack-protector -Wno-pointer-sign 
-Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c 
/usr/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_dprintf.c
 -o uu_dprintf.po
--- gnu.all__D ---
--- hashtab.o ---
cc   -O2 -pipe   -DBFD_DEFAULT_TARGET_SIZE=64 -I. 
-I/usr/src/gnu/usr.bin/binutils/libiberty 
-I/usr/src/gnu/usr.bin/binutils/libiberty/../libbfd 
-I/media/da0s1/obj/usr/src/gnu/usr.bin/binutils/libiberty/../libbfd 
-I/usr/src/gnu/usr.bin/binutils/libiberty/../../../../contrib/binutils/include 
-DHAVE_CONFIG_H -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall 
-Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter -Qunused-arguments -c 
/usr/src/gnu/usr.bin/binutils/libiberty/../../../../contrib/binutils/libiberty/hashtab.c
 -o hashtab.o
--- cddl.all__D ---
--- uu_ident.po ---
cc  -pg  -O2 -pipe   -DNATIVE_BUILD 
-I/usr/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common
 -I/usr/src/cddl/lib/libuutil/../../../sys/cddl/compat/opensolaris 
-I/usr/src/cddl/lib/libuutil/../../../sys/cddl/contrib/opensolaris/uts/common 
-I/usr/src/cddl/lib/libuutil/../../../cddl/compat/opensolaris/include 
-I/usr/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/head 
-DNEED_SOLARIS_BOOLEAN -std=gnu99 -fstack-protector -Wno-pointer-sign 
-Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c 
/usr/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_ident.c
 -o uu_ident.po
--- bin.all__D ---
--- getfacl.1.gz ---
gzip -cn /usr/src/bin/getfacl/getfacl.1 > getfacl.1.gz
--- getfacl ---
cc  -O2 -pipe   -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall 
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings 
-Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline 
-Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign 
-Wmissing-variable-declarations -Wthread-safety -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments  -o getfacl 
getfacl.o 
--- all_subdir_hostname ---
===> bin/hostname (all)
--- libexec.all__D ---
--- ftpd ---
cc  -O2 -pipe   -DSETPROCTITLE

Re: Build world error after update from r284175 to r284207

[Ivan Klymenko]

Wed, 10 Jun 2015 13:01:32 +0300
Ivan Klymenko  написав:

> ...
> ===> bin/getfacl (all)
> --- gnu.all__D ---
> --- floatformat.o ---
> cc   -O2 -pipe   -DBFD_DEFAULT_TARGET_SIZE=64 -I.
> -I/usr/src/gnu/usr.bin/binutils/libiberty
> -I/usr/src/gnu/usr.bin/binutils/libiberty/../libbfd
> -I/media/da0s1/obj/usr/src/gnu/usr.bin/binutils/libiberty/../libbfd
> -I/usr/src/gnu/usr.bin/binutils/libiberty/../../../../contrib/binutils/include
> -DHAVE_CONFIG_H -std=gnu99 -fstack-protector -Wsystem-headers -Werror
> -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign
> -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
> -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
> -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter
> -Qunused-arguments
> -c 
> /usr/src/gnu/usr.bin/binutils/libiberty/../../../../contrib/binutils/libiberty/floatformat.c
> -o floatformat.o --- bin.all__D --- --- getfacl.o --- cc  -O2 -pipe
> -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall
> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
> -Wold-style-definition -Wno-pointer-sign
> -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body
> -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments
> -c /usr/src/bin/getfacl/getfacl.c -o getfacl.o --- cddl.all__D ---
> --- uu_dprintf.po --- cc  -pg  -O2 -pipe   -DNATIVE_BUILD
> -I/usr/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common
> -I/usr/src/cddl/lib/libuutil/../../../sys/cddl/compat/opensolaris
> -I/usr/src/cddl/lib/libuutil/../../../sys/cddl/contrib/opensolaris/uts/common
> -I/usr/src/cddl/lib/libuutil/../../../cddl/compat/opensolaris/include
> -I/usr/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/head
> -DNEED_SOLARIS_BOOLEAN -std=gnu99 -fstack-protector -Wno-pointer-sign
> -Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int
> -Wno-unused-const-variable -Wno-tautological-compare
> -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function
> -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch
> -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses
> -Qunused-arguments
> -c 
> /usr/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_dprintf.c
> -o uu_dprintf.po --- gnu.all__D --- --- hashtab.o --- cc   -O2
> -pipe   -DBFD_DEFAULT_TARGET_SIZE=64 -I.
> -I/usr/src/gnu/usr.bin/binutils/libiberty
> -I/usr/src/gnu/usr.bin/binutils/libiberty/../libbfd
> -I/media/da0s1/obj/usr/src/gnu/usr.bin/binutils/libiberty/../libbfd
> -I/usr/src/gnu/usr.bin/binutils/libiberty/../../../../contrib/binutils/include
> -DHAVE_CONFIG_H -std=gnu99 -fstack-protector -Wsystem-headers -Werror
> -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign
> -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
> -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
> -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter
> -Qunused-arguments
> -c 
> /usr/src/gnu/usr.bin/binutils/libiberty/../../../../contrib/binutils/libiberty/hashtab.c
> -o hashtab.o --- cddl.all__D --- --- uu_ident.po --- cc  -pg  -O2
> -pipe   -DNATIVE_BUILD
> -I/usr/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common
> -I/usr/src/cddl/lib/libuutil/../../../sys/cddl/compat/opensolaris
> -I/usr/src/cddl/lib/libuutil/../../../sys/cddl/contrib/opensolaris/uts/common
> -I/usr/src/cddl/lib/libuutil/../../../cddl/compat/opensolaris/include
> -I/usr/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/head
> -DNEED_SOLARIS_BOOLEAN -std=gnu99 -fstack-protector -Wno-pointer-sign
> -Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int
> -Wno-unused-const-variable -Wno-tautological-compare
> -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function
> -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch
> -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses
> -Qunused-arguments
> -c 
> /usr/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_ident.c
> -o uu_ident.po --- bin.all__D --- --- getfacl.1.gz --- gzip
> -cn /usr/src/bin/getfacl/getfacl.1 > getfacl.1.gz --- getfacl --- cc
> -O2 -pipe   -std=gnu99 -fstack-protector -Wsystem-headers -Werror
> -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
> -Wwrite-strings -Wswitch -Wshadow

Re: Build world error after update from r284175 to r284207

[Ivan Klymenko]

Wed, 10 Jun 2015 13:26:17 +0300
Ivan Klymenko  написав:

> Wed, 10 Jun 2015 13:01:32 +0300
> Ivan Klymenko  написав:
> 
> > ...
> > ===> bin/getfacl (all)
> > --- gnu.all__D ---
> > --- floatformat.o ---
> > cc   -O2 -pipe   -DBFD_DEFAULT_TARGET_SIZE=64 -I.
> > -I/usr/src/gnu/usr.bin/binutils/libiberty
> > -I/usr/src/gnu/usr.bin/binutils/libiberty/../libbfd
> > -I/media/da0s1/obj/usr/src/gnu/usr.bin/binutils/libiberty/../libbfd
> > -I/usr/src/gnu/usr.bin/binutils/libiberty/../../../../contrib/binutils/include
> > -DHAVE_CONFIG_H -std=gnu99 -fstack-protector -Wsystem-headers
> > -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign
> > -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
> > -Wno-tautological-compare -Wno-unused-value
> > -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion
> > -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum
> > -Wno-knr-promoted-parameter -Qunused-arguments
> > -c 
> > /usr/src/gnu/usr.bin/binutils/libiberty/../../../../contrib/binutils/libiberty/floatformat.c
> > -o floatformat.o --- bin.all__D --- --- getfacl.o --- cc  -O2 -pipe
> > -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall
> > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
> > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
> > -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
> > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
> > -Wold-style-definition -Wno-pointer-sign
> > -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body
> > -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments
> > -c /usr/src/bin/getfacl/getfacl.c -o getfacl.o --- cddl.all__D ---
> > --- uu_dprintf.po --- cc  -pg  -O2 -pipe   -DNATIVE_BUILD
> > -I/usr/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common
> > -I/usr/src/cddl/lib/libuutil/../../../sys/cddl/compat/opensolaris
> > -I/usr/src/cddl/lib/libuutil/../../../sys/cddl/contrib/opensolaris/uts/common
> > -I/usr/src/cddl/lib/libuutil/../../../cddl/compat/opensolaris/include
> > -I/usr/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/head
> > -DNEED_SOLARIS_BOOLEAN -std=gnu99 -fstack-protector
> > -Wno-pointer-sign -Wno-unknown-pragmas -Wno-empty-body
> > -Wno-string-plus-int -Wno-unused-const-variable
> > -Wno-tautological-compare -Wno-unused-value
> > -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion
> > -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum
> > -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments
> > -c 
> > /usr/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common/uu_dprintf.c
> > -o uu_dprintf.po --- gnu.all__D --- --- hashtab.o --- cc   -O2
> > -pipe   -DBFD_DEFAULT_TARGET_SIZE=64 -I.
> > -I/usr/src/gnu/usr.bin/binutils/libiberty
> > -I/usr/src/gnu/usr.bin/binutils/libiberty/../libbfd
> > -I/media/da0s1/obj/usr/src/gnu/usr.bin/binutils/libiberty/../libbfd
> > -I/usr/src/gnu/usr.bin/binutils/libiberty/../../../../contrib/binutils/include
> > -DHAVE_CONFIG_H -std=gnu99 -fstack-protector -Wsystem-headers
> > -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign
> > -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
> > -Wno-tautological-compare -Wno-unused-value
> > -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion
> > -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum
> > -Wno-knr-promoted-parameter -Qunused-arguments
> > -c 
> > /usr/src/gnu/usr.bin/binutils/libiberty/../../../../contrib/binutils/libiberty/hashtab.c
> > -o hashtab.o --- cddl.all__D --- --- uu_ident.po --- cc  -pg  -O2
> > -pipe   -DNATIVE_BUILD
> > -I/usr/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/lib/libuutil/common
> > -I/usr/src/cddl/lib/libuutil/../../../sys/cddl/compat/opensolaris
> > -I/usr/src/cddl/lib/libuutil/../../../sys/cddl/contrib/opensolaris/uts/common
> > -I/usr/src/cddl/lib/libuutil/../../../cddl/compat/opensolaris/include
> > -I/usr/src/cddl/lib/libuutil/../../../cddl/contrib/opensolaris/head
> > -DNEED_SOLARIS_BOOLEAN -std=gnu99 -fstack-protector
> > -Wno-pointer-sign -Wno-unknown-pragmas -Wno-empty-body
> > -Wno-string-plus-int -Wno-unused-const-variable
> > -Wno-tautological-compare -Wno-unused-value
> > -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion
> > -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum
> > -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments
> > -c 
> > /usr/src/cddl/lib/libuutil/../../../cddl/con

Re: src/libexec/ftpd possible make error on svn_revision 284205

[Ivan Klymenko]

Wed, 10 Jun 2015 18:27:30 +0200
"Julian H. Stacey"  написав:

> There may possibly be an un-matched commit at:
> cat /usr/src/.svn_revision # 284205
> cat /usr/src/.ctm_status # src-cur 11995
> make world
> 
> /usr/src/libexec/ftpd/../../bin/ls/print.c:(.text+0xdf8): undefined
> reference to
> `xo_close_list' /usr/src/libexec/ftpd/../../bin/ls/print.c:(.text+0xe01):
> undefined reference to `xo_warn' util.o: In function
> `prn_normal': /usr/src/libexec/ftpd/../../bin/ls/util.c:(.text+0x43):
> undefined reference to `xo_emit' util.o: In function
> `usage': /usr/src/libexec/ftpd/../../bin/ls/util.c:(.text+0x84c):
> undefined reference to `xo_error' cc: error: linker command failed
> with exit code 1 (use -v to see invocation) *** Error code 1
> 
> Now I'm runnning make -k all
> Before the world above I had run
>   'cd src/include ; make install ; cd .. ; make all'
> so the problem might be just here.
> 
> Cheers,
> Julian
> --
> Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich
> http://berklix.com Indent previous with "> ". Reply Below as a
> play script. Send plain text, Not quoted-printable, HTML, or base64.
> ___
> 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"

Fixed r284221
___
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"

Build world problem r284331 > r284377

[Ivan Klymenko]

...
CC='cc  ' mkdep -f .depend -a-DBTHIDCONTROL=1 
-I/usr/src/usr.sbin/bluetooth/bthidcontrol/../bthidd -std=gnu99   
/usr/src/usr.sbin/bluetooth/bthidcontrol/bthidcontrol.c 
/usr/src/usr.sbin/bluetooth/bthidcontrol/hid.c lexer.c parser.c 
/usr/src/usr.sbin/bluetooth/bthidcontrol/sdp.c
--- depend_subdir_bsnmpd ---
--- atm_tree.c ---
cat 
/usr/src/usr.sbin/bsnmpd/modules/snmp_atm/../../../../contrib/ngatm/snmp_atm/atm_tree.def
 /usr/src/usr.sbin/bsnmpd/modules/snmp_atm/atm_freebsd.def | gensnmptree -p atm_
--- atm_oid.h ---
cat 
/usr/src/usr.sbin/bsnmpd/modules/snmp_atm/../../../../contrib/ngatm/snmp_atm/atm_tree.def
 /usr/src/usr.sbin/bsnmpd/modules/snmp_atm/atm_freebsd.def | gensnmptree -e 
begemotAtm > atm_oid.h
--- .depend ---
rm -f .depend
CC='cc  ' mkdep -f .depend -a
-I/usr/src/usr.sbin/bsnmpd/modules/snmp_atm/../../../../contrib/ngatm/snmp_atm 
-I. -std=gnu99   
/usr/src/usr.sbin/bsnmpd/modules/snmp_atm/../../../../contrib/ngatm/snmp_atm/snmp_atm.c
 /usr/src/usr.sbin/bsnmpd/modules/snmp_atm/atm_sys.c atm_tree.c
--- usr.bin.depend__D ---
--- depend_subdir_keylogout ---
===> usr.bin/keylogout (depend)
--- .depend ---
rm -f .depend
CC='cc  ' mkdep -f .depend -a -std=gnu99   
/usr/src/usr.bin/keylogout/keylogout.c
echo keylogout: /media/da0s1/obj/usr/src/tmp/usr/lib/libc.a  >> .depend
--- depend_subdir_killall ---
===> usr.bin/killall (depend)
--- usr.sbin.depend__D ---
===> usr.sbin/bsnmpd/modules/snmp_bridge (depend)
--- usr.bin.depend__D ---
--- .depend ---
rm -f .depend
CC='cc  ' mkdep -f .depend -a -std=gnu99   
/usr/src/usr.bin/killall/killall.c
--- usr.sbin.depend__D ---
--- depend_subdir_bluetooth ---
echo bthidcontrol: /media/da0s1/obj/usr/src/tmp/usr/lib/libc.a 
/media/da0s1/obj/usr/src/tmp/usr/lib/libbluetooth.a 
/media/da0s1/obj/usr/src/tmp/usr/lib/libsdp.a 
/media/da0s1/obj/usr/src/tmp/usr/lib/libusbhid.a >> .depend
===> usr.sbin/bluetooth/bthidd (depend)
--- depend_subdir_bsnmpd ---
--- bridge_tree.c ---
cat /usr/src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_tree.def | gensnmptree 
-p bridge_
--- bridge_oid.h ---
cat /usr/src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_tree.def | gensnmptree 
-e dot1dBridge newRoot topologyChange begemotBridgeNewRoot  
begemotBridgeTopologyChange begemotBridgeBaseName > bridge_oid.h
--- depend_subdir_bluetooth ---
--- lexer.c ---
lex  -olexer.c /usr/src/usr.sbin/bluetooth/bthidd/lexer.l
--- depend_subdir_bsnmpd ---
--- .depend ---
rm -f .depend
CC='cc  ' mkdep -f .depend -a-DSNMPTREE_TYPES -I. -std=gnu99   
/usr/src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_snmp.c 
/usr/src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_if.c 
/usr/src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_port.c 
/usr/src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_addrs.c 
/usr/src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_pf.c 
/usr/src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c bridge_tree.c
--- depend_subdir_bluetooth ---
--- parser.c ---
yacc -d -o parser.c /usr/src/usr.sbin/bluetooth/bthidd/parser.y
--- usr.bin.depend__D ---
echo killall: /media/da0s1/obj/usr/src/tmp/usr/lib/libc.a 
/media/da0s1/obj/usr/src/tmp/usr/lib/libjail.a >> .depend
--- depend_subdir_ktrace ---
--- usr.sbin.depend__D ---
--- .depend ---
--- usr.bin.depend__D ---
===> usr.bin/ktrace (depend)
--- usr.sbin.depend__D ---
rm -f .depend
CC='cc  ' mkdep -f .depend -a-I/usr/src/usr.sbin/bluetooth/bthidd 
-std=gnu99   /usr/src/usr.sbin/bluetooth/bthidd/bthidd.c 
/usr/src/usr.sbin/bluetooth/bthidd/client.c 
/usr/src/usr.sbin/bluetooth/bthidd/hid.c 
/usr/src/usr.sbin/bluetooth/bthidd/kbd.c lexer.c parser.c 
/usr/src/usr.sbin/bluetooth/bthidd/server.c 
/usr/src/usr.sbin/bluetooth/bthidd/session.c
--- usr.bin.depend__D ---
--- .depend ---
rm -f .depend
CC='cc  ' mkdep -f .depend -a -std=gnu99   /usr/src/usr.bin/ktrace/ktrace.c 
/usr/src/usr.bin/ktrace/subr.c
echo ktrace: /media/da0s1/obj/usr/src/tmp/usr/lib/libc.a  >> .depend
--- usr.sbin.depend__D ---
--- depend_subdir_btxld ---
===> usr.sbin/btxld (depend)
--- .depend ---
rm -f .depend
CC='cc  ' mkdep -f .depend -a -std=gnu99   /usr/src/usr.sbin/btxld/btxld.c 
/usr/src/usr.sbin/btxld/elfh.c
--- depend_subdir_bsnmpd ---
===> usr.sbin/bsnmpd/modules/snmp_hast (depend)
--- hast_tree.c ---
cat /usr/src/usr.sbin/bsnmpd/modules/snmp_hast/hast_tree.def | gensnmptree -p 
hast_
--- depend_subdir_btxld ---
echo btxld: /media/da0s1/obj/usr/src/tmp/usr/lib/libc.a  >> .depend
--- usr.bin.depend__D ---
--- depend_subdir_ktrdump ---
===> usr.bin/ktrdump (depend)
--- usr.sbin.depend__D ---
--- depend_subdir_bsnmpd ---
--- parse.c ---
yacc -d -v 
/usr/src/usr.sbin/bsnmpd/modules/snmp_hast/../../../../sbin/hastd/parse.y
cp y.tab.c parse.c
--- token.c ---
lex  -otoken.c 
/usr/src/usr.sbin/bsnmpd/modules/snmp_hast/../../../../sbin/hastd/token.l
--- depend_subdir_bluetooth ---
echo bthidd: /media/da0s1/obj/usr/src/tmp/usr/lib/libc.a 
/media/da0s1/obj/usr/src/tmp/usr/lib/libbluetooth.a 
/media/da0s1/obj/usr/src/tmp/usr/lib/libusbhid.a >> .depend
--- de

Re: Error building x11/nvidia-driver kernel module @r284408

[Ivan Klymenko]

Mon, 15 Jun 2015 06:34:12 -0700
David Wolfskill  написав:

> Now that "vanilla" head @284408 builds (& boots):
> 
> FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT
> #1751  r284408M/284408:1100077: Mon Jun 15 05:51:00 PDT 2015
> r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/GENERIC
> amd64
> 
> I find that for my laptop, I encounter an error while trying to build
> the x11/nvidia-driver kernel module (courtesy of /etc/src.conf:
> 
> Please note that the (similar) refreshes for stable/10 (@r284404)
> had no problems; I have typescripts of them accessible (but I haven't
> put'them up on the Web server, as they're pretty boring).
> 
> Perhaps some changes need to be made for (some?) ports to adjust for
> recent make & mk changes in head?
> 
> I note that in the stable/10 case,
> the 
> .../obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-346.47/src/machine
> "file" is a symlink to /usr/src/sys/amd64/include -- and that it
> doesn't exist in the i386 case (and that doesn't appear to be a
> problem).
> 
> Peace,
> david

The situation|problem is similar with emulators/virtualbox-ose-kmod
I think that many of the modules from the port tree will not be
building, but personally tested only emulators/virtualbox-ose-kmod.
___
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: Build world problem r284331 > r284377

[Ivan Klymenko]

Mon, 15 Jun 2015 22:05:29 +0200
"O. Hartmann"  написав:

> Am Mon, 15 Jun 2015 20:27:49 +0200
> Dimitry Andric  schrieb:
> 
> > On 15 Jun 2015, at 18:21, O. Hartmann 
> > wrote: ...
> > > r284417 still fails ...
> > 
> > Please revert to r284344, e.g. just before r284345 (the huge
> > "meta-mode" commit by Simon).  This broke custom CXXFLAGS for mkdep
> > invocations.  I have updated bug 200868 with some information. [1]
> > 
> > -Dimitry
> > 
> > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200868#c6
> > 
> 
> 
> Tried reverting to r284344, but buildworld fails in the same or
> similar manner ...

My revision 284344 was built properly.
___
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: Build world problem r284331 > r284377

[Ivan Klymenko]

Mon, 15 Jun 2015 22:51:42 +0200
Baptiste Daroussin  написав:

> On Mon, Jun 15, 2015 at 11:50:05PM +0300, Ivan Klymenko wrote:
> > Mon, 15 Jun 2015 22:05:29 +0200
> > "O. Hartmann"  написав:
> > 
> > > Am Mon, 15 Jun 2015 20:27:49 +0200
> > > Dimitry Andric  schrieb:
> > > 
> > > > On 15 Jun 2015, at 18:21, O. Hartmann
> > > >  wrote: ...
> > > > > r284417 still fails ...
> > > > 
> > > > Please revert to r284344, e.g. just before r284345 (the huge
> > > > "meta-mode" commit by Simon).  This broke custom CXXFLAGS for
> > > > mkdep invocations.  I have updated bug 200868 with some
> > > > information. [1]
> > > > 
> > > > -Dimitry
> > > > 
> > > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200868#c6
> > > > 
> > > 
> > > 
> > > Tried reverting to r284344, but buildworld fails in the same or
> > > similar manner ...
> > 
> > My revision 284344 was built properly.
> 
> FYI head should be fix for standard options, non standard options may
> need some work
> 
> Best regards,
> Bapt

standard options != defaults options ;)
___
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"

build world from ccache broken after > r284345

[Ivan Klymenko]

Hi.

I have next problem:

root@nonamehost:/usr/src # make -j5 buildworld kernel
--- buildworld ---
--- buildworld_prologue ---
--
>>> World build started on Fri Jun 19 10:43:22 EEST 2015
--
--- _worldtmp ---
--
>>> Rebuilding the temporary build tree
--
rm -rf /media/da0s1/obj/usr/src/tmp
rm -rf /media/da0s1/obj/usr/src/lib32
mkdir -p /media/da0s1/obj/usr/src/tmp/lib
mkdir -p /media/da0s1/obj/usr/src/tmp/usr
mkdir -p /media/da0s1/obj/usr/src/tmp/legacy/bin
mkdir -p /media/da0s1/obj/usr/src/tmp/legacy/usr
mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist
-p /media/da0s1/obj/usr/src/tmp/legacy/usr >/dev/null mtree -deU
-f /usr/src/etc/mtree/BSD.groff.dist
-p /media/da0s1/obj/usr/src/tmp/legacy/usr >/dev/null mtree -deU
-f /usr/src/etc/mtree/BSD.usr.dist  -p /media/da0s1/obj/usr/src/tmp/usr
>/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.include.dist
>-p /media/da0s1/obj/usr/src/tmp/usr/include >/dev/null ln
>-sf /usr/src/sys /media/da0s1/obj/usr/src/tmp --- _legacy ---
--
>>> stage 1.1: legacy release compatibility shims
--
cd /usr/src; MAKEOBJDIRPREFIX=/media/da0s1/obj/usr/src/tmp
INSTALL="sh /usr/src/tools/install.sh"
PATH=/media/da0s1/obj/usr/src/tmp/legacy/usr/sbin:/media/da0s1/obj/usr/src/tmp/legacy/usr/bin:/media/da0s1/obj/usr/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
WORLDTMP=/media/da0s1/obj/usr/src/tmp  VERSION="FreeBSD 11.0-CURRENT
amd64 1100077"  MAKEFLAGS="-m /usr/src/tools/build/mk  -j 5 -J 15,16
-m /usr/src/share/mk" make  -f Makefile.inc1  DESTDIR=
BOOTSTRAPPING=1100077  SSP_CFLAGS=  MK_HTML=no NO_LINT=yes MK_MAN=no
-DNO_PIC MK_PROFILE=no -DNO_SHARED  -DNO_CPU_CFLAGS MK_WARNS=no
MK_CTF=no  MK_CLANG_EXTRAS=no MK_CLANG_FULL=no  MK_LLDB=no MK_TESTS=no
MK_INCLUDES=yes legacy --- legacy --- ===> tools/build
(obj,includes,depend,all,install) --- obj
--- /media/da0s1/obj/usr/src/tmp/usr/src/tools/build created
for /usr/src/tools/build --- includes --- ; cd /usr/src/tools/build;
make buildincludes; make installincludes --- .depend --- rm -f .depend
CC=' ' mkdep -f .depend -a
-I/media/da0s1/obj/usr/src/tmp/legacy/usr/include
-std=gnu99   /usr/src/tools/build/dummy.c /usr/bin/mkdep: -E: not found
mkdep: compile failed *** [.depend] Error code 1

make[3]: stopped in /usr/src/tools/build
1 error

make[3]: stopped in /usr/src/tools/build
A failure has been detected in another branch of the parallel make

make[2]: stopped in /usr/src
*** [_legacy] Error code 2

make[1]: stopped in /usr/src
1 error

make[1]: stopped in /usr/src
*** [buildworld] Error code 2

make: stopped in /usr/src
1 error

make: stopped in /usr/src


For the early revisions of all passed successfully.

For example, on my i386 router the buildworld (after > r284345) with
use time for more than 2 days! Before it takes a few hours.

What should be done, that would be everything as before?

Thanks.
___
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: build world from ccache broken after > r284345

[Ivan Klymenko]

Fri, 19 Jun 2015 07:58:57 -0700
"Simon J. Gerraty"  написав:

> Ivan Klymenko  wrote:
> > I have next problem:
> 
> I just commited the patch in D2860, which at least one user confirms
> fixed his problems, and since I assume you are introducing ccache
> via make.conf or src.conf should fix yours too.

Thanks.
___
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: panic in sysctl code in recent head

[Ivan Klymenko]

Thu, 30 Jul 2015 12:11:22 -0700
Navdeep Parhar  написав:

> Does anyone else see this too?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201992
___
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: panic in sysctl code in recent head

[Ivan Klymenko]

Thu, 30 Jul 2015 21:53:20 +0200
Mateusz Guzik  написав:

> On Thu, Jul 30, 2015 at 10:17:10PM +0300, Ivan Klymenko wrote:
> > Thu, 30 Jul 2015 12:11:22 -0700
> > Navdeep Parhar  написав:
> > 
> > > Does anyone else see this too?
> > 
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201992
> 
> This bz is unrelated.

Oops. Sorry.

> 
> Problematic change was reverted in r286094.
> 
___
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"

emulators/virtualbox-ose-kmod build error

[Ivan Klymenko]

After update from r295867 to r295994:

...
/usr/local/bin/ccache cc -O2 -pipe -march=native -fno-strict-aliasing 
-DRT_OS_FREEBSD -DIN_RING0 -DIN_RT_R0 -DIN_SUP_R0 -DSUPDRV_WITH_RELEASE_LOGGER 
-DVBOX -DRT_WITH_VBOX -w -DVBOX_WITH_HARDENING -DVBOX_WITH_64_BITS_GUESTS 
-DRT_ARCH_AMD64 -march=native  -Werror -D_KERNEL -DKLD_MODULE -nostdinc  
-Iinclude -I. -Ir0drv -I. -I/usr/src/sys -fno-common  -fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer  -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse 
-msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv 
-fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign -Wno-error-shift-negative-value  -fvectorize 
-fslp-vectorize -fbloc
 ks -fcolor-diagnostics -mno-aes -mno-avx  -std=iso9899:1999 -c 
/media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c
 -o memobj-r0drv-freebsd.o
--- assert-r0drv-freebsd.o ---
In file included from 
/media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/assert-r0drv-freebsd.c:34:
In file included from 
/media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/the-freebsd-kernel.h:39:
/usr/src/sys/sys/bus.h:659:10: fatal error: 'device_if.h' file not found
#include "device_if.h"
 ^
--- alloc-r0drv-freebsd.o ---
In file included from 
/media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/alloc-r0drv-freebsd.c:34:
In file included from 
/media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/the-freebsd-kernel.h:39:
/usr/src/sys/sys/bus.h:659:10: fatal error: 'device_if.h' file not found
#include "device_if.h"
 ^
--- assert-r0drv-freebsd.o ---
1 error generated.
--- initterm-r0drv-freebsd.o ---
In file included from 
/media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/initterm-r0drv-freebsd.c:34:
In file included from 
/media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/the-freebsd-kernel.h:39:
/usr/src/sys/sys/bus.h:659:10: fatal error: 'device_if.h' file not found
#include "device_if.h"
 ^
--- assert-r0drv-freebsd.o ---
*** [assert-r0drv-freebsd.o] Error code 1

make[3]: stopped in 
/media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv
--- initterm-r0drv-freebsd.o ---
1 error generated.
--- alloc-r0drv-freebsd.o ---
1 error generated.
--- initterm-r0drv-freebsd.o ---
*** [initterm-r0drv-freebsd.o] Error code 1

make[3]: stopped in 
/media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv
--- memobj-r0drv-freebsd.o ---
In file included from 
/media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c:36:
In file included from 
/media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/the-freebsd-kernel.h:39:
/usr/src/sys/sys/bus.h:659:10: fatal error: 'device_if.h' file not found
#include "device_if.h"
 ^
--- alloc-r0drv-freebsd.o ---
*** [alloc-r0drv-freebsd.o] Error code 1

make[3]: stopped in 
/media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv
--- memobj-r0drv-freebsd.o ---
1 error generated.
*** [memobj-r0drv-freebsd.o] Error code 1

make[3]: stopped in 
/media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv
4 errors

make[3]: stopped in 
/media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src/vboxdrv
*** [all] Error code 2

make[2]: stopped in 
/media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src
1 error

make[2]: stopped in 
/media/da0s1/obj/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.3.36/out/freebsd.amd64/release/bin/src
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make[1]:

Re: emulators/virtualbox-ose-kmod build error

[Ivan Klymenko]

On Thu, 25 Feb 2016 09:46:04 +0100
"O. Hartmann"  wrote:

> On Thu, 25 Feb 2016 09:31:00 +0100
> Tommy Scheunemann  wrote:
> 
> > > Am Wed, 24 Feb 2016 22:04:29 +0200
> > > Ivan Klymenko  schrieb:
> > >
> > >> After update from r295867 to r295994:
> > >>
> > >> ...
> > >
> > > Same here ...
> > >
> > 
> > Hi,
> > 
> > try to disable ccache for building the port. Been running into the
> > same problem and disabling ccache fixed it.
> > 
> > Kind regards  
> 
> Don't use ccache!

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

So the problem is not on the ccache ;)
___
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 r296272 breaks virtualbox

[Ivan Klymenko]

On Tue, 1 Mar 2016 17:29:37 -0500
Michael Butler  wrote:

> The removal of "taskqueue_enqueue_fast" breaks the virtualbox kmods:
> 
> Mar  1 16:54:36 toshi kernel: vboxdrv: fAsync=0 offMin=0x914
> offMax=0x151c Mar  1 16:54:36 toshi kernel: link_elf_obj: symbol
> taskqueue_enqueue_fast undefined
> Mar  1 16:54:36 toshi kernel: linker_load_file: Unsupported file type
> Mar  1 16:54:36 toshi kernel: link_elf_obj: symbol
> taskqueue_enqueue_fast undefined
> Mar  1 16:54:36 toshi kernel: linker_load_file: Unsupported file type
> Mar  1 16:54:36 toshi kernel: KLD vboxnetadp.ko: depends on
> vboxnetflt - not available or version mismatch
> Mar  1 16:54:36 toshi kernel: linker_load_file: Unsupported file type
> 
>   Michael
> 


+1
___
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: SD card adapter doesn't working anymore

[Ivan Klymenko]

On Fri, 25 Mar 2016 23:33:45 +0300
Ruslan Makhmatkhanov  wrote:

> Hello,
> 
> I have this in pciconf output:
> 
> ==
> none1@pci0:36:0:0:class=0x088000 card=0x167e103c
> chip=0x2392197b rev=0x30 hdr=0x00
>  vendor = 'JMicron Technology Corp.'
>  device = 'SD/MMC Host Controller'
>  class  = base peripheral
> 
> none2@pci0:36:0:3:class=0x088000 card=0x167e103c
> chip=0x2393197b rev=0x30 hdr=0x00
>  vendor = 'JMicron Technology Corp.'
>  device = 'MS Host Controller'
>  class  = base peripheral
> ==
> 
> And my SD-card controller is not working anymore (it worked on
> -current on the same laptop year or two ago). Do I need to load some
> kld to make it working, or support for this controllers was dropped
> altogether for some reason? I have mostly vanilla GENERIC at r296772,
> but it actually stopped to work much earlier.
> 
> Thanks.
> 

+1
I would also like to clarify about this problem was drawn up a bug
report.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193341

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: SD card adapter doesn't working anymore

[Ivan Klymenko]

On Sat, 26 Mar 2016 00:05:13 +0300
Ruslan Makhmatkhanov  wrote:

> Ivan Klymenko wrote on 03/25/16 11:41 PM:
> > On Fri, 25 Mar 2016 23:33:45 +0300
> > Ruslan Makhmatkhanov  wrote:
> >  
> >> Hello,
> >>
> >> I have this in pciconf output:
> >>
> >> ==
> >> none1@pci0:36:0:0: class=0x088000 card=0x167e103c
> >> chip=0x2392197b rev=0x30 hdr=0x00
> >>   vendor = 'JMicron Technology Corp.'
> >>   device = 'SD/MMC Host Controller'
> >>   class  = base peripheral
> >>
> >> none2@pci0:36:0:3: class=0x088000 card=0x167e103c
> >> chip=0x2393197b rev=0x30 hdr=0x00
> >>   vendor = 'JMicron Technology Corp.'
> >>   device = 'MS Host Controller'
> >>   class  = base peripheral
> >> ==
> >>
> >> And my SD-card controller is not working anymore (it worked on
> >> -current on the same laptop year or two ago). Do I need to load
> >> some kld to make it working, or support for this controllers was
> >> dropped altogether for some reason? I have mostly vanilla GENERIC
> >> at r296772, but it actually stopped to work much earlier.
> >>
> >> Thanks.
> >>  
> >
> > +1
> > I would also like to clarify about this problem was drawn up a bug
> > report.
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193341
> >
> > Thanks.  
> 
> Hah, I even see my comment from 2014 in this PR.

I have it broken just from that moment to this day.
uname -a
FreeBSD nonamehost.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r297234:
Thu Mar 24 15:15:39 EET 2016
ivan@nonamehost.local:/media/da0s1/obj/usr/src/sys/mk11  amd64


> So looks like it was 
> broken not in r292180 as Ian pointed, but much-much earlier. Anyway, 
> I'll try to update to fresh -current first.
> 
___
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: SD card adapter doesn't working anymore

[Ivan Klymenko]

On Fri, 25 Mar 2016 15:33:58 -0600
Ian Lepore  wrote:

> On Fri, 2016-03-25 at 23:11 +0200, Ivan Klymenko wrote:
> > On Sat, 26 Mar 2016 00:05:13 +0300
> > Ruslan Makhmatkhanov  wrote:
> >   
> > > Ivan Klymenko wrote on 03/25/16 11:41 PM:  
> > > > On Fri, 25 Mar 2016 23:33:45 +0300
> > > > Ruslan Makhmatkhanov  wrote:
> > > >
> > > > > Hello,
> > > > > 
> > > > > I have this in pciconf output:
> > > > > 
> > > > > ===
> > > > > ===
> > > > > none1@pci0:36:0:0:class=0x088000 card=0x167e103c
> > > > > chip=0x2392197b rev=0x30 hdr=0x00
> > > > >   vendor = 'JMicron Technology Corp.'
> > > > >   device = 'SD/MMC Host Controller'
> > > > >   class  = base peripheral
> > > > > 
> > > > > none2@pci0:36:0:3:class=0x088000 card=0x167e103c
> > > > > chip=0x2393197b rev=0x30 hdr=0x00
> > > > >   vendor = 'JMicron Technology Corp.'
> > > > >   device = 'MS Host Controller'
> > > > >   class  = base peripheral
> > > > > ===
> > > > > ===
> > > > > 
> > > > > And my SD-card controller is not working anymore (it worked on
> > > > > -current on the same laptop year or two ago). Do I need to
> > > > > load some kld to make it working, or support for this
> > > > > controllers was
> > > > > dropped altogether for some reason? I have mostly vanilla
> > > > > GENERIC
> > > > > at r296772, but it actually stopped to work much earlier.
> > > > > 
> > > > > Thanks.
> > > > >
> > > > 
> > > > +1
> > > > I would also like to clarify about this problem was drawn up a
> > > > bug
> > > > report.
> > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193341
> > > > 
> > > > Thanks.
> > > 
> > > Hah, I even see my comment from 2014 in this PR.  
> > 
> > I have it broken just from that moment to this day.
> > uname -a
> > FreeBSD nonamehost.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0
> > r297234:
> > Thu Mar 24 15:15:39 EET 2016
> > ivan@nonamehost.local:/media/da0s1/obj/usr/src/sys/mk11  amd64
> > 
> >   
> > > So looks like it was 
> > > broken not in r292180 as Ian pointed, but much-much earlier.
> > > Anyway, 
> > > I'll try to update to fresh -current first.
> > >   
> 
> That PR has a very small range, r271081-138, but I don't any changes
> in that range related to sdhci, or to pci.  The PR doesn't say
> anything about how the device "doesn't work".  Does the sdhci device
> show up in dmesg, but the sd card is never detected, or does sdhci
> not even attach?
> 
> -- Ian

"doesn't work" - this means that the necessary modules loaded either
nothing happens by dmesg and does not appear in the device /dev/

in any case - it is a message about the problem and some strange
reason, unless specified more detailed report.
___
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: Heads up

[Ivan Klymenko]

On Thu, 14 Apr 2016 16:42:33 -0600
Warner Losh  wrote:

> The CAM I/O scheduler has been committed to current. This work is
> described in
> https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the
> default scheduler doesn't change the default (old) behavior.
> 
> One possible issue, however, is that it also enables NCQ Trims on ada
> SSDs. There are a few rogue drives that claim support for this
> feature, but actually implement data corrupt instead of queued trims.
> The list of known rogues is believed to be complete, but some caution
> is in order.
> 
> Warner

Hi.
Thanks for you work.
But i have problem with VirtualBox if i use the kernel with option
CAM_NETFLIX_IOSCHED
http://imgur.com/JpcfW1h
___
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: Heads up

[Ivan Klymenko]

On Fri, 15 Apr 2016 07:29:23 -0600
Warner Losh  wrote:

> Do you have this problem w/o CAM_NETFLIX_IOSCHED?

I not have problem without option CAM_NETFLIX_IOSCHED.

> 
> What version of virtualbox? I've not booted with that in 3 years.

virtualbox-ose-4.3.36

> 
> Warner
> 
> On Fri, Apr 15, 2016 at 2:44 AM, Ivan Klymenko  wrote:
> 
> > On Thu, 14 Apr 2016 16:42:33 -0600
> > Warner Losh  wrote:
> >  
> > > The CAM I/O scheduler has been committed to current. This work is
> > > described in
> > > https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though
> > > the default scheduler doesn't change the default (old) behavior.
> > >
> > > One possible issue, however, is that it also enables NCQ Trims on
> > > ada SSDs. There are a few rogue drives that claim support for this
> > > feature, but actually implement data corrupt instead of queued
> > > trims. The list of known rogues is believed to be complete, but
> > > some caution is in order.
> > >
> > > Warner  
> >
> > Hi.
> > Thanks for you work.
> > But i have problem with VirtualBox if i use the kernel with option
> > CAM_NETFLIX_IOSCHED
> > http://imgur.com/JpcfW1h
> >  
___
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: Heads up

[Ivan Klymenko]

On Thu, 14 Apr 2016 16:42:33 -0600
Warner Losh  wrote:

> The CAM I/O scheduler has been committed to current. This work is
> described in
> https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the
> default scheduler doesn't change the default (old) behavior.
> 
> One possible issue, however, is that it also enables NCQ Trims on ada
> SSDs. There are a few rogue drives that claim support for this
> feature, but actually implement data corrupt instead of queued trims.
> The list of known rogues is believed to be complete, but some caution
> is in order.
> 
> Warner

Hi.
i386 arch build error r298145:
...
--- cam_iosched.o ---
/usr/local/libexec/ccache/world/cc -target i386-unknown-freebsd11.0 
--sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe 
-march=native  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   
-DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/k11/opt_global.h -I. 
-I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/k11  -MD  
-MF.depend.cam_iosched.o -MTcam_iosched.o -mno-mmx -mno-sse -msoft-float 
-ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign -Wno-error-shift-negative-value  -Ofast -fvectorize 
-fslp-vectorize -fblocks -fcolor-diagnostics -mno-aes -mno-avx  -std
 =iso9899:1999 -c /usr/src/sys/modules/cam/../../cam/cam_iosched.c -o 
cam_iosched.o
/usr/src/sys/modules/cam/../../cam/cam_iosched.c:612:8: error: format specifies 
type 'long' but the argument has type 'unsigned long long' [-Werror,-Wformat]
((uint64_t)100 * (uint32_t)lat) >> 32);
^
1 error generated.
*** [cam_iosched.o] Error code 1

make[4]: stopped in /usr/src/sys/modules/cam
1 error

make[4]: stopped in /usr/src/sys/modules/cam
*** [all_subdir_cam] Error code 2

make[3]: stopped in /usr/src/sys/modules
--- all_subdir_bxe ---
--- bxe_elink.o ---
ctfconvert -L VERSION -g bxe_elink.o
A failure has been detected in another branch of the parallel make

make[4]: stopped in /usr/src/sys/modules/bxe
*** [all_subdir_bxe] Error code 2

make[3]: stopped in /usr/src/sys/modules
2 errors

make[3]: stopped in /usr/src/sys/modules
*** [modules-all] Error code 2

make[2]: stopped in /usr/obj/usr/src/sys/k11
1 error

make[2]: stopped in /usr/obj/usr/src/sys/k11
*** [buildkernel] Error code 2

make[1]: stopped in /usr/src
1 error

make[1]: stopped in /usr/src
*** [buildkernel] Error code 2

make: stopped in /usr/src
1 error

make: stopped in /usr/src
Press any key to continue...
___
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: Heads up

[Ivan Klymenko]

On Thu, 14 Apr 2016 16:42:33 -0600
Warner Losh  wrote:

> The CAM I/O scheduler has been committed to current. This work is
> described in
> https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the
> default scheduler doesn't change the default (old) behavior.
> 
> One possible issue, however, is that it also enables NCQ Trims on ada
> SSDs. There are a few rogue drives that claim support for this
> feature, but actually implement data corrupt instead of queued trims.
> The list of known rogues is believed to be complete, but some caution
> is in order.
> 
> Warner

Hi.

I have the small issue.
I have one hard drive with zfs.
If i beginning cloning the hard drive in VirtualBox machine - this
process is very slow 1,5-2 hours.
Without CAM_NETFLIX_IOSCHED options - this process two or three times
faster.
With this is possible to do something?
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: Heads up

[Ivan Klymenko]

On Fri, 15 Apr 2016 11:44:43 +0300
Ivan Klymenko  wrote:

> On Thu, 14 Apr 2016 16:42:33 -0600
> Warner Losh  wrote:
> 
> > The CAM I/O scheduler has been committed to current. This work is
> > described in
> > https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the
> > default scheduler doesn't change the default (old) behavior.
> > 
> > One possible issue, however, is that it also enables NCQ Trims on
> > ada SSDs. There are a few rogue drives that claim support for this
> > feature, but actually implement data corrupt instead of queued
> > trims. The list of known rogues is believed to be complete, but
> > some caution is in order.
> > 
> > Warner  
> 
> Hi.
> Thanks for you work.
> But i have problem with VirtualBox if i use the kernel with option
> CAM_NETFLIX_IOSCHED
> http://imgur.com/JpcfW1h

This problem is not over.
After the update on other hardware from r296979 to r298512 (!!! without
option CAM_NETFLIX_IOSCHED !!!) due to errors in recording the virtual
machine to a virtual disk I lost completely virtual machine with
permanent damage to the integrity of the file system in the inside of
the virtual machine.

This is a serious bug!

Who cares not to fall into the same situation - is testing yourself
and needed more testers.
Because there is a suspicion that the problem is also relevant for
bhyve VM.
With me on this no more neither the strength nor the desire nor
time.

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: New FreeBSD snapshots available: head (20160617 r301975)

[Ivan Klymenko]

On Sat, 18 Jun 2016 23:07:22 +
Glen Barber  wrote:

> On Sat, Jun 18, 2016 at 02:02:50PM +, Glen Barber wrote:
> > On Sat, Jun 18, 2016 at 10:12:07AM +0300, fidaj wrote:  
> > > === Installation ISOs ===
> > > 
> > > Installation images are available for:
> > > 
> > > o 11.0-ALPHA4 amd64 GENERIC
> > > o 11.0-ALPHA4 i386 GENERIC
> > > o 11.0-ALPHA4 powerpc GENERIC
> > > o 11.0-ALPHA4 powerpc64 GENERIC64
> > > o 11.0-ALPHA4 sparc64 GENERIC
> > > o 11.0-ALPHA4 armv6 BANANAPI
> > > o 11.0-ALPHA4 armv6 BEAGLEBONE
> > > o 11.0-ALPHA4 armv6 CUBIEBOARD
> > > o 11.0-ALPHA4 armv6 CUBIEBOARD2
> > > o 11.0-ALPHA4 armv6 CUBOX-HUMMINGBOARD
> > > o 11.0-ALPHA4 armv6 GUMSTIX
> > > o 11.0-ALPHA4 armv6 RPI-B
> > > o 11.0-ALPHA4 armv6 RPI2
> > > o 11.0-ALPHA4 armv6 PANDABOARD
> > > o 11.0-ALPHA4 armv6 WANDBOARD
> > > o 11.0-ALPHA4 aarch64 GENERIC
> > >  
> > > Hello. 
> > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/11.0-ALPHA4/
> > > not have manifest file. 
> > 
> > Huh.  Yep, this is a problem.
> > 
> > Thank you for the report.  I'll investigate what happened here.
> >   
> 
> This doesn't make sense.  The MANIFEST exists on the build machine,
> and should have been copied as result of the distribution to the
> mirrors.
> 
> I don't understand how it did not make it to the mirrors.
> 
> So I know, how did you discover this?
> 
> I *do* see the MANIFEST for amd64, so something very bizarre happened
> here.
> 
> Glen
> 

It breaks my poudriere.
poudriere jail -c -v 11.0-ALPHA4 -a i386 -j 11_ALPHA4_i386 -m
url=ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/11.0-ALPHA4/
___
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"

Fatal trap 12

[Ivan Klymenko]

Hello.
After update from r302000 to r302083 i have panic
http://i.imgur.com/YfvvhdS.png

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: Fatal trap 12

[Ivan Klymenko]

On Wed, 22 Jun 2016 20:36:36 +0300
Ivan Klymenko  wrote:

> Hello.
> After update from r302000 to r302083 i have panic
> http://i.imgur.com/YfvvhdS.png
> 
> Thanks.
Sorry, the first time discovered a revision  r302060.
___
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: Fatal trap 12

[Ivan Klymenko]

On Wed, 22 Jun 2016 20:45:26 +0300
Ivan Klymenko  wrote:

> On Wed, 22 Jun 2016 20:36:36 +0300
> Ivan Klymenko  wrote:
> 
> > Hello.
> > After update from r302000 to r302083 i have panic
> > http://i.imgur.com/YfvvhdS.png
> > 
> > Thanks.  
> Sorry, the first time discovered a revision  r302060.

There is a suspicion that the reason for this commit:
https://svnweb.freebsd.org/base?view=revision&revision=302054
___
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: Fatal trap 12

[Ivan Klymenko]

On Thu, 23 Jun 2016 10:54:46 +0200
Johan Hendriks  wrote:

> I have the following in my kernel config
> # pf
> options ALTQ
> options ALTQ_CBQ
> options ALTQ_RED
> options ALTQ_RIO
> options ALTQ_HFSC
> options ALTQ_CDNR
> options ALTQ_PRIQ
> device  pf
> device  pflog
> device  pfsync
> 
> I can not alter the order the modules load as far as I know.
> I changed the following in /usr/src/sys/netpfil/pf/if_pflog.c
> 
> from
> 
> DECLARE_MODULE(pflog, pflog_mod, SI_SUB_PSEUDO, SI_ORDER_ANY);
> 
> to
> 
> DECLARE_MODULE(pflog, pflog_mod, SI_SUB_PROTO_FIREWALL, SI_ORDER_ANY);
> 
> But after a buildworld the same error.
> 

+1

> Do you compile pflog into the kernel or load it from loader by any 
> chance?   I can see what might happen here.  

Yes, i have kernel options:
device  pf
device  pflog
device  pfsync
ALTQ...

> 
> Can you try to see if this goes away if you load pflog after pf is 
> loaded?   If that helps change the SI_SUB_PSEUDO at the end of 
> sys/netpfil/pf/if_pflog.c to SI_SUB_PROTO_FIREWALL ;  that should fix 

This does not solve the problem.
___
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: Fatal trap 12

[Ivan Klymenko]

On Thu, 23 Jun 2016 16:45:30 +
"Bjoern A. Zeeb"  wrote:

> Hi,
> 
> can you try checking out svn://svn.freebsd.org/base/projects/vnet and 
> see if a kernel from there works better?
> 
> It contains further pf/pflog/pfsync changes; mostly for VIMAGE which 
> will go into head the next days.
> 
> 
> Thanks
> 
> /bz

Update to r302164 - solved problem.
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: New FreeBSD snapshots available: head (20160701 r302303)

[Ivan Klymenko]

On Sat, 2 Jul 2016 06:19:58 +
Glen Barber  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> New FreeBSD development branch installation ISOs and virtual machine
> disk images have been uploaded to the FTP mirrors.
> 
> As with any development branch, the installation snapshots are not
> intended for use on production systems.  We do, however, encourage
> testing on non-production systems as much as possible.
> 
> Please also consider installing the sysutils/panicmail port, which can
> help in providing FreeBSD developers the necessary information
> regarding system crashes.
> 
> Checksums for the installation ISOs and the VM disk images follow at
> the end of this email.
> 

ivan@nonamehost:/ % ftp
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/11.0-ALPHA6 Trying
77.88.40.106:21 ... Connected to ftp.geo.freebsd.org.
220 This is ftp0.ydx.freebsd.org - hosted at Yandex.
331 Please specify the password.
230-
230-This is ftp0.ydx.FreeBSD.org, graciously hosted by Yandex.
230-
230-FreeBSD files can be found in the /pub/FreeBSD directory.
230-
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
200 Switching to Binary mode.
250 Directory successfully changed.
250-ISO images of FreeBSD releases may be found in the
releases/ISO-IMAGES 250-directory.  For independent files and tarballs,
see individual 250-releases/${machine}/${machine_arch} directories.
For example, 250-releases/amd64/amd64 and releases/powerpc/powerpc64.
250 Directory successfully changed.
250 Directory successfully changed.
250 Directory successfully changed.
local: 11.0-ALPHA6 remote: 11.0-ALPHA6
ftp: Can't access `11.0-ALPHA6': Permission denied
221 Goodbye.
___
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"

Increase the degree of interactivity ULE scheduler

[Ivan Klymenko]

Hello people!

I have:
CPU: Intel(R) Core(TM)2 Duo CPU T7250  @ 2.00GHz (1994.48-MHz K8-class CPU)
FreeBSD 10.0-CURRENT r226607 amd64

For example during the building of the port lang/gcc46 in four streams (-j 4) 
with a heavy load on the processor - use the system was nearly impossible - 
responsiveness was terrible - the mouse cursor sometimes froze on the spot a 
few seconds...

I managed to achieve a significant increase in the degree of interactivity ULE 
scheduler due to the following changes:
##
--- sched_ule.c.orig2011-10-22 11:40:30.0 +0300
+++ sched_ule.c 2011-10-22 12:25:05.0 +0300
@@ -2119,6 +2119,14 @@
 
THREAD_LOCK_ASSERT(td, MA_OWNED);
tdq = TDQ_SELF();
+   if (td->td_pri_class & PRI_FIFO_BIT)
+   return;
+   ts = td->td_sched;
+   /*
+* We used up one time slice.
+*/
+   if (--ts->ts_slice > 0)
+   return;
 #ifdef SMP
/*
 * We run the long term load balancer infrequently on the first cpu.
@@ -2144,9 +2152,6 @@
if (TAILQ_EMPTY(&tdq->tdq_timeshare.rq_queues[tdq->tdq_ridx]))
tdq->tdq_ridx = tdq->tdq_idx;
}
-   ts = td->td_sched;
-   if (td->td_pri_class & PRI_FIFO_BIT)
-   return;
if (PRI_BASE(td->td_pri_class) == PRI_TIMESHARE) {
/*
 * We used a tick; charge it to the thread so
@@ -2157,11 +2162,6 @@
sched_priority(td);
}
/*
-* We used up one time slice.
-*/
-   if (--ts->ts_slice > 0)
-   return;
-   /*
 * We're out of time, force a requeue at userret().
 */
ts->ts_slice = sched_slice;
##

What do you think about this?

Thanks!___
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: Increase the degree of interactivity ULE scheduler

[Ivan Klymenko]

Thank you for taking the time to answer me.

В Thu, 3 Nov 2011 10:21:48 -1000 (HST)
Jeff Roberson  пишет:

> On Sat, 22 Oct 2011, Ivan Klymenko wrote:
> 
> > Hello people!
> >
> > I have:
> > CPU: Intel(R) Core(TM)2 Duo CPU T7250  @ 2.00GHz (1994.48-MHz
> > K8-class CPU) FreeBSD 10.0-CURRENT r226607 amd64
> >
> > For example during the building of the port lang/gcc46 in four
> > streams (-j 4) with a heavy load on the processor - use the system
> > was nearly impossible - responsiveness was terrible - the mouse
> > cursor sometimes froze on the spot a few seconds...
> 
> Am I right in understanding that you have only two cores?

Yes.

> What else is running that achieves poor interactivity?

This is mainly a compilation with make option -j >= ncpu*2
And as an example - launching a large number of programs
http://www.youtube.com/watch?v=1CLCp-dqWu0
This patch allows me to make do with ULE nearly as well as with FBFS
Without the patch, somewhere in the middle of the time with ULE has
been difficult to control the mouse cursor.

> What is the cpu utilization of your x server at this time?

~2.00% - 20.00% WCPU time... But sometimes there are up to 79%...
Upon unloading the CPU returns to normal...

> 
> >
> > I managed to achieve a significant increase in the degree of
> > interactivity ULE scheduler due to the following changes:
> 
> This patch probably breaks nice, adaptive idling, and slows the 
> interactivity computation.  That being said I'm not sure why it helps
> you.
> 
> It seems that there are increasing reports of bad interactivity
> creeping in to ULE over the last year.  If people can help provide me
> with data I can look into this more.
> 

I'll be glad to provide data

> Thanks for your report.
> 
> Jeff

How to repeat your tests on my system?
http://jeffr-tech.livejournal.com/24280.html

Sorry for my english.

Thanks!
___
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: Increase the degree of interactivity ULE scheduler

[Ivan Klymenko]

В Thu, 3 Nov 2011 11:22:28 -1000 (HST)
Jeff Roberson  пишет:

> When the x server is down at 20% is it laggy?

In different ways, but basically - yes.
Sometimes appear in Xorg.0.log messages like:
"[mi] EQ overflowing. The server is probably stuck in an infinite loop."
When I run a lot of programs is beginning to actively use swap,
although i have 4G RAM on my system and if use 4BSD or FBFS this does
not happen...

> Can you tell me the priorities of the x server and the compile tasks?

cc1: PRI 74-86 (4 processes)
X: PRI 20-74 (mainly 74 at high load CPU) WCPU: 0.98%-6.98%

> You can use the 'pri' keyword with ps and write a short script to log
> all priorities once per second during your test.

Yes.
ps ax|grep X
 2786  -  S 3:31,13 /usr/local/bin/X :0 -br -verbose
-auth /var/run/gdm/auth-for-gdm-cqiXfH/database -nolisten tcp (Xorg)

I use script
#!/bin/sh

while [ 1 -lt 2 ]
do
#ps -p 2786 -uo pri >> pri_test.log
ps -p 2786 -o pri >> pri_test.log
sleep 1
done

log file pri_test.log as an attachment...

> That would be most helpful.
> Let me know if you need assistance with that.

Thanks!
___
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: Increase the degree of interactivity ULE scheduler

[Ivan Klymenko]

Maybe useful the following information:
This problem appears not to all architectures and types of CPU.
on the Russian forums
http://www.bsdportal.ru/viewtopic.php?t=24900
http://forum.lissyara.su/viewtopic.php?f=45&t=34641&sid=aa596f0b70806ba053011da911f9ccae
was a brute force to find out that:
there is a suspicion that:
- for AMD processors, this problem is not observed at all when the number of 
cores >= 2
- on all single-core is the problem
- only for some models with Intel >= 2 cores of the problem is not found

Perhaps, after all, avg@ rights (Subject: couple of sched_ule issues), that is 
not working
properly mechanism rebalancing and to determine the topology of CPU?
All converge, because my patch ( 
http://docs.freebsd.org/cgi/mid.cgi?20111022132817.35db5ccd )
for SMP systems just do respite for rebalancing, which eliminates the problem 
with interactivity ...

Thanks!
___
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: Increase the degree of interactivity ULE scheduler

[Ivan Klymenko]

В Sat, 05 Nov 2011 19:42:12 +0100
"O. Hartmann"  пишет:

> Am 11/04/11 14:33, schrieb Ivan Klymenko:
> > Maybe useful the following information:
> > This problem appears not to all architectures and types of CPU.
> > on the Russian forums
> > http://www.bsdportal.ru/viewtopic.php?t=24900
> > http://forum.lissyara.su/viewtopic.php?f=45&t=34641&sid=aa596f0b70806ba053011da911f9ccae
> > was a brute force to find out that:
> > there is a suspicion that:
> > - for AMD processors, this problem is not observed at all when the
> > number of cores >= 2
> > - on all single-core is the problem
> > - only for some models with Intel >= 2 cores of the problem is not
> > found
> > 
> > Perhaps, after all, avg@ rights (Subject: couple of sched_ule
> > issues), that is not working properly mechanism rebalancing and to
> > determine the topology of CPU? All converge, because my patch
> > ( http://docs.freebsd.org/cgi/mid.cgi?20111022132817.35db5ccd ) for
> > SMP systems just do respite for rebalancing, which eliminates the
> > problem with interactivity ...
> > 
> > Thanks!
> 
> Is the patch going to be merged into HEAD shortly?
> 
> Regards,
> Oliver
> 

I'm not sure... Most of all we must address the root causes of this
problem...
___
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: buildworld race?

[Ivan Klymenko]

В Tue, 22 Nov 2011 19:35:22 +0100
Andreas Tobler  пишет:

> Anyone seen this too?
> 
> make: don't know how to make 
> /usr/obj/export/devel/fbsd/src/tmp/usr/lib/libkrb5.a. Stop
> *** Error code 2
> 
> Happens on amd64 and powerpc64 while doing a make -j4 buildworld.
> Continuing with -DNO_CLEAN -j1 completes the build.
> 
> Thanks,
> Andreas

I see the same thing.
Now try to find what SVN revision it happened ...http://komitet-2012.com
___
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: buildworld race?

[Ivan Klymenko]

В Tue, 22 Nov 2011 21:20:10 +0200
Ivan Klymenko  пишет:

> В Tue, 22 Nov 2011 19:35:22 +0100
> Andreas Tobler  пишет:
> 
> > Anyone seen this too?
> > 
> > make: don't know how to make 
> > /usr/obj/export/devel/fbsd/src/tmp/usr/lib/libkrb5.a. Stop
> > *** Error code 2
> > 
> > Happens on amd64 and powerpc64 while doing a make -j4 buildworld.
> > Continuing with -DNO_CLEAN -j1 completes the build.
> > 
> > Thanks,
> > Andreas
> 
> I see the same thing.
> Now try to find what SVN revision it
> happened ...http://komitet-2012.com

Sorry for URL :(
___
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: buildworld race?

[Ivan Klymenko]

В Tue, 22 Nov 2011 19:35:22 +0100
Andreas Tobler  пишет:

> Anyone seen this too?
> 
> make: don't know how to make 
> /usr/obj/export/devel/fbsd/src/tmp/usr/lib/libkrb5.a. Stop
> *** Error code 2
> 
> Happens on amd64 and powerpc64 while doing a make -j4 buildworld.
> Continuing with -DNO_CLEAN -j1 completes the build.
> 
> Thanks,
> Andreas

Problem is solved in revision 227841
http://svn.freebsd.org/changeset/base/227841
___
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: SCHED_ULE should not be the default

[Ivan Klymenko]

В Mon, 12 Dec 2011 16:18:35 +
Bruce Cran  пишет:

> On 12/12/2011 15:51, Steve Kargl wrote:
> > This comes up every 9 months or so, and must be approaching FAQ 
> > status. In a HPC environment, I recommend 4BSD. Depending on the 
> > workload, ULE can cause a severe increase in turn around time when 
> > doing already long computations. If you have an MPI application, 
> > simply launching greater than ncpu+1 jobs can show the problem. PS: 
> > search the list archives for "kargl and ULE". 
> 
> This isn't something that can be fixed by tuning ULE? For example for 
> desktop applications kern.sched.preempt_thresh should be set to 224
> from its default. I'm wondering if the installer should ask people
> what the typical use will be, and tune the scheduler appropriately.
> 

This is by and large does not help in certain situations ...
___
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: SCHED_ULE should not be the default

[Ivan Klymenko]

> On 12/12/2011 05:47, O. Hartmann wrote:
> > Do we have any proof at hand for such cases where SCHED_ULE performs
> > much better than SCHED_4BSD?
> 
> I complained about poor interactive performance of ULE in a desktop
> environment for years. I had numerous people try to help, including
> Jeff, with various tunables, dtrace'ing, etc. The cause of the problem
> was never found.
> 
> I switched to 4BSD, problem gone.
> 
> This is on 2 separate systems with core 2 duos.
> 
> 
> hth,
> 
> Doug
> 

If the algorithm ULE does not contain problems - it means the problem
has Core2Duo, or in a piece of code that uses the ULE scheduler.
I already wrote in a mailing list that specifically in my case (Core2Duo)
partially helps the following patch:
--- sched_ule.c.orig2011-11-24 18:11:48.0 +0200
+++ sched_ule.c 2011-12-10 22:47:08.0 +0200
@@ -794,7 +794,8 @@
 * 1.5 * balance_interval.
 */
balance_ticks = max(balance_interval / 2, 1);
-   balance_ticks += random() % balance_interval;
+// balance_ticks += random() % balance_interval;
+   balance_ticks += ((int)random()) % balance_interval;
if (smp_started == 0 || rebalance == 0)
return;
tdq = TDQ_SELF();
@@ -2118,13 +2119,21 @@
struct td_sched *ts;
 
THREAD_LOCK_ASSERT(td, MA_OWNED);
+   if (td->td_pri_class & PRI_FIFO_BIT)
+   return;
+   ts = td->td_sched;
+   /*
+* We used up one time slice.
+*/
+   if (--ts->ts_slice > 0)
+   return;
tdq = TDQ_SELF();
 #ifdef SMP
/*
 * We run the long term load balancer infrequently on the first cpu.
 */
-   if (balance_tdq == tdq) {
-   if (balance_ticks && --balance_ticks == 0)
+   if (balance_ticks && --balance_ticks == 0) {
+   if (balance_tdq == tdq)
sched_balance();
}
 #endif
@@ -2144,9 +2153,6 @@
if (TAILQ_EMPTY(&tdq->tdq_timeshare.rq_queues[tdq->tdq_ridx]))
tdq->tdq_ridx = tdq->tdq_idx;
}
-   ts = td->td_sched;
-   if (td->td_pri_class & PRI_FIFO_BIT)
-   return;
if (PRI_BASE(td->td_pri_class) == PRI_TIMESHARE) {
/*
 * We used a tick; charge it to the thread so
@@ -2157,11 +2163,6 @@
sched_priority(td);
}
/*
-* We used up one time slice.
-*/
-   if (--ts->ts_slice > 0)
-   return;
-   /*
 * We're out of time, force a requeue at userret().
 */
ts->ts_slice = sched_slice;


and refusal to use options FULL_PREEMPTION
But no one has unsubscribed to my letter, my patch helps or not in the case of 
Core2Duo...
There is a suspicion that the problems stem from the sections of code 
associated with the SMP...
Maybe I'm in something wrong, but I want to help in solving this problem ...
___
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: SCHED_ULE should not be the default

[Ivan Klymenko]

В Wed, 14 Dec 2011 00:04:42 +0100
Jilles Tjoelker  пишет:

> On Tue, Dec 13, 2011 at 10:40:48AM +0200, Ivan Klymenko wrote:
> > If the algorithm ULE does not contain problems - it means the
> > problem has Core2Duo, or in a piece of code that uses the ULE
> > scheduler. I already wrote in a mailing list that specifically in
> > my case (Core2Duo) partially helps the following patch:
> > --- sched_ule.c.orig2011-11-24 18:11:48.0 +0200
> > +++ sched_ule.c 2011-12-10 22:47:08.0 +0200
> > @@ -794,7 +794,8 @@
> >  * 1.5 * balance_interval.
> >  */
> > balance_ticks = max(balance_interval / 2, 1);
> > -   balance_ticks += random() % balance_interval;
> > +// balance_ticks += random() % balance_interval;
> > +   balance_ticks += ((int)random()) % balance_interval;
> > if (smp_started == 0 || rebalance == 0)
> > return;
> > tdq = TDQ_SELF();
> 
> This avoids a 64-bit division on 64-bit platforms but seems to have no
> effect otherwise. Because this function is not called very often, the
> change seems unlikely to help.

Yes, this section does not apply to this problem :)
Just I posted the latest patch which i using now...

> 
> > @@ -2118,13 +2119,21 @@
> > struct td_sched *ts;
> >  
> > THREAD_LOCK_ASSERT(td, MA_OWNED);
> > +   if (td->td_pri_class & PRI_FIFO_BIT)
> > +   return;
> > +   ts = td->td_sched;
> > +   /*
> > +* We used up one time slice.
> > +*/
> > +   if (--ts->ts_slice > 0)
> > +   return;
> 
> This skips most of the periodic functionality (long term load
> balancer, saving switch count (?), insert index (?), interactivity
> score update for long running thread) if the thread is not going to
> be rescheduled right now.
> 
> It looks wrong but it is a data point if it helps your workload.

Yes, I did it for as long as possible to delay the execution of the code in 
section:
...
#ifdef SMP
/*
 * We run the long term load balancer infrequently on the first cpu.
 */
if (balance_tdq == tdq) {
if (balance_ticks && --balance_ticks == 0)
sched_balance();
}
#endif
...

> 
> > tdq = TDQ_SELF();
> >  #ifdef SMP
> > /*
> >  * We run the long term load balancer infrequently on the
> > first cpu. */
> > -   if (balance_tdq == tdq) {
> > -   if (balance_ticks && --balance_ticks == 0)
> > +   if (balance_ticks && --balance_ticks == 0) {
> > +   if (balance_tdq == tdq)
> > sched_balance();
> > }
> >  #endif
> 
> The main effect of this appears to be to disable the long term load
> balancer completely after some time. At some point, a CPU other than
> the first CPU (which uses balance_tdq) will set balance_ticks = 0, and
> sched_balance() will never be called again.
> 

That is, for the same reason as above in the text...

> It also introduces a hypothetical race condition because the access to
> balance_ticks is no longer restricted to one CPU under a spinlock.
> 
> If the long term load balancer may be causing trouble, try setting
> kern.sched.balance_interval to a higher value with unpatched code.

I checked it in the first place - but it did not help fix the situation...

The impression of malfunction rebalancing...
It seems that the thread is passed on to the same core that is loaded and so...
Perhaps this is a consequence of an incorrect definition of the topology CPU?

> 
> > @@ -2144,9 +2153,6 @@
> > if
> > (TAILQ_EMPTY(&tdq->tdq_timeshare.rq_queues[tdq->tdq_ridx]))
> > tdq->tdq_ridx = tdq->tdq_idx; }
> > -   ts = td->td_sched;
> > -   if (td->td_pri_class & PRI_FIFO_BIT)
> > -   return;
> > if (PRI_BASE(td->td_pri_class) == PRI_TIMESHARE) {
> > /*
> >  * We used a tick; charge it to the thread so
> > @@ -2157,11 +2163,6 @@
> > sched_priority(td);
> > }
> > /*
> > -* We used up one time slice.
> > -*/
> > -   if (--ts->ts_slice > 0)
> > -   return;
> > -   /*
> >  * We're out of time, force a requeue at userret().
> >  */
> > ts->ts_slice = sched_slice;
> 
> > and refusal to use options FULL_PREEMPTION
> > But no one has unsubscribed to my letter, my patch helps or not in
> > the case of Core2Duo...
> > There is a suspicion that the problems stem from the sections of
> > code associated with the SMP...
> > Maybe I'm in something wrong, but I want to help in solving this
> > problem ...
> 
___
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: SCHED_ULE should not be the default

[Ivan Klymenko]

В Tue, 13 Dec 2011 23:02:15 +
Marcus Reid  пишет:

> On Mon, Dec 12, 2011 at 04:29:14PM -0800, Doug Barton wrote:
> > On 12/12/2011 05:47, O. Hartmann wrote:
> > > Do we have any proof at hand for such cases where SCHED_ULE
> > > performs much better than SCHED_4BSD?
> > 
> > I complained about poor interactive performance of ULE in a desktop
> > environment for years. I had numerous people try to help, including
> > Jeff, with various tunables, dtrace'ing, etc. The cause of the
> > problem was never found.
> 
> The issues that I've seen with ULE on the desktop seem to be caused
> by X taking up a steady amount of CPU, and being demoted from being an
> "interactive" process.  X then becomes the bottleneck for other
> processes that would otherwise be "interactive".  Try 'renice -20
> ' and see if that makes your problems go away.

Why, then X is not a bottleneck when using 4BSD?

> Marcus
___
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: SCHED_ULE should not be the default

[Ivan Klymenko]

В Tue, 13 Dec 2011 16:01:56 -0800
m...@freebsd.org пишет:

> On Tue, Dec 13, 2011 at 3:39 PM, Ivan Klymenko  wrote:
> > В Wed, 14 Dec 2011 00:04:42 +0100
> > Jilles Tjoelker  пишет:
> >
> >> On Tue, Dec 13, 2011 at 10:40:48AM +0200, Ivan Klymenko wrote:
> >> > If the algorithm ULE does not contain problems - it means the
> >> > problem has Core2Duo, or in a piece of code that uses the ULE
> >> > scheduler. I already wrote in a mailing list that specifically in
> >> > my case (Core2Duo) partially helps the following patch:
> >> > --- sched_ule.c.orig        2011-11-24 18:11:48.0 +0200
> >> > +++ sched_ule.c     2011-12-10 22:47:08.0 +0200
> >> > @@ -794,7 +794,8 @@
> >> >      * 1.5 * balance_interval.
> >> >      */
> >> >     balance_ticks = max(balance_interval / 2, 1);
> >> > -   balance_ticks += random() % balance_interval;
> >> > +// balance_ticks += random() % balance_interval;
> >> > +   balance_ticks += ((int)random()) % balance_interval;
> >> >     if (smp_started == 0 || rebalance == 0)
> >> >             return;
> >> >     tdq = TDQ_SELF();
> >>
> >> This avoids a 64-bit division on 64-bit platforms but seems to
> >> have no effect otherwise. Because this function is not called very
> >> often, the change seems unlikely to help.
> >
> > Yes, this section does not apply to this problem :)
> > Just I posted the latest patch which i using now...
> >
> >>
> >> > @@ -2118,13 +2119,21 @@
> >> >     struct td_sched *ts;
> >> >
> >> >     THREAD_LOCK_ASSERT(td, MA_OWNED);
> >> > +   if (td->td_pri_class & PRI_FIFO_BIT)
> >> > +           return;
> >> > +   ts = td->td_sched;
> >> > +   /*
> >> > +    * We used up one time slice.
> >> > +    */
> >> > +   if (--ts->ts_slice > 0)
> >> > +           return;
> >>
> >> This skips most of the periodic functionality (long term load
> >> balancer, saving switch count (?), insert index (?), interactivity
> >> score update for long running thread) if the thread is not going to
> >> be rescheduled right now.
> >>
> >> It looks wrong but it is a data point if it helps your workload.
> >
> > Yes, I did it for as long as possible to delay the execution of the
> > code in section: ...
> > #ifdef SMP
> >        /*
> >         * We run the long term load balancer infrequently on the
> > first cpu. */
> >        if (balance_tdq == tdq) {
> >                if (balance_ticks && --balance_ticks == 0)
> >                        sched_balance();
> >        }
> > #endif
> > ...
> >
> >>
> >> >     tdq = TDQ_SELF();
> >> >  #ifdef SMP
> >> >     /*
> >> >      * We run the long term load balancer infrequently on the
> >> > first cpu. */
> >> > -   if (balance_tdq == tdq) {
> >> > -           if (balance_ticks && --balance_ticks == 0)
> >> > +   if (balance_ticks && --balance_ticks == 0) {
> >> > +           if (balance_tdq == tdq)
> >> >                     sched_balance();
> >> >     }
> >> >  #endif
> >>
> >> The main effect of this appears to be to disable the long term load
> >> balancer completely after some time. At some point, a CPU other
> >> than the first CPU (which uses balance_tdq) will set balance_ticks
> >> = 0, and sched_balance() will never be called again.
> >>
> >
> > That is, for the same reason as above in the text...
> >
> >> It also introduces a hypothetical race condition because the
> >> access to balance_ticks is no longer restricted to one CPU under a
> >> spinlock.
> >>
> >> If the long term load balancer may be causing trouble, try setting
> >> kern.sched.balance_interval to a higher value with unpatched code.
> >
> > I checked it in the first place - but it did not help fix the
> > situation...
> >
> > The impression of malfunction rebalancing...
> > It seems that the thread is passed on to the same core that is
> > loaded and so... Perhaps this is a consequence of an incorrect
> > definition of the topology CPU?
> >
> >>
> >> > @@ -2144,9 +2153,6 @@
> >> >             if
> >> > (TAILQ_EMPTY(&tdq->tdq_timeshare.rq_queues[tdq->tdq_ridx]))
&

Re: SCHED_ULE should not be the default

[Ivan Klymenko]

В Wed, 14 Dec 2011 21:34:35 +0400
Andrey Chernov  пишет:

> On Tue, Dec 13, 2011 at 02:22:48AM -0800, Adrian Chadd wrote:
> > On 13 December 2011 01:00, Andrey Chernov  wrote:
> > 
> > >> If the algorithm ULE does not contain problems - it means the
> > >> problem has Core2Duo, or in a piece of code that uses the ULE
> > >> scheduler.
> > >
> > > I observe ULE interactivity slowness even on single core machine
> > > (Pentium 4) in very visible places, like 'ps ax' output stucks in
> > > the middle by ~1 second. When I switch back to SHED_4BSD, all
> > > slowness is gone.
> > 
> > Are you able to provide KTR traces of the scheduler results?
> > Something that can be fed to schedgraph?
> 
> Sorry, this machine is not mine anymore. I try SCHED_ULE on Core 2
> Duo instead and don't notice this effect, but it is overall pretty
> fast comparing to that Pentium 4.
> 

Give me, please, detailed instructions on how to do it - I'll do it ...
Be a shame if this the theme is will end again just only the
discussions ...  :(
___
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: SCHED_ULE should not be the default

[Ivan Klymenko]

В Thu, 15 Dec 2011 20:02:44 +0100
Attilio Rao  пишет:

> 2011/12/15 Jeremy Chadwick :
> > On Thu, Dec 15, 2011 at 05:26:27PM +0100, Attilio Rao wrote:
> >> 2011/12/13 Jeremy Chadwick :
> >> > On Mon, Dec 12, 2011 at 02:47:57PM +0100, O. Hartmann wrote:
> >> >> > Not fully right, boinc defaults to run on idprio 31 so this
> >> >> > isn't an issue. And yes, there are cases where SCHED_ULE
> >> >> > shows much better performance then SCHED_4BSD. ??[...]
> >> >>
> >> >> Do we have any proof at hand for such cases where SCHED_ULE
> >> >> performs much better than SCHED_4BSD? Whenever the subject
> >> >> comes up, it is mentioned, that SCHED_ULE has better
> >> >> performance on boxes with a ncpu > 2. But in the end I see here
> >> >> contradictionary statements. People complain about poor
> >> >> performance (especially in scientific environments), and other
> >> >> give contra not being the case.
> >> >>
> >> >> Within our department, we developed a highly scalable code for
> >> >> planetary science purposes on imagery. It utilizes present GPUs
> >> >> via OpenCL if present. Otherwise it grabs as many cores as it
> >> >> can. By the end of this year I'll get a new desktop box based
> >> >> on Intels new Sandy Bridge-E architecture with plenty of
> >> >> memory. If the colleague who developed the code is willing
> >> >> performing some benchmarks on the same hardware platform, we'll
> >> >> benchmark bot FreeBSD 9.0/10.0 and the most recent Suse. For
> >> >> FreeBSD I intent also to look for performance with both
> >> >> different schedulers available.
> >> >
> >> > This is in no way shape or form the same kind of benchmark as
> >> > what you're planning to do, but I thought I'd throw it out there
> >> > for folks to take in as they see fit.
> >> >
> >> > I know folks were focused mainly on buildworld.
> >> >
> >> > I personally would find it interesting if someone with a
> >> > higher-end system (e.g. 2 physical CPUs, with 6 or 8 cores per
> >> > CPU) was to do the same test (changing -jX to -j{numofcores} of
> >> > course).
> >> >
> >> > --
> >> > | Jeremy
> >> > Chadwick ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??jdc at
> >> > parodius.com | | Parodius
> >> > Networking ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
> >> > http://www.parodius.com/ | | UNIX Systems
> >> > Administrator ?? ?? ?? ?? ?? ?? ?? ?? ?? Mountain View, CA, US |
> >> > | Making life hard for others since 1977. ?? ?? ?? ?? ?? ?? ??
> >> > PGP 4BD6C0CB |
> >> >
> >> >
> >> > sched_ule
> >> > ===
> >> > - time make -j2 buildworld
> >> > ??1689.831u 229.328s 18:46.20 170.4% 6566+2051k 432+4264io
> >> > 4565pf+0w
> >> > - time make -j2 buildkernel
> >> > ??640.542u 87.737s 9:01.38 134.5% 6490+1920k 134+5968io 0pf+0w
> >> >
> >> >
> >> > sched_4bsd
> >> > 
> >> > - time make -j2 buildworld
> >> > ??1662.793u 206.908s 17:12.02 181.1% 6578+2054k 23750+4271io
> >> > 6451pf+0w
> >> > - time make -j2 buildkernel
> >> > ??638.717u 76.146s 8:34.90 138.8% 6530+1927k 6415+5903io 0pf+0w
> >> >
> >> >
> >> > software
> >> > ==
> >> > * sched_ule test: ??FreeBSD 8.2-STABLE, Thu Dec ??1 04:37:29 PST
> >> > 2011
> >> > * sched_4bsd test: FreeBSD 8.2-STABLE, Mon Dec 12 22:42:54 PST
> >> > 2011
> >>
> >> Hi Jeremy,
> >> thanks for the time you spent on this.
> >>
> >> However, I wanted to ask/let you note 3 things:
> >> 1) Did you use 2 different code base for the test? (one updated on
> >> December 1 and another one on December 12)
> >
> > No; src-all (/usr/src on this system) was not updated between
> > December 1st and December 12th PST.  I do believe I updated it
> > today (15th PST). I can/will obviously hold off so that we have a
> > consistent code base for comparing numbers between schedulers
> > during buildworld and/or buildkernel.
> >
> >> 2) Please note that you should have repeated this test several
> >> times (basically until you don't get a standard deviation which is
> >> acceptable with ministat) and report the ministat output
> >
> > This is the first time I have heard of ministat(1).  I'm pretty
> > sure I see what it's for and how it applies to this situation, but
> > boy that man page could use some clarification (I have 3 people
> > looking at this thing right now trying to figure out what means
> > what in the graph :-) ). Anyway, graph or not, I see the point.
> >
> > Regarding multiple tests: yup, you're absolutely right, the only
> > way to do it would be to run a sequence of tests repeatedly
> > (probably 10 per scheduler).  Reboots and rm -fr /usr/obj/* would
> > be required after each test too, to guarantee empty kernel caches
> > (of all types) consistently every time.
> >
> > What I posted was supposed to give people just a "general idea" if
> > there was any gigantic difference between the two, and there really
> > isn't. But, as others have stated (and you below), buildworld may
> > not be an effective way to "benchmark" what we're trying to test.
> >
> > Hence me wondering exactly what would make for a goo

Re: scheduler panic

[Ivan Klymenko]

В Fri, 23 Dec 2011 07:21:41 -0600
Larry Rosenman  пишет:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> I've been getting these in a VirtualBox VM.  I'm not sure what to do.
> 
> I CAN give VNC access to this VM in this state.
> 
> panic: sched_priority: invalid priority 331: nice 0, ticks 56612596
> ftick 1213618 itick 1214628 tick pri 159
> cpuid = 0
> KDB: enter: panic
> 
> Ideas?
> (repost without the screenshot).

uname -a ???
___
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: scheduler panic

[Ivan Klymenko]

В Fri, 23 Dec 2011 07:38:21 -0600
Larry Rosenman  пишет:

> BORG-DTRACE
Show, please, the kernel config BORG-DTRACE
___
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: softdep: out of journaling space for softdep!

[Ivan Klymenko]

В Fri, 09 Nov 2012 09:04:43 +0100
"O. Hartmann"  пишет:

> I just received since two days from now on one of my FreeBSD 10-CUR
> boxes a kernel message after syncing disks, just the moment when the
> system is supposed to switch off or reboot, like
> 
> softdep: out of journaling space for softdep
> 
> or something similar. I checked the /var/log for more details, but
> nothing has been logged there so far regarding this subject.
> 
> The box in question has buildworld and kernel most recent as
> 
> FreeBSD 10.0-CURRENT #0 r242747M: Thu Nov  8 10:40:09 CET 2012 amd64
> 
> The system is CLANG compiled, as it is now the standard and with
> 
> CXXFLAGS+=  -stdlib=libc++ -std=c++11
> 
> The box has its root filesystem on a SAMSUNG 830 SSD with a capacity
> of 120 GB, GPT partitions, UFS2 formated.
> 
> The box is the only one of a bunch of other FBSD 10 boxes with the
> very same software revision and a similar setup, but with traditional
> harddrives.
> 
> I can not reboot the box, the box is spinning with the above mentioned
> error message forever (did so for day on the unattended box).
> 
> A 'hard' reboot is quit with a kernel dump due to "sleeping thread".
> 
> Regards,
> 
> Oliver
> 

http://svnweb.freebsd.org/changeset/base/242815
___
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: Mesa 8.0 Info

[Ivan Klymenko]

В Mon, 13 Feb 2012 00:34:36 -0800
vehemens  пишет:

> 

Well, of course! Haiku is much more meaningful project than FreeBSD!
___
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: Mesa 8.0 Info

[Ivan Klymenko]

В Mon, 13 Feb 2012 19:02:30 +0100
"O. Hartmann"  пишет:

> On 02/13/12 09:34, vehemens wrote:
> 
> > 
> 
> 
> Interesting to read that FreeBSD has now explicitely been extracted
> from the description file :-(
> 

The impression that someone really wants to destroy FreeBSD...
___
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: Mesa 8.0 Info

[Ivan Klymenko]

В Mon, 13 Feb 2012 19:57:42 +0100
Niclas Zeising  пишет:

> On 2012-02-13 19:32, Kevin Oberman wrote:
> > On Mon, Feb 13, 2012 at 10:02 AM, O. Hartmann
> >  wrote:
> >> On 02/13/12 09:34, vehemens wrote:
> >>
> >>> 
> >>
> >>
> >> Interesting to read that FreeBSD has now explicitly been extracted
> >> from the description file :-(
> > 
> > Well, the section listing FreeBSD was totally removed, so all OSes
> > were explicitly removed and replaced with text describing APIs.
> > Since those are mostly orthogonal, I'd say that they simply removed
> > references to any specific OS with DRI support.
> 
> For those of you interested in trying out MESA 8.0 it is in the
> experimental xorg repository:
> http://trillian.chruetertee.ch/ports/browser
> It is however not part of the CFT miwi sent a week or so ago, since i
> was released after that.
> Feel free to try it out though, and report success/failiure.
> Regards!

Where did you see there is Mesa 8.0? Can you give my a direct link?

___
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: Mesa 8.0 Info

[Ivan Klymenko]

В Mon, 13 Feb 2012 19:57:42 +0100
Niclas Zeising  пишет:

> On 2012-02-13 19:32, Kevin Oberman wrote:
> > On Mon, Feb 13, 2012 at 10:02 AM, O. Hartmann
> >  wrote:
> >> On 02/13/12 09:34, vehemens wrote:
> >>
> >>> 
> >>
> >>
> >> Interesting to read that FreeBSD has now explicitly been extracted
> >> from the description file :-(
> > 
> > Well, the section listing FreeBSD was totally removed, so all OSes
> > were explicitly removed and replaced with text describing APIs.
> > Since those are mostly orthogonal, I'd say that they simply removed
> > references to any specific OS with DRI support.
> 
> For those of you interested in trying out MESA 8.0 it is in the
> experimental xorg repository:
> http://trillian.chruetertee.ch/ports/browser
> It is however not part of the CFT miwi sent a week or so ago, since i
> was released after that.
> Feel free to try it out though, and report success/failiure.
> Regards!

Sorry - had already seen, it is in the trunk :(
___
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"