Re: Getting value of MAKEOBJDIRPREFIX with 'make -V MAKEOBJDIRPREFIX'
From: Yasuhiro KIMURA Subject: Re: Getting value of MAKEOBJDIRPREFIX with 'make -V MAKEOBJDIRPREFIX' Date: Sat, 17 Nov 2018 09:18:53 +0900 (JST) > As far as I read this, behavior change of 'make -V MAKEOBJDIRPREFIX` > doesn't seem intentional. So I'll submit bug report. Submitted. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233265 --- Yasuhiro KIMURA ___ 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: Getting value of MAKEOBJDIRPREFIX with 'make -V MAKEOBJDIRPREFIX'
From: Yasuhiro KIMURA Subject: Getting value of MAKEOBJDIRPREFIX with 'make -V MAKEOBJDIRPREFIX' Date: Sat, 17 Nov 2018 01:57:58 +0900 (JST) > Then is this just bug? Or are there any reason that behavior is > changed from 11.x to 12.x and later? To find when behavior changed I bisected head from r302408 (revision that stable/11 is cleated) to r340439 and got following result. Order RevisionDoes 'make -V MAKEOBJDIRPREFIX` work? -- 1 302408 Yes 2 340439 No 3 323176 Yes 4 332305 No 5 327441 No 6 325415 No 7 324362 Yes 8 324940 Yes 9 325181 Yes 10 325295 No 11 325248 Yes 12 325271 Yes 13 325285 Yes 14 325290 No 15 325288 No 16 325287 Yes That is, behavior changed at r325288. And commit message says as following. -- Add option UNIFIED_OBJDIR, on by default, which moves the default build OBJDIR. This changes the build OBJDIR from the older style of /usr/obj/ for native builds, and /usr/obj/./ for cross builds to a new simpler format of /usr/obj//.. This new format is used regardless of cross or native build. It allows easier management of multiple source tree object directories. The UNIFIED_OBJDIR option will be removed and its feature made permanent for the 12.0 release. -- As far as I read this, behavior change of 'make -V MAKEOBJDIRPREFIX` doesn't seem intentional. So I'll submit bug report. --- Yasuhiro KIMURA ___ 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: axp288 on Intel HW
On Fri, Nov 16, 2018 at 5:11 PM John Baldwin wrote: > On 11/16/18 12:51 AM, Johannes Lundberg wrote: > > Hi > > > > I have a Lenovo Ideapad Miix 310 that has a Intel CherryTrail CPU and it > > runs FreeBSD quite nicely (with accelerated graphics). What I'm missing > is > > battery life status.. > > > > I can get this information using smb (for some reason i2c just returns > > error sending start condition) > > smbmsg -f /dev/smb6 -s 0x68 -c 0xB9 -i 1 -F %d > > > > In emergency this works but it would be nice to have a kernel driver for > > it. > > > > I found the axp2xx driver for Allwinner in the tree. Would it be possible > > to share this with amd64 with not too much effort? > > > > If not, all I'm really interested in is battery status so I might just > hack > > together a simple driver for that report values to hw.acpi.battery > (because > > I don't think there is a sysctl for battery info that aggregates > different > > sources?) > > > > Datasheet for the pmic can be found here > > http://download.bbs.ickey.cn/201707/cfe88ee7ef01eed7a4586ce340165da0.pdf > > Have you looked to see why ACPI isn't reporting battery status? Maybe we > need to be invoking some specific method like DSM or OSC before your > battery > devices work? Maybe your battery devices don't have a _STA method and you > need the change in > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191? > On Linux the axp288 driver is needed to make this happen so I haven't considered any other options. https://www.normalesup.org/~george/comp/linux_lenovo_miix3/#s_7_9 > -- > John Baldwin > > > > ___ 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: axp288 on Intel HW
On 11/16/18 12:51 AM, Johannes Lundberg wrote: > Hi > > I have a Lenovo Ideapad Miix 310 that has a Intel CherryTrail CPU and it > runs FreeBSD quite nicely (with accelerated graphics). What I'm missing is > battery life status.. > > I can get this information using smb (for some reason i2c just returns > error sending start condition) > smbmsg -f /dev/smb6 -s 0x68 -c 0xB9 -i 1 -F %d > > In emergency this works but it would be nice to have a kernel driver for > it. > > I found the axp2xx driver for Allwinner in the tree. Would it be possible > to share this with amd64 with not too much effort? > > If not, all I'm really interested in is battery status so I might just hack > together a simple driver for that report values to hw.acpi.battery (because > I don't think there is a sysctl for battery info that aggregates different > sources?) > > Datasheet for the pmic can be found here > http://download.bbs.ickey.cn/201707/cfe88ee7ef01eed7a4586ce340165da0.pdf Have you looked to see why ACPI isn't reporting battery status? Maybe we need to be invoking some specific method like DSM or OSC before your battery devices work? Maybe your battery devices don't have a _STA method and you need the change in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191? -- John Baldwin ___ 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"
Getting value of MAKEOBJDIRPREFIX with 'make -V MAKEOBJDIRPREFIX'
Hello, I'm writing shell script to build and install base system from source and -V option of make(1) is used in it to get value of MAKEOBJDIRPREFIX. By default it works fine with all of head, releng/11.2, releng/12.0, stable/11 and stable/12. yasu@eastasia[2389]% svn info /usr0/freebsd/base/head Path: /usr0/freebsd/base/head Working Copy Root Path: /usr0/freebsd/base/head URL: https://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 340474 Node Kind: directory Schedule: normal Last Changed Author: karels Last Changed Rev: 340474 Last Changed Date: 2018-11-16 12:42:29 +0900 (Fri, 16 Nov 2018) yasu@eastasia[2390]% make -V MAKEOBJDIRPREFIX -C /usr0/freebsd/base/head /usr/obj yasu@eastasia[2391]% svn info /usr0/freebsd/base/releng/11.2 Path: /usr0/freebsd/base/releng/11.2 Working Copy Root Path: /usr0/freebsd/base/releng/11.2 URL: https://svn.freebsd.org/base/releng/11.2 Relative URL: ^/releng/11.2 Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 338990 Node Kind: directory Schedule: normal Last Changed Author: gordon Last Changed Rev: 338981 Last Changed Date: 2018-09-28 03:36:30 +0900 (Fri, 28 Sep 2018) yasu@eastasia[2392]% make -V MAKEOBJDIRPREFIX -C /usr0/freebsd/base/releng/11.2 /usr/obj yasu@eastasia[2393]% svn info /usr0/freebsd/base/releng/12.0 Path: /usr0/freebsd/base/releng/12.0 Working Copy Root Path: /usr0/freebsd/base/releng/12.0 URL: https://svn.freebsd.org/base/releng/12.0 Relative URL: ^/releng/12.0 Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 340471 Node Kind: directory Schedule: normal Last Changed Author: gjb Last Changed Rev: 340470 Last Changed Date: 2018-11-16 09:00:59 +0900 (Fri, 16 Nov 2018) yasu@eastasia[2394]% make -C /usr0/freebsd/base/releng/12.0 -V MAKEOBJDIRPREFIX /usr/obj yasu@eastasia[2395]% svn info /usr0/freebsd/base/stable/11 Path: /usr0/freebsd/base/stable/11 Working Copy Root Path: /usr0/freebsd/base/stable/11 URL: https://svn.freebsd.org/base/stable/11 Relative URL: ^/stable/11 Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 340473 Node Kind: directory Schedule: normal Last Changed Author: ygy Last Changed Rev: 340449 Last Changed Date: 2018-11-15 17:43:17 +0900 (Thu, 15 Nov 2018) yasu@eastasia[2396]% make -V MAKEOBJDIRPREFIX -C /usr0/freebsd/base/stable/11 /usr/obj yasu@eastasia[2397]% svn info /usr0/freebsd/base/stable/12 Path: /usr0/freebsd/base/stable/12 Working Copy Root Path: /usr0/freebsd/base/stable/12 URL: https://svn.freebsd.org/base/stable/12 Relative URL: ^/stable/12 Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 340474 Node Kind: directory Schedule: normal Last Changed Author: gjb Last Changed Rev: 340471 Last Changed Date: 2018-11-16 09:03:31 +0900 (Fri, 16 Nov 2018) yasu@eastasia[2398]% make -V MAKEOBJDIRPREFIX -C /usr0/freebsd/base/stable/12 /usr/obj But if I customize value of MAKEOBJDIRPREFIX then it still works with releng/11.2 and stable/11 but doesn't with head, releng/12.0 and stable/12. yasu@eastasia[2399]% env MAKEOBJDIRPREFIX=/usr0/freebsd/base/ogj make -V MAKEOBJDIRPREFIX -C /usr0/freebsd/base/head yasu@eastasia[2400]% env MAKEOBJDIRPREFIX=/usr0/freebsd/base/ogj make -V MAKEOBJDIRPREFIX -C /usr0/freebsd/base/releng/11.2 /usr0/freebsd/base/ogj yasu@eastasia[2401]% env MAKEOBJDIRPREFIX=/usr0/freebsd/base/ogj make -V MAKEOBJDIRPREFIX -C /usr0/freebsd/base/releng/12.0 yasu@eastasia[2402]% env MAKEOBJDIRPREFIX=/usr0/freebsd/base/ogj make -V MAKEOBJDIRPREFIX -C /usr0/freebsd/base/stable/11 /usr0/freebsd/base/ogj yasu@eastasia[2403]% env MAKEOBJDIRPREFIX=/usr0/freebsd/base/ogj make -V MAKEOBJDIRPREFIX -C /usr0/freebsd/base/stable/12 yasu@eastasia[2404]% I used env(1) to customize but I got same results when I use src-env.conf. Then is this just bug? Or are there any reason that behavior is changed from 11.x to 12.x and later? Best Regards. --- Yasuhiro KIMURA ___ 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: Panic on kern_event.c
Le ven. 16 nov. 2018 à 16:42, Mark Johnston a écrit :
> On Fri, Nov 16, 2018 at 03:47:39PM +0100, Sylvain GALLIANO wrote:
> > Le jeu. 15 nov. 2018 à 23:10, Mark Johnston a écrit
> :
> >
> > > On Thu, Nov 08, 2018 at 05:05:03PM +0100, Sylvain GALLIANO wrote:
> > > > Hi,
> > > >
> > > > I replaced
> > > > << printf("XXX knote %p already in tailq status:%x kq_count:%d [%p
> %p]
> > > >
> > >
> %u\n",kn,kn->kn_status,kq->kq_count,kn->kn_tqe.tqe_next,kn->kn_tqe.tqe_prev,__LINE__);
> > > > by
> > > > >> panic("XXX knote %p already in tailq status:%x kq_count:%d [%p
> %p]
> > > >
> > >
> %u\n",kn,kn->kn_status,kq->kq_count,kn->kn_tqe.tqe_next,kn->kn_tqe.tqe_prev,__LINE__);
> > > >
> > > > Here is the stack during panic:
> > > > panic: XXX knote 0xf801e1c6ddc0 already in tailq status:1
> kq_count:2
> > > > [0 0xf8000957a978] 2671
> > > >
> > > Could you please give the following patch a try?
> > >
> > > If possible, could you also ktrace one of the active syslog-ng
> processes
> > > for some time, perhaps 15 seconds, and share the kdump? I have been
> > > trying to reproduce the problem without any luck.
> > >
> > Unfortunately patched kernel is not stable:
> > - some processes run at 100% CPU (STOP state) and cannot be killed
> > - sometime the system completely freeze (need a hard reboot)
> >
> > I cannot reproduce the issue as soon as syslog-ng is under ktrace (even
> > after 10GB of ktrace file)
> > When I stop ktrace, issue come back after few minutes.
>
> That's ok, I'd like to see part of the ktrace even if the problem
> doesn't occur; this bug appears to be a race condition, so it's not
> surprising that ktrace might hide it.
>
Lucky ktrace this time, issue occured 2 times:
Nov 16 16:13:29 solid kernel: XXX knote 0xf8003282fb40 already in
tailq status:1 kq_count:1 [0 0xf80032883138] 2671
Nov 16 16:14:39 solid kernel: XXX knote 0xf8003282f3c0 already in
tailq status:1 kq_count:1 [0 0xf80032883138] 2671
ktrace.out.xz located in:
https://drive.google.com/drive/folders/1MbqJQm12-KOYDbb4-9uNRTnAdsNqLaIP?usp=sharing
___
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: Panic on kern_event.c
On Fri, Nov 16, 2018 at 03:47:39PM +0100, Sylvain GALLIANO wrote:
> Le jeu. 15 nov. 2018 à 23:10, Mark Johnston a écrit :
>
> > On Thu, Nov 08, 2018 at 05:05:03PM +0100, Sylvain GALLIANO wrote:
> > > Hi,
> > >
> > > I replaced
> > > << printf("XXX knote %p already in tailq status:%x kq_count:%d [%p %p]
> > >
> > %u\n",kn,kn->kn_status,kq->kq_count,kn->kn_tqe.tqe_next,kn->kn_tqe.tqe_prev,__LINE__);
> > > by
> > > >> panic("XXX knote %p already in tailq status:%x kq_count:%d [%p %p]
> > >
> > %u\n",kn,kn->kn_status,kq->kq_count,kn->kn_tqe.tqe_next,kn->kn_tqe.tqe_prev,__LINE__);
> > >
> > > Here is the stack during panic:
> > > panic: XXX knote 0xf801e1c6ddc0 already in tailq status:1 kq_count:2
> > > [0 0xf8000957a978] 2671
> > >
> > Could you please give the following patch a try?
> >
> > If possible, could you also ktrace one of the active syslog-ng processes
> > for some time, perhaps 15 seconds, and share the kdump? I have been
> > trying to reproduce the problem without any luck.
> >
> Unfortunately patched kernel is not stable:
> - some processes run at 100% CPU (STOP state) and cannot be killed
> - sometime the system completely freeze (need a hard reboot)
>
> I cannot reproduce the issue as soon as syslog-ng is under ktrace (even
> after 10GB of ktrace file)
> When I stop ktrace, issue come back after few minutes.
That's ok, I'd like to see part of the ktrace even if the problem
doesn't occur; this bug appears to be a race condition, so it's not
surprising that ktrace might hide it.
___
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: Panic on kern_event.c
Le jeu. 15 nov. 2018 à 23:10, Mark Johnston a écrit :
> On Thu, Nov 08, 2018 at 05:05:03PM +0100, Sylvain GALLIANO wrote:
> > Hi,
> >
> > I replaced
> > << printf("XXX knote %p already in tailq status:%x kq_count:%d [%p %p]
> >
> %u\n",kn,kn->kn_status,kq->kq_count,kn->kn_tqe.tqe_next,kn->kn_tqe.tqe_prev,__LINE__);
> > by
> > >> panic("XXX knote %p already in tailq status:%x kq_count:%d [%p %p]
> >
> %u\n",kn,kn->kn_status,kq->kq_count,kn->kn_tqe.tqe_next,kn->kn_tqe.tqe_prev,__LINE__);
> >
> > Here is the stack during panic:
> > panic: XXX knote 0xf801e1c6ddc0 already in tailq status:1 kq_count:2
> > [0 0xf8000957a978] 2671
> >
> > cpuid = 0
> > time = 1541688832
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2c/frame
> > 0xfe0412258fd0
> > kdb_backtrace() at kdb_backtrace+0x53/frame 0xfe04122590a0
> > vpanic() at vpanic+0x277/frame 0xfe0412259170
> > doadump() at doadump/frame 0xfe04122591d0
> > knote_enqueue() at knote_enqueue+0xf2/frame 0xfe0412259210
> > kqueue_register() at kqueue_register+0xaed/frame 0xfe0412259340
> > kqueue_kevent() at kqueue_kevent+0x13c/frame 0xfe04122595b0
> > kern_kevent_fp() at kern_kevent_fp+0x66/frame 0xfe0412259610
> > kern_kevent() at kern_kevent+0x17f/frame 0xfe0412259700
> > kern_kevent_generic() at kern_kevent_generic+0xfe/frame
> 0xfe0412259780
> > sys_kevent() at sys_kevent+0xaa/frame 0xfe0412259810
> > syscallenter() at syscallenter+0x4e3/frame 0xfe04122598f0
> > amd64_syscall() at amd64_syscall+0x1b/frame 0xfe04122599b0
> > fast_syscall_common() at fast_syscall_common+0x101/frame
> 0xfe04122599b0
> > --- syscall (560, FreeBSD ELF64, sys_kevent), rip = 0x406e3bfa, rsp =
> > 0x7fffdf7e9db8, rbp = 0x7fffdf7e9e00 ---
> > KDB: enter: panic
> >
> >
> > you can get kernel.debug + vmcore at:
> >
> https://drive.google.com/drive/folders/1MbqJQm12-KOYDbb4-9uNRTnAdsNqLaIP?usp=sharing
>
> Could you please give the following patch a try?
>
> If possible, could you also ktrace one of the active syslog-ng processes
> for some time, perhaps 15 seconds, and share the kdump? I have been
> trying to reproduce the problem without any luck.
>
> diff --git a/sys/kern/kern_event.c b/sys/kern/kern_event.c
> index d9c670e29d60..9ef7c53361bf 100644
> --- a/sys/kern/kern_event.c
> +++ b/sys/kern/kern_event.c
> @@ -224,6 +224,7 @@ SYSCTL_UINT(_kern, OID_AUTO, kq_calloutmax, CTLFLAG_RW,
> #define KQ_LOCK(kq) do { \
> mtx_lock(&(kq)->kq_lock); \
> } while (0)
> +#defineKQ_LOCKPTR(kq) (&(kq)->kq_lock)
> #define KQ_FLUX_WAKEUP(kq) do {
> \
> if (((kq)->kq_state & KQ_FLUXWAIT) == KQ_FLUXWAIT) {\
> (kq)->kq_state &= ~KQ_FLUXWAIT; \
> @@ -687,8 +688,11 @@ filt_timerexpire(void *knx)
> struct kq_timer_cb_data *kc;
>
> kn = knx;
> + KQ_OWNED(kn->kn_kq);
> kn->kn_data++;
> - KNOTE_ACTIVATE(kn, 0); /* XXX - handle locking */
> +
> + if (!kn_in_flux(kn) || (kn->kn_status & KN_SCAN) != 0)
> + KNOTE_ACTIVATE(kn, 1);
>
> if ((kn->kn_flags & EV_ONESHOT) != 0)
> return;
> @@ -753,7 +757,7 @@ filt_timerattach(struct knote *kn)
> kn->kn_flags |= EV_CLEAR; /* automatically set */
> kn->kn_status &= ~KN_DETACHED; /* knlist_add clears it */
> kn->kn_ptr.p_v = kc = malloc(sizeof(*kc), M_KQUEUE, M_WAITOK);
> - callout_init(>c, 1);
> + callout_init_mtx(>c, KQ_LOCKPTR(kn->kn_kq), 0);
> filt_timerstart(kn, to);
>
> return (0);
> @@ -772,8 +776,10 @@ filt_timerstart(struct knote *kn, sbintime_t to)
> kc->next = to + sbinuptime();
> kc->to = to;
> }
> + KQ_LOCK(kn->kn_kq);
> callout_reset_sbt_on(>c, kc->next, 0, filt_timerexpire, kn,
> PCPU_GET(cpuid), C_ABSOLUTE);
> + KQ_UNLOCK(kn->kn_kq);
> }
>
> static void
> @@ -826,7 +832,6 @@ filt_timertouch(struct knote *kn, struct kevent *kev,
> u_long type)
> KQ_LOCK(kq);
> if (kn->kn_status & KN_QUEUED)
> knote_dequeue(kn);
> -
> kn->kn_status &= ~KN_ACTIVE;
> kn->kn_data = 0;
> KQ_UNLOCK(kq);
> @@ -1843,6 +1848,7 @@ kqueue_scan(struct kqueue *kq, int maxevents, struct
> kevent_copyops *k_ops,
> }
>
> TAILQ_INSERT_TAIL(>kq_head, marker, kn_tqe);
> + marker->kn_status |= KN_QUEUED;
> influx = 0;
> while (count) {
> KQ_OWNED(kq);
> @@ -1861,8 +1867,10 @@ kqueue_scan(struct kqueue *kq, int maxevents,
> struct kevent_copyops *k_ops,
> }
>
> TAILQ_REMOVE(>kq_head, kn, kn_tqe);
> + KASSERT((kn->kn_status & KN_QUEUED) != 0,
> +
axp288 on Intel HW
Hi I have a Lenovo Ideapad Miix 310 that has a Intel CherryTrail CPU and it runs FreeBSD quite nicely (with accelerated graphics). What I'm missing is battery life status.. I can get this information using smb (for some reason i2c just returns error sending start condition) smbmsg -f /dev/smb6 -s 0x68 -c 0xB9 -i 1 -F %d In emergency this works but it would be nice to have a kernel driver for it. I found the axp2xx driver for Allwinner in the tree. Would it be possible to share this with amd64 with not too much effort? If not, all I'm really interested in is battery status so I might just hack together a simple driver for that report values to hw.acpi.battery (because I don't think there is a sysctl for battery info that aggregates different sources?) Datasheet for the pmic can be found here http://download.bbs.ickey.cn/201707/cfe88ee7ef01eed7a4586ce340165da0.pdf Cheers ___ 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"
