From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 21 10:38:16 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF804106570A for ; Mon, 21 Feb 2011 10:38:16 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 814E28FC15 for ; Mon, 21 Feb 2011 10:38:16 +0000 (UTC) Received: by qwj9 with SMTP id 9so4718968qwj.13 for ; Mon, 21 Feb 2011 02:38:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yylmVXixjrGZZak3cXSUIxlQ9Zq1WQqqrFLusV1jWco=; b=RqSGDgbQe4OvGDIJJTZj4rHvCd7DJ0onkGC58ta3TM1FFt5cHWlNMB+8yutKMQkVfA R92Feh0hqtvfixKjan3JXzjHd4uqF8L+vSXydnvUfaKrOcAp57T9fkYcNtABTwFIngJm yfplNSil3keSUHV/Burnw5afJHTPu7Kcv/Y+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=UitY+1MjYJsavaWaFGj4FMZZ6w68eWFr4k63XDN06iKDfCoKhMqlkOWulRxcGBC1NJ 2qT9bVkC33r7T55GEV9uVpgLax/a27XOOxjJJs5cOulH8OTLOUFLFUhHcNtnJiZeY4/k COtHpZT7kHF8M06LlJtLkzrM5VE7o7CThAD8s= MIME-Version: 1.0 Received: by 10.224.45.84 with SMTP id d20mr934719qaf.210.1298284695347; Mon, 21 Feb 2011 02:38:15 -0800 (PST) Received: by 10.224.2.83 with HTTP; Mon, 21 Feb 2011 02:38:15 -0800 (PST) In-Reply-To: <201102181609.39955.hselasky@c2i.net> References: <201102181609.39955.hselasky@c2i.net> Date: Mon, 21 Feb 2011 11:38:15 +0100 Message-ID: From: Svatopluk Kraus To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hans Petter Selasky Subject: Re: ichsmb - correct locking strategy? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 10:38:16 -0000 On Fri, Feb 18, 2011 at 4:09 PM, Hans Petter Selasky wro= te: > On Friday 18 February 2011 15:10:47 Svatopluk Kraus wrote: >> Hi, >> >> =A0 I try to figure out locking strategy in FreeBSD and found 'ichsmb' >> device. There is a mutex which protects smb bus (ichsmb device). For >> example in ichsmb_readw() in sys/dev/ichsmb/ichsmb.c, the mutex is >> locked and a command is written to bus, then unbounded (but with >> timeout) sleep is done (mutex is unlocked during sleep). After sleep a >> word is read from bus and the mutex is unlocked. >> >> =A0 1. If an use of the device IS NOT serialized by layers around then >> more calls to this function (or others) can be started or even done >> before the first one is finished. The mutex don't protect sms bus. >> >> =A0 2. If an use of the device IS serialized by layers around then the >> mutex is useless. >> >> =A0 Moreover, I don't mension interrupt routine which uses the mutex and >> smb bus too. >> >> =A0 Am I right? Or did I miss something? > > man sx ? > > struct sx ? > > --HPS > Thanks for your reply. It seems that everybody knows that ichsmb driver is not in good shape but nobody cares for ... Svata From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 21 16:46:51 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 686C3106566C for ; Mon, 21 Feb 2011 16:46:51 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id AD64D8FC1B for ; Mon, 21 Feb 2011 16:46:50 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA08313; Mon, 21 Feb 2011 18:29:17 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4D6292DD.8010704@freebsd.org> Date: Mon, 21 Feb 2011 18:29:17 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101213 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Steven Hartland References: <8332E9240ECA403480B48D21FA3A8694@multiplay.co.uk> In-Reply-To: <8332E9240ECA403480B48D21FA3A8694@multiplay.co.uk> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: machdep.hlt_cpus not safe with ULE? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 16:46:51 -0000 on 19/02/2011 14:36 Steven Hartland said the following: > I'm trying to debug a possibly failing CPU, so I thought it would > be easy just disable the cores using machdep.hlt_cpus and see if > we see the panic's we've been seeing. > > The problem is it seems ULE doesnt properly support machdep.hlt_cpus > and still schedules processes onto the halted cpus which obviously > causes problems. > > Can anyone confirm this behaviour? Yes, your observations are correct. Please also see: http://www.freebsd.org/cgi/query-pr.cgi?pr=145385 > Should machdep.hlt_cpus and I assume > the logical counterpart never be used with ULE? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 21 18:38:32 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60AA3106564A; Mon, 21 Feb 2011 18:38:32 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 6AAC08FC0C; Mon, 21 Feb 2011 18:38:31 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 80B681E00241; Mon, 21 Feb 2011 19:38:29 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id p1LIaCqp038253; Mon, 21 Feb 2011 19:36:12 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id p1LIaC8Y038252; Mon, 21 Feb 2011 19:36:12 +0100 (CET) (envelope-from nox) From: Juergen Lock Date: Mon, 21 Feb 2011 19:36:11 +0100 To: Kostik Belousov Message-ID: <20110221183611.GA38073@triton8.kn-bremen.de> References: <20110129201000.GA10774@triton8.kn-bremen.de> <20110129205105.GI2518@deviant.kiev.zoral.com.ua> <20110129235448.GA15788@triton8.kn-bremen.de> <20110218205542.GA45210@triton8.kn-bremen.de> <20110219175744.GH78089@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110219175744.GH78089@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Mon, 21 Feb 2011 18:42:52 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org, Juergen Lock Subject: Re: Can vm_mmap()/vm_map_remove() be called with giant held? (linuxolator dvb patches) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 18:38:32 -0000 On Sat, Feb 19, 2011 at 07:57:44PM +0200, Kostik Belousov wrote: > On Fri, Feb 18, 2011 at 09:55:42PM +0100, Juergen Lock wrote: > > I have finally got back to this and did the style and vm_map_remove() > > return value handling fixes, updated the patches in-place: > > > > http://people.freebsd.org/~nox/dvb/linux-dvb.patch > > > > (for head) > > > > http://people.freebsd.org/~nox/dvb/linux-dvb-8.patch > > > > (for 8.) > > > > On Sun, Jan 30, 2011 at 12:54:48AM +0100, Juergen Lock wrote: > > > On Sat, Jan 29, 2011 at 10:51:05PM +0200, Kostik Belousov wrote: > > > > On Sat, Jan 29, 2011 at 09:10:00PM +0100, Juergen Lock wrote: > > > > > Hi! > > > > > > > > > > I was kinda hoping to be able to post a correct patch in public but > > > > > getting an answer to ${Subject} seems to be more difficult than I > > > > > thought... :) So, does anyone here know? copyout_map() and > > > > You do not need Giant locked for vm_map* functions. > > > > > > > The question was more do I need to drop it first before calling them... > > > > > > > > copyout_unmap() are copied from ksyms_map() from sys/dev/ksyms/ksyms.c > > > > > - should there maybe be global versions instead of two static copies > > > > > each, and what would be good names? And giant is taken by linux_ioctl() > > > > Would you make a patch for this ? > > > > > > > Heh if you want me to... Where should they go and are my name choices ok? > > > > > I haven't done this yet so people can keep patching linux.ko in-place > > without having to build a new kernel too... > Separate build of linux.ko is not quite supported action. I would greatly > prefer to have the move of these two functions before the rest of the > patch comes in. Together with conversion of other users. > > I propose to put it into vm/vm_glue.c. > Ok, new patches are here: http://people.freebsd.org/~nox/dvb/linux-dvb-2nd.patch (for head, also copied below) http://people.freebsd.org/~nox/dvb/linux-dvb-2nd-8.patch (for 8.) > > > > > > > in the same source file before calling the parts I added. So here > > > > > comes the patch, it is to add support for dvb ioctls to the linuxolator > > > > > as discussed on -emulation earlier in this thread: > > > > > > > > > > http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-January/011575.html > > > > > > > > > > (patch also at: > > > > > > > > > > http://people.freebsd.org/~nox/dvb/linux-dvb.patch > > > > > > > > > > and a version for 8, which is what I tested with w_scan on dvb-s2 > > > > > and dvb-t, and Andrew Gallatin also tested it with SageTV: > > > > > > > > > > http://people.freebsd.org/~nox/dvb/linux-dvb-8.patch > > > > > > > > > > ) > > > > > > > > > > > > + /* > > > > > + * Map somewhere after heap in process memory. > > > > > + */ > > > > > + PROC_LOCK(td->td_proc); > > > > > + *addr = round_page((vm_offset_t)vms->vm_daddr + > > > > > + lim_max(td->td_proc, RLIMIT_DATA)); > > > > > + PROC_UNLOCK(td->td_proc); > > > > Are you sure that this is needed ? Why not leave the address selection > > > > to the VM ? > > > > > > > I don't know, maybe sys/dev/ksyms/ksyms.c has a reason? > > > > How would I leave the address selection to the VM? Just trying > > to initialize *addr to (vm_offset_t)NULL there caused the patch to > > stop working. > I believe you should do > *addr = 0; > vm_mmap(map, addr); vm_mmap() needs more args, but other than that thats basically what I tested, and it didn't work. Thanx, :) Juergen And here comes the patch for head: Index: src/sys/vm/vm_extern.h =================================================================== RCS file: /home/scvs/src/sys/vm/vm_extern.h,v retrieving revision 1.99 diff -u -p -r1.99 vm_extern.h --- src/sys/vm/vm_extern.h 27 Dec 2010 07:12:22 -0000 1.99 +++ src/sys/vm/vm_extern.h 20 Feb 2011 17:15:42 -0000 @@ -83,16 +79,16 @@ void vmspace_exitfree(struct proc *); void vnode_pager_setsize(struct vnode *, vm_ooffset_t); int vslock(void *, size_t); void vsunlock(void *, size_t); void vm_object_print(/* db_expr_t */ long, boolean_t, /* db_expr_t */ long, char *); int vm_fault_quick(caddr_t v, int prot); struct sf_buf *vm_imgact_map_page(vm_object_t object, vm_ooffset_t offset); void vm_imgact_unmap_page(struct sf_buf *sf); void vm_thread_dispose(struct thread *td); int vm_thread_new(struct thread *td, int pages); void vm_thread_swapin(struct thread *td); void vm_thread_swapout(struct thread *td); +int copyout_map(struct thread *td, vm_offset_t *addr, size_t sz); +int copyout_unmap(struct thread *td, vm_offset_t addr, size_t sz); #endif /* _KERNEL */ #endif /* !_VM_EXTERN_H_ */ Index: src/sys/vm/vm_glue.c =================================================================== RCS file: /home/scvs/src/sys/vm/vm_glue.c,v retrieving revision 1.248 diff -u -p -r1.248 vm_glue.c --- src/sys/vm/vm_glue.c 9 Jan 2011 12:50:44 -0000 1.248 +++ src/sys/vm/vm_glue.c 20 Feb 2011 17:23:48 -0000 @@ -81,6 +81,7 @@ __FBSDID("$FreeBSD: src/sys/vm/vm_glue.c #include #include #include +#include #include #include @@ -1064,3 +1101,51 @@ swapout(p) return (0); } #endif /* !NO_SWAPPING */ + +/* + * Map some anonymous memory in user space of size sz, rounded up to the page + * boundary. + */ +int +copyout_map(struct thread *td, vm_offset_t *addr, size_t sz) +{ + struct vmspace *vms; + int error; + vm_size_t size; + + vms = td->td_proc->p_vmspace; + + /* + * Map somewhere after heap in process memory. + */ + PROC_LOCK(td->td_proc); + *addr = round_page((vm_offset_t)vms->vm_daddr + + lim_max(td->td_proc, RLIMIT_DATA)); + PROC_UNLOCK(td->td_proc); + + /* Round size up to page boundary. */ + size = (vm_size_t)round_page(sz); + + error = vm_mmap(&vms->vm_map, addr, size, PROT_READ | PROT_WRITE, + VM_PROT_ALL, MAP_PRIVATE | MAP_ANON, OBJT_DEFAULT, NULL, 0); + + return (error); +} + +/* + * Unmap memory in user space. + */ +int +copyout_unmap(struct thread *td, vm_offset_t addr, size_t sz) +{ + int error; + vm_map_t map; + vm_size_t size; + + map = &td->td_proc->p_vmspace->vm_map; + size = (vm_size_t) round_page(sz); + + error = vm_map_remove(map, addr, addr + size); + + return (error); +} Index: src/sys/compat/linux/linux_ioctl.c =================================================================== RCS file: /home/scvs/src/sys/compat/linux/linux_ioctl.c,v retrieving revision 1.167 diff -u -p -r1.167 linux_ioctl.c --- src/sys/compat/linux/linux_ioctl.c 30 Dec 2010 02:18:04 -0000 1.167 +++ src/sys/compat/linux/linux_ioctl.c 21 Feb 2011 17:48:32 -0000 @@ -59,6 +59,14 @@ __FBSDID("$FreeBSD: src/sys/compat/linux #include #include #include +#include +#include +#include + +#include +#include +#include +#include #include #include @@ -83,6 +91,9 @@ __FBSDID("$FreeBSD: src/sys/compat/linux #include #include +#include +#include + CTASSERT(LINUX_IFNAMSIZ == IFNAMSIZ); static linux_ioctl_function_t linux_ioctl_cdrom; @@ -97,6 +108,7 @@ static linux_ioctl_function_t linux_ioct static linux_ioctl_function_t linux_ioctl_drm; static linux_ioctl_function_t linux_ioctl_sg; static linux_ioctl_function_t linux_ioctl_v4l; +static linux_ioctl_function_t linux_ioctl_dvb; static linux_ioctl_function_t linux_ioctl_special; static linux_ioctl_function_t linux_ioctl_fbsd_usb; @@ -124,6 +136,8 @@ static struct linux_ioctl_handler sg_han { linux_ioctl_sg, LINUX_IOCTL_SG_MIN, LINUX_IOCTL_SG_MAX }; static struct linux_ioctl_handler video_handler = { linux_ioctl_v4l, LINUX_IOCTL_VIDEO_MIN, LINUX_IOCTL_VIDEO_MAX }; +static struct linux_ioctl_handler dvb_handler = +{ linux_ioctl_dvb, LINUX_IOCTL_DVB_MIN, LINUX_IOCTL_DVB_MAX }; static struct linux_ioctl_handler fbsd_usb = { linux_ioctl_fbsd_usb, FBSD_LUSB_MIN, FBSD_LUSB_MAX }; @@ -139,6 +153,7 @@ DATA_SET(linux_ioctl_handler_set, privat DATA_SET(linux_ioctl_handler_set, drm_handler); DATA_SET(linux_ioctl_handler_set, sg_handler); DATA_SET(linux_ioctl_handler_set, video_handler); +DATA_SET(linux_ioctl_handler_set, dvb_handler); DATA_SET(linux_ioctl_handler_set, fbsd_usb); struct handler_element @@ -2988,6 +3003,207 @@ linux_ioctl_special(struct thread *td, s return (error); } +static int +linux_to_bsd_dtv_properties(struct l_dtv_properties *lvps, struct dtv_properties *vps) +{ + + vps->num = lvps->num; + vps->props = PTRIN(lvps->props); /* possible pointer size conversion */ + return (0); +} + +static int +linux_to_bsd_dtv_property(struct l_dtv_property *lvp, struct dtv_property *vp) +{ + + /* + * Everything until u.buffer.reserved2 is fixed size so + * just memcpy it. + */ + memcpy(vp, lvp, offsetof(struct l_dtv_property, u.buffer.reserved2)); + /* + * The pointer may be garbage since it's part of a union, + * currently no Linux code uses it so just set it to NULL. + */ + vp->u.buffer.reserved2 = NULL; + vp->result = lvp->result; + return (0); +} + +static int +bsd_to_linux_dtv_property(struct dtv_property *vp, struct l_dtv_property *lvp) +{ + + /* + * Everything until u.buffer.reserved2 is fixed size so + * just memcpy it. + */ + memcpy(lvp, vp, offsetof(struct l_dtv_property, u.buffer.reserved2)); + /* + * The pointer may be garbage since it's part of a union, + * currently no Linux code uses it so just set it to NULL. + */ + lvp->u.buffer.reserved2 = PTROUT(NULL); + lvp->result = vp->result; + return (0); +} + +static int +linux_ioctl_dvb(struct thread *td, struct linux_ioctl_args *args) +{ + struct file *fp; + int error, i; + struct l_dtv_properties l_vps; + struct dtv_properties vps; + struct l_dtv_property *l_vp, *l_p; + struct dtv_property *vp, *p; + size_t l_propsiz, propsiz; + vm_offset_t uvp; + + l_vp = NULL; + vp = NULL; + + switch (args->cmd & 0xffff) { + case LINUX_AUDIO_STOP: + case LINUX_AUDIO_PLAY: + case LINUX_AUDIO_PAUSE: + case LINUX_AUDIO_CONTINUE: + case LINUX_AUDIO_SELECT_SOURCE: + case LINUX_AUDIO_SET_MUTE: + case LINUX_AUDIO_SET_AV_SYNC: + case LINUX_AUDIO_SET_BYPASS_MODE: + case LINUX_AUDIO_CHANNEL_SELECT: + case LINUX_AUDIO_CLEAR_BUFFER: + case LINUX_AUDIO_SET_ID: + case LINUX_AUDIO_SET_STREAMTYPE: + case LINUX_AUDIO_SET_EXT_ID: + case LINUX_AUDIO_BILINGUAL_CHANNEL_SELECT: + case LINUX_DMX_START: + case LINUX_DMX_STOP: + case LINUX_DMX_SET_BUFFER_SIZE: + case LINUX_NET_REMOVE_IF: + case LINUX_FE_DISEQC_RESET_OVERLOAD: + case LINUX_FE_DISEQC_SEND_BURST: + case LINUX_FE_SET_TONE: + case LINUX_FE_SET_VOLTAGE: + case LINUX_FE_ENABLE_HIGH_LNB_VOLTAGE: + case LINUX_FE_DISHNETWORK_SEND_LEGACY_CMD: + case LINUX_FE_SET_FRONTEND_TUNE_MODE: + case LINUX_CA_RESET: + if ((args->cmd & IOC_DIRMASK) != LINUX_IOC_VOID) + return ENOIOCTL; + args->cmd = (args->cmd & 0xffff) | IOC_VOID; + break; + + case LINUX_DMX_REMOVE_PID: + /* overlaps with LINUX_NET_ADD_IF */ + if ((args->cmd & IOC_DIRMASK) == LINUX_IOC_INOUT) + goto net_add_if; + /* FALLTHRU */ + case LINUX_AUDIO_SET_MIXER: + case LINUX_AUDIO_SET_ATTRIBUTES: + case LINUX_AUDIO_SET_KARAOKE: + case LINUX_DMX_SET_FILTER: + case LINUX_DMX_SET_PES_FILTER: + case LINUX_DMX_SET_SOURCE: + case LINUX_DMX_ADD_PID: + case LINUX_FE_DISEQC_SEND_MASTER_CMD: + case LINUX_FE_SET_FRONTEND: + case LINUX_CA_SEND_MSG: + case LINUX_CA_SET_DESCR: + case LINUX_CA_SET_PID: + args->cmd = (args->cmd & ~IOC_DIRMASK) | IOC_IN; + break; + + case LINUX_AUDIO_GET_STATUS: + case LINUX_AUDIO_GET_CAPABILITIES: + case LINUX_AUDIO_GET_PTS: + case LINUX_DMX_GET_PES_PIDS: + case LINUX_DMX_GET_CAPS: + case LINUX_FE_GET_INFO: + case LINUX_FE_DISEQC_RECV_SLAVE_REPLY: + case LINUX_FE_READ_STATUS: + case LINUX_FE_READ_BER: + case LINUX_FE_READ_SIGNAL_STRENGTH: + case LINUX_FE_READ_SNR: + case LINUX_FE_READ_UNCORRECTED_BLOCKS: + case LINUX_FE_GET_FRONTEND: + case LINUX_FE_GET_EVENT: + case LINUX_CA_GET_CAP: + case LINUX_CA_GET_SLOT_INFO: + case LINUX_CA_GET_DESCR_INFO: + case LINUX_CA_GET_MSG: + args->cmd = (args->cmd & ~IOC_DIRMASK) | IOC_OUT; + break; + + case LINUX_DMX_GET_STC: + case LINUX_NET_GET_IF: + net_add_if: + args->cmd = (args->cmd & ~IOC_DIRMASK) | IOC_INOUT; + break; + + case LINUX_FE_SET_PROPERTY: + case LINUX_FE_GET_PROPERTY: + error = copyin((void *)args->arg, &l_vps, sizeof(l_vps)); + if (error) + return (error); + linux_to_bsd_dtv_properties(&l_vps, &vps); + if ((vps.num == 0) || vps.num > DTV_IOCTL_MAX_MSGS) + return EINVAL; + + l_propsiz = vps.num * sizeof(*l_vp); + propsiz = vps.num * sizeof(*vp); + l_vp = malloc(l_propsiz, M_LINUX, M_WAITOK); + vp = malloc(propsiz, M_LINUX, M_WAITOK); + error = copyin((void *)vps.props, l_vp, l_propsiz); + if (error) + goto out2; + for (i = vps.num, l_p = l_vp, p = vp; i--; ++l_p, ++p) + linux_to_bsd_dtv_property(l_p, p); + + error = copyout_map(td, &uvp, propsiz); + if (error) + goto out2; + copyout(vp, (void *)uvp, propsiz); + + if ((error = fget(td, args->fd, &fp)) != 0) { + (void)copyout_unmap(td, uvp, propsiz); + goto out2; + } + vps.props = (void *)uvp; + if ((args->cmd & 0xffff) == LINUX_FE_SET_PROPERTY) + error = fo_ioctl(fp, FE_SET_PROPERTY, &vps, td->td_ucred, td); + else + error = fo_ioctl(fp, FE_GET_PROPERTY, &vps, td->td_ucred, td); + if (error) { + (void)copyout_unmap(td, uvp, propsiz); + goto out; + } + error = copyin((void *)uvp, vp, propsiz); + (void)copyout_unmap(td, uvp, propsiz); + if (error) + goto out; + for (i = vps.num, l_p = l_vp, p = vp; i--; ++l_p, ++p) + bsd_to_linux_dtv_property(p, l_p); + linux_to_bsd_dtv_properties(&l_vps, &vps); + copyout(l_vp, (void *)vps.props, l_propsiz); + + out: + fdrop(fp, td); + out2: + if (l_vp) + free(l_vp, M_LINUX); + if (vp) + free(vp, M_LINUX); + return (error); + + default: return (ENOIOCTL); + } + + error = ioctl(td, (struct ioctl_args *)args); + return (error); +} + /* * Support for emulators/linux-libusb. This port uses FBSD_LUSB* macros * instead of USB* ones. This lets us to provide correct values for cmd. Index: src/sys/compat/linux/linux_ioctl.h =================================================================== RCS file: /home/scvs/src/sys/compat/linux/linux_ioctl.h,v retrieving revision 1.32 diff -u -p -r1.32 linux_ioctl.h --- src/sys/compat/linux/linux_ioctl.h 30 Dec 2010 02:18:04 -0000 1.32 +++ src/sys/compat/linux/linux_ioctl.h 20 Feb 2011 16:37:17 -0000 @@ -32,6 +32,17 @@ #define _LINUX_IOCTL_H_ /* + * ioctl + * + * XXX comments in Linux' indicate these + * could be arch-dependant... + */ +#define LINUX_IOC_VOID 0 +#define LINUX_IOC_IN 0x40000000 +#define LINUX_IOC_OUT 0x80000000 +#define LINUX_IOC_INOUT (LINUX_IOC_IN|LINUX_IOC_OUT) + +/* * disk */ #define LINUX_BLKROSET 0x125d @@ -613,6 +624,83 @@ int linux_ifname(struct ifnet *, char #define LINUX_IOCTL_VIDEO_MAX LINUX_VIDIOCSVBIFMT /* + * DVB (osd.h and video.h not handled) + */ +#define LINUX_AUDIO_STOP 0x6f01 /* 0x00006f01 */ +#define LINUX_AUDIO_PLAY 0x6f02 /* 0x00006f02 */ +#define LINUX_AUDIO_PAUSE 0x6f03 /* 0x00006f03 */ +#define LINUX_AUDIO_CONTINUE 0x6f04 /* 0x00006f04 */ +#define LINUX_AUDIO_SELECT_SOURCE 0x6f05 /* 0x00006f05 */ +#define LINUX_AUDIO_SET_MUTE 0x6f06 /* 0x00006f06 */ +#define LINUX_AUDIO_SET_AV_SYNC 0x6f07 /* 0x00006f07 */ +#define LINUX_AUDIO_SET_BYPASS_MODE 0x6f08 /* 0x00006f08 */ +#define LINUX_AUDIO_CHANNEL_SELECT 0x6f09 /* 0x00006f09 */ +#define LINUX_AUDIO_GET_STATUS 0x6f0a /* 0x80206f0a */ +#define LINUX_AUDIO_GET_CAPABILITIES 0x6f0b /* 0x80046f0b */ +#define LINUX_AUDIO_CLEAR_BUFFER 0x6f0c /* 0x00006f0c */ +#define LINUX_AUDIO_SET_ID 0x6f0d /* 0x00006f0d */ +#define LINUX_AUDIO_SET_MIXER 0x6f0e /* 0x40086f0e */ +#define LINUX_AUDIO_SET_STREAMTYPE 0x6f0f /* 0x00006f0f */ +#define LINUX_AUDIO_SET_EXT_ID 0x6f10 /* 0x00006f10 */ +#define LINUX_AUDIO_SET_ATTRIBUTES 0x6f11 /* 0x40026f11 */ +#define LINUX_AUDIO_SET_KARAOKE 0x6f12 /* 0x400c6f12 */ +#define LINUX_AUDIO_GET_PTS 0x6f13 /* 0x80086f13 */ +#define LINUX_AUDIO_BILINGUAL_CHANNEL_SELECT 0x6f14 /* 0x00006f14 */ +#define LINUX_DMX_START 0x6f29 /* 0x00006f29 */ +#define LINUX_DMX_STOP 0x6f2a /* 0x00006f2a */ +#define LINUX_DMX_SET_FILTER 0x6f2b /* 0x403c6f2b */ +#define LINUX_DMX_SET_PES_FILTER 0x6f2c /* 0x40146f2c */ +#define LINUX_DMX_SET_BUFFER_SIZE 0x6f2d /* 0x00006f2d */ +#define LINUX_DMX_GET_PES_PIDS 0x6f2f /* 0x800a6f2f */ +#define LINUX_DMX_GET_CAPS 0x6f30 /* 0x80086f30 */ +#define LINUX_DMX_SET_SOURCE 0x6f31 /* 0x40046f31 */ +#define LINUX_DMX_GET_STC 0x6f32 /* 0xc0106f32 */ +#define LINUX_DMX_ADD_PID 0x6f33 /* 0x40026f33 */ +#define LINUX_DMX_REMOVE_PID 0x6f34 /* 0x40026f34 */ +#define LINUX_FE_GET_INFO 0x6f3d /* 0x80a86f3d */ +#define LINUX_FE_DISEQC_RESET_OVERLOAD 0x6f3e /* 0x00006f3e */ +#define LINUX_FE_DISEQC_SEND_MASTER_CMD 0x6f3f /* 0x40076f3f */ +#define LINUX_FE_DISEQC_RECV_SLAVE_REPLY 0x6f40 /* 0x800c6f40 */ +#define LINUX_FE_DISEQC_SEND_BURST 0x6f41 /* 0x00006f41 */ +#define LINUX_FE_SET_TONE 0x6f42 /* 0x00006f42 */ +#define LINUX_FE_SET_VOLTAGE 0x6f43 /* 0x00006f43 */ +#define LINUX_FE_ENABLE_HIGH_LNB_VOLTAGE 0x6f44 /* 0x00006f44 */ +#define LINUX_FE_READ_STATUS 0x6f45 /* 0x80046f45 */ +#define LINUX_FE_READ_BER 0x6f46 /* 0x80046f46 */ +#define LINUX_FE_READ_SIGNAL_STRENGTH 0x6f47 /* 0x80026f47 */ +#define LINUX_FE_READ_SNR 0x6f48 /* 0x80026f48 */ +#define LINUX_FE_READ_UNCORRECTED_BLOCKS 0x6f49 /* 0x80046f49 */ +#define LINUX_FE_SET_FRONTEND 0x6f4c /* 0x40246f4c */ +#define LINUX_FE_GET_FRONTEND 0x6f4d /* 0x80246f4d */ +#define LINUX_FE_GET_EVENT 0x6f4e /* 0x80286f4e */ +#define LINUX_FE_DISHNETWORK_SEND_LEGACY_CMD 0x6f50 /* 0x00006f50 */ +#define LINUX_FE_SET_FRONTEND_TUNE_MODE 0x6f51 /* 0x00006f51 */ +#define LINUX_FE_SET_PROPERTY 0x6f52 /* 0x40086f52 */ +#define LINUX_FE_GET_PROPERTY 0x6f53 /* 0x80086f53 */ +#define LINUX_CA_RESET 0x6f80 /* 0x00006f80 */ +#define LINUX_CA_GET_CAP 0x6f81 /* 0x80106f81 */ +#define LINUX_CA_GET_SLOT_INFO 0x6f82 /* 0x800c6f82 */ +#define LINUX_CA_GET_DESCR_INFO 0x6f83 /* 0x80086f83 */ +#define LINUX_CA_GET_MSG 0x6f84 /* 0x810c6f84 */ +#define LINUX_CA_SEND_MSG 0x6f85 /* 0x410c6f85 */ +#define LINUX_CA_SET_DESCR 0x6f86 /* 0x40106f86 */ +#define LINUX_CA_SET_PID 0x6f87 /* 0x40086f87 */ + +/* + * DVB net.h + * (LINUX_NET_ADD_IF and LINUX___NET_ADD_IF_OLD overlap with + * LINUX_DMX_REMOVE_PID) + */ +#define LINUX_NET_ADD_IF 0x6f34 /* 0xc0066f34 */ +#define LINUX_NET_REMOVE_IF 0x6f35 /* 0x00006f35 */ +#define LINUX_NET_GET_IF 0x6f36 /* 0xc0066f36 */ +#define LINUX___NET_ADD_IF_OLD 0x6f34 /* 0xc0046f34 */ +#define LINUX___NET_GET_IF_OLD 0x6f36 /* 0xc0046f36 */ + +#define LINUX_IOCTL_DVB_MIN LINUX_AUDIO_STOP +#define LINUX_IOCTL_DVB_MAX LINUX_CA_SET_PID + +/* * Our libusb(8) calls emulated within linux(4). */ #define FBSD_LUSB_DEVICEENUMERATE 0xffff Index: src/sys/dev/ksyms/ksyms.c =================================================================== RCS file: /home/scvs/src/sys/dev/ksyms/ksyms.c,v retrieving revision 1.6 diff -u -p -r1.6 ksyms.c --- src/sys/dev/ksyms/ksyms.c 29 Dec 2009 21:51:28 -0000 1.6 +++ src/sys/dev/ksyms/ksyms.c 21 Feb 2011 17:47:55 -0000 @@ -360,53 +360,6 @@ ksyms_snapshot(struct tsizes *ts, vm_off return (error); } -/* - * Map some anonymous memory in user space of size sz, rounded up to the page - * boundary. - */ -static int -ksyms_map(struct thread *td, vm_offset_t *addr, size_t sz) -{ - struct vmspace *vms = td->td_proc->p_vmspace; - int error; - vm_size_t size; - - - /* - * Map somewhere after heap in process memory. - */ - PROC_LOCK(td->td_proc); - *addr = round_page((vm_offset_t)vms->vm_daddr + - lim_max(td->td_proc, RLIMIT_DATA)); - PROC_UNLOCK(td->td_proc); - - /* round size up to page boundry */ - size = (vm_size_t) round_page(sz); - - error = vm_mmap(&vms->vm_map, addr, size, PROT_READ | PROT_WRITE, - VM_PROT_ALL, MAP_PRIVATE | MAP_ANON, OBJT_DEFAULT, NULL, 0); - - return (error); -} - -/* - * Unmap memory in user space. - */ -static int -ksyms_unmap(struct thread *td, vm_offset_t addr, size_t sz) -{ - vm_map_t map; - vm_size_t size; - - map = &td->td_proc->p_vmspace->vm_map; - size = (vm_size_t) round_page(sz); - - if (!vm_map_remove(map, addr, addr + size)) - return (EINVAL); - - return (0); -} - static void ksyms_cdevpriv_dtr(void *data) { @@ -475,7 +428,7 @@ ksyms_open(struct cdev *dev, int flags, total_elf_sz = sizeof(struct ksyms_hdr) + ts.ts_symsz + ts.ts_strsz; - error = ksyms_map(td, &(sc->sc_uaddr), + error = copyout_map(td, &(sc->sc_uaddr), (vm_size_t) total_elf_sz); if (error) break; @@ -488,7 +441,7 @@ ksyms_open(struct cdev *dev, int flags, } /* Snapshot failed, unmap the memory and try again */ - (void) ksyms_unmap(td, sc->sc_uaddr, sc->sc_usize); + (void) copyout_unmap(td, sc->sc_uaddr, sc->sc_usize); } failed: @@ -624,7 +577,7 @@ ksyms_close(struct cdev *dev, int flags return (error); /* Unmap the buffer from the process address space. */ - error = ksyms_unmap(td, sc->sc_uaddr, sc->sc_usize); + error = copyout_unmap(td, sc->sc_uaddr, sc->sc_usize); devfs_clear_cdevpriv(); Index: src/sys/compat/linux/linux_dvb.h @@ -0,0 +1,63 @@ +/* + * Extracted from , which is: + * + * Copyright (C) 2000 Marcus Metzler + * Ralph Metzler + * Holger Waechtler + * Andre Draszik + * for convergence integrated media GmbH + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public License + * as published by the Free Software Foundation; either version 2.1 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + * + */ + +#ifndef __LINUX_DVB_H +#define __LINUX_DVB_H + +#include + +struct dtv_property { + uint32_t cmd; + uint32_t reserved[3]; + union { + uint32_t data; + struct { + uint8_t data[32]; + uint32_t len; + uint32_t reserved1[3]; + void *reserved2; + } buffer; + } u; + int result; +} __attribute__ ((packed)); + +/* num of properties cannot exceed DTV_IOCTL_MAX_MSGS per ioctl */ +#define DTV_IOCTL_MAX_MSGS 64 + +struct dtv_properties { + uint32_t num; + struct dtv_property *props; +}; + +#define FE_SET_PROPERTY _IOW('o', 82, struct dtv_properties) +/* + * This is broken on linux as well but they workaround it in the driver. + * Since this is impossible to do on FreeBSD fix the header instead. + * Detailed and discussion : + * http://lists.freebsd.org/pipermail/freebsd-multimedia/2010-April/010958.html + */ +#define FE_GET_PROPERTY _IOW('o', 83, struct dtv_properties) + +#endif /*__LINUX_DVB_H*/ Index: src/sys/compat/linux/linux_dvb_compat.h @@ -0,0 +1,26 @@ +#ifndef __LINUX_DVB_COMPAT_H +#define __LINUX_DVB_COMPAT_H + +#include + +struct l_dtv_property { + uint32_t cmd; + uint32_t reserved[3]; + union { + uint32_t data; + struct { + uint8_t data[32]; + uint32_t len; + uint32_t reserved1[3]; + l_uintptr_t reserved2; + } buffer; + } u; + l_int result; +} __attribute__ ((packed)); + +struct l_dtv_properties { + uint32_t num; + l_uintptr_t props; +}; + +#endif /*__LINUX_DVB_H*/ From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 21 19:01:36 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D72811065670 for ; Mon, 21 Feb 2011 19:01:36 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id A9C3C8FC1F for ; Mon, 21 Feb 2011 19:01:36 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id p1LIXloI087289 for ; Mon, 21 Feb 2011 10:33:48 -0800 (PST) (envelope-from yuri@rawbw.com) Message-ID: <4D62B0B7.1060604@rawbw.com> Date: Mon, 21 Feb 2011 10:36:39 -0800 From: Yuri User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20101211 Thunderbird/3.0.11 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: FreeBSD ABI? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 19:01:36 -0000 Where is it documented? Are there differences with the linux ABI? Particularly I am interested in stack alignment requirement. For example i386 Solaris, Linux and MacOS have 16 bit stack alignment for procedure calls. This is reflected in LLVM sources: if (isTargetDarwin() || isTargetLinux() || isTargetSolaris() || Is64Bit) stackAlignment = 16; But FreeBSD is excluded there. Is this a bug in LLVM which magically doesn't cause crashes or this is correct and FreeBSD doesn't have 16 bit alignment? Yuri From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 21 20:07:57 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 451AD106566C; Mon, 21 Feb 2011 20:07:57 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ew0-f49.google.com (mail-ew0-f49.google.com [209.85.215.49]) by mx1.freebsd.org (Postfix) with ESMTP id 77FF58FC12; Mon, 21 Feb 2011 20:07:56 +0000 (UTC) Received: by ewy23 with SMTP id 23so720639ewy.8 for ; Mon, 21 Feb 2011 12:07:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1ykyobV8y6187OR5JHXYKP59rNq4eFA5NuE6cm+2eRU=; b=EFEgWHgYRs7ucuISAHzPqZ09+5Au4k3ZFlsgGl4t0DlIoFFesge8r9cMZpKtkpNCnV RFVJFYbLHkCpwn28nYKkaTOc1CYi7zsSwB3QAxVhAvnWRDC1O/ihyW+hc4Jax4j+0PRU 83pny5QOCamsNFLBHOEpA0pywmqNjNwAsqq+Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=pvLNIjBldpMB7fNY/YT0M3a7RWyy3xjUhFuEOx3xh0zmH/aaFWjIStvoFBPTxYcrLE XcTl5PIcjxQcaeoXayTZuD2vZZJ++NPk9ve+ONXhcDv7sSiqrRIJnBp02rCKjFeP+070 XN6wse8dxxA+70CpoqjYjDz05xChqAuvhlVfs= MIME-Version: 1.0 Received: by 10.216.155.75 with SMTP id i53mr2512006wek.27.1298318875220; Mon, 21 Feb 2011 12:07:55 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.71.200 with HTTP; Mon, 21 Feb 2011 12:07:54 -0800 (PST) In-Reply-To: <4D6292DD.8010704@freebsd.org> References: <8332E9240ECA403480B48D21FA3A8694@multiplay.co.uk> <4D6292DD.8010704@freebsd.org> Date: Mon, 21 Feb 2011 12:07:54 -0800 X-Google-Sender-Auth: wgVU-5gTp7RGTPT4RddyOwFItKI Message-ID: From: Garrett Cooper To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Steven Hartland , freebsd-stable@freebsd.org Subject: Re: machdep.hlt_cpus not safe with ULE? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 20:07:57 -0000 On Mon, Feb 21, 2011 at 8:29 AM, Andriy Gapon wrote: > on 19/02/2011 14:36 Steven Hartland said the following: >> I'm trying to debug a possibly failing CPU, so I thought it would >> be easy just disable the cores using machdep.hlt_cpus and see if >> we see the panic's we've been seeing. >> >> The problem is it seems ULE doesnt properly support machdep.hlt_cpus >> and still schedules processes onto the halted cpus which obviously >> causes problems. >> >> Can anyone confirm this behaviour? > > Yes, your observations are correct. > Please also see: http://www.freebsd.org/cgi/query-pr.cgi?pr=145385 > >> Should machdep.hlt_cpus and I assume >> the logical counterpart never be used with ULE? As a followup to this and based on discussions with other folks, the fact that it's using hlt to halt CPUs without rescheduling tasks / masking interrupts, etc is not good. So none of the *hlt* sysctls are really doing the right thing on x86. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 21 20:41:40 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FBC61065673; Mon, 21 Feb 2011 20:41:40 +0000 (UTC) (envelope-from prvs=10337ef692=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 31F658FC1A; Mon, 21 Feb 2011 20:41:38 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Mon, 21 Feb 2011 20:30:21 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 21 Feb 2011 20:30:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50012271061.msg; Mon, 21 Feb 2011 20:30:19 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=10337ef692=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <7048D14F1FD341F2AFD2B0CB13C95477@multiplay.co.uk> From: "Steven Hartland" To: "Garrett Cooper" , "Andriy Gapon" References: <8332E9240ECA403480B48D21FA3A8694@multiplay.co.uk><4D6292DD.8010704@freebsd.org> Date: Mon, 21 Feb 2011 20:30:54 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: machdep.hlt_cpus not safe with ULE? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 20:41:40 -0000 ----- Original Message ----- From: "Garrett Cooper" > As a followup to this and based on discussions with other folks, > the fact that it's using hlt to halt CPUs without rescheduling tasks / > masking interrupts, etc is not good. So none of the *hlt* sysctls are > really doing the right thing on x86. Time to disable them until they are fixed properly then I would suggest? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 21 20:46:22 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65018106566C for ; Mon, 21 Feb 2011 20:46:22 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 2288C8FC0C for ; Mon, 21 Feb 2011 20:46:22 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 570C39CB0CA; Mon, 21 Feb 2011 21:46:21 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjlJjIl4BHEJ; Mon, 21 Feb 2011 21:46:09 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 473ED9CB472; Mon, 21 Feb 2011 21:46:09 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id p1LKk8CK029819; Mon, 21 Feb 2011 21:46:08 +0100 (CET) (envelope-from rdivacky) Date: Mon, 21 Feb 2011 21:46:08 +0100 From: Roman Divacky To: Yuri Message-ID: <20110221204608.GA29656@freebsd.org> References: <4D62B0B7.1060604@rawbw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D62B0B7.1060604@rawbw.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD ABI? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 20:46:22 -0000 On Mon, Feb 21, 2011 at 10:36:39AM -0800, Yuri wrote: > Where is it documented? > Are there differences with the linux ABI? > > Particularly I am interested in stack alignment requirement. For example > i386 Solaris, Linux and MacOS have 16 bit stack alignment for procedure > calls. This is reflected in LLVM sources: > > if (isTargetDarwin() || isTargetLinux() || isTargetSolaris() || Is64Bit) > stackAlignment = 16; > > > But FreeBSD is excluded there. Is this a bug in LLVM which magically > doesn't cause crashes or this is correct and FreeBSD doesn't have 16 bit > alignment? the alignment is specified in bytes but yes, I wonder too, what is the stack alignment on freebsd on amd64/i386? From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 21 20:47:45 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50471106566B; Mon, 21 Feb 2011 20:47:45 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 860BF8FC08; Mon, 21 Feb 2011 20:47:44 +0000 (UTC) Received: by wwf26 with SMTP id 26so6344410wwf.31 for ; Mon, 21 Feb 2011 12:47:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qwCWNv2u6GFAi+yrq8S6P6hewG8lm4IChW9Ap1HYWpI=; b=rk9bhQpSol9yQ/nl1UmSpwk2L8FdfsXmiTwmoOTTpWkw4lcuufBFBnIj0lmhZGUT9s 0NAeFbwwlVn2in6KGQxSJm7nfSXuTzrG5vHDIsMflMoX81Bn3PMdqkmyoXng/Ptef4Ua rQRYndf8h8yPbN1lcYA6xpDMhdvvRT7Ts5om0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=QjnKpLTewkiQS7/kPHsTxZsid/1IJJGZkrhIMOhF2koNmdchC0Yjit1Mh2JcJ2LLWK zHmndGM0QQ14wW+EWet5jCFTsqPua/nhsLdD+4+FCBW9MT/Rk+P6PyNtMfT37NhcBeCL /xzN8parYym0e5n4DPnltqqqyrLYonq9+Zwco= MIME-Version: 1.0 Received: by 10.216.241.138 with SMTP id g10mr1628225wer.27.1298321244744; Mon, 21 Feb 2011 12:47:24 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.71.200 with HTTP; Mon, 21 Feb 2011 12:47:24 -0800 (PST) In-Reply-To: <7048D14F1FD341F2AFD2B0CB13C95477@multiplay.co.uk> References: <8332E9240ECA403480B48D21FA3A8694@multiplay.co.uk> <4D6292DD.8010704@freebsd.org> <7048D14F1FD341F2AFD2B0CB13C95477@multiplay.co.uk> Date: Mon, 21 Feb 2011 12:47:24 -0800 X-Google-Sender-Auth: pJ654n1YnpnqwiaIHKihBV0HfY4 Message-ID: From: Garrett Cooper To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: machdep.hlt_cpus not safe with ULE? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 20:47:45 -0000 On Mon, Feb 21, 2011 at 12:30 PM, Steven Hartland wrote: > ----- Original Message ----- From: "Garrett Cooper" >> >> =A0 As a followup to this and based on discussions with other folks, >> the fact that it's using hlt to halt CPUs without rescheduling tasks / >> masking interrupts, etc is not good. So none of the *hlt* sysctls are >> really doing the right thing on x86. > > Time to disable them until they are fixed properly then I would suggest? Andriy's patch attached to the PR above does the right thing when first bringing up the system, but it's still broken with the sysctl case, so I would actually vote to disable the sysctls for now and commit his patch separately as it's better than the existing code is in that area. Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 21 23:10:49 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 096A8106566C for ; Mon, 21 Feb 2011 23:10:49 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id BC8538FC1E for ; Mon, 21 Feb 2011 23:10:48 +0000 (UTC) Received: by ywf9 with SMTP id 9so411321ywf.13 for ; Mon, 21 Feb 2011 15:10:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:date:message-id:subject :from:to:content-type; bh=mF6O4D5p4kjZ5h56gJ0exUPM7kHKyFvEfyjes/ekN2Q=; b=BA2zUhPOUk3sC81niND8fJEo4Z4tYuHwKuCFGRKIhmUm3Yg0jhqpfwaVQTTQzgPRv7 GX7ulRKbbVgQrLuT14QpMXhSlRR3uJkU1qspXL3VgMG6Fb6eYxSDcbzXgfYLo7i/RiOt d+1Jw1v7dBUetvxB8g/u7pET6JD+iRZFlvRiQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=GzwFgQ8T2sq46eTY+b9MBMQVkWDqCCiiYAmS8UPaxZ1nMtULA67i3/tUNZLp+odBN4 +FGbexisEyTe/2gyAGQnituEWhvsKgslUkvy08FA+d8VWbOIy4MXd2eZQLAStfPiKGoO H4P9eRNhZrbaqhpElx7NluhdjvGWSDcL6+xBk= MIME-Version: 1.0 Received: by 10.236.109.166 with SMTP id s26mr3568780yhg.76.1298328463723; Mon, 21 Feb 2011 14:47:43 -0800 (PST) Received: by 10.236.110.52 with HTTP; Mon, 21 Feb 2011 14:47:43 -0800 (PST) Date: Mon, 21 Feb 2011 17:47:43 -0500 Message-ID: From: "b. f." To: freebsd-hackers@FreeBSD.org, Roman Divacky , Yuri Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: FreeBSD ABI? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 23:10:49 -0000 > > Where is it documented? > > Are there differences with the linux ABI? > > > > Particularly I am interested in stack alignment requirement. For example > > i386 Solaris, Linux and MacOS have 16 bit stack alignment for procedure > > calls. This is reflected in LLVM sources: > > > > if (isTargetDarwin() || isTargetLinux() || isTargetSolaris() || Is64Bit) > > stackAlignment = 16; > > > > > > But FreeBSD is excluded there. Is this a bug in LLVM which magically > > doesn't cause crashes or this is correct and FreeBSD doesn't have 16 bit > > alignment? > > the alignment is specified in bytes but yes, I wonder too, what is the > stack alignment on freebsd on amd64/i386? > > Isn't it supposed to [1] conform to: http://www.sco.com/developers/devspecs/abi386-4.pdf http://www.x86-64.org/documentation/abi.pdf ? [1] See, for example: http://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/034045.html http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/csu/i386-elf/crt1_s.S http://lists.freebsd.org/pipermail/svn-src-head/2010-December/023065.html From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 21 23:16:55 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0ABA106566C for ; Mon, 21 Feb 2011 23:16:55 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id AA6DE8FC17 for ; Mon, 21 Feb 2011 23:16:55 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id p1LNE4Om048302; Mon, 21 Feb 2011 15:14:04 -0800 (PST) (envelope-from yuri@rawbw.com) Message-ID: <4D62F267.3000706@rawbw.com> Date: Mon, 21 Feb 2011 15:16:55 -0800 From: Yuri User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20101211 Thunderbird/3.0.11 MIME-Version: 1.0 To: bf1783@gmail.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Roman Divacky , "b. f." Subject: Re: FreeBSD ABI? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 23:16:55 -0000 On 02/21/2011 14:47, b. f. wrote: > Isn't it supposed to [1] conform to: > > http://www.sco.com/developers/devspecs/abi386-4.pdf > http://www.x86-64.org/documentation/abi.pdf > > ? > > [1] See, for example: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/034045.html > http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/csu/i386-elf/crt1_s.S > http://lists.freebsd.org/pipermail/svn-src-head/2010-December/023065.html > Solaris-i386 ABI is also supposed to conform to abi386-4.pdf. In section 3-10 it says: "The stack is word aligned. Although the architecture does not require any alignment of the stack, software convention and the operating system requires that the stack be aligned on a word boundary." But I know for the fact that Solaris-i386 uses 16 byte alignment. At least that's what gcc-4.5.2 thinks when on Solaris. Still not sure about FreeBSD-i386. Yuri From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 21 23:38:36 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE96E106564A for ; Mon, 21 Feb 2011 23:38:36 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.162]) by mx1.freebsd.org (Postfix) with ESMTP id 68F098FC0C for ; Mon, 21 Feb 2011 23:38:36 +0000 (UTC) X-RZG-AUTH: :JiIXek6mfvEEUpFQdo7Fj1/zg48CFjWjQv0cW+St/nW/auYssS93lrdGFRy9Xe0= X-RZG-CLASS-ID: mo00 Received: from britannica.bec.de (ip-2-202-164-146.web.vodafone.de [2.202.164.146]) by post.strato.de (mrclete mo4) (RZmta 25.5) with (DHE-RSA-AES128-SHA encrypted) ESMTPA id h0733en1LNSZ4g for ; Tue, 22 Feb 2011 00:38:33 +0100 (MET) Received: by britannica.bec.de (sSMTP sendmail emulation); Tue, 22 Feb 2011 00:38:17 +0100 Date: Tue, 22 Feb 2011 00:38:17 +0100 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20110221233817.GA4792@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <4D62F267.3000706@rawbw.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D62F267.3000706@rawbw.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: FreeBSD ABI? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 23:38:36 -0000 On Mon, Feb 21, 2011 at 03:16:55PM -0800, Yuri wrote: > But I know for the fact that Solaris-i386 uses 16 byte alignment. At > least that's what gcc-4.5.2 thinks when on Solaris. That's a major difference. The Linux people decided a while ago that stack alignment should be 16 Byte. GCC effectively forces that down everyone's throat because until at least GCC 4.2 or 4.3, it can't correctly realign the stack and just fails miserable. I would be surprised if it was a conscious decision for the Solaris either. The main exception here is Mac OSX, since it defined the x86 ABI a lot latter and doesn't claim to be SYSV compatible. Joerg From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 21 23:58:33 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41AC8106564A for ; Mon, 21 Feb 2011 23:58:33 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 11CB98FC14 for ; Mon, 21 Feb 2011 23:58:32 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id p1LNtfXv056566 for ; Mon, 21 Feb 2011 15:55:41 -0800 (PST) (envelope-from yuri@rawbw.com) Message-ID: <4D62FC28.9040300@rawbw.com> Date: Mon, 21 Feb 2011 15:58:32 -0800 From: Yuri User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20101211 Thunderbird/3.0.11 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4D62F267.3000706@rawbw.com> <20110221233817.GA4792@britannica.bec.de> In-Reply-To: <20110221233817.GA4792@britannica.bec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD ABI? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 23:58:33 -0000 On 02/21/2011 15:38, Joerg Sonnenberger wrote: > That's a major difference. The Linux people decided a while ago that > stack alignment should be 16 Byte. GCC effectively forces that down > everyone's throat because until at least GCC 4.2 or 4.3, it can't > correctly realign the stack and just fails miserable. I would be > surprised if it was a conscious decision for the Solaris either. > I filed gcc PR asking gcc to revert their behavior back to prescribed by documentation: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47842 From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 00:10:35 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A240F106564A for ; Tue, 22 Feb 2011 00:10:35 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 8CF218FC0C for ; Tue, 22 Feb 2011 00:10:35 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id p1M07hFK059148 for ; Mon, 21 Feb 2011 16:07:44 -0800 (PST) (envelope-from yuri@rawbw.com) Message-ID: <4D62FEFB.1070709@rawbw.com> Date: Mon, 21 Feb 2011 16:10:35 -0800 From: Yuri User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20101211 Thunderbird/3.0.11 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4D62F267.3000706@rawbw.com> <20110221233817.GA4792@britannica.bec.de> In-Reply-To: <20110221233817.GA4792@britannica.bec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD ABI? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 00:10:35 -0000 On 02/21/2011 15:38, Joerg Sonnenberger wrote: > That's a major difference. The Linux people decided a while ago that > stack alignment should be 16 Byte. GCC effectively forces that down > everyone's throat because until at least GCC 4.2 or 4.3, it can't > correctly realign the stack and just fails miserable. I would be > surprised if it was a conscious decision for the Solaris either. > On the other hand, 16 byte alignment allows for some extra optimizations. For example many SIMD instructions like movdqa can only be used on 16 byte aligned values. That's why linux probably decided to change this. Yuri From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 00:16:50 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07E35106566B for ; Tue, 22 Feb 2011 00:16:50 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id B95928FC17 for ; Tue, 22 Feb 2011 00:16:49 +0000 (UTC) Received: by gyh4 with SMTP id 4so1307542gyh.13 for ; Mon, 21 Feb 2011 16:16:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:date:message-id:subject :from:to:content-type; bh=tAl+M008/R54pNQ/HP6PX84KFOXdH6RyCwr8iDuK85o=; b=gU2jrgcFifudu1iEWGGPtSdrmKn74RnIdIGF20idc74eBY934W/tvHUb4gLMvu0+os QJTmoPqhk1aj4MDIj+pytwzXa3w2J2yU+nfQuTptNaQF+G3zeFynZOJuiC8WjUw3Qgr6 p6Em4srvm2a/0Lq3tmKcj4FYilgNsyX398Tok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=eGrkdpxsVEsm5fkQ/lWAYfQd8DHKkFoZQVYCGNgnCEHt466pWKN45Y83CglKvYMkZF biMz/driA6NLu++9nvrFhISUoOnntsfp8sFkIAb/TvLviCRcD3tAIarBKUadB1uXKQ7f Ycx2yrdJKqrwBGKCypriVpNTi1VGUR+jnz2OI= MIME-Version: 1.0 Received: by 10.236.109.164 with SMTP id s24mr3688519yhg.89.1298333806392; Mon, 21 Feb 2011 16:16:46 -0800 (PST) Received: by 10.236.110.52 with HTTP; Mon, 21 Feb 2011 16:16:46 -0800 (PST) Date: Tue, 22 Feb 2011 00:16:46 +0000 Message-ID: From: "b. f." To: freebsd-hackers , Yuri Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: FreeBSD ABI? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 00:16:50 -0000 >I filed gcc PR asking gcc to revert their behavior back to prescribed by >documentation: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47842 Heh, good luck!: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496 From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 03:15:58 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 423D2106564A for ; Tue, 22 Feb 2011 03:15:58 +0000 (UTC) (envelope-from dougb@dougbarton.us) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id DEB448FC0A for ; Tue, 22 Feb 2011 03:15:57 +0000 (UTC) Received: (qmail 28015 invoked by uid 399); 22 Feb 2011 02:47:55 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 22 Feb 2011 02:47:55 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D6323D9.5090500@dougbarton.us> Date: Mon, 21 Feb 2011 18:47:53 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: multipart/mixed; boundary="------------000906090401000304050905" X-Mailman-Approved-At: Tue, 22 Feb 2011 03:22:36 +0000 Cc: Subject: Problem with etc/periodic/daily/310.accounting X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 03:15:58 -0000 This is a multi-part message in MIME format. --------------000906090401000304050905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I was looking over etc/periodic/daily/310.accounting on a system that is very tight on space in /var, and I think that at minimum there is a race, and at best there is a pretty serious inefficiency. Right now after rotating the old logs the script does this: cp -pf acct acct.0 || rc=3 sa -s $daily_accounting_flags || rc=3 case "$daily_accounting_compress" in [Yy][Ee][Ss]) gzip -f acct.0 || rc=3;; esac To start with, the cp is a problem on a space-constrained system especially when the log is very large. However I think that doing it this way also introduces a race where events that are logged between the cp and the sa run are not backed up in acct.0. ITSM that the proper procedure is: mv acct acct.0 || rc=3 case "$daily_accounting_compress" in [Yy][Ee][Ss]) gzip --keep -f acct.0 || rc=3;; esac sa -s $daily_accounting_flags acct.0 && unlink acct.0 || rc=3 Can anyone see why that would be wrong? If there is no objection, I'll be committing the attached patch. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ --------------000906090401000304050905 Content-Type: text/plain; name="310.accounting.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="310.accounting.diff" Index: 310.accounting =================================================================== --- 310.accounting (revision 218864) +++ 310.accounting (working copy) @@ -41,13 +41,15 @@ m=$n n=$(($n - 1)) done - cp -pf acct acct.0 || rc=3 - sa -s $daily_accounting_flags || rc=3 + mv acct acct.0 || rc=3 + case "$daily_accounting_compress" in [Yy][Ee][Ss]) - gzip -f acct.0 || rc=3;; + gzip --keep -f acct.0 || rc=3;; esac + + sa -s $daily_accounting_flags acct.0 && unlink acct.0 || rc=3 fi;; *) rc=0;; --------------000906090401000304050905-- From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 07:52:49 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAF99106564A for ; Tue, 22 Feb 2011 07:52:49 +0000 (UTC) (envelope-from gnehzuil@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8F8428FC1B for ; Tue, 22 Feb 2011 07:52:49 +0000 (UTC) Received: by pxi20 with SMTP id 20so453136pxi.13 for ; Mon, 21 Feb 2011 23:52:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=u8GQkinbLBM1lXr57xQ8aMbg7f/tlH/V+cS/S1XDUg8=; b=xrBxVNz2SlCKvEl6bxAnM53t3DT79YKywPed3DQKtC/MCn4QS57mtHyRAb0VVIc2Nz duKCMBrT5gcGvB6SniEUa2/27Bm6qSngr4GrzjS7BKEH+/Okwt7wlpXRtmd4MaFk0NfT JmJc87tVLmxBCl0AYTZ9Hy8mgOwLvMc9f2SyI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=wR9Vq8tH8+hzRvrIH03Y843+M6E2lyy8JVW4jBBPaiJkNMWbByh8ivF9jNzo9QcGex o2l/nt/UmVRFnUY5H72p8ZtO4KXxHT3RgW8RT1I0h50gxYSRRqi+8+C5T4AqPTgKV91q TNY9PmG66n6s9/xHRQmmEABfUTV1lozA/X+Ec= Received: by 10.142.144.2 with SMTP id r2mr1909006wfd.244.1298359843869; Mon, 21 Feb 2011 23:30:43 -0800 (PST) Received: from [192.168.1.157] ([166.111.68.197]) by mx.google.com with ESMTPS id o11sm8852895wfa.0.2011.02.21.23.30.41 (version=SSLv3 cipher=OTHER); Mon, 21 Feb 2011 23:30:43 -0800 (PST) Message-ID: <4D63661D.2090205@gmail.com> Date: Tue, 22 Feb 2011 15:30:37 +0800 From: gnehzuil User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: buildkernel error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 07:52:49 -0000 Hi all, I updated my kernel source code and try to make a new kernel using make buildkernel command. But I got an error as follow: ------------------------ :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=make sh /usr/src/sys/conf/newvers.sh GENERIC cc -c -O -pipe -std=c99 -g -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 inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug ld:/usr/src/sys/conf/ldscript.i386:66: syntax error *** Error code 1 Stop in /usr/obj/usr/src/sys/MYKERNEL. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. gnehzuil-freebsd# -------------------------- I run a freebsd OS in virtualbox. Best regards, lz From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 08:36:42 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91038106566C for ; Tue, 22 Feb 2011 08:36:42 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2836B8FC13 for ; Tue, 22 Feb 2011 08:36:41 +0000 (UTC) Received: by bwz13 with SMTP id 13so3205706bwz.17 for ; Tue, 22 Feb 2011 00:36:41 -0800 (PST) Received: by 10.204.46.130 with SMTP id j2mr2259176bkf.169.1298363800494; Tue, 22 Feb 2011 00:36:40 -0800 (PST) Received: from [192.168.0.20] (paris.c-mal.com [88.170.200.60]) by mx.google.com with ESMTPS id v25sm4326486bkt.6.2011.02.22.00.36.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Feb 2011 00:36:39 -0800 (PST) References: <4D63661D.2090205@gmail.com> In-Reply-To: <4D63661D.2090205@gmail.com> Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <9466185C-B180-408F-BE3F-85F29AECAA94@my.gd> X-Mailer: iPhone Mail (8A293) From: Damien Fleuriot Date: Tue, 22 Feb 2011 09:36:16 +0100 To: gnehzuil Cc: "freebsd-hackers@freebsd.org" Subject: Re: buildkernel error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 08:36:42 -0000 Rebuild the world first, then the kernel :) --- Fleuriot Damien On 22 Feb 2011, at 08:30, gnehzuil wrote: > Hi all, >=20 > I updated my kernel source code and try to make a new kernel using make bu= ildkernel command. But I got an error as follow: >=20 > ------------------------ > :> hack.c > cc -shared -nostdlib hack.c -o hack.So > rm -f hack.c > MAKE=3Dmake sh /usr/src/sys/conf/newvers.sh GENERIC > cc -c -O -pipe -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs -Ws= trict-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=3D8000 --param inline-unit-growth=3D= 100 --param large-function-growth=3D1000 -mno-align-long-strings -mpreferre= d-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft= -float -ffreestanding -fstack-protector -Werror vers.c > linking kernel.debug > ld:/usr/src/sys/conf/ldscript.i386:66: syntax error > *** Error code 1 >=20 > Stop in /usr/obj/usr/src/sys/MYKERNEL. > *** Error code 1 >=20 > Stop in /usr/src. > *** Error code 1 >=20 > Stop in /usr/src. > gnehzuil-freebsd# > -------------------------- >=20 > I run a freebsd OS in virtualbox. >=20 >=20 > Best regards, > lz >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 08:39:14 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91665106564A for ; Tue, 22 Feb 2011 08:39:14 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 62F7E8FC14 for ; Tue, 22 Feb 2011 08:39:14 +0000 (UTC) Received: by pzk32 with SMTP id 32so309750pzk.13 for ; Tue, 22 Feb 2011 00:39:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=/NmRecsUAEKrxYumq2rGJfztLV7oSzuLrceg5C7tkaI=; b=LJ2q49AE1JEnIZDhBjF9/k+nBgbyjhifGZn0LRwIaN/ADqCfiiVEJGiFk8G3PRa9Uw u0z6e592QqPCsnTOZ2e3P0imHprdPIOi9sMvMhk9A8PzFVC+p0MB4BYXRP8ONtTZGDVR XWbAVAAfDy2VTqncgWx43hiLdBmXJ+QHwlNdc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=QlObGeiRBIX3CSHRZRK7j6eM7l0n47pM3/vHcAnQD/fV81Y2r9Km4FQ8P02kPEsyzT qlGTXwJ8oznkJo9fuyw9C0EfgXza1RhgcNmFuVPAIn9DFdJKi6aTxueS6cBC3/JkJU+/ JiKS0Wp6hzqwlV8LpW5CjnSKZQoEZgar+LGRA= Received: by 10.142.204.9 with SMTP id b9mr1986666wfg.354.1298363953669; Tue, 22 Feb 2011 00:39:13 -0800 (PST) Received: from [192.168.20.5] (c-24-4-33-131.hsd1.ca.comcast.net [24.4.33.131]) by mx.google.com with ESMTPS id s41sm4257200wfc.15.2011.02.22.00.39.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Feb 2011 00:39:12 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <4D63661D.2090205@gmail.com> Date: Tue, 22 Feb 2011 00:39:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <94D6A4A4-1C05-40C7-8B29-8E025A0E4CB3@gmail.com> References: <4D63661D.2090205@gmail.com> To: gnehzuil X-Mailer: Apple Mail (2.1082) Cc: freebsd-hackers@freebsd.org Subject: Re: buildkernel error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 08:39:14 -0000 On Feb 21, 2011, at 11:30 PM, gnehzuil wrote: > Hi all, >=20 > I updated my kernel source code and try to make a new kernel using = make buildkernel command. But I got an error as follow: ... Read UPDATING, follow the handbook instructions :). Cheers, -Garrett= From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 08:46:40 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED91F1065670 for ; Tue, 22 Feb 2011 08:46:40 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id A9ADF8FC16 for ; Tue, 22 Feb 2011 08:46:40 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id 4330681F52 for ; Tue, 22 Feb 2011 09:31:33 +0100 (CET) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id nufZ5MhK5TeM for ; Tue, 22 Feb 2011 09:31:31 +0100 (CET) Received: from danger-mbp.local (59576.ba.3pp.slovanet.sk [84.16.39.226]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.syscare.sk (Postfix) with ESMTPSA id 3A65081F45 for ; Tue, 22 Feb 2011 09:31:31 +0100 (CET) Message-ID: <4D637462.7000807@FreeBSD.org> Date: Tue, 22 Feb 2011 09:31:30 +0100 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15pre) Gecko/20110221 Lanikai/3.1.9pre MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4D6323D9.5090500@dougbarton.us> In-Reply-To: <4D6323D9.5090500@dougbarton.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Problem with etc/periodic/daily/310.accounting X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 08:46:41 -0000 On 22.2.2011 3:47, Doug Barton wrote: > I was looking over etc/periodic/daily/310.accounting on a system that is > very tight on space in /var, and I think that at minimum there is a > race, and at best there is a pretty serious inefficiency. > > Right now after rotating the old logs the script does this: > > cp -pf acct acct.0 || rc=3 > sa -s $daily_accounting_flags || rc=3 > > case "$daily_accounting_compress" in > [Yy][Ee][Ss]) > gzip -f acct.0 || rc=3;; > esac > > To start with, the cp is a problem on a space-constrained system > especially when the log is very large. However I think that doing it > this way also introduces a race where events that are logged between the > cp and the sa run are not backed up in acct.0. ITSM that the proper > procedure is: > > mv acct acct.0 || rc=3 I think you should at least `touch acct' here. > case "$daily_accounting_compress" in > [Yy][Ee][Ss]) > gzip --keep -f acct.0 || rc=3;; > esac > > sa -s $daily_accounting_flags acct.0 && unlink acct.0 || rc=3 > > Can anyone see why that would be wrong? If there is no objection, I'll > be committing the attached patch. > > > Doug -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 10:12:22 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36B5C106567A for ; Tue, 22 Feb 2011 10:12:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id A2C6E8FC18 for ; Tue, 22 Feb 2011 10:12:21 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p1MACG4A084556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Feb 2011 12:12:16 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p1MACGKi048553; Tue, 22 Feb 2011 12:12:16 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p1MACGLt048552; Tue, 22 Feb 2011 12:12:16 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Feb 2011 12:12:16 +0200 From: Kostik Belousov To: Yuri Message-ID: <20110222101216.GZ78089@deviant.kiev.zoral.com.ua> References: <4D62F267.3000706@rawbw.com> <20110221233817.GA4792@britannica.bec.de> <4D62FC28.9040300@rawbw.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iiKkCP5ouIvP2yCm" Content-Disposition: inline In-Reply-To: <4D62FC28.9040300@rawbw.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD ABI? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 10:12:22 -0000 --iiKkCP5ouIvP2yCm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 21, 2011 at 03:58:32PM -0800, Yuri wrote: > On 02/21/2011 15:38, Joerg Sonnenberger wrote: > >That's a major difference. The Linux people decided a while ago that > >stack alignment should be 16 Byte. GCC effectively forces that down > >everyone's throat because until at least GCC 4.2 or 4.3, it can't > >correctly realign the stack and just fails miserable. I would be > >surprised if it was a conscious decision for the Solaris either. > > =20 >=20 > I filed gcc PR asking gcc to revert their behavior back to prescribed by= =20 > documentation: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D47842 The i386 ABI was de-facto changed to require 16-byte stack alignment. The change is reasonable, both due to modern CPU cache behaviour, and to not put a block on the usage of the new CPU features (SSE instructions sets). There was a combination of bugs in gcc/glibc/bsd libc etc that made this not a reliable feature. I think there is no point of moving back to 4-byte alignment. --iiKkCP5ouIvP2yCm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1jjAAACgkQC3+MBN1Mb4gguACg4cYjUsd8KOW6vwkCkF23sQ9O 0KYAn0oJH3NtGICNHgCjw1UqTEB0oAP7 =jqiR -----END PGP SIGNATURE----- --iiKkCP5ouIvP2yCm-- From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 11:31:37 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99DEE106564A for ; Tue, 22 Feb 2011 11:31:37 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5F6E28FC0A for ; Tue, 22 Feb 2011 11:31:37 +0000 (UTC) Received: by yxl31 with SMTP id 31so938923yxl.13 for ; Tue, 22 Feb 2011 03:31:36 -0800 (PST) Received: by 10.90.50.4 with SMTP id x4mr3444897agx.90.1298374296401; Tue, 22 Feb 2011 03:31:36 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id 37sm433272anr.24.2011.02.22.03.31.35 (version=SSLv3 cipher=OTHER); Tue, 22 Feb 2011 03:31:35 -0800 (PST) Message-ID: <4D639E96.70902@my.gd> Date: Tue, 22 Feb 2011 12:31:34 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: LAGG - interface comes up but no laggports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 11:31:37 -0000 Hello list, I've been having this odd problem with a lagg interface for some time now... I have 2 boxes at home, a NAS running 8.1-RELEASE and a win7 workstation. I recently purchased 2 intel dual port NICs and gifted my machines one each. My problem is that on the FreeBSD box, the lagg interface is created correctly, but the NIC's ports aren't added to it. loader.conf --- # Up a bit our intel cards parameters hw.em.txd=4096 hw.em.xxd=4096 hw.em.tx_int_delay=512 hw.em.rx_int_delay=512 hw.em.tx_abs_int_delay=1024 hw.em.rx_abs_int_delay=1024 rc.conf --- # LINK AGGREG ifconfig_em0="polling mtu 9014 up" ifconfig_em1="polling mtu 9014 up" cloned_interfaces="lagg0" ifconfig_lagg0="laggproto failover laggport em0 laggport em1" ipv4_addrs_lagg0="192.168.1.3/29" ifconfig_lagg0="inet6 fe80::3/64" lagg0 interface after boot --- lagg0: flags=8843 metric 0 mtu 1500 ether 00:00:00:00:00:00 inet6 fe80::3%lagg0 prefixlen 64 scopeid 0x5 inet 192.168.1.3 netmask 0xfffffff8 broadcast 192.168.1.7 nd6 options=3 media: Ethernet autoselect status: no carrier laggproto failover lagg0 interface after "ifconfig lagg0 laggport em0 laggport em1" manually --- lagg0: flags=8843 metric 0 mtu 9014 options=19b ether 00:15:17:37:17:e6 inet6 fe80::3%lagg0 prefixlen 64 scopeid 0x5 inet 192.168.1.3 netmask 0xfffffff8 broadcast 192.168.1.7 nd6 options=3 media: Ethernet autoselect status: active laggproto failover laggport: em1 flags=0<> laggport: em0 flags=5 pciconf -lcvb --- em0@pci0:1:0:0: class=0x020000 card=0x135e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfe7a0000, size 131072, enabled bar [14] = type Memory, range 32, base 0xfe780000, size 131072, enabled bar [18] = type I/O Port, range 32, base 0xa880, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x4(x4) em1@pci0:1:0:1: class=0x020000 card=0x135e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfe7e0000, size 131072, enabled bar [14] = type Memory, range 32, base 0xfe7c0000, size 131072, enabled bar [18] = type I/O Port, range 32, base 0xac00, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x4(x4) Now, this is not such a BIG concern because this lagg is only used between my win7 workstation and the NAS. What bothers me is that we have other PF boxes at work, which I also configured, and for which I do not have this problem. I should note that this is a direct connection, there is no switch between the 2 machines. Also, notice I set a 9014 MTU on my physical ports: em0: flags=8843 metric 0 mtu 9014 options=19b ether 00:15:17:37:17:e6 inet6 fe80::215:17ff:fe37:17e6%em0 prefixlen 64 scopeid 0x1 nd6 options=3 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 9014 options=19b ether 00:15:17:37:17:e7 inet6 fe80::215:17ff:fe37:17e7%em1 prefixlen 64 scopeid 0x2 nd6 options=3 media: Ethernet autoselect status: no carrier Yet the lagg interface itself reports a MTU of 1500. Anyone ever run into this problem before ? From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 12:39:27 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C217F106564A for ; Tue, 22 Feb 2011 12:39:27 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 842308FC1E for ; Tue, 22 Feb 2011 12:39:27 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:794d:2247:36f9:4086] (unknown [IPv6:2001:7b8:3a7:0:794d:2247:36f9:4086]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 66D8F5C59; Tue, 22 Feb 2011 13:39:26 +0100 (CET) Message-ID: <4D63AE83.5040007@FreeBSD.org> Date: Tue, 22 Feb 2011 13:39:31 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.15pre) Gecko/20110221 Lanikai/3.1.9pre MIME-Version: 1.0 To: gnehzuil References: <4D63661D.2090205@gmail.com> In-Reply-To: <4D63661D.2090205@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: buildkernel error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 12:39:27 -0000 On 2011-02-22 08:30, gnehzuil wrote: > I updated my kernel source code and try to make a new kernel using make > buildkernel command. But I got an error as follow: ... > ld:/usr/src/sys/conf/ldscript.i386:66: syntax error Your /usr/bin/ld is still at version 2.15, which is too old to parse the kernel linker script. In this case, first run "make buildworld", or at least "make kernel-toolchain" before you attempt to build any kernels. From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 12:45:48 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FA37106564A for ; Tue, 22 Feb 2011 12:45:48 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1B4858FC17 for ; Tue, 22 Feb 2011 12:45:47 +0000 (UTC) Received: by fxm19 with SMTP id 19so3611845fxm.13 for ; Tue, 22 Feb 2011 04:45:47 -0800 (PST) Received: by 10.223.79.74 with SMTP id o10mr3358039fak.63.1298377143339; Tue, 22 Feb 2011 04:19:03 -0800 (PST) Received: from jessie.localnet (p5B2ECE97.dip0.t-ipconnect.de [91.46.206.151]) by mx.google.com with ESMTPS id z1sm2490532fau.21.2011.02.22.04.19.01 (version=SSLv3 cipher=OTHER); Tue, 22 Feb 2011 04:19:02 -0800 (PST) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Damien Fleuriot Date: Tue, 22 Feb 2011 13:18:53 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.32-28-generic; KDE/4.4.5; i686; ; ) References: <4D639E96.70902@my.gd> In-Reply-To: <4D639E96.70902@my.gd> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102221318.53376.bschmidt@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: LAGG - interface comes up but no laggports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bschmidt@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 12:45:48 -0000 On Tuesday, February 22, 2011 12:31:34 Damien Fleuriot wrote: > rc.conf > --- > # LINK AGGREG > ifconfig_lagg0="laggproto failover laggport em0 laggport em1" > ipv4_addrs_lagg0="192.168.1.3/29" > ifconfig_lagg0="inet6 fe80::3/64" You are overwriting the variable, you have to use some alternative or move everything into one statement. -- Bernhard From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 07:28:38 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E2761065673 for ; Tue, 22 Feb 2011 07:28:38 +0000 (UTC) (envelope-from dougb@dougbarton.us) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 9FB308FC12 for ; Tue, 22 Feb 2011 07:28:37 +0000 (UTC) Received: (qmail 699 invoked by uid 399); 22 Feb 2011 07:28:32 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 22 Feb 2011 07:28:32 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D63659E.6010305@dougbarton.us> Date: Mon, 21 Feb 2011 23:28:30 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org References: <4D6323D9.5090500@dougbarton.us> In-Reply-To: <4D6323D9.5090500@dougbarton.us> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: multipart/mixed; boundary="------------080201010908080508080504" X-Mailman-Approved-At: Tue, 22 Feb 2011 12:46:23 +0000 Cc: Subject: Re: Problem with etc/periodic/daily/310.accounting X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 07:28:38 -0000 This is a multi-part message in MIME format. --------------080201010908080508080504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ignore my last. The problem is that if /var/account/acct disappears then accounting stops. The attached is better, albeit more complicated. It also has the pleasant side effect of cleaning up /etc/rc.d/accounting a bit. I've confirmed that with this patch nothing is lost while the file is being switched: unlink - root pts/2 0.006 secs Mon Feb 21 23:23 sa - root pts/2 0.014 secs Mon Feb 21 23:23 gzip - root pts/2 0.014 secs Mon Feb 21 23:23 sh - root pts/2 0.099 secs Mon Feb 21 23:23 unlink - root pts/2 0.006 secs Mon Feb 21 23:23 accton - root pts/2 0.006 secs Mon Feb 21 23:23 ln - root pts/2 0.006 secs Mon Feb 21 23:23 mv - root pts/2 0.007 secs Mon Feb 21 23:23 accton - root pts/2 0.011 secs Mon Feb 21 23:23 Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ --------------080201010908080508080504 Content-Type: text/plain; name="310.accounting-2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="310.accounting-2.diff" Index: periodic/daily/310.accounting =================================================================== --- periodic/daily/310.accounting (revision 218938) +++ periodic/daily/310.accounting (working copy) @@ -41,13 +41,16 @@ m=$n n=$(($n - 1)) done - cp -pf acct acct.0 || rc=3 - sa -s $daily_accounting_flags || rc=3 + /etc/rc.d/accounting rotate_log || rc=3 + case "$daily_accounting_compress" in [Yy][Ee][Ss]) - gzip -f acct.0 || rc=3;; + gzip --keep -f acct.0 || rc=3;; esac + + sa -s $daily_accounting_flags /var/account/acct.0 && + unlink acct.0 || rc=3 fi;; *) rc=0;; Index: rc.d/accounting =================================================================== --- rc.d/accounting (revision 218938) +++ rc.d/accounting (working copy) @@ -14,30 +14,34 @@ rcvar=`set_rcvar` accounting_command="/usr/sbin/accton" accounting_file="/var/account/acct" + +extra_commands="rotate_log" + start_cmd="accounting_start" stop_cmd="accounting_stop" +rotate_log_cmd="accounting_rotate_log" accounting_start() { local _dir - _dir=`dirname "$accounting_file"` - if [ ! -d `dirname "$_dir"` ]; then + _dir="${accounting_file%/*}" + if [ ! -d "$_dir" ]; then if ! mkdir -p "$_dir"; then - warn "Could not create $_dir." - return 1 + err 1 "Could not create $_dir." fi fi + if [ ! -e "$accounting_file" ]; then + echo -n "Creating accounting file ${accounting_file}" touch "$accounting_file" + echo '.' fi + chmod 644 "$accounting_file" - if [ ! -f ${accounting_file} ]; then - echo "Creating accounting file ${accounting_file}" - ( umask 022 ; > ${accounting_file} ) - fi - echo "Turning on accounting." + echo -n 'Turning on accounting' ${accounting_command} ${accounting_file} + echo '.' } accounting_stop() @@ -46,5 +50,26 @@ ${accounting_command} } +accounting_rotate_log() +{ + local _dir _file + + _dir="${accounting_file%/*}" + cd $_dir + + if checkyesno accounting_enable; then + _file=`mktemp newacct-XXXXX` + ${accounting_command} /var/account/${_file} + fi + + mv ${accounting_file} ${accounting_file}.0 + + if checkyesno accounting_enable; then + ln $_file ${accounting_file##*/} + ${accounting_command} ${accounting_file} + unlink $_file + fi +} + load_rc_config $name run_rc_command "$1" --------------080201010908080508080504-- From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 08:27:20 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00F73106564A; Tue, 22 Feb 2011 08:27:20 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id A2A7A8FC14; Tue, 22 Feb 2011 08:27:19 +0000 (UTC) Received: from outgoing.leidinger.net (p5B32E836.dip.t-dialin.net [91.50.232.54]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 9F035844012; Tue, 22 Feb 2011 09:27:14 +0100 (CET) Received: from webmail.leidinger.net (unknown [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 11D6A2A94; Tue, 22 Feb 2011 09:27:09 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p1M8QgxQ053923; Tue, 22 Feb 2011 09:26:42 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 22 Feb 2011 09:26:41 +0100 Message-ID: <20110222092641.18945u7safu272o8@webmail.leidinger.net> Date: Tue, 22 Feb 2011 09:26:41 +0100 From: Alexander Leidinger To: Juergen Lock References: <20110129201000.GA10774@triton8.kn-bremen.de> <20110129205105.GI2518@deviant.kiev.zoral.com.ua> <20110129235448.GA15788@triton8.kn-bremen.de> <20110218205542.GA45210@triton8.kn-bremen.de> <20110219175744.GH78089@deviant.kiev.zoral.com.ua> <20110221183611.GA38073@triton8.kn-bremen.de> In-Reply-To: <20110221183611.GA38073@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 9F035844012.A5D04 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=1.351, required 6, autolearn=disabled, RDNS_NONE 1.27, TW_DV 0.08) X-EBL-MailScanner-SpamScore: s X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1298968034.97497@/g2zsUmTPOKP+C+wn9KY2Q X-EBL-Spam-Status: No X-Mailman-Approved-At: Tue, 22 Feb 2011 12:46:38 +0000 Cc: Kostik Belousov , freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org Subject: Re: Can vm_mmap()/vm_map_remove() be called with giant held? (linuxolator dvb patches) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 08:27:20 -0000 Quoting Juergen Lock (from Mon, 21 Feb 2011 19:36:11 +0100): > And here comes the patch for head: linux_dvb.h is still GPLed (not taking into account that there are voices which tell that interface descriptions are not copyrightable or something like this). As already told this is a no-go, the linuxulator is BSD licensed. Bye, Alexander. > Index: src/sys/compat/linux/linux_dvb.h > @@ -0,0 +1,63 @@ > +/* > + * Extracted from , which is: > + * > + * Copyright (C) 2000 Marcus Metzler > + * Ralph Metzler > + * Holger Waechtler > + * Andre Draszik > + * for convergence integrated media GmbH > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public License > + * as published by the Free Software Foundation; either version 2.1 > + * of the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA > 02111-1307, USA. > + * > + */ Bye, Alexander. -- Sight is a faculty; seeing is an art. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 11:40:25 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37824106566C; Tue, 22 Feb 2011 11:40:25 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id E2FBD8FC0C; Tue, 22 Feb 2011 11:40:24 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 0D6DA1E000C7; Tue, 22 Feb 2011 12:40:24 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id p1MBbsg7064838; Tue, 22 Feb 2011 12:37:54 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id p1MBbsMs064837; Tue, 22 Feb 2011 12:37:54 +0100 (CET) (envelope-from nox) From: Juergen Lock Date: Tue, 22 Feb 2011 12:37:53 +0100 To: Alexander Leidinger Message-ID: <20110222113753.GA62966@triton8.kn-bremen.de> References: <20110129201000.GA10774@triton8.kn-bremen.de> <20110129205105.GI2518@deviant.kiev.zoral.com.ua> <20110129235448.GA15788@triton8.kn-bremen.de> <20110218205542.GA45210@triton8.kn-bremen.de> <20110219175744.GH78089@deviant.kiev.zoral.com.ua> <20110221183611.GA38073@triton8.kn-bremen.de> <20110222092641.18945u7safu272o8@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110222092641.18945u7safu272o8@webmail.leidinger.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Tue, 22 Feb 2011 12:46:50 +0000 Cc: Kostik Belousov , freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org, Juergen Lock Subject: Re: Can vm_mmap()/vm_map_remove() be called with giant held? (linuxolator dvb patches) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 11:40:25 -0000 On Tue, Feb 22, 2011 at 09:26:41AM +0100, Alexander Leidinger wrote: > Quoting Juergen Lock (from Mon, 21 Feb 2011 > 19:36:11 +0100): > > > And here comes the patch for head: > > linux_dvb.h is still GPLed (not taking into account that there are > voices which tell that interface descriptions are not copyrightable or > something like this). As already told this is a no-go, the linuxulator > is BSD licensed. Right I should have mentioned your concerns. (I said it wouldn't really matter since the linuxolator already is a kld and the header file from which I took the definitions is LGPL'd not GPL'd [1], to which I didn't see an answer.) Cheers, Juergen [1] probably just for this reason. I prefer the BSDL too but if we bug the Linux guys about this I fear we'd only come across as nitpickers or people that `can't get enough'... :/ --- Oooh and now I also just saw this in the LGPL: [2] [...] 3. Object Code Incorporating Material from Library Header Files. The object code form of an Application may incorporate material from a header file that is part of the Library. You may convey such object code under terms of your choice, provided that, if the incorporated material is not limited to numerical parameters, data structure layouts and accessors, or small macros, inline functions and templates (ten or fewer lines in length), you do both of the following: a) Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License. b) Accompany the object code with a copy of the GNU GPL and this license document. [...] ...so it seems the LGPL in linux_dvb.h wouldn't even apply to the rest of the linuxolator or any other of our code anyway since `the incorporated material [the header] in fact _is_ limited to numerical parameters, data structure layouts and accessors, or small macros, inline functions and templates (ten or fewer lines in length)'. [2] http://www.gnu.org/copyleft/lesser.html From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 12:51:09 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3D611065673 for ; Tue, 22 Feb 2011 12:51:09 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 787158FC12 for ; Tue, 22 Feb 2011 12:51:09 +0000 (UTC) Received: by ewy28 with SMTP id 28so93620ewy.13 for ; Tue, 22 Feb 2011 04:51:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7YJTUiTRTenm+aBnqxEngivhK8oh2SKnUhzJInx0Tcc=; b=jrlMZKgQkRvbRbSZT92c9UWY8iSBvb+YQWJqRk7zdyOfAaVEbiDT5ZM2JgNEgOoHjw DqT79U6WpAYeRzYmTir5eNHHC+JAi3pmHOofTkJLio3fihroE4i++6dU8pMt9vIfaRpw LX69o8gZs2iyFXq/uV26RS/7I5bv1/55XnXrU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=u2lR1SrEVL9vehS/RbviHB69nl+YngoXJLnRGR6QxO3JvDqLHkCcZXCY7fGzYZcsI5 Pe7ViqWRkVxPX3Azv+3Ss5VaS/D8ir0cUOsxO1p5WCCYjqCL8/Ueb08BFMoy8QwMscUB NJY2cq/jn96cTs22AILNA3xgvr9LQkiUt0GEY= MIME-Version: 1.0 Received: by 10.213.7.138 with SMTP id d10mr2949769ebd.55.1298379068230; Tue, 22 Feb 2011 04:51:08 -0800 (PST) Received: by 10.213.20.135 with HTTP; Tue, 22 Feb 2011 04:51:08 -0800 (PST) In-Reply-To: <4D639E96.70902@my.gd> References: <4D639E96.70902@my.gd> Date: Tue, 22 Feb 2011 07:51:08 -0500 Message-ID: From: Ryan Stone To: Damien Fleuriot Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: LAGG - interface comes up but no laggports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 12:51:10 -0000 On Tue, Feb 22, 2011 at 6:31 AM, Damien Fleuriot wrote: > ifconfig_lagg0="laggproto failover laggport em0 laggport em1" > ipv4_addrs_lagg0="192.168.1.3/29" > ifconfig_lagg0="inet6 fe80::3/64" You're setting ifconfig_lagg0 twice, so the first setting is being discarded. Off-hand I'm not sure how you're supposed to configure ipv6 addresses. There's nothing in the man page about an ipv6_addrs_lagg0 variable but that would be the obvious thing to try, From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 12:51:06 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 485AF1065673; Tue, 22 Feb 2011 12:51:06 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id CE9108FC0A; Tue, 22 Feb 2011 12:51:05 +0000 (UTC) Received: from outgoing.leidinger.net (p5B32E836.dip.t-dialin.net [91.50.232.54]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id CB373844012; Tue, 22 Feb 2011 13:51:00 +0100 (CET) Received: from webmail.leidinger.net (unknown [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 41B5F2AAF; Tue, 22 Feb 2011 13:50:57 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p1MCoVMN013930; Tue, 22 Feb 2011 13:50:31 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 22 Feb 2011 13:50:31 +0100 Message-ID: <20110222135031.31453ocol73fg3k0@webmail.leidinger.net> Date: Tue, 22 Feb 2011 13:50:31 +0100 From: Alexander Leidinger To: Juergen Lock References: <20110129201000.GA10774@triton8.kn-bremen.de> <20110129205105.GI2518@deviant.kiev.zoral.com.ua> <20110129235448.GA15788@triton8.kn-bremen.de> <20110218205542.GA45210@triton8.kn-bremen.de> <20110219175744.GH78089@deviant.kiev.zoral.com.ua> <20110221183611.GA38073@triton8.kn-bremen.de> <20110222092641.18945u7safu272o8@webmail.leidinger.net> <20110222113753.GA62966@triton8.kn-bremen.de> In-Reply-To: <20110222113753.GA62966@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: CB373844012.A5B59 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=1.351, required 6, autolearn=disabled, RDNS_NONE 1.27, TW_DV 0.08) X-EBL-MailScanner-SpamScore: s X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1298983862.21466@tbiyYnFuh3H2gM+MJL+Ong X-EBL-Spam-Status: No X-Mailman-Approved-At: Tue, 22 Feb 2011 12:58:04 +0000 Cc: Kostik Belousov , freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org Subject: Re: Can vm_mmap()/vm_map_remove() be called with giant held? (linuxolator dvb patches) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 12:51:06 -0000 Quoting Juergen Lock (from Tue, 22 Feb 2011 12:37:53 +0100): > On Tue, Feb 22, 2011 at 09:26:41AM +0100, Alexander Leidinger wrote: >> Quoting Juergen Lock (from Mon, 21 Feb 2011 >> 19:36:11 +0100): >> >> > And here comes the patch for head: >> >> linux_dvb.h is still GPLed (not taking into account that there are >> voices which tell that interface descriptions are not copyrightable or >> something like this). As already told this is a no-go, the linuxulator >> is BSD licensed. > > Right I should have mentioned your concerns. (I said it wouldn't > really matter since the linuxolator already is a kld and the header LThe lnuxulator can be included into the kernel (think about an embedded system where the vendor does not want to give the source). The authors of the v4l and v4l2 headers where contacted to get their OK to license the headers within the BSDL (and we got their permission), and I make the suggestion again that you do the same for the dvb header parts you took. If you do not get their OK, my next suggestion is to talk to core about it (if the LGPLed code gets committed without a note that core is OK, I will make a call to core anyway (I will not ask to back it out, it's up to core then to ask for a backout or not), so it may be better to ask before committing). > file from which I took the definitions is LGPL'd not GPL'd [1], to > which I didn't see an answer.) IMO the first L does not matter if the rest contains GPL. I'm really happy that you take the time to take care about DVB compatibility, and I would like to see the code in FreeBSD, but the linuxulator is (L)GPL free and changing this is a step backward. Bye, Alexander. -- In Newark the laundromats are open 24 hours a day! http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 13:17:49 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 674971065670 for ; Tue, 22 Feb 2011 13:17:49 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2B3478FC18 for ; Tue, 22 Feb 2011 13:17:48 +0000 (UTC) Received: by gxk7 with SMTP id 7so1009666gxk.13 for ; Tue, 22 Feb 2011 05:17:48 -0800 (PST) Received: by 10.91.77.15 with SMTP id e15mr3512331agl.73.1298380668337; Tue, 22 Feb 2011 05:17:48 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id e24sm1363226ana.2.2011.02.22.05.17.47 (version=SSLv3 cipher=OTHER); Tue, 22 Feb 2011 05:17:47 -0800 (PST) Message-ID: <4D63B77A.2060509@my.gd> Date: Tue, 22 Feb 2011 14:17:46 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4D639E96.70902@my.gd> <201102221318.53376.bschmidt@freebsd.org> In-Reply-To: <201102221318.53376.bschmidt@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: LAGG - interface comes up but no laggports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 13:17:49 -0000 On 2/22/11 1:18 PM, Bernhard Schmidt wrote: > On Tuesday, February 22, 2011 12:31:34 Damien Fleuriot wrote: >> rc.conf >> --- >> # LINK AGGREG >> ifconfig_lagg0="laggproto failover laggport em0 laggport em1" >> ipv4_addrs_lagg0="192.168.1.3/29" >> ifconfig_lagg0="inet6 fe80::3/64" > > You are overwriting the variable, you have to use some alternative or > move everything into one statement. > Good call, it now works correctly: lagg0: flags=8843 metric 0 mtu 9014 options=19b ether 00:15:17:37:17:e6 inet6 fe80::215:17ff:fe37:17e6%lagg0 prefixlen 64 scopeid 0x5 inet 192.168.1.3 netmask 0xfffffff8 broadcast 192.168.1.7 nd6 options=3 media: Ethernet autoselect status: active laggproto failover laggport: em1 flags=0<> laggport: em0 flags=5 You'll notice that using ipv6_addrs didn't work, as the interface is using an automatic address instead of fe80::3/64 which I tried to set. I suppose I could use the crontab for this, @reboot ifconfig lagg0 inet6 fe80::3/64 , or perhaps rc.local Thanks for the help everyone, this was becoming frustrating. From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 13:27:36 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 055B4106564A for ; Tue, 22 Feb 2011 13:27:36 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 93AD88FC0C for ; Tue, 22 Feb 2011 13:27:34 +0000 (UTC) Received: by fxm19 with SMTP id 19so3649176fxm.13 for ; Tue, 22 Feb 2011 05:27:34 -0800 (PST) Received: by 10.223.87.78 with SMTP id v14mr3410890fal.80.1298381240061; Tue, 22 Feb 2011 05:27:20 -0800 (PST) Received: from jessie.localnet (p5B2ECE97.dip0.t-ipconnect.de [91.46.206.151]) by mx.google.com with ESMTPS id n2sm589687fam.28.2011.02.22.05.27.18 (version=SSLv3 cipher=OTHER); Tue, 22 Feb 2011 05:27:18 -0800 (PST) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Damien Fleuriot Date: Tue, 22 Feb 2011 14:27:09 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.32-28-generic; KDE/4.4.5; i686; ; ) References: <4D639E96.70902@my.gd> <201102221318.53376.bschmidt@freebsd.org> <4D63B77A.2060509@my.gd> In-Reply-To: <4D63B77A.2060509@my.gd> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102221427.09817.bschmidt@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: LAGG - interface comes up but no laggports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bschmidt@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 13:27:36 -0000 On Tuesday, February 22, 2011 14:17:46 Damien Fleuriot wrote: > On 2/22/11 1:18 PM, Bernhard Schmidt wrote: > > On Tuesday, February 22, 2011 12:31:34 Damien Fleuriot wrote: > >> rc.conf > >> --- > >> # LINK AGGREG > >> ifconfig_lagg0="laggproto failover laggport em0 laggport em1" > >> ipv4_addrs_lagg0="192.168.1.3/29" > >> ifconfig_lagg0="inet6 fe80::3/64" > > > > You are overwriting the variable, you have to use some alternative > > or move everything into one statement. > > Good call, it now works correctly: > lagg0: flags=8843 metric 0 > mtu 9014 > options=19b > ether 00:15:17:37:17:e6 > inet6 fe80::215:17ff:fe37:17e6%lagg0 prefixlen 64 scopeid 0x5 > inet 192.168.1.3 netmask 0xfffffff8 broadcast 192.168.1.7 > nd6 options=3 > media: Ethernet autoselect > status: active > laggproto failover > laggport: em1 flags=0<> > laggport: em0 flags=5 > > > You'll notice that using ipv6_addrs didn't work, as the interface is > using an automatic address instead of fe80::3/64 which I tried to > set. > > I suppose I could use the crontab for this, @reboot ifconfig lagg0 > inet6 fe80::3/64 , or perhaps rc.local I'm using ipv6_ifconfig_XXX0[_aliasX] to assign IPv6 addresses, might be worth a try? I don't see ipv6_addrs_XXX0 to be even defined somewhere. -- Bernhard From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 13:28:58 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5313106566C for ; Tue, 22 Feb 2011 13:28:58 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 79D028FC0A for ; Tue, 22 Feb 2011 13:28:58 +0000 (UTC) Received: by gyh4 with SMTP id 4so1530771gyh.13 for ; Tue, 22 Feb 2011 05:28:57 -0800 (PST) Received: by 10.91.96.2 with SMTP id y2mr3514224agl.140.1298381337691; Tue, 22 Feb 2011 05:28:57 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id c39sm2818730anc.27.2011.02.22.05.28.56 (version=SSLv3 cipher=OTHER); Tue, 22 Feb 2011 05:28:57 -0800 (PST) Message-ID: <4D63BA17.60003@my.gd> Date: Tue, 22 Feb 2011 14:28:55 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ryan Stone References: <4D639E96.70902@my.gd> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: LAGG - interface comes up but no laggports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 13:28:58 -0000 On 2/22/11 1:51 PM, Ryan Stone wrote: > On Tue, Feb 22, 2011 at 6:31 AM, Damien Fleuriot wrote: >> ifconfig_lagg0="laggproto failover laggport em0 laggport em1" >> ipv4_addrs_lagg0="192.168.1.3/29" >> ifconfig_lagg0="inet6 fe80::3/64" > > You're setting ifconfig_lagg0 twice, so the first setting is being > discarded. Off-hand I'm not sure how you're supposed to configure > ipv6 addresses. There's nothing in the man page about an > ipv6_addrs_lagg0 variable but that would be the obvious thing to try, ipv6_addrs_XXX doesn't do the trick, however this one does: ipv6_ifconfig_lagg0="fe80::3/64" lagg0: flags=8843 metric 0 mtu 9014 options=19b ether 00:15:17:37:17:e6 inet6 fe80::215:17ff:fe37:17e6%lagg0 prefixlen 64 scopeid 0x5 inet 192.168.1.3 netmask 0xfffffff8 broadcast 192.168.1.7 inet6 fe80::3%lagg0 prefixlen 64 scopeid 0x5 nd6 options=3 media: Ethernet autoselect status: active laggproto failover laggport: em1 flags=0<> laggport: em0 flags=5 For a reason that eludes me, the interface still insists on getting an automatic link local address, but I'll look into this ;) From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 13:29:43 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78D1D106567A; Tue, 22 Feb 2011 13:29:43 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 27B308FC16; Tue, 22 Feb 2011 13:29:42 +0000 (UTC) Received: by gxk7 with SMTP id 7so1014103gxk.13 for ; Tue, 22 Feb 2011 05:29:42 -0800 (PST) Received: by 10.100.137.14 with SMTP id k14mr1212225and.190.1298381382377; Tue, 22 Feb 2011 05:29:42 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id i10sm558637anh.12.2011.02.22.05.29.41 (version=SSLv3 cipher=OTHER); Tue, 22 Feb 2011 05:29:41 -0800 (PST) Message-ID: <4D63BA44.4080404@my.gd> Date: Tue, 22 Feb 2011 14:29:40 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: bschmidt@freebsd.org References: <4D639E96.70902@my.gd> <201102221318.53376.bschmidt@freebsd.org> <4D63B77A.2060509@my.gd> <201102221427.09817.bschmidt@freebsd.org> In-Reply-To: <201102221427.09817.bschmidt@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: LAGG - interface comes up but no laggports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 13:29:43 -0000 On 2/22/11 2:27 PM, Bernhard Schmidt wrote: > On Tuesday, February 22, 2011 14:17:46 Damien Fleuriot wrote: >> On 2/22/11 1:18 PM, Bernhard Schmidt wrote: >>> On Tuesday, February 22, 2011 12:31:34 Damien Fleuriot wrote: >>>> rc.conf >>>> --- >>>> # LINK AGGREG >>>> ifconfig_lagg0="laggproto failover laggport em0 laggport em1" >>>> ipv4_addrs_lagg0="192.168.1.3/29" >>>> ifconfig_lagg0="inet6 fe80::3/64" >>> >>> You are overwriting the variable, you have to use some alternative >>> or move everything into one statement. >> >> Good call, it now works correctly: >> lagg0: flags=8843 metric 0 >> mtu 9014 >> options=19b >> ether 00:15:17:37:17:e6 >> inet6 fe80::215:17ff:fe37:17e6%lagg0 prefixlen 64 scopeid 0x5 >> inet 192.168.1.3 netmask 0xfffffff8 broadcast 192.168.1.7 >> nd6 options=3 >> media: Ethernet autoselect >> status: active >> laggproto failover >> laggport: em1 flags=0<> >> laggport: em0 flags=5 >> >> >> You'll notice that using ipv6_addrs didn't work, as the interface is >> using an automatic address instead of fe80::3/64 which I tried to >> set. >> >> I suppose I could use the crontab for this, @reboot ifconfig lagg0 >> inet6 fe80::3/64 , or perhaps rc.local > > I'm using ipv6_ifconfig_XXX0[_aliasX] to assign IPv6 addresses, might be > worth a try? I don't see ipv6_addrs_XXX0 to be even defined somewhere. > Indeed I was just tryng that and waiting for the reboot, works fine. From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 14:11:12 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id C049A1065675; Tue, 22 Feb 2011 14:11:12 +0000 (UTC) Date: Tue, 22 Feb 2011 14:11:12 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20110222141112.GA98964@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: seeking into /dev/{null,zero} X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 14:11:12 -0000 hi there, there's a PR [1] regarding seeking into /dev/null and /dev/zero. i just wanted to ask what the overall opinion is on this matter. technically it's quite easy to seek into those files upon fwrite(3) and fread(3). the point is, if the file position should be repositioned according the the amount of bytes read or written. the zero(4) and null(4) manual pages claim that both devices act as "ordinary" files. right now only reading from /dev/zero will seek into the file. writing to /dev/zero and reading/writing to /dev/null will *not* adjust the file position. cheers. alex [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/152485 ps: i might also be worth thinking about turning null(4) and zero(4) into a single manual page, since their contents seem quite similar. -- a13x From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 15:57:15 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8628106566B for ; Tue, 22 Feb 2011 15:57:15 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5B1308FC15 for ; Tue, 22 Feb 2011 15:57:15 +0000 (UTC) Received: by wyb32 with SMTP id 32so3099396wyb.13 for ; Tue, 22 Feb 2011 07:57:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=b6UYwQKvkAkD/dLj7CD1EEe2xSY6uhELQfEnhaOQgF4=; b=nseNgShalA730rXTETi1fAqgug2/sR2q23WqRCGkozL7al43YnfD5W10A32R5Gv749 7sCXQ1iQqj9UfyPw2pQ95xSBeXL2FoSECy8tYU9bebFrUf8b53tyS/BEG98SWP2BFAkE h2ji3hPlRVDy66ZrAh5S/oVBhrbTM6cs9TQd0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Y0sMofOLlLnnZiXdYB+xV6zxSIU6E1LmwHAvVnCxrtQ8+YfqKquS5v7M+WoBxOVejA TM43dGX5bOUpQPP7kyhMtVjXxdJc+N60s5RVMd8quW/mqI0iABgxwVJa2soDCG3Tou2i Z9YbUccLPjeVNvPa5ICfojKjxwtqd84reDfkQ= MIME-Version: 1.0 Received: by 10.216.46.193 with SMTP id r43mr3471081web.20.1298390234437; Tue, 22 Feb 2011 07:57:14 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.15.74 with HTTP; Tue, 22 Feb 2011 07:57:14 -0800 (PST) In-Reply-To: <4D63659E.6010305@dougbarton.us> References: <4D6323D9.5090500@dougbarton.us> <4D63659E.6010305@dougbarton.us> Date: Tue, 22 Feb 2011 07:57:14 -0800 X-Google-Sender-Auth: olAFOCiD_G_K05iB9IdGIsh8SmA Message-ID: From: Garrett Cooper To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Problem with etc/periodic/daily/310.accounting X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 15:57:15 -0000 On Mon, Feb 21, 2011 at 11:28 PM, Doug Barton wrote: > Ignore my last. > > The problem is that if /var/account/acct disappears then accounting stops= . > The attached is better, albeit more complicated. It also has the pleasant > side effect of cleaning up /etc/rc.d/accounting a bit. > > I've confirmed that with this patch nothing is lost while the file is bei= ng > switched: > > unlink =A0 - =A0 =A0root =A0 =A0 =A0 pts/2 =A0 0.006 secs Mon Feb 21 23:2= 3 > sa =A0 =A0 =A0 - =A0 =A0root =A0 =A0 =A0 pts/2 =A0 0.014 secs Mon Feb 21 = 23:23 > gzip =A0 =A0 - =A0 =A0root =A0 =A0 =A0 pts/2 =A0 0.014 secs Mon Feb 21 23= :23 > sh =A0 =A0 =A0 - =A0 =A0root =A0 =A0 =A0 pts/2 =A0 0.099 secs Mon Feb 21 = 23:23 > unlink =A0 - =A0 =A0root =A0 =A0 =A0 pts/2 =A0 0.006 secs Mon Feb 21 23:2= 3 > accton =A0 - =A0 =A0root =A0 =A0 =A0 pts/2 =A0 0.006 secs Mon Feb 21 23:2= 3 > ln =A0 =A0 =A0 - =A0 =A0root =A0 =A0 =A0 pts/2 =A0 0.006 secs Mon Feb 21 = 23:23 > mv =A0 =A0 =A0 - =A0 =A0root =A0 =A0 =A0 pts/2 =A0 0.007 secs Mon Feb 21 = 23:23 > accton =A0 - =A0 =A0root =A0 =A0 =A0 pts/2 =A0 0.011 secs Mon Feb 21 23:2= 3 Can accounting_file by provided by user input (doesn't look like it today, but just to be safe I thought I should check)? If so then the dirname should be restored. Example: $ foo=3D/a/b//////c $ echo ${foo%/*} /a/b///// $ dirname $foo /a/b Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 16:19:58 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD3E7106566C for ; Tue, 22 Feb 2011 16:19:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9E99F8FC16 for ; Tue, 22 Feb 2011 16:19:58 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5121B46B2D; Tue, 22 Feb 2011 11:19:58 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 877898A027; Tue, 22 Feb 2011 11:19:57 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 22 Feb 2011 09:37:53 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102220937.53075.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 22 Feb 2011 11:19:57 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Svatopluk Kraus Subject: Re: ichsmb - correct locking strategy? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 16:19:58 -0000 On Friday, February 18, 2011 9:10:47 am Svatopluk Kraus wrote: > Hi, > > I try to figure out locking strategy in FreeBSD and found 'ichsmb' > device. There is a mutex which protects smb bus (ichsmb device). For > example in ichsmb_readw() in sys/dev/ichsmb/ichsmb.c, the mutex is > locked and a command is written to bus, then unbounded (but with > timeout) sleep is done (mutex is unlocked during sleep). After sleep a > word is read from bus and the mutex is unlocked. > > 1. If an use of the device IS NOT serialized by layers around then > more calls to this function (or others) can be started or even done > before the first one is finished. The mutex don't protect sms bus. > > 2. If an use of the device IS serialized by layers around then the > mutex is useless. > > Moreover, I don't mension interrupt routine which uses the mutex and > smb bus too. > > Am I right? Or did I miss something? Hmm, the mutex could be useful if you have an smb controller with an interrupt handler (I think ichsmb or maybe intpm can support an interrupt handler) to prevent concurrent access to device registers. That is the purpose of the mutex at least. There is a separate locking layer in smbus itself in (see smbus_request_bus(), etc.). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 16:20:08 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 376B310656B0 for ; Tue, 22 Feb 2011 16:20:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5B8908FC23 for ; Tue, 22 Feb 2011 16:20:07 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1639446B03; Tue, 22 Feb 2011 11:20:07 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1B92F8A01D; Tue, 22 Feb 2011 11:20:06 -0500 (EST) From: John Baldwin To: Sergey Kandaurov Date: Tue, 22 Feb 2011 11:06:57 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D553027.5040606@gmail.com> <4D5E5476.5010107@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102221106.57115.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 22 Feb 2011 11:20:06 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org, venom Subject: Re: problem with build mcelog X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 16:20:08 -0000 On Friday, February 18, 2011 7:11:07 am Sergey Kandaurov wrote: > On 18 February 2011 14:13, venom wrote: > > On 02/11/2011 11:31 PM, John Baldwin wrote: > >> > >> On Friday, February 11, 2011 7:48:39 am venom wrote: > >>> > >>> Hello. > >>> > >>> i am trying build mcelog > >>> > >>> > >>> FreeBSD XXXX 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 #0: Fri Jan 14 > >>> 04:15:56 > >>> UTC 2011 root@freebsd:/usr/obj/usr/src/sys/GENERIC amd64 > >>> > >>> > >>> # fetch > >>> http://ftp2.pl.freebsd.org/pub/FreeBSD/distfiles/mcelog-1.0pre2.tar.gz > >>> # tar -xf mcelog-1.0pre2.tar.gz > >>> # cd mcelog-1.0pre2 > >>> # fetch http://people.freebsd.org/~jhb/mcelog/mcelog.patch > >>> # fetch http://people.freebsd.org/~jhb/mcelog/memstream.c > >> > >> Oops, I just updated mcelog.patch and it should work fine now. > >> > > > > |--- //depot/vendor/mcelog/tsc.c 2010-03-05 20:24:22.000000000 0000 > > |+++ //depot/projects/mcelog/tsc.c 2010-03-05 21:09:24.000000000 0000 > > -------------------------- > > Patching file tsc.c using Plan A... > > Hunk #1 succeeded at 15. > > Hunk #2 succeeded at 52. > > Hunk #3 succeeded at 75. > > Hunk #4 succeeded at 156. > > done > > 12:12:46 ~/temp/MCE/mcelog-1.0pre2 > > # gmake FREEBSD=yes > > Makefile:92: .depend: No such file or directory > > cc -MM -I. p4.c k8.c mcelog.c dmi.c tsc.c core2.c bitfield.c intel.c > > nehalem.c dunnington.c tulsa.c config.c memutil.c msg.c eventloop.c > > leaky-bucket.c memdb.c server.c client.c cache.c rbtree.c memstream.c > > > .depend.X && mv .depend.X .depend > > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > > -Wmissing-declarations -Wdeclaration-after-statement -o mcelog.o mcelog.c > > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > > -Wmissing-declarations -Wdeclaration-after-statement -o p4.o p4.c > > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > > -Wmissing-declarations -Wdeclaration-after-statement -o k8.o k8.c > > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > > -Wmissing-declarations -Wdeclaration-after-statement -o dmi.o dmi.c > > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > > -Wmissing-declarations -Wdeclaration-after-statement -o tsc.o tsc.c > > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > > -Wmissing-declarations -Wdeclaration-after-statement -o core2.o core2.c > > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > > -Wmissing-declarations -Wdeclaration-after-statement -o bitfield.o > > bitfield.c > > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > > -Wmissing-declarations -Wdeclaration-after-statement -o intel.o intel.c > > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > > -Wmissing-declarations -Wdeclaration-after-statement -o nehalem.o nehalem.c > > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > > -Wmissing-declarations -Wdeclaration-after-statement -o dunnington.o > > dunnington.c > > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > > -Wmissing-declarations -Wdeclaration-after-statement -o tulsa.o tulsa.c > > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > > -Wmissing-declarations -Wdeclaration-after-statement -o config.o config.c > > config.c:135: error: static declaration of 'getline' follows non-static > > declaration > > /usr/include/stdio.h:370: error: previous declaration of 'getline' was here > > gmake: *** [config.o] Error 1 > > > > A local getline() needs the FreeBSD version check. > > %%% > --- config.c.olg 2011-02-18 14:57:52.000000000 +0300 > +++ config.c 2011-02-18 15:07:59.000000000 +0300 > @@ -18,6 +18,9 @@ > Author: Andi Kleen > */ > #define _GNU_SOURCE 1 > +#ifdef __FreeBSD__ > +# include > +#endif > #include > #include > #include > @@ -126,7 +129,7 @@ > return s; > } > > -#ifdef __FreeBSD__ > +#if (defined __FreeBSD__) && (__FreeBSD_version < 800067) > /* > * Newer versions do have getline(), so this should use a version test > * at some point. > %%% Thanks, I've updated mcelog.patch. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 16:22:52 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31BCA10656A8; Tue, 22 Feb 2011 16:22:52 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8FDF08FC1F; Tue, 22 Feb 2011 16:22:51 +0000 (UTC) Received: by ewy28 with SMTP id 28so233197ewy.13 for ; Tue, 22 Feb 2011 08:22:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=72Fchf63K0A0hh9n+ZfUbboH9RFLRjTHMRKB84EStKg=; b=pDLfICN3Cj6VwJPN3nY3LWE7oP4W0y3cK9RJtpPNTpHnebWM9w23ljIu/WCgx982KR 2wj2NSv+Xdj4WgYzPQC9yXNnlHYiUGvk1ZLWMd2AR+K+wdn8iWs+aFYDyXY+0GW48B0O yKAEWOCCu0okPPreXkXwhLl2+AXtNR0reKP10= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Fvr0DgZtc5L4q0A8w/gC4iTs+GfwTBy3/m6pAqU/FM1Oa8lwSs+btYf3tvwRxYx8bJ ctVTgOyMxRb7ADLS464HTL+I5dmX+t0D1+LrcdKi+0XKgdiegXqrY6FYQUpcroSsZ+4q +QGvEeQtMD94psSHKZQTlmmHZyrIcFgmvhKGY= MIME-Version: 1.0 Received: by 10.216.144.205 with SMTP id n55mr3505238wej.5.1298391770223; Tue, 22 Feb 2011 08:22:50 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.15.74 with HTTP; Tue, 22 Feb 2011 08:22:50 -0800 (PST) In-Reply-To: <20110222141112.GA98964@freebsd.org> References: <20110222141112.GA98964@freebsd.org> Date: Tue, 22 Feb 2011 08:22:50 -0800 X-Google-Sender-Auth: AAgEUGLVFxnCs_42-m4V5WtjKCA Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: seeking into /dev/{null,zero} X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 16:22:52 -0000 On Tue, Feb 22, 2011 at 6:11 AM, Alexander Best wrote: > hi there, > > there's a PR [1] regarding seeking into /dev/null and /dev/zero. i just wanted > to ask what the overall opinion is on this matter. technically it's quite easy > to seek into those files upon fwrite(3) and fread(3). the point is, if the file > position should be repositioned according the the amount of bytes read or > written. > > the zero(4) and null(4) manual pages claim that both devices act as "ordinary" > files. right now only reading from /dev/zero will seek into the file. writing > to /dev/zero and reading/writing to /dev/null will *not* adjust the file > position. lseek on CURRENT (and its assorted functions) is funky. Try this as an example: 1. Create a zero character file. 2. lseek with SEEK_SET to byte 1. 2. will always return 1. My Fedora Linux 13 VM on the other hand actually reports the error when you try and seek outside the bounds of the file descriptor (this makes more sense IMO because it accurately reflects reality). This is an extension to the POSIX spec though as the spec doesn't say whether or not seeking past the bounds of the descriptor is legal or illegal. So what I'm trying to say is that the seek family functions in general don't report helpful data except with success. Found this when trying to write testcases for lseek(2) the night before last. I'll get back to you about the POSIXness of those /dev's in the most recent spec once I get access back to the OpenGroup download section -_-... Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 16:35:46 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AF10106564A for ; Tue, 22 Feb 2011 16:35:46 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by mx1.freebsd.org (Postfix) with ESMTP id DBC1E8FC14 for ; Tue, 22 Feb 2011 16:35:45 +0000 (UTC) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTWPl4Yhshs3HUW9YkOLtafaui/ZX3gtl@postini.com; Tue, 22 Feb 2011 08:35:46 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 22 Feb 2011 08:32:54 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 22 Feb 2011 11:33:27 -0500 From: Andrew Duane To: Garrett Cooper , Alexander Best Date: Tue, 22 Feb 2011 11:31:12 -0500 Thread-Topic: seeking into /dev/{null,zero} Thread-Index: AcvSrOTLLWLRlbw0TeyBbYAA+7OlhwAAQZ5n Message-ID: References: <20110222141112.GA98964@freebsd.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-hackers@freebsd.org" Subject: RE: seeking into /dev/{null,zero} X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 16:35:46 -0000 I thought seeking past EOF was valid; writing something creates a file with= a hole in it. I always assumed that was standard semantics. As for /dev/zero and /dev/null, you could easily ask "who cares about the f= ile position?" But I think some programs might want to seek around and chec= k values, and those shouldn't change behaviour if someone uses /dev/null as= a test file. It seems pretty trivial to update it, so why not make it beha= ve the same. -- Andrew Duane Juniper Networks 978-589-0551 10 Technology Park Dr aduane@juniper.net Westford, MA 01886-3418 ________________________________________ From: owner-freebsd-hackers@freebsd.org [owner-freebsd-hackers@freebsd.org]= On Behalf Of Garrett Cooper [gcooper@freebsd.org] Sent: Tuesday, February 22, 2011 11:22 AM To: Alexander Best Cc: freebsd-hackers@freebsd.org Subject: Re: seeking into /dev/{null,zero} On Tue, Feb 22, 2011 at 6:11 AM, Alexander Best wrote= : > hi there, > > there's a PR [1] regarding seeking into /dev/null and /dev/zero. i just w= anted > to ask what the overall opinion is on this matter. technically it's quite= easy > to seek into those files upon fwrite(3) and fread(3). the point is, if th= e file > position should be repositioned according the the amount of bytes read or > written. > > the zero(4) and null(4) manual pages claim that both devices act as "ordi= nary" > files. right now only reading from /dev/zero will seek into the file. wri= ting > to /dev/zero and reading/writing to /dev/null will *not* adjust the file > position. lseek on CURRENT (and its assorted functions) is funky. Try this as an exam= ple: 1. Create a zero character file. 2. lseek with SEEK_SET to byte 1. 2. will always return 1. My Fedora Linux 13 VM on the other hand actually reports the error when you try and seek outside the bounds of the file descriptor (this makes more sense IMO because it accurately reflects reality). This is an extension to the POSIX spec though as the spec doesn't say whether or not seeking past the bounds of the descriptor is legal or illegal. So what I'm trying to say is that the seek family functions in general don't report helpful data except with success. Found this when trying to write testcases for lseek(2) the night before las= t. I'll get back to you about the POSIXness of those /dev's in the most recent spec once I get access back to the OpenGroup download section -_-... Thanks, -Garrett _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 16:46:07 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93A43106564A; Tue, 22 Feb 2011 16:46:07 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id EE3D68FC0A; Tue, 22 Feb 2011 16:46:06 +0000 (UTC) Received: by eyg7 with SMTP id 7so1032987eyg.13 for ; Tue, 22 Feb 2011 08:46:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1wB6FJVFuwZ/VTbSm6Qj7+byNTvz2tKq1tKYJX24+tM=; b=e9cJtzabp+6PVy9hW1rfae2pMYMyqQAAKEPCed0dgBc//wrLUexkWOn/21giwZeD2d mIWGRGsenFbyLCLXyAG9f+20n32lV6Z8kh1TXctekmns20JVknrM2o5YhN5bgw+d0NnG xhbi/nUbmyjcHFp553Km2i+Kmw1UaqL2OatMU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=wrIB8/J740/8Veu3NpWp86sffFLjsgJ4Df/GimPRCs5nBkEzCa9kJg5EZsu6wfgbqb GZKtE/mN9oEMkZLMkULHco+cy2hrGnd8zWJ7xLoJXi5qn9dhDANFPL5E6iz+cuE1+NwC 86tEBcn8OtB1ET1zSQJKH00m4Uwy/DjC1pUP8= MIME-Version: 1.0 Received: by 10.216.179.207 with SMTP id h57mr2602794wem.20.1298393165780; Tue, 22 Feb 2011 08:46:05 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.15.74 with HTTP; Tue, 22 Feb 2011 08:46:05 -0800 (PST) In-Reply-To: References: <20110222141112.GA98964@freebsd.org> Date: Tue, 22 Feb 2011 08:46:05 -0800 X-Google-Sender-Auth: LPQ9QMyZ08g-XjE-j8zchJqYFzA Message-ID: From: Garrett Cooper To: Andrew Duane Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexander Best , "freebsd-hackers@freebsd.org" Subject: Re: seeking into /dev/{null,zero} X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 16:46:07 -0000 (Please bottom post) On Tue, Feb 22, 2011 at 8:31 AM, Andrew Duane wrote: > I thought seeking past EOF was valid; writing something creates a file with a hole in it. I always assumed that was standard semantics. That's with SET_HOLE/SET_DATA though, correct? If so, outside of that functionality I would assume relatively standard POSIX semantics. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 17:51:36 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F38831065675; Tue, 22 Feb 2011 17:51:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C23438FC08; Tue, 22 Feb 2011 17:51:35 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 61AEF46B2E; Tue, 22 Feb 2011 12:51:35 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4A6688A027; Tue, 22 Feb 2011 12:51:34 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 22 Feb 2011 12:51:33 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <20110222141112.GA98964@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201102221251.33717.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 22 Feb 2011 12:51:34 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Alexander Best , Garrett Cooper Subject: Re: seeking into /dev/{null,zero} X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 17:51:36 -0000 On Tuesday, February 22, 2011 11:46:05 am Garrett Cooper wrote: > (Please bottom post) >=20 > On Tue, Feb 22, 2011 at 8:31 AM, Andrew Duane wrote: > > I thought seeking past EOF was valid; writing something creates a file= =20 with a hole in it. I always assumed that was standard semantics. >=20 > That's with SET_HOLE/SET_DATA though, correct? If so, outside of > that functionality I would assume relatively standard POSIX semantics. Err, no, you can always seek past EOF and then call write(2) to extend a fi= le=20 (it does an implicit ftruncate(2)). SEEK_HOLE and SEEK_DATA are different,= =20 they are just used to discover sparse regions within a file. =46rom the manpage: The lseek() system call allows the file offset to be set beyond the end of the existing end-of-file of the file. If data is later written at this point, subsequent reads of the data in the gap return bytes of ze= ros (until data is actually written into the gap). =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 18:33:26 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29AB8106564A; Tue, 22 Feb 2011 18:33:26 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id A21868FC14; Tue, 22 Feb 2011 18:33:25 +0000 (UTC) Received: by ywf9 with SMTP id 9so793592ywf.13 for ; Tue, 22 Feb 2011 10:33:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AktZrzd9oHXbnasUqSMAV4ZALA/kS66Fjru+IehHlP8=; b=tKCZjtaJLfr6deTQ4gvIZD5HFxvHZ8WCtRglp9/INZ/X0PGFEFhvLnC0maAU19C0Vx JQMANg39r4jcglu+bFRS6kR2oInwaZnJ5HFx04GYo/Vw4iZE2wzShj3pEIgkqlmwpxUZ BWt0hRpkOFBoZ4fgsYW4sZb08OZZmo7ZsKN/g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LTmHUPTF69qjGeDX19YB4+jiGgatF7XqSlayDVfuoR1icEDy5AQfXXbSfYzHW0SQx9 IhVRbUdm+Jp0+A0oGUNui38PD7A9pFn0aXRMAJ8wjADvaaNHimUnD9WPJFjytTeTfRs9 HScfolLLnrOiuwqJ0eeVoZYJDuHnRGd+A10+w= MIME-Version: 1.0 Received: by 10.147.83.17 with SMTP id k17mr1818226yal.9.1298397998344; Tue, 22 Feb 2011 10:06:38 -0800 (PST) Received: by 10.146.186.29 with HTTP; Tue, 22 Feb 2011 10:06:38 -0800 (PST) In-Reply-To: <201102221738.p1MHchsd016185@svn.freebsd.org> References: <201102221738.p1MHchsd016185@svn.freebsd.org> Date: Tue, 22 Feb 2011 13:06:38 -0500 Message-ID: From: Ben Kaduk To: Bruce Cran Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-Hackers Subject: Re: svn commit: r218953 - stable/8/usr.sbin/sysinstall X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 18:33:26 -0000 [replying to the MFC that triggered the connection] On Tue, Feb 22, 2011 at 12:38 PM, Bruce Cran wrote: > Author: brucec > Date: Tue Feb 22 17:38:43 2011 > New Revision: 218953 > URL: http://svn.freebsd.org/changeset/base/218953 > > Log: > =A0MFC r218840: > > =A0Remove the quotas option from the Startup Services menu. > =A0GENERIC has no support for quotas so this option has no effect. Do you know why GENERIC does not have quota support enabled? I note that the Debian/kFreeBSD folk have enabled quota support for the kernel they ship: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D608995 In that report, emaste@ is quoted as saying: > If you mean "kFreeBSD should ship with a quota-enabled kernel" then I'd > say go for it. The reason we don't have it on in upstream FreeBSD is > largely historical; enabling quotas used to require additional locking > that caused performance and other issues. The additional locking is now > not required, and it's just that nobody has stepped in to turn them on. If you believe everything you read on the internet, "In order to achieve a modern operating system, the quota support should be active by default, not achieved only after compilation of a custom kernel." Is there more to "stepping in and turning them on" than just the one-line change? -Ben Kaduk From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 18:43:54 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0D70106566B for ; Tue, 22 Feb 2011 18:43:54 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 534588FC18 for ; Tue, 22 Feb 2011 18:43:53 +0000 (UTC) Received: by ewy28 with SMTP id 28so348191ewy.13 for ; Tue, 22 Feb 2011 10:43:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:date:from:to:subject:message-id:mime-version :content-type:content-disposition; bh=l3q+iPFfF3TwvrhbfGTxQVFAvvEe7JiTkspSba/eYy0=; b=C7x4Ty0EKk/NZbs2H6GZv/SzMTWN04sbr2zCoo7zO8BdI2VJ3QbEXgoVo9+8m/r34B mnpocEWtLko5C1g0lmCkpG18mG2eoh7iXXrWgDYVKf17B4dWCY2BQNwRSs2PlZdCf//d a4cgTbzYBb5CnaihfoqSr0p2/KjqRjdL98YGo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition; b=fG8lWo+g66S7Skqj4juUKCNLQBif3xCK/ySzbe0CkE6e/jBnG0bHC0l/haC3E5/uw9 UusByYZnGyNiD/IOyDg7p+a0JPGk04+ibXCyPh1YhZIwALAuCgPLKirMwafzOOctAcfx Cbfm+P+W7YNFdObC5bG+2lzL5dT91JtZr99dI= Received: by 10.213.13.16 with SMTP id z16mr1181702ebz.57.1298398538064; Tue, 22 Feb 2011 10:15:38 -0800 (PST) Received: from viper.internal.network (dsl78-143-205-37.in-addr.fast.co.uk [78.143.205.37]) by mx.google.com with ESMTPS id t50sm6196698eeh.12.2011.02.22.10.15.37 (version=TLSv1/SSLv3 cipher=AES128-SHA); Tue, 22 Feb 2011 10:15:37 -0800 (PST) Received: by viper.internal.network (Postfix, from userid 11001) id C22A64AC08; Tue, 22 Feb 2011 18:15:35 +0000 (UTC) Date: Tue, 22 Feb 2011 18:15:35 +0000 From: xorquewasp@googlemail.com To: freebsd-hackers@freebsd.org Message-ID: <20110222181535.GA21015@viper> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Building java ports with openjdk6/7 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 18:43:54 -0000 Hello. Is it possible to build Eclipse (and other java ports) with openjdk6/7? I have both built and installed but for whatever reason, attempting to build Eclipse always causes the ports system to try to build jdk16 as a dependency (which fails as it's an "interactive port" and I always run in BATCH=1 mode). xw From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 19:28:43 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FE4A106566B for ; Tue, 22 Feb 2011 19:28:43 +0000 (UTC) (envelope-from dougb@dougbarton.us) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 1F89A8FC18 for ; Tue, 22 Feb 2011 19:28:42 +0000 (UTC) Received: (qmail 2695 invoked by uid 399); 22 Feb 2011 19:28:37 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 22 Feb 2011 19:28:37 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D640E64.5020008@dougbarton.us> Date: Tue, 22 Feb 2011 11:28:36 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4D6323D9.5090500@dougbarton.us> <4D63659E.6010305@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 22 Feb 2011 19:39:45 +0000 Subject: Re: Problem with etc/periodic/daily/310.accounting X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 19:28:43 -0000 On 02/22/2011 07:57, Garrett Cooper wrote: > Can accounting_file by provided by user input (doesn't look like > it today, but just to be safe I thought I should check)? These are the kinds of questions it's good to answer for yourself before you post to the list. :) > If so then the dirname should be restored. Example: > > $ foo=/a/b//////c > $ echo ${foo%/*} > /a/b///// > $ dirname $foo > /a/b A) I refuse to believe that our users are that stupid B) Even if they are, it works Doug (ok, "refuse" is a bit strong ...) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 20:54:11 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 378611065670; Tue, 22 Feb 2011 20:54:11 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id E323B8FC08; Tue, 22 Feb 2011 20:54:10 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 4CE231E0028A; Tue, 22 Feb 2011 21:54:10 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id p1MKnO7d078958; Tue, 22 Feb 2011 21:49:24 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id p1MKnNjV078957; Tue, 22 Feb 2011 21:49:23 +0100 (CET) (envelope-from nox) From: Juergen Lock Date: Tue, 22 Feb 2011 21:49:23 +0100 To: Alexander Leidinger Message-ID: <20110222204923.GA78744@triton8.kn-bremen.de> References: <20110129201000.GA10774@triton8.kn-bremen.de> <20110129205105.GI2518@deviant.kiev.zoral.com.ua> <20110129235448.GA15788@triton8.kn-bremen.de> <20110218205542.GA45210@triton8.kn-bremen.de> <20110219175744.GH78089@deviant.kiev.zoral.com.ua> <20110221183611.GA38073@triton8.kn-bremen.de> <20110222092641.18945u7safu272o8@webmail.leidinger.net> <20110222113753.GA62966@triton8.kn-bremen.de> <20110222135031.31453ocol73fg3k0@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110222135031.31453ocol73fg3k0@webmail.leidinger.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Tue, 22 Feb 2011 21:07:52 +0000 Cc: Kostik Belousov , freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org, Juergen Lock Subject: Re: Can vm_mmap()/vm_map_remove() be called with giant held? (linuxolator dvb patches) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 20:54:11 -0000 On Tue, Feb 22, 2011 at 01:50:31PM +0100, Alexander Leidinger wrote: > Quoting Juergen Lock (from Tue, 22 Feb 2011 > 12:37:53 +0100): > > > On Tue, Feb 22, 2011 at 09:26:41AM +0100, Alexander Leidinger wrote: > >> Quoting Juergen Lock (from Mon, 21 Feb 2011 > >> 19:36:11 +0100): > >> > >> > And here comes the patch for head: > >> > >> linux_dvb.h is still GPLed (not taking into account that there are > >> voices which tell that interface descriptions are not copyrightable or > >> something like this). As already told this is a no-go, the linuxulator > >> is BSD licensed. > > > > Right I should have mentioned your concerns. (I said it wouldn't > > really matter since the linuxolator already is a kld and the header > > LThe lnuxulator can be included into the kernel (think about an > embedded system where the vendor does not want to give the source). > > The authors of the v4l and v4l2 headers where contacted to get their > OK to license the headers within the BSDL (and we got their > permission), and I make the suggestion again that you do the same for > the dvb header parts you took. > > If you do not get their OK, my next suggestion is to talk to core > about it (if the LGPLed code gets committed without a note that core > is OK, I will make a call to core anyway (I will not ask to back it > out, it's up to core then to ask for a backout or not), so it may be > better to ask before committing). > > > file from which I took the definitions is LGPL'd not GPL'd [1], to > > which I didn't see an answer.) > > IMO the first L does not matter if the rest contains GPL. > > I'm really happy that you take the time to take care about DVB > compatibility, and I would like to see the code in FreeBSD, but the > linuxulator is (L)GPL free and changing this is a step backward. Oh well so it looks like I'll really have to bug the linux folks... But first I'll have to find all the authors of the dvb-s2 api additions in linux/dvb/frontend.h that this is part of, and I'm not up to for that at least today. :) Juergen From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 21:26:05 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04C8A1065672; Tue, 22 Feb 2011 21:26:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 7003B8FC08; Tue, 22 Feb 2011 21:26:04 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p1MLQ0Pl032615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Feb 2011 23:26:01 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p1MLQ0AI062605; Tue, 22 Feb 2011 23:26:00 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p1MLQ0QR062604; Tue, 22 Feb 2011 23:26:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Feb 2011 23:26:00 +0200 From: Kostik Belousov To: Ben Kaduk Message-ID: <20110222212600.GG78089@deviant.kiev.zoral.com.ua> References: <201102221738.p1MHchsd016185@svn.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Hl7iIDUZZE9gOHs4" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org, FreeBSD-Hackers , Bruce Cran Subject: Re: svn commit: r218953 - stable/8/usr.sbin/sysinstall X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 21:26:05 -0000 --Hl7iIDUZZE9gOHs4 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 22, 2011 at 01:06:38PM -0500, Ben Kaduk wrote: > [replying to the MFC that triggered the connection] >=20 > On Tue, Feb 22, 2011 at 12:38 PM, Bruce Cran wrote: > > Author: brucec > > Date: Tue Feb 22 17:38:43 2011 > > New Revision: 218953 > > URL: http://svn.freebsd.org/changeset/base/218953 > > > > Log: > > =9AMFC r218840: > > > > =9ARemove the quotas option from the Startup Services menu. > > =9AGENERIC has no support for quotas so this option has no effect. >=20 > Do you know why GENERIC does not have quota support enabled? I note > that the Debian/kFreeBSD folk have enabled quota support for the > kernel they ship: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D608995 >=20 > In that report, emaste@ is quoted as saying: > > If you mean "kFreeBSD should ship with a quota-enabled kernel" then I'd > > say go for it. The reason we don't have it on in upstream FreeBSD is > > largely historical; enabling quotas used to require additional locking > > that caused performance and other issues. The additional locking is now > > not required, and it's just that nobody has stepped in to turn them on. >=20 > If you believe everything you read on the internet, "In order to > achieve a modern operating system, the quota support should be active > by default, not achieved only after compilation of a custom kernel." >=20 > Is there more to "stepping in and turning them on" than just the > one-line change? I promise to enable UFS quotas in GENERIC in one week unless anybody objects now. --Hl7iIDUZZE9gOHs4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1kKegACgkQC3+MBN1Mb4gfpQCgjMiTff37Oxv/J4wC2o+XuZpw 0ycAoJTefNzu36dpTF7y2dfZshQjnb0A =Z80l -----END PGP SIGNATURE----- --Hl7iIDUZZE9gOHs4-- From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 21:48:53 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB50A106564A for ; Tue, 22 Feb 2011 21:48:53 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from lab.alexdupre.com (alexdupre-1-pt.tunnel.tserv23.zrh1.ipv6.he.net [IPv6:2001:470:25:450::2]) by mx1.freebsd.org (Postfix) with ESMTP id 77B698FC08 for ; Tue, 22 Feb 2011 21:48:53 +0000 (UTC) Received: (qmail 1481 invoked from network); 22 Feb 2011 21:48:43 -0000 Received: from atom.alexdupre.com (HELO ?192.168.178.12?) (sysadmin@alexdupre.com@192.168.178.12) by lab.alexdupre.com with ESMTPSA; 22 Feb 2011 21:48:43 -0000 Message-ID: <4D642F3C.5030702@FreeBSD.org> Date: Tue, 22 Feb 2011 22:48:44 +0100 From: Alex Dupre User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.1.16) Gecko/20101123 SeaMonkey/2.0.11 MIME-Version: 1.0 To: xorquewasp@googlemail.com References: <20110222181535.GA21015@viper> In-Reply-To: <20110222181535.GA21015@viper> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Building java ports with openjdk6/7 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 21:48:54 -0000 xorquewasp@googlemail.com ha scritto: > Is it possible to build Eclipse (and other java ports) > with openjdk6/7? JAVA_PREFERRED_PORTS=JAVA_PORT_NATIVE_OPENJDK_JDK_1_6 But I don't think it's related to freebsd-hackers. -- Alex Dupre From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 23:54:02 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1952106566B for ; Tue, 22 Feb 2011 23:54:02 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 557C08FC16 for ; Tue, 22 Feb 2011 23:54:01 +0000 (UTC) Received: by fxm19 with SMTP id 19so4250647fxm.13 for ; Tue, 22 Feb 2011 15:54:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:from:to:subject:date:x-mailer; bh=9MfpPevj0hXKbOchqEbmnzedpKxCb89kDzvwUX+DL48=; b=V0A0kNSPPwL+Tp5YzsIWoVGPeX1TNjc167Sd0c4yehb3UZ8wC29TG/dG9YGIg+LNkg ntvjXZ4dcYuvFUyXuCP//Vt7aLpCTZoCXiTp/auidLGQP62UKQegILDSHiAE2p6bhAFN O9XLWRTzibmgiyGBWAMPrAtaJPrzv2Fr+Em7M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:x-mailer; b=ig4Jb6LNGFESRXhO3D96D4AQ/HlDKDq+ba7QoQRMGJkWGRRf90SeZ/bJx8juUesipc lW3mkvpSV5rwTePwGvzKDMsk2dqsreDrbBxZg1mSZ4wQnPkZIol6mEE3PlU2GRwOAldG 2o+ILRIHsBgL9AtU1R7cRxYq0k4IfBni1xa+4= Received: by 10.223.96.206 with SMTP id i14mr4196742fan.67.1298418841219; Tue, 22 Feb 2011 15:54:01 -0800 (PST) Received: from DEV ([82.193.208.173]) by mx.google.com with ESMTPS id n2sm179498fam.4.2011.02.22.15.53.55 (version=SSLv3 cipher=OTHER); Tue, 22 Feb 2011 15:54:00 -0800 (PST) Message-ID: <20110222.235355.253.1@DEV> From: rank1seeker@gmail.com To: freebsd-hackers@freebsd.org Date: Wed, 23 Feb 2011 00:53:55 +0100 X-Mailer: POP Peeper (3.7.0.0) Subject: Kern Conf options non existant in LINT X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 23:54:02 -0000 In this example for i386 8.1 RELEASE-p2 cd /sys/i386/conf make LINT Besides LINT, it also creates LINT-VIMAGE Upon csup of src LINT gets delete but LINT-VIMAGE doesn't. So, looking at "/sys/i386/conf/DEFAULTS" options NATIVE options ISAPNP device io device uart_ns8250 device atpic DON'T exist in LINT How come?! PS: How do I ensure "/sys/i386/conf/DEFAULTS" is being ignored when I issue: # make kernel and a ... for what is used: (found in LINT) options DIRECTIO Domagoj S. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 23 00:19:20 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72A35106564A for ; Wed, 23 Feb 2011 00:19:20 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 062738FC0C for ; Wed, 23 Feb 2011 00:19:19 +0000 (UTC) Received: by wwf26 with SMTP id 26so7697908wwf.31 for ; Tue, 22 Feb 2011 16:19:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UiFGHbwV7V9sg8OiH/QcaGLtvrt0ukyjJgVrFl9/JBU=; b=J5u44jlibw41NZQk65toavgAQqntEPifc7kpoRiWpXUcEOg0cku6GUGJFrodh5Rc0+ iK7S1o87sfZuw3VoIOpjw2MdGY8c4cYb71mdnW9nJTrc5XKSI22fLHkqByQVNaUujpR0 a1Kz0T7e20reFcQO2iAsvOoTyAq/vVBDu51Ok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=VBM0jiBvQVuS5iPj+wpfLZj5wdfQG23v83qoU32Lj+742nfLShT721kl/q+7IF4dkF FVrg39imvDJIYF82AskreeQ2cNyr0/BwxSbmRHx/j2/JKWidP9pmk7ZxEt33asHtV6I8 MA1yrSZLhcPQXgWjoSvUZ6Y9w2R//gORNa2XQ= MIME-Version: 1.0 Received: by 10.216.179.81 with SMTP id g59mr3909017wem.35.1298420359004; Tue, 22 Feb 2011 16:19:19 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.15.74 with HTTP; Tue, 22 Feb 2011 16:19:18 -0800 (PST) In-Reply-To: <20110222.235355.253.1@DEV> References: <20110222.235355.253.1@DEV> Date: Tue, 22 Feb 2011 16:19:18 -0800 X-Google-Sender-Auth: vHgxKD5XZegF0UnngDmOMYieF2g Message-ID: From: Garrett Cooper To: rank1seeker@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Kern Conf options non existant in LINT X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 00:19:20 -0000 On Tue, Feb 22, 2011 at 3:53 PM, wrote: ... > PS: How do I ensure "/sys/i386/conf/DEFAULTS" is being ignored when I iss= ue: > # make kernel > > and a ... for what is used: (found in LINT) > options =A0 =A0DIRECTIO nodevice name [, name [...]] nodevices name [, name [...]] Remove the specified devices from the list of previously selec= ted devices. This directive can be used to cancel the effects of device or devices directives in files included using include. etc. See config(5) for more details. Cheers, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 23 04:30:05 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57180106566B; Wed, 23 Feb 2011 04:30:05 +0000 (UTC) (envelope-from mmatsuda@cybernet.co.jp) Received: from mfow.securemx.jp (mfow300.securemx.jp [210.130.202.50]) by mx1.freebsd.org (Postfix) with ESMTP id D25298FC08; Wed, 23 Feb 2011 04:30:04 +0000 (UTC) Received: by mfow.securemx.jp (mfow300) id p1N3slfc025372; Wed, 23 Feb 2011 12:54:47 +0900 Received: by mow.securemx.jp (mow302) id p1N3sjET022754; Wed, 23 Feb 2011 12:54:45 +0900 X-MXL-Hash: 4d6485055487a197-f9366b51c9d9ba23e3445d7757e05077ec83e298 Received: from cscu-112sm.cybernet.co.jp (cscusm222.cybernet.co.jp [202.214.244.222]) by relay.securemx.jp (mx-mr301) id p1N3sidw014983; Wed, 23 Feb 2011 12:54:44 +0900 X-AuditID: c0a8cbde-0000000900000e83-f8-4d6485047607 Received: from mail.cybernet.co.jp (cscu-110sm.cybernet.co.jp [192.168.201.76]) by cscu-112sm.cybernet.co.jp (Symantec Mail Security) with ESMTP id 7DDA414AA6; Wed, 23 Feb 2011 12:54:44 +0900 (JST) Received: from localhost (unknown [172.21.78.145]) by mail.cybernet.co.jp (Postfix) with ESMTP id 4EA182A9FF; Wed, 23 Feb 2011 12:54:44 +0900 (JST) Date: Wed, 23 Feb 2011 12:54:35 +0900 (JST) Message-Id: <20110223.125435.202697583.mmatsuda@cybernet.co.jp> To: dim@FreeBSD.org From: mmatsuda@cybernet.co.jp In-Reply-To: <4D63AE83.5040007@FreeBSD.org> References: <4D63661D.2090205@gmail.com> <4D63AE83.5040007@FreeBSD.org> X-Mailer: Mew version 5.1 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-CC-Mail-RelayStamp: CC/Mail=pass X-CC-Mail-UserOperation: Confirmed Mail X-Brightmail-Tracker: AAAAAA== Cc: freebsd-hackers@freebsd.org, gnehzuil@gmail.com Subject: Re: buildkernel error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 04:30:05 -0000 From: Dimitry Andric Date: Tue, 22 Feb 2011 13:39:31 +0100 ::On 2011-02-22 08:30, gnehzuil wrote: ::> I updated my kernel source code and try to make a new kernel using make ::> buildkernel command. But I got an error as follow: ::... ::> ld:/usr/src/sys/conf/ldscript.i386:66: syntax error :: ::Your /usr/bin/ld is still at version 2.15, which is too old to parse the ::kernel linker script. In this case, first run "make buildworld", or at ::least "make kernel-toolchain" before you attempt to build any kernels. Hello, Does it mean we have no-way of source upgrading from 8.X? We need newest world to build 9.x kernel, and need 9.x kernel to run newest world, and... Thanks, Haro From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 23 05:04:25 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3B9D106564A; Wed, 23 Feb 2011 05:04:25 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4214C8FC0A; Wed, 23 Feb 2011 05:04:24 +0000 (UTC) Received: by wwf26 with SMTP id 26so7908108wwf.31 for ; Tue, 22 Feb 2011 21:04:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5PvcY5m4E6E9gPXxwWJQjyQTB3zZ49oTdWoYKH3AgOY=; b=EXq1z2xUdsYRdU0LSBjBlQiY0FTg8wQkwUPZ9AiEpG0sVlBV4h4cw3vFvqTPDBAZL8 zyrZEs+lKe8467TA1sOsrx/GnRdeayOdnXsz3DNiCCwJqKEnHFN3q94mpV3BVf2HVkbF usVhkBeAafnc0UP/vgKuNFg1kc9YwlTM0hTnM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=bA75I1kMHhvKG4gFh+wn0he1priZWic6XWrDHi55+Qb6xL/C+tAg0K+mnSnf7CZRIQ 0TicUU+RNIOSNY/3+mZKBc97xxHLjbJF0/AYnCrD7gxkYqIZ1xkYUhKp4BoW3rUn/XIs mpo+yWGYr3mJ8UzESqyYEHJkjL1HHvute1drE= MIME-Version: 1.0 Received: by 10.216.1.145 with SMTP id 17mr3258476wed.50.1298437464248; Tue, 22 Feb 2011 21:04:24 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.15.74 with HTTP; Tue, 22 Feb 2011 21:04:24 -0800 (PST) In-Reply-To: <20110223.125435.202697583.mmatsuda@cybernet.co.jp> References: <4D63661D.2090205@gmail.com> <4D63AE83.5040007@FreeBSD.org> <20110223.125435.202697583.mmatsuda@cybernet.co.jp> Date: Tue, 22 Feb 2011 21:04:24 -0800 X-Google-Sender-Auth: Gw4ZEutNgtimcGjFmp9dSFOEK0Y Message-ID: From: Garrett Cooper To: mmatsuda@cybernet.co.jp Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, dim@freebsd.org, gnehzuil@gmail.com Subject: Re: buildkernel error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 05:04:25 -0000 On Tue, Feb 22, 2011 at 7:54 PM, wrote: > From: Dimitry Andric > Date: Tue, 22 Feb 2011 13:39:31 +0100 > ::On 2011-02-22 08:30, gnehzuil wrote: > ::> I updated my kernel source code and try to make a new kernel using ma= ke > ::> buildkernel command. But I got an error as follow: > ::... > ::> ld:/usr/src/sys/conf/ldscript.i386:66: syntax error > :: > ::Your /usr/bin/ld is still at version 2.15, which is too old to parse th= e > ::kernel linker script. =A0In this case, first run "make buildworld", or = at > ::least "make kernel-toolchain" before you attempt to build any kernels. > > Hello, > > Does it mean we have no-way of source upgrading from 8.X? > We need newest world to build 9.x kernel, and need 9.x kernel to run > newest world, and... No; you have to do something like the following: [kernel-]toolchain buildworld buildkernel. A plus side of doing this is that I do kernel-toolchain at -j12 and then do buildworld buildkernel at -j12 as well. It's much quicker than buildworld buildkernel at -j1, and less error prone than doing it at any other -j value in parallel. The handbook just says buildworld buildkernel ( http://www.freebsd.org/doc/handbook/makeworld.html ), and UPDATING just says kernel-toolchain buildkernel installkernel (look for "To build a kernel"), but there aren't any official directions in the quick to find spots that mention those above steps. Cheers, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 23 05:24:17 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCCDC1065672; Wed, 23 Feb 2011 05:24:17 +0000 (UTC) (envelope-from mmatsuda@cybernet.co.jp) Received: from mow.securemx.jp (mow302.securemx.jp [210.130.202.52]) by mx1.freebsd.org (Postfix) with ESMTP id 870298FC17; Wed, 23 Feb 2011 05:24:16 +0000 (UTC) Received: by mow.securemx.jp (mow302) id p1N5OFDg017659; Wed, 23 Feb 2011 14:24:15 +0900 X-MXL-Hash: 4d6499fe322c6a7a-c7e2dbc70546b5b1552de15728d429401d3daf23 Received: from cscu-112sm.cybernet.co.jp (cscusm222.cybernet.co.jp [202.214.244.222]) by relay.securemx.jp (mx-mr300) id p1N5OEnh032767; Wed, 23 Feb 2011 14:24:14 +0900 X-AuditID: c0a8cbde-0000000800000e83-da-4d6499fe19dd Received: from mail.cybernet.co.jp (cscu-110sm.cybernet.co.jp [192.168.201.76]) by cscu-112sm.cybernet.co.jp (Symantec Mail Security) with ESMTP id 13C2F14AA6; Wed, 23 Feb 2011 14:24:14 +0900 (JST) Received: from localhost (unknown [172.21.78.145]) by mail.cybernet.co.jp (Postfix) with ESMTP id 050CE2A9FF; Wed, 23 Feb 2011 14:24:14 +0900 (JST) Date: Wed, 23 Feb 2011 14:24:05 +0900 (JST) Message-Id: <20110223.142405.160720730.mmatsuda@cybernet.co.jp> To: gcooper@FreeBSD.org From: mmatsuda@cybernet.co.jp In-Reply-To: References: <4D63AE83.5040007@FreeBSD.org> <20110223.125435.202697583.mmatsuda@cybernet.co.jp> X-Mailer: Mew version 5.1 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-CC-Mail-RelayStamp: CC/Mail=pass X-CC-Mail-UserOperation: Confirmed Mail X-Brightmail-Tracker: AAAAAA== Cc: freebsd-hackers@freebsd.org, dim@freebsd.org, gnehzuil@gmail.com Subject: Re: buildkernel error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 05:24:17 -0000 From: Garrett Cooper Date: Tue, 22 Feb 2011 21:04:24 -0800 ::On Tue, Feb 22, 2011 at 7:54 PM, wrote: ::> From: Dimitry Andric ::> Date: Tue, 22 Feb 2011 13:39:31 +0100 ::> ::On 2011-02-22 08:30, gnehzuil wrote: ::> ::> I updated my kernel source code and try to make a new kernel us= ing make ::> ::> buildkernel command. But I got an error as follow: ::> ::... ::> ::> ld:/usr/src/sys/conf/ldscript.i386:66: syntax error ::> :: ::> ::Your /usr/bin/ld is still at version 2.15, which is too old to pa= rse the ::> ::kernel linker script. =A0In this case, first run "make buildworld= ", or at ::> ::least "make kernel-toolchain" before you attempt to build any ker= nels. ::> ::> Hello, ::> ::> Does it mean we have no-way of source upgrading from 8.X? ::> We need newest world to build 9.x kernel, and need 9.x kernel to ru= n ::> newest world, and... :: :: No; you have to do something like the following: :: ::[kernel-]toolchain buildworld buildkernel. :: :: A plus side of doing this is that I do kernel-toolchain at -j12 ::and then do buildworld buildkernel at -j12 as well. It's much quicker= ::than buildworld buildkernel at -j1, and less error prone than doing i= t ::at any other -j value in parallel. :: The handbook just says buildworld buildkernel ( ::http://www.freebsd.org/doc/handbook/makeworld.html ), and UPDATING ::just says kernel-toolchain buildkernel installkernel (look for "To ::build a kernel"), but there aren't any official directions in the ::quick to find spots that mention those above steps. Ahh, thanks for pointers. I was just reading the "To upgrade in-place from 8.x-stable to current"= from UPDATING, which does not say anything about [kernel-]toolchain. May by that part, and some others, also needs updating. Thanks, Haro From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 23 08:25:43 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70AE0106566C; Wed, 23 Feb 2011 08:25:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 0DCAB8FC13; Wed, 23 Feb 2011 08:25:42 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p1N8PWlG091182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Feb 2011 10:25:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p1N8PWbl066131; Wed, 23 Feb 2011 10:25:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p1N8PWBl066130; Wed, 23 Feb 2011 10:25:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 23 Feb 2011 10:25:32 +0200 From: Kostik Belousov To: mmatsuda@cybernet.co.jp Message-ID: <20110223082532.GK78089@deviant.kiev.zoral.com.ua> References: <4D63AE83.5040007@FreeBSD.org> <20110223.125435.202697583.mmatsuda@cybernet.co.jp> <20110223.142405.160720730.mmatsuda@cybernet.co.jp> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="F1SS92tkPgcRhhUi" Content-Disposition: inline In-Reply-To: <20110223.142405.160720730.mmatsuda@cybernet.co.jp> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, dim@freebsd.org Subject: Re: buildkernel error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 08:25:43 -0000 --F1SS92tkPgcRhhUi Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 23, 2011 at 02:24:05PM +0900, mmatsuda@cybernet.co.jp wrote: > From: Garrett Cooper > Date: Tue, 22 Feb 2011 21:04:24 -0800 > ::On Tue, Feb 22, 2011 at 7:54 PM, wrote: > ::> From: Dimitry Andric > ::> Date: Tue, 22 Feb 2011 13:39:31 +0100 > ::> ::On 2011-02-22 08:30, gnehzuil wrote: > ::> ::> I updated my kernel source code and try to make a new kernel usin= g make > ::> ::> buildkernel command. But I got an error as follow: > ::> ::... > ::> ::> ld:/usr/src/sys/conf/ldscript.i386:66: syntax error > ::> :: > ::> ::Your /usr/bin/ld is still at version 2.15, which is too old to pars= e the > ::> ::kernel linker script. =9AIn this case, first run "make buildworld",= or at > ::> ::least "make kernel-toolchain" before you attempt to build any kerne= ls. > ::> > ::> Hello, > ::> > ::> Does it mean we have no-way of source upgrading from 8.X? > ::> We need newest world to build 9.x kernel, and need 9.x kernel to run > ::> newest world, and... > :: > :: No; you have to do something like the following: > :: > ::[kernel-]toolchain buildworld buildkernel. > :: > :: A plus side of doing this is that I do kernel-toolchain at -j12 > ::and then do buildworld buildkernel at -j12 as well. It's much quicker > ::than buildworld buildkernel at -j1, and less error prone than doing it > ::at any other -j value in parallel. > :: The handbook just says buildworld buildkernel ( > ::http://www.freebsd.org/doc/handbook/makeworld.html ), and UPDATING > ::just says kernel-toolchain buildkernel installkernel (look for "To > ::build a kernel"), but there aren't any official directions in the > ::quick to find spots that mention those above steps. >=20 > Ahh, thanks for pointers. > I was just reading the "To upgrade in-place from 8.x-stable to current" > from UPDATING, which does not say anything about [kernel-]toolchain. > May by that part, and some others, also needs updating. You do not need to do anything with kernel-toolchain. THe proper procedure of buildworld/buildkernel just works. --F1SS92tkPgcRhhUi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1kxHsACgkQC3+MBN1Mb4gw2QCfbIS1wtbJliUVvJBOoj8Sxtur Nb4AoLzhdHY6y5kuczYT0tZbUxiNtHuk =Nwwl -----END PGP SIGNATURE----- --F1SS92tkPgcRhhUi-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 23 09:11:01 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3D9C1065670; Wed, 23 Feb 2011 09:11:01 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 863228FC2D; Wed, 23 Feb 2011 09:11:01 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p1N9B0HW062037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Feb 2011 01:11:00 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p1N9B08E062036; Wed, 23 Feb 2011 01:11:00 -0800 (PST) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA07387; Wed, 23 Feb 11 01:00:31 PST Date: Wed, 23 Feb 2011 01:00:06 -0800 From: perryh@pluto.rain.com To: gnehzuil@gmail.com, dim@freebsd.org Message-Id: <4d64cc96.gh+SoZb8LSOAInQd%perryh@pluto.rain.com> References: <4D63661D.2090205@gmail.com> <4D63AE83.5040007@FreeBSD.org> In-Reply-To: <4D63AE83.5040007@FreeBSD.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: buildkernel error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 09:11:01 -0000 Dimitry Andric wrote: > On 2011-02-22 08:30, gnehzuil wrote: > > I updated my kernel source code and try to make a new kernel > > using make buildkernel command. But I got an error as follow: > ... > > ld:/usr/src/sys/conf/ldscript.i386:66: syntax error > > Your /usr/bin/ld is still at version 2.15, which is too old to > parse the kernel linker script. In this case, first run "make > buildworld", or at least "make kernel-toolchain" before you > attempt to build any kernels. Will either "make buildworld" or "make kernel-toolchain" accomplish anything if, as the OP said, s/he only updated the _kernel_ sources? From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 23 09:54:34 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42318106564A; Wed, 23 Feb 2011 09:54:34 +0000 (UTC) (envelope-from mmatsuda@cybernet.co.jp) Received: from mow.securemx.jp (mow301.securemx.jp [210.130.202.49]) by mx1.freebsd.org (Postfix) with ESMTP id DBD688FC18; Wed, 23 Feb 2011 09:54:33 +0000 (UTC) Received: by mow.securemx.jp (mow301) id p1N9sWAf029248; Wed, 23 Feb 2011 18:54:32 +0900 X-MXL-Hash: 4d64d95731b105ff-8cabedfde2e473cdc5e47994bc2199859db2e288 Received: from cscu-112sm.cybernet.co.jp (cscusm222.cybernet.co.jp [202.214.244.222]) by relay.securemx.jp (mx-mr301) id p1N9sUJg014551; Wed, 23 Feb 2011 18:54:30 +0900 X-AuditID: c0a8cbde-0000000600000e83-c4-4d64d956051f Received: from mail.cybernet.co.jp (cscu-110sm.cybernet.co.jp [192.168.201.76]) by cscu-112sm.cybernet.co.jp (Symantec Mail Security) with ESMTP id 6C49214AA6; Wed, 23 Feb 2011 18:54:30 +0900 (JST) Received: from localhost (unknown [172.21.78.145]) by mail.cybernet.co.jp (Postfix) with ESMTP id ED16F2A9FF; Wed, 23 Feb 2011 18:54:29 +0900 (JST) Date: Wed, 23 Feb 2011 18:54:22 +0900 (JST) Message-Id: <20110223.185422.190209276.mmatsuda@cybernet.co.jp> To: kostikbel@gmail.com From: mmatsuda@cybernet.co.jp In-Reply-To: <20110223082532.GK78089@deviant.kiev.zoral.com.ua> References: <20110223.142405.160720730.mmatsuda@cybernet.co.jp> <20110223082532.GK78089@deviant.kiev.zoral.com.ua> X-Mailer: Mew version 5.1 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable X-CC-Mail-RelayStamp: CC/Mail=pass X-CC-Mail-UserOperation: Confirmed Mail X-Brightmail-Tracker: AAAAAA== Cc: freebsd-hackers@freebsd.org, dim@freebsd.org Subject: Re: buildkernel error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 09:54:34 -0000 From: Kostik Belousov Date: Wed, 23 Feb 2011 10:25:32 +0200 ::On Wed, Feb 23, 2011 at 02:24:05PM +0900, mmatsuda@cybernet.co.jp wro= te: ::> From: Garrett Cooper ::> Date: Tue, 22 Feb 2011 21:04:24 -0800 ::> ::On Tue, Feb 22, 2011 at 7:54 PM, wrote= : ::> ::> From: Dimitry Andric ::> ::> Date: Tue, 22 Feb 2011 13:39:31 +0100 ::> ::> ::On 2011-02-22 08:30, gnehzuil wrote: ::> ::> ::> I updated my kernel source code and try to make a new kerne= l using make ::> ::> ::> buildkernel command. But I got an error as follow: ::> ::> ::... ::> ::> ::> ld:/usr/src/sys/conf/ldscript.i386:66: syntax error ::> ::> :: ::> ::> ::Your /usr/bin/ld is still at version 2.15, which is too old t= o parse the ::> ::> ::kernel linker script. =9AIn this case, first run "make buildw= orld", or at ::> ::> ::least "make kernel-toolchain" before you attempt to build any= kernels. ::> ::> ::> ::> Hello, ::> ::> ::> ::> Does it mean we have no-way of source upgrading from 8.X? ::> ::> We need newest world to build 9.x kernel, and need 9.x kernel t= o run ::> ::> newest world, and... ::> :: ::> :: No; you have to do something like the following: ::> :: ::> ::[kernel-]toolchain buildworld buildkernel. ::> :: ::> :: A plus side of doing this is that I do kernel-toolchain at -j= 12 ::> ::and then do buildworld buildkernel at -j12 as well. It's much qui= cker ::> ::than buildworld buildkernel at -j1, and less error prone than doi= ng it ::> ::at any other -j value in parallel. ::> :: The handbook just says buildworld buildkernel ( ::> ::http://www.freebsd.org/doc/handbook/makeworld.html ), and UPDATIN= G ::> ::just says kernel-toolchain buildkernel installkernel (look for "T= o ::> ::build a kernel"), but there aren't any official directions in the= ::> ::quick to find spots that mention those above steps. ::> = ::> Ahh, thanks for pointers. ::> I was just reading the "To upgrade in-place from 8.x-stable to curr= ent" ::> from UPDATING, which does not say anything about [kernel-]toolchain= .= ::> May by that part, and some others, also needs updating. ::You do not need to do anything with kernel-toolchain. THe proper ::procedure of buildworld/buildkernel just works. OK. Thanks for the confirmation. Haro From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 23 11:16:48 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id CD38F1065836; Wed, 23 Feb 2011 11:16:48 +0000 (UTC) Date: Wed, 23 Feb 2011 11:16:48 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20110223111648.GA41592@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="DocE+STaALJfprDB" Content-Disposition: inline Subject: [patch] off by one issue in sys/kern/kern_thr.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 11:16:48 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi there, i think the following should be changed. with kern.threads.max_threads_per_proc=N, a process should be able to maintain N threads and not N-1. to verify simply use tools/test/pthread_vfork. cheers. alex -- a13x --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kern_thr.c.diff" diff --git a/sys/kern/kern_thr.c b/sys/kern/kern_thr.c index 75656f0..63bf1bc 100644 --- a/sys/kern/kern_thr.c +++ b/sys/kern/kern_thr.c @@ -153,7 +153,7 @@ create_thread(struct thread *td, mcontext_t *ctx, p = td->td_proc; /* Have race condition but it is cheap. */ - if (p->p_numthreads >= max_threads_per_proc) { + if (p->p_numthreads > max_threads_per_proc) { ++max_threads_hits; return (EPROCLIM); } --DocE+STaALJfprDB-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 23 12:46:09 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBACF1065679 for ; Wed, 23 Feb 2011 12:46:09 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8B39F8FC22 for ; Wed, 23 Feb 2011 12:46:09 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:1131:79f:9a2b:b0a3] (unknown [IPv6:2001:7b8:3a7:0:1131:79f:9a2b:b0a3]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 5561B5C37; Wed, 23 Feb 2011 13:46:08 +0100 (CET) Message-ID: <4D650197.6010302@FreeBSD.org> Date: Wed, 23 Feb 2011 13:46:15 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.15pre) Gecko/20110221 Lanikai/3.1.9pre MIME-Version: 1.0 To: perryh@pluto.rain.com References: <4D63661D.2090205@gmail.com> <4D63AE83.5040007@FreeBSD.org> <4d64cc96.gh+SoZb8LSOAInQd%perryh@pluto.rain.com> In-Reply-To: <4d64cc96.gh+SoZb8LSOAInQd%perryh@pluto.rain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, gnehzuil@gmail.com Subject: Re: buildkernel error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 12:46:09 -0000 On 2011-02-23 10:00, perryh@pluto.rain.com wrote: > Will either "make buildworld" or "make kernel-toolchain" accomplish > anything if, as the OP said, s/he only updated the _kernel_ sources? No. You must update all sources atomically, or there is no guarantee it will build. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 23 13:11:39 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A6BF1065675 for ; Wed, 23 Feb 2011 13:11:39 +0000 (UTC) (envelope-from drbaud@yahoo.com) Received: from nm16.bullet.mail.sp2.yahoo.com (nm16.bullet.mail.sp2.yahoo.com [98.139.91.86]) by mx1.freebsd.org (Postfix) with SMTP id 05F7B8FC18 for ; Wed, 23 Feb 2011 13:11:38 +0000 (UTC) Received: from [98.139.91.66] by nm16.bullet.mail.sp2.yahoo.com with NNFMP; 23 Feb 2011 12:59:01 -0000 Received: from [98.139.91.27] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 23 Feb 2011 12:59:01 -0000 Received: from [127.0.0.1] by omp1027.mail.sp2.yahoo.com with NNFMP; 23 Feb 2011 12:59:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 118086.49250.bm@omp1027.mail.sp2.yahoo.com Received: (qmail 87202 invoked by uid 60001); 23 Feb 2011 12:59:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1298465940; bh=o4wVsklDvl4Y/OMImR4H1QnYuuyRuLMXOXDsiikubXk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=lMmfhu9IOLqsp+QOR6xEuDFeM54kPyz4YVX8bCS6IurcsYaYIuZA6NzGzSZ3rblspOJCkiDKyvU2iAA30OWlD5WH2mqGflitLRfZgI2dLzGVSydP/cEd67T5fOcbMt9Fvfbp/SKna6Th4v1iBE8Ba2bjQqupjp3ZwVgyt9RSnRQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=nZnC5Ajg2PESgIId5SWKcgIA1lpyq5VsubMZ+53hZg3WQ5apDsCDbYGBQzwIoPNJyswPf0uF99RavYdDRrAO/sSWLYQa5Tt+q80HaKv0F9Qn+jx70Uvjvryi+M3sYjV+5WrYpIYHMxL8o0bqae8vupawW3Gvo0bAYeGo6QppLRE=; Message-ID: <601918.80426.qm@web120714.mail.ne1.yahoo.com> X-YMail-OSG: 9yHaThMVM1mnlOj6Xf5vYKX5dUu8XhWoPbUDce2Y7PsPnfe 85pDC1ehVs6tNjFY9Efo6ILDXPZBJ1MXtBNWvZ1whEi8fTzNtxXqigYQcfpg WOwM5L7maBgoRcKgdCJKgzVuMqL33ISxEupIGgdf7rVnJyTlE29LzUN.otDh JjU4n3Bp5gcBjcjrlFeDVE901ILUu2RWzelusIkc0JHqKEueTB6lCOzv5Szv RuboW18z0qNhKmp6Otz2.7e5wZ_DVXqx99F2gL_XlQNGd4oomGIxM5r.nnTe P4VVEBS58Lk_cAp2A.ppF Received: from [64.238.244.146] by web120714.mail.ne1.yahoo.com via HTTP; Wed, 23 Feb 2011 04:59:00 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.109.292656 References: <137445.33642.qm@web120719.mail.ne1.yahoo.com> <20110218122136.GA78089@deviant.kiev.zoral.com.ua> Date: Wed, 23 Feb 2011 04:59:00 -0800 (PST) From: "Dr. Baud" To: freebsd-hackers@freebsd.org In-Reply-To: <20110218122136.GA78089@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Wed, 23 Feb 2011 13:47:36 +0000 Subject: Re: spontaneous reboot - ptrace X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 13:11:39 -0000 As it happens the NMI was caused by attempting to access memory mapped PCI address space. The HBA associated with the mapped PCI address space generated a PERR. Thanks for the help. ----- Original Message ---- From: Kostik Belousov To: Dr. Baud Cc: freebsd-hackers@freebsd.org Sent: Fri, February 18, 2011 6:21:36 AM Subject: Re: spontaneous reboot - ptrace On Fri, Feb 18, 2011 at 03:58:05AM -0800, Dr. Baud wrote: > > > > First, do you have a console output during the run ? Is it possible > > that machine paniced ? If not, were there any kernel messages before> > > reboot ? > > > > Second, what is the process you are dumping ? Can you show at least > > the procstat -v output for the process ? > > Sorry for this late response but my earlier response appears to have been > consumed by the email reflector. > > I'm getting an NMI. And the trouble appears to be when trying to > read via ptrace memory segments of type KVME_TYPE_DEVICE. The app in > quesion allocates a large number of large memory buffers and maps them > into virtual address space. Not all segments cause the NMI however. > Small sampling of the virtual memory map. You did not provided exact console output on the panic, despite requested. What is the device that was mmaped ? Obviously, this is your problem. Can you gather all required information ? > > PID START END PRT RES PRES REF SHD FL TP PATH > 931 0x400000 0x1773000 r-x 4239 5053 2 1 CN vn >/mnt/dia > g/problemchild > 931 0x1872000 0x2ef2000 rw- 416 0 1 0 C- vn >/mnt/dia > g/problemchld > 931 0x2ef2000 0x6700000 rw- 11765 0 1 0 C- df > 931 0x801872000 0x8018a2000 r-x 48 0 57 28 CN vn >/libexec > /ld-elf.so.1 > 931 0x8018a2000 0x8018b3000 rw- 15 0 1 0 C- df > 931 0x8018b3000 0x801924000 rw- 113 0 1698 0 -- dv > 931 0x801924000 0x801925000 rw- 1 0 1698 0 -- dv > 931 0x801925000 0x801926000 rw- 1 0 1698 0 -- dv > 931 0x801926000 0x801927000 rw- 1 0 1698 0 -- dv > 931 0x801927000 0x801928000 rw- 1 0 1698 0 -- dv > 931 0x801928000 0x80192a000 rw- 2 0 1698 0 -- dv > 931 0x80192a000 0x80192b000 rw- 1 0 1698 0 -- dv > 931 0x80192b000 0x80192c000 rw- 1 0 1698 0 -- dv > 931 0x80192c000 0x80192d000 rw- 1 0 1698 0 -- dv > 931 0x80192d000 0x80192e000 rw- 1 0 1698 0 -- dv > 931 0x80192e000 0x801930000 rw- 2 0 1698 0 -- dv > 931 0x801930000 0x801932000 rw- 2 0 1698 0 -- dv > 931 0x801932000 0x801993000 rw- 97 0 1698 0 -- dv > 931 0x801993000 0x8019a0000 rw- 13 0 1698 0 -- dv > 931 0x8019a0000 0x8019a1000 rw- 1 0 1698 0 -- dv > > .... > > 931 0x802ab7000 0x802bb7000 --- 0 0 1 0 CN df > 931 0x0x802bb70 0x0x802bd6000 rw- 17 0 1 0 C- vn >/lib/lib > c.so.7 > 931 0x802bd6000 0x802bf1000 rw- 18 0 1 0 C- df > 931 0x802bf1000 0x802bfd000 r-x 9 14 2 1 CN vn >/lib/lib > gcc_s.so.1 > 931 0x802bfd000 0x802cfc000 --- 0 0 1 0 CN df > 931 0x802cfc000 0x802cfe000 rw- 2 0 1 0 CN vn >/lib/lib > gcc_s.so.1 > 931 0x802cfe000 0x802cff000 rw- 1 0 1698 0 -- dv > 931 0x802cff000 0x802d00000 rw- 1 0 1698 0 -- dv > 931 0x802d00000 0x802e00000 rw- 132 0 1 0 C- df > 931 0x802e00000 0x802f00000 rw- 109 0 1 0 C- df > 931 0x802f00000 0x802f91000 rw- 145 0 1698 0 -- dv > 931 0x802f91000 0x802fb2000 rw- 33 0 1698 0 -- dv > 931 0x802fb2000 0x802fd3000 rw- 33 0 1698 0 -- dv > 931 0x802fd3000 0x802ff5000 rw- 34 0 1698 0 -- dv > 931 0x802ff5000 0x802ff6000 rw- 1 0 1698 0 -- dv > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 23 13:16:33 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 061461065674 for ; Wed, 23 Feb 2011 13:16:33 +0000 (UTC) (envelope-from drbaud@yahoo.com) Received: from nm6.bullet.mail.ne1.yahoo.com (nm6.bullet.mail.ne1.yahoo.com [98.138.90.69]) by mx1.freebsd.org (Postfix) with SMTP id AB1EA8FC1A for ; Wed, 23 Feb 2011 13:16:32 +0000 (UTC) Received: from [98.138.90.57] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 23 Feb 2011 13:03:28 -0000 Received: from [98.138.88.235] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 23 Feb 2011 13:03:28 -0000 Received: from [127.0.0.1] by omp1035.mail.ne1.yahoo.com with NNFMP; 23 Feb 2011 13:03:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 77379.90360.bm@omp1035.mail.ne1.yahoo.com Received: (qmail 95646 invoked by uid 60001); 23 Feb 2011 13:03:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1298466207; bh=SXtFFce1PmNS2wMtt+HpshMTYYqSAEWZs9TOTRuKkog=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=CuxrX2VBSiGVnkzrgb2BxjQtbFSgP+ZagAkxK/ZcpkrPgA9GCYQodv9EpUO/xEpy3mFbUQctulwhYGPJbaX9S3L+VEk6yeiMvqSxuOKHw4ZcoGbEbWFC7C0Rl5YDuIS3In+g81mZH0l2wfMX/k0oScCa+xbMhZ7kt+x2bWyZlOI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=WIYL9pBXHDZ9Yo3flPqdNG67LaqcViipxR/LbIGmVk4VyI+YI75LYhW07iX/QAa2qIWDrSLWLY7vcUPnKdowL5a/YHgHK5EvzI7RB4Ftfpi7lszMbQW/7PGWZTm4XfdNo48czVppNvQIKExVvSyz13HaAm6Sqmoy/ulL2eOGZE4=; Message-ID: <857081.94354.qm@web120706.mail.ne1.yahoo.com> X-YMail-OSG: VjeRn1EVM1mG59r3UQSUOeYZsCDwi7wf4znezZvKtWOkRTE cMcdDLl6yFtfyBDkNp02c0SYIr79rNZzaFF83ucMiB9XEg7o4NI_x2eL7fHb jgZWH.Md4tHO4RnnEVmg14.ZagcEcnAJ5KR2rBks1SakhEgWsW91RuSl8Pvm S_XlG2uuJwyy0pBRq5.V6LedVre7nb6bjIHvN6HHgj7OjH9_GqSIfo25j6uQ WMe.06MsC0F.bUj_kk51EeuyyrxBdiv2gHB4lC_KM Received: from [64.238.244.146] by web120706.mail.ne1.yahoo.com via HTTP; Wed, 23 Feb 2011 05:03:27 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.109.292656 Date: Wed, 23 Feb 2011 05:03:27 -0800 (PST) From: "Dr. Baud" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Wed, 23 Feb 2011 13:47:48 +0000 Subject: Super pages X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 13:16:33 -0000 In general, is it unadvisable to disable super pages? Dr. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 23 15:18:24 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30EBB106564A for ; Wed, 23 Feb 2011 15:18:24 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id C78018FC0A for ; Wed, 23 Feb 2011 15:18:23 +0000 (UTC) Received: by qyk27 with SMTP id 27so2699477qyk.13 for ; Wed, 23 Feb 2011 07:18:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=S3e0J/hprUuV1zQAfV/5xSYEsb1r8RJfkSrt/AGh6ZE=; b=w2cJwT1iFmPrp/ZvHjPQNe+rYuQxZYOiNtka3KSp+w64StXxkpU6CkLdPk9CsVkBH1 e3RcS99+rH2cIrVph40r+HYHGGKNQbGjucbYZGZMyi3v5orbCzJKr5ixvsqtpEbNINqA KmkFXTMwPHUdwJKdkzJek57pcaMTZQJHcH3vw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DEstpdkThB3xd7VCDy8ZH1GgCdJ+vTyml/PfUTU1lxiZ7sMVB1oNpMLy40pZQFNfWb r1Ekq0bdq7PzRAjhyYwBFXbyCgxxiaYvt10iUQKmBQd/te2zaENFKi8c5uZcDxwusDx7 /qc8MdOcQDJ4R90hN9HOCjepo6bFOEacG0r/A= MIME-Version: 1.0 Received: by 10.224.176.67 with SMTP id bd3mr3540777qab.110.1298474302851; Wed, 23 Feb 2011 07:18:22 -0800 (PST) Received: by 10.224.73.206 with HTTP; Wed, 23 Feb 2011 07:18:22 -0800 (PST) In-Reply-To: <201102220937.53075.jhb@freebsd.org> References: <201102220937.53075.jhb@freebsd.org> Date: Wed, 23 Feb 2011 16:18:22 +0100 Message-ID: From: Svatopluk Kraus To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: ichsmb - correct locking strategy? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 15:18:24 -0000 On Tue, Feb 22, 2011 at 3:37 PM, John Baldwin wrote: > On Friday, February 18, 2011 9:10:47 am Svatopluk Kraus wrote: >> Hi, >> >> =A0 I try to figure out locking strategy in FreeBSD and found 'ichsmb' >> device. There is a mutex which protects smb bus (ichsmb device). For >> example in ichsmb_readw() in sys/dev/ichsmb/ichsmb.c, the mutex is >> locked and a command is written to bus, then unbounded (but with >> timeout) sleep is done (mutex is unlocked during sleep). After sleep a >> word is read from bus and the mutex is unlocked. >> >> =A0 1. If an use of the device IS NOT serialized by layers around then >> more calls to this function (or others) can be started or even done >> before the first one is finished. The mutex don't protect sms bus. >> >> =A0 2. If an use of the device IS serialized by layers around then the >> mutex is useless. >> >> =A0 Moreover, I don't mension interrupt routine which uses the mutex and >> smb bus too. >> >> =A0 Am I right? Or did I miss something? > > Hmm, the mutex could be useful if you have an smb controller with an inte= rrupt > handler (I think ichsmb or maybe intpm can support an interrupt handler) = to > prevent concurrent access to device registers. =A0That is the purpose of = the > mutex at least. =A0There is a separate locking layer in smbus itself in (= see > smbus_request_bus(), etc.). > > -- > John Baldwin > I see. So, multiple accesses to bus are protected by upper smbus layer itself. And the mutex encloses each single access in respect of interrupt. I.e., an interrupt can be assigned to a command (bus is either command processing or idle) and a wait to command result can be done atomically (no wakeup is missed). Am I right? BTW, a mutex priority propagation isn't too much exploited here. Maybe, it will be better for me to not take this feature into account when thinking about locking strategy and just take a mutex in most cases as a low level locking primitive which is indeed. Well, it seems that things become more clear. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 23 15:56:41 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B31E6106564A for ; Wed, 23 Feb 2011 15:56:41 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 69DD98FC1A for ; Wed, 23 Feb 2011 15:56:41 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PsH4v-0002p0-4c for freebsd-hackers@freebsd.org; Wed, 23 Feb 2011 16:56:37 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Feb 2011 16:56:37 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Feb 2011 16:56:37 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Wed, 23 Feb 2011 16:56:22 +0100 Lines: 9 Message-ID: References: <857081.94354.qm@web120706.mail.ne1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <857081.94354.qm@web120706.mail.ne1.yahoo.com> X-Enigmail-Version: 1.1.2 Subject: Re: Super pages X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 15:56:41 -0000 On 23/02/2011 14:03, Dr. Baud wrote: > > In general, is it unadvisable to disable super pages? I don't think there would be any effect on the stability of operation if you disable superpages, but generally (except in cases of CPU bugs) you would not need to. Your system should operate a bit faster with superpages enabled. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 23 16:55:00 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64DC61065670 for ; Wed, 23 Feb 2011 16:55:00 +0000 (UTC) (envelope-from drbaud@yahoo.com) Received: from nm6.bullet.mail.ne1.yahoo.com (nm6.bullet.mail.ne1.yahoo.com [98.138.90.69]) by mx1.freebsd.org (Postfix) with SMTP id 2AE0F8FC0A for ; Wed, 23 Feb 2011 16:54:59 +0000 (UTC) Received: from [98.138.90.57] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 23 Feb 2011 16:54:59 -0000 Received: from [98.138.89.234] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 23 Feb 2011 16:54:59 -0000 Received: from [127.0.0.1] by omp1049.mail.ne1.yahoo.com with NNFMP; 23 Feb 2011 16:54:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 543518.81854.bm@omp1049.mail.ne1.yahoo.com Received: (qmail 2668 invoked by uid 60001); 23 Feb 2011 16:54:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1298480099; bh=zVC15ZeKiF6GxRkoTUozSx3xmrfHOTBIHMfbA58097E=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=sA6pSy0bi38lSZNFo3+9KjzK2Kc/Cs/TJddcZAMIEG6qG3FlyzFEp3ZLTQFwixkYFEM9CuNNwS+snJ0+K+zH/nRjZ3QA6FziUmxkbb9hxGG2ocTR3u2FLrRNAU2jIINnZEQ8KpT6R2FupaDQm/1NEzanjuJb8ksd0S54uRbUBi0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=ZBrHB+bN2hmT1jtFyJFGFaeQxyY1hU3a10saC1TJHEkBXrGVU01PS+aJgeCqefJ6qQH2hrtIKyJF2eWk0GAvrL3eV2PRzXTt5bCaDBq+4WAm8ZWwlSSMcpM8UCb6gfVn280eT8bOG80rl3J82b6h5k0gi9NVJ0lt1WHqjHTWx/s=; Message-ID: <365029.99890.qm@web120713.mail.ne1.yahoo.com> X-YMail-OSG: GbNlA8EVM1kRU0cbQCI4XQjHWjFB0Pqx5bilHm7xWXuhiwf EY4R4e3o6LUhrKk54sM_2YXU6H3YymWuPac4FQhbnvldm1p1vNqmcdYYLtPz j6PShWMwJKYTt_Fwx3lmG6csewMP8VTf7SrOmC57ZfofDoLDmlbXfHXrnTbp QNNlhQSHDGXlmRUg7NQA8lPG342WqdRNAVBcIUp8NDp24JCuCfbXCvGJaBA9 Xvd25Ddrd_CTDc5QynfrLrathAzp0B3EeS1D0SIC1 Received: from [64.238.244.146] by web120713.mail.ne1.yahoo.com via HTTP; Wed, 23 Feb 2011 08:54:59 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.109.292656 Date: Wed, 23 Feb 2011 08:54:59 -0800 (PST) From: "Dr. Baud" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1873715402-1298480099=:99890" X-Mailman-Approved-At: Wed, 23 Feb 2011 16:59:50 +0000 Subject: Re: Super pages X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 16:55:00 -0000 --0-1873715402-1298480099=:99890 Content-Type: text/plain; charset=us-ascii > On 23/02/2011 14:03, Dr. Baud wrote: > > > > In general, is it unadvisable to disable super pages? > > I don't think there would be any effect on the stability of operation if > you disable superpages, but generally (except in cases of CPU bugs) you > would not need to. Your system should operate a bit faster with > superpages enabled. When is the memory allocated via contigmalloc freed? I have a test kernel module that allocates memory in 8MB chucks until contigmalloc says enough (the ginormous.c/Makefile attachment). I also have a bash script that displays the interesting memory related kernel state variables (the mem attachement). When I load and unload the kernel module and display the VM pages stats I never see the wired pages nor free pages change: vm.pmap.pg_ps_enabled: 1 SYSTEM MEMORY INFORMATION: mem_phys: = 2138693632 ( 2039MB) Physical memory tunable mem_user: = 2107297792 ( 2009MB) User space memory available mem_real: = 2146893824 ( 2047MB) Maximum physical pages mem_all: = 2075402240 ( 1979MB) [100%] Virual memory pages mem_cache: = 0 ( 0MB) [ 0%] Cached: almost avail. to allocat mem_inactive:= 7360512 ( 7MB) [ 0%] Inactive: recently unreferenced mem_active: + 8765440 ( 8MB) [ 0%] Active: recently referenced mem_wire: 31395840 ( 29MB) [ 1%] Wired: disabled for paging out mem_free: + 2027589632 ( 1933MB) [ 97%] Free: fully available -------------- ------------ ----------- mem_hw: = 2147483648 ( 2048MB) Virual memory (cached, etc.) kldload /sys/modules/ginormous/ginormous.ko Ginormous module loading Ginormous contigmalloc failed(229): SYSTEM MEMORY INFORMATION: mem_phys: = 2138693632 ( 2039MB) Physical memory tunable mem_user: = 180330496 ( 171MB) User space memory available mem_real: = 2146893824 ( 2047MB) Maximum physical pages mem_all: = 2075402240 ( 1979MB) [100%] Virual memory pages mem_cache: = 22237184 ( 21MB) [ 1%] Cached: almost avail. to allocat mem_inactive:= 253952 ( 0MB) [ 0%] Inactive: recently unreferenced mem_active: + 2387968 ( 2MB) [ 0%] Active: recently referenced mem_wire: 1958363136 ( 1867MB) [ 94%] Wired: disabled for paging out mem_free: + 91795456 ( 87MB) [ 4%] Free: fully available -------------- ------------ ----------- mem_hw: = 2147483648 ( 2048MB) Virual memory (cached, etc.) kldunload ginormous Ginormous module unloading Warning: memory type GINORMOUS leaked memory on destroy (229 allocations, 1920991232 bytes leaked). SYSTEM MEMORY INFORMATION: mem_phys: = 2138693632 ( 2039MB) Physical memory tunable mem_user: = 180314112 ( 171MB) User space memory available mem_real: = 2146893824 ( 2047MB) Maximum physical pages mem_all: = 2075402240 ( 1979MB) [100%] Virual memory pages mem_cache: = 21565440 ( 20MB) [ 1%] Cached: almost avail. to allocat mem_inactive:= 413696 ( 0MB) [ 0%] Inactive: recently unreferenced mem_active: + 2842624 ( 2MB) [ 0%] Active: recently referenced mem_wire: 1958379520 ( 1867MB) [ 94%] Wired: disabled for paging out mem_free: + 91807744 ( 87MB) [ 4%] Free: fully available -------------- ------------ ----------- mem_hw: = 2147483648 ( 2048MB) Virual memory (cached, etc.) Note that this behavior occurs whether superpages are enabled or not. Anyone have and explanation? Dr. --0-1873715402-1298480099=:99890 Content-Type: text/plain; name="ginormous.c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ginormous.c" I2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8c3lzL21vZHVsZS5o PgojaW5jbHVkZSA8c3lzL21hbGxvYy5oPgojaW5jbHVkZSA8c3lzL3N5c3Rt Lmg+ICAvKiB1cHJpbnRmICovCiNpbmNsdWRlIDxzeXMvcGFyYW0uaD4gIC8q IGRlZmluZXMgdXNlZCBpbiBrZXJuZWwuaCAqLwojaW5jbHVkZSA8c3lzL2tl cm5lbC5oPiAvKiB0eXBlcyB1c2VkIGluIG1vZHVsZSBpbml0aWFsaXphdGlv biAqLwojaW5jbHVkZSA8c3lzL2NvbmYuaD4gICAvKiBjZGV2c3cgc3RydWN0 ICovCgpNQUxMT0NfREVGSU5FKE1fR0lOT1JNT1VTLCAiR0lOT1JNT1VTIiwg Ikdpbm9ybW91cyBLZXJuZWwgTW9kdWxlIik7CgojZGVmaW5lIEJVRlNJWkUg KDgqMTAyNCoxMDI0KQojZGVmaW5lIE5NQUxMT0NTIDI0MQoKc3RhdGljIGlu dApnaW5vcm1vdXNfbG9hZGVyKHN0cnVjdCBtb2R1bGUgKm0sIGludCB3aGF0 LCB2b2lkICphcmcpCnsKICAgIGludCBlcnIgPSAwOwogICAgdm9pZCAqbWVt W05NQUxMT0NTXTsKCiAgICBzd2l0Y2ggKHdoYXQpCiAgICB7CiAgICBjYXNl IE1PRF9MT0FEOiAgICAgICAgICAgICAgICAvKiBrbGRsb2FkICovCiAgICAg ICAgewogICAgICAgIGludCBpOwoKICAgICAgICBwcmludGYoIkdpbm9ybW91 cyBtb2R1bGUgbG9hZGluZ1xuIik7CgogICAgICAgIGZvciAoaSA9IDA7IGkg PCBOTUFMTE9DUzsgaSsrKSB7CiAgICAgICAgICAgIGlmICgobWVtW2ldID0g Y29udGlnbWFsbG9jKCBCVUZTSVpFLAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgTV9HSU5PUk1PVVMsIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgMCwgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAwVUwsIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfjBVTCwgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQQUdFX1NJWkUsCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwKSkgPT0gTlVM TCkgewogICAgICAgICAgICAgICAgcHJpbnRmKCJHaW5vcm1vdXMgY29udGln bWFsbG9jIGZhaWxlZCglZCk6XG4iLCBpKTsKICAgICAgICAgICAgICAgIGJy ZWFrOwogICAgICAgICAgICB9CiAgICAgICAgfQogICAgICAgIH0KICAgICAg ICBicmVhazsKCiAgICBjYXNlIE1PRF9VTkxPQUQ6CiAgICAgICAgcHJpbnRm KCJHaW5vcm1vdXMgbW9kdWxlIHVubG9hZGluZ1xuIik7CiAgICAgICAgYnJl YWs7CgogICAgZGVmYXVsdDoKICAgICAgICBlcnIgPSBFSU5WQUw7CiAgICAg ICAgYnJlYWs7CiAgICB9CiAgICByZXR1cm4oZXJyKTsKfQoKREVWX01PRFVM RShnaW5vcm1vdXMsIGdpbm9ybW91c19sb2FkZXIsIE5VTEwpOwo= --0-1873715402-1298480099=:99890 Content-Type: application/octet-stream; name=Makefile Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Makefile" LlBBVEg6ICAkey5DVVJESVJ9Ly4uLy4uL2Rldi9naW5vcm1vdXMKS01PRCAg ICA9IGdpbm9ybW91cwpTUkNTICAgID0gZ2lub3Jtb3VzLmMKCkNGTEFHUys9 IC1JJHsuQ1VSRElSfS8uLi8uLi9kZXYvZ2lub3Jtb3VzIC1nIC1XYWxsIC1X ZXJyb3IKQ0ZMQUdTKz0gLURWRVJTSU9OPVwiJChWRVJTSU9OKVwiCgpjbGVh bjoKCXJtIC1mICoubyAqLmtsZCAqLmtvCglybSAtZiBAIG1hY2hpbmUKCXJt IC1mICR7Q0xFQU5GSUxFU30KCi5pbmNsdWRlIDxic2Qua21vZC5taz4K --0-1873715402-1298480099=:99890 Content-Type: application/octet-stream; name=mem Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mem" IyEvdXNyL2xvY2FsL2Jpbi9iYXNoCgpyZXR1cm5fdmFsPQoKKChhbWVnID0g KDEwMjQqMTAyNCkgKSkKCmluZm9bMF09IlBoeXNpY2FsIG1lbW9yeSB0dW5h YmxlIiAgICAgICAgICAgICAgICMgbWVtX3BoeXMKaW5mb1sxXT0iVXNlciBz cGFjZSBtZW1vcnkgYXZhaWxhYmxlIiAgICAgICAgICAgIyBtZW1fdXNlciAo bWVtX3BoeXMtbWVtX3dpcmVkKQppbmZvWzJdPSJNYXhpbXVtIHBoeXNpY2Fs IHBhZ2VzIiAgICAgICAgICAgICAgICAjIG1lbV9yZWFsCmluZm9bNF09IlZp cnVhbCBtZW1vcnkgcGFnZXMiICAgICAgICAgICAgICAgICAgICMgbWVtX3Zt X3BhZ2VzCmluZm9bNV09IkNhY2hlZDogYWxtb3N0IGF2YWlsLiB0byBhbGxv Y2F0IiAgICAgICMgbWVtX2NhY2hlCmluZm9bNl09IkluYWN0aXZlOiByZWNl bnRseSB1bnJlZmVyZW5jZWQiICAgICAgICMgbWVtX2luYWN0aXZlCmluZm9b N109IkFjdGl2ZTogcmVjZW50bHkgcmVmZXJlbmNlZCIgICAgICAgICAgICMg bWVtX2FjdGl2ZQppbmZvWzhdPSJXaXJlZDogZGlzYWJsZWQgZm9yIHBhZ2lu ZyBvdXQiICAgICAgICAjIG1lbV93aXJlCmluZm9bOV09IkZyZWU6IGZ1bGx5 IGF2YWlsYWJsZSIgICAgICAgICAgICAgICAgICMgbWVtX2ZyZWUKaW5mb1sx MF09IlZpcnVhbCBtZW1vcnkgKGNhY2hlZCwgZXRjLikiICAgICAgICAgIyBt ZW1fdm0KCgptZW1fcm91bmRlZCAoKQp7CiAgICAoKCBjaGlwX3NpemUgPSAx ICkpCiAgICAoKCBjaGlwX2d1ZXNzID0gKCQxIC8gOCkgLSAxKSkKICAgIGZv ciAoKCA7IGNoaXBfZ3Vlc3MgIT0gMCA7ICkpCiAgICBkbwogICAgICAgICgo IGNoaXBfZ3Vlc3MgPSBjaGlwX2d1ZXNzID4+IDEgKSkKICAgICAgICAoKCBj aGlwX3NpemUgPSBjaGlwX3NpemUgPDwgMSApKQogICAgZG9uZQoKICAgICgo IHJldHVybl92YWwgPSAoKCQxIC8gJGNoaXBfc2l6ZSkgKyAxKSAqICRjaGlw X3NpemUgKSkKCiAgICByZXR1cm4gCn0KCgpNRU1fUEhZUz1gc3lzY3RsIC1l IGh3LnBoeXNtZW1gCk1FTV9VU0VSPWBzeXNjdGwgLWUgaHcudXNlcm1lbWAK TUVNX1JFQUw9YHN5c2N0bCAtZSBody5yZWFsbWVtYApNRU1fVk1fUEFHRVM9 YHN5c2N0bCAtZSB2bS5zdGF0cy52bS52X3BhZ2VfY291bnRgCk1FTV9DQUNI RT1gc3lzY3RsIC1lIHZtLnN0YXRzLnZtLnZfY2FjaGVfY291bnRgCk1FTV9J TkFDVElWRT1gc3lzY3RsIC1lIHZtLnN0YXRzLnZtLnZfaW5hY3RpdmVfY291 bnRgCk1FTV9BQ1RJVkU9YHN5c2N0bCAtZSB2bS5zdGF0cy52bS52X2FjdGl2 ZV9jb3VudGAKTUVNX1dJUkU9YHN5c2N0bCAtZSB2bS5zdGF0cy52bS52X3dp cmVfY291bnRgCk1FTV9GUkVFPWBzeXNjdGwgLWUgdm0uc3RhdHMudm0udl9m cmVlX2NvdW50YApQQUdFX1NJWkU9YHN5c2N0bCAtZSBody5wYWdlc2l6ZWAK CgojICAgZGV0ZXJtaW5lIHRoZSBpbmRpdmlkdWFsIGtub3duIGluZm9ybWF0 aW9uCm1lbV9waHlzPSR7TUVNX1BIWVMjaHcucGh5c21lbT19Cm1lbV9yb3Vu ZGVkICRtZW1fcGh5cwptZW1faHc9JHJldHVybl92YWwKcGFnZV9zaXplPSR7 UEFHRV9TSVpFI2h3LnBhZ2VzaXplPX0KCgptZW1fdXNlcj0kKCgke01FTV9V U0VSI2h3LnVzZXJtZW09fSkpCm1lbV9yZWFsPSQoKCR7TUVNX1JFQUwjaHcu cmVhbG1lbT19KSkKbWVtX2FsbD0kKCgke01FTV9WTV9QQUdFUyN2bS5zdGF0 cy52bS52X3BhZ2VfY291bnQ9fSAqICRwYWdlX3NpemUpKQptZW1fY2FjaGU9 JCgoJHtNRU1fQ0FDSEUjdm0uc3RhdHMudm0udl9jYWNoZV9jb3VudD19ICog JHBhZ2Vfc2l6ZSkpCm1lbV9pbmFjdGl2ZT0kKCgke01FTV9JTkFDVElWRSN2 bS5zdGF0cy52bS52X2luYWN0aXZlX2NvdW50PX0gKiAkcGFnZV9zaXplKSkK bWVtX2FjdGl2ZT0kKCgke01FTV9BQ1RJVkUjdm0uc3RhdHMudm0udl9hY3Rp dmVfY291bnQ9fSAqICRwYWdlX3NpemUpKQptZW1fd2lyZT0kKCgke01FTV9X SVJFI3ZtLnN0YXRzLnZtLnZfd2lyZV9jb3VudD19ICogJHBhZ2Vfc2l6ZSkp Cm1lbV9mcmVlPSQoKCR7TUVNX0ZSRUUjdm0uc3RhdHMudm0udl9mcmVlX2Nv dW50PX0gKiAkcGFnZV9zaXplKSkKCgojICAgZGV0ZXJtaW5lIGxvZ2ljYWwg c3VtbWFyeSBpbmZvcm1hdGlvbgptZW1fdm09PSQoKCRtZW1fY2FjaGVkICsg JG1lbV9pbmFjdGl2ZSArICRtZW1fYWN0aXZlICsgJG1lbV93aXJlZCArICRt ZW1fZnJlZSkpCgojICAgcHJpbnQgc3lzdGVtIHJlc3VsdHMKcHJpbnRmICJT WVNURU0gTUVNT1JZIElORk9STUFUSU9OOlxuIgpwcmludGYgIm1lbV9waHlz OiAgICA9ICUxMmQgKCU3ZE1CKSAgICAgICAgJXNcbiIgJG1lbV9waHlzICQo KCRtZW1fcGh5cyAvICRhbWVnKSkgIiR7aW5mb1swXX0iCnByaW50ZiAibWVt X3VzZXI6ICAgID0gJTEyZCAoJTdkTUIpICAgICAgICAlc1xuIiAkbWVtX3Vz ZXIgJCgoJG1lbV91c2VyIC8gJGFtZWcpKSAiJHtpbmZvWzFdfSIKcHJpbnRm ICJtZW1fcmVhbDogICAgPSAlMTJkICglN2RNQikgICAgICAgICVzXG4iICRt ZW1fcmVhbCAkKCgkbWVtX3JlYWwgLyAkYW1lZykpICIke2luZm9bMl19Igpw cmludGYgIm1lbV9hbGw6ICAgICA9ICUxMmQgKCU3ZE1CKSBbMTAwJSVdICVz XG4iICRtZW1fYWxsICQoKCRtZW1fYWxsIC8gJGFtZWcpKSAiJHtpbmZvWzRd fSIKcHJpbnRmICJtZW1fY2FjaGU6ICAgPSAlMTJkICglN2RNQikgWyUzZCUl XSAlc1xuIiAkbWVtX2NhY2hlICQoKCRtZW1fY2FjaGUgLyAkYW1lZykpICQo KCAoJG1lbV9jYWNoZSAqIDEwMCkgLyAkbWVtX2FsbCApKSAiJHtpbmZvWzVd fSIKcHJpbnRmICJtZW1faW5hY3RpdmU6PSAlMTJkICglN2RNQikgWyUzZCUl XSAlc1xuIiAkbWVtX2luYWN0aXZlICQoKCRtZW1faW5hY3RpdmUgLyAkYW1l ZykpICQoKCAoJG1lbV9pbmFjdGl2ZSAqIDEwMCkgLyAkbWVtX2FsbCApKSAi JHtpbmZvWzZdfSIKcHJpbnRmICJtZW1fYWN0aXZlOiAgKyAlMTJkICglN2RN QikgWyUzZCUlXSAlc1xuIiAkbWVtX2FjdGl2ZSAkKCgkbWVtX2FjdGl2ZSAv ICRhbWVnKSkgJCgoICgkbWVtX2FjdGl2ZSAqIDEwMCkgLyAkbWVtX2FsbCAp KSAiJHtpbmZvWzddfSIKcHJpbnRmICJtZW1fd2lyZTogICAgICAlMTJkICgl N2RNQikgWyUzZCUlXSAlc1xuIiAkbWVtX3dpcmUgJCgoJG1lbV93aXJlIC8g JGFtZWcpKSAkKCggKCRtZW1fd2lyZSAqIDEwMCkgLyAkbWVtX2FsbCApKSAi JHtpbmZvWzhdfSIKcHJpbnRmICJtZW1fZnJlZTogICAgKyAlMTJkICglN2RN QikgWyUzZCUlXSAlc1xuIiAkbWVtX2ZyZWUgJCgoJG1lbV9mcmVlIC8gJGFt ZWcpKSAkKCggKCRtZW1fZnJlZSAqIDEwMCkgLyAkbWVtX2FsbCApKSAiJHtp bmZvWzldfSIKZWNobyAiLS0tLS0tLS0tLS0tLS0gLS0tLS0tLS0tLS0tIC0t LS0tLS0tLS0tIgpwcmludGYgIm1lbV9odzogICAgICA9ICUxMmQgKCU3ZE1C KSAgICAgICAgJXNcbiIgJG1lbV9odyAkKCgkbWVtX2h3IC8gJGFtZWcpKSAi JHtpbmZvWzEwXX0iCg== --0-1873715402-1298480099=:99890-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 23 18:56:59 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C5211065670 for ; Wed, 23 Feb 2011 18:56:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5D17A8FC17 for ; Wed, 23 Feb 2011 18:56:59 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E5C1646B1A; Wed, 23 Feb 2011 13:56:58 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2658A8A009; Wed, 23 Feb 2011 13:56:58 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 23 Feb 2011 13:56:51 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <365029.99890.qm@web120713.mail.ne1.yahoo.com> In-Reply-To: <365029.99890.qm@web120713.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201102231356.51176.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 23 Feb 2011 13:56:58 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: "Dr. Baud" Subject: Re: Super pages X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 18:56:59 -0000 On Wednesday, February 23, 2011 11:54:59 am Dr. Baud wrote: > > On 23/02/2011 14:03, Dr. Baud wrote: > > > > > > In general, is it unadvisable to disable super pages? > > > > I don't think there would be any effect on the stability of operation if > > you disable superpages, but generally (except in cases of CPU bugs) you > > would not need to. Your system should operate a bit faster with > > superpages enabled. > > When is the memory allocated via contigmalloc freed? I have a test kernel > module that allocates memory in 8MB chucks until contigmalloc says enough (the > ginormous.c/Makefile attachment). I also have a bash script that displays the > interesting memory related kernel state variables (the mem attachement). > When I load and unload the kernel module and display the VM pages stats I > never see the wired pages nor free pages change: Err, it's freed when you call contigfree(). If you leak the memory when you do a kldunload, it is just lost until you reboot. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 23 23:04:52 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BC58106566C; Wed, 23 Feb 2011 23:04:52 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id C6B778FC0A; Wed, 23 Feb 2011 23:04:51 +0000 (UTC) Received: by pxi20 with SMTP id 20so771926pxi.13 for ; Wed, 23 Feb 2011 15:04:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to:x-mailer; bh=BqrNEvnL+Et0IYmDX+McDcvB866afNSWteBcHH6PvCg=; b=mdzsxmXVlBSyQowTtE8ddEKFYDv4i2pjWdFy0nWviU5luy/rlhvPsb/is8XYRtXCJ/ StxVkMxUP2XrTKwHNurmuW2mZZWlZmhwuQr8V4QRp/Ya5mh1maTTb5FC0u0Td/yyjWJz y/JZRvXbPDiPBkymj4QPRNWYOzRdBfq0L2vdA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=TATSX+lnW3Kwa2ZwAoMl343MoTucqyBZv2X8YkqGHGtnUrxD0ZMKLyK7q4DMWU9dbV wkyrXyTzfmkF5fZUpnY3RVdzGBMQ97DIScde/vPFj3g1T1qDua2q943cYtcZmiTAiMR0 9hTjskjX3RKfqZITYUH43RaEIeLS0u/n+EoDo= Received: by 10.142.125.3 with SMTP id x3mr34173wfc.402.1298502291227; Wed, 23 Feb 2011 15:04:51 -0800 (PST) Received: from dhcp-173-37-1-90.cisco.com (nat.ironport.com [63.251.108.100]) by mx.google.com with ESMTPS id w19sm7383854wfd.8.2011.02.23.15.04.48 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Feb 2011 15:04:49 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) From: Garrett Cooper In-Reply-To: <201102221251.33717.jhb@freebsd.org> Date: Wed, 23 Feb 2011 15:04:47 -0800 Message-Id: <3A287E45-A369-4C7A-BA8E-A205679AC0BC@gmail.com> References: <20110222141112.GA98964@freebsd.org> <201102221251.33717.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, Alexander Best , Garrett Cooper Subject: Re: seeking into /dev/{null,zero} X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 23:04:52 -0000 On Feb 22, 2011, at 9:51 AM, John Baldwin wrote: > On Tuesday, February 22, 2011 11:46:05 am Garrett Cooper wrote: >> (Please bottom post) >>=20 >> On Tue, Feb 22, 2011 at 8:31 AM, Andrew Duane = wrote: >>> I thought seeking past EOF was valid; writing something creates a = file=20 > with a hole in it. I always assumed that was standard semantics. >>=20 >> That's with SET_HOLE/SET_DATA though, correct? If so, outside of >> that functionality I would assume relatively standard POSIX = semantics. >=20 > Err, no, you can always seek past EOF and then call write(2) to extend = a file=20 > (it does an implicit ftruncate(2)). SEEK_HOLE and SEEK_DATA are = different,=20 > they are just used to discover sparse regions within a file. >=20 > =46rom the manpage: >=20 > The lseek() system call allows the file offset to be set beyond = the end > of the existing end-of-file of the file. If data is later written = at > this point, subsequent reads of the data in the gap return bytes = of zeros > (until data is actually written into the gap). You're correct. Linux (Fedora 13) isn't POSIX compliant (this is = from the official POSIX text): The lseek ( ) function shall allow the file offset to be set beyond the = end of the existing data in the file. If data is later written at this = point, subsequent reads of data in the gap shall return bytes with the = value 0 until data is actually written into the gap. Thanks! -Garrett= From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 23 23:36:13 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id F31CA1065670; Wed, 23 Feb 2011 23:36:12 +0000 (UTC) Date: Wed, 23 Feb 2011 23:36:12 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20110223233612.GA46124@freebsd.org> References: <20110222141112.GA98964@freebsd.org> <201102221251.33717.jhb@freebsd.org> <3A287E45-A369-4C7A-BA8E-A205679AC0BC@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A287E45-A369-4C7A-BA8E-A205679AC0BC@gmail.com> Cc: freebsd-hackers@freebsd.org, John Baldwin , Garrett Cooper Subject: Re: seeking into /dev/{null,zero} X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 23:36:13 -0000 On Wed Feb 23 11, Garrett Cooper wrote: > On Feb 22, 2011, at 9:51 AM, John Baldwin wrote: > > > On Tuesday, February 22, 2011 11:46:05 am Garrett Cooper wrote: > >> (Please bottom post) > >> > >> On Tue, Feb 22, 2011 at 8:31 AM, Andrew Duane wrote: > >>> I thought seeking past EOF was valid; writing something creates a file > > with a hole in it. I always assumed that was standard semantics. > >> > >> That's with SET_HOLE/SET_DATA though, correct? If so, outside of > >> that functionality I would assume relatively standard POSIX semantics. > > > > Err, no, you can always seek past EOF and then call write(2) to extend a file > > (it does an implicit ftruncate(2)). SEEK_HOLE and SEEK_DATA are different, > > they are just used to discover sparse regions within a file. > > > > From the manpage: > > > > The lseek() system call allows the file offset to be set beyond the end > > of the existing end-of-file of the file. If data is later written at > > this point, subsequent reads of the data in the gap return bytes of zeros > > (until data is actually written into the gap). > > You're correct. Linux (Fedora 13) isn't POSIX compliant (this is from the official POSIX text): > > The lseek ( ) function shall allow the file offset to be set beyond the end of the existing data in the file. If data is later written at this point, subsequent reads of data in the gap shall return bytes with the value 0 until data is actually written into the gap. so except for reading from /dev/zero freebsd also isn't posix compliant, right? will this patch fix writing to /dev/{zero,null}? diff --git a/sys/dev/null/null.c b/sys/dev/null/null.c index 3005c19..aa9fa87 100644 --- a/sys/dev/null/null.c +++ b/sys/dev/null/null.c @@ -71,6 +71,7 @@ static void *zbuf; static int null_write(struct cdev *dev __unused, struct uio *uio, int flags __unused) { + uio->uio_offset += uio->uio_resid; uio->uio_resid = 0; return (0); cheers. alex > > Thanks! > -Garrett -- a13x From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 23 23:53:55 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id B884E1065675; Wed, 23 Feb 2011 23:53:55 +0000 (UTC) Date: Wed, 23 Feb 2011 23:53:55 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20110223235355.GA48790@freebsd.org> References: <20110222141112.GA98964@freebsd.org> <201102221251.33717.jhb@freebsd.org> <3A287E45-A369-4C7A-BA8E-A205679AC0BC@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A287E45-A369-4C7A-BA8E-A205679AC0BC@gmail.com> Cc: freebsd-hackers@freebsd.org, John Baldwin , Garrett Cooper Subject: Re: seeking into /dev/{null,zero} X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 23:53:55 -0000 On Wed Feb 23 11, Garrett Cooper wrote: > On Feb 22, 2011, at 9:51 AM, John Baldwin wrote: > > > On Tuesday, February 22, 2011 11:46:05 am Garrett Cooper wrote: > >> (Please bottom post) > >> > >> On Tue, Feb 22, 2011 at 8:31 AM, Andrew Duane wrote: > >>> I thought seeking past EOF was valid; writing something creates a file > > with a hole in it. I always assumed that was standard semantics. > >> > >> That's with SET_HOLE/SET_DATA though, correct? If so, outside of > >> that functionality I would assume relatively standard POSIX semantics. > > > > Err, no, you can always seek past EOF and then call write(2) to extend a file > > (it does an implicit ftruncate(2)). SEEK_HOLE and SEEK_DATA are different, > > they are just used to discover sparse regions within a file. on the other hand POSIX says: "The behavior of lseek() on devices which are incapable of seeking is implementation-defined. The value of the file offset associated with such a device is undefined." ...if we define /dev/{zero,null} as incapable of seeking the current implementation should be ok. > > > > From the manpage: > > > > The lseek() system call allows the file offset to be set beyond the end > > of the existing end-of-file of the file. If data is later written at > > this point, subsequent reads of the data in the gap return bytes of zeros > > (until data is actually written into the gap). > > You're correct. Linux (Fedora 13) isn't POSIX compliant (this is from the official POSIX text): > > The lseek ( ) function shall allow the file offset to be set beyond the end of the existing data in the file. If data is later written at this point, subsequent reads of data in the gap shall return bytes with the value 0 until data is actually written into the gap. > > Thanks! > -Garrett -- a13x From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 24 00:15:22 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 858C3106564A; Thu, 24 Feb 2011 00:15:22 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 850908FC14; Thu, 24 Feb 2011 00:15:21 +0000 (UTC) Received: by wyb32 with SMTP id 32so18767wyb.13 for ; Wed, 23 Feb 2011 16:15:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=To7irkHGXnIXdwsEud19Dvfds1nkdyuuiMDn5iQaH0c=; b=NRTjLwlBUHJ8TZsUauroWFb2gVRDMvMz8n8aW5X9QhRCGOvfzQAY1hKd4iovc9WCzw mdkfWpkKMFqhLFa/RXdOR9ncIeuB64JfJHehIaWhsciLjKl/jt62FLBcRHPCQXxJGnDm Q/uG8YSlrQawyQswbw6JsnJ5TzqNKsJoeYek4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gSCO31uQ95rswly3TLjylNhZq+fpimMoab5PxG0u9s2nwYxv4nhj6XLxpjzYu1RZ7i 804yoYRLsX5HsmZFuGKeyAmmAbw+bGBLLyfvS+MYmUmbhEHCqL2zGGwe7phJubSdb+n2 gVGOp4TsPcBb3xhgCwkKq4tLl/c3uXbGztoJQ= MIME-Version: 1.0 Received: by 10.216.173.7 with SMTP id u7mr5170271wel.50.1298506520275; Wed, 23 Feb 2011 16:15:20 -0800 (PST) Received: by 10.216.15.74 with HTTP; Wed, 23 Feb 2011 16:15:20 -0800 (PST) In-Reply-To: <20110223233612.GA46124@freebsd.org> References: <20110222141112.GA98964@freebsd.org> <201102221251.33717.jhb@freebsd.org> <3A287E45-A369-4C7A-BA8E-A205679AC0BC@gmail.com> <20110223233612.GA46124@freebsd.org> Date: Wed, 23 Feb 2011 16:15:20 -0800 Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: seeking into /dev/{null,zero} X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 00:15:22 -0000 On Wed, Feb 23, 2011 at 3:36 PM, Alexander Best wrote= : > On Wed Feb 23 11, Garrett Cooper wrote: >> On Feb 22, 2011, at 9:51 AM, John Baldwin wrote: >> >> > On Tuesday, February 22, 2011 11:46:05 am Garrett Cooper wrote: >> >> (Please bottom post) >> >> >> >> On Tue, Feb 22, 2011 at 8:31 AM, Andrew Duane wr= ote: >> >>> I thought seeking past EOF was valid; writing something creates a fi= le >> > with a hole in it. I always assumed that was standard semantics. >> >> >> >> =A0 =A0That's with SET_HOLE/SET_DATA though, correct? If so, outside = of >> >> that functionality I would assume relatively standard POSIX semantics= . >> > >> > Err, no, you can always seek past EOF and then call write(2) to extend= a file >> > (it does an implicit ftruncate(2)). =A0SEEK_HOLE and SEEK_DATA are dif= ferent, >> > they are just used to discover sparse regions within a file. >> > >> > From the manpage: >> > >> > =A0 =A0 The lseek() system call allows the file offset to be set beyon= d the end >> > =A0 =A0 of the existing end-of-file of the file. =A0If data is later w= ritten at >> > =A0 =A0 this point, subsequent reads of the data in the gap return byt= es of zeros >> > =A0 =A0 (until data is actually written into the gap). >> >> =A0 =A0 =A0 You're correct. Linux (Fedora 13) isn't POSIX compliant (thi= s is from the official POSIX text): >> >> The lseek ( ) function shall allow the file offset to be set beyond the = end of the existing data in the file. If data is later written at this poin= t, subsequent reads of data in the gap shall return bytes with the value 0 = until data is actually written into the gap. > > so except for reading from /dev/zero freebsd also isn't posix compliant, = right? Huh...? Please better explain what you mean here. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 24 00:16:36 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8628D1065674; Thu, 24 Feb 2011 00:16:36 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id BE8718FC12; Thu, 24 Feb 2011 00:16:35 +0000 (UTC) Received: by wwb31 with SMTP id 31so20988wwb.31 for ; Wed, 23 Feb 2011 16:16:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YhoVMDsMIWvpNjIg4wiml5vuoYdskUDPOt+gUve9I3U=; b=Ou8KPz1bOUgkCGk5jLn9PdTmbVbCtSK7V2L6WpA6PgjdcCX3IT28qnNKCBqEfnWgKi fuMegLsNrquLXgK1U8YaX29+e7QuAou7gZfk3LI0yykOU0zX7fDGZSkxp+l33d6uWrq9 9s+AMmlpTIOP3JYe8IMY4hNC5s+b7ar9/CcZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bq5lIEeG90fKpERuaWFpjqCr3Z3x8BH67t86Z09B8de04AdLHElmI5wvnb/XvMi99i oNIi5BsSD3uXjg6IWaWegM1iIoSld0VSDpvjQYy8EWwmW263+LRliXFFG48CfOlx8jbM MVxRuKve6HxhnYMK/VzXEKcisqh1sXuyyTSCQ= MIME-Version: 1.0 Received: by 10.216.1.145 with SMTP id 17mr117010wed.50.1298506442371; Wed, 23 Feb 2011 16:14:02 -0800 (PST) Received: by 10.216.15.74 with HTTP; Wed, 23 Feb 2011 16:14:02 -0800 (PST) In-Reply-To: <20110223235355.GA48790@freebsd.org> References: <20110222141112.GA98964@freebsd.org> <201102221251.33717.jhb@freebsd.org> <3A287E45-A369-4C7A-BA8E-A205679AC0BC@gmail.com> <20110223235355.GA48790@freebsd.org> Date: Wed, 23 Feb 2011 16:14:02 -0800 Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: seeking into /dev/{null,zero} X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 00:16:36 -0000 On Wed, Feb 23, 2011 at 3:53 PM, Alexander Best wrote= : > On Wed Feb 23 11, Garrett Cooper wrote: >> On Feb 22, 2011, at 9:51 AM, John Baldwin wrote: >> >> > On Tuesday, February 22, 2011 11:46:05 am Garrett Cooper wrote: >> >> (Please bottom post) >> >> >> >> On Tue, Feb 22, 2011 at 8:31 AM, Andrew Duane wr= ote: >> >>> I thought seeking past EOF was valid; writing something creates a fi= le >> > with a hole in it. I always assumed that was standard semantics. >> >> >> >> =A0 =A0That's with SET_HOLE/SET_DATA though, correct? If so, outside = of >> >> that functionality I would assume relatively standard POSIX semantics= . >> > >> > Err, no, you can always seek past EOF and then call write(2) to extend= a file >> > (it does an implicit ftruncate(2)). =A0SEEK_HOLE and SEEK_DATA are dif= ferent, >> > they are just used to discover sparse regions within a file. > > on the other hand POSIX says: > > "The behavior of lseek() on devices which are incapable of seeking is imp= lementation-defined. > The value of the file offset associated with such a device is undefined." > > ...if we define /dev/{zero,null} as incapable of seeking the current > implementation should be ok. > >> > >> > From the manpage: >> > >> > =A0 =A0 The lseek() system call allows the file offset to be set beyon= d the end >> > =A0 =A0 of the existing end-of-file of the file. =A0If data is later w= ritten at >> > =A0 =A0 this point, subsequent reads of the data in the gap return byt= es of zeros >> > =A0 =A0 (until data is actually written into the gap). >> >> =A0 =A0 =A0 You're correct. Linux (Fedora 13) isn't POSIX compliant (thi= s is from the official POSIX text): >> >> The lseek ( ) function shall allow the file offset to be set beyond the = end of the existing data in the file. If data is later written at this poin= t, subsequent reads of data in the gap shall return bytes with the value 0 = until data is actually written into the gap. Yes, but look at how it's defined by POSIX before you do that (yes, there's a section for null/zero IIRC). Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 24 00:27:21 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id E741F106566C; Thu, 24 Feb 2011 00:27:21 +0000 (UTC) Date: Thu, 24 Feb 2011 00:27:21 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20110224002721.GA53978@freebsd.org> References: <20110222141112.GA98964@freebsd.org> <201102221251.33717.jhb@freebsd.org> <3A287E45-A369-4C7A-BA8E-A205679AC0BC@gmail.com> <20110223233612.GA46124@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: seeking into /dev/{null,zero} X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 00:27:22 -0000 On Wed Feb 23 11, Garrett Cooper wrote: > On Wed, Feb 23, 2011 at 3:36 PM, Alexander Best wrote: > > On Wed Feb 23 11, Garrett Cooper wrote: > >> On Feb 22, 2011, at 9:51 AM, John Baldwin wrote: > >> > >> > On Tuesday, February 22, 2011 11:46:05 am Garrett Cooper wrote: > >> >> (Please bottom post) > >> >> > >> >> On Tue, Feb 22, 2011 at 8:31 AM, Andrew Duane wrote: > >> >>> I thought seeking past EOF was valid; writing something creates a file > >> > with a hole in it. I always assumed that was standard semantics. > >> >> > >> >>    That's with SET_HOLE/SET_DATA though, correct? If so, outside of > >> >> that functionality I would assume relatively standard POSIX semantics. > >> > > >> > Err, no, you can always seek past EOF and then call write(2) to extend a file > >> > (it does an implicit ftruncate(2)).  SEEK_HOLE and SEEK_DATA are different, > >> > they are just used to discover sparse regions within a file. > >> > > >> > From the manpage: > >> > > >> >     The lseek() system call allows the file offset to be set beyond the end > >> >     of the existing end-of-file of the file.  If data is later written at > >> >     this point, subsequent reads of the data in the gap return bytes of zeros > >> >     (until data is actually written into the gap). > >> > >>       You're correct. Linux (Fedora 13) isn't POSIX compliant (this is from the official POSIX text): > >> > >> The lseek ( ) function shall allow the file offset to be set beyond the end of the existing data in the file. If data is later written at this point, subsequent reads of data in the gap shall return bytes with the value 0 until data is actually written into the gap. > > > > so except for reading from /dev/zero freebsd also isn't posix compliant, right? > > Huh...? Please better explain what you mean here. if i got this right when reading from /dev/{zero,null} and writing to /dev/{zero,null} seeking past EOF should take place. right now only reading from /dev/zero seeks correctly. writing to /dev/zero and reading/writing to/from /dev/null will not seek, but remain at offset 0. cheers. alex > Thanks, > -Garrett -- a13x From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 24 00:36:08 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 3F6F31065670; Thu, 24 Feb 2011 00:36:08 +0000 (UTC) Date: Thu, 24 Feb 2011 00:36:08 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20110224003608.GA55221@freebsd.org> References: <20110222141112.GA98964@freebsd.org> <201102221251.33717.jhb@freebsd.org> <3A287E45-A369-4C7A-BA8E-A205679AC0BC@gmail.com> <20110223233612.GA46124@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="wac7ysb48OaltWcw" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: seeking into /dev/{null,zero} X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 00:36:08 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Wed Feb 23 11, Garrett Cooper wrote: > On Wed, Feb 23, 2011 at 3:36 PM, Alexander Best wrote: > > On Wed Feb 23 11, Garrett Cooper wrote: > >> On Feb 22, 2011, at 9:51 AM, John Baldwin wrote: > >> > >> > On Tuesday, February 22, 2011 11:46:05 am Garrett Cooper wrote: > >> >> (Please bottom post) > >> >> > >> >> On Tue, Feb 22, 2011 at 8:31 AM, Andrew Duane wrote: > >> >>> I thought seeking past EOF was valid; writing something creates a file > >> > with a hole in it. I always assumed that was standard semantics. > >> >> > >> >>    That's with SET_HOLE/SET_DATA though, correct? If so, outside of > >> >> that functionality I would assume relatively standard POSIX semantics. > >> > > >> > Err, no, you can always seek past EOF and then call write(2) to extend a file > >> > (it does an implicit ftruncate(2)).  SEEK_HOLE and SEEK_DATA are different, > >> > they are just used to discover sparse regions within a file. > >> > > >> > From the manpage: > >> > > >> >     The lseek() system call allows the file offset to be set beyond the end > >> >     of the existing end-of-file of the file.  If data is later written at > >> >     this point, subsequent reads of the data in the gap return bytes of zeros > >> >     (until data is actually written into the gap). > >> > >>       You're correct. Linux (Fedora 13) isn't POSIX compliant (this is from the official POSIX text): > >> > >> The lseek ( ) function shall allow the file offset to be set beyond the end of the existing data in the file. If data is later written at this point, subsequent reads of data in the gap shall return bytes with the value 0 until data is actually written into the gap. > > > > so except for reading from /dev/zero freebsd also isn't posix compliant, right? > > Huh...? Please better explain what you mean here. this patch should make things a bit clearer. cheers. alex > Thanks, > -Garrett -- a13x --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="null.c.diff" diff --git a/sys/dev/null/null.c b/sys/dev/null/null.c index 3005c19..a83be6f 100644 --- a/sys/dev/null/null.c +++ b/sys/dev/null/null.c @@ -47,11 +47,12 @@ static struct cdev *zero_dev; static d_write_t null_write; static d_ioctl_t null_ioctl; +static d_read_t null_read; static d_read_t zero_read; static struct cdevsw null_cdevsw = { .d_version = D_VERSION, - .d_read = (d_read_t *)nullop, + .d_read = null_read, .d_write = null_write, .d_ioctl = null_ioctl, .d_name = "null", @@ -71,6 +72,19 @@ static void *zbuf; static int null_write(struct cdev *dev __unused, struct uio *uio, int flags __unused) { + + uio->uio_offset += uio->uio_resid; + uio->uio_resid = 0; + + return (0); +} + +/* ARGSUSED */ +static int +null_read(struct cdev *dev __unused, struct uio *uio, int flags __unused) +{ + + uio->uio_offset += uio->uio_resid; uio->uio_resid = 0; return (0); --wac7ysb48OaltWcw-- From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 24 01:33:59 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E0A21065672; Thu, 24 Feb 2011 01:33:59 +0000 (UTC) (envelope-from gnehzuil@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 27F818FC0A; Thu, 24 Feb 2011 01:33:58 +0000 (UTC) Received: by pwj8 with SMTP id 8so119552pwj.13 for ; Wed, 23 Feb 2011 17:33:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6nguFm1s2OZ+ZWMwt19Fbb4jjNEj68ZTBvQl96EQ4mo=; b=UQDukYe+SUCZhIy72/mf3aMZA/9ANbQICXMqrW+XuaOFkJM9O2XgJKXdzGlIBT+hjl aLDErV0xPoTGUJUIBtkxL2XF3ucPS0VU3sB8rHZ8hrEZTAhUf9nmEBPsEydnKVt3m8ew J3ANE7nqMd2Ik8RJDCjSSw/li3VGXlPsNjIFQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=kRu4Dmmvun28Fj1EWpFPgWwoxYSmnV293KRLyQaKv6c5pZnapMe42FPMNrLGJGfmVV jLyDr8S68EkVim1419LBAMF5QJN8nGHIbT33rDemE3HTW3pvDOTbvwnz1yV89GCxVsf6 Gdm/b6FF6y4ZgfDONoTqSZ2RhwvjYRGIkBXnc= Received: by 10.142.240.4 with SMTP id n4mr175858wfh.211.1298511238415; Wed, 23 Feb 2011 17:33:58 -0800 (PST) Received: from [192.168.1.157] ([166.111.68.197]) by mx.google.com with ESMTPS id p40sm11557169wfc.5.2011.02.23.17.33.54 (version=SSLv3 cipher=OTHER); Wed, 23 Feb 2011 17:33:56 -0800 (PST) Message-ID: <4D65B57D.4070306@gmail.com> Date: Thu, 24 Feb 2011 09:33:49 +0800 From: gnehzuil User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dimitry Andric References: <4D63661D.2090205@gmail.com> <4D63AE83.5040007@FreeBSD.org> In-Reply-To: <4D63AE83.5040007@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: buildkernel error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 01:33:59 -0000 Hi all, I have rebuilt my world and it works well. Thanks Best regards, lz On 02/22/2011 08:39 PM, Dimitry Andric wrote: > On 2011-02-22 08:30, gnehzuil wrote: >> I updated my kernel source code and try to make a new kernel using make >> buildkernel command. But I got an error as follow: > ... >> ld:/usr/src/sys/conf/ldscript.i386:66: syntax error > > Your /usr/bin/ld is still at version 2.15, which is too old to parse the > kernel linker script. In this case, first run "make buildworld", or at > least "make kernel-toolchain" before you attempt to build any kernels. From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 24 02:22:28 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6F1C1065679 for ; Thu, 24 Feb 2011 02:22:28 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id CE1FE8FC15 for ; Thu, 24 Feb 2011 02:22:27 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p1O2MNmX005275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Feb 2011 12:52:24 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <53A394ED-7C2E-4E4B-A9A7-CB5F1B27DBE3@gsoft.com.au> Date: Thu, 24 Feb 2011 12:52:23 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <49CFB6EF-404A-44C3-A061-F9A7AE604B56@gsoft.com.au> References: <53A394ED-7C2E-4E4B-A9A7-CB5F1B27DBE3@gsoft.com.au> To: "Daniel O'Connor" X-Mailer: Apple Mail (2.1082) X-Spam-Score: -2.51 () ALL_TRUSTED,BAYES_00,T_RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-hackers Hackers Subject: Re: Scheduler question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 02:22:28 -0000 On 04/02/2011, at 13:26, Daniel O'Connor wrote: > I am writing a program which reads from a data acquisition chassis = connected to a radar via USB. The interface is a Cypress FX2 and I am = communicating via libusb. I ended up writing a kernel driver (thank you hps for usb_fifo_*!) and = it has greatly improved things which is good news for me :) I will some of the tests suggested by various people soon, I have to = wait for a new PC to do them though. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 24 11:17:58 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1683106566B for ; Thu, 24 Feb 2011 11:17:58 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 61B908FC1B for ; Thu, 24 Feb 2011 11:17:57 +0000 (UTC) Received: by wwb31 with SMTP id 31so525279wwb.31 for ; Thu, 24 Feb 2011 03:17:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:date:from:to:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type :content-transfer-encoding; bh=ZX1Zt7CeTVVOIaaWvE2uI+aNTVWPc4M1vRUE5KJfUqM=; b=uAM42bRA6lQPu1M2r/aYXKFF0nQNrHqbflwZGjxloFhh5u99lqBLy3NpsDiT9SIGwd TPQ5sETe+NERrWfHPzbmskZ/hGtWHAPNnO9oBCr3cydHeaCha2N+LA0rpr7UxIFhNGQ2 9HJXU6BsxYcOQxS6pxCF2FYSjvba2He4GN6ig= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=DflNDjJQUcf/Bq0SuVmKJ8e7mVJPqPcYVe/EESfcpbzKbJr3jrgh2jcmMQAqqWE6cY PmEscSPbv9WIc/RhZyQYqA7JTk3zoq0rs10cCsajJlgTfaifG0q5+uP4T1bQvSMJaPx7 OVWK42GUlkzOdr9LdD0TF4llGTwqfl3suMojw= Received: by 10.227.153.202 with SMTP id l10mr575936wbw.173.1298544696317; Thu, 24 Feb 2011 02:51:36 -0800 (PST) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk [87.194.105.247]) by mx.google.com with ESMTPS id i80sm3675609wej.4.2011.02.24.02.51.34 (version=SSLv3 cipher=OTHER); Thu, 24 Feb 2011 02:51:35 -0800 (PST) Date: Thu, 24 Feb 2011 10:51:32 +0000 From: RW To: freebsd-hackers@freebsd.org Message-ID: <20110224105132.69d074f7@gumby.homeunix.com> In-Reply-To: References: X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Why FreeBSD fetch does not download a file via a proxy for HTTPS URLS (the same works fine for HTTP urls) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 11:17:58 -0000 On Thu, 24 Feb 2011 12:49:06 +0530 chandra reddy wrote: > Hi All, > > I am working on a project where i need to download a file via a proxy > server using HTTPS protocol. I found that fetch does not work/support > HTTPS requests over a proxy. I just checked and neither do wget nor curl. > I could overcome the above problem if I do the following change. > > 1375: > 1.58 > > des 1376: if (purl) { 1.51 > > des 1377: URL = purl; > I don't think that would work, presumably it would just cause an attempt at an ssl connection to the proxy, followed by a GET request for an https URL. https through a proxy is supposed to use a CONNECT to tunnel through to the actual server. From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 24 07:46:29 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 641C71065673; Thu, 24 Feb 2011 07:46:29 +0000 (UTC) (envelope-from creddym@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 972738FC14; Thu, 24 Feb 2011 07:46:28 +0000 (UTC) Received: by wyb32 with SMTP id 32so297498wyb.13 for ; Wed, 23 Feb 2011 23:46:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=A7RHomDfeEen2UrxdzERCGyKKfgOXuT7iy+bvpdEBa8=; b=lMWKij+Py4aU8bWPGkDkrpmyJ3OvdhHm7XszCUEjpt7zpXQveDvmyeX8YAfSo8/J0S C7WVO14g2ZCo6L3E/jcNtr+HiGYJzGC+AhEpUQvTD8bDSMNzRLv8dlaeM/FYU1LRsreD c5ys4/o1fpjYsc+/NT5yJwPsrZQQt++wujrT8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=xifYm+hEUEgRMbZcf5Xjgkm/gXEnOdORULkMf6IUpD/C55DgTf7UmrYB2Wd9AX9MG4 agjxouFhj9VI5Emr87yPE1qZgHRe1BfGziGyYs71TwRU7fHurbu6RbQCyUnURKuCtDH8 /svMs9IF+sNh0A0bNsa6Q2/C7G4iOXeJXBGVE= MIME-Version: 1.0 Received: by 10.216.142.224 with SMTP id i74mr343926wej.83.1298531946834; Wed, 23 Feb 2011 23:19:06 -0800 (PST) Received: by 10.216.78.147 with HTTP; Wed, 23 Feb 2011 23:19:06 -0800 (PST) Date: Thu, 24 Feb 2011 12:49:06 +0530 Message-ID: From: chandra reddy To: freebsd-questions@freebsd.org X-Mailman-Approved-At: Thu, 24 Feb 2011 12:06:54 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, freebsd-i386@freebsd.org Subject: Why FreeBSD fetch does not download a file via a proxy for HTTPS URLS (the same works fine for HTTP urls) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 07:46:29 -0000 Hi All, I am working on a project where i need to download a file via a proxy server using HTTPS protocol. I found that fetch does not work/support HTTPS requests over a proxy. My setup would be like this: Intranet Internet ----------------------------------------------------------------------- | https or http | https | Client m/cs -----------------------------> Porxy Server -------------------------------> Destination Server (or Download server) | | ----------------------------------------------------------------------- I can use https or http protocol between Client and Proxy but only HTTPS is used between proxy and Destination server(or Download server) . I tried to use "squid" proxy as my proxy server and tried to download a file from my download server to Client m/c using FreeBSD "fetch" command. It fails to download a file via proxy for HTTPS requests Please note that Proxy setup is 100% correct and a web server (Apache) running fine. [I have tested it using my Mozilla browser on my PC]. I have done the following: 1. *Download a file using HTTPS over a proxy server* #env HTTP_PROXY=http://:3128/ /usr/sbin/fetch -v -o /tmp/download.out 'https:///index.htm' looking up connecting to:443 connection established fetch: https:///index.htm Authentication error Even I have tried this also and found the same error. #env HTTP_PROXY=https://:3128/ /usr/sbin/fetch -v -o /tmp/download.out 'https:///index.htm' My question is why it is not connected via "Proxy sever". It tries to connect directly. I could see that if I use HTTP protocol then it connects via proxy. Please see the logs here. 2. *Download a file using HTTP over a proxy server* #env HTTP_PROXY=http://:3128/ /usr/sbin/fetch -v -o /tmp/download.out 'http:///index.htm' looking up connecting to :3128 connection established requesting http://destination-server-ip/index.htm Even I have tried this also and found that works fine. #env HTTP_PROXY=https://:3128/ /usr/sbin/fetch -v -o /tmp/download.out 'http:///index.htm' I have debugged "fetch" and found that the following check is stopping HTTPS requests over a proxy. *http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libfetch/http.c .OR. http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libfetch/http.c?annotate=1.78.2.5.4.1 * 1375: 1.58 des 1376: if (purl && strcasecmp(URL->scheme, SCHEME_HTTPS) != 0) { 1.51 des 1377: URL = purl; I could overcome the above problem if I do the following change. 1375: 1.58 des 1376: if (purl) { 1.51 des 1377: URL = purl; I want to know why HTTPS over proxy is not working with "libfetch". I want to make it work how can do it? Thanks -Chandra From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 24 16:10:48 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C50F106566B for ; Thu, 24 Feb 2011 16:10:48 +0000 (UTC) (envelope-from krivenok.dmitry@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 46E8F8FC16 for ; Thu, 24 Feb 2011 16:10:48 +0000 (UTC) Received: by mail-iy0-f182.google.com with SMTP id 12so405638iyj.13 for ; Thu, 24 Feb 2011 08:10:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=mITIevIDF35GEt5qvEkWScrValjT73eaiL7IIQhInIY=; b=RIkvdhKfwxGZbtPhYL46Qg5GL9V8bqnscn8Vh1nNRhi/FXfwE8vWfHqcKNfTSGrmLD r6wxepTBQDuSvxtaoxF2Xx98P99sKyeGSN8FtEsamJrufvjqRmMNGnE3JK83IzMaY+5V vzb7sTnEuGdfW7eGknIpZj+UC2m4hwiaVjoJs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=Dl+CKqht2pSZ0LG4SBKU72pzV19ANcKwFPRDOMTTuAwExpukOct7usK5Bd44jtbWlL MIxeZtdyse9M7mgISr+Scg17rAAJqJsJGRDY6MXT9/3X9VX12rO6TPV0oLMREouktvU3 n2XAEjRFDwBBBit0xK8DvI991tCLRGxWEI4MQ= MIME-Version: 1.0 Received: by 10.231.182.13 with SMTP id ca13mr1665660ibb.57.1298562447160; Thu, 24 Feb 2011 07:47:27 -0800 (PST) Received: by 10.231.144.140 with HTTP; Thu, 24 Feb 2011 07:47:27 -0800 (PST) Date: Thu, 24 Feb 2011 18:47:27 +0300 Message-ID: From: Dmitry Krivenok To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: mtx_init/lock_init and uninitialized struct mtx X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 16:10:48 -0000 Hello Hackers, Is it allowed to call mtx_init on a mutex defined as an auto variable and not initialized explicitly, i.e.: static int foo() { struct mtx m; // Uninitialized auto variable, so it's value is undefine= d. mtx_init(&m, "my_mutex", NULL, MTX_DEF); =85 // Do something ... mtx_destroy(&m); return 0; } I encountered a problem with such code on a kernel compiled with INVARIANTS option. The problem is that mtx_init calls lock_init(&m->lock_object) and lock_init, in turn, calls: 79 /* Check for double-init and zero object. */ 80 KASSERT(!lock_initalized(lock), ("lock \"%s\" %p already initialized", 81 name, lock)); lock_initialized() just checks that a bit is set in lo_flags field of struct lock_object: 178 #define lock_initalized(lo) ((lo)->lo_flags & LO_INITIALIZED) However, the structure containing this field is never initialized (neither in mtx_init nor in lock_init). So, assuming that the mutex was defined as auto variable, the content of lock_object field of struct mtx is also undefined: 37 struct mtx { 38 struct lock_object lock_object; /* Common lock properties. */ 39 volatile uintptr_t mtx_lock; /* Owner and flags. */ 40 }; In some cases, the initial value of lo_flags _may_ have the "initialized" bit set and KASSERT will call panic. Is it user's responsibility to properly (how exactly?) initialize struct mtx, e.g. memset(&m, '\0', sizeof(struct mtx)); Or should mtx_init() explicitly initialize all fields of struct mtx? Thanks in advance! --=20 Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmitry@gmail.com skype: krivenok_dmitry jabber: krivenok_dmitry@jabber.ru icq: 242-526-443 From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 24 16:56:50 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E900F1065694 for ; Thu, 24 Feb 2011 16:56:49 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7E69B8FC08 for ; Thu, 24 Feb 2011 16:56:49 +0000 (UTC) Received: by wwb31 with SMTP id 31so957552wwb.31 for ; Thu, 24 Feb 2011 08:56:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AnYH++niiRg8DqugJgRx59weS7JIt0mgeThUvOLeyjU=; b=MRozaCr16BZ8AMMZZYhmIg3cwtzWfnj++X3z52xn964E5vBrDNsnqISa7N4nQqGArm CRUzU1Fi+LfvRLkoOgngyXHt8gtHdhPuB9AHUxkjzVumybx9OYuGFdL7X8x6OrVcr/+g GgtGjYCeOc37I7fZpsMnu9FTyZnusN3KGOivI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kvO0GOUj4kG1hRVF/3V61SlGH/Yx4HKtREAq2YgUPaW2WbSxbNUr8b6hh5LmjEzblU KTSiYQZwKcj8GumUZzbDj2jbvcLClQ+LOqR5V8Sqvj5OHBFoW19ou4IaX8SIOabkqa3s HynUmWP5pREMV9+iL2xITKF7zFVJFFlYToMz0= MIME-Version: 1.0 Received: by 10.216.145.135 with SMTP id p7mr6044269wej.38.1298566607576; Thu, 24 Feb 2011 08:56:47 -0800 (PST) Received: by 10.216.86.200 with HTTP; Thu, 24 Feb 2011 08:56:47 -0800 (PST) In-Reply-To: References: Date: Thu, 24 Feb 2011 08:56:47 -0800 Message-ID: From: Matthew Fleming To: Dmitry Krivenok Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: mtx_init/lock_init and uninitialized struct mtx X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 16:56:50 -0000 On Thu, Feb 24, 2011 at 7:47 AM, Dmitry Krivenok wrote: > Hello Hackers, > > Is it allowed to call mtx_init on a mutex defined as an auto variable > and not initialized explicitly, i.e.: We recently ran into this problem at $WORK because we turned on the deadc0de checking in uma zones for any zone without an explicit init/fini function, in order to detect more use-after-free scenarios. It happens that one of the bits in 0xDEADC0DE is the LO_INITIALIZED bit. It's a bit of a tough call, since one would like mtx_init(9) and family to just work on any blob of memory, but one would also like to catch a programmer error where a lock is re-initialized. I suppose that for INVARIANTS the kernel can remember the address of all initialized locks and forget it on lock destroy, and in this way have a useful assert and also allow lock_init on random storage. This would also allow for detecting if the memory for a lock was released but the lock wasn't destroyed. Sadly, I have just enough time to propose this and not enough to write a patch at the moment. Thanks, matthew > > static int foo() > { > =A0 struct mtx m; =A0// Uninitialized auto variable, so it's value is und= efined. > =A0 mtx_init(&m, "my_mutex", NULL, MTX_DEF); > =A0 =85 > =A0 // Do something > =A0 ... > =A0 mtx_destroy(&m); > =A0 return 0; > } > > I encountered a problem with such code on a kernel compiled with > INVARIANTS option. > The problem is that mtx_init calls lock_init(&m->lock_object) and > lock_init, in turn, calls: > > =A079 =A0 =A0 =A0 =A0 /* Check for double-init and zero object. */ > =A080 =A0 =A0 =A0 =A0 KASSERT(!lock_initalized(lock), ("lock \"%s\" %p al= ready > initialized", > =A081 =A0 =A0 =A0 =A0 =A0 =A0 name, lock)); > > lock_initialized() just checks that a bit is set in lo_flags field of > struct lock_object: > > 178 #define lock_initalized(lo) =A0 =A0 ((lo)->lo_flags & LO_INITIALIZED) > > However, the structure containing this field is never initialized > (neither in mtx_init nor in lock_init). > So, assuming that the mutex was defined as auto variable, the content > of lock_object field of struct mtx > is also undefined: > > =A037 struct mtx { > =A038 =A0 =A0 =A0 =A0 struct lock_object =A0 =A0 =A0lock_object; =A0 =A0/= * Common lock > properties. */ > =A039 =A0 =A0 =A0 =A0 volatile uintptr_t =A0 =A0 =A0mtx_lock; =A0 =A0 =A0= /* Owner and flags. */ > =A040 }; > > In some cases, the initial value of lo_flags _may_ have the > "initialized" bit set and KASSERT will call panic. > > Is it user's responsibility to properly (how exactly?) initialize > struct mtx, e.g. > memset(&m, '\0', sizeof(struct mtx)); > > Or should mtx_init() explicitly initialize all fields of struct mtx? > > Thanks in advance! > > -- > Sincerely yours, Dmitry V. Krivenok > e-mail: krivenok.dmitry@gmail.com > skype: krivenok_dmitry > jabber: krivenok_dmitry@jabber.ru > icq: 242-526-443 From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 24 17:51:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A38CD1065672 for ; Thu, 24 Feb 2011 17:51:47 +0000 (UTC) (envelope-from PMahan@adaranet.com) Received: from barracuda.adaranet.com (smtp.adaranet.com [72.5.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7BD7D8FC08 for ; Thu, 24 Feb 2011 17:51:47 +0000 (UTC) X-ASG-Debug-ID: 1298567532-554971ca0001-P5m3U7 Received: from SJ-EXCH-1.adaranet.com ([10.10.1.29]) by barracuda.adaranet.com with ESMTP id EnDoOgblN6SnjMA8; Thu, 24 Feb 2011 09:12:12 -0800 (PST) X-Barracuda-Envelope-From: PMahan@adaranet.com Received: from SJ-EXCH-1.adaranet.com ([fe80::7042:d8c2:5973:c523]) by SJ-EXCH-1.adaranet.com ([fe80::7042:d8c2:5973:c523%14]) with mapi; Thu, 24 Feb 2011 09:12:12 -0800 From: Patrick Mahan X-Barracuda-BBL-IP: fe80::7042:d8c2:5973:c523 X-Barracuda-RBL-IP: fe80::7042:d8c2:5973:c523 To: Dmitry Krivenok , "freebsd-hackers@freebsd.org" Date: Thu, 24 Feb 2011 09:12:00 -0800 X-ASG-Orig-Subj: RE: mtx_init/lock_init and uninitialized struct mtx Thread-Topic: mtx_init/lock_init and uninitialized struct mtx Thread-Index: AcvUPXQVDy7BwaqZQm+rpoeC1wOgRQAB+pcw Message-ID: <32AB5C9615CC494997D9ABB1DB12783C024CD0266E@SJ-EXCH-1.adaranet.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: hXI= CxA3 C5xt EC+O FdjR GA+g G2Hb Iy5O LCTO LMMx L/A2 NZRP OvRV PNxK P2pC TGN1; 2; ZgByAGUAZQBiAHMAZAAtAGgAYQBjAGsAZQByAHMAQABmAHIAZQBlAGIAcwBkAC4AbwByAGcAOwBrAHIAaQB2AGUAbgBvAGsALgBkAG0AaQB0AHIAeQBAAGcAbQBhAGkAbAAuAGMAbwBtAA==; Sosha1_v1; 7; {B412F822-DEF6-4767-A32E-DBC3ABCAA9D3}; cABtAGEAaABhAG4AQABhAGQAYQByAGEAbgBlAHQALgBjAG8AbQA=; Thu, 24 Feb 2011 17:12:01 GMT; UgBFADoAIABtAHQAeABfAGkAbgBpAHQALwBsAG8AYwBrAF8AaQBuAGkAdAAgAGEAbgBkACAAdQBuAGkAbgBpAHQAaQBhAGwAaQB6AGUAZAAgAHMAdAByAHUAYwB0ACAAbQB0AHgA x-cr-puzzleid: {B412F822-DEF6-4767-A32E-DBC3ABCAA9D3} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[10.10.1.29] X-Barracuda-Start-Time: 1298567532 X-Barracuda-URL: http://172.16.10.203:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at adaranet.com Cc: Subject: RE: mtx_init/lock_init and uninitialized struct mtx X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 17:51:47 -0000 > -----Original Message----- > From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd- > hackers@freebsd.org] On Behalf Of Dmitry Krivenok > Sent: Thursday, February 24, 2011 7:47 AM > To: freebsd-hackers@freebsd.org > Subject: mtx_init/lock_init and uninitialized struct mtx > > Hello Hackers, > > Is it allowed to call mtx_init on a mutex defined as an auto variable > and not initialized explicitly, i.e.: > > static int foo() > { > struct mtx m; // Uninitialized auto variable, so it's value is > undefined. > mtx_init(&m, "my_mutex", NULL, MTX_DEF); > ... > // Do something > ... > mtx_destroy(&m); > return 0; > } > > I encountered a problem with such code on a kernel compiled with > INVARIANTS option. > The problem is that mtx_init calls lock_init(&m->lock_object) and > lock_init, in turn, calls: > > 79 /* Check for double-init and zero object. */ > 80 KASSERT(!lock_initalized(lock), ("lock \"%s\" %p already > initialized", > 81 name, lock)); > > lock_initialized() just checks that a bit is set in lo_flags field of > struct lock_object: > > 178 #define lock_initalized(lo) ((lo)->lo_flags & LO_INITIALIZED) > > However, the structure containing this field is never initialized > (neither in mtx_init nor in lock_init). > So, assuming that the mutex was defined as auto variable, the content > of lock_object field of struct mtx > is also undefined: > > 37 struct mtx { > 38 struct lock_object lock_object; /* Common lock > properties. */ > 39 volatile uintptr_t mtx_lock; /* Owner and flags. *= / > 40 }; > > In some cases, the initial value of lo_flags _may_ have the > "initialized" bit set and KASSERT will call panic. > > Is it user's responsibility to properly (how exactly?) initialize > struct mtx, e.g. > memset(&m, '\0', sizeof(struct mtx)); > > Or should mtx_init() explicitly initialize all fields of struct mtx? > > Thanks in advance! > When dealing with stack variables, I always initialize them to a known stat= e, (mostly doing as you do above, with memset() though in the kernel I then to use bzero()) Given that if it is global then it is either in .bss or in .data if it has been initialized. If it is part of a structure then most often you zero ou= t the structure right after allocation. So there is an implicit assumption that the structure will be zero'd before calling mtx_init(). Patrick ---------------------------------------------------- Patrick Mahan Lead Technical Kernel Engineer Adara Networks Disclaimer: The opinions expressed here are solely the responsibility of th= e author and are not to be construed as an official opinion of Adara Networks. > -- > Sincerely yours, Dmitry V. Krivenok > e-mail: krivenok.dmitry@gmail.com > skype: krivenok_dmitry > jabber: krivenok_dmitry@jabber.ru > icq: 242-526-443 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 24 19:02:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B29D106566C for ; Thu, 24 Feb 2011 19:02:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id EF6438FC18 for ; Thu, 24 Feb 2011 19:02:46 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 9F24246B03; Thu, 24 Feb 2011 14:02:46 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3F8EA8A009; Thu, 24 Feb 2011 14:02:45 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 24 Feb 2011 14:02:21 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Message-Id: <201102241402.21556.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 24 Feb 2011 14:02:45 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Dmitry Krivenok Subject: Re: mtx_init/lock_init and uninitialized struct mtx X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 19:02:47 -0000 On Thursday, February 24, 2011 10:47:27 am Dmitry Krivenok wrote: > Hello Hackers, >=20 > Is it allowed to call mtx_init on a mutex defined as an auto variable > and not initialized explicitly, i.e.: It does expect you to zero it first. I've considered adding a MTX_NEW flag= to=20 disable this check for places where the developer knows it is safe. Most=20 mutexes are allocated in an already-zero'd structure or BSS as Patrick note= d, so they are already correct. It is a trade off between catching double=20 initializations and requiring extra M_ZERO flags or bzero() calls in variou= s=20 places. > static int foo() > { > struct mtx m; // Uninitialized auto variable, so it's value is=20 undefined. > mtx_init(&m, "my_mutex", NULL, MTX_DEF); > =85 > // Do something > ... > mtx_destroy(&m); > return 0; > } >=20 > I encountered a problem with such code on a kernel compiled with > INVARIANTS option. > The problem is that mtx_init calls lock_init(&m->lock_object) and > lock_init, in turn, calls: >=20 > 79 /* Check for double-init and zero object. */ > 80 KASSERT(!lock_initalized(lock), ("lock \"%s\" %p already > initialized", > 81 name, lock)); >=20 > lock_initialized() just checks that a bit is set in lo_flags field of > struct lock_object: >=20 > 178 #define lock_initalized(lo) ((lo)->lo_flags & LO_INITIALIZED) >=20 > However, the structure containing this field is never initialized > (neither in mtx_init nor in lock_init). > So, assuming that the mutex was defined as auto variable, the content > of lock_object field of struct mtx > is also undefined: >=20 > 37 struct mtx { > 38 struct lock_object lock_object; /* Common lock > properties. */ > 39 volatile uintptr_t mtx_lock; /* Owner and flags. */ > 40 }; >=20 > In some cases, the initial value of lo_flags _may_ have the > "initialized" bit set and KASSERT will call panic. >=20 > Is it user's responsibility to properly (how exactly?) initialize > struct mtx, e.g. > memset(&m, '\0', sizeof(struct mtx)); >=20 > Or should mtx_init() explicitly initialize all fields of struct mtx? >=20 > Thanks in advance! >=20 > --=20 > Sincerely yours, Dmitry V. Krivenok > e-mail: krivenok.dmitry@gmail.com > skype: krivenok_dmitry > jabber: krivenok_dmitry@jabber.ru > icq: 242-526-443 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >=20 =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 24 20:43:55 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B57851065696 for ; Thu, 24 Feb 2011 20:43:55 +0000 (UTC) (envelope-from krivenok.dmitry@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6E5668FC08 for ; Thu, 24 Feb 2011 20:43:55 +0000 (UTC) Received: by iyj12 with SMTP id 12so575756iyj.13 for ; Thu, 24 Feb 2011 12:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZUkEQVJdk0dfL2X+ehstg4AQcPp5gya7W9NLKFkpqwA=; b=X9vLSzhn5sGYPyDnXiLMK9zyerRzhbRzQircZujONRARaREF1amm11D28Hp7JayyOa HEmn8kdobLoYRy2yVzT65t6D0bF5zwUzB5P8X6lCtShpn3qs0Mo9OqKrZTYwkkjF+RDx QHnBj3OYJqarmCb1M9DHIqez9q8XLL5WJ5Rhs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vhkILSPp+jTBIXsGzyXgWfK3VnOCETgeUItKfxv17Ooy3d09qz/VWojAbPDmhxFZQ2 rMQp0kowShtrYtOA0JaWU763pzfHmNAFPtrk2VszBCnM1DCTcYQIw9ylvak7tlxUQVdH hMIkCrR1W9KWEcEPvJaitZ5YOYQreNgqtOYZw= MIME-Version: 1.0 Received: by 10.231.38.10 with SMTP id z10mr2114866ibd.107.1298580234689; Thu, 24 Feb 2011 12:43:54 -0800 (PST) Received: by 10.231.144.140 with HTTP; Thu, 24 Feb 2011 12:43:54 -0800 (PST) In-Reply-To: <201102241402.21556.jhb@freebsd.org> References: <201102241402.21556.jhb@freebsd.org> Date: Thu, 24 Feb 2011 23:43:54 +0300 Message-ID: From: Dmitry Krivenok To: John Baldwin Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: mtx_init/lock_init and uninitialized struct mtx X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 20:43:55 -0000 Thanks a lot for your answers! I'll always explicitly zero stack variables before calling actual *_init() functions. Also, it would be great to document this "zeroing" requirement in a man page for mtx_init() or simply add a comment in the source. Dmitry On Thu, Feb 24, 2011 at 10:02 PM, John Baldwin wrote: > On Thursday, February 24, 2011 10:47:27 am Dmitry Krivenok wrote: >> Hello Hackers, >> >> Is it allowed to call mtx_init on a mutex defined as an auto variable >> and not initialized explicitly, i.e.: > > It does expect you to zero it first. =A0I've considered adding a MTX_NEW = flag to > disable this check for places where the developer knows it is safe. =A0Mo= st > mutexes are allocated in an already-zero'd structure or BSS as Patrick no= ted, > so they are already correct. =A0It is a trade off between catching double > initializations and requiring extra M_ZERO flags or bzero() calls in vari= ous > places. > >> static int foo() >> { >> =A0 =A0struct mtx m; =A0// Uninitialized auto variable, so it's value is > undefined. >> =A0 =A0mtx_init(&m, "my_mutex", NULL, MTX_DEF); >> =A0 =A0=85 >> =A0 =A0// Do something >> =A0 =A0... >> =A0 =A0mtx_destroy(&m); >> =A0 =A0return 0; >> } >> >> I encountered a problem with such code on a kernel compiled with >> INVARIANTS option. >> The problem is that mtx_init calls lock_init(&m->lock_object) and >> lock_init, in turn, calls: >> >> =A079 =A0 =A0 =A0 =A0 /* Check for double-init and zero object. */ >> =A080 =A0 =A0 =A0 =A0 KASSERT(!lock_initalized(lock), ("lock \"%s\" %p a= lready >> initialized", >> =A081 =A0 =A0 =A0 =A0 =A0 =A0 name, lock)); >> >> lock_initialized() just checks that a bit is set in lo_flags field of >> struct lock_object: >> >> 178 #define lock_initalized(lo) =A0 =A0 ((lo)->lo_flags & LO_INITIALIZED= ) >> >> However, the structure containing this field is never initialized >> (neither in mtx_init nor in lock_init). >> So, assuming that the mutex was defined as auto variable, the content >> of lock_object field of struct mtx >> is also undefined: >> >> =A037 struct mtx { >> =A038 =A0 =A0 =A0 =A0 struct lock_object =A0 =A0 =A0lock_object; =A0 =A0= /* Common lock >> properties. */ >> =A039 =A0 =A0 =A0 =A0 volatile uintptr_t =A0 =A0 =A0mtx_lock; =A0 =A0 = =A0 /* Owner and flags. */ >> =A040 }; >> >> In some cases, the initial value of lo_flags _may_ have the >> "initialized" bit set and KASSERT will call panic. >> >> Is it user's responsibility to properly (how exactly?) initialize >> struct mtx, e.g. >> memset(&m, '\0', sizeof(struct mtx)); >> >> Or should mtx_init() explicitly initialize all fields of struct mtx? >> >> Thanks in advance! >> >> -- >> Sincerely yours, Dmitry V. Krivenok >> e-mail: krivenok.dmitry@gmail.com >> skype: krivenok_dmitry >> jabber: krivenok_dmitry@jabber.ru >> icq: 242-526-443 >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.or= g" >> > > -- > John Baldwin > --=20 Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmitry@gmail.com skype: krivenok_dmitry jabber: krivenok_dmitry@jabber.ru icq: 242-526-443 From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 25 00:40:32 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11A5910656B9 for ; Fri, 25 Feb 2011 00:40:32 +0000 (UTC) (envelope-from lgj@usenix.org) Received: from lonestar.usenix.org (lonestar.usenix.org [131.106.3.102]) by mx1.freebsd.org (Postfix) with ESMTP id 95F6D8FC19 for ; Fri, 25 Feb 2011 00:40:31 +0000 (UTC) Received: from negroni.usenix.org (negroni.usenix.org [131.106.3.145]) (authenticated bits=0) by lonestar.usenix.org (8.14.2/8.14.2) with ESMTP id p1P0e9ZI005561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 24 Feb 2011 16:40:31 -0800 (PST) From: Lionel Garth Jones Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 24 Feb 2011 16:40:31 -0800 Message-Id: To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-DCC-USENIX-Metrics: lonestar; whitelist X-Spam-Status: No, score=0.7 required=6.0 tests=ALL_TRUSTED, FH_DATE_PAST_20XX autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lonestar X-Mailman-Approved-At: Fri, 25 Feb 2011 00:46:57 +0000 Subject: NSDI '11 Early Bird Registration Deadline Approaching X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 00:40:32 -0000 We are writing to remind you that the Early Bird Registration Deadline for the 8th USENIX Symposium on Networked Systems Design and Implementation (NSDI '11) is just over two weeks away. Please register by Monday, March 7, 2011, to save! http://www.usenix.org/nsdi11/progb NSDI '11 focuses on the design principles of large-scale networks and distributed systems. Our goal is to bring together researchers from across the systems and networking communities to foster cross-disciplinary approaches and to address shared research challenges. This year's program includes 27 technical papers carefully selected out of 157 submissions. The high-quality papers represent a diverse range of hot research areas including data-intensive computing, energy and storage, debugging and correctness, and more. In addition, NSDI '11 will feature a poster session where attendees can discuss emerging ideas in networked systems design by talking with leading researchers who are introducing their ongoing work. Submissions are due March 20, 2011. Find out more at: http://www.usenix.org/events/nsdi11/activities.html#poster Please join us in Boston for the latest innovative networked systems research. We look forward to seeing you there. Sincerely, David G. Andersen, Carnegie Mellon University Sylvia Ratnasamy, Intel Labs Berkeley nsdi11chairs@usenix.org P.S. Don't miss these workshops, which will be co-located with NSDI '11 and will take place on Tuesday, March 29, 2011: -- 4th USENIX Workshop on Large-Scale Exploits and Emergent Threats (LEET '11) http://www.usenix.org/events/leet11/ -- Workshop on Hot Topics in Management of Internet, Cloud, and Enterprise Networks and Services (Hot-ICE '11) http://www.usenix.org/events/hotice11/ ------------------------------------------------------------------------ 8th USENIX Symposium on Networked Systems Design and Implementation (NSDI '11) March 30-April 1, 2011 Boston, MA, USA http://www.usenix.org/nsdi11/progb Sponsored by USENIX in cooperation with ACM SIGCOMM and ACM SIGOPS Early Bird Registration Deadline: March 7, 2011 ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 25 08:11:39 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E058106566C for ; Fri, 25 Feb 2011 08:11:39 +0000 (UTC) (envelope-from mahamuni.ashish@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id EBCE98FC15 for ; Fri, 25 Feb 2011 08:11:38 +0000 (UTC) Received: by wyb32 with SMTP id 32so1609028wyb.13 for ; Fri, 25 Feb 2011 00:11:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=IcP5wP3YK3mplz0oK3eyk/ReV7y8GeZRUBf3FThbNtA=; b=Zs0momjj7Ne5TZzMK+nEkN6PLSlWrhT3SBQcVmqNBXo/CSWxKppHAbWG/6qicYX6N4 Znoz11fBRWr2B4JZjQPTvMxhDFK/6vLYYNeSPKrmlCgzWtEqD1ZUMCkDpJ1Z2XlUPbe8 wZ0jfCkejKJNvyixWwrZLXRkakCqTPFzsmogw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=n/btYRTfQcsvu++k1+MpZRSzGtO/qUp1kcKCY0cc5cKZ7ggemrs2vDOzd/OqStVmBr AsLQyJrQmR7kFhVQ054riarhVdXl8593Fb5BGFGjA+uCj0RrxeJ9eghrDplblHVRuz7+ lw4181p8ibGPbMWw6YaYZld2tyGpDfawXtoy8= MIME-Version: 1.0 Received: by 10.216.171.19 with SMTP id q19mr6782976wel.53.1298621497795; Fri, 25 Feb 2011 00:11:37 -0800 (PST) Received: by 10.216.254.82 with HTTP; Fri, 25 Feb 2011 00:11:36 -0800 (PST) Date: Fri, 25 Feb 2011 13:41:36 +0530 Message-ID: From: Ashish Mahamuni To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ssh terminal settings X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 08:11:39 -0000 I am doing some automation stuff with freebsd. on my local machine I am using Net::SSH::Expect (perl library) to run commands on FreeBSD machine. The problem is when I execute commands on FreeBSD, I am not able to get the output of that command on my local machine. All I am getting is remote shell as a output. Same script work perfectly if I run it against linux target. my $ssh = Net::SSH::Expect->new ( host=>"172.18.28.104", user=>"root", password=> "root", timeout=>5, raw_pty=>1 ); $ssh->login(); my $out = $ssh->exec("ps -aux"); print $out; //Here I expect complete ps output, which is not working for FreeBSD. Is there any terminal setting that I have to do to achieve this? How does shell gets allocated when we start ssh session? --Ashish From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 25 10:52:55 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A472D106566C for ; Fri, 25 Feb 2011 10:52:55 +0000 (UTC) (envelope-from putrycydestengier@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5EF9C8FC0A for ; Fri, 25 Feb 2011 10:52:55 +0000 (UTC) Received: by vws16 with SMTP id 16so1453503vws.13 for ; Fri, 25 Feb 2011 02:52:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=6QN2zThjEAunRrFmuamF+lqI5HNdOg/okbu2mMvyeuo=; b=V8NTiKaCtzu54SK72evKL0tD87jaSSlOdbT5R55XVDNDVndFNt6YH3G0ppu2cPn4iW oI2YEiTlwjoueJl+V+GIfDZRsB+F2gxC6fPztyvcuEi/PcQgFQRbpl+3B/+4szvWSqPI j7JkrANtA6USuhuikJJO/Xs5f1p8I3vmFducU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=F2XtI5+JmQ+a8WoP0ggYbi8cyrrAUGOrpncDvPlxJrtNbdaLzyc01fZP65oIgHfI0+ cKORGAYEBVb6WilMuNCbMAoLjH+xPb0BedYybL9L2Wr2n7bh17FDDFo8oQIyvq3keH7s l+y4MXHeM/4JSbJ5WllrKt32LUizcjYrUdF8Q= MIME-Version: 1.0 Received: by 10.220.164.73 with SMTP id d9mr505347vcy.276.1298629725397; Fri, 25 Feb 2011 02:28:45 -0800 (PST) Received: by 10.220.187.9 with HTTP; Fri, 25 Feb 2011 02:28:45 -0800 (PST) In-Reply-To: References: Date: Fri, 25 Feb 2011 11:28:45 +0100 Message-ID: From: Putrycy To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Fwd: linking part of openssl into a kernel ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 10:52:55 -0000 Hi! I am working on a piece of kernel software, that needs to use publc key cryptography, especially RSA. As far as i know, no RSA related in-kernel functionality is currently implemented. Writing a new implementation of key management, and the algorithm itself, and making it stable and efficent is rather long and slippery road, so i started to look shy on openssl. Porting just RSA and key-related stuff is again, a tiresome work. I am rather lazy, and i thought, that maybe I could force linker to to the job for me, i.e. link kernel against openssl library to get just some function that i am interested in. My question is: how to achieve this ? Second: Any better idea ? Is it totally stupid idea ? regards, From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 25 10:59:17 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C184D1065741 for ; Fri, 25 Feb 2011 10:59:17 +0000 (UTC) (envelope-from putrycydestengier@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7B5FF8FC08 for ; Fri, 25 Feb 2011 10:59:17 +0000 (UTC) Received: by vws16 with SMTP id 16so1457118vws.13 for ; Fri, 25 Feb 2011 02:59:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=6QN2zThjEAunRrFmuamF+lqI5HNdOg/okbu2mMvyeuo=; b=vqzHZoYGU9Rc9fGUbO0ibmKjfe2A6hSJzYPd2iTCwy75u0wrWV7erlaP4/9ifbyVTF e5AB2EUdHec7CTmGvTUVQzvXWtm1YUEyEIAgfkh7m077nGhFQ2Ul9hZ6Rijk1gZ/4HXA vbuUf/nSqEBxBRqvW56zNymUulScDTsNQ5QrQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ZACTz6BKIVGvfLZkGAZw7J9vAcefqXt1dqAMEBRNOefH4ZddPbYdHWpAxH1XxOrk/f OznFOO8SRCcFD/gxiejTfy2y6XFJFzvfe6T+nXsDhHCuZbKoarCENVMPzuLUfsmXIKnM 3Js+0MH+PfjByfOAFtDKzEtHNrPUJ/898Yy9g= MIME-Version: 1.0 Received: by 10.52.155.1 with SMTP id vs1mr3344309vdb.44.1298629871550; Fri, 25 Feb 2011 02:31:11 -0800 (PST) Received: by 10.220.187.9 with HTTP; Fri, 25 Feb 2011 02:31:11 -0800 (PST) Date: Fri, 25 Feb 2011 11:31:11 +0100 Message-ID: From: Putrycy To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: linking part of openssl into a kernel ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 10:59:17 -0000 Hi! I am working on a piece of kernel software, that needs to use publc key cryptography, especially RSA. As far as i know, no RSA related in-kernel functionality is currently implemented. Writing a new implementation of key management, and the algorithm itself, and making it stable and efficent is rather long and slippery road, so i started to look shy on openssl. Porting just RSA and key-related stuff is again, a tiresome work. I am rather lazy, and i thought, that maybe I could force linker to to the job for me, i.e. link kernel against openssl library to get just some function that i am interested in. My question is: how to achieve this ? Second: Any better idea ? Is it totally stupid idea ? regards, From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 25 10:17:31 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0405106564A; Fri, 25 Feb 2011 10:17:31 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 9172C8FC16; Fri, 25 Feb 2011 10:17:31 +0000 (UTC) Received: from outgoing.leidinger.net (p5B32EA03.dip.t-dialin.net [91.50.234.3]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 2F2D6844012; Fri, 25 Feb 2011 11:17:25 +0100 (CET) Received: from webmail.leidinger.net (unknown [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id E9DC82D3B; Fri, 25 Feb 2011 11:17:21 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p1PAHLaN099403; Fri, 25 Feb 2011 11:17:21 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 25 Feb 2011 11:17:21 +0100 Message-ID: <20110225111721.36912bbuq9erz740@webmail.leidinger.net> Date: Fri, 25 Feb 2011 11:17:21 +0100 From: Alexander Leidinger To: Robert Watson References: <20110211103028.12684f54yrw8tgqo@webmail.leidinger.net> <20110212151442.000016bb@unknown> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 2F2D6844012.A55A3 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=1.874, required 6, autolearn=disabled, J_CHICKENPOX_73 0.60, RDNS_NONE 1.27) X-EBL-MailScanner-SpamScore: s X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1299233848.5347@1jrgnscEevTRaXOlGc3xiA X-EBL-Spam-Status: No X-Mailman-Approved-At: Fri, 25 Feb 2011 12:23:29 +0000 Cc: hackers@FreeBSD.org, kibab@FreeBSD.org Subject: Re: CFR: FEATURE macros for AUDIT/CAM/IPC/KTR/MAC/NFS/NTP/PMC/SYSV/... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 10:17:32 -0000 Quoting Robert Watson (from Sat, 12 Feb 2011 19:08:59 +0000 (GMT)): > > On Sat, 12 Feb 2011, Alexander Leidinger wrote: > >> On Sat, 12 Feb 2011 00:52:48 +0000 (GMT) Robert Watson >> wrote: >> >>> The one comment I'd make is that the MAC case should indicate that >>> "The MAC Framework" is supported, rather than mandatory access >>> controls being present -- the presence of the framework doesn't >>> imply the presence of mandatory access control policies. >> >> Does >> FEATURE(mac, "Mandatory Access Control Framework support"); >> look better? >> >> Alternatively/additionally we could use mac_framework as the name >> of the feature. > > The above seems fine -- while I've been moving to names like > mac_framework.h, it's still "options MAC" and "security/mac", etc, > and think that "mac" is the most consistent options. Committed. If you want you can modify some userland applications to check for it now with feature_present(3). When every feature macro of the GSoC project is committed, I will commit a change to this function (being able to administratively tell a feature is not there when it is there), and a corresponding userland app to be able to use it in scripts. Bye, Alexander. -- One place where you're sure to find the perfect driver is in the back seat. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 25 14:53:13 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78673106566B; Fri, 25 Feb 2011 14:53:13 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id A92018FC1B; Fri, 25 Feb 2011 14:53:12 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id B8F373593A7; Fri, 25 Feb 2011 15:53:11 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 1677) id AB8DE1737B; Fri, 25 Feb 2011 15:53:11 +0100 (CET) Date: Fri, 25 Feb 2011 15:53:11 +0100 From: Jilles Tjoelker To: freebsd-hackers@freebsd.org, freebsd-i18n@freebsd.org Message-ID: <20110225145311.GA4423@stack.nl> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Basic UTF-8 support for sh(1) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 14:53:13 -0000 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Here is a patch that adds basic UTF-8 support to sh(1). This is enabled if the locale is set appropriately. Features: * ${#var} counts codepoints. (Really, bytes with (b & 0xc0) != 0x80.) * ?, [...] patterns match codepoints instead of bytes. They do not match invalid sequences. This is so that ${var#?} removes the first codepoint, not the first byte. However, * continues to match any string and an invalid sequence matches an identical invalid sequence. (This differs from fnmatch(3).) Internal: * CTL* bytes are moved to bytes that cannot occur in UTF-8 so that mbrtowc(3) can be used directly. The new locations do occur in iso-8859-* encodings. Limitations: * Only UTF-8 support is added, not any other multibyte encodings. I do not want to bloat up sh with mbrtowc(3) and similar everywhere. * Invalid sequences may not be handled as desired. It seems aborting on invalid UTF-8 sequences would break things, so they are let through. This also avoids bloating the code up with checking everywhere. * There is no special treatment for combining characters, accented letters may match ? or ?? or even more depending on normalization form. This matches other code in FreeBSD and is usually good enough because normalization forms that use as few codepoints as possible tend to be used. * IFS remains byte-based as in ksh93 (but unlike bash and zsh). * Our version of libedit does not support UTF-8 so sh will still be rather unpleasant to use interactively with characters not in us-ascii. Is this useful and worth the (small) bloat? A somewhat related feature is support for \uNNNN and \UNNNNNNNN sequences in $'...' (this will be added to POSIX, see http://austingroupbugs.net/view.php?id=249 and I plan to add it to sh). Ideally, these are converted using iconv(3) but as long as it is not unconditionally available in base or if it is not supposed to be used, the codepoints can be encoded in UTF-8 for UTF-8 locales, leaving other locales with question marks. -- Jilles Tjoelker --ikeVEW9yuYc//A+q Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="sh-utf8.patch" Index: parser.h =================================================================== --- parser.h (revision 218371) +++ parser.h (working copy) @@ -34,16 +34,16 @@ */ /* control characters in argument strings */ -#define CTLESC '\201' -#define CTLVAR '\202' -#define CTLENDVAR '\203' -#define CTLBACKQ '\204' +#define CTLESC '\300' +#define CTLVAR '\301' +#define CTLENDVAR '\371' +#define CTLBACKQ '\372' #define CTLQUOTE 01 /* ored with CTLBACKQ code if in quotes */ /* CTLBACKQ | CTLQUOTE == '\205' */ -#define CTLARI '\206' -#define CTLENDARI '\207' -#define CTLQUOTEMARK '\210' -#define CTLQUOTEEND '\211' /* only for ${v+-...} */ +#define CTLARI '\374' +#define CTLENDARI '\375' +#define CTLQUOTEMARK '\376' +#define CTLQUOTEEND '\377' /* only for ${v+-...} */ /* variable substitution byte (follows CTLVAR) */ #define VSTYPE 0x0f /* type of variable substitution */ Index: sh.1 =================================================================== --- sh.1 (revision 218467) +++ sh.1 (working copy) @@ -2510,4 +2510,7 @@ was originally written by .Sh BUGS The .Nm -utility does not recognize multibyte characters. +utility does not recognize multibyte characters other than UTF-8. +The line editing library +.Xr editline 3 +does not recognize multibyte characters. Index: expand.c =================================================================== --- expand.c (revision 218371) +++ expand.c (working copy) @@ -52,6 +52,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include /* * Routines to expand arguments to commands. We have to deal with @@ -111,16 +112,16 @@ static void addfname(char *); static struct strlist *expsort(struct strlist *); static struct strlist *msort(struct strlist *, int); static char *cvtnum(int, char *); -static int collate_range_cmp(int, int); +static int collate_range_cmp(wchar_t, wchar_t); static int -collate_range_cmp(int c1, int c2) +collate_range_cmp(wchar_t c1, wchar_t c2) { - static char s1[2], s2[2]; + static wchar_t s1[2], s2[2]; s1[0] = c1; s2[0] = c2; - return (strcoll(s1, s2)); + return (wcscoll(s1, s2)); } /* @@ -665,6 +666,7 @@ evalvar(char *p, int flag) int special; int startloc; int varlen; + int varlenb; int easy; int quotes = flag & (EXP_FULL | EXP_CASE | EXP_REDIR); @@ -712,8 +714,15 @@ again: /* jump here after setting a variable with if (special) { varvalue(var, varflags & VSQUOTE, subtype, flag); if (subtype == VSLENGTH) { - varlen = expdest - stackblock() - startloc; - STADJUST(-varlen, expdest); + varlenb = expdest - stackblock() - startloc; + varlen = varlenb; + if (localeisutf8) { + val = stackblock() + startloc; + for (;val != expdest; val++) + if ((*val & 0xC0) == 0x80) + varlen--; + } + STADJUST(-varlenb, expdest); } } else { char const *syntax = (varflags & VSQUOTE) ? DQSYNTAX @@ -721,7 +730,9 @@ again: /* jump here after setting a variable with if (subtype == VSLENGTH) { for (;*val; val++) - varlen++; + if (!localeisutf8 || + (*val & 0xC0) != 0x80) + varlen++; } else { if (quotes) @@ -1367,6 +1378,23 @@ msort(struct strlist *list, int len) +static wchar_t +get_wc(const char **p) +{ + wchar_t c; + int chrlen; + + chrlen = mbtowc(&c, *p, 4); + if (chrlen == 0) + return 0; + else if (chrlen == -1) + c = *(*p)++; + else + *p += chrlen; + return c; +} + + /* * Returns true if the pattern matches the string. */ @@ -1376,6 +1404,7 @@ patmatch(const char *pattern, const char *string, { const char *p, *q; char c; + wchar_t wc, wc2; p = pattern; q = string; @@ -1394,7 +1423,11 @@ patmatch(const char *pattern, const char *string, case '?': if (squoted && *q == CTLESC) q++; - if (*q++ == '\0') + if (localeisutf8) + wc = get_wc(&q); + else + wc = *q++; + if (wc == '\0') return 0; break; case '*': @@ -1424,7 +1457,7 @@ patmatch(const char *pattern, const char *string, case '[': { const char *endp; int invert, found; - char chr; + wchar_t chr; endp = p; if (*endp == '!' || *endp == '^') @@ -1445,8 +1478,11 @@ patmatch(const char *pattern, const char *string, p++; } found = 0; - chr = *q++; - if (squoted && chr == CTLESC) + if (squoted && *q == CTLESC) + q++; + if (localeisutf8) + chr = get_wc(&q); + else chr = *q++; if (chr == '\0') return 0; @@ -1456,19 +1492,27 @@ patmatch(const char *pattern, const char *string, continue; if (c == CTLESC) c = *p++; + if (localeisutf8 && c & 0x80) { + p--; + wc = get_wc(&p); + } else + wc = c; if (*p == '-' && p[1] != ']') { p++; while (*p == CTLQUOTEMARK) p++; if (*p == CTLESC) p++; - if ( collate_range_cmp(chr, c) >= 0 - && collate_range_cmp(chr, *p) <= 0 + if (localeisutf8) + wc2 = get_wc(&p); + else + wc2 = *p++; + if ( collate_range_cmp(chr, wc) >= 0 + && collate_range_cmp(chr, wc2) <= 0 ) found = 1; - p++; } else { - if (chr == c) + if (chr == wc) found = 1; } } while ((c = *p++) != ']'); Index: main.c =================================================================== --- main.c (revision 218371) +++ main.c (working copy) @@ -76,6 +76,7 @@ __FBSDID("$FreeBSD$"); int rootpid; int rootshell; struct jmploc main_handler; +int localeisutf8; static void read_profile(const char *); static char *find_dot_file(char *); @@ -96,6 +97,7 @@ main(int argc, char *argv[]) char *shinit; (void) setlocale(LC_ALL, ""); + updatecharset(); state = 0; if (setjmp(main_handler.loc)) { switch (exception) { Index: var.c =================================================================== --- var.c (revision 218371) +++ var.c (working copy) @@ -47,6 +47,7 @@ __FBSDID("$FreeBSD$"); */ #include +#include #include "shell.h" #include "output.h" @@ -361,6 +362,7 @@ setvareq(char *s, int flags) if ((vp->flags & VEXPORT) && localevar(s)) { change_env(s, 1); (void) setlocale(LC_ALL, ""); + updatecharset(); } INTON; return; @@ -379,6 +381,7 @@ setvareq(char *s, int flags) if ((vp->flags & VEXPORT) && localevar(s)) { change_env(s, 1); (void) setlocale(LC_ALL, ""); + updatecharset(); } INTON; } @@ -480,6 +483,7 @@ bltinsetlocale(void) if (loc != NULL) { setlocale(LC_ALL, loc); INTON; + updatecharset(); return; } locdef = bltinlookup("LANG", 0); @@ -491,6 +495,7 @@ bltinsetlocale(void) setlocale(locale_categories[i], loc); } INTON; + updatecharset(); } /* @@ -505,13 +510,25 @@ bltinunsetlocale(void) for (lp = cmdenviron ; lp ; lp = lp->next) { if (localevar(lp->text)) { setlocale(LC_ALL, ""); + updatecharset(); return; } } INTON; } +/* + * Update the localeisutf8 flag. + */ +void +updatecharset(void) +{ + char *charset; + charset = nl_langinfo(CODESET); + localeisutf8 = !strcmp(charset, "UTF-8"); +} + /* * Generate a list of exported variables. This routine is used to construct * the third argument to execve when executing a program. @@ -656,6 +673,7 @@ exportcmd(int argc, char **argv) if ((vp->flags & VEXPORT) && localevar(vp->text)) { change_env(vp->text, 1); (void) setlocale(LC_ALL, ""); + updatecharset(); } goto found; } @@ -850,6 +868,7 @@ unsetvar(const char *s) if ((vp->flags & VEXPORT) && localevar(vp->text)) { change_env(s, 0); setlocale(LC_ALL, ""); + updatecharset(); } vp->flags &= ~VEXPORT; vp->flags |= VUNSET; Index: var.h =================================================================== --- var.h (revision 218371) +++ var.h (working copy) @@ -81,6 +81,8 @@ extern struct var vhistsize; extern struct var vterm; #endif +extern int localeisutf8; + /* * The following macros access the values of the above variables. * They have to skip over the name. They return the null string @@ -112,6 +114,7 @@ char *lookupvar(const char *); char *bltinlookup(const char *, int); void bltinsetlocale(void); void bltinunsetlocale(void); +void updatecharset(void); char **environment(void); int showvarscmd(int, char **); int exportcmd(int, char **); --ikeVEW9yuYc//A+q-- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 25 17:07:14 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA381106566B; Fri, 25 Feb 2011 17:07:14 +0000 (UTC) (envelope-from creddym@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id C222B8FC0C; Fri, 25 Feb 2011 17:07:13 +0000 (UTC) Received: by wwb31 with SMTP id 31so2433307wwb.31 for ; Fri, 25 Feb 2011 09:07:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hFtKhz+k1r4Gx+b9nyEZNwjTtFGSILGNVXJ6NTwJrYM=; b=v49c29Gwq3lAudbeTD12arjgzyXR8zLOGHHJGP/KUtkr+NO6tlg7pJtKdxGFB4hf2B o36tWUkLue4zp+jgpQkdbeuuPjIXrPg2pErKA6EeiEPGWqg2LiUWdEhhkj0Qg1h1Au9W lPCkiFnLZjCqZZ0K+ZK8FA0plc6FFWOwYAiaw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NezypnHHcAPA8UxigfDnY8q5peM0C7Y6ANGxxgwSOdnZBOaugXLOGwXaZDWZfwU/ZK lTNNhNfuGNoo8CWkv4VQ7ov4tIhDmvWW3sozDNRqtI8WQO40DjUHWYhGDUanGPfal0nw C/yRDtOaG87BvqDXrucuWSSRnjoXDdOY3LrUI= MIME-Version: 1.0 Received: by 10.216.19.133 with SMTP id n5mr7062484wen.83.1298653632370; Fri, 25 Feb 2011 09:07:12 -0800 (PST) Received: by 10.216.78.147 with HTTP; Fri, 25 Feb 2011 09:07:12 -0800 (PST) In-Reply-To: References: Date: Fri, 25 Feb 2011 22:37:12 +0530 Message-ID: From: chandra reddy To: rwmaillists@googlemail.com X-Mailman-Approved-At: Fri, 25 Feb 2011 17:23:01 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, freebsd-i386@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Why FreeBSD fetch does not download a file via a proxy for HTTPS URLS (the same works fine for HTTP urls) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 17:07:14 -0000 Hi RW, Thanks alot for your reply. Do you mean to say "curl" also not using a CONNECT to tunnel through to the actual server? How can I achieve downloading files HTTPS over a proxy? Thanks <%20http://permalink.gmane.org/gmane.os.freebsd.devel.hackers/42588> -Chandra > Hi All, > > I am working on a project where i need to download a file via a proxy > server using HTTPS protocol. I found that fetch does not work/support > HTTPS requests over a proxy. I just checked and neither do wget nor curl. > I could overcome the above problem if I do the following change. > > 1375: > 1.58 > > des 1376: if (purl) { 1.51 > > des 1377: URL = purl; > I don't think that would work, presumably it would just cause an attempt at an ssl connection to the proxy, followed by a GET request for an https URL. https through a proxy is supposed to use a CONNECT to tunnel through to the actual server. On Thu, Feb 24, 2011 at 12:49 PM, chandra reddy wrote: > Hi All, > > I am working on a project where i need to download a file via a proxy > server using HTTPS protocol. I found that fetch does not work/support HTTPS > requests over a proxy. > > My setup would be like this: > > > > Intranet > Internet > ----------------------------------------------------------------------- > | https or http | > https > | Client m/cs -----------------------------> Porxy Server > -------------------------------> Destination Server (or Download server) > | | > ----------------------------------------------------------------------- > > > I can use https or http protocol between Client and Proxy but only HTTPS > is used between proxy and Destination server(or Download server) . > > I tried to use "squid" proxy as my proxy server and tried to download a > file from my download server to Client m/c using FreeBSD "fetch" command. > It fails to download a file via proxy for HTTPS requests Please note that > Proxy setup is 100% correct and a web server (Apache) running fine. > [I have tested it using my Mozilla browser on my PC]. > > I have done the following: > > 1. *Download a file using HTTPS over a proxy server* > > #env HTTP_PROXY=http://:3128/ /usr/sbin/fetch -v -o > /tmp/download.out 'https:///index.htm' > > looking up > > connecting to:443 > > connection established > > fetch: https:///index.htm Authentication error > Even I have tried this also and found the same error. > > #env HTTP_PROXY=https://:3128/ /usr/sbin/fetch -v -o > /tmp/download.out 'https:///index.htm' > > > My question is why it is not connected via "Proxy sever". It tries to > connect directly. I could see that if I use HTTP protocol then it connects > via proxy. > Please see the logs here. > > 2. *Download a file using HTTP over a proxy server* > > #env HTTP_PROXY=http://:3128/ /usr/sbin/fetch -v -o > /tmp/download.out 'http:///index.htm' > > looking up > > connecting to :3128 > > connection established > > requesting http://destination-server-ip/index.htm > Even I have tried this also and found that works fine. > > #env HTTP_PROXY=https://:3128/ /usr/sbin/fetch -v -o > /tmp/download.out 'http:///index.htm' > > I have debugged "fetch" and found that the following check is stopping > HTTPS requests over a proxy. > > *http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libfetch/http.c > > .OR. > > http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libfetch/http.c?annotate=1.78.2.5.4.1 > > * > > 1375: > 1.58 des 1376: if (purl && strcasecmp(URL->scheme, SCHEME_HTTPS) != 0) { > 1.51 des 1377: URL = purl; > > > > I could overcome the above problem if I do the following change. > > 1375: > 1.58 des 1376: if (purl) { > 1.51 des 1377: URL = purl; > > > I want to know why HTTPS over proxy is not working with "libfetch". I want > to make it work how can do it? > > Thanks > -Chandra > > -- Thanks, cr(); -------------------------------------------------------------------------------------------------------------------------- "Remote debugging a buggy debugger with a cross buggy debugger is a funny thing" -------------------------------------------------------------------------------------------------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 25 19:02:57 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1FAB1065672 for ; Fri, 25 Feb 2011 19:02:57 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from imr-db01.mx.aol.com (imr-db01.mx.aol.com [205.188.91.95]) by mx1.freebsd.org (Postfix) with ESMTP id 7F87A8FC12 for ; Fri, 25 Feb 2011 19:02:57 +0000 (UTC) Received: from imo-da03.mx.aol.com (imo-da03.mx.aol.com [205.188.169.201]) by imr-db01.mx.aol.com (8.14.1/8.14.1) with ESMTP id p1PJ2K7A003056; Fri, 25 Feb 2011 14:02:20 -0500 Received: from dieterbsd@engineer.com by imo-da03.mx.aol.com (mail_out_v42.9.) id n.f66.ef72306 (55713); Fri, 25 Feb 2011 14:02:17 -0500 (EST) Received: from smtprly-ma02.mx.aol.com (smtprly-ma02.mx.aol.com [64.12.207.141]) by cia-md01.mx.aol.com (v129.9) with ESMTP id MAILCIAMD014-5c524d67fcad35b; Fri, 25 Feb 2011 14:02:10 -0500 Received: from web-mmc-d05 (web-mmc-d05.sim.aol.com [205.188.103.95]) by smtprly-ma02.mx.aol.com (v129.9) with ESMTP id MAILSMTPRLYMA028-5c524d67fcad35b; Fri, 25 Feb 2011 14:02:05 -0500 To: kostikbel@gmail.com, freebsd-hackers@freebsd.org, freebsd-fs@freebsd.org Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Feb 2011 14:02:05 -0500 X-AOL-IP: 67.206.162.62 X-MB-Message-Source: WebUI Received: from 67.206.162.62 by web-mmc-d05.sysops.aol.com (205.188.103.95) with HTTP (WebMailUI); Fri, 25 Feb 2011 14:02:05 -0500 MIME-Version: 1.0 From: dieterbsd@engineer.com X-MB-Message-Type: User Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailer: Mail.com Webmail 33298-STANDARD Message-Id: <8CDA335A0CABF7E-338-9FC4@web-mmc-d05.sysops.aol.com> X-Spam-Flag: NO X-AOL-SENDER: dieterbsd@engineer.com Cc: minimarmot@gmail.com, brucec@freebsd.org Subject: quotas an essential feature? (was: svn commit: r218953 - stable/8/usr.sbin/sysinstall) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 19:02:57 -0000 > I promise to enable UFS quotas in GENERIC in one week unless anybody=20 objects > now. Huh? I thought GENERIC was supposed to include everything you needed to boot, not every possible feature that someone might desire? But requests to include things required to boot get rejected and nonessential features like quotas get added. WTF? From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 25 19:26:30 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37ECB1065670 for ; Fri, 25 Feb 2011 19:26:30 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id DA3818FC0A for ; Fri, 25 Feb 2011 19:26:29 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.4/8.14.3) with ESMTP id p1PJDqt5000256 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 25 Feb 2011 11:13:53 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4D67FF70.3000704@feral.com> Date: Fri, 25 Feb 2011 11:13:52 -0800 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <8CDA335A0CABF7E-338-9FC4@web-mmc-d05.sysops.aol.com> In-Reply-To: <8CDA335A0CABF7E-338-9FC4@web-mmc-d05.sysops.aol.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.168.221.1]); Fri, 25 Feb 2011 11:13:53 -0800 (PST) Subject: Re: quotas an essential feature? (was: svn commit: r218953 - stable/8/usr.sbin/sysinstall) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 19:26:30 -0000 Actually, GENERIC is there to provide the most features for the most uses. A large percentage of users don't config new kernels, and FreeBSD has not elected the approach Digital Unix (aka "DUH") took about installs which required a reconfig as one of the last steps of an installation. I can't speak to your "required to boot" case- not sure what you're referring to. I also have been sometimes unhappy about things that can't be added for booting, but that's really more of a "need a driver disk or options disk" kind of case that was more during the FreeBSD delivered on floppy which is long ago and far away and a country now pushing up daisies. On 2/25/2011 11:02 AM, dieterbsd@engineer.com wrote: >> I promise to enable UFS quotas in GENERIC in one week unless anybody > objects >> now. > > Huh? I thought GENERIC was supposed to include everything you needed to > boot, not every possible feature that someone might desire? > > But requests to include things required to boot get rejected and > nonessential features like quotas get added. WTF? > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 25 23:57:09 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B82E9106566C; Fri, 25 Feb 2011 23:57:09 +0000 (UTC) (envelope-from prvs=10374d3e62=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 01EF38FC08; Fri, 25 Feb 2011 23:57:08 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Fri, 25 Feb 2011 23:46:15 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 25 Feb 2011 23:46:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50012318159.msg; Fri, 25 Feb 2011 23:46:15 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=10374d3e62=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <317BD8618FA7450ABC86001948F4DFE4@multiplay.co.uk> From: "Steven Hartland" To: , , , References: <8CDA335A0CABF7E-338-9FC4@web-mmc-d05.sysops.aol.com> Date: Fri, 25 Feb 2011 23:46:30 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Cc: brucec@freebsd.org Subject: Re: quotas an essential feature? (was: svn commit: r218953 - stable/8/usr.sbin/sysinstall) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 23:57:09 -0000 While I can understand some may want its not something we use on any of our machines, and I suspect that's the case for many others. Given adding it means the kernel will be doing extra work and hence a drop in performance for a feature most will never use, I'm guessing here, I would say just leave it out of generic unless there is a real pressing requirement for it? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 26 07:49:31 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 185441065674; Sat, 26 Feb 2011 07:49:31 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id CD1FE8FC1A; Sat, 26 Feb 2011 07:49:30 +0000 (UTC) Received: by iwn33 with SMTP id 33so1940573iwn.13 for ; Fri, 25 Feb 2011 23:49:30 -0800 (PST) Received: by 10.42.218.134 with SMTP id hq6mr1873491icb.289.1298705104301; Fri, 25 Feb 2011 23:25:04 -0800 (PST) Received: from [192.168.2.119] (99-74-169-43.lightspeed.sntcca.sbcglobal.net [99.74.169.43]) by mx.google.com with ESMTPS id wt14sm1096803icb.4.2011.02.25.23.25.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 Feb 2011 23:25:03 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle X-Priority: 3 In-Reply-To: <317BD8618FA7450ABC86001948F4DFE4@multiplay.co.uk> Date: Fri, 25 Feb 2011 23:25:00 -0800 Content-Transfer-Encoding: 7bit Message-Id: <98FE1AB5-5276-4B12-A034-106330EBB713@kientzle.com> References: <8CDA335A0CABF7E-338-9FC4@web-mmc-d05.sysops.aol.com> <317BD8618FA7450ABC86001948F4DFE4@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1082) Cc: freebsd-fs@freebsd.org, freebsd-hackers Subject: Re: quotas an essential feature? (was: svn commit: r218953 - stable/8/usr.sbin/sysinstall) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 07:49:31 -0000 On Feb 25, 2011, at 3:46 PM, Steven Hartland wrote: > While I can understand some may want its not something we use on any of > our machines, and I suspect that's the case for many others. > > Given adding it means the kernel will be doing extra work and hence a > drop in performance... Does anyone have benchmark results to measure the performance hit? Tim From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 26 08:55:27 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D720A106566C for ; Sat, 26 Feb 2011 08:55:27 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by mx1.freebsd.org (Postfix) with ESMTP id 953D48FC17 for ; Sat, 26 Feb 2011 08:55:27 +0000 (UTC) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta12.westchester.pa.mail.comcast.net with comcast id CYiD1g0010bG4ec5CYiDZx; Sat, 26 Feb 2011 08:42:13 +0000 Received: from koitsu.dyndns.org ([98.248.33.18]) by omta03.westchester.pa.mail.comcast.net with comcast id CYiB1g0090PUQVN3PYiBvG; Sat, 26 Feb 2011 08:42:12 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0AF279B422; Sat, 26 Feb 2011 00:42:10 -0800 (PST) Date: Sat, 26 Feb 2011 00:42:10 -0800 From: Jeremy Chadwick To: Tim Kientzle Message-ID: <20110226084210.GA24248@icarus.home.lan> References: <8CDA335A0CABF7E-338-9FC4@web-mmc-d05.sysops.aol.com> <317BD8618FA7450ABC86001948F4DFE4@multiplay.co.uk> <98FE1AB5-5276-4B12-A034-106330EBB713@kientzle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <98FE1AB5-5276-4B12-A034-106330EBB713@kientzle.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sat, 26 Feb 2011 12:38:06 +0000 Cc: freebsd-fs@freebsd.org, freebsd-hackers , Steven Hartland Subject: Re: quotas an essential feature? (was: svn commit: r218953 - stable/8/usr.sbin/sysinstall) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 08:55:27 -0000 On Fri, Feb 25, 2011 at 11:25:00PM -0800, Tim Kientzle wrote: > On Feb 25, 2011, at 3:46 PM, Steven Hartland wrote: > > > While I can understand some may want its not something we use on any of > > our machines, and I suspect that's the case for many others. > > > > Given adding it means the kernel will be doing extra work and hence a > > drop in performance... > > Does anyone have benchmark results to measure the performance hit? I imagine there wouldn't be any (or extremely negligible) unless you used quotaon(8). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 26 12:57:15 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFB63106566C; Sat, 26 Feb 2011 12:57:15 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 218D48FC0C; Sat, 26 Feb 2011 12:57:14 +0000 (UTC) Received: by wwb31 with SMTP id 31so3290177wwb.31 for ; Sat, 26 Feb 2011 04:57:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=TOdXdMepBF51gDF5sw8yntQLxmKpLvD/xYELnoP4pUs=; b=jpZHxjTwYiOHCGY1Kd+86y9QPz47xFmJv05czVzYb17DRl/YiBdYaTB2uGvl8r1FC+ IKbW3jYKmPoGpizyZ0lzALWC4L+GIG6AOmfaV10TGtbQXV5n9i2W8AarevvUVDoiH26z gQnXy2gL13HxOOYiK+Bz152Y1l1ul2RWSjlT0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=JO6jUIph2lb91xWy1CrDwvP5AgZ1o20PrKbCRrThR+B1fJR1l/ei5nEcIvaZhkJuaq U8UdrBVlyyywfqYiQcYzagqFylF49ZjWTfzbIox5dHR02u9QWWLKPMSaKQKDMr12svDR tbEuUnNhy1eTO6s4qzOHhIQjPwMsdII3bqUS0= MIME-Version: 1.0 Received: by 10.227.2.83 with SMTP id 19mr3138908wbi.115.1298723196690; Sat, 26 Feb 2011 04:26:36 -0800 (PST) Received: by 10.227.72.213 with HTTP; Sat, 26 Feb 2011 04:26:36 -0800 (PST) Date: Sat, 26 Feb 2011 14:26:36 +0200 Message-ID: From: Marin Atanasov Nikolov To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 12:57:15 -0000 Hello, I updated a system from 8.1-RELEASE to 8.2-RELEASE today and now I'm having issues with gpart and gmirror. In the past I had two non-identical disks (one 250gb and one 750gb), which I wanted to create a mirror for them, so to do this, I gpart'ed them to equal sizes and then gmirror'ed them, without any issues. Of course that means that the rest 500gb of the bigger disk is not mirrored, but that wasn't a problem, since I was keeping non-important data there. Now I've got a second 750gb disk and updated to 8.2-RELEASE, and I wanted to create a full mirror of the two disks and the problems popped up. Hope you can help me a bit here. What I did is: 1. Backed up my system 2. Booted from FixIt image 3. Removed all previous partitions for gpart. 4. Did a gmirror for ad0 Fixit# gmirror label -vb round-robin gm0 /dev/ad0 5. gpart'ed the gm0 device, so I have gm0pN partitions 6. Restored everything from the backup to the gmirror'ed partitions 7. Reboot After a reboot I get this right before the FreeBSD bootloader starts: gptboot:=A0invalid GPT backup header I suppose this error simply means that gpart can't find it's backup header, because gmirror and gpart both are using the last sectors for a provider to write it's metadata. Which would mean that gmirror and gpart metadata overlap, and that's why I see this message? Anyway, I can still boot from the primary GPT header, and here's the second message I get during boot: GEOM: ad0: secondary GPT header is not in the last LBA. Why does GEOM reports ad0, and not mirror/gm0 as the provider? I've used the gmirror'ed device for gpart, not ad0. I still have another option, and that is to create partitions on the disks and then gmirror them, just like a did before without issues, and my explanation for this would be that gpart would use the last sectors of ad0 and ad1, while gmirror would use the last sectors of the partitions - ad0pN. That way I don't get any issues, but why when I want to create mirror of the whole disks I get this? Shouldn't gmirror and gpart store it's data on different sectors in that case? What would happen if I try to glabel the disks first, then gmirror and then gpart them? I guess I would mess up everything again. Should I go back to my previous setup with mirroring partitions, instead of disks? gpart now supports a `backup' option, so inserting a new disk in case of disk crash is just as simple as putting the new disk, restoring GPT tables from backup and putting the partitions in a mirror. Thanks for any feedback. Marin -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org http://www.unix-heaven.org/ From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 26 15:18:27 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5117106566B; Sat, 26 Feb 2011 15:18:27 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 276958FC15; Sat, 26 Feb 2011 15:18:25 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA10603; Sat, 26 Feb 2011 17:18:24 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PtLua-0003Xp-2B; Sat, 26 Feb 2011 17:18:24 +0200 Message-ID: <4D6919BE.3090003@freebsd.org> Date: Sat, 26 Feb 2011 17:18:22 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101211 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-multimedia@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: /dev/dsp mmap question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 15:18:27 -0000 Guys, if we the following on FreeBSD (pseudo-code): fd = open(/dev/dsp, O_RDWR); mmap(PROT_READ, fd); mmap(PROT_WRITE, fd); This won't work entirely correctly, right? I base my question on some observations of how a particular program behaves on FreeBSD and on the following comment in sys/dev/sound/pcm/dsp.c: /* * XXX The linux api uses the nprot to select read/write buffer * our vm system doesn't allow this, so force write buffer. * * This is just a quack to fool full-duplex mmap, so that at * least playback _or_ recording works. If you really got the * urge to make _both_ work at the same time, avoid O_RDWR. * Just open each direction separately and mmap() it. * * Failure is not an option due to INVARIANTS check within * device_pager.c, which means, we have to give up one over * another. */ P.S. is this something that can easily fixed or not? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 26 18:31:22 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 585FD1065670 for ; Sat, 26 Feb 2011 18:31:22 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward8.mail.yandex.net (forward8.mail.yandex.net [77.88.61.38]) by mx1.freebsd.org (Postfix) with ESMTP id 0227F8FC17 for ; Sat, 26 Feb 2011 18:31:21 +0000 (UTC) Received: from smtp8.mail.yandex.net (smtp8.mail.yandex.net [77.88.61.54]) by forward8.mail.yandex.net (Yandex) with ESMTP id 2B346F619B4; Sat, 26 Feb 2011 21:15:46 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1298744146; bh=BpT/QrOUKLBm0womk6DVZiXv4lL18htH8x5VXB2dqIQ=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=jBnKJfDLoyRUAV3c0zJI5En2Cf+qJuzHRBofZKb3BVqGcxvj2KmtUc/axLHPCsvZD E60sufHxyjZkk97CarCqIIMqNCDgHayq5jIZqvRmk80Jm0gO9V58qC0mZFy7ghrYem dMTRgVea7EnWMplxfG3ZJDaccmSMsQwu32JyfwVs= Received: from [178.141.6.23] (dynamic-178-141-6-23.kirov.comstar-r.ru [178.141.6.23]) by smtp8.mail.yandex.net (Yandex) with ESMTPSA id D47FE41900B5; Sat, 26 Feb 2011 21:15:45 +0300 (MSK) Message-ID: <4D694336.3090203@yandex.ru> Date: Sat, 26 Feb 2011 21:15:18 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110122 Thunderbird/3.1.7 MIME-Version: 1.0 To: Marin Atanasov Nikolov References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1F430112FAE44C26722D253D" Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 18:31:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1F430112FAE44C26722D253D Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 26.02.2011 15:26, Marin Atanasov Nikolov wrote: > After a reboot I get this right before the FreeBSD bootloader starts: >=20 > gptboot: invalid GPT backup header >=20 > I suppose this error simply means that gpart can't find it's backup > header, because gmirror and gpart both are using the last sectors for > a provider to write it's metadata. This message is from gptboot. Loader does not know about your software mirror and it just checks GPT headers in the second and last LBA. As i see now, there is inconsistency in the behavior between gptboot and GEOM_PART_GPT. gptboot does reading of GPT backup header from the last LBA, but GEOM_PART_GPT from the alternate LBA which is not equal to last LBA in your case. > Which would mean that gmirror and gpart metadata overlap, and that's > why I see this message? No. > Anyway, I can still boot from the primary GPT header, and here's the > second message I get during boot: >=20 > GEOM: ad0: secondary GPT header is not in the last LBA. >=20 > Why does GEOM reports ad0, and not mirror/gm0 as the provider? I've > used the gmirror'ed device for gpart, not ad0. This is how GEOM tasting works. Do you have any problem except for those messages? What does not work? Also when you are writing problem report about gpart it will be not bad to add output of `gpart show` or `gpart list` commands. And `gmirror list` for GEOM_MIRROR. --=20 WBR, Andrey V. Elsukov --------------enig1F430112FAE44C26722D253D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBAgAGBQJNaUNBAAoJEAHF6gQQyKF6Iw8H/0ogwxSIoc6fMui2kRIltYNk TNS6OePTMf1n1UnHcKsixkA8mdRxXj3gv7+2G2WyXyKQGCvNSnjz3QgrID+Mc1Rm WE1N7UyGVzxC2Jto7HYN5TisSEC0gj95laK481unGGKRUGeoeJaX0+mTIz8NU1eQ HruiPEjqC7Mx8Py9ZmiNhaVDjgrTQCpb7IIAEhwZVFGvzsC+0k0paKyJ/vAK6FEj pwf0NbyaMHacj5iPe0DgJmMmhNOBqtrBGrX0Lt1W51A3KIdUBfzzUjQoww9TsgMw FQ6tZg9HmJE1wTsGQo13l6XIr4etGNALD7swW2IvdMDtzor+SOnFqb9fHsoyh5k= =Ywvu -----END PGP SIGNATURE----- --------------enig1F430112FAE44C26722D253D-- From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 26 18:53:44 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88A02106566C; Sat, 26 Feb 2011 18:53:44 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id EB36C8FC17; Sat, 26 Feb 2011 18:53:43 +0000 (UTC) Received: by wyb32 with SMTP id 32so3075072wyb.13 for ; Sat, 26 Feb 2011 10:53:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YIMzuwr7+dIvbavjA2e2v/hCK1MR8TwWkYukyNC0TUw=; b=dEcZTRnsgyIkbaXoldxjSrgAJSu0i78pLAosWrYhrb9tP1+EAuRzPRcYW8tNlLadaC XqeEJbPG2nP3uFXzh3sRKeXHC4UvTzzXcnAKbO8eZz6ilY3rUQ9n8TMtNulxxNhEax56 hQuK4rXxyYr4YAQFXwSfbtnylxZqfRFnHCJsQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bNCMlBbd0N/zHoz/lAnEdHVQp/ijyiwMuHN6j/8Mri5Hd81Al7eudhkL8AGLzqss94 IRPbR0YP0uaWTlJLF2xh1i5gdOPsFknfHeKiOxVPj+xcmr9LNBD+2qGu2cQ51um0ico1 KUff7MxsXVxi8DH/tZ9E4jXhC51YD0hX2UsCU= MIME-Version: 1.0 Received: by 10.227.2.83 with SMTP id 19mr3397767wbi.115.1298746422366; Sat, 26 Feb 2011 10:53:42 -0800 (PST) Received: by 10.227.72.213 with HTTP; Sat, 26 Feb 2011 10:53:42 -0800 (PST) In-Reply-To: <4D694336.3090203@yandex.ru> References: <4D694336.3090203@yandex.ru> Date: Sat, 26 Feb 2011 20:53:42 +0200 Message-ID: From: Marin Atanasov Nikolov To: "Andrey V. Elsukov" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 18:53:44 -0000 2011/2/26 Andrey V. Elsukov : > On 26.02.2011 15:26, Marin Atanasov Nikolov wrote: >> After a reboot I get this right before the FreeBSD bootloader starts: >> >> gptboot: invalid GPT backup header >> >> I suppose this error simply means that gpart can't find it's backup >> header, because gmirror and gpart both are using the last sectors for >> a provider to write it's metadata. > > This message is from gptboot. Loader does not know about your software > mirror and it just checks GPT headers in the second and last LBA. > As i see now, there is inconsistency in the behavior between gptboot and > GEOM_PART_GPT. > > gptboot does reading of GPT backup header from the last LBA, > but GEOM_PART_GPT from the alternate LBA which is not equal to last LBA > in your case. > >> Which would mean that gmirror and gpart metadata overlap, and that's >> why I see this message? > > No. > >> Anyway, I can still boot from the primary GPT header, and here's the >> second message I get during boot: >> >> GEOM: ad0: secondary GPT header is not in the last LBA. >> >> Why does GEOM reports ad0, and not mirror/gm0 as the provider? I've >> used the gmirror'ed device for gpart, not ad0. > > This is how GEOM tasting works. Do you have any problem except for > those messages? What does not work? No, no other issues noticed. > > Also when you are writing problem report about gpart it will be not bad > to add output of `gpart show` or `gpart list` commands. And `gmirror > list` for GEOM_MIRROR. Would do that, but unfortunately as mentioned I was running a Fixit image locally, so the only thing I got was a lit of paper and a pen to write down the messages :) Anyway, I've switched back to partition mirroring, which is good enough for me. Redundancy is still present in case of a disk failure since the second disk also contains bootcode and it boots up normally. Thanks for the feedback. Regards, Marin > > -- > WBR, Andrey V. Elsukov > > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org http://www.unix-heaven.org/ From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 26 18:30:44 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD108106566B; Sat, 26 Feb 2011 18:30:44 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id B08778FC08; Sat, 26 Feb 2011 18:30:44 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id p1QIUige092782; Sat, 26 Feb 2011 10:30:44 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id p1QIUila092781; Sat, 26 Feb 2011 10:30:44 -0800 (PST) (envelope-from sgk) Date: Sat, 26 Feb 2011 10:30:44 -0800 From: Steve Kargl To: freebsd-hackers@freebsd.org, freebsd-standards@freebsd.org Message-ID: <20110226183044.GA92706@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Sat, 26 Feb 2011 20:56:20 +0000 Cc: Subject: [PATCH] improve accuracy and speed of tanh[f] for x in [0:1) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 18:30:45 -0000 The patch that follows my signature improves both the accuracy and speed of tanhf and tanh in the interval [0,1). The testing was done on an Intel Core2 Duo CPU T7250 and everything is compiled with gcc. The improvements are accomplished by using a trancated continued fraction instead of relying on expm1[f] and a rewritten definition of tanh(x). The results can be summarized by | fdlibm | Con. frac. ------------------------------- | ulp time | ulp time tanhf | 1.66 1.36 | 0.56 1.31 tanh | 2.16 5.65 | 1.53 5.33 tanhl | 2.36 4.72 | 1.53 5.12 ulp in the above table is the maximum ulp observed for 2 million evenly distributed values with the interval. The timing for tanhf is for 5 million calls and the timing for tanh is for 20 million calls, where again the values are evenly distributed across the interval. The timings are the total time in seconds for a tight loop. For those paying attention, yes, the last entry is for tanhl, which libm does not currently implement. I have an implementation that uses expm1l and fdlibm's simple rewritten tanh(x) definition. I, of course, have a truncated continued fraction implementation as well. Now for those that are really paying attention, libm does not contain an expm1l. :) -- Steve Index: src/s_tanh.c =================================================================== --- src/s_tanh.c (revision 219046) +++ src/s_tanh.c (working copy) @@ -66,8 +66,33 @@ t = expm1(two*fabs(x)); z = one - two/(t+two); } else { +#if 0 + /* + * In the interval, one has a max ulp of 2.156 for 2M + * evenly distributed values. For timing, 20M call + * gives 5.65 s. + */ t = expm1(-two*fabs(x)); z= -t/(t+two); +#else + /* + * This is a continued fraction representation that + * was truncated at the 10th level and then refractored + * to get rid of the divisions. In the interval, one + * has a max ulp of 1.532 for 2M evenly distributed + * values. For timing, 20M calls give 5.33 s. + */ + double x2, t1, t2, t3, t4, t5; + x2 = x * x; + t1 = 399 + 20 * x2; + t3 = 17 * t1 + (21 + x2) * x2; + t4 = 15 * t3 + t1 * x2; + t5 = 13 * t4 + t3 * x2; + t2 = 99 * t5 + (9 * t4 + t5) * x2; + t3 = 7 * t2 + (11 * t5 + t4 * x2) * x2; + z = x / (1 + x2 / (3 + t3 * x2 / (5 * t3 + t2 * x2))); + return (z); +#endif } /* |x| >= 22, return +-1 */ } else { Index: src/s_tanhf.c =================================================================== --- src/s_tanhf.c (revision 219046) +++ src/s_tanhf.c (working copy) @@ -44,8 +44,29 @@ t = expm1f(two*fabsf(x)); z = one - two/(t+two); } else { +#if 0 + /* + * In the interval, one has a max ulp of 1.66 for 2M + * evenly distributed values. For timing, 5M calls + * give 1.36 s. + */ t = expm1f(-two*fabsf(x)); z= -t/(t+two); +#else + /* + * This is a continued fraction representation that + * was truncated at the 6th level and then refractored + * to get rid of the divisions. In the interval, one + * has a max ulp of 0.559 for 2M evenly distributed + * values. For timing, 5M calls give 1.306 s. + */ + float x2, t1, t2, t3; + x2 = x * x; + t1 = 11 + x2; + t2 = 9 * t1 + x2; + t3 = 7 * t2 + t1 * x2; + z = x / (1 + x2 / (3 + t3 * x2 / (5 * t3 + t2 * x2 ))); +#endif } /* |x| >= 9, return +-1 */ } else {