Re: SM bus ioctls incorrect in FreeBSD 11
On Friday, October 14, 2016 05:50:40 PM Andriy Gapon wrote: > On 14/10/2016 00:39, Lewis Donzis wrote: > > After upgrading to FreeBSD 11.0 and changing source code to use the new > > version of “struct smbcmd”, some commands are not working as documented, > > specifically those that read data. > > > > As an example, SMB_READW is documented as returning the word read from the > > device in rdata.word. However, this doesn’t happen, I think because the > > ioctl request value is defined using _IOW(), so the kernel doesn’t copy the > > data it read back out. > > > > In prior versions, the structure had only a pointer to the data, and the > > smb.c code used copyout() to transfer the data back to userland. > > > > As a temporary work-around, we added code to set rbuf to point to rdata.word > > and rcount to two. > > Lewis, > > thank you for the report. This is a bug indeed and your analysis is correct. > Could you please open a bugzilla issue for the bug? > https://bugs.freebsd.org/bugzilla/ > > Looking at ports commit 385155 > https://svnweb.freebsd.org/ports/head/sysutils/xmbmon/files/patch-getMB-smb_ioctl.c?r1=385155&r2=385154&pathrev=385155 > I see that it also used the approach that you use as a workaround. > And that port commit is by Michael Gmelin who made the change to smb.h in > r281985 https://svnweb.freebsd.org/base?view=revision&revision=281985 > So, I am not sure if the documented approach was known to not work. > > The src change is described as "Expand SMBUS API ...", but in fact it also > _changed_ the existing ioctls. And both binary compatibility and programming > compatibility were broken because of how struct smbcmd was changed. > In FreeBSD we try to not do that without a very strong reason, but alas. > And, as you report, the change was not done entirely correctly. > > I see several possibilities now. > > Option 1. Change the documentation to reflect the actual behavior. > In this case data.rdata will remain unusable and unused. No interface > changes. > > Option 2. Redefine SMB_READB, SMB_READW and SMB_PCALL ioctls using _IOWR, so > that data.rdata could be returned from kernel. This seems like a proper fix, > but it is another binary level incompatibility. > > Option 3. Use a horrible hack to discover a userland address of smbcmd and > explicitly copyout to data.rdata. No interface incompatibilities, but it will > be a horrible hack. Besides, not sure how feasible it is. > > Option 4. Revert smb ioctl changes to what they used to be before r281985. > Personally, I would prefer this approach. But now that the new interface is > in > 11.0, it means another interface change just like Option 2. > > I would like to hear other developers' opinions about this situation. > > P.S. > Two changes that I want to do no matter which course of action we select are: > - revert SMB_MAXBLOCKSIZE to 32 > - remove SMB_TRANS as it does not map to anything defined by the SMBus > specification and it can not be implemented for most, if not all, > SMBus controllers During the review the assumption was that breaking the ABI wasn't great, but that we could always fix it by adding compat handlers for the old ioctl values. If those are needed then they need to be restored. If the new API is useful then it needs to be fixed which I think is option 2. I think it is new enough to just fix without support compat shims for the broken version of it. Unfortunately I don't know SMBus well enough to comment on your latter changes, so I will defer to your call on those. -- 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: asio and kqueue (2nd trye) (was: RE: (boost::)asio and kqueue problem)
Patch generally lgtm ... just 1 nit comment:
+ } else {
+ if (sbavail(&so->so_rcv) >= so->so_rcv.sb_lowat)
+ return 1;
+ }
Collapse the else and the block inside to just make it an `else if`
for less branching.
On Fri, Oct 14, 2016 at 5:03 AM, Konstantin Belousov
wrote:
> On Fri, Oct 14, 2016 at 09:21:52AM +, hartmut.bra...@dlr.de wrote:
> > Hi all,
> >
> > here is the 2nd try taking into account the comments I received. Since
> I'm not familiar with the locking in the sockets area I ask somebody with
> that knowledge to check it before I commit it.
>
> I have only style notes, the factual code changes in the patch look good
> to me.
>
> Index: uipc_socket.c
> ===
> --- uipc_socket.c (revision 307091)
> +++ uipc_socket.c (working copy)
> @@ -159,15 +159,9 @@
> static int filt_soread(struct knote *kn, long hint);
> static voidfilt_sowdetach(struct knote *kn);
> static int filt_sowrite(struct knote *kn, long hint);
> -static int filt_solisten(struct knote *kn, long hint);
> static int inline hhook_run_socket(struct socket *so, void *hctx, int32_t
> h_id);
> fo_kqfilter_t soo_kqfilter;
>
> -static struct filterops solisten_filtops = {
> - .f_isfd = 1,
> - .f_detach = filt_sordetach,
> - .f_event = filt_solisten,
> -};
> static struct filterops soread_filtops = {
> .f_isfd = 1,
> .f_detach = filt_sordetach,
> @@ -3075,10 +3069,7 @@
>
> switch (kn->kn_filter) {
> case EVFILT_READ:
> - if (so->so_options & SO_ACCEPTCONN)
> - kn->kn_fop = &solisten_filtops;
> - else
> - kn->kn_fop = &soread_filtops;
> + kn->kn_fop = &soread_filtops;
> sb = &so->so_rcv;
> break;
> case EVFILT_WRITE:
> @@ -3282,29 +3273,34 @@
> static int
> filt_soread(struct knote *kn, long hint)
> {
> - struct socket *so;
> + struct socket *so = kn->kn_fp->f_data;
> Style is against mixing declaration and initialization. Please keep the
> next removed line instead.
>
> - so = kn->kn_fp->f_data;
> This one.
>
> - SOCKBUF_LOCK_ASSERT(&so->so_rcv);
> + if (so->so_options & SO_ACCEPTCONN) {
> + kn->kn_data = so->so_qlen;
> + return (!TAILQ_EMPTY(&so->so_comp));
>
> - kn->kn_data = sbavail(&so->so_rcv) - so->so_rcv.sb_ctl;
> - if (so->so_rcv.sb_state & SBS_CANTRCVMORE) {
> - kn->kn_flags |= EV_EOF;
> - kn->kn_fflags = so->so_error;
> - return (1);
> - } else if (so->so_error)/* temporary udp error */
> - return (1);
> + } else {
> You do not need else {} block, 'then' branch ends with return(). If you
> remove else, you do not need additional indent for the old filt_soread()
> function' body.
>
> + SOCKBUF_LOCK_ASSERT(&so->so_rcv);
>
> - if (kn->kn_sfflags & NOTE_LOWAT) {
> - if (kn->kn_data >= kn->kn_sdata)
> - return 1;
> - } else {
> - if (sbavail(&so->so_rcv) >= so->so_rcv.sb_lowat)
> - return 1;
> + kn->kn_data = sbavail(&so->so_rcv) - so->so_rcv.sb_ctl;
> + if (so->so_rcv.sb_state & SBS_CANTRCVMORE) {
> + kn->kn_flags |= EV_EOF;
> + kn->kn_fflags = so->so_error;
> + return (1);
> + } else if (so->so_error)/* temporary udp error */
> + return (1);
> +
> + if (kn->kn_sfflags & NOTE_LOWAT) {
> + if (kn->kn_data >= kn->kn_sdata)
> + return 1;
> return (1);
> since you change the line anyway.
>
> + } else {
> + if (sbavail(&so->so_rcv) >= so->so_rcv.sb_lowat)
> + return 1;
> Same.
>
> + }
> +
> + /* This hook returning non-zero indicates an event, not
> error */
> + return (hhook_run_socket(so, NULL, HHOOK_FILT_SOREAD));
> }
> -
> - /* This hook returning non-zero indicates an event, not error */
> - return (hhook_run_socket(so, NULL, HHOOK_FILT_SOREAD));
> }
>
> static void
> @@ -3346,16 +3342,6 @@
> return (kn->kn_data >= so->so_snd.sb_lowat);
> }
>
> -/*ARGSUSED*/
> -static int
> -filt_solisten(struct knote *kn, long hint)
> -{
> - struct socket *so = kn->kn_fp->f_data;
> -
> - kn->kn_data = so->so_qlen;
> - return (!TAILQ_EMPTY(&so->so_comp));
> -}
> -
> int
> socheckuid(struct socket *so, uid_t uid)
> {
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any ma
Re: SM bus ioctls incorrect in FreeBSD 11
> On Oct 14, 2016, at 9:50 AM, Andriy Gapon wrote: > Could you please open a bugzilla issue for the bug? > https://bugs.freebsd.org/bugzilla/ Sure, will do. I was unsure of the effectiveness of that, because I filed a much more serious report about a different issue a couple of weeks ago and have seen no activity or even acknowledgement. > The src change is described as "Expand SMBUS API ...", but in fact it also > _changed_ the existing ioctls. And both binary compatibility and programming > compatibility were broken because of how struct smbcmd was changed. > In FreeBSD we try to not do that without a very strong reason, but alas. > And, as you report, the change was not done entirely correctly. I was also surprised, but it wasn’t really a big deal, and the new structure might be slightly easier to use. There have been other similar things in 11.0, like __mq_oshandle() disappearing, and more .so files needing to be added to our embedded system, so all things considered, it’s been reasonably smooth moving from 10.3 to 11.0. > I see several possibilities now. > > Option 1. Change the documentation to reflect the actual behavior. > In this case data.rdata will remain unusable and unused. No interface > changes. > > Option 2. Redefine SMB_READB, SMB_READW and SMB_PCALL ioctls using _IOWR, so > that data.rdata could be returned from kernel. This seems like a proper fix, > but it is another binary level incompatibility. > > Option 3. Use a horrible hack to discover a userland address of smbcmd and > explicitly copyout to data.rdata. No interface incompatibilities, but it will > be a horrible hack. Besides, not sure how feasible it is. > > Option 4. Revert smb ioctl changes to what they used to be before r281985. > Personally, I would prefer this approach. But now that the new interface is > in > 11.0, it means another interface change just like Option 2. > > I would like to hear other developers' opinions about this situation. Our opinion doesn’t count for much, but I like 2 or 4. Option 1 would essentially obviate the entire purpose of changing the structure. Option 2 basically finishes the job and makes it work properly. Option 3 is, as you say, unappealing. I have no problem with Option 4, obviously we can change our code back to the old way, but assuming there was a good reason for this change in the first place, Option 2 seems more logical. But whatever y’all decide is fine with us, we’ll just change code to match at the appropriate time. Thanks, lew ___ 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: SM bus ioctls incorrect in FreeBSD 11
On 14/10/2016 18:11, Michael Gmelin wrote: > For some history on these changes, please see also [1] and [2] (there > were a few discussions and the revision was bumped, I also tried to > get some attention, but not enough it seems). > > Given your recent changes to iicbus in HEAD, I think it would be best to > MFC those and go with Option 4 or, if that's to drastic, go with > Option 1. I am leaning towards this approach as well. > Thanks for cleaning after me. You asked for a discussion and reviews. I can not recall what I was doing at that time, but I completely ignored the development and for that I can only blame myself. > [1]https://lists.freebsd.org/pipermail/freebsd-arch/2015-March/016972.html > [2]https://lists.freebsd.org/pipermail/freebsd-arch/2015-May/017157.html I also agree that having a thin library on top of the ioctl would be a convenience. -- Andriy Gapon ___ 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: SM bus ioctls incorrect in FreeBSD 11
On Fri, 14 Oct 2016 17:50:40 +0300 Andriy Gapon wrote: > On 14/10/2016 00:39, Lewis Donzis wrote: > > After upgrading to FreeBSD 11.0 and changing source code to use the > > new version of “struct smbcmd”, some commands are not working as > > documented, specifically those that read data. > > > > As an example, SMB_READW is documented as returning the word read > > from the device in rdata.word. However, this doesn’t happen, I > > think because the ioctl request value is defined using _IOW(), so > > the kernel doesn’t copy the data it read back out. > > > > In prior versions, the structure had only a pointer to the data, > > and the smb.c code used copyout() to transfer the data back to > > userland. > > > > As a temporary work-around, we added code to set rbuf to point to > > rdata.word and rcount to two. > > Lewis, > > thank you for the report. This is a bug indeed and your analysis is > correct. Could you please open a bugzilla issue for the bug? > https://bugs.freebsd.org/bugzilla/ > > Looking at ports commit 385155 > https://svnweb.freebsd.org/ports/head/sysutils/xmbmon/files/patch-getMB-smb_ioctl.c?r1=385155&r2=385154&pathrev=385155 > I see that it also used the approach that you use as a workaround. > And that port commit is by Michael Gmelin who made the change to > smb.h in r281985 > https://svnweb.freebsd.org/base?view=revision&revision=281985 So, I > am not sure if the documented approach was known to not work. > > The src change is described as "Expand SMBUS API ...", but in fact it > also _changed_ the existing ioctls. And both binary compatibility > and programming compatibility were broken because of how struct > smbcmd was changed. In FreeBSD we try to not do that without a very > strong reason, but alas. And, as you report, the change was not done > entirely correctly. > > I see several possibilities now. > > Option 1. Change the documentation to reflect the actual behavior. > In this case data.rdata will remain unusable and unused. No > interface changes. > > Option 2. Redefine SMB_READB, SMB_READW and SMB_PCALL ioctls using > _IOWR, so that data.rdata could be returned from kernel. This seems > like a proper fix, but it is another binary level incompatibility. > > Option 3. Use a horrible hack to discover a userland address of > smbcmd and explicitly copyout to data.rdata. No interface > incompatibilities, but it will be a horrible hack. Besides, not sure > how feasible it is. > > Option 4. Revert smb ioctl changes to what they used to be before > r281985. Personally, I would prefer this approach. But now that the > new interface is in 11.0, it means another interface change just like > Option 2. > > I would like to hear other developers' opinions about this situation. > > P.S. > Two changes that I want to do no matter which course of action we > select are: > - revert SMB_MAXBLOCKSIZE to 32 > - remove SMB_TRANS as it does not map to anything defined by the SMBus > specification and it can not be implemented for most, if not all, > SMBus controllers > For some history on these changes, please see also [1] and [2] (there were a few discussions and the revision was bumped, I also tried to get some attention, but not enough it seems). Given your recent changes to iicbus in HEAD, I think it would be best to MFC those and go with Option 4 or, if that's to drastic, go with Option 1. Thanks for cleaning after me. - Michael [1]https://lists.freebsd.org/pipermail/freebsd-arch/2015-March/016972.html [2]https://lists.freebsd.org/pipermail/freebsd-arch/2015-May/017157.html -- Michael Gmelin ___ 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: SM bus ioctls incorrect in FreeBSD 11
On 14/10/2016 00:39, Lewis Donzis wrote: > After upgrading to FreeBSD 11.0 and changing source code to use the new > version of “struct smbcmd”, some commands are not working as documented, > specifically those that read data. > > As an example, SMB_READW is documented as returning the word read from the > device in rdata.word. However, this doesn’t happen, I think because the > ioctl request value is defined using _IOW(), so the kernel doesn’t copy the > data it read back out. > > In prior versions, the structure had only a pointer to the data, and the > smb.c code used copyout() to transfer the data back to userland. > > As a temporary work-around, we added code to set rbuf to point to rdata.word > and rcount to two. Lewis, thank you for the report. This is a bug indeed and your analysis is correct. Could you please open a bugzilla issue for the bug? https://bugs.freebsd.org/bugzilla/ Looking at ports commit 385155 https://svnweb.freebsd.org/ports/head/sysutils/xmbmon/files/patch-getMB-smb_ioctl.c?r1=385155&r2=385154&pathrev=385155 I see that it also used the approach that you use as a workaround. And that port commit is by Michael Gmelin who made the change to smb.h in r281985 https://svnweb.freebsd.org/base?view=revision&revision=281985 So, I am not sure if the documented approach was known to not work. The src change is described as "Expand SMBUS API ...", but in fact it also _changed_ the existing ioctls. And both binary compatibility and programming compatibility were broken because of how struct smbcmd was changed. In FreeBSD we try to not do that without a very strong reason, but alas. And, as you report, the change was not done entirely correctly. I see several possibilities now. Option 1. Change the documentation to reflect the actual behavior. In this case data.rdata will remain unusable and unused. No interface changes. Option 2. Redefine SMB_READB, SMB_READW and SMB_PCALL ioctls using _IOWR, so that data.rdata could be returned from kernel. This seems like a proper fix, but it is another binary level incompatibility. Option 3. Use a horrible hack to discover a userland address of smbcmd and explicitly copyout to data.rdata. No interface incompatibilities, but it will be a horrible hack. Besides, not sure how feasible it is. Option 4. Revert smb ioctl changes to what they used to be before r281985. Personally, I would prefer this approach. But now that the new interface is in 11.0, it means another interface change just like Option 2. I would like to hear other developers' opinions about this situation. P.S. Two changes that I want to do no matter which course of action we select are: - revert SMB_MAXBLOCKSIZE to 32 - remove SMB_TRANS as it does not map to anything defined by the SMBus specification and it can not be implemented for most, if not all, SMBus controllers -- Andriy Gapon ___ 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: asio and kqueue (2nd trye) (was: RE: (boost::)asio and kqueue problem)
On Fri, Oct 14, 2016 at 09:21:52AM +, hartmut.bra...@dlr.de wrote:
> Hi all,
>
> here is the 2nd try taking into account the comments I received. Since I'm
> not familiar with the locking in the sockets area I ask somebody with that
> knowledge to check it before I commit it.
I have only style notes, the factual code changes in the patch look good
to me.
Index: uipc_socket.c
===
--- uipc_socket.c (revision 307091)
+++ uipc_socket.c (working copy)
@@ -159,15 +159,9 @@
static int filt_soread(struct knote *kn, long hint);
static voidfilt_sowdetach(struct knote *kn);
static int filt_sowrite(struct knote *kn, long hint);
-static int filt_solisten(struct knote *kn, long hint);
static int inline hhook_run_socket(struct socket *so, void *hctx, int32_t
h_id);
fo_kqfilter_t soo_kqfilter;
-static struct filterops solisten_filtops = {
- .f_isfd = 1,
- .f_detach = filt_sordetach,
- .f_event = filt_solisten,
-};
static struct filterops soread_filtops = {
.f_isfd = 1,
.f_detach = filt_sordetach,
@@ -3075,10 +3069,7 @@
switch (kn->kn_filter) {
case EVFILT_READ:
- if (so->so_options & SO_ACCEPTCONN)
- kn->kn_fop = &solisten_filtops;
- else
- kn->kn_fop = &soread_filtops;
+ kn->kn_fop = &soread_filtops;
sb = &so->so_rcv;
break;
case EVFILT_WRITE:
@@ -3282,29 +3273,34 @@
static int
filt_soread(struct knote *kn, long hint)
{
- struct socket *so;
+ struct socket *so = kn->kn_fp->f_data;
Style is against mixing declaration and initialization. Please keep the
next removed line instead.
- so = kn->kn_fp->f_data;
This one.
- SOCKBUF_LOCK_ASSERT(&so->so_rcv);
+ if (so->so_options & SO_ACCEPTCONN) {
+ kn->kn_data = so->so_qlen;
+ return (!TAILQ_EMPTY(&so->so_comp));
- kn->kn_data = sbavail(&so->so_rcv) - so->so_rcv.sb_ctl;
- if (so->so_rcv.sb_state & SBS_CANTRCVMORE) {
- kn->kn_flags |= EV_EOF;
- kn->kn_fflags = so->so_error;
- return (1);
- } else if (so->so_error)/* temporary udp error */
- return (1);
+ } else {
You do not need else {} block, 'then' branch ends with return(). If you
remove else, you do not need additional indent for the old filt_soread()
function' body.
+ SOCKBUF_LOCK_ASSERT(&so->so_rcv);
- if (kn->kn_sfflags & NOTE_LOWAT) {
- if (kn->kn_data >= kn->kn_sdata)
- return 1;
- } else {
- if (sbavail(&so->so_rcv) >= so->so_rcv.sb_lowat)
- return 1;
+ kn->kn_data = sbavail(&so->so_rcv) - so->so_rcv.sb_ctl;
+ if (so->so_rcv.sb_state & SBS_CANTRCVMORE) {
+ kn->kn_flags |= EV_EOF;
+ kn->kn_fflags = so->so_error;
+ return (1);
+ } else if (so->so_error)/* temporary udp error */
+ return (1);
+
+ if (kn->kn_sfflags & NOTE_LOWAT) {
+ if (kn->kn_data >= kn->kn_sdata)
+ return 1;
return (1);
since you change the line anyway.
+ } else {
+ if (sbavail(&so->so_rcv) >= so->so_rcv.sb_lowat)
+ return 1;
Same.
+ }
+
+ /* This hook returning non-zero indicates an event, not error */
+ return (hhook_run_socket(so, NULL, HHOOK_FILT_SOREAD));
}
-
- /* This hook returning non-zero indicates an event, not error */
- return (hhook_run_socket(so, NULL, HHOOK_FILT_SOREAD));
}
static void
@@ -3346,16 +3342,6 @@
return (kn->kn_data >= so->so_snd.sb_lowat);
}
-/*ARGSUSED*/
-static int
-filt_solisten(struct knote *kn, long hint)
-{
- struct socket *so = kn->kn_fp->f_data;
-
- kn->kn_data = so->so_qlen;
- return (!TAILQ_EMPTY(&so->so_comp));
-}
-
int
socheckuid(struct socket *so, uid_t uid)
{
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: zfs crash on FreeBSD 10.3
On Fri, 14 Oct 2016 00:19-0700, Julian Elischer wrote: > I attempted to add a second partition to an existing FS pool in FreeBSD 10.3 > and the result was a crash.. > > is there anyone out there with a scratch system (10.3) (or two spare drives) > who can show me this working? > > Does it look familiar to anyone? > > The drive 'boot0' is being used as the root drive, but we are in single user > mode, so its' read-only at this stage. > > === cut-n-paste = > > [boot -s] > > [...] > > Trying to mount root from zfs:p8/image1 []... > Enter full pathname of shell or RETURN for /bin/sh: > PS1="# " > # > # > # ls /dev/gpt > boot0boot1 > # zpool attach -f p8 gpt/boot0 gpt/boot1 Do you really need to force zpool to attach the second partition? What happens if you omit the -f flag? > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address= 0x50 > fault code= supervisor read data, page not present > instruction pointer= 0x20:0x81717063 > stack pointer= 0x28:0xfe0169bfc640 > frame pointer= 0x28:0xfe0169bfc9a0 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process= 3 (txg_thread_enter) > trap number= 12 > Panic:Thought about setting the watchdog to 10 Minutes > panic: page fault > cpuid = 1 > > KDB: stack backtrace: > stack1 db_trace_self_wrapper+0x2a > kdb_backtrace+0x37 vpanic+0xf7 > panic+0x67 trap_fatal+0x264 > trap_pfault+0x1c2 > trap+0x38c > calltrap+0x8 > dsl_scan_sync+0x2f3 > spa_sync+0x328 > txg_sync_thread+0x140 > fork_exit+0x135 > fork_trampoline+0xe > > KDB: enter: panic > [ thread pid 3 tid 100328 ] > Stopped at kdb_enter+0x50: movq$0,0x6bd5cd(%rip) > db> reboot > > I will add that after this, every boot hits this problem. (same stack trace). > the box is effectively bricked > (or would be if it weren't just a bhyve image) -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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"
asio and kqueue (2nd trye) (was: RE: (boost::)asio and kqueue problem)
Hi all, here is the 2nd try taking into account the comments I received. Since I'm not familiar with the locking in the sockets area I ask somebody with that knowledge to check it before I commit it. Thanks, harti From: Scott Mitchell [mailto:scott.k.mit...@gmail.com] Sent: Friday, October 14, 2016 2:16 AM To: freebsd-current@freebsd.org Cc: sepher...@gmail.com; kostik...@gmail.com; Brandt, Hartmut; adrian.ch...@gmail.com Subject: (boost::)asio and kqueue problem I am not using boost but I have also encountered this unexpected behavior when calling listen after kevent. Is their any update on the approach to merge filt_soread and filt_solisten? FYI - MacOS does not have this unexpected behavior. Read events are not "missed" if the listen is done after the kevent EVFILT_READ change is registered. Thanks, -Scott asio_listen.diff Description: asio_listen.diff ___ 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"
CURRENT [r307305]: Crashing
Systems I updated to recent CURRENT start crashing spontaneously. recent crashing system is on 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r307305: Fri Oct 14 08:37:59 CEST 2016 other (no access since it is remote and not accessible until later the day) has been updated ~ 12 hours ago and it is alos rebooting/crashing without any warnings. Can be triggered on heavy load. Only system with r307263 and stable so far is an older two-socket XEON Core2Duao based machine, all crashing boxes have CPUs newer or equal than IvyBridge. Does anyone also see these crashes? I tried to compile a debug kernel on one host, but that's the remote machine I have access to later, it failed compiling the kernel - under load it crashed often. After ZFS scrubbing kickied in, it vanished from the net ;-/ kind regards, oh ___ 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: (boost::)asio and kqueue problem
I have a fix that works and is better and simpler than the previous and will try to put it together in the next few days. harti From: Scott Mitchell [mailto:scott.k.mit...@gmail.com] Sent: Friday, October 14, 2016 2:16 AM To: freebsd-current@freebsd.org Cc: sepher...@gmail.com; kostik...@gmail.com; Brandt, Hartmut; adrian.ch...@gmail.com Subject: (boost::)asio and kqueue problem I am not using boost but I have also encountered this unexpected behavior when calling listen after kevent. Is their any update on the approach to merge filt_soread and filt_solisten? FYI - MacOS does not have this unexpected behavior. Read events are not "missed" if the listen is done after the kevent EVFILT_READ change is registered. Thanks, -Scott ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
zfs crash on FreeBSD 10.3
I attempted to add a second partition to an existing FS pool in FreeBSD 10.3 and the result was a crash.. is there anyone out there with a scratch system (10.3) (or two spare drives) who can show me this working? Does it look familiar to anyone? The drive 'boot0' is being used as the root drive, but we are in single user mode, so its' read-only at this stage. === cut-n-paste = [boot -s] [...] Trying to mount root from zfs:p8/image1 []... Enter full pathname of shell or RETURN for /bin/sh: PS1="# " # # # ls /dev/gpt boot0boot1 # zpool attach -f p8 gpt/boot0 gpt/boot1 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address= 0x50 fault code= supervisor read data, page not present instruction pointer= 0x20:0x81717063 stack pointer= 0x28:0xfe0169bfc640 frame pointer= 0x28:0xfe0169bfc9a0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process= 3 (txg_thread_enter) trap number= 12 Panic:Thought about setting the watchdog to 10 Minutes panic: page fault cpuid = 1 KDB: stack backtrace: stack1 db_trace_self_wrapper+0x2a kdb_backtrace+0x37 vpanic+0xf7 panic+0x67 trap_fatal+0x264 trap_pfault+0x1c2 trap+0x38c calltrap+0x8 dsl_scan_sync+0x2f3 spa_sync+0x328 txg_sync_thread+0x140 fork_exit+0x135 fork_trampoline+0xe KDB: enter: panic [ thread pid 3 tid 100328 ] Stopped at kdb_enter+0x50: movq$0,0x6bd5cd(%rip) db> reboot I will add that after this, every boot hits this problem. (same stack trace). the box is effectively bricked (or would be if it weren't just a bhyve image) ___ 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"
