Re: reason for "magic" crashes.
thanks first for all suggestions. Now the (not really)funny part begins. After turning on all this checks in kernel the system crashes repeatable even before ending fully bootstrap sequence. Before this i've got tons of warning about lock order reversal. On seems strange as it is lock order reversal: 1st 0xff80f5c4ba80 bufwait (bufwait) @ kern/vfs_bio.c:2636 2nd 0xff0005cb0600 dirhash (dirhash) @ ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x80a _sx_xlock() at _sx_xlock+0x5d ufsdirhash_acquire() at ufsdirhash_acquire+0x33 ufsdirhash_remove() at ufsdirhash_remove+0x16 ufs_dirremove() at ufs_dirremove+0x181 ufs_remove() at ufs_remove+0x85 VOP_REMOVE_APV() at VOP_REMOVE_APV+0x93 kern_unlinkat() at kern_unlinkat+0x211 amd64_syscall() at amd64_syscall+0x2e0 Xfast_syscall() at Xfast_syscall+0xfc --- syscall (10, FreeBSD ELF64, unlink), rip = 0xeede070c, rsp = 0x7fffdb08, rbp = 0x7fffef58 --- every now and then when files are deleted. The rest seems to be a problem with not really good and it sync 3-rd party kernel addons. After fixing that part i would post again. Still - what may be a cause of this messages? ___ 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: tcsh's exit codes
- Original Message - From: Johan van Selst To: rank1see...@gmail.com Cc: hack...@freebsd.org Date: Sat, 23 Jun 2012 19:14:07 +0200 Subject: Re: tcsh's exit codes > rank1see...@gmail.com wrote: > > There is something wrong with tcsh shell: > > > > # mergemaster -V | grep '\--run-updates' > > Returned exit code 1 > > # mergemaster -V | grep -q '\--run-updates' > > Returned exit code 141 > > I believe this has been a feature of csh and tcsh since the dark ages. > Negative status codes propagate through pipelines (and through backtick > sub-commands as well). In fact the returned $status value is the value > of the last command that returned an error (non-zero) status code. > This makes it easy to determine if a pipeline command sequence has > failed. > > The 141 status code indicates a sigpipe: the pipeline was not completely > read (as described in the grep manual for this case). This also is the > common exit code when using head(1) for example. > > This error-propagation behaviour can be suppessed with 'unset anyerror' > in tcsh. In that case it should work as you expect. But note that your > commands are no longer compatible with 'good old' csh behaviour then. > > > Regards, > Johan Thanks for clarification J. D. ___ 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: MAGIC with HP KVM - someone will help?
On Wed, Jun 20, 2012 at 08:14:09AM +0200, Wojciech Puchar wrote: > I bought used IP 16 port KVM connected to few servers, in between them > FreeBSD 8 server running on Dell PowerEdge T110. > > As this KVM have PS/2 connectors to keyboard and mouse i added USB to > dual-PS/2 converter. This is ancient history now, but I used HP KVM switches 6-12 years ago and they weren't without problems. Regardless of OS and hardware behind the switches, they often acted up. Some combinations were more prone to problems, but since switching back and forth between targets would solve the problem over 99% of the time, I never put any further effort into it. If it's any consolation, I've used other brand KVM switches as well and the only one I've found quite reliable were Raritan and those cost an arm and a leg. -- Atte Peltomäki atte.peltom...@iki.fi <> http://kameli.org "Your effort to remain what you are is what limits you" ___ 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: MAGIC with HP KVM - someone will help?
On Mon, 25 Jun 2012 09:38:01 -0500, Atte Peltomäki wrote: If it's any consolation, I've used other brand KVM switches as well and the only one I've found quite reliable were Raritan and those cost an arm and a leg. raritan userstation $65.00 http://www.ebay.com/itm/Raritan-Paragon-II-P2-UST-IP-CAT5-KVM-Keyboard-Video-Mouse-User-Station-/150743344570?pt=US_KVM_Switches_KVM_Cables&hash=item231900e5ba 10 dongles $50.00 http://www.ebay.com/itm/LOT-of-10-NEW-Raritan-Paragon-II-KVM-CIM-P2CIM-PS2-Computer-Interface-Module-/221042459695?pt=COMP_EN_Hubs&hash=item337728442f We use these at work, as well as the daisy-chain versions of this line and they work quite well. ___ 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: MAGIC with HP KVM - someone will help?
This is ancient history now, but I used HP KVM switches 6-12 years ago and they weren't without problems. Regardless of OS and hardware behind the switches, they often acted up. Some combinations were more prone to today i did a bit of work being locally connected with monitor to KVM and it stopped work too with system running multiuser. removing USB-PS/2 converted and putting it back "solved" it. problems, but since switching back and forth between targets would solve the problem over 99% of the time, I never put any further effort into it. you mean different brands or pieces? ___ 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"
DTrace 32 bit on 64 bit machine?
Can the DTrace user space application compiled as 32 bit app be run on
machine with x86_64 kernel
I have this DTrace port done for code base based on FreeBSD 6.1, and
the app is crashing on the amd64 machine with assert
Assertion failed: (fsz > 0), function _libelf_getphdr, file
../../../../src/bsd/lib/libelf/libelf_phdr.c, lie 83.
I do not have the user space DTrace enabled. Pretty much stuff picked
up from FreeBSD 8.1
Looking at libdtrace code, there is this section in function "dt_module_update",
#if defined(__i386__)
/*
* Find the first load section and figure out the relocation
* offset for the symbols. The kernel module will not need
* relocation, but the kernel linker modules will.
*/
for (i = 0; gelf_getphdr(dmp->dm_elf, i, &ph) != NULL; i++) {
But the actual failure is because of faulty elf header...
#2 0xc822bb02 in abort () from /usr/lib/libc.so.6
#3 0xc8205aea in __assert from /usr/lib/libc.so.6
#4 0xc812fbb4 in _libelf_getphdr (e=0xffefc4c4, ec=2) at
libelf_phdr.c:83 <<== The same is not getting passed
down, 'e' is now different and gibberish.
#5 0xc812c3ac in gelf_getphdr (e=0x805df80, index=0, ...) at
libelf/gelf_phdr.c:87 <<== The struct _Elf 'e' is sane
#6 0xc80ea26c in dt_module_update at dt_module.c:934
But the elf header read from the kernel module is sane.
___
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"
sysctl filesystem ?
Hi folks, I find myself in a situation where I need to directly explore the sysctl(8) tree from my program. The tricky part is this: from `src/sbin/sysctl.c': /* * These functions uses a presently undocumented interface to the kernel * to walk the tree and get the type so it can print the value. * This interface is under work and consideration, and should probably * be killed with a big axe by the first person who can find the time. * (be aware though, that the proper interface isn't as obvious as it * may seem, there are various conflicting requirements. */ AFAIT, the whole interface used by sysctl(8) to explore the sysctl tree (ie. list, name, get description) is undocumented. This comment has been there for about, well... 17 years. No matter to say that it is highly unlikely anyone is ever gonna design that perfect interface. Right now, I am left with no choice but to figure out how that stuff work, which I foresee will be a real PITA. No choice ? Well, not so much. About 12 years ago a filesystem interface was written for sysctl, namely scfs(4). It was authored by Kelly Yancey and (?) Boris Popov. Unfortunately, time passed and no code is any longer publicly available. URLs are either no longer valid or password-protected. This interface would just be perfect for my use-case. No need to spend time decoding a prehistoric interface, no need to craft custom accessors. I would just have to use standard POSIX file interface... if the code was available. I was hoping some of the people on this list would either, have the scfs(4) code on their drives/tapes, or have a way to contact the original author(s) and thus have a chance to get that code ? Thanks in advance, - Arnaud ps: I know the code will certainly have to be fixed, but that is still the best option I've got so far. ___ 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"
libgeom documentation?
Libgeom has these functions geom_gettree() and geom_getxml but there is no documentation in the man page. Was this intentional? Is there a place these functions are documented other than their source code? :) Thanks in advance. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org *The opinions expressed above are entirely my own* Nasrudin loaded his donkey with wood for the fire and instead of sitting in its saddle, sat astride one of the logs. "Why don't you sit in the saddle?" someone asked. "What? And add my weight to what the poor animal has to carry? My weight is on the _wood_ and it is going to stay there." ___ 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: sysctl filesystem ?
On Mon, Jun 25, 2012 at 5:03 PM, Arnaud Lacombe wrote:
> Hi folks,
>
> I find myself in a situation where I need to directly explore the
> sysctl(8) tree from my program. The tricky part is this:
>
> from `src/sbin/sysctl.c':
> /*
> * These functions uses a presently undocumented interface to the kernel
> * to walk the tree and get the type so it can print the value.
> * This interface is under work and consideration, and should probably
> * be killed with a big axe by the first person who can find the time.
> * (be aware though, that the proper interface isn't as obvious as it
> * may seem, there are various conflicting requirements.
> */
>
> AFAIT, the whole interface used by sysctl(8) to explore the sysctl
> tree (ie. list, name, get description) is undocumented. This comment
> has been there for about, well... 17 years. No matter to say that it
> is highly unlikely anyone is ever gonna design that perfect interface.
> Right now, I am left with no choice but to figure out how that stuff
> work, which I foresee will be a real PITA. No choice ? Well, not so
> much. About 12 years ago a filesystem interface was written for
> sysctl, namely scfs(4). It was authored by Kelly Yancey and (?) Boris
> Popov. Unfortunately, time passed and no code is any longer publicly
> available. URLs are either no longer valid or password-protected.
>
> This interface would just be perfect for my use-case. No need to spend
> time decoding a prehistoric interface, no need to craft custom
> accessors. I would just have to use standard POSIX file interface...
> if the code was available.
>
> I was hoping some of the people on this list would either, have the
> scfs(4) code on their drives/tapes, or have a way to contact the
> original author(s) and thus have a chance to get that code ?
>
> Thanks in advance,
> - Arnaud
>
> ps: I know the code will certainly have to be fixed, but that is still
> the best option I've got so far.
Alternatively, the interface could just be documented (from
sys/kern/kern_sysctl.c):
/*
* "Staff-functions"
*
* These functions implement a presently undocumented interface
* used by the sysctl program to walk the tree, and get the type
* so it can print the value.
* This interface is under work and consideration, and should probably
* be killed with a big axe by the first person who can find the time.
* (be aware though, that the proper interface isn't as obvious as it
* may seem, there are various conflicting requirements.
*
* {0,0}printf the entire MIB-tree.
* {0,1,...}return the name of the "..." OID.
* {0,2,...}return the next OID.
* {0,3}return the OID of the name in "new"
* {0,4,...}return the kind & format info for the "..." OID.
* {0,5,...}return the description the "..." OID.
*/
I know 2 closed-source versions that have wholesale stolen/"borrowed"
the code from sysctl(3), and I adapted the sysctl(8) code for my own
uses for the cython derivative I made here [1].
Thanks,
-Garrett
1. http://sourceforge.net/projects/sysctl/
___
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: libgeom documentation?
On Mon, Jun 25, 2012 at 4:56 PM, Dave Hayes wrote: > Libgeom has these functions geom_gettree() and geom_getxml but there is no > documentation in the man page. Was this intentional? Is there a place these > functions are documented other than their source code? :) I can't really say 100%, but I found some documentation about it here: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/geom-class/article.html . It was probably discussed in a previous BSDCan as well. You can access this via sysctl -b kern.geom.confxml, but the problem that I see based on the above article is that the printout content and format is GEOM-class topology dependent. Cheers, -Garrett PS freebsd-geom might be a better list.. ___ 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: sysctl filesystem ?
On Mon, Jun 25, 2012 at 7:03 PM, Arnaud Lacombe wrote: > Hi folks, > > I find myself in a situation where I need to directly explore the > sysctl(8) tree from my program. The tricky part is this: > There is this: http://svnweb.freebsd.org/base/releng/4.7/sys/miscfs/kernfs/ -- Adam Vande More ___ 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: sysctl filesystem ?
Hi, On Mon, Jun 25, 2012 at 8:30 PM, Adam Vande More wrote: > On Mon, Jun 25, 2012 at 7:03 PM, Arnaud Lacombe wrote: >> >> Hi folks, >> >> I find myself in a situation where I need to directly explore the >> sysctl(8) tree from my program. The tricky part is this: > > There is this: > > http://svnweb.freebsd.org/base/releng/4.7/sys/miscfs/kernfs/ > yes, `kernfs' is mentioned in some of the thread about a sysctl filesystem as a potential code base, and has been used in such purpose. However, if I can avoid to re-design that wheel too, by getting access to scfs(4) code, I will. - Arnaud > -- > Adam Vande More ___ 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: sysctl filesystem ?
On Mon, Jun 25, 2012 at 8:13 PM, Garrett Cooper wrote:
> On Mon, Jun 25, 2012 at 5:03 PM, Arnaud Lacombe wrote:
>> Hi folks,
>>
>> I find myself in a situation where I need to directly explore the
>> sysctl(8) tree from my program. The tricky part is this:
>>
>> from `src/sbin/sysctl.c':
>> /*
>> * These functions uses a presently undocumented interface to the kernel
>> * to walk the tree and get the type so it can print the value.
>> * This interface is under work and consideration, and should probably
>> * be killed with a big axe by the first person who can find the time.
>> * (be aware though, that the proper interface isn't as obvious as it
>> * may seem, there are various conflicting requirements.
>> */
>>
>> AFAIT, the whole interface used by sysctl(8) to explore the sysctl
>> tree (ie. list, name, get description) is undocumented. This comment
>> has been there for about, well... 17 years. No matter to say that it
>> is highly unlikely anyone is ever gonna design that perfect interface.
>> Right now, I am left with no choice but to figure out how that stuff
>> work, which I foresee will be a real PITA. No choice ? Well, not so
>> much. About 12 years ago a filesystem interface was written for
>> sysctl, namely scfs(4). It was authored by Kelly Yancey and (?) Boris
>> Popov. Unfortunately, time passed and no code is any longer publicly
>> available. URLs are either no longer valid or password-protected.
>>
>> This interface would just be perfect for my use-case. No need to spend
>> time decoding a prehistoric interface, no need to craft custom
>> accessors. I would just have to use standard POSIX file interface...
>> if the code was available.
>>
>> I was hoping some of the people on this list would either, have the
>> scfs(4) code on their drives/tapes, or have a way to contact the
>> original author(s) and thus have a chance to get that code ?
>>
>> Thanks in advance,
>> - Arnaud
>>
>> ps: I know the code will certainly have to be fixed, but that is still
>> the best option I've got so far.
>
> Alternatively, the interface could just be documented (from
> sys/kern/kern_sysctl.c):
>
> /*
> * "Staff-functions"
> *
> * These functions implement a presently undocumented interface
> * used by the sysctl program to walk the tree, and get the type
> * so it can print the value.
> * This interface is under work and consideration, and should probably
> * be killed with a big axe by the first person who can find the time.
> * (be aware though, that the proper interface isn't as obvious as it
> * may seem, there are various conflicting requirements.
> *
> * {0,0} printf the entire MIB-tree.
> * {0,1,...} return the name of the "..." OID.
> * {0,2,...} return the next OID.
> * {0,3} return the OID of the name in "new"
> * {0,4,...} return the kind & format info for the "..." OID.
> * {0,5,...} return the description the "..." OID.
> */
>
> I know 2 closed-source versions that have wholesale stolen/"borrowed"
> the code from sysctl(3), and I adapted the sysctl(8) code for my own
> uses for the cython derivative I made here [1].
>
I guess I will have no choice but to write a third...
- Arnaud
> Thanks,
> -Garrett
>
> 1. http://sourceforge.net/projects/sysctl/
___
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: sysctl filesystem ?
On 26.06.2012 6:56, Arnaud Lacombe wrote: > purpose. However, if I can avoid to re-design that wheel too, by > getting access to scfs(4) code, I will. It is interesting, that the old drive with this code are still alive. Most likely, FS related part will need serious attention because of numerous changes in the VFS subsystem. Here is the link: http://www.vertex.kz/scfs.tgz -- Boris Popov ___ 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: sysctl filesystem ?
Hi, On Mon, Jun 25, 2012 at 10:51 PM, Boris Popov wrote: > On 26.06.2012 6:56, Arnaud Lacombe wrote: >> purpose. However, if I can avoid to re-design that wheel too, by >> getting access to scfs(4) code, I will. > > It is interesting, that the old drive with this code are still alive. > Most likely, FS related part will need serious attention because of > numerous changes in the VFS subsystem. Here is the link: > > http://www.vertex.kz/scfs.tgz > Outstanding ! I was pointed another implementation by Jakub Dawidek made in 2002, which seems more advanced. In any case, lots of KPI changed... I guess I found a new toy for this week :-) Thanks a lot, - Arnaud ___ 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: sysctl filesystem ?
as well as we don't depend of /proc for normal operation we shouldn't for say /proc/sysctl improvements are welcome, better documentation is welcome, changes to what is OK - isn'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: sysctl filesystem ?
On Jun 26, 2012 7:07 AM, "Wojciech Puchar" wrote: > > as well as we don't depend of /proc for normal operation we shouldn't for say /proc/sysctl > > improvements are welcome, better documentation is welcome, changes to what is OK - isn't. /proc/sysctl might be useful. Just because Linux uses it doesn't make it a bad idea. Chris ___ 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"
