Controlling a process
Hi guys, What is the best way to control a process (running in chroot env): 1- Execution time 2- Memory limit And to be able to kill the process when it breaks this limits. Finally, i would like to know the exit status of the process or the signal that killed it (sigfault, .) The idea is that I'm developing a problem judge that runs FreeBSD (something like www.spoj.pl or topcoder.com/tc) Where every problem has a run-time and a memory limit. Thanks a lot -- System Programmer -- I'm Searching For Perfection, So Even If U Need Portability U've To Use Assembly ;-) -- http://libosdk.berlios.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
btx/pxeboot problem
latest pxeboot (7.1): mother-boardNIC/LOM CPU - --- --- Intel SWV25 em xeonworks fine SUN X2200bgeamd works fine DELL PE 2950 bcexeonfailes 95% of the times hangs or goes into btx dump regs. mode :-) Intel SE7320VP21 mskxeonfailes 50% of the times - hangs pxeboot with btx.S 1.45 2008/02/27 23:35:39, works fine. so it seems that changes since 1.45 have fixed it for some, but it brakes for others :-). I can help testing, but btx is way out of my league. danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to build kernel module spread on subdirectories?
[EMAIL PROTECTED] writes: heresy Provided the module in question is contemplated for delivery as a port, rather than as part of the base -- so that having a build dependency on a port is tolerable -- perhaps it would be more easily built using devel/gmake? /heresy You'd have to reproduce most of /usr/share/mk/*.mk in gmake syntax. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Controlling a process
Maslan, good day.
Tue, Dec 02, 2008 at 09:53:09AM +, Maslan wrote:
What is the best way to control a process (running in chroot env):
1- Execution time
2- Memory limit
And to be able to kill the process when it breaks this limits.
man 2 setrlimit
Finally, i would like to know the exit status of the process or the
signal that killed it (sigfault, .)
If you're spawning the process in question, then 'man 2 wait'.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpSeBCIu43Om.pgp
Description: PGP signature
Re: How to build kernel module spread on subdirectories?
On 2 Dec 2008, at 13:33 , Dag-Erling Smørgrav wrote:
[EMAIL PROTECTED] writes:
heresy Provided the module in question is contemplated for delivery
as a port, rather than as part of the base -- so that having a build
dependency on a port is tolerable -- perhaps it would be more easily
built using devel/gmake? /heresy
You'd have to reproduce most of /usr/share/mk/*.mk in gmake syntax.
That was the main reason why I decided to switch to make :) I had
problems with CFLAGS set in that GNUmakefile, so I wanted to extract
CFLAGS used to build the rest of the kernel. And it works now, without
any problems :)
To answer the other question in other email: yes, that file needs to
be generated, or I would need to regenerate it whenever I add a new
element... Which I may forget... So, this is what I ended up using:
snip til the end
.MAKEFILEDEPS: elements.mk
beforedepend: elements.mk
.if make(depend) !exists(${.CURDIR}/elements.mk)
.warning You should first generate elements.mk
afterdepend:
rm -f .depend
$(MAKE) depend
.endif
.sinclude elements.mk
.include bsd.kmod.mk
Cheers,
Nikola___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: keeping track of local modifications
On Mon, 01 Dec 2008 21:08:25 -0800, [EMAIL PROTECTED] wrote: Git and Mercurial cannot import Subversion $FreeBSD$ lines so far, and you may end up submitting patches that include unexpanded forms of the $FreeBSD: $ text. These will fail to apply if they same patch touches nearby lines. Ahm, yes. sed -e's|$FreeBSD: [^$]* \$|$FreeBSD$|g' should help in this case. Not sure I understand what is meant by unexpanded here, since it looks as if this sed example would convert an expanded form -- containing the version info -- to an unexpanded one that merely shows where that info should go. Perhaps it's my ClearCase background showing through, but I'd think it highly desirable for a patch to include what I think of as the expanded tag line -- including the version info, as it appears in the distributed files under /usr/src -- thereby explicitly showing the version on which the patch is based (the base contributor in ClearCase-speak). This should greatly simplify merging in the (likely) event that other development has occurred on the same file in the meantime -- provided one is using a 3-way merge tool that understands such things. You are right, of course. The fact that `$FreeBSD$' is extracted in unexpanded form by the current svn-hg converter is a limitation of the Python bindings of Subversion. They do not support expansion of the svn:keywords property of checked out files. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: btx/pxeboot problem
On Tue, Dec 02, 2008 at 01:48:17PM +0200, Danny Braniss wrote: latest pxeboot (7.1): mother-boardNIC/LOM CPU - --- --- Intel SWV25 em xeonworks fine SUN X2200bgeamd works fine DELL PE 2950 bcexeonfailes 95% of the times hangs or goes into btx dump regs. mode :-) Intel SE7320VP21 mskxeonfailes 50% of the times - hangs pxeboot with btx.S 1.45 2008/02/27 23:35:39, works fine. so it seems that changes since 1.45 have fixed it for some, but it brakes for others :-). I can help testing, but btx is way out of my league. interesting, so this is the same problem i was seeing on the Asus/amd machines here... the commit log for 1.47 mention interrupt issues which are consistent with the random hangs or errors that I see while booting over the network. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/btx/btx/btx.S.diff?r1=1.46;r2=1.47 I wonder if the hangs are related to interrupts coming in at the wrong time. I also wonder whether the same symptoms might also affect the standard loader and not just pxeloader, in which case the problem would be slightly more serious. I am afraid my ability to debug the problem isn't going much beyond this... cheers luigi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
unionfs kernel panic on 7.1-PRERELEASE
Not sure where to go with this one any help appreciated:-
FreeBSD dedicated11.multiplay.co.uk 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #4: Tue Dec 2 16:53:30 UTC 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/MULTIPLAY i386
kgdb kernel /var/crash/vmcore.1
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd...
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x150
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0624115
stack pointer = 0x28:0xe62c3b80
frame pointer = 0x28:0xe62c3ba8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 763 (srcds_i686)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 2m5s
Physical memory: 1007 MB
Dumping 53 MB: 38 22 6
warning: kld_current_sos: Can't read filename: Input/output error
Reading symbols from /boot/kernel/acpi.ko...Reading symbols from
/boot/kernel/acpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from
/boot/kernel/linprocfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linprocfs.ko
Reading symbols from /boot/kernel/linux.ko...Reading symbols from
/boot/kernel/linux.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/kernel/unionfs.ko...Reading symbols from
/boot/kernel/unionfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/unionfs.ko
#0 doadump () at pcpu.h:196
196 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) list *0xc0624115
0xc0624115 is in getvnode (/usr/src/sys/kern/vfs_syscalls.c:3969).
3964fp = NULL;
3965if (fdp == NULL)
3966error = EBADF;
3967else {
3968FILEDESC_SLOCK(fdp);
3969if ((u_int)fd = fdp-fd_nfiles ||
3970(fp = fdp-fd_ofiles[fd]) == NULL)
3971error = EBADF;
3972else if (fp-f_vnode == NULL) {
3973fp = NULL;
(kgdb) bt
#0 doadump () at pcpu.h:196
#1 0xc05a0937 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2 0xc05a0c09 in panic (fmt=Variable fmt is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3 0xc072eb8c in trap_fatal (frame=0xe62c3b40, eva=336) at
/usr/src/sys/i386/i386/trap.c:939
#4 0xc072ee10 in trap_pfault (frame=0xe62c3b40, usermode=0, eva=336) at
/usr/src/sys/i386/i386/trap.c:852
#5 0xc072f7cc in trap (frame=0xe62c3b40) at /usr/src/sys/i386/i386/trap.c:530
#6 0xc071563b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
#7 0xc0624115 in getvnode (fdp=0xc40b4d00, fd=4, fpp=0xe62c3c70) at
/usr/src/sys/kern/vfs_syscalls.c:3969
#8 0xc3e2a13d in getdents_common (td=0xc408f460, args=0xe62c3cfc, is64bit=0) at
/usr/src/sys/modules/linux/../../compat/linux/linux_file.c:446
#9 0xc072f165 in syscall (frame=0xe62c3d38) at
/usr/src/sys/i386/i386/trap.c:1090
#10 0xc07156a0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255
#11 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) frame 7
#7 0xc0624115 in getvnode (fdp=0xc40b4d00, fd=4, fpp=0xe62c3c70) at
/usr/src/sys/kern/vfs_syscalls.c:3969
3969if ((u_int)fd = fdp-fd_nfiles ||
(kgdb) print *fdp
$1 = {fd_ofiles = 0x140, fd_ofileflags = 0x154 Address 0x154 out of bounds, fd_cdir = 0x168, fd_rdir = 0x17c, fd_jdir = 0x18c,
fd_nfiles = 512, fd_map = 0xc3bed560, fd_lastfile = 4,
fd_freefile = 5, fd_cmask = 18, fd_refcnt = 1, fd_holdcnt = 1, fd_sx = {lock_object = {lo_name = 0xc076e1c2 filedesc
structure, lo_type = 0xc076e1c2 filedesc structure, lo_flags = 37421056,
lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, sx_lock = 17, sx_recurse = 0}, fd_kqlist = {slh_first
= 0x0}, fd_holdleaderscount = 0, fd_holdleaderswakeup = 0}
(kgdb) print fd
$2 = 4
(kgdb) print fdp-fd_ofiles
$3 = (struct file **) 0x140
(kgdb) print fdp-fd_ofiles[fd]
Cannot access memory at address 0x150
(kgdb) print fdp-fd_ofiles[0]
Cannot access memory at address 0x140
(kgdb) print *fdp-fd_ofiles
Cannot access memory at address 0x140
0xc3e2a13d is in getdents_common
(/usr/src/sys/modules/linux/../../compat/linux/linux_file.c:446).
441 nbytes = sizeof(linux_dirent);
442 justone = 1;
443 } else
444 justone = 0;
445
446
Help debugging, machine won't boot anymore.
I have a machine running 7.0-STABLE/amd64 and it has suddenly stopped booting. It just leaves me at the debugger with this message: Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x8:0x804d913d stack pointer = 0x10:0x80c9ec10 frame pointer = 0x10:0x80c9ec70 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [thread pid 0 tid 0 ] Stopped at device_probe_child+0x61:movq0x28(%rax),%rsi db dmesg at http://foo.is/~baldur/enigmaboot.txt The ACPI warning has always been there. Any places of interest in the debugger? What's a likely culprit? bad RAM? Baldur ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unionfs kernel panic on 7.1-PRERELEASE
On Tue, Dec 02, 2008 at 04:42:58PM -, Steven Hartland wrote:
Not sure where to go with this one any help appreciated:-
FreeBSD dedicated11.multiplay.co.uk 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE
#4: Tue Dec 2 16:53:30 UTC 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/MULTIPLAY i386
kgdb kernel /var/crash/vmcore.1
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd...
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x150
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0624115
stack pointer = 0x28:0xe62c3b80
frame pointer = 0x28:0xe62c3ba8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 763 (srcds_i686)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 2m5s
Physical memory: 1007 MB
Dumping 53 MB: 38 22 6
warning: kld_current_sos: Can't read filename: Input/output error
Reading symbols from /boot/kernel/acpi.ko...Reading symbols from
/boot/kernel/acpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from
/boot/kernel/linprocfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linprocfs.ko
Reading symbols from /boot/kernel/linux.ko...Reading symbols from
/boot/kernel/linux.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/kernel/unionfs.ko...Reading symbols from
/boot/kernel/unionfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/unionfs.ko
#0 doadump () at pcpu.h:196
196 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) list *0xc0624115
0xc0624115 is in getvnode (/usr/src/sys/kern/vfs_syscalls.c:3969).
3964fp = NULL;
3965if (fdp == NULL)
3966error = EBADF;
3967else {
3968FILEDESC_SLOCK(fdp);
3969if ((u_int)fd = fdp-fd_nfiles ||
3970(fp = fdp-fd_ofiles[fd]) == NULL)
3971error = EBADF;
3972else if (fp-f_vnode == NULL) {
3973fp = NULL;
(kgdb) bt
#0 doadump () at pcpu.h:196
#1 0xc05a0937 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2 0xc05a0c09 in panic (fmt=Variable fmt is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3 0xc072eb8c in trap_fatal (frame=0xe62c3b40, eva=336) at
/usr/src/sys/i386/i386/trap.c:939
#4 0xc072ee10 in trap_pfault (frame=0xe62c3b40, usermode=0, eva=336) at
/usr/src/sys/i386/i386/trap.c:852
#5 0xc072f7cc in trap (frame=0xe62c3b40) at
/usr/src/sys/i386/i386/trap.c:530
#6 0xc071563b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
#7 0xc0624115 in getvnode (fdp=0xc40b4d00, fd=4, fpp=0xe62c3c70) at
/usr/src/sys/kern/vfs_syscalls.c:3969
#8 0xc3e2a13d in getdents_common (td=0xc408f460, args=0xe62c3cfc,
is64bit=0) at /usr/src/sys/modules/linux/../../compat/linux/linux_file.c:446
#9 0xc072f165 in syscall (frame=0xe62c3d38) at
/usr/src/sys/i386/i386/trap.c:1090
#10 0xc07156a0 in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:255
#11 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) frame 7
#7 0xc0624115 in getvnode (fdp=0xc40b4d00, fd=4, fpp=0xe62c3c70) at
/usr/src/sys/kern/vfs_syscalls.c:3969
3969if ((u_int)fd = fdp-fd_nfiles ||
(kgdb) print *fdp
$1 = {fd_ofiles = 0x140, fd_ofileflags = 0x154 Address 0x154 out of
bounds, fd_cdir = 0x168, fd_rdir = 0x17c, fd_jdir = 0x18c, fd_nfiles =
512, fd_map = 0xc3bed560, fd_lastfile = 4,
fd_freefile = 5, fd_cmask = 18, fd_refcnt = 1, fd_holdcnt = 1, fd_sx =
{lock_object = {lo_name = 0xc076e1c2 filedesc structure, lo_type =
0xc076e1c2 filedesc structure, lo_flags = 37421056,
lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}},
sx_lock = 17, sx_recurse = 0}, fd_kqlist = {slh_first = 0x0},
fd_holdleaderscount = 0, fd_holdleaderswakeup = 0}
(kgdb) print fd
$2 = 4
(kgdb) print fdp-fd_ofiles
$3 = (struct file **) 0x140
(kgdb) print fdp-fd_ofiles[fd]
Cannot access memory at address 0x150
(kgdb) print fdp-fd_ofiles[0]
Cannot access memory at address 0x140
(kgdb) print *fdp-fd_ofiles
Cannot access memory at address 0x140
0xc3e2a13d is in getdents_common
TCSBRK not implemented in linux compat
Hi,
While trying to get a linux binary running on FreeBSD I encountered
the following problem during serial port I/O.
Dec 1 22:22:34 soekris kernel: linux: pid 7239 (linuxbinary): ioctl
fd=0, cmd=0x5409 ('T',9) is not implemented
0x5409 turns out to be TCSBRK, which is not implemented (yet?). Can
anyone give me some clues where / how to start implementing this? It
seems like the linux way of handling it is to call tcdrain(), but I'm
not sure as to how this translates to the FreeBSD compat layer.
Thanks,
Regards,
Arjan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TCSBRK not implemented in linux compat
On Tue, Dec 02, 2008 at 09:56:28PM +0100, Arjan van der Velde wrote:
Hi,
While trying to get a linux binary running on FreeBSD I encountered
the following problem during serial port I/O.
Dec 1 22:22:34 soekris kernel: linux: pid 7239 (linuxbinary): ioctl
fd=0, cmd=0x5409 ('T',9) is not implemented
0x5409 turns out to be TCSBRK, which is not implemented (yet?). Can
anyone give me some clues where / how to start implementing this? It
seems like the linux way of handling it is to call tcdrain(), but I'm
not sure as to how this translates to the FreeBSD compat layer.
I believe you want to talk to Ed Schouten as this is a TTY thing..
I CCed him
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unionfs kernel panic on 7.1-PRERELEASE
Yes every time, I've got a half life 2 dedicated install mounted under unionfs:- mount -t unionfs -o noatime -o below /usr/local/games/hl2ds /usr/local/games/servers/1 As soon as I start the server from under servers/1 the machine panics I'm thinking its a combination of the Linux ABI and unionfs interaction which is causing the issue. Regards Steve - Original Message - From: Kostik Belousov [EMAIL PROTECTED] To: Steven Hartland [EMAIL PROTECTED] Cc: freebsd-hackers@freebsd.org Sent: Tuesday, December 02, 2008 8:39 PM Subject: Re: unionfs kernel panic on 7.1-PRERELEASE Is it reproducible ? The start of *fdp structure looks very suspicious, fd_ofiles = 0x140, fd_ofileflags = 0x154, fd_cdir = 0x168, fd_rdir = 0x17c, fd_jdir = 0x18c The values are consequently increasing by 0x14, except fd_jdir, and pointer values are wrong for kernel. 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 [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TCSBRK not implemented in linux compat
Hello Arjan,
* Arjan van der Velde [EMAIL PROTECTED] wrote:
While trying to get a linux binary running on FreeBSD I encountered the
following problem during serial port I/O.
Dec 1 22:22:34 soekris kernel: linux: pid 7239 (linuxbinary): ioctl
fd=0, cmd=0x5409 ('T',9) is not implemented
0x5409 turns out to be TCSBRK, which is not implemented (yet?). Can
anyone give me some clues where / how to start implementing this? It
seems like the linux way of handling it is to call tcdrain(), but I'm
not sure as to how this translates to the FreeBSD compat layer.
I think you could just make it call TIOCDRAIN directly. Unfortunately
that's not correct if the argument is 0, because then we have to call
TIOCSBRK and TIOCCBRK with a 250 msec interval. I guess adding some kind
of printf() there should be good enough for now.
I can't look into it right now, because I have to get up at 6:15
tomorrow. Sorry! :-/
--
Ed Schouten [EMAIL PROTECTED]
WWW: http://80386.nl/
pgpHUWMPMVbVk.pgp
Description: PGP signature
Re: TCSBRK not implemented in linux compat
While trying to get = a linux binary running on FreeBSD I encountered
the following prob= lem during serial port I/O.
Dec 1 22:22:34 soekris kernel: = linux: pid 7239 (linuxbinary): ioctl
fd=0, cmd=0x5409 ('T',9) = is not implemented
0x5409 turns out to be TCSBRK, which is = not implemented (yet?). Can
anyone give me some clues where / how = to start implementing this?
It
seems like the linux way of handlin= g it is to call tcdrain(), but
I'm
not sure as to how this transla= tes to the FreeBSD compat layer.
It should probably be translated to= the same BSD call. What it does
is
drain the buffer then send the seria= l BREAK signal: a low-voltage
signal lasting
longer than the length of o= ne normal character. The other side can
detect this and generate
an inte= rrupt, which then may get translated to a signal (see the
stty parametersn= bsp;
ignbrk, brkint).
-SB
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tcsh loses the foreground process group?
In article [EMAIL PROTECTED] you write: [ ... ] I'm running 6-STABLE (6.4-PRE as of 24 Nov right now), tcsh 6.15.00, which shows tcsh 6.15.00 (Astron) 2007-03-03 (i386-intel-FreeBSD) options wide,nls,dl,al,kan,sm,rh,color,filec as $version. The symptom is that when I do a long-ish running task inside a `` expansion that I then ^C, nobody gets the foreground process group... I never get a prompt back after the ^C, and ^T gets me load: 0.27 no foreground process group [ ... ] One portable reproduction: # cd /usr/src # less `egrep -lir '^Foo.*baz' *` ^Cload: 0.02 no foreground process group (I typed ^C ^T) SIGKILL to the shell seems to be the only way to get things back to normal. I've gotten one me too, which indicated that SIGHUP to the shell will also make it go away, but does not solve the problem. I've got another FreeBSD machine available that was running tcsh 6.14.00, and it does _NOT_ display the problem. When I build 6.15.00 on that same box (/usr/src is more up to date than the install right now), that does fail. Thus I'm pretty comfortable saying that it's a tcsh bug of some sort, and probably a regression. Hopefully this can be fixed (PR being filed now) before 6.4 releases... -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5 / 37N 20' 15.3 Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: keeping track of local modifications
On Tue, Dec 2, 2008 at 6:52 AM, Giorgos Keramidas [EMAIL PROTECTED] wrote: On Mon, 01 Dec 2008 21:08:25 -0800, [EMAIL PROTECTED] wrote: Git and Mercurial cannot import Subversion $FreeBSD$ lines so far, and you may end up submitting patches that include unexpanded forms of the $FreeBSD: $ text. These will fail to apply if they same patch touches nearby lines. Ahm, yes. sed -e's|$FreeBSD: [^$]* \$|$FreeBSD$|g' should help in this case. You are right, of course. The fact that `$FreeBSD$' is extracted in unexpanded form by the current svn-hg converter is a limitation of the Python bindings of Subversion. They do not support expansion of the svn:keywords property of checked out files. good evening Giorgos and Eygene (and list), So am i to understand that there is no automatic way to use Hg or Git? -- and as Eygene said in order to use them in such a manner special patching will be required? I too am looking to set something else up other than my SVN repository because i personally prefer Hg and Git to SVN. Thank you to all who have contributed to this conversation it has been extremely informative for me and i'm sure several others. I hope everyone is looking forward to the holidays Respectfully, -- /jT http://git.zen-sources.org/?p=kernel/zenmm.git;a=summary ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
NFS ( amd?) dysfunction descending a hierarchy
I seem to have a fairly- (though not deterministly so) reproducible
mode of failure with an NFS-mounted directory hierarchy: An attempt to
traverse a sufficiently large hierarchy (e.g., via tar zcpf or rm
-fr) will fail to visit some subdirectories, typically apparently
acting as if the subdirectories in question do not actually exist
(despite the names having been returned in the output of a previous
readdir()).
The file system is mounted read-write, courtesy of amd(8); none of
the files has any non-default flags; there are no ACLs involved;
and I owned the lot (that is, as owning user of the files).
An example of sufficiently large has been demonstrated to be a recent
copy of a FreeBSD ports tree. (The problem was discovered using a
hierarchy that had some proprietary content; I tried a copy of the ports
tree to see if I could replicate the issue with something a FreeBSD
hacker would more likely have handy. And avoid NDA issues. :-})
Now, before I go further: I'm not pointing the finger at FreeBSD,
here (yet). At minimum, there could be fault with FreeBSD (as the NFS
client); with amd(8); with the NetApp Filer (as the NFS server);
or the network -- or the configuration(s) of any of them.
But I just tried this, using the same NFS server, but a machine running
Solaris 8 as an NFS client, and was unable to re-create the problem.
And I found a way to avoid having the problem occur using a FreeBSD NFS
client: whack amd(8)'s config so that the dismount_interval is 12 hours
instead of the default 2 minutes, thus effectivly preventing amd(8) from
its normal attempts to unmount file systems. Please note that I don't
consider this a fix -- or even an acceptable circumvention, in the long
term. Rather, it's a diagnostic change, in an attempt to better
understand the nature of the problem.
Here are step-by-step instructions to recreate the problem;
unfortunately, I believe I don't have the resources to test this
anywhere but at work, though I will try it at home, to the extent
that I can:
* Set up the environment.
* The failing environment uses NetApp filers as NFS servers. I don't
know what kind or how recent the software is on them, but can
find out. (I exepct they're fairly well-maintained.)
* Ensure that the NFS space available is at least 10 GB or more.
I will refer to this as ~/NFS/, as I tend to create such symlinks
to keep track of things.
* I used a dual, quad-core machine running FreeBSD RELENG_7_1 as of
yesterday morning as an NFS client. It also had a recently-updated
/usr/ports tree, which was a CVS working directory (so each real
subdirectory also had a CVS subdirectory within it).
* Set up amd(8) so that ~/NFS is mounted on demand when it's
referenced, and only via amd(8). Ensure that the dismount_interval
has the default value of 120 seconds.
* Create a reference tarball.
* cd /usr tar zcpf ~/NFS/ports.tgz ports/
* Create the test directory hierarchy.
* cd ~/NFS tar zxpf ports.tgz
* Clear any cache.
* Unmount ~/NFS, then re-mount it. Or just reboot the NFS client
machine. Or arrange to have done all of the above set-up stuff
from a differnet NFS client.
* Set up for information capture (optional).
* Use ps(1) or your favorite alternative tool to determine the PID for
amd(8). Note that `cat /var/run/amd.pid` won't do the trick. :-{
* Run ktrace(1) to capture activity from amd(8) and its descendants,
e.g.:
sudo ktrace -dip ${amd_pid} -f ktrace_amd.out
* Start a packet-capture for NFS traffic, e.g.:
sudo tcpdump -s 0 -n -w nfs.bpf host ${nfs_server}
* Start the test.
* Do this under ktrace(1), if you did the above optional step:
rm -fr ~/NFS/ports; echo $?
As soon as rm(1) issues a whine, you might as well interrupt it
(^C).
* Stop the information capture, if you started it.
* ^C for the tcpdump(1) process.
* sudo ktrace -C
If the packet capture file is too big for the analysis program you
prefer to digest as a unit, see the net/tcpslice port for a bit of
relief. (Wireshark seems to want to read an entire packet capture file
into main memory.)
I have performed the above, with the information-gathering step; I can
*probably* make that information available, but I'll need to check --
some organizations get paranoid about things like host names. I don't
expect that my current employer is, but I don't know yet, so I won't
promise.
In the mean time, I should be able to extract somewhat-relevant
information from what I've collected, if that would be useful. While I
wouldn't mind sharing the results, I strongly suspect that blow-by-blow
analysis wouldn't be ideal for this (or any other) mailing list; I would
be very happy to work with others to figure out what's gone wrong (or is
misconfigured) and get things working properly.
If someone(s) would be willing to help, I'd appreciate it very much. If
(enough) folks would actually prefer that the details stay in
AMD64 qemu completely broken?
I decided to take the comments about testing ZFS to heart --- so I decided to try copying my 7.0 v6 ZFS configuration into a qemu instance and upgrading it. To do this, I carefully copied my UFS boot partition and my ZFS partion to a physical USB disk that I could put on a system to do the test. After compiling qemu and loading the kqemu and aio kernel module, I started the emulator, first in VNC mode. It loaded the kernel (currently 7.1-RC) and tried to boot, but kept failing either shortly after kbdmux detected a keyboard or it would get through to mounting root and not find any drives. For reference, besides the display option (ie: -vnc or whatever), my command line was: qemu-system-x86_64 -hda /dev/da0 -snapshot -m 512 I couldn't scroll back in VNC mode using the pause/break key, so I tried to get qemu running directly in X. Now... I see a few posts stating that running qemu remotely causes an X protocol error. I can confirm that. Something about Qemu's use of X will no work over an SSH remote connection (with -X), nor will it work with dxpc. It dies for me every time at X event sequence number 22. Xterms work. Gimp even works. qemu does not. So I got a vnc server running to run it locally. And now it crashes reliably in one spot. boot0 and boot1 don't recognize the keyboard ... but the press space after crash does. Besides that quirk, the 7.1-RC kernel crashes with the following transcript reliably: MADT: Forcing active-low polarity and level trigger for SCI kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id=00 instruction pointer = 0x8:0x ... and so on. I'd like to test this... has anyone any successes with the AMD64 qemu? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
ZFS make install with exec=no in /tmp
Hello hackers, I was wondering if there is a work around for this... In 8.0-current I have installed the new version of ZFS and upgraded the filing systems to 13. I had a thought that I would make a zfs for /tmp and set the exec to no (thinking that nothing should ever be executed in the tmp). All seemed to work ok, however, I ran into a problem when I was installing a new world. The script immediately bombed out with a permission denied message. I remembered seeing that type of message before when I was testing the no- exec bit in /tmp before, so I reset it to 'yes' and all is well and installed fine.. Is there any way to specify what directory is used for building and executing the install scripts? Ta, Peg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZFS make install with exec=no in /tmp
Pegasus Mc Cleaft wrote: Hello hackers, I was wondering if there is a work around for this... In 8.0-current I have installed the new version of ZFS and upgraded the filing systems to 13. I had a thought that I would make a zfs for /tmp and set the exec to no (thinking that nothing should ever be executed in the tmp). All seemed to work ok, however, I ran into a problem when I was installing a new world. The script immediately bombed out with a permission denied message. I remembered seeing that type of message before when I was testing the no- exec bit in /tmp before, so I reset it to 'yes' and all is well and installed fine.. Is there any way to specify what directory is used for building and executing the install scripts? The standard UNIX way is to set the TMPDIR env variable. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: keeping track of local modifications
jT, good day.
Tue, Dec 02, 2008 at 07:15:55PM -0500, jT wrote:
On Tue, Dec 2, 2008 at 6:52 AM, Giorgos Keramidas [EMAIL PROTECTED] wrote:
The fact that `$FreeBSD$' is extracted in unexpanded form by the current
svn-hg converter is a limitation of the Python bindings of Subversion.
They do not support expansion of the svn:keywords property of checked
out files.
So am i to understand that there is no automatic way to use Hg or
Git? -- and as Eygene said in order to use them in such a manner
special patching will be required?
I am happily using Git for my FreeBSD work: I have local repository that
is just CVSupped from time to time to sync the master branch to the
mainline and, possibly, rebase my work against it. This isn't even
git-svn, just Git repo + CVSup. Probably git-svn will also work here,
but as ports are still using CVS and I have both ports and src
repositories, this is just easier for me to use CVSup. Yes, I am losing
the commit history, but I don't care about this: cvsweb.freebsd.org is
still alive and kicking.
About patching: the point was that some percentage of patches, that are
carrying '$FreeBSD$' tags in their body, won't apply cleanly in some
situations (namely, when your patch is based on the revision N and
maintainer applies it to the revision != N). It turns to be true even
for Subversion itself, but the hope isn't completely lost -- for some
cases patches can be applied with fuzz (namely, ignoring the '$Id'
mismatch). Larry Wall and others were smart about introducing the fuzz
factor ;))
I too am looking to set something
else up other than my SVN repository because i personally prefer Hg
and Git to SVN. Thank you to all who have contributed to this
conversation it has been extremely informative for me and i'm sure
several others.
I think that you can at least try to work with git-svn: you'll check out
the master timely and will be able to rebase your own work, provided
that it is lying in the separate branches. This way you'll have the
whole history, at least you should.
Don't know for Mercurial, hadn't used it for FreeBSD yet.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpW7qBNX3UCB.pgp
Description: PGP signature
Re: Controlling a process
setrlimit(2)
Ok thanks a lot
On Tue, Dec 2, 2008 at 10:37 AM, Eygene Ryabinkin [EMAIL PROTECTED] wrote:
Maslan, good day.
Tue, Dec 02, 2008 at 09:53:09AM +, Maslan wrote:
What is the best way to control a process (running in chroot env):
1- Execution time
2- Memory limit
And to be able to kill the process when it breaks this limits.
man 2 setrlimit
Finally, i would like to know the exit status of the process or the
signal that killed it (sigfault, .)
If you're spawning the process in question, then 'man 2 wait'.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
--
System Programmer
--
I'm Searching For Perfection,
So Even If U Need Portability U've To Use Assembly ;-)
--
http://libosdk.berlios.de
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
