Re: ctfconvert dependency...
Shrikanth Kamath wrote:
Just trying to understand the build dependency for ctfconvert...
I see ctfconvert (cddl/usr.bin/ctfconvert/) has dependency on libctf.a
(cddl/lib/libctf/)
Now the snippet in bsd.lib.mk has this check for various target suffixes,
.c.So:
.if defined(CTFCONVERT)
${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
.endif
and sys.mk
.c
.if defined(CTFCONVERT)
${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
.endif
My query, libctf includes in it's Makefile, so will the above
not try to
run 'ctfconvert' on libctf itself?
I'm going to make some assumptions and go out on a limb here..
The CDDL code in FBSD came from OpenSolaris (specifically onnv-gate hg
repo) When OpenSolaris is built they convert stab debugging information
over to CTF (compressed text format?). This is done so that they can
have debugging information, but without the overhead of stab (or
dwarf2). I don't know how much of the original onnv-gate Makefiles came
over from OpenSolaris, but assuming the FBSD kernel doesn't need/use CTF
format this dependency can and probably should go away. (Only (k)mdb
supports CTF that I'm aware of?)
Hopefully this is useful information and I'm not too wrong or someone
will correct me
Best,
./C
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ctfconvert dependency...
Any idea if ctfconvert is needed to run on the cddl and sys/cddl files? My
understanding here is ctfconvert
needs to build the ctfdata for the kernel image and the kernel loadable
modules. If we were to DTrace 'DTrace' then
we need the ctfdata for the files under cddl/ and sys/cddl, is that correct?
2010/3/11 Marius Nünnerich
> 2010/3/11 "C. Bergström" :
> > Shrikanth Kamath wrote:
> >>
> >> Just trying to understand the build dependency for ctfconvert...
> >>
> >> I see ctfconvert (cddl/usr.bin/ctfconvert/) has dependency on libctf.a
> >> (cddl/lib/libctf/)
> >>
> >> Now the snippet in bsd.lib.mk has this check for various target
> suffixes,
> >>
> >> .c.So:
> >> .if defined(CTFCONVERT)
> >>${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
> >> .endif
> >>
> >> and sys.mk
> >>
> >> .c
> >> .if defined(CTFCONVERT)
> >>${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
> >> .endif
> >>
> >> My query, libctf includes in it's Makefile, so will the
> >> above
> >> not try to
> >> run 'ctfconvert' on libctf itself?
> >>
> >
> > I'm going to make some assumptions and go out on a limb here..
> >
> > The CDDL code in FBSD came from OpenSolaris (specifically onnv-gate hg
> repo)
> > When OpenSolaris is built they convert stab debugging information over
> to
> > CTF (compressed text format?). This is done so that they can have
> debugging
> > information, but without the overhead of stab (or dwarf2). I don't know
> how
> > much of the original onnv-gate Makefiles came over from OpenSolaris, but
> > assuming the FBSD kernel doesn't need/use CTF format this dependency can
> and
> > probably should go away. (Only (k)mdb supports CTF that I'm aware of?)
> >
> > Hopefully this is useful information and I'm not too wrong or someone
> will
> > correct me
>
> The CTF information is needed by DTrace.
> My guess is that it will run ctfconvert on itself so it should be
> there from a prior install or it is part of some early toolchain
> stuff.
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ctfconvert dependency...
Marius Nünnerich wrote:
2010/3/11 "C. Bergström" :
Shrikanth Kamath wrote:
Just trying to understand the build dependency for ctfconvert...
I see ctfconvert (cddl/usr.bin/ctfconvert/) has dependency on libctf.a
(cddl/lib/libctf/)
Now the snippet in bsd.lib.mk has this check for various target suffixes,
.c.So:
.if defined(CTFCONVERT)
${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
.endif
and sys.mk
.c
.if defined(CTFCONVERT)
${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
.endif
My query, libctf includes in it's Makefile, so will the
above
not try to
run 'ctfconvert' on libctf itself?
I'm going to make some assumptions and go out on a limb here..
The CDDL code in FBSD came from OpenSolaris (specifically onnv-gate hg repo)
When OpenSolaris is built they convert stab debugging information over to
CTF (compressed text format?). This is done so that they can have debugging
information, but without the overhead of stab (or dwarf2). I don't know how
much of the original onnv-gate Makefiles came over from OpenSolaris, but
assuming the FBSD kernel doesn't need/use CTF format this dependency can and
probably should go away. (Only (k)mdb supports CTF that I'm aware of?)
Hopefully this is useful information and I'm not too wrong or someone will
correct me
The CTF information is needed by DTrace.
My guess is that it will run ctfconvert on itself so it should be
there from a prior install or it is part of some early toolchain
stuff.
CTF is needed by DTrace where? The build may depend on it, but this is
probably for legacy reasons only. DTrace in opensolaris isn't dependent
on it to function correctly. Replace the $(CTFCONVERT) and a few other
utilities with /bin/true and the build will succeed. (I can only speak
first hand from OSUNIX/OpenSolaris though and not FBSD..)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
bus_space_tag, bus_space_handle
Hi. Im currently needing to write to a few registers for a PCI device. The driver is provided, but it does not contain support for writing specific registers itself. I also do not with to modify the driver. I would like to know what the best method would be for writing to these registers, the best way to go about getting bus_space_tag, and handle for the connected pci device. Im currently using FreeBSD 7.x. Regards /Cole ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ctfconvert dependency...
This DTrace wiki page mandates the CTF option when enabling DTrace,
http://wiki.freebsd.org/DTrace#head-41e7ce9a981893f126bd67c0eb77f388e2213d9d
2010/3/11 "C. Bergström"
> Marius Nünnerich wrote:
>
>> 2010/3/11 "C. Bergström" :
>>
>>
>>> Shrikanth Kamath wrote:
>>>
>>>
Just trying to understand the build dependency for ctfconvert...
I see ctfconvert (cddl/usr.bin/ctfconvert/) has dependency on libctf.a
(cddl/lib/libctf/)
Now the snippet in bsd.lib.mk has this check for various target
suffixes,
.c.So:
.if defined(CTFCONVERT)
${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
.endif
and sys.mk
.c
.if defined(CTFCONVERT)
${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
.endif
My query, libctf includes in it's Makefile, so will the
above
not try to
run 'ctfconvert' on libctf itself?
>>> I'm going to make some assumptions and go out on a limb here..
>>>
>>> The CDDL code in FBSD came from OpenSolaris (specifically onnv-gate hg
>>> repo)
>>> When OpenSolaris is built they convert stab debugging information over
>>> to
>>> CTF (compressed text format?). This is done so that they can have
>>> debugging
>>> information, but without the overhead of stab (or dwarf2). I don't know
>>> how
>>> much of the original onnv-gate Makefiles came over from OpenSolaris, but
>>> assuming the FBSD kernel doesn't need/use CTF format this dependency can
>>> and
>>> probably should go away. (Only (k)mdb supports CTF that I'm aware of?)
>>>
>>> Hopefully this is useful information and I'm not too wrong or someone
>>> will
>>> correct me
>>>
>>>
>>
>> The CTF information is needed by DTrace.
>> My guess is that it will run ctfconvert on itself so it should be
>> there from a prior install or it is part of some early toolchain
>> stuff.
>>
>>
> CTF is needed by DTrace where? The build may depend on it, but this is
> probably for legacy reasons only. DTrace in opensolaris isn't dependent on
> it to function correctly. Replace the $(CTFCONVERT) and a few other
> utilities with /bin/true and the build will succeed. (I can only speak
> first hand from OSUNIX/OpenSolaris though and not FBSD..)
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ctfconvert dependency...
On Thu, Mar 11, 2010 at 10:26, Shrikanth Kamath wrote: > Any idea if ctfconvert is needed to run on the cddl and sys/cddl files? My > understanding here is ctfconvert > needs to build the ctfdata for the kernel image and the kernel loadable > modules. If we were to DTrace 'DTrace' then > we need the ctfdata for the files under cddl/ and sys/cddl, is that correct? ctf information is needed for everything we want to dtrace. We even need it for tracing userland stuff but that doesn't work right now for other reasons. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ctfconvert dependency...
2010/3/11 "C. Bergström" :
> Marius Nünnerich wrote:
>>
>> 2010/3/11 "C. Bergström" :
>>
>>>
>>> Shrikanth Kamath wrote:
>>>
Just trying to understand the build dependency for ctfconvert...
I see ctfconvert (cddl/usr.bin/ctfconvert/) has dependency on libctf.a
(cddl/lib/libctf/)
Now the snippet in bsd.lib.mk has this check for various target
suffixes,
.c.So:
.if defined(CTFCONVERT)
${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
.endif
and sys.mk
.c
.if defined(CTFCONVERT)
${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
.endif
My query, libctf includes in it's Makefile, so will the
above
not try to
run 'ctfconvert' on libctf itself?
>>>
>>> I'm going to make some assumptions and go out on a limb here..
>>>
>>> The CDDL code in FBSD came from OpenSolaris (specifically onnv-gate hg
>>> repo)
>>> When OpenSolaris is built they convert stab debugging information over
>>> to
>>> CTF (compressed text format?). This is done so that they can have
>>> debugging
>>> information, but without the overhead of stab (or dwarf2). I don't know
>>> how
>>> much of the original onnv-gate Makefiles came over from OpenSolaris, but
>>> assuming the FBSD kernel doesn't need/use CTF format this dependency can
>>> and
>>> probably should go away. (Only (k)mdb supports CTF that I'm aware of?)
>>>
>>> Hopefully this is useful information and I'm not too wrong or someone
>>> will
>>> correct me
>>>
>>
>> The CTF information is needed by DTrace.
>> My guess is that it will run ctfconvert on itself so it should be
>> there from a prior install or it is part of some early toolchain
>> stuff.
>>
>
> CTF is needed by DTrace where? The build may depend on it, but this is
> probably for legacy reasons only. DTrace in opensolaris isn't dependent on
> it to function correctly. Replace the $(CTFCONVERT) and a few other
> utilities with /bin/true and the build will succeed. (I can only speak
> first hand from OSUNIX/OpenSolaris though and not FBSD..)
The build will succeed but dtracing something with the FBT provider won't.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ctfconvert dependency...
2010/3/11 "C. Bergström" :
> Shrikanth Kamath wrote:
>>
>> Just trying to understand the build dependency for ctfconvert...
>>
>> I see ctfconvert (cddl/usr.bin/ctfconvert/) has dependency on libctf.a
>> (cddl/lib/libctf/)
>>
>> Now the snippet in bsd.lib.mk has this check for various target suffixes,
>>
>> .c.So:
>> .if defined(CTFCONVERT)
>> ${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
>> .endif
>>
>> and sys.mk
>>
>> .c
>> .if defined(CTFCONVERT)
>> ${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
>> .endif
>>
>> My query, libctf includes in it's Makefile, so will the
>> above
>> not try to
>> run 'ctfconvert' on libctf itself?
>>
>
> I'm going to make some assumptions and go out on a limb here..
>
> The CDDL code in FBSD came from OpenSolaris (specifically onnv-gate hg repo)
> When OpenSolaris is built they convert stab debugging information over to
> CTF (compressed text format?). This is done so that they can have debugging
> information, but without the overhead of stab (or dwarf2). I don't know how
> much of the original onnv-gate Makefiles came over from OpenSolaris, but
> assuming the FBSD kernel doesn't need/use CTF format this dependency can and
> probably should go away. (Only (k)mdb supports CTF that I'm aware of?)
>
> Hopefully this is useful information and I'm not too wrong or someone will
> correct me
The CTF information is needed by DTrace.
My guess is that it will run ctfconvert on itself so it should be
there from a prior install or it is part of some early toolchain
stuff.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: namei() returns EISDIR for "/" (Re: svn commit: r203990 - head/lib/libc/sys)
On 2010-03-10, Alexander Best wrote: > could this panic have been triggered by the patch? It doesn't look like it's caused by the patch. > panic() at panic+0x15f > _mtx_lock_flags() at _mtx_lock_flags+0xc5 > fdesc_allocvp() at fdesc_allocvp+0xbf > fdesc_lookup() at fdesc_lookup+0x15c > > this was 100% reducible when doing `portsnap fetch` though i changed a lot of > stuff in my kernel config and reverted a lot of src patches to resolve the > issue so i'm not sure what exactly was causing it. The panic happened in fdescfs code. Did you have local patches related to fdescfs? -- Jaakko ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: To sendmail or to postfix that is the question?
Steven Hartland wrote: Ok so I'm looking to replace our current windows mail server using mdaemon with a FreeBSD solution, having looked around there seems to be differing opinions of which is the best option to go with between sendmail and postfix. ... Any advice, opinions on a full mail solution on FreeBSD would be appreciated. Regards Steve Sorry to hi-jack your thread, but this is also something I am currently looking in to I really wanted to use Sendmail as a friend knows Sendmail fairly well and I have a Sendmail book, but what I am wanting is the ability to have mail for virtual users, ie I might have 4 admin accounts, ad...@domain1.com ad...@domain2.com ad...@domain3.com and ad...@domain4.com and want all the accounts to be independent of each other and not necessarily have a real UNIX user account. I know I can create 4 different admin accounts say admin1, admin2, admin3, admin4 and then use the "virtual users" table, but I can see that getting a little messy and from the end user's point they are going to have unusual login names. I know I can do this in Postfix, but is it possible in Sendmail? Cheers Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: tty or script(1) weirdness?
On Wed, 10 Mar 2010 21:04:10 +0100 Ed Schouten wrote: > * Ed Schouten wrote: > > Hmmm... It seems this is a TTY bug. When you close a TTY, the final > > close() call should get stuck until all data is actually drained. This > > doesn't seem to happen properly. > > Some further research: it's not a TTY bug, but a bug in script(1). > The script parent process leaves a file descriptor open, which means > output is never properly drained. > > I can't reproduce this issue after applying this patch: > > %%% > Index: script.c > === > --- script.c (revision 204965) > +++ script.c (working copy) > @@ -158,6 +158,8 @@ > } > if (child == 0) > doshell(argv); > + else > + close(slave); > > if (flushtime > 0) > tvp = &tv; > %%% > Looks very convincing. I say commit it. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: To sendmail or to postfix that is the question?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/03/2010 10:13:21, Paul Wootton wrote: > Sorry to hi-jack your thread, but this is also something I am currently > looking in to > > I really wanted to use Sendmail as a friend knows Sendmail fairly well > and I have a Sendmail book, but what I am wanting is the ability to have > mail for virtual users, ie I might have 4 admin accounts, > ad...@domain1.com ad...@domain2.com ad...@domain3.com and > ad...@domain4.com and want all the accounts to be independent of each > other and not necessarily have a real UNIX user account. I know I can > create 4 different admin accounts say admin1, admin2, admin3, admin4 and > then use the "virtual users" table, but I can see that getting a little > messy and from the end user's point they are going to have unusual login > names. > I know I can do this in Postfix, but is it possible in Sendmail? Sure, this is possible in sendmail, and you have already identified the way to do it: virtusertable, but as you say, the local user accounts end up looking pretty unusual. Unless you've got a delivery system that also takes account of the domain part of an e-mail address (something that is pretty unusual with sendmail(8)) you have to map all of the accepted mail addresses into a set of local userids: so ad...@domainx.com --> admin-domainX. The only good way of doing that is with virtusertable, since that's the only aliasing mechanism in sendmail which looks at the domain part of an address. aliases treats all of the RHSes as equivalent, so long as they belong to the set of addresses sendmail knows is locally delivered. On the other hand, virtusertable is a 1:1 transformation, aliases is a 1:many transformation -- the two different address transformation mechanisms is a historical peculiarity of sendmail and makes virtual server setups like this pretty tricky. To deliver to mailboxes where the userid includes a domain part, you have to have a mail-user database distinct from the password file and you will need to rewrite large parts of the basic message processing in sendmail.cf. As well, you'll need a fairly heavy-weight IMAP server like cyrus IMAPd for this functionality (does dovecot support it? no idea.) Doing this sort of stuff in other MTAs is easier than doing it in sendmail. postfix would be my choice. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuYzzYACgkQ8Mjk52CukIxSMwCffdtKiVQ8XWvpjLPs+zMmsDth aw8Ani9AhuC04YMAkLsDLfMWhR4mo9QP =FMxw -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: namei() returns EISDIR for "/" (Re: svn commit: r203990 - head/lib/libc/sys)
Jaakko Heinonen schrieb am 2010-03-11: > On 2010-03-10, Alexander Best wrote: > > could this panic have been triggered by the patch? > It doesn't look like it's caused by the patch. > > panic() at panic+0x15f > > _mtx_lock_flags() at _mtx_lock_flags+0xc5 > > fdesc_allocvp() at fdesc_allocvp+0xbf > > fdesc_lookup() at fdesc_lookup+0x15c > > this was 100% reducible when doing `portsnap fetch` though i > > changed a lot of > > stuff in my kernel config and reverted a lot of src patches to > > resolve the > > issue so i'm not sure what exactly was causing it. > The panic happened in fdescfs code. Did you have local patches > related > to fdescfs? after reverting a few patches (including yours) i got rid of the problem. i then re-applied your patch and noticed that (as you said) it wasn't causing the panic. i don't have any fdescfs specific patches in my src. i suspect however [1] being responsible for the panic. after backing it out i got no more panics in connection with `portsnap fetch`. [1] http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg70400.html thanks for the help oh...and btw.: i'm not sure but i think i've asked this question once before in this thread: in sys/kern/vfs_syscalls.c:kern_rmdirat() there's still local code to check for "." and "/" after applying your patch. isn't this all being done by calling namei() now? cheers. alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
[patch] tiny comment fix in sys/kern/vfs_syscalls.c
nothing spectacular. ;)
alex
Index: sys/kern/vfs_syscalls.c
===
--- sys/kern/vfs_syscalls.c (revision 204988)
+++ sys/kern/vfs_syscalls.c (working copy)
@@ -1060,7 +1060,7 @@
AUDIT_ARG_MODE(mode);
/* XXX: audit dirfd */
/*
-* Only one of the O_EXEC, O_RDONLY, O_WRONLY and O_RDWR may
+* Only one of the O_EXEC, O_RDONLY, O_WRONLY and O_RDWR flags may
* be specified.
*/
if (flags & O_EXEC) {
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: To sendmail or to postfix that is the question?
According to Steven Hartland: > 1. Has sendmail's config moved away from the black art > it once was? Well, not really. .cf files are still .cf files but most people don't use them directly (except old farts ;-)). .mc files are the easiest way to configure sendmail (and of course tables) > 2. Is postfix that much easier? Yes. You get tables for everything as well but it is IMHO cleaner. > 3. What would people use for: > 3.1. POP / IMAP support? dovecot is the one I found the easiest to work with. > 3.2. Web Mail? Don't use it so I can't advise. > 3.2. AV / Spam filtering? clamav-milter along with milter-greylist rocks. Spam filtering is more done at the user level through bogofilter though. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: tiny lib/libkvm/kvm_proc.c correction
John Baldwin schrieb am 2010-03-08: > On Saturday 06 March 2010 3:39:17 am Ulrich Spörlein wrote: > > On Fri, 05.03.2010 at 12:38:40 -0800, Xin LI wrote: > > > On 2010/03/05 11:59, Alexander Best wrote: > > > > Xin LI schrieb am 2010-03-05: > > > > On 2010/03/05 11:26, Alexander Best wrote: > > > hi there. does this look right? > > > > Not to me, the value is not to be used this way and the > > > > comments > > > > above the code explained the same thing. > > > > I think we should use cputick2usec but it's not available to > > > > userland > > > > (one have to copy cpu_tick_frequency and friends). > > > >> damn you're right. i completely overlooked that comment. would > > > >> it be > worth > > > >> making cputick2usec available to userland? is kvm_proc.c the > > > >> only > candidate in > > > >> need of converting cpu ticks to usecs? > > > I'm not sure how to do that unfortunately, is there a way to > > > expose a > > > kernel variable to userland which also works on a crash dump? > > ticks *is* available to libkvm, not sure what happens on > > crashdumps, > > though. The following patchset has not been tested: i've just had a look at the overall use of bintime2timeval in the src. it's not used very often. i only found a handful of calls and in fact with the exception of kvm_proc.c bintime2timeval() always gets used with a proper struct bintime. so i guess it's okay to import cputick2usec() exclusively to kvm_proc.c. cheers. alex > https://www.spoerlein.net/gitweb/?p=freebsd.work/.git;a=commitdiff;h=d500a051eb75dd234166bb11485c0a953aefce1d > I'm fine with this patch so long as you are reading 'ticks' from the > crash > dump. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: To sendmail or to postfix that is the question?
> I really wanted to use Sendmail as a friend knows Sendmail fairly well > and I have a Sendmail book, but what I am wanting is the ability to have > mail for virtual users, ie I might have 4 admin accounts, > ad...@domain1.com ad...@domain2.com ad...@domain3.com and > ad...@domain4.com and want all the accounts to be independent of each > other and not necessarily have a real UNIX user account. I know I can > create 4 different admin accounts say admin1, admin2, admin3, admin4 and > then use the "virtual users" table, but I can see that getting a little > messy and from the end user's point they are going to have unusual login > names. > I know I can do this in Postfix, but is it possible in Sendmail? Yes its possible. I do that with sendmail for a friend's domain I host Here's an anonymised real operational sample from my server with comment added /etc/mail/virtusertable hostmas...@sparedomain.comhostmaster hostmas...@www.sparedomain.comhostmaster # I take the hostmaster cos hes not competent to. friend-local-acc-on-my-h...@sparedomain.com sparedomain-default # friend-local-acc-on-my-host@ is redundant as # done by default, but left for clarity. # could also go to secretary-of-fri...@anywhere-else.com # exam...@sparedomain.com s...@where_else @sparedomain.com sparedomain-default # this collects all of # friends-new-colleague-he-hasnt-told-me-ab...@sparedomain.com # random-guess-by-spam...@sparedomain.com @www.sparedomain.com sparedomain-default # divert any mail re friends web site to the friend. /etc/mail/aliases: # switchable choice depending if I POP serve the friend or forward. sparedomain-default:fri...@some-other-domain.com # sparedomain-default: friend-local-acc-on-my-host PS I skimmed but didnt really understand Matthew's posting, (not saying its right or wrong, just didnt grasp it), but I have sendmail working fine for my @berklix.org & for a friend's @surfacevision.com So Paul, you can use sendmail for this if you want. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text not quoted-printable, HTML or Base64 http://www.asciiribbon.org Old 20s expire 30 6 2010 http://www.bankofengland.co.uk/banknotes/twentyv/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: namei() returns EISDIR for "/" (Re: svn commit: r203990 - head/lib/libc/sys)
On 2010-03-11, Alexander Best wrote: > in sys/kern/vfs_syscalls.c:kern_rmdirat() there's still local code to check > for "." and "/" after applying your patch. isn't this all being done by > calling namei() now? Looking at it quickly I think that the "." case is handled by lookup() since r199137. However the VV_ROOT test is for all mount points not just for "/". -- Jaakko ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
How to slow down SATA to 1.5 GBit/s ?
Hi, i am looking for a way to curb SATA speed to 1.5 GBit/s to avoid write failures with an eSATA attached DVD burner. I tried this as superuser: # atacontrol mode acd1 current mode = SATA300 # atacontrol mode acd1 SATA150 current mode = SATA300 # atacontrol mode acd1 current mode = SATA300 with obviously no success. $ uname -a FreeBSD ... 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 atapicam is running. The problem of the burner appears as checksum errors during write operations (but not during reading, strangely). It hits both, FreeBSD 8.0 and Debian Linux 5.04. But Debian switches to 1.5 GBit/s after a few errors and then works fine, whereas FreeBSD stays error prone. E.g. writing to a DVD+RW by $ dd if=/dev/zero bs=1M count=100 of=/dev/cd1 100+0 records in 100+0 records out 104857600 bytes transferred in 195.130322 secs (537372 bytes/sec) yields only 10 % of normal speed and afterwards i get from dmesg: acd1: FAILURE - REQUEST_SENSE timed out acd1: FAILURE - REQUEST_SENSE timed out (cd1:ata2:0:0:0): WRITE(10). CDB: 2a 0 0 0 41 40 0 0 20 0 (cd1:ata2:0:0:0): CAM Status: SCSI Status Error (cd1:ata2:0:0:0): SCSI Status: Check Condition (cd1:ata2:0:0:0): HARDWARE FAILURE asc:8,3 (cd1:ata2:0:0:0): Logical unit communication CRC error (Ultra-DMA/32) (cd1:ata2:0:0:0): Retrying Command (per Sense Data) acd1: FAILURE - WRITE_BIG timed out ... (cd1:ata2:0:0:0): WRITE(10). CDB: 2a 0 0 0 8f c0 0 0 20 0 ... (cd1:ata2:0:0:0): WRITE(10). CDB: 2a 0 0 0 92 60 0 0 20 0 ... (cd1:ata2:0:0:0): WRITE(10). CDB: 2a 0 0 0 a1 a0 0 0 20 0 ... (cd1:ata2:0:0:0): WRITE(10). CDB: 2a 0 0 0 c7 60 0 0 20 0 ... acd1: FAILURE - REQUEST_SENSE timed out I then tried via /dev/acd1. The behavior got quite nasty: $ dd if=/dev/zero bs=1M count=100 of=/dev/acd1 was stuck for at least 15 minutes. Uninterruptible. I had to reboot. dmesg reported sparsely: acd1: FAILURE - WRITE_BIG HARDWARE ERROR asc=0x08 ascq=0x03 Further tries with /dev/acd1 yielded: $ dd if=/dev/zero bs=1M count=100 of=/dev/acd1 dd: /dev/acd1: Input/output error 2+0 records in 1+0 records out 1048576 bytes transferred in 0.882248 secs (1188527 bytes/sec) with dmesg: acd1: FAILURE - WRITE_BIG HARDWARE ERROR asc=0x08 ascq=0x03 acd1: TIMEOUT - WRITE_BIG retrying (1 retry left) Reading data works fine $ dd if=/dev/cd1 bs=1M count=1000 of=/dev/null 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 127.781828 secs (8205987 bytes/sec) at nearly twice the speed of flawless writing. The same drive works well at USB or inside the computer at SATA. Nevertheless i would like to get eSATA ready so that i can test SATA drives without opening the computer box. Have a nice day :) Thomas ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Re: [patch] extending {amd64|i386} cpu info
since ed@ noticed that there's no CPUID_TO_STEPPING() macro this new patch
adds one. i checked and include/specialreg.h is only available on amd64, i386
and pc98. all the latter does however is:
#include
cheers.
alex
Index: amd64/include/specialreg.h
===
--- amd64/include/specialreg.h (revision 204977)
+++ amd64/include/specialreg.h (working copy)
@@ -169,6 +169,8 @@
#defineCPUID_FAMILY0x0f00
#defineCPUID_EXT_MODEL 0x000f
#defineCPUID_EXT_FAMILY0x0ff0
+#define CPUID_TO_STEPPING(id) \
+((id) & CPUID_STEPPING)
#defineCPUID_TO_MODEL(id) \
id) & CPUID_MODEL) >> 4) | \
(((id) & CPUID_EXT_MODEL) >> 12))
Index: amd64/amd64/identcpu.c
===
--- amd64/amd64/identcpu.c (revision 204977)
+++ amd64/amd64/identcpu.c (working copy)
@@ -187,7 +187,12 @@
if (cpu_vendor_id == CPU_VENDOR_INTEL ||
cpu_vendor_id == CPU_VENDOR_AMD ||
cpu_vendor_id == CPU_VENDOR_CENTAUR) {
- printf(" Stepping = %u", cpu_id & 0xf);
+ printf(" Stepping = %u"
+ " Model = %u"
+ " Family = %u",
+ CPUID_TO_STEPPING(cpu_id),
+ CPUID_TO_MODEL(cpu_id),
+ CPUID_TO_FAMILY(cpu_id));
if (cpu_high > 0) {
/*
Index: i386/include/specialreg.h
===
--- i386/include/specialreg.h (revision 204977)
+++ i386/include/specialreg.h (working copy)
@@ -166,6 +166,8 @@
#defineCPUID_FAMILY0x0f00
#defineCPUID_EXT_MODEL 0x000f
#defineCPUID_EXT_FAMILY0x0ff0
+#define CPUID_TO_STEPPING(id) \
+((id) & CPUID_STEPPING)
#defineCPUID_TO_MODEL(id) \
id) & CPUID_MODEL) >> 4) | \
id) & CPUID_FAMILY) >= 0x600) ? \
Index: i386/i386/identcpu.c
===
--- i386/i386/identcpu.c(revision 204977)
+++ i386/i386/identcpu.c(working copy)
@@ -672,7 +672,12 @@
cpu_vendor_id == CPU_VENDOR_NSC ||
(cpu_vendor_id == CPU_VENDOR_CYRIX &&
((cpu_id & 0xf00) > 0x500))) {
- printf(" Stepping = %u", cpu_id & 0xf);
+ printf(" Stepping = %u"
+ " Model = %u"
+ " Family = %u",
+ CPUID_TO_STEPPING(cpu_id),
+ CPUID_TO_MODEL(cpu_id),
+ CPUID_TO_FAMILY(cpu_id));
if (cpu_vendor_id == CPU_VENDOR_CYRIX)
printf(" DIR=0x%04x", cyrix_did);
if (cpu_high > 0) {
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: To sendmail or to postfix that is the question?
Julian H. Stacey wrote: I really wanted to use Sendmail as a friend knows Sendmail fairly well and I have a Sendmail book, but what I am wanting is the ability to have mail for virtual users, ie I might have 4 admin accounts, ad...@domain1.com ad...@domain2.com ad...@domain3.com and ad...@domain4.com and want all the accounts to be independent of each other and not necessarily have a real UNIX user account. I know I can create 4 different admin accounts say admin1, admin2, admin3, admin4 and then use the "virtual users" table, but I can see that getting a little messy and from the end user's point they are going to have unusual login names. I know I can do this in Postfix, but is it possible in Sendmail? Yes its possible. I do that with sendmail for a friend's domain I host Here's an anonymised real operational sample from my server with comment added ... PS I skimmed but didnt really understand Matthew's posting, (not saying its right or wrong, just didnt grasp it), but I have sendmail working fine for my @berklix.org & for a friend's @surfacevision.com So Paul, you can use sendmail for this if you want. Cheers, Julian Thanks but unfortunately this really wont help me too much. My fault for not posting it before, but I currently have 9 domains (with a likely hood of another couple more being added), with an range from 5 to 15 different email accounts per domain, hence me thinking it might get a little messy with all the UNIX accounts and virtual user table. Cheers Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: To sendmail or to postfix that is the question?
Matthias Andree writes: > sendmail's configuration was never a black art unless you needed > features beyond what the m4 macro set supported. The m4 macro set is a fairly recent development. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: bus_space_tag, bus_space_handle
On Thursday 11 March 2010 4:04:52 am Cole wrote: > Hi. > > Im currently needing to write to a few registers for a PCI device. The > driver is provided, but it does not contain support for writing > specific registers itself. I also do not with to modify the driver. > > I would like to know what the best method would be for writing to > these registers, the best way to go about getting bus_space_tag, and > handle for the connected pci device. > > Im currently using FreeBSD 7.x. You will most likely need to modify the driver. The PCI bus code only hands out valid resources for a given BAR to the device_t for a given device. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [patch] extending {amd64|i386} cpu info
On Thursday 11 March 2010 8:43:29 am Alexander Best wrote: > since ed@ noticed that there's no CPUID_TO_STEPPING() macro this new patch > adds one. i checked and include/specialreg.h is only available on amd64, i386 > and pc98. all the latter does however is: > > #include I don't think we need the CPUID_TO_STEPPING() macro as stepping is still a simple mask operation. The other macros were added when the operations became more complicated. I do have a version of your patch I plan to commit soon. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: To sendmail or to postfix that is the question?
On Thu, Mar 11, 2010 at 03:11:06PM +0100, Dag-Erling Smørgrav wrote: > Matthias Andree writes: > > sendmail's configuration was never a black art unless you needed > > features beyond what the m4 macro set supported. > > The m4 macro set is a fairly recent development. I was using it in 1993. With respect, perspectives as to "never" or "recent" tend to be subjective. (Some folks on this list may well have not been born yet in 1993.) FWIW: * The FreeBSD.org mail infrastructure uses Postfix. In general, I find its configuration cleaner & more orthogonal than that of sendmail. * I still use sendmail at home -- partly because there are still things I can do with sendmail that I don't know how to do with Postfix (e.g., taking action based on the lack of a header), partly because I still find sendmail logs easier to parse and undertsand, and partly from inertia. And we have Greg Shapiro shepherding sendmail in the FreeBSD source tree, which is wonderful. * I worked at an installation that had a fair amount of infrastructure built around the use of qmail a few years back. I hope to never repeat that experience, and would not willingly use qmail ever again. * I have no experience with administering other MTAs. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpzolNRqqHii.pgp Description: PGP signature
Re: To sendmail or to postfix that is the question?
On Thu, 11.03.2010 at 13:54:53 +, Paul Wootton wrote: Julian H. Stacey wrote: >> I really wanted to use Sendmail as a friend knows Sendmail fairly well >> and I have a Sendmail book, but what I am wanting is the ability to have >> mail for virtual users, ie I might have 4 admin accounts, >> ad...@domain1.com ad...@domain2.com ad...@domain3.com and >> ad...@domain4.com and want all the accounts to be independent of each >> other and not necessarily have a real UNIX user account. I know I can >> create 4 different admin accounts say admin1, admin2, admin3, admin4 and >> then use the "virtual users" table, but I can see that getting a little >> messy and from the end user's point they are going to have unusual login >> names. >> I know I can do this in Postfix, but is it possible in Sendmail? >> > > Yes its possible. I do that with sendmail for a friend's domain I host > Here's an anonymised real operational sample from my server with comment added > > ... > > PS I skimmed but didnt really understand Matthew's posting, (not > saying its right or wrong, just didnt grasp it), but I have sendmail > working fine for my @berklix.org & for a friend's @surfacevision.com > So Paul, you can use sendmail for this if you want. > > Cheers, > Julian > Thanks but unfortunately this really wont help me too much. My fault for not posting it before, but I currently have 9 domains (with a likely hood of another couple more being added), with an range from 5 to 15 different email accounts per domain, hence me thinking it might get a little messy with all the UNIX accounts and virtual user table. Use LDAP. That's what I did. Works fine with sendmail and dovecot, once you have it working, you will find out, that it's actually documented pretty decently. One of those things you always have to find out on hindsight :) Cheers, Uli ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: To sendmail or to postfix that is the question?
David Wolfskill writes: > Dag-Erling Smørgrav writes: > > Matthias Andree writes: > > > sendmail's configuration was never a black art unless you needed > > > features beyond what the m4 macro set supported. > > The m4 macro set is a fairly recent development. > I was using it in 1993. ISTR it did not become official until much later? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: bus_space_tag, bus_space_handle
On Thu, 11 Mar 2010 11:04:52 +0200 Cole wrote: > Hi. > > Im currently needing to write to a few registers for a PCI device. The > driver is provided, but it does not contain support for writing > specific registers itself. I also do not with to modify the driver. > > I would like to know what the best method would be for writing to > these registers, the best way to go about getting bus_space_tag, and > handle for the connected pci device. > > Im currently using FreeBSD 7.x. > Take a look at pciconf(8). Might help. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [patch] extending {amd64|i386} cpu info
On Thursday 11 March 2010 09:07 am, John Baldwin wrote: > On Thursday 11 March 2010 8:43:29 am Alexander Best wrote: > > since ed@ noticed that there's no CPUID_TO_STEPPING() macro this > > new patch adds one. i checked and include/specialreg.h is only > > available on amd64, > > i386 > > > and pc98. all the latter does however is: > > > > #include > > I don't think we need the CPUID_TO_STEPPING() macro as stepping is > still a simple mask operation. The other macros were added when > the operations became more complicated. Just for the record, I added CPUID_TO_* macros and I absolutely agree that we don't need CPUID_TO_STEPPING(). > I do have a version of your patch I plan to commit soon. Thanks! Jung-uk Kim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: bus_space_tag, bus_space_handle
On Thu, 11 Mar 2010 08:14:30 -0500 John Baldwin wrote: > On Thursday 11 March 2010 4:04:52 am Cole wrote: > > Hi. > > > > Im currently needing to write to a few registers for a PCI device. > > The driver is provided, but it does not contain support for writing > > specific registers itself. I also do not with to modify the driver. > > > > I would like to know what the best method would be for writing to > > these registers, the best way to go about getting bus_space_tag, and > > handle for the connected pci device. > > > > Im currently using FreeBSD 7.x. > > You will most likely need to modify the driver. The PCI bus code > only hands out valid resources for a given BAR to the device_t for a > given device. > > -- > John Baldwin I used /dev/mem and dd in the past for this purpose. Not pretty and custom tool beats it any day, but it does work. -- Alexander Kabaev signature.asc Description: PGP signature
memguard(9) rewrite
This patch is against something close to stable/7. We've found internally that memguard(9) isn't very usable for debugging; it seems to run out of resources and do other unfriendly things. This patch is my first attempt to make it more usable. The basic changes are: - take a lot more KVA if available - use vm_map_findspace() directly, with a moving cursor, so that KVA is not reused for a while. When the cursor gets to the end of the map, start from the beginning which will re-use KVA. - free the physical pages and KVA on a memguard_free(). This requires no extra space for tracking, and no additional locks beyond the vm_map lock. Since on amd64 the KVA reserved is generally more than physical memory, there's also a limit on the physical memory used to keep memguard's page promotions from using up all the system resources. I hope this is useful. I'm working on code to add unused pages on each side of the allocation to detect memory overflow and underflow, and also some knobs to limit page promotions to larger allocations, and also randomly guarding any call to malloc(9). This code is going into our HEAD build today; in a few days I'll have good system test results to know if I butchered anything. I don't have a good test rig for CURRENT, but I can produce a patch against CURRENT that has no references to Isilon tags or isi_* filenames if desired. Is there anyone who wants to take such a patch and commit it? Should I send this to freebsd-arch as well? Thanks, matthew memguard.diff Description: memguard.diff ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
[RFC] Saving the latest errno from syscalls.
While I was debugging syscalls, I found a very useful field in struct
thread, td_errno. It seems it was added for dtrace but it is only
populated on amd64 and i386. Is the attached patch acceptable for
maintainers of other platforms?
Thanks,
Jung-uk Kim
Index: sys/arm/arm/trap.c
===
--- sys/arm/arm/trap.c (revision 205027)
+++ sys/arm/arm/trap.c (working copy)
@@ -928,6 +928,10 @@ syscall(struct thread *td, trapframe_t *frame, u_i
AUDIT_SYSCALL_ENTER(code, td);
error = (*callp->sy_call)(td, args);
AUDIT_SYSCALL_EXIT(error, td);
+
+ /* Save the latest error return value. */
+ td->td_errno = error;
+
KASSERT(td->td_ar == NULL,
("returning from syscall with td_ar set!"));
}
Index: sys/powerpc/booke/trap.c
===
--- sys/powerpc/booke/trap.c(revision 205027)
+++ sys/powerpc/booke/trap.c(working copy)
@@ -413,6 +413,9 @@ syscall(struct trapframe *frame)
error = (*callp->sy_call)(td, params);
AUDIT_SYSCALL_EXIT(error, td);
+ /* Save the latest error return value. */
+ td->td_errno = error;
+
CTR3(KTR_SYSC, "syscall: p=%s %s ret=%x", p->p_comm,
syscallnames[code], td->td_retval[0]);
}
Index: sys/powerpc/aim/trap.c
===
--- sys/powerpc/aim/trap.c (revision 205027)
+++ sys/powerpc/aim/trap.c (working copy)
@@ -409,6 +409,9 @@ syscall(struct trapframe *frame)
error = (*callp->sy_call)(td, params);
AUDIT_SYSCALL_EXIT(error, td);
+ /* Save the latest error return value. */
+ td->td_errno = error;
+
CTR3(KTR_SYSC, "syscall: p=%s %s ret=%x", td->td_name,
syscallnames[code], td->td_retval[0]);
}
Index: sys/sparc64/sparc64/trap.c
===
--- sys/sparc64/sparc64/trap.c (revision 205027)
+++ sys/sparc64/sparc64/trap.c (working copy)
@@ -652,6 +652,9 @@ syscall(struct trapframe *tf)
error = (*sa.callp->sy_call)(td, sa.argp);
AUDIT_SYSCALL_EXIT(error, td);
+ /* Save the latest error return value. */
+ td->td_errno = error;
+
CTR5(KTR_SYSC, "syscall: p=%p error=%d %s return %#lx %#lx",
p, error, syscallnames[sa.code], td->td_retval[0],
td->td_retval[1]);
Index: sys/ia64/ia64/trap.c
===
--- sys/ia64/ia64/trap.c(revision 205027)
+++ sys/ia64/ia64/trap.c(working copy)
@@ -974,6 +974,9 @@ syscall(struct trapframe *tf)
error = (*callp->sy_call)(td, args);
AUDIT_SYSCALL_EXIT(error, td);
+ /* Save the latest error return value. */
+ td->td_errno = error;
+
cpu_set_syscall_retval(td, error);
td->td_syscalls++;
Index: sys/ia64/ia32/ia32_trap.c
===
--- sys/ia64/ia32/ia32_trap.c (revision 205027)
+++ sys/ia64/ia32/ia32_trap.c (working copy)
@@ -127,6 +127,9 @@ ia32_syscall(struct trapframe *tf)
AUDIT_SYSCALL_ENTER(code, td);
error = (*callp->sy_call)(td, args64);
AUDIT_SYSCALL_EXIT(error, td);
+
+ /* Save the latest error return value. */
+ td->td_errno = error;
}
switch (error) {
Index: sys/sun4v/sun4v/trap.c
===
--- sys/sun4v/sun4v/trap.c (revision 205027)
+++ sys/sun4v/sun4v/trap.c (working copy)
@@ -666,6 +666,9 @@ syscall(struct trapframe *tf)
error = (*callp->sy_call)(td, argp);
AUDIT_SYSCALL_EXIT(error, td);
+ /* Save the latest error return value. */
+ td->td_errno = error;
+
CTR5(KTR_SYSC, "syscall: p=%p error=%d %s return %#lx %#lx ", p,
error, syscallnames[code], td->td_retval[0],
td->td_retval[1]);
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: To sendmail or to postfix that is the question?
Hi, Roundcube is a web pop or imap client. It's simple and light. And you just need Php and any sql base. Roundcube support ssl/tls on imap connection. You also can use a virtusertable to login. 2010/3/10 Lowell Gilbert > "Steven Hartland" writes: > > > A few key question come to mind:- > > 1. Has sendmail's config moved away from the black art > > it once was? > > Somewhat. The configurations are done with m4 these days, but there's > a lot of black magic possible with the many potential combinations of > features and options. > > > 2. Is postfix that much easier? > > Yes. However, the black magic in sendmail is very powerful. > > > 3. What would people use for: > > 3.1. POP / IMAP support? > > Separate problem. I use dovecot and I like it, but it's just a > household server. > > > 3.2. Web Mail? > > I don't do that, because I don't want to go to the effort of making sure > it is and stays secure, but from what I hear I'd probably try > squirrelmail first if I were doing it. > > > 3.2. AV / Spam filtering? > > I use spamassassin. You can plug most other analyzers into it. > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > -- // Buschini Edouard :: Moon // Epitech university // moon.bo...@gmail.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC] Saving the latest errno from syscalls.
On Mar 11, 2010, at 1:24 PM, Jung-uk Kim wrote: > While I was debugging syscalls, I found a very useful field in struct > thread, td_errno. It seems it was added for dtrace but it is only > populated on amd64 and i386. Is the attached patch acceptable for > maintainers of other platforms? Isn't it better to do it in cpu_set_syscall_retval()? That way you catch all cases, plus you can save the translated error as well... -- Marcel Moolenaar xcl...@mac.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Sudden mbuf demand increase and shortage under the load (igb issue?)
Hello Jack, We're seeing iffy behavior with igb on FreeBSD 8.0-RELEASE on a new Intel server box (based on their S5520UR motherboard). So far we've seen only oddness with link-state (it wants to always say "active", with no cable plugged in, unless we do an ifconfig up/down/up), but I'm concerned that we might fall victim to other symptoms mentioned if we put the system under load. Would you recommend we apply the igb patch you've mentioned? Is it in RELENG_8 yet, or is it still under development? Thanks very much, Charles Charles Owens Great Bay Software, Inc. Jack Vogel wrote: > This thread is confusing, first he says its an igb problem, then you offer > an em patch :) > > I have an important rev of igb that I am about ready to release, anyone that > wishes to > test against a problem they have would be welcome to have early access, just > let me > know. > > I am not sure about this ich10 change, there are client NICs that > specifically do NOT > support jumbo frames, I'll need to look into it tomorrow at work. > > Jack > > > On Thu, Feb 18, 2010 at 7:42 PM, Pyun YongHyeon wrote: > > >> On Thu, Feb 18, 2010 at 05:05:16PM -0800, Maxim Sobolev wrote: >> >>> Folks, >>> >>> Indeed, it looks like igb(4) issue. Replacing the card with the >>> desktop-grade em(4)-supported card has fixed the problem for us. The >>> system has been happily pushing 110mbps worth of RTP traffic and 2000 >>> concurrent calls without any problems for two days now. >>> >>> e...@pci0:7:0:0: class=0x02 card=0xa01f8086 chip=0x10d38086 rev=0x00 >>> hdr=0x00 >>> vendor = 'Intel Corporation' >>> class = network >>> subclass = ethernet >>> >>> em0: port 0xec00-0xec1f mem >>> 0xfbee-0xfbef,0xfbe0-0xfbe7,0xfbedc000-0xfbed irq 24 >>> at device 0.0 on pci7 >>> em0: Using MSIX interrupts >>> em0: [ITHREAD] >>> em0: [ITHREAD] >>> em0: [ITHREAD] >>> em0: Ethernet address: 00:1b:21:50:02:49 >>> >>> I really think that this has to be addressed before 7.3 release is out. >>> FreeBSD used to be famous for its excellent network performance and it's >>> shame to see that deteriorating due to sub-standard quality drivers. >>> Especially when there is a multi-billion vendor supporting the driver in >>> question. No finger pointing, but it really looks like either somebody >>> is not doing his job or the said vendor doesn't care so much about >>> supporting FreeBSD. I am pretty sure the vendor in question has access >>> to numerous load-testing tools, that should have catched this issue. >>> >>> This is the second time during the past 6 months I have issue with the >>> quality of the Intel-based drivers - the first one is filed as >>> kern/140326, which has stalled apparently despite me providing all >>> necessary debug information. >>> >>> >> I can reproduce this bug on my box and I guess the root cause comes >> from PBA(Packet Buffer Allocation) configuration. Some controllers >> seems to require more TX buffer size to use 9000 MTU. The datasheet >> is not clear which controller has how much amount of Packet Buffer >> storage. This parameter seems to affect performance a lot because >> increasing TX buffer size results in decreasing RX buffer size. The >> attached patch seems to fix the issue for me but Jack may know >> better the hardware details as publicly available datasheet seems >> to be useless here. >> >> > ___ > freebsd-...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > > > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Sudden mbuf demand increase and shortage under the load (igb issue?)
I've dug around in the source repo... it appears the new code is just shy of being MFC'd. Any known caveats with the new code or is it by all accounts good to go? I'm going to try testing it in 8.0. Thanks Charles Owens Great Bay Software, Inc. Charles Owens wrote: > Hello Jack, > > We're seeing iffy behavior with igb on FreeBSD 8.0-RELEASE on a new > Intel server box (based on their S5520UR motherboard). So far we've > seen only oddness with link-state (it wants to always say "active", with > no cable plugged in, unless we do an ifconfig up/down/up), but I'm > concerned that we might fall victim to other symptoms mentioned if we > put the system under load. > > Would you recommend we apply the igb patch you've mentioned? Is it in > RELENG_8 yet, or is it still under development? > > Thanks very much, > Charles > > Charles Owens > Great Bay Software, Inc. > > > > Jack Vogel wrote: > >> This thread is confusing, first he says its an igb problem, then you offer >> an em patch :) >> >> I have an important rev of igb that I am about ready to release, anyone that >> wishes to >> test against a problem they have would be welcome to have early access, just >> let me >> know. >> >> I am not sure about this ich10 change, there are client NICs that >> specifically do NOT >> support jumbo frames, I'll need to look into it tomorrow at work. >> >> Jack >> >> >> On Thu, Feb 18, 2010 at 7:42 PM, Pyun YongHyeon wrote: >> >> >> >>> On Thu, Feb 18, 2010 at 05:05:16PM -0800, Maxim Sobolev wrote: >>> >>> Folks, Indeed, it looks like igb(4) issue. Replacing the card with the desktop-grade em(4)-supported card has fixed the problem for us. The system has been happily pushing 110mbps worth of RTP traffic and 2000 concurrent calls without any problems for two days now. e...@pci0:7:0:0: class=0x02 card=0xa01f8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet em0: port 0xec00-0xec1f mem 0xfbee-0xfbef,0xfbe0-0xfbe7,0xfbedc000-0xfbed irq 24 at device 0.0 on pci7 em0: Using MSIX interrupts em0: [ITHREAD] em0: [ITHREAD] em0: [ITHREAD] em0: Ethernet address: 00:1b:21:50:02:49 I really think that this has to be addressed before 7.3 release is out. FreeBSD used to be famous for its excellent network performance and it's shame to see that deteriorating due to sub-standard quality drivers. Especially when there is a multi-billion vendor supporting the driver in question. No finger pointing, but it really looks like either somebody is not doing his job or the said vendor doesn't care so much about supporting FreeBSD. I am pretty sure the vendor in question has access to numerous load-testing tools, that should have catched this issue. This is the second time during the past 6 months I have issue with the quality of the Intel-based drivers - the first one is filed as kern/140326, which has stalled apparently despite me providing all necessary debug information. >>> I can reproduce this bug on my box and I guess the root cause comes >>> from PBA(Packet Buffer Allocation) configuration. Some controllers >>> seems to require more TX buffer size to use 9000 MTU. The datasheet >>> is not clear which controller has how much amount of Packet Buffer >>> storage. This parameter seems to affect performance a lot because >>> increasing TX buffer size results in decreasing RX buffer size. The >>> attached patch seems to fix the issue for me but Jack may know >>> better the hardware details as publicly available datasheet seems >>> to be useless here. >>> >>> >>> >> ___ >> freebsd-...@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >> >> >> >> > ___ > freebsd-...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > > > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC] Saving the latest errno from syscalls.
On Thursday 11 March 2010 04:55 pm, Marcel Moolenaar wrote: > On Mar 11, 2010, at 1:24 PM, Jung-uk Kim wrote: > > While I was debugging syscalls, I found a very useful field in > > struct thread, td_errno. It seems it was added for dtrace but it > > is only populated on amd64 and i386. Is the attached patch > > acceptable for maintainers of other platforms? > > Isn't it better to do it in cpu_set_syscall_retval()? > That way you catch all cases, plus you can save the > translated error as well... I just took amd64/i386 as an example and I was not sure whether it was meant to store translated error or not. Does anyone with DTrace internal knowledge answer the question? Jung-uk Kim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to slow down SATA to 1.5 GBit/s ?
On 11.03.2010 16:27, Thomas Schmitt wrote: i am looking for a way to curb SATA speed to 1.5 GBit/s to avoid write failures with an eSATA attached DVD burner. Can you show `pciconf -l` output? -- WBR, Andrey V. Elsukov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to slow down SATA to 1.5 GBit/s ?
Hi, Andrey V. Elsukov wrote: > Can you show `pciconf -l` output? # pciconf -l hos...@pci0:0:0:0: class=0x06 card=0x50001458 chip=0x79111002 rev=0x00 hdr=0x00 pc...@pci0:0:1:0: class=0x060400 card=0x79121002 chip=0x79121002 rev=0x00 hdr=0x01 pc...@pci0:0:6:0: class=0x060400 card=0x50001458 chip=0x79161002 rev=0x00 hdr=0x01 atap...@pci0:0:17:0:class=0x010601 card=0xb0021458 chip=0x43911002 rev=0x00 hdr=0x00 oh...@pci0:0:18:0: class=0x0c0310 card=0x50041458 chip=0x43971002 rev=0x00 hdr=0x00 oh...@pci0:0:18:1: class=0x0c0310 card=0x50041458 chip=0x43981002 rev=0x00 hdr=0x00 eh...@pci0:0:18:2: class=0x0c0320 card=0x50041458 chip=0x43961002 rev=0x00 hdr=0x00 oh...@pci0:0:19:0: class=0x0c0310 card=0x50041458 chip=0x43971002 rev=0x00 hdr=0x00 oh...@pci0:0:19:1: class=0x0c0310 card=0x50041458 chip=0x43981002 rev=0x00 hdr=0x00 eh...@pci0:0:19:2: class=0x0c0320 card=0x50041458 chip=0x43961002 rev=0x00 hdr=0x00 no...@pci0:0:20:0: class=0x0c0500 card=0x43851458 chip=0x43851002 rev=0x3c hdr=0x00 atap...@pci0:0:20:1:class=0x01018a card=0x50021458 chip=0x439c1002 rev=0x00 hdr=0x00 no...@pci0:0:20:2: class=0x040300 card=0xa0021458 chip=0x43831002 rev=0x00 hdr=0x00 is...@pci0:0:20:3: class=0x060100 card=0x50011458 chip=0x439d1002 rev=0x00 hdr=0x00 pc...@pci0:0:20:4: class=0x060401 card=0x chip=0x43841002 rev=0x00 hdr=0x01 oh...@pci0:0:20:5: class=0x0c0310 card=0x50041458 chip=0x43991002 rev=0x00 hdr=0x00 hos...@pci0:0:24:0: class=0x06 card=0x chip=0x12001022 rev=0x00 hdr=0x00 hos...@pci0:0:24:1: class=0x06 card=0x chip=0x12011022 rev=0x00 hdr=0x00 hos...@pci0:0:24:2: class=0x06 card=0x chip=0x12021022 rev=0x00 hdr=0x00 hos...@pci0:0:24:3: class=0x06 card=0x chip=0x12031022 rev=0x00 hdr=0x00 hos...@pci0:0:24:4: class=0x06 card=0x chip=0x12041022 rev=0x00 hdr=0x00 vgap...@pci0:1:5:0: class=0x03 card=0xd0001458 chip=0x796e1002 rev=0x00 hdr=0x00 no...@pci0:1:5:2: class=0x040300 card=0x79191458 chip=0x79191002 rev=0x00 hdr=0x00 r...@pci0:2:0:0: class=0x02 card=0xe0001458 chip=0x816810ec rev=0x02 hdr=0x00 Have a nice day :) Thomas ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
